[Ovmsdev] Firmware release 3.3.004
Chris van der Meijden
chris at arachnon.de
Sat Mar 30 19:59:40 HKT 2024
Thank you for your quick response. Now I understand :-)
Regards
Chris
Am Samstag, dem 30.03.2024 um 12:11 +0100 schrieb Michael Balzer:
> Chris,
>
> this does not affect the standard "edge" builds in any way, these
> continue to be done on the latest "master" branch state.
>
> The release branch is a pure backport branch. It's not intended to
> get any commits that are not part of "master" already. It's only
> purpose is to receive cherry-picks of bug fix commits from the master
> branch, and to be used as the build branch for eap & main.
>
> If you're a developer contributing some bug fix that needs to be
> included in the release branch (and trigger an eap/main update
> cycle), you can either simply request that in your PR, and we will
> do the cherry-pick for you, or you can create a secondary PR for the
> current release branch. Note: the secondary PR needs to be based off
> the release branch, not the master branch -- but you'll normally be
> able to simply use your local release branch for this, as there will
> normally be no concurrent changes to that branch. Btw, gitk is a
> great assistance in cherry-picking, simply switch the branch, then
> select the pick action from the commit's context menu (that's "Diese
> Version pflücken" in the german version).
>
> Only if you maintain some eap/main release server, you'll need to
> switch to the release branch to build an update to the eap/main
> release. That's only necessary if new commits (fixes) have been
> pushed to the release branch, and can be automated easily.
>
> Regards,
> Michael
>
>
> Am 30.03.24 um 11:39 schrieb Chris van der Meijden:
>
> >
> > Hi Michael,
> >
> > sorry, I have diffulties to understand the new sceme. Could you
> > explain it a bit more?
> >
> > I try to keep my reposotitory up to date with the main branch and
> > compile the newest version to have my own (test) version of the
> > newest commited code running. Do I now need to switch to the
> > release branch? Will all commits in the release branch find their
> > way at some time to the master branch, or will some drop out? Is
> > the release branch now an even more early eap branch?
> >
> > What would you suggest to do for me, as I'm interested in compiling
> > the latest, commited, code for just for testing purposes?
> >
> > Thanx.
> >
> > Regards
> >
> > Chris
> >
> > Am Samstag, dem 30.03.2024 um 09:20 +0100 schrieb Michael Balzer:
> >
> > > We need to add a few fixes to the 3.3.004 release.
> > >
> > > I'd like to propose a new scheme to release important fixes to
> > > eap /
> > > main. In the past, we set a new release tag if important fixes
> > > were
> > > missing. That didn't take into account, that fixes could mix with
> > > new
> > > features, that should not yet be released. That's the case now.
> > >
> > > In my other projects, I create a dedicated release branch on
> > > every major
> > > release, and cherry-pick important fixes from master into that
> > > branch.
> > >
> > > My proposal is, that we adopt that scheme here as well, i.e. add
> > > a
> > > branch "release-3.3.004" beginning at tag "3.3.004", pick the
> > > commits
> > > there that need to be added to 3.3.004, and publish the builds of
> > > that
> > > branch to eap/main.
> > >
> > > The slight disadvantage is more a theoretical issue: our build
> > > version
> > > numbering scheme (git describe --always --tags --dirty) uses the
> > > commit
> > > distance to the last tag, so there will be a difference between
> > > the same
> > > version number 3.3.004-x on the release branch vs. on the master
> > > branch.
> > > But that only applies to the version number, not to the full
> > > version
> > > code, as that also includes the abbreviated most recent commit
> > > hash at
> > > build time.
> > >
> > > Version numbers remain easily comparable: there will always be at
> > > least
> > > the same number of commits in the release branch as in the master
> > > branch, so the version number on edge is still always equal or
> > > higher to
> > > eap/main.
> > >
> > > As an example & for reviews / tests, I've created the branch
> > > "release-3.3.004" as proposed, including the fixes that need to
> > > be
> > > included now. The build version for this is currently
> > > 3.3.004-4-gab8f16b7, that would become the eap / main release
> > > now.
> > >
> > > Any objections?
> > >
> > > Regards,
> > > Michael
> > >
> > >
> > > Am 25.03.24 um 02:22 schrieb Mark Webb-Johnson:
> > >
> > > > I’ve done the same. 3.3.004 is now in EAP.
> > > >
> > > > A huge thanks to everyone involved in this.
> > > >
> > > > Regards, Mark
> > > >
> > > >
> > > > > On 23 Mar 2024, at 5:28 PM, Michael Balzer
> > > > > <dexter at expeedo.de> wrote:
> > > > >
> > > > > Everyone,
> > > > >
> > > > > I've just tagged version 3.3.004 and released the build to
> > > > > EAP on ovms.dexters-web.de -- Mark, please follow up. As
> > > > > usual, we will release this to MAIN in about a week.
> > > > >
> > > > > This release has been long overdue, it includes numerous new
> > > > > features, new vehicles and of course lots of bug fixes.
> > > > >
> > > > > A huge thank you to everyone involved in this collaborative
> > > > > effort!
> > > > >
> > > > > Changes since 3.3.003:
> > > > >
> > > > > - MG EV Added support for MG5 (2020 - 2023) Short Range
> > > > > - MG EV Added support for MG ZS EV (2023 - ) and MG5 (2020 -
> > > > > 2023) Long Range
> > > > > - OVMS Server v3 metrics filtering
> > > > > New configs:
> > > > > [server.v3] metrics.include -- Comma-separated
> > > > > list of metric names (with possible wildcard) matching
> > > > > metrics to send
> > > > > [server.v3] metrics.exclude -- Comma-separated
> > > > > list of metric names (with possible wildcard) matching
> > > > > metrics to not send
> > > > > - Renault Zoe Phase 2: Initial support
> > > > > - Improved output of bms shell command for narrow windows.
> > > > > New commands:
> > > > > bms volt -- Output only
> > > > > voltage info if available
> > > > > bms temp -- Output only
> > > > > temperature info if available
> > > > > - Hyundai Ioniq 5: Initial support
> > > > > - Support for specifying units in scripts
> > > > > New commands:
> > > > > metrics units -- Display available
> > > > > unit identifiers
> > > > > metrics get -- Get at a
> > > > > particular metric value (with a specified unit)
> > > > > Extended commands:
> > > > > metrics set -- Support setting
> > > > > with a specified unit
> > > > > Extend functions
> > > > > OvmsMetrics.Value -- Optionally
> > > > > specify a unit (and make 'decode' work) and to get values
> > > > > with units.
> > > > > OvmsMetrics.GetValues -- Optionally
> > > > > specify a unit to get values with units.
> > > > > OvmsMetrics.AsFloat -- Optionally
> > > > > specify a unit
> > > > > New DukTape function
> > > > > OvmsMetrics.HasValue -- Returns true if
> > > > > the metric has a valid value.
> > > > > - Added power consumptions units: kWhP100K,KPkWh,MPkWh
> > > > > - Consolidate custom trip power consumption metrics to single
> > > > > value (kWhP100K)
> > > > > in Kia Niro and Kia Soul
> > > > > - VFS: sorted directory listings & recursive directory
> > > > > listings
> > > > > New commands:
> > > > > vfs rls <path> -- List <path> and
> > > > > all subdirectory contents
> > > > > - Vehicle: emit standard events on charge/generator
> > > > > connection type changes
> > > > > New events:
> > > > > vehicle.charge.type -- Vehicle charge
> > > > > connection type has changed (e.g. ccs/type2/…)
> > > > > vehicle.gen.type -- Vehicle generator
> > > > > connection type has changed
> > > > > - CAN logging: add possibility to log events (name) and
> > > > > metrics (JSON object with name, value, unit)
> > > > > New configs:
> > > > > [can] log.events_filters -- comma-separated
> > > > > list of filters (with possible wildcard) matching an event
> > > > > name
> > > > > [can] log.metrics_filters -- comma-separated
> > > > > list of filters (with possible wildcard) matching a metric
> > > > > name
> > > > > - Add units Bar, Permille
> > > > > - Add user configuration for groups of metrics
> > > > > Adds the 'ToUser' unit that converts to the user specified
> > > > > unit.
> > > > > Add -u to 'metrics list' to view metrics as user units.
> > > > > - Add completion for metrics set/get as well as units
> > > > > - Mini Cooper SE: Initial support
> > > > > - Hyundai Ioniq vFL: trip metrics, range estimations, TPMS,
> > > > > web configuration,
> > > > > charge type detection, charge speed & time estimation
> > > > > New configs:
> > > > > [xhi] ctp.maxpower -- Default charge
> > > > > power limit [kW] for charge time estimations, default 0 =
> > > > > unlimited
> > > > > [xhi] ctp.soclimit -- SOC level [%] for
> > > > > secondary charge time estimation (sufficient SOC), default 80
> > > > > [xhi] notify.charge.delay.ccs -- Wait time [sec] for
> > > > > DC charge power to ramp up before sending the notification,
> > > > > default 15
> > > > > [xhi] notify.charge.delay.type2 -- … same for AC
> > > > > charging, default 3
> > > > > [xhi] range.ideal -- ideal new car range
> > > > > [km], default 200
> > > > > [xhi] range.user -- typical current
> > > > > user range [km], default 200
> > > > > [xhi] range.smoothing -- Number of SOC
> > > > > samples, default 10 = ~ 5% SOC
> > > > > [xhi] tpms.pressure.warn -- default 230
> > > > > [kPa]
> > > > > [xhi] tpms.pressure.alert -- default 220 [kPa]
> > > > > [xhi] tpms.temp.warn -- default 90 [°C]
> > > > > [xhi] tpms.temp.alert -- default 100 [°C]
> > > > > New metrics:
> > > > > xhi.b.range.user -- actual current user
> > > > > range [km]
> > > > > xhi.e.state -- General/ignition
> > > > > state flags
> > > > > - Module: support deep sleep schedules
> > > > > New commands:
> > > > > module sleep -- Shutdown all
> > > > > components and enter deep sleep for a time span or until a
> > > > > specific time.
> > > > > - Add support for user-configured metrics in the web
> > > > > interface and plugins:
> > > > > Adds an extra 'units' stream from the websocket
> > > > > containing sub-streams:
> > > > > - metrics (for the current user unit/label for each
> > > > > metric) (subscribe to units/metrics)
> > > > > - prefs (for any user preferences for unit
> > > > > groups/types) (subscribe to units/prefs)
> > > > > Adds proxy arrays metrics_user[] , metrics_label[]
> > > > > available to plugin pages.
> > > > > Adds various browser javascript functions and methods for
> > > > > plugins related
> > > > > to displaying user configurations Auto-converts metric
> > > > > display to user
> > > > > units in plugins that use attributes
> > > > > - Cellular: add GPS/GNSS state control commands (for power
> > > > > management)
> > > > > New commands:
> > > > > cellular gps [status] -- output current
> > > > > modem GPS/GNSS subsystem status
> > > > > cellular gps start -- start modem
> > > > > GPS/GNSS subsystem
> > > > > cellular gps stop -- stop modem GPS/GNSS
> > > > > subsystem
> > > > > - CAN framework: add bus reset command
> > > > > New commands:
> > > > > can [can1…4] reset -- reset the CAN
> > > > > interface
> > > > > - Vehicle: add support for custom command handlers, see…
> > > > > https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsvehicle-command-plugins
> > > > > - Renault Twizy: read battery energy available from BMS
> > > > > (thanks to Martin Bitz)
> > > > > New metrics:
> > > > > xrt.b.energy.avail -- Current battery
> > > > > energy available [kWh] (aged)
> > > > > xrt.b.energy.full -- Maximum battery
> > > > > energy capacity [kWh] (aged, needs full charge)
> > > > > - Add button on web file editor to reload obd2ECU (when
> > > > > obd2ECU is enabled).
> > > > > - Vehicle: add support for a geofence for valet mode similar
> > > > > to parking/flatbed warnings.
> > > > > New Configs:
> > > > > [vehicle] valet.alarmdistance -- How far away from
> > > > > the original position before raising an alert (in metres)
> > > > > [vehicle] valet.alarminterval -- How often the
> > > > > alarm can be raised in minumtes
> > > > > - Add metric and events related to obd2ecu process:
> > > > > New metric:
> > > > > m.obdc2ecu.on -- Is the OBD2ECU
> > > > > process currently on.
> > > > > New events:
> > > > > obd2ecu.start -- Called after the
> > > > > OBD2ECU process is started.
> > > > > obd2ecu.stop -- Called before the
> > > > > OBD2ECU process is stopped.
> > > > > - Web UI: Add configuration for Valet and Flatbed geofence to
> > > > > the Locations config page.
> > > > > - Network: New 'network ping' command to ping (ICMP) hostname
> > > > > or IP address. (ESP-IDFv4+ only / needs to be enabled in
> > > > > menuconfig - Developer Options)
> > > > > - Vehicle: add automatic module shutdown/reboot based on 12V
> > > > > battery voltage level
> > > > > New configs:
> > > > > [vehicle] 12v.shutdown -- Shutdown voltage
> > > > > level (default: disabled)
> > > > > [vehicle] 12v.wakeup -- Reboot minimum
> > > > > voltage level after shutdown (default: any)
> > > > > [vehicle] 12v.wakeup_interval -- Reboot test
> > > > > interval in seconds (default: 60)
> > > > > New events:
> > > > > vehicle.alert.12v.shutdown -- 12V shutdown
> > > > > threshold reached, entering deep sleep
> > > > > - BYD Atto 3 initial support
> > > > > - Vehicle: add 12V shutdown delay & notification
> > > > > New configs:
> > > > > [vehicle] 12v.shutdown_delay -- Shutdown delay in
> > > > > minutes (default: 2)
> > > > > New events:
> > > > > vehicle.alert.12v.low -- 12V shutdown
> > > > > voltage level detected
> > > > > vehicle.alert.12v.operational -- 12V recovered above
> > > > > shutdown level
> > > > > New notifications:
> > > > > [alert] batt.12v.shutdown -- Alert about
> > > > > imminent 12V shutdown
> > > > > - VFS toolkit: add recursive options to mkdir (-p) & rmdir (-
> > > > > r) commands
> > > > > - Renault-Zoe-Ph1: add Cabin Pre-heat/cool Control
> > > > >
> > > > >
> > > > > Regards,
> > > > > Michael
> > > > >
> > > > > --
> > > > > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> > > > > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> > > > >
> > > > > _______________________________________________
> > > > > OvmsDev mailing list
> > > > > OvmsDev at lists.openvehicles.com
> > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > _______________________________________________
> > > > OvmsDev mailing list
> > > > OvmsDev at lists.openvehicles.com
> > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > >
> > > --
> > > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> > > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> > >
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> >
> >
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240330/46078fbd/attachment-0001.htm>
More information about the OvmsDev
mailing list