Firmware release 3.3.004
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... - 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
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@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... - 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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... - 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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
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@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... - 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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... - 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
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@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... - 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Applying the scheme as proposed, I've just released 3.3.004-4-gab8f16b7 to eap & main on ovms.dexters-web.de. Regards, Michael Am 30.03.24 um 12:59 schrieb Chris van der Meijden:
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@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... - 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
My friend has a roadster and has a OVT1 cable that has failed; looks like a case of stranded wires being flexed one time too many. He said the connector shell had to be created from scratch but I'm hoping the terminals are standard and can be sourced from somewhere. Is there a part number for these? Craig
Craig, Is this the cable? https://shop.openenergymonitor.com/tesla-roadster-early-model-s-obd2-ovms-ca... <https://shop.openenergymonitor.com/tesla-roadster-early-model-s-obd2-ovms-cable/> It may be quicker, and only slight more costly, to simply replace the entire cable. If you’re looking for just the terminals for either end of the cable, if you can’t find them at the URL below, they’re probably not available in “retail” quantities— https://www.te.com/usa-en/plp/automotive-terminals/Y30g2.html <https://www.te.com/usa-en/plp/automotive-terminals/Y30g2.html> I hope that this assists. Chip
On Apr 1, 2024, at 1:33 PM, Craig Leres <leres@xse.com> wrote:
My friend has a roadster and has a OVT1 cable that has failed; looks like a case of stranded wires being flexed one time too many. He said the connector shell had to be created from scratch but I'm hoping the terminals are standard and can be sourced from somewhere. Is there a part number for these?
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Craig, This might help: https://teslamotorsclub.com/tmc/threads/diagnostic-port-index.98663/ I’ve got thousands here, but postage and hassle would probably be more than the price of a single new OVT-1 cable. Regards, Mark
On Apr 2, 2024, at 04:33, Craig Leres <leres@xse.com> wrote:
My friend has a roadster and has a OVT1 cable that has failed; looks like a case of stranded wires being flexed one time too many. He said the connector shell had to be created from scratch but I'm hoping the terminals are standard and can be sourced from somewhere. Is there a part number for these?
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 4/1/2024 5:23 PM, Mark Webb-Johnson wrote:
This might help:
https://teslamotorsclub.com/tmc/threads/diagnostic-port-index.98663/ <https://teslamotorsclub.com/tmc/threads/diagnostic-port-index.98663/>
I’ve got thousands here, but postage and hassle would probably be more than the price of a single new OVT-1 cable.
Thanks for the link! So it looks like the "Roadster and pre Sept 15 S" female terminals are AMP 173630-1 and AMP 173630-6. Indeed, mouser.com has a 4000 unit minimum for both of these but digikey does not and has many of each in stock. I want terminals because I think I can refurb his cable to use larger gauge wires that won't break so easily. Craig
I was able to source terminals and shell from mouser.com and make a new cable. Here are some part numbers and other info for reference: 173630-1 terminal 22-24 AWG 173630-6 terminal 22-24 AWG 173851-1 shell white 173851-2 shell black (in stock @ mouser.com) 173630-2 terminal 22-24 AWG gold (no stock) 1-173630-2 terminal 22-24 AWG gold (no stock) 173630-7 terminal 22-24 AWG gold (no stock) 173631-1 terminal 16-20 AWG 173631-6 terminal 16-20 AWG 173631-2 terminal 16-20 AWG gold 173631-7 terminal 16-20 AWG gold 1-173631-2 terminal 16-20 AWG gold I used 173630-1 terminals because the PTFE/Teflon jacketed hookup wire I like (Belden 83004) is 24 AWG. I used a delphi 12085271 crimping tool. It's worth noting that mouser flags the black version of the shell as end-of-life. Craig
It's worth noting that mouser flags the black version of the shell as end-of-life.
I noticed that a few months back. I think I may have a ‘hoarding’ problem (7,000 pins and 600 connectors). Need to make sure that our community can still get these cables for the foreseeable future. Regards, Mark.
On 10 Apr 2024, at 3:58 AM, Craig Leres <leres@xse.com> wrote:
I was able to source terminals and shell from mouser.com and make a new cable. Here are some part numbers and other info for reference:
173630-1 terminal 22-24 AWG 173630-6 terminal 22-24 AWG 173851-1 shell white 173851-2 shell black (in stock @ mouser.com) 173630-2 terminal 22-24 AWG gold (no stock) 1-173630-2 terminal 22-24 AWG gold (no stock) 173630-7 terminal 22-24 AWG gold (no stock)
173631-1 terminal 16-20 AWG 173631-6 terminal 16-20 AWG 173631-2 terminal 16-20 AWG gold 173631-7 terminal 16-20 AWG gold 1-173631-2 terminal 16-20 AWG gold
I used 173630-1 terminals because the PTFE/Teflon jacketed hookup wire I like (Belden 83004) is 24 AWG. I used a delphi 12085271 crimping tool.
It's worth noting that mouser flags the black version of the shell as end-of-life.
Craig<IMG_5001.JPG><IMG_5003.JPG><IMG_5004.JPG>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I hadn't updated the build I run on my module since early April. Today I updated to 3.3.003-814-gd7013460, picked up the new CONFIG_OVMS_COMP_POLLER sdkconfig option, but when I run gmake I get *tons* of warnings (more than 300), e.g: gmake[1]: warning: undefined variable 'GNUMAKEFLAGS' The result seems to run ok. And I guess I don't understand why the "ota" version is different from what "git describe" reports. Craig ====================================================== OVMS# ota Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 Firmware: 3.3.004-117-gd7013460-dirty/ota_1/main (build idf v3.3.4-849-g6e214dc33 Jun 26 2024 10:55:23) Running partition: ota_1 Boot partition: ota_1 Factory image: 3.3.002 OTA_O image: 3.3.004-20-g447fd7c4-dirty OTA_1 image: 3.3.004-117-gd7013460-dirty ====================================================== ice 266 % git describe 3.3.003-814-gd7013460 ======================================================
Can you try the full describe command (like we use in the OVMS makefile): git describe --always --tags --dirty Regards, Mark.
On 27 Jun 2024, at 2:03 AM, Craig Leres via OvmsDev <ovmsdev@lists.openvehicles.com> wrote:
I hadn't updated the build I run on my module since early April. Today I updated to 3.3.003-814-gd7013460, picked up the new CONFIG_OVMS_COMP_POLLER sdkconfig option, but when I run gmake I get *tons* of warnings (more than 300), e.g:
gmake[1]: warning: undefined variable 'GNUMAKEFLAGS'
The result seems to run ok.
And I guess I don't understand why the "ota" version is different from what "git describe" reports.
Craig
======================================================
OVMS# ota Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 Firmware: 3.3.004-117-gd7013460-dirty/ota_1/main (build idf v3.3.4-849-g6e214dc33 Jun 26 2024 10:55:23) Running partition: ota_1 Boot partition: ota_1 Factory image: 3.3.002 OTA_O image: 3.3.004-20-g447fd7c4-dirty OTA_1 image: 3.3.004-117-gd7013460-dirty
======================================================
ice 266 % git describe 3.3.003-814-gd7013460
====================================================== _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Since upgrading from 3.3.004-20 I've noticed my modules frequently are not connected to the cell network: OVMS# cell MODEM Status Model: SIM7600 Network Registration: Searching Provider: AT&T Hologram Signal: -105 dBm Mode: LTE,Online State: NetWait Mux: Status up PPP: Not connected Last Error: User Interrupt GPS: Connected on channel: #1 As before, power cycling is a short term fix. While I was looking into this I noticed that both of my production modules had crash counters=1 with stack traces. One looks like an abort() from esp_sha_read_digest_state(). The car for the first crash hasn't moved in more than a week. I drove the 2nd car yesterday (and had to power cycle the ovms module while I was out because I noticed it wasn't connected to the cell network so the module had less than 24 hours of uptime on it when it crashed). Craig ice 1470 % ./backtrace.sh 0x400891bf 0x40089459 0x4026f861 0x4024b93a 0x40244182 0x402470d7 0x4025650b 0x402473a6 0x402473d1 0x4012bd0c 0x4012d3bc 0x4012eb09 0x4012f02f 0x4012b516 0x4011f40b 0x4011f4a9 + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891bf 0x40089459 0x4026f861 0x4024b93a 0x40244182 0x402470d7 0x4025650b 0x402473a6 0x402473d1 0x4012bd0c 0x4012d3bc 0x4012eb09 0x4012f02f 0x4012b516 0x4011f40b 0x4011f4a9 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 components/mongoose/mongoose/mongoose.c:1701 main/ovms_netmanager.cpp:1203 main/ovms_netmanager.cpp:1203 ice 1471 % ./backtrace.sh 0x400f5950 0x4023fc12 0x40122463 0x401223fa 0x40114f35 0x401150f6 0x401151d0 0x4011524d + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400f5950 0x4023fc12 0x40122463 0x401223fa 0x40114f35 0x401150f6 0x401151d0 0x4011524d /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/lwip/src/core/timeouts.c:381 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/lwip/lwip/src/apps/sntp/sntp.c:693 main/ovms_time.cpp:104 main/ovms_time.cpp:104 /usr/local/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271 main/ovms_events.cpp:310 (discriminator 2) main/ovms_events.cpp:262 main/ovms_events.cpp:89
participants (5)
-
Charles B Cangialose -
Chris van der Meijden -
Craig Leres -
Mark Webb-Johnson -
Michael Balzer