- OvmsDev - Open Vehicles

Temperature precision needlessly high
by Lance Tjessem 10 Feb '21

10 Feb '21

I just updated to the latest edge build, and I see that the cabin temp metric is now needlessly precise. Examples of v/e/cabintemp I've seen today are -5.55556 and -1.66667 This is on a NL, not sure if it affects other cars as well.

4 5

Running Android app on Linux desktop
by Chris van der Meijden 08 Feb '21

08 Feb '21

I just got the Android app running on the Linux desktop :-) On Debian Stretch I used an old emulator from 2016: Shashlik 0.9.3http: //www.shashlik.io/news/2016/03/02/shashlik-0-9-3/ Advantage - super simpleDisadvantage - buggy and not maintained any more But it is running well for me. Even with the correct locale: What I did ... Install ShashlikInstall OVMS apk in Shashlikhttps://www.howtoforge.com/ tutorial/how-to-install-and-run-android-apk-on-linux-with-shashlik/ Create folder ~/.local/share/shashlik/system Edit /opt/shashlik/android/config.ini hw.ramSize=8000 /opt/shashlik/bin/shashlik-run emulator_args change "-noskin" to "-skin", "480x800", Create an executable script /usr/local/bin/ovms containing: #!/bin/bashcd /opt/shashlik/bin/./shashlik-run com.openvehicles.OVMS com.openvehicles.OVMS.apk Start it with the command "ovms" on the console. Set locale in a second console: adb shell "setprop persist.sys.language de; setprop persist.sys.country DE;" After restart of the emulator locale is set. On a black screen with only arrows (yes, it is buggy): adb shell rm -rf "/data/system/*" and restart the emulator. Have fun ... Regards Chris

1 0

BMS voltage series validity check
by Michael Balzer 03 Feb '21

03 Feb '21

Everyone, TL;DR: I've extended the BMS cell voltage processing to check for inconsistent / broken series and skip the deviation analysis and alerts on such. After implementing the BMS cell sensor queries for the e-Up / Mii / Go, we got lots of cell alerts even on brand new batteries. These were caused by a combination of a) our need to query each sensor value separately via OBD request, i.e. 84 (or 102 in case of the former model) OBD requests to retrieve the voltages, and b) the vehicle BMS probably not caring about taking a synchronized snapshot and holding that before beginning to overwrite the data with the next measurements. Or maybe it's actually got some snapshot/hold feature we just don't know how to use yet. Either way, we're seeing the effect of sudden load changes on the cell voltages clearly within a series run, even though all 84/102 requests are done within a few milliseconds. Example: This is the effect of a low load being present when cells 1-27 were queried, and an increased load being present afterwards. The cell deviation analysis would see a high deviation here e.g. on cells 15-17 and 75-77 and trigger an alert. The green line shows the linear regression gradient. In case of a series like this, or vice versa (high → low load during query run), the regression gradient is a clear sign of an inconsistent series. We also see series like this: In this case, the regression doesn't help. To cover these as well, I've added a test for a sudden offset in the stddev level from the previously observed average. Note: the average is built as a running average with smoothing over 5 samples. The first 5 series taken after a reboot will not be checked for deviations to get an initial average. For both gradient and stddev deviation, thresholds can be defined. Defaults can be given by the vehicle (added to the BmsSetCellDefaultThresholdsVoltage() API call), and users may overwrite these as needed (these may need some more explanation though). The system defaults I've chosen from my tests are: * Max gradient: 10 mV (= voltage drop/rise over the full series) * Max stddev deviation: 10 mV These may be wrong for batteries with drastically different sensor (pack) layouts. I've also reinterpreted the warning & alert thresholds as "exceeding the stddev level" (used to be absolute deviations from the average voltage level). The max. stddev deviation must not be chosen too low, or chances are we won't catch faulty cells anymore. If a faulty cell causes a high change in the standard deviation, it may cause the series to be considered invalid now. I assume a faulty cell will not fail completely within a measurement cycle, but degrade slowly over time. In that case, it should still be detected. I've done some tests with artificial faults and seen some warnings getting triggered from actual data, so I think the defaults should work. The gradient is published to a new metric (v.b.p.voltage.grad), which is also shown now in the battery monitor. I've also added a configuration to enable logging the cell voltages on demand, so you can load your actual data series into a spreadsheet from a log excerpt. To enable logging, set config vehicle bms.log.voltage.interval to e.g. 1 to check for new data every second – it will only log the series when changed. The logging feature is also available for temperatures, but temperatures are slow movers. Please test and report any issues. If you see issues, please send me your voltage logs for analysis. If you haven't had false alerts yet, chances are your BMS has a synchronized snapshot of the cell voltages. In that case, you can set the gradient and stddev deviation thresholds to some high values to effectively disable the validity check. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 2

Re: [Ovmsdev] Update WolfSSH/SSL
by Stephen Casner 31 Jan '21

31 Jan '21

Any objections to merging my update-wolfssh branch into master? -- Steve ---------- Forwarded message ---------- Date: Wed, 27 Jan 2021 18:03:42 -0800 (PST) From: Stephen Casner <casner(a)acm.org> Reply-To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> Subject: Re: [Ovmsdev] Update WolfSSH/SSL On Sun, 24 Jan 2021, Michael Balzer wrote: > The higher base memory footprint due to the higher NetMan stack size + some > additional buffer it seems (some 512 bytes?) means this needs to be checked > with complex vehicle modules in live operation before merging, but I think > that won't be an issue. As suggested to me by WolfSSL support, there is a configuration parameter for wolfssl to use heap allocation rather than stack for some buffers and structures. With that change, I can restore the NetMan stack to 8K. Now the comparison of memory usage is as follows: - With the current master code the max NetMan stack depth on my OVMS was 5616 whereas after the update it is 5760. - With the current master code, the amount of memory added by NetMan when an ssh connection was established was 2557 D/IRAM and 6108 SPIRAM for 8665 total. With the update it was 1056 D/IRAM and 7532 SPIRAM for 8588 total. I think this change should clear the way for merging into master. -- Steve _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

1 0

Implementing advanced charge control
by Stephen Casner 29 Jan '21

29 Jan '21

I've been working intermittently over the past two years on functionality to replace the ACC (advanced charge control) feature of OVMS v2. As an example, ACC could be configured to begin a cooldown charge cycle upon plug-in at home. In OVMS v3 the geofencing aspect of the ACC feature was implemented in the "location" command to be usable more generally. Based on design discussions with Mark about how the charge control operations and other functions should be attached to geolocations I have extended the location command to allow a list of actions to be attached to a defined location upon entering or leaving. The initial set of actions is: - acc -- initiate a charging profile (only upon entering) - homelink -- transmit homelink code - notify -- send a notification text to the app While this activity has been in progress the OVMS scripting features have been enhanced significantly. It is possible to do much of what I describe using scripts that are triggered upon entering or leaving a location. However, creating and installing scripts requires some developer skills that are likely beyond the comfort zone of many OVMS users, so I think it is still worthwhile to implement these location actions. At this point the homelink and notify actions are already implemented for activation upon entering or leaving a location. Assignment of acc actions to locations is also implemented, but those actions have no effect at this point. This message describes what I propose for acc. ACC is based on named charging profiles that specify a charge type (on-demand, charge at time, charge by time, etc) and associated parameters controlling the charge. Mark suggested that at home he might want to do a: Type: Charge By Cooldown on plugin Charge limit: 90% SOC Charge mode: Standard Charge current: 32A Complete charge by 7am Another example: Type: Charge At Cooldown: no Charge limit: 200km Charge mode: Standard Charge current: 32A Start charge at 11pm Charge profiles could also be activated manually or by a script. For example, you might arrive at a restaurant and type "charge acc ontheroad" to select the profile ontheroad without having to set all the individual parameters. The "charge" command currently includes subcommands to set the current and mode but would need to be extended to control times and limits. The front-end changes would be to extended the command tree as follows: acc list <name> acc set <name> at <time> acc set <name> by <time> acc set <name> on-plugin acc set <name> soc <percent> acc set <name> range <distance> acc rm <name> acc rm <name> at <time> acc rm <name> by <time> acc rm <name> on-plugin acc rm <name> soc <percent> acc rm <name> range <distance> charge acc <name> charge at <time> charge by <time> charge on-plugin charge soc <percent> charge range <distance> The choices at, by and on-plugin are mutually exclusive, so the last one is effective. The soc and range limits will stop the charge when reached and if set together with a "by <time>" would cause charging to continue after the specified time if the limit has not been reached. Charge profiles would be stored in the config in a manner similar to the way locations are stored with the name as the instance and the list of charge parameters in the value. I have not worked out all the backend details yet, so this is where those of you who are more familiar with the vehicle code can provide some guidance. Mark's suggestion was to extend the general vehicle framework to support the core ACC functionality; some parts might be handled completely at the generic layer, while other parts would require vehicle-specific implementation. The goal is to bring a set of advanced charge control functionality to all vehicle types (even if the vehicle has limited support). So long as the vehicle can start / stop charging, we can provide things like timed charges (at or by) in OVMS firmware. So at a minimum the functionality we require is the vehicle ability to start a charge, stop a charge, and provide signaling when the pilot signal is detected. We also need to be able to monitor the SOC and range as they increase during charging, but I think those values are already implemented well enough in the metrics. Some cars might not be able to support the minimum functions, so we may need some sort of capabilities back from the vehicle module to know whether the acc functions can be implemented Something like 'HasChargeStop', 'HasChargeStart', 'HasTimer', etc. Since many cars will normally start charging as soon as the charge cable is plugged in, OVMS needs to see the pilot-signal-present notification and stop the car from charging until the ACC conditions dictate. This is the case for the Tesla Roadster unless the car is at a location where a scheduled charge time has been configured. But having a scheduled charge configured is not good because that may interfere with what OVMS is trying to control. The "charge by" operation requires using the charge time predictor to figure the start time, then is becomes the same as "charge at". I have some concern that the existing CTP may not be accurate for Roadsters with the 3.0 battery. I don't know whether the other vehicles have an accurate CTP. The "charge on-plugin" operation has an associated event, but all the other operations require use of a ticker to see if the start time has come or the stopping condition has been reached. Comments appreciated. -- Steve

3 7

Update WolfSSH/SSL
by Stephen Casner 28 Jan '21

28 Jan '21

After a pause of three years, I have finally gotten around to updating wolfssh and wolfssl to the current stable releases, 1.4.5 and 4.6.0 respectively. This includes the code to support SCP that I wrote and contributed back to them and was integrated into wolfssh 1.3.0. There were some API tweaks that I needed to work through, but the source files are now unmodified except for wolfcrypt/settings.h where I ran into a compilation conflict on the XREALLOC macro. As before, I need to supply my own malloc, free and realloc functions so we can control PSRAM usage and so we can emit a log message if memory allocation fails. For starters, this update removes the restriction to use cipher aes128-cbc. In addition, the WolfSSL code now includes integration with the hardware crypto acceleration capabilities of the ESP32. I'm not sure how much that will affect performance as we see it because I think the biggest performance factor is how we need to use the APIs given our task structure. The public key handshake for initial connection may be faster. I added the new code on a branch named update-wolfssh by copying in the source files as I did when creating the wolfssh and wolfssl components initially. I'm running the new code on OVMS in my car and have given it basic testing by connecting with the ssh client and transferring files with scp. I invite anyone else who is interested to test as well or to comment if there are any concerns about merging to the master branch. There are some memory considerations. I've added the complete wolfssl source tree even though we only use the wolfcrypt subset of wolfssl. The update added a bunch of files and increased the required disk space from 18M to 43M. Similarly, wolfssh added code for scp, sftp, ssh agent server code and also ssh clients that we are not using; that increased disk space from 2.0M to 2.6M. I added our scp code before they implemented theirs and I have not examined their scp and sftp code to see if there would be any advantage in trying to adapt it to fit our non-blocking architecture. I had to increase the size of the NetMan stack from 8K to 10K to avoid stack overflow. With current master code the max used on my OVMS was 5616 whereas after the update it is 9700. With the current master code, the amount of memory added by NetMan when an ssh connection was established was 2557 D/IRAM and 6108 SPIRAM for 8665 total. With the update it was 1240 D/IRAM and 8768 SPIRAM for 10008 total. -- Steve

3 4

Proposed new config option
by Stephen Casner 27 Jan '21

27 Jan '21

When I'm working with my bench OVMS unit attached with USB and frequently rebooting, I don't want to have to log in each time. To avoid this I have patched console_async.cpp to SetSecure(true) in the constructor. But I have to be careful to omit that patched file when committing my changes. I proposed to add a Kconfig developer option to control whether that SetSecure(true) statement is included. Then I can commit this functionality into the code base where it will normally be excluded but can be included for a developer build configuration. This is similar to OVMS_DEV_CONFIGVFS option that allows read access to the ovms_config file. My proposed change is attached. Any objections? -- Steve

3 3

Fwd: How does TPMS work now?
by Michael Balzer 27 Jan '21

27 Jan '21

It seems the list server still has issues: -------- Weitergeleitete Nachricht -------- Betreff: Re: [Ovmsdev] How does TPMS work now? Datum: Mon, 18 Jan 2021 07:54:31 +0100 Von: Michael Balzer <dexter(a)expeedo.de> An: ovmsdev(a)lists.openvehicles.com Craig, vector metrics can (as all metrics btw) be set by their string representation, i.e. metrics set v.t.pressure 210.29,210.29,210.29,210.29 …and all TPMS metrics (also the new ones) are persistent now, see my post "extended metrics persistence". Regarding the sensor sets, I haven't used them yet, and documentation is lacking, so you need to check the source. Regards, Michael Am 18.01.21 um 04:11 schrieb Craig Leres: > It used to be possible to manually set tire pressure with: > > metrics set v.tp.fl.p 210.29 > metrics set v.tp.fr.p 210.29 > metrics set v.tp.rl.p 210.29 > metrics set v.tp.rr.p 210.29 > > but after upgrading to the latest persistent metrics code I see these > are all gone. > > I looked at the tpms command but it seems to be designed to track > different sets of tpms sensor id numbers. > > Is it possible to set these from the command line? Are tpms tire > pressures (and temperatures) still persistent across warm reboots? Is > my problem that these are stored in vectors now and there is not yet a > way to manipulate them from the command line? > > Craig > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)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 -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 5

Scan and discover process for 29bits PID
by didier＠ernotte.com 26 Jan '21

26 Jan '21

Hi, Thanks to all the help you provide me here, I was able to identify most of the 11bits ECU with broadcast request and SavvyCAN, and relative PID with the PID scanner.I am a bit confused how I can scan ECU/PID with the extended mode (29 bits). How can I do the same kind of investigation and scanning with the extended mode ? Didier

2 1

General trip & grid log proposal
by Michael Balzer 25 Jan '21

25 Jan '21

Everyone, followup to my previous mail, these are the record structures for the general trip & grid logs I would like to add. I'm going to implement this with configurable server hold times, with 0 = no server storage at all. As this has more potential for data privacy impact as the standard 24 hour storage of telemetry records, I wouldn't enable the logs by default, but leave this decision to the user. Please check & provide feedback. Regards, Michael ==================================================================================================== History type "*-LOG-Trip" Notification type "data", subtype "log.trip" OvmsMetricBool* ms_v_pos_gpslock; OvmsMetricFloat* ms_v_pos_latitude; OvmsMetricFloat* ms_v_pos_longitude; OvmsMetricFloat* ms_v_pos_altitude; OvmsMetricString* ms_v_pos_location; // Name of current location if defined OvmsMetricFloat* ms_v_pos_odometer; OvmsMetricFloat* ms_v_pos_trip; // Trip distance OvmsMetricInt* ms_v_env_drivetime; // Trip duration OvmsMetricInt* ms_v_env_drivemode; // Active drive profile number [1] OvmsMetricFloat* ms_v_bat_soc; // State of charge [%] OvmsMetricFloat* ms_v_bat_range_est; // Estimated range [km] OvmsMetricFloat* ms_v_bat_range_ideal; // Ideal range [km] OvmsMetricFloat* ms_v_bat_range_full; // Ideal range at 100% SOC & current conditions [km] OvmsMetricFloat* ms_v_bat_energy_used; // Main battery energy used on trip [kWh] OvmsMetricFloat* ms_v_bat_energy_recd; // Main battery energy recovered on trip [kWh] OvmsMetricFloat* ms_v_bat_coulomb_used; OvmsMetricFloat* ms_v_bat_coulomb_recd; OvmsMetricFloat* ms_v_bat_soh; // State of health [%] OvmsMetricString* ms_v_bat_health; // General textual description of battery health OvmsMetricFloat* ms_v_bat_cac; // Calculated capacity [Ah] OvmsMetricFloat* ms_v_bat_energy_used_total; // Battery energy used total (life time) [kWh] OvmsMetricFloat* ms_v_bat_energy_recd_total; // Battery energy recovered total (life time) [kWh] OvmsMetricFloat* ms_v_bat_coulomb_used_total; // Battery coulomb used total (life time) [Ah] OvmsMetricFloat* ms_v_bat_coulomb_recd_total; // Battery coulomb recovered total (life time) [Ah] OvmsMetricFloat* ms_v_env_temp; // Ambient temperature [°C] OvmsMetricFloat* ms_v_env_cabintemp; // Cabin temperature [°C] OvmsMetricFloat* ms_v_bat_temp; // Battery temperature [°C] OvmsMetricFloat* ms_v_inv_temp; // Inverter temperature [°C] OvmsMetricFloat* ms_v_mot_temp; // Motor temperature [°C] OvmsMetricFloat* ms_v_charge_12v_temp; // Temperature of DC/DC-converter [°C] OvmsMetricFloat* MAX(ms_v_tpms_temp); // Maximum tyre temperature OvmsMetricFloat* MIN(ms_v_tpms_pressure); // Minimum tyre pressure OvmsMetricFloat* MIN(ms_v_tpms_health); // Minimum tyre health ==================================================================================================== History type "*-LOG-Grid" Notification type "data", subtype "log.grid" OvmsMetricBool* ms_v_pos_gpslock; OvmsMetricFloat* ms_v_pos_latitude; OvmsMetricFloat* ms_v_pos_longitude; OvmsMetricFloat* ms_v_pos_altitude; OvmsMetricString* ms_v_pos_location; // Name of current location if defined OvmsMetricFloat* ms_v_pos_odometer; OvmsMetricString* ms_v_charge_type; // Grid connection type OvmsMetricString* ms_v_charge_state; // charging, topoff, done, prepare, … OvmsMetricString* ms_v_charge_substate; // scheduledstop, scheduledstart, … OvmsMetricString* ms_v_charge_mode; // standard, range, performance, storage OvmsMetricFloat* ms_v_charge_climit; // Maximum charger output current [A] OvmsMetricFloat* ms_v_charge_limit_range; // Sufficient range limit for current charge [km] OvmsMetricFloat* ms_v_charge_limit_soc; // Sufficient SOC limit for current charge [%] OvmsMetricString* ms_v_gen_type; // Grid connection type OvmsMetricString* ms_v_gen_state; // TBD OvmsMetricString* ms_v_gen_substate; // TBD OvmsMetricString* ms_v_gen_mode; // TBD OvmsMetricFloat* ms_v_gen_climit; // Maximum battery output current [A] OvmsMetricFloat* ms_v_gen_limit_range; // Min range [km] OvmsMetricFloat* ms_v_gen_limit_soc; // Min SOC [%] OvmsMetricInt* ms_v_charge_time; // Duration of running charge session [sec] OvmsMetricFloat* ms_v_charge_kwh; // Energy charged into battery for running session [kWh] OvmsMetricFloat* ms_v_charge_kwh_grid; // Energy drawn from grid during running session [kWh] OvmsMetricFloat* ms_v_charge_kwh_grid_total; // Energy drawn from grid total (life time) [kWh] OvmsMetricInt* ms_v_gen_time; // Duration of running generator session [sec] OvmsMetricFloat* ms_v_gen_kwh; // Energy taken from battery for running session [kWh] OvmsMetricFloat* ms_v_gen_kwh_grid; // Energy sent to grid during running session [kWh] OvmsMetricFloat* ms_v_gen_kwh_grid_total; // Energy sent to grid total (life time) [kWh] OvmsMetricFloat* ms_v_bat_soc; // State of charge [%] OvmsMetricFloat* ms_v_bat_range_est; // Estimated range [km] OvmsMetricFloat* ms_v_bat_range_ideal; // Ideal range [km] OvmsMetricFloat* ms_v_bat_range_full; // Ideal range at 100% SOC & current conditions [km] OvmsMetricFloat* ms_v_bat_voltage; // Main battery momentary voltage [V] OvmsMetricFloat* ms_v_bat_temp; // Battery temperature [°C] OvmsMetricFloat* ms_v_charge_temp; // Charger temperature [°C] OvmsMetricFloat* ms_v_charge_12v_temp; // Temperature of DC/DC-converter [°C] OvmsMetricFloat* ms_v_env_temp; // Ambient temperature [°C] OvmsMetricFloat* ms_v_env_cabintemp; // Cabin temperature [°C] OvmsMetricFloat* ms_v_bat_soh; // State of health [%] OvmsMetricString* ms_v_bat_health; // General textual description of battery health OvmsMetricFloat* ms_v_bat_cac; // Calculated capacity [Ah] OvmsMetricFloat* ms_v_bat_energy_used_total; // Battery energy used total (life time) [kWh] OvmsMetricFloat* ms_v_bat_energy_recd_total; // Battery energy recovered total (life time) [kWh] OvmsMetricFloat* ms_v_bat_coulomb_used_total; // Battery coulomb used total (life time) [Ah] OvmsMetricFloat* ms_v_bat_coulomb_recd_total; // Battery coulomb recovered total (life time) [Ah] -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 11