- OvmsDev - Open Vehicles

Addition to OVMS Developer Guide
by Stephen Casner 05 Jan '21

05 Jan '21

At Mark's request I have added a description of how to add commands to the console command interpreter including the usage string syntax. This should be considered a draft at this point; questions and comments are welcome. I added this under Vehicle Firmware Overview, but that might not be the right place. There is no general description of the core firmware. -- Steve

3 22

Investigating crashes. And, OVMS stopped collecting data
by Steve Davies 01 Jan '21

01 Jan '21

Hi, I went for a scenic drive partly to test my OVMS I3 stuff and feeding data to ABRP. When I got home I found that ABRP had my drive ending say 15km from home. And when I checked OVMS it also thought I was in the same spot. [6315S] v.p.altitude 65.4m [6315S] v.p.direction 97.5° [6315S] v.p.gpshdop 1 [9999S] v.p.gpslock yes [6315S] v.p.gpsmode AN [6315S] v.p.gpsspeed 18.7052km/h [6315S] v.p.latitude -34.0808 [-----] v.p.location [6315S] v.p.longitude 18.4327 [5282S] v.p.odometer 14901km [6315S] v.p.satcount 9 [5195S] v.p.speed 0km/h [5195S] v.p.trip 85km You can see that the metrics are very old (I show more digits in my version). I then looked further and no metrics seemed to be updating - for instance the m.time.utc wasn't updating. I was starting to look at it when my OVMS rebooted (which seems to happen sometimes. I've also had the logging stop - I noticed one less task so I presume that's related). Last boot was 127 second(s) ago Time at boot: 2020-12-31 19:10:09 SAST This is reset #8 since last power cycle Detected boot reason: Crash (12/12) Reset reason: Exception/panic (4) Crash counters: 1 total, 0 early Last crash: LoadProhibited exception on core 1 Registers: PC : 0x400f0161 PS : 0x00060a30 A0 : 0x800f023a A1 : 0x3ffe5920 A2 : 0x3ffb5738 A3 : 0x00000000 A4 : 0x3f8566a8 A5 : 0x00000001 A6 : 0x3ffe5990 A7 : 0x3f8567d0 A8 : 0x800f015c A9 : 0x3ffe5910 A10 : 0x00000000 A11 : 0x3f414cb1 A12 : 0x00000002 A13 : 0x00000001 A14 : 0x000000fe A15 : 0x3ffd4f90 SAR : 0x00000004 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000000 LBEG : 0x4008bcf1 LEND : 0x4008bd01 LCOUNT : 0xfffffffd Backtrace: 0x400f0161 0x400f0237 0x400fe87f 0x40103d4b 0x40103f02 0x400fe8af 0x4013a432 Version: 3.2.015-267-g39dba375-dirty/ota_1/main (build idf v3.3.4-845-gd59ed8bba-dirty Dec 26 2020 15:37:52) After this crash and restart m.time.utc was empty. I rebooted and its still missing - does it only appear once NTP syncs or something? Also I have no GPS position, gpsmode or anything like that (but I have a 3G session with the hologram sim and roaming on one of the local cellular operators). I've made sure the GPS puck is out in the open and I guess I'll wait - does the time come from the GPS? And any ideas why I'm not getting a GPS lock suddenly? Apart from that - how do I debug crashes? I went looking for some sort of loader memory map in the build directory to try turn the PC and backtrace addresses into something more useful but didn't pick up anything. Thanks Steve

3 6

Email: Flow and Topics
by jaunius＠gmx.com 01 Jan '21

01 Jan '21

Hi, I noticed the email subjects for troubleshooting and other stuff usually does not have any information to what part of the system they apply. Would suggest to have a naming convention like: [system part]: [topic]. For example: "NL: Charging State Incorrect" or "General: RAM Issues" and etc... It would be easier and more efficient to identify which email to act uppon. What do you guys think? New Year Greetings, Jaunius Sent using the GMX mail app

1 0

Curious message about GreyPeter/Open-Vehicle-Monitoring-System-3
by Stephen Casner 30 Dec '20

30 Dec '20

This morning I received the below automated email from GitGuardian, which is another thing I didn't know existed. The warning does not identify a real problem since the RSA Private Key in question is an example server key included as part of the WolfSSL package that I imported into our OVMS repository in 2017. However, the thing that's curious is that this is in reference to repository GreyPeter/Open-Vehicle-Monitoring-System-3 which does not appear as a fork of the openvehicles repository but rather some other kind of copy. If GreyPeter is listening here, was that intentional? -- Steve ---------- Forwarded message ---------- Date: Tue, 29 Dec 2020 05:57:23 +0000 From: GitGuardian <security(a)mail.gitguardian.com> To: casner(a)acm.org Subject: [GreyPeter/Open-Vehicle-Monitoring-System-3] RSA Private Key exposed on GitHub GitGuardian security alert GitGuardian has detected the following RSA Private Key exposed within your GitHub account. Details - Secret type: RSA Private Key - Repository: GreyPeter/Open-Vehicle-Monitoring-System-3 - Pushed date: 2020-12-29T05:51:58+0000 Protect your GitHub repos GitGuardian is an automated secrets detection service trusted by 150,000 developers worldwide. Unsubscribe from these alerts. [eJyVUk2P3CAM_TWTyyojvgmHHHalTg9V1VW36jUyYBLUfIlhRpp_X2dH6r0IkI0xfu-Z2DOluG9gz3_wMUx5 nGZaFeNwK3M_1bpfT_L1JC40x1ynmz-HbSHna8HHO1YsZP_YcW1_45TDjO33bc11K3kd24_HteLSSrpCSUuu hwECjQ3RgEwmRCud7mQnpI5SuRQ1dJEr59xJyJhTahFTsJYZsIx5B8iC9UZHSL4znhntlA8U5ZJxB96HJFxg 3nIZvGLKYJN7wQTjQjimtRXyzM-GfRHGvimrO3PR_HJSbIE8n4ngeIMSM6wHy4bA7zNUHFZYsP_n7WUZ7qLB O651iMdJ2soClVT7rNVy0Qr3i2lSTvNj607ijdFoYMZShxx7RBG9Zp2JILwLB3BOaDiyqDtOhLpE6IXVUYAP OnLHuETiq7kLEXxT-gDXleRXDMJy3srY1H4vWxzA37n6dPL9AHc0tlyhmXpBiaAAjbGOaimdkiYQ3EYVwDpo IjU0UPOGmK_E9fEk_vPj9eX9-djLN3w0BfftGfmfT_AXbLjFZw]

1 0

Decoding "OBD/UDS" errors
by Steve Davies 29 Dec '20

29 Dec '20

Hi, For some of my requests I get errors: steve@maximus ovms-logs % grep 'process.*error' log.20201228 | sed -e 's/^.*vehicle/vehicle/' | sort | uniq -c 1 vehicle: PollerReceive[607F1]: process OBD/UDS error 22(6335) code=21 4 vehicle: PollerReceive[607F1]: process OBD/UDS error 22(DD68) code=21 4 vehicle: PollerReceive[607F1]: process OBD/UDS error 22(DD69) code=21 285 vehicle: PollerReceive[614F1]: process OBD/UDS error 22(DEF7) code=12 304 vehicle: PollerReceive[614F1]: process OBD/UDS error 22(DEFA) code=31 39 vehicle: PollerReceive[61AF1]: process OBD/UDS error 22(DE8A) code=31 148 vehicle: PollerReceive[640F1]: process OBD/UDS error 22(D130) code=22 I found a list here: https://automotive.wiki/index.php/ISO_14229 If so: 0x21: Busy, try again 0x12: sub function not supported (problem with my PID?) 0x31: "request out of range". 0x22: "conditions not correct". Does that sound right? Thanks, Steve D

2 1

Android App V3.17.3
by Michael Balzer 29 Dec '20

29 Dec '20

…is now being processed by the Play Store. Release info: https://github.com/openvehicles/Open-Vehicle-Android/wiki/History Note: you can download the APK files of the current and previous releases from:https://github.com/openvehicles/Open-Vehicle-Android/tree/master/relea… <https://github.com/openvehicles/Open-Vehicle-Android/tree/master/release> To install an App from an APK file, you need to allow installing from "unknown sources" in your Android security configuration. <https://github.com/openvehicles/Open-Vehicle-Android/wiki/History#version-3…>Version 3.17.3 (2020-12-28) * Overall image size optimizations * Volt/Ampera: images for doors, lighting, charge port * Nicer light images for VW e-Up / Mii / Citigo * Add "car_hvac_on" flag to Update Broadcast Intent * Add car service interval info if available <https://github.com/openvehicles/Open-Vehicle-Android/wiki/History#version-3…> -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

Fireplace app
by Chris van der Meijden 29 Dec '20

29 Dec '20

I'm writing a little Android app with Cordova to do something similar as Tesla's "Romance mode". The app will turn climate control on or off and will show a burning log fire while the car is heating. As cordova uses HTML and Javascript you can see an online preview here: http://www.arachnon.de/fire/test.html When you click or tap on the fireplace the countdown for turning "climatecontrol" on ticks down for 17 seconds. After that the fire starts "moving" and on webkit browsers you will hear a tickling sound. When you click or tap again the tickling will stop and you will get a static image again. You will also get a red bar for 10 seconds, turning "climatecontrol" off and blocking any new commands for those 10 seconds. When you click or tap on the yellow bar you will be able to store your OVMS credentials (vehicle ID and password). Cave: this is done in plain text with window.localstorage so the password will be plain readable from the local storage within the browser on your device. The credentials are needed to communicate with the Android OVMS app, as I am planning to use the "SendCommand Broadcast Intent data" functionality of the OVMS app. I should be able to do that via this cordova plugin: https://github.com/cordova-misc/cordova-webintent I read the OVMS "SendCommand Broadcast Intent data" documentation here: https://github.com/openvehicles/Open-Vehicle-Android/wiki/SendCommand-B roadcast-Intent-data but it is not clear to me, how I can initiate the "climatecontrol on" shell command over the broadcast. So would like to ask for help on that :-) Once the app is up and running it should be usable for any vehicle with OVMS climate control implemented. Just a little gimmick. But fun :-)) Regards Chris

3 12

Keeping OBD-II alive
by Steve Davies 27 Dec '20

27 Dec '20

Hi all, Merry Christmas if you celebrate - beautiful hot weather here in Cape Town but surely a different story for most of you! (Michael: Thanks for the help with that "BC".) My car's OBD currently goes off after a while whenever it's not READY (to drive) (whether charging or not), This obviously affects the usability on my car, especially when charging since you can't follow the charging process properly. I did find that if you use the remote key it will wake things up; if you use BMW Connected drive app to lock/unlock then that also wakes things up. I see that the MGEV seems similar - the docs for that car say: The car is accessible over the OBD port when it is running (ignition on) and for around 40 seconds after it is turned off or the car is "tweaked" (lock button pushed, etc). The OBD port may be kept awake by using the "tester present" message to the gateway ECU. This keeps a lot of systems awake and draws roughly 5A on the 12V bus, so it's not a good idea to do. If the car is unlocked, the gateway can be woken if the car is unlocked by pinging the "tester present" message continuously every 100ms until it responds. If the car is locked this simply causes the gateway to go into some kind of zombie proxy mode that isn't very useful. If the car is locked, the gateway may be woken by sending a session 2 command every 250ms to the gateway. I'm looking at the MGEV code to see how it's done - can see the gist of it. It looks like Chris Staite was the author of the MGEV support - Chris are you on the list? Can you answer some questions for me or give me an outline as to how it goes? My logic would be that if the car is charging it doesn't do much harm to try to keep the OBD-II responsive. I suppose it diverts a little power from charging, but when you are on a long trip and fast charging somewhere you want to know if charging stops! Thanks, Steve

2 3

WiFi client not switching to better AP
by Stephen Casner 23 Dec '20

23 Dec '20

Many months ago I installed another AP for the home network in my garage because the signal quality to the main router was too poor for OVMS to operate. Today I needed to restart the garage AP, so OVMS hear the main router again and associated to it. But even after the garage AP came back up, OVMS stuck with the main router and kept toggling between WiFi and modem because the signal quality was bad. It this behavior just a function of the WiFi driver that we can't control, or is it something we could improve? I fixed it by "wifi mode off" then "wifi mode client". -- Steve I (513443477) netmanager: WIFI client has bad signal quality (-89.2 dBm); disconnect I (513443477) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (513443477) netmanager: Set DNS#0 8.8.8.8 I (513443477) netmanager: Set DNS#1 8.8.4.4 I (513443477) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (513443537) time: Network was reconfigured: restarting SNTP client I (513443547) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513443547) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513443717) ovms-server-v2: Status: Disconnected I (513463467) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (513463467) ovms-server-v2: Status: Connecting... I (513466157) ovms-server-v2: Connection successful I (513466157) ovms-server-v2: Status: Logging in... ... I (513522477) netmanager: WIFI client has good signal quality (-86.9 dBm); connect I (513522477) netmanager: Interface priority is st13 (192.168.1.74/255.255.255.0 gateway 192.168.1.254) I (513522477) netmanager: Set DNS#0 8.8.8.8 I (513522477) netmanager: Set DNS#1 8.8.4.4 I (513522477) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (513522527) time: Network was reconfigured: restarting SNTP client I (513522527) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513522527) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513522697) ovms-server-v2: Status: Disconnected I (513529477) netmanager: WIFI client has bad signal quality (-89.0 dBm); disconnect I (513529477) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (513529477) netmanager: Set DNS#0 8.8.8.8 I (513529477) netmanager: Set DNS#1 8.8.4.4 I (513529477) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (513529527) time: Network was reconfigured: restarting SNTP client I (513529537) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513529537) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513539467) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (513539467) ovms-server-v2: Status: Connecting... I (513541987) ovms-server-v2: Connection successful I (513541987) ovms-server-v2: Status: Logging in...

4 30

Help me get my first data item on the I3
by Steve Davies 23 Dec '20

23 Dec '20

Hi, Can I ask someone to help me get started with pulling data off the OBD-2 on the I3. I have info on what works via an LM327 and I know the pids, but it would help me for some pointers as to how to do it on the OVMS. You know - the goal to get the first one working. Here's an example definition - the SOC of the main battery. This is extracted from decompiling a definition file for ediasbas/ediasblib: (The "_EN" text is translated using Google cloud translate so the German is the original) The "job" is defined like so: { "SERVICE" : "22", "ID" : "0xDDBC", "DIV" : "-", "INFO" : "aktueller Anzeige Soc", "RES_TABELLE" : "RES_0xDDBC_D", "ARG_TABELLE" : "-", "EINHEIT" : "-", "DATENTYP" : "-", "ARG" : "ANZEIGE_SOC", "LABEL" : "-", "ADD" : "-", "MUL" : "-", "INFO_EN" : "current advertisement Soc", "L/H" : "-", "RESULTNAME" : "-", "NAME" : "-", "SG_ADR" : "-" }, The "results" are defined like so: "RES_0XDDBC_D" : [ { "DIV" : "10.0", "INFO_EN" : "current advertisement Soc", "DATENTYP" : "unsigned int", "EINHEIT" : "%", "INFO" : "aktueller Anzeige Soc", "MASKE" : "-", "RESULTNAME" : "STAT_ANZEIGE_SOC_WERT", "L/H" : "high", "MUL" : "1.0", "ADD" : "0.0", "NAME" : "-" }, { "NAME" : "-", "ADD" : "0.0", "MUL" : "1.0", "L/H" : "high", "RESULTNAME" : "STAT_MAXIMALE_ANZEIGE_SOC_WERT", "INFO" : "obere Grenze des Anzeige Soc", "MASKE" : "-", "INFO_EN" : "upper limit of the display Soc", "EINHEIT" : "%", "DATENTYP" : "unsigned int", "DIV" : "10.0" }, { "RESULTNAME" : "STAT_MINIMALE_ANZEIGE_SOC_WERT", "L/H" : "high", "MUL" : "1.0", "NAME" : "-", "ADD" : "0.0", "DIV" : "10.0", "INFO_EN" : "lower limit of the display Soc", "EINHEIT" : "%", "DATENTYP" : "unsigned int", "INFO" : "untere Grenze des Anzeige Soc", "MASKE" : "-" } ], I read it that three unsigned ints (16 bits each) are returned. Each is divided by 10 to return a "%". I traced an app that can retrieves this parameter using an LM327 based OBD2 interface. That app initialises the LM327 like so: 2020-11-15 10:34:28.831 --> ATD Return all settings to default 2020-11-15 10:34:28.849 --> ATE0 Disable command echo 2020-11-15 10:34:28.861 --> ATH1 Show CAN message headers 2020-11-15 10:34:28.875 --> ATAL Allow long messages 2020-11-15 10:34:28.887 --> ATPBE101 Set programmable param 0x2c to 0xE1, 0x2d to 0x01 - 2c=0xE1: - 11 bit IDs - variable data-length code - 11 or 29 bit received IDs - use data format ISO 15765-4 (CAN) - 2d=0x01 - Use rate divisor of 1 2020-11-15 10:34:28.901 --> ATSPB Use protocol USER1 CAN (as set above I think) 2020-11-15 10:34:28.949 --> ATBI Bypass initialisation - apparently a bad idea... ? 2020-11-15 10:34:28.964 --> ATSH6F1 Set header bytes to 0x6F1 ( 0x06F1 ? ) 2020-11-15 10:34:28.978 --> ATAT0 Disable adaptive timing - wait up to ATSF time 2020-11-15 10:34:28.992 --> ATSTFF Maximum wait Then, when it fetches this PID it does the following: 2020-11-15 10:34:35.101 --> ATCRA607⏎ // Listen for 0x607 2020-11-15 10:34:35.114 <-- OK⏎⏎> 2020-11-15 10:34:35.115 --> ATCEA07⏎ // "extended address" 0x07 [matches 607?] 2020-11-15 10:34:35.127 <-- OK⏎⏎> 2020-11-15 10:34:35.129 --> ATFCSH6F1⏎ // Flow control header 2020-11-15 10:34:35.141 <-- OK⏎⏎> 2020-11-15 10:34:35.143 --> ATFCSD07300800⏎ // Flow control data 2020-11-15 10:34:35.156 <-- OK⏎⏎> 2020-11-15 10:34:35.157 --> ATFCSM1⏎ // Flow control mode 2020-11-15 10:34:35.170 <-- OK⏎⏎> 2020-11-15 10:34:36.367 --> 22␣DD␣BC⏎ // asking for "extended" PID 0xDDBC 2020-11-15 10:34:36.474 <-- 607␣F1␣03␣7F␣22␣78␣⏎ // this is some unrelated packet? 2020-11-15 10:34:36.539 <-- 607␣F1␣10␣09␣62␣DD␣BC␣02␣4C␣⏎ // reply --> 0x24C = 588 = 58.8 SOC 607␣F1␣21␣03␣A6␣00␣69␣FF␣FF␣⏎ // 0x03A6 = = 93.4%, 0x0069 = 10.5% 2020-11-15 10:34:37.598 <-- ⏎> Remember the LM327 takes the sent bytes and wraps with into a full CAN message - though I'm not sure exactly how that comes out - I presume that "extended address" goes in somewhere. --> 22 DD BC is the PID <-- 2 part reply. First has the SOC. Second has 0x03A6 (934) and 0x0069 (105) First int is 588 or 58.8% which is the physical SOC of the battery. 934 is 93.4 which is the physical SOC level which the car displays as "100%" (i3 keeps some headroom "reserved"). 105 is 10.5 which is the physical SOC level that the car displays as 0%. I'd appreciate some help to give me a head-start to be able to retrieve this attribute on the OVMS box. Thanks, Steve

2 17