[Ovmsdev] Firmware release 3.3.004
Michael Balzer
dexter at expeedo.de
Sat Mar 30 19:11:54 HKT 2024
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
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240330/7decc882/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240330/7decc882/attachment-0001.sig>
More information about the OvmsDev
mailing list