- OvmsDev - Open Vehicles

Adding Pollers object to Duktape
by Michael Geddes 08 Jul '24

08 Jul '24

I figured I may as well add an OvmsPoller object to DukTape for Ovms. I'm waiting to get back to my OVMS so that I can test it.. but this is the documentation I have for the stuff I have coded. Thoughts on this? What do people think of OvmsPoller.Times sub-object? I've added a general mechanism for this. Also should I have OvmsPoller.Pause() or OvmsPoller.SetUserPaused(true) ? //. OvmsPoller ^^^^^^^^^^ The Ovms Poller object represents the poller sub-system. It contains the following methods: - ``ispaused = OvmsPoller.GetPaused()``: Return true if the poller is paused by the system/user. - ``ispaused = OvmsPoller.GetUserPaused()``: Return true if the poller is paused by the user. - ``OvmsPoller.Pause()``: Pause the poller (adds User poller pause) - ``OvmsPoller.Resume()``: Remove the User poller pause. - ``tracemode = OvmsPoller.GetTrace()``: Return the current trace mode. - ``OvmsPoller.SetTrace(tracemode)``: Set the current trace mode. The Traces still require that 'Verbose' and 'Debug' levels (depending) for the 'vehicle-poll' debug tag are set. Trace modes for verbose logging can be one of: - ``on``: On for poller loop - ``txrx``: On for txrx queue (this can be hazardous for some cars) - ``all``: On for both poller loop and txrx queuing - ``off``: Logging Off Note that only ``on`` and ``off`` are recommended. The poller object also contains a ``Times`` property for the OBD Poll-Time tracing which contains the following methods: - ``isrunning = OvmsPoller.Times.GetEnabled()``: Returns true if the time-tracing is enabled - ``OvmsPoller.Times.SetEnabled(isrunning)``: Sets the enabled status of the timer-tracing - ``OvmsPoller.Times.Reset()``: Reset the timers (doesn't affect their current state). - ``OvmsPoller.Times.GetStatus()``: Gets the status of the various times. This returns an object of this format: .. code-block:: javascript return_value = { "items": { "Poll:PRI" : { "count_hz": 1, "avg_util_pm": 0.529, "peak_util_pm":0.652, "avg_time_ms": 0.052, "peak_time_ms":1.516 }, "Poll:SRX": { "count_hz": 1.47, "avg_util_pm": 0.302, "peak_util_pm":0.44, "avg_time_ms": 0.02, "peak_time_ms":0.573 }, "RxCan1[778]": { "count_hz": 0.74, "avg_util_pm": 0.427, "peak_util_pm":0.826, "avg_time_ms": 0.063, "peak_time_ms":1.872 }, "RxCan1[7a8]": { "count_hz": 0.35, "avg_util_pm": 0.183, "peak_util_pm":0.355, "avg_time_ms": 0.052, "peak_time_ms":1.382 }, "TxCan1[7b3]": { "count_hz": 0.07, "avg_util_pm": 0.005, "peak_util_pm":0.01, "avg_time_ms": 0.007, "peak_time_ms":0.099 }, "TxCan1[7c6]": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0.009, "avg_time_ms": 0.004, "peak_time_ms":0.098 }, "Cmd:State": { "count_hz": 0, "avg_util_pm": 0, "peak_util_pm":0, "avg_time_ms": 0.011, "peak_time_ms":0.109 } }, "tot_count_hz": 11.76, "tot_util_pm": 6.247, "tot_time_ms": 4.628 };

2 7

Firmware release 3.3.004
by Michael Balzer 29 Jun '24

29 Jun '24

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#ovmsvehicl… - 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

5 15

Integer division approximation
by Michael Geddes 12 Jun '24

12 Jun '24

I'm really not sure if this would make enough difference to be useful - but it's kinda neat. It's basically a template class that turns y = m * x / d into y = (c * x) >> n eg: fast_int_muldiv<int, 10, 3>::op( x ) it is an approximation only, and the larger PREC value you give, the more precise it is, and the larger integer it would need. So a decent precision would probably need a 64 bit integer. I would need to do experiments on the ESP32 to really get an idea. One thing it does do is turn a multiply and divide (like for imperial units) into 2 operations. //. constexpr unsigned floorlog2(unsigned x) { return x == 1 ? 0 : 1+floorlog2(x >> 1); } constexpr unsigned ceillog2(unsigned x) { return x == 1 ? 0 : floorlog2(x - 1) + 1; } /* Use a multiple and shift (right) to approximate a multiply and divide. * T - the intermediate type used. * M - The multiplier (1 is fine) * D - The divisor * PREC - The precision required for the operation. */ template<typename T, unsigned M, unsigned D, unsigned PREC=100> class fast_int_muldiv { public: static const uint8_t shift = ceillog2(D * PREC); // Gives the approx multiplier that fits with the chosen shift value . static const T mult = M* (((T(0x1) << shift)+(D>>1)) / D); // Perform the operation approx (val * M / D) static T op(T val) { // Make sure there is enough space (16bits) for a value. static_assert( (8 * sizeof(T)) >= (16 + shift + floorlog2(mult)), "Use a larger integer or smaller precision"); return ((val * mult) >> shift); } };

3 2

Improve shutdown of poller
by frog＠bunyip.wheelycreek.net 26 May '24

26 May '24

I've had some hang-ups on shutdown and have been through a few iterations on working out what is happening. I then realised there was the whole MyBoot.ShutdownPending thing which would be the proper way to do waiting for shut-down. I'm mostly read to submit for that. but one small thing was that I have been conditionally creating the poller thread and queue and that has potential race-condition problems. I can definitely solve that using the poller crit section and some atomic operations. However, I'm thinking that maybe I should create the poller Task and poller queue unconditionally in the constructor? Any objections? It would certainly remove the whole race condition. I had the best intentions of making it conditional.. but now the act of creating any Vehicle class starts the poller, it seems a bit pointless. //.ichael

1 0

Critical P/R - Sorry. Multiframe ISOTP responses only receiving 1st frame
by Michael Geddes 12 May '24

12 May '24

For any developer building from the current release - you will also need: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1013 Or multi-frame ISOTP & VWTP packets will be broken. //.ichael

1 1

OVMS Poller module/singleton
by Michael Geddes 28 Apr '24

28 Apr '24

Hey all, The poller singleton code that I've been working on for over a year now is merged in. (Thanks Michael for expediting the final step). This includes separate multi-frame states per bus and multiple poll lists as well as non-blocking one off queries. As well as more 'states'. I have included some programming documentation in the change but am happy to supply more if needed. The ioniq 5 code has some examples of how it can be used. Some examples are: * grabbing the vin as a one shot without blocking * having a short list of queries that are polled quickly for obd2ecu (this also demonstrates using a shorter frame break value and then a break after successful a response) Have a play please! Also interested in hearing what user tools might be worth looking at next for the poller object. //.ichael G.

3 8

OBD poller module shell proposal
by Michael Geddes 27 Apr '24

27 Apr '24

Hi all, I know some of this (especially for the status) functionality is predicated on code that's not gone up yet - however this is allowing 'pause' and 'resume' of the poller (which has been merged). My question is not so much about the functionality and status information, but about the location of the *poller* subcommand. (See below). Should 'vehicle' be exclusively for switching the vehicle type? Should the 'poller' command be top-level? Under obdii? Thoughts welcome. If you do vehicle poller pause then the last line reads 'Vehicle OBD Polling is paused' //. -------8<---------------------------------------- *OVMS# vehicle ?* Usage: vehicle [list|module|poller|status] list Show list of available vehicle modules module Set (or clear) vehicle module poller OBD polling status status Show vehicle module status *OVMS# vehicle poller ?* Usage: vehicle poller [pause|resume] pause Pause OBD Polling resume Resume OBD Polling *OVMS# vehicle poller* OBD Polling running on bus 1 with an active list Time between polling ticks is 1000ms with 1 secondary sub-ticks Last poll command received 1s (ticks) ago. Vehicle OBD Polling is running.

4 18

Upgrading Mongoose ?
by Michael Geddes 26 Apr '24

26 Apr '24

I've been looking at the work of Ludovic in updating OVMS to the new framework. I've even put up a few pull-requests where this work has uncovered bugs due to improvements in the compiler. Ludovic did a great job in also updating the Mongoose library. For those unaware, the big issue is that there was a massive reworking of the library just after the point where ovms forked the library. I suspect some/many? of the changes that were made in our fork are no longer required. There was a lot done in moving some of the work that had to be done in the callers (ovms) code into the mongoose code which is great - and Ludovic has done that conversion - there are just a few more things that needed to be done on top of that. One of the things they did was remove mg_locals.h which allowed us to configure mongoose from our own custom include. The other really annoying thing they did was to remove the use of MG_ALLOC, MG_CALLOC in place of malloc( calloc( etc. The problem with this is for freertos they define #define calloc(a, b) mg_calloc(a, b) #define free(a) vPortFree(a) #define malloc(a) pvPortMalloc(a) without any further condition. Tihs means we don't have a way of defining these to our own versions which is what we originally did... well not without forking the mongoose (which maybe we do anyway). It also means that any of our files that include mongoose.h will have these redefined away from our own versions of these. Fortunately it seems we don't use those much. I also noticed that even the latest Mongoose MQTT doesn't appear to support aliases (and therefore optimising the amount of data used by a v3 server).. but it appears that wolfmqtt does - so should we be using that instead as a mqtt client?? Does anybody else have some further input on this?? //.

2 2

Munging the sender
by Mark Webb-Johnson 15 Apr '24

15 Apr '24

Just an FYI: to try to workaround problems with DMARC and recent anti-spam policies deployed by Google and others, we have enabled the option on this mailing list to ‘munge’ the sender. Messages sent to this list will now appear to come from “<Your name> via OvmsDev” and from the list address, not your own personal eMail. Hopefully this will improve the deliverability (especially from those sending from domains with DMARC policies). Regards, Mark.

1 0

EV6/IONIQ5
by N A 15 Apr '24

15 Apr '24

I'm completely new to OVMS but very interested in learning how to contribute. I have an EV6 and would love to be able to use it with this system. I looked through the listserv archives and have noticed a few requests and discussions about the Kia EV6 but no indication that it's being worked on. If not, I'd like to see if I can help. I know that there are folks working on the IONIQ5, which is very similar to the EV6, so, my first question -- has anyone tried to use the IONIQ configuration on an EV6? If they do share a platform, which could be the case, it would seem possible that it is already supported, just not officially -- or am I mistaken? If so, I'm happy to order an OVMS box and test things out. If not, I'd like to see what else I could do to get the EV6 supported and/or perhaps collaborate with others.

4 3