February 2021 - OvmsDev - Open Vehicles

Using the BMW Connecteddrive API from OVMS
by Steve Davies 19 Feb '21

19 Feb '21

Hi, One way to "command" the BMW/Mini cars is with the BMW ConnectedDrive app. This talks to REST APIs on BMW servers around the place. This API has been sniffed by others and seems simple to use. The actual delivery of the command to the car is deathly slow - at least here in South Africa. I think it actually sends the car an SMS to kick things off. And it doesn't always work. Still, it does allow things like unlock / lock / climatise and what have you. I expect I can come up with some sort of "noop" operation that boils down to "wake up the car" which would be helpful to get fresh state from the car from time to time. Would you be OK with taking a PR for the bmwi3 vehicle module that uses this? Are there any available frameworks for calling HTTP/JSON/REST APIs from the C++ code? Thanks, Steve -- https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>

3 6

Re: [Ovmsdev] GPS theft alert (fwd)
by Stephen Casner 13 Feb '21

13 Feb '21

Delivery of the message below to ovmsdev(a)lists.openvehicles.com failed: "554 command rejected for policy reasons". Is that because of a .pl attachment? Fortunately I addressed it directly to Craig as well. -- Steve ---------- Forwarded message ---------- Date: Fri, 12 Feb 2021 12:30:13 -0800 (PST) From: Stephen Casner <casner(a)acm.org> To: Craig Leres <leres(a)xse.com> Cc: OVMS Developers <ovmsdev(a)lists.openvehicles.com> Subject: Re: [Ovmsdev] GPS theft alert On Fri, 12 Feb 2021, Craig Leres wrote: > I also got a theft alert last night. Considering that I had never seen this > alert until a few weeks ago it feels like something has changed. This includes > the vehicle_cadillac_c2_cts which until a few days ago was not updating > StandardMetrics.ms_v_env_on->SetValue() (which I believe maps to v.e.on?) And > looking at OvmsLocations::CheckTheft() it's not even clear to me that a > vehicle module that never sets ms_v_env_on can even trigger an alert?!?! > > void OvmsLocations::CheckTheft() > { > if ((m_park_latitude == 0) && (m_park_longitude == 0)) return; > if (StandardMetrics.ms_v_env_on->AsBool()) return; > [...] Right. That was why I asked you if v.e.on was set in your cars. > I browsed changes to ovms_location.cpp over the last months and if anything I > would think it was less likely to get a theft alert. That has been the intent. > It's difficult for me to see how upgrading my esp32 hardware could be causing > this especially since the gps hardware is in the simcom. Agreed. > On 2/12/21 1:35 AM, Michael Balzer wrote: > > Please check your "L" log at the time of the alert: what did your GPS > > data look like just before the alert? > > Do I need to turn on logging to the sdcard to see this? As far as I know I'm > not doing any logging right now. No, this is referring to the records stored on the v2 server. They are only kept for a limited time (48 hours?). I have attached a perl script given to me by Tom Saxton to fetch those records. I have it run daily on my laptop. Note that you need to put your credentials in variables near the top, and you'll probably have to adjust some paths and libraries for your system. -- Steve

1 0

Changed log file timestamps
by Stephen Casner 11 Feb '21

11 Feb '21

While investigating the delay in ssh connection establishment I observed that the wallclock timestamps added to the log file don't match the deltas in the kernel-supplied uptime timestamps: 2021-02-10 09:55:35 PST I (305470) wolfssh: Entering wolfSSH_accept() 2021-02-10 09:55:35 PST I (305480) wolfssh: Entering DoKexInit() 2021-02-10 09:55:35 PST I (305480) wolfssh: Leaving DoKexInit(), ret = 0 2021-02-10 09:55:35 PST I (305490) wolfssh: Entering wolfSSH_accept() 2021-02-10 09:55:35 PST I (305490) wolfssh: Entering SendKexDhReply() 2021-02-10 09:55:35 PST I (310800) wolfssh: Signing hash with RSA. 2021-02-10 09:55:35 PST I (312640) wolfssh: Entering SendNewKeys() 2021-02-10 09:55:35 PST I (312640) wolfssh: Entering wolfSSH_SendPacket() 2021-02-10 09:55:35 PST I (312640) wolfssh: Leaving SendNewKeys(), ret = 0 2021-02-10 09:55:35 PST I (312640) wolfssh: Leaving SendKexDhReply(), ret = 0 That's because the wallclock timestamps are obtained when the log is written, not when the message occurred and may have been queued. I have improved this by basing the timestamps on the kernel-supplied uptime timestamp added to a calculated system boot time. I also extended the wallclock timestamp with milliseconds: 2021-02-10 23:59:16.410 PST I (99560) wolfssh: Entering wolfSSH_accept() 2021-02-10 23:59:16.410 PST I (99560) wolfssh: Entering DoKexInit() 2021-02-10 23:59:16.410 PST I (99560) wolfssh: Leaving DoKexInit(), ret = 0 2021-02-10 23:59:16.420 PST I (99570) wolfssh: Entering wolfSSH_accept() 2021-02-10 23:59:16.420 PST I (99570) wolfssh: Entering SendKexDhReply() 2021-02-10 23:59:16.430 PST I (99580) wolfssl: wolfSSL Entering wc_ecc_make_key_ex2 2021-02-10 23:59:18.730 PST I (101880) wolfssl: wolfSSL Leaving wc_ecc_make_key_ex2, return 0 2021-02-10 23:59:18.730 PST I (101880) wolfssl: wolfSSL Entering wc_ecc_shared_secret 2021-02-10 23:59:21.070 PST I (104220) wolfssl: wolfSSL Leaving wc_ecc_shared_secret, return 0 2021-02-10 23:59:21.070 PST I (104220) wolfssh: Signing hash with RSA. 2021-02-10 23:59:21.070 PST I (104220) wolfssl: wolfSSL Entering RsaPublicEncryptEx 2021-02-10 23:59:22.980 PST I (106130) wolfssl: wolfSSL Leaving RsaPublicEncryptEx, return 256 2021-02-10 23:59:22.980 PST I (106130) wolfssh: Entering SendNewKeys() 2021-02-10 23:59:22.980 PST I (106130) wolfssh: Entering wolfSSH_SendPacket() 2021-02-10 23:59:22.980 PST I (106130) wolfssh: Leaving SendNewKeys(), ret = 0 2021-02-10 23:59:22.990 PST I (106140) wolfssh: Leaving SendKexDhReply(), ret = 0 If the extra milliseconds field is going to cause breakage in some scripts or something I can remove it. -- Steve

1 0

Android App release 3.18.1
by Michael Balzer 10 Feb '21

10 Feb '21

I've just released version 3.18.1 of the Android App on the Google Play Store. *Version 3.18.1 (2021-02-10)* * Show charge input power & loss if available * Support new TPMS 'Y' record, adding health & alert states * Add car_auxiliary_12v state data & broadcast * Fix UpMiiGo images * Fix service info You can also download the APK file from: https://github.com/openvehicles/Open-Vehicle-Android/tree/master/release Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

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