November 2017 - OvmsDev - Open Vehicles

v2 android clients crashes while v3 is charging
by Tom Parker 08 Nov '17

08 Nov '17

I found that the android client crashes when my leaf with v3 hardware is charging. This is because it expects integers for some values and throws NumberFormatException parsing if it encounters a floating point string. The AsString() method on float metrics returns a floating point string and we have a bunch of metrics that used to be integers but are now (correctly) floats. I've sent a pull request with one possible solution https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/6 but I'm pretty sure it's the wrong solution. I added a special case unit conversion to integer, but having done this I think an AsIntString(default, unit) method on the floating point metrics would be a more appropriate api. As I've written it, you can't combine a unit conversion and a rounding to integer. Thoughts? I also sent another pull request for a minimal implementation of the charger state related values in the v2 protocol, and some small leaf fixes.

3 6

MS_V_MOT_RPM
by Mark Webb-Johnson 06 Nov '17

06 Nov '17

I’ve added a new standard metric (MS_V_MOT_RPM, v.m.rpm. StandardMetrics.ms_v_mot_rpm). This should be used to track engine/motor RPM. It is need by pretty much every OBDII tool out there, so makes sense for us to have it. In single-gear EVs, it can be output just after speed, via a simple scaling factor. Please try to implement it in your vehicle modules. Regards, Mark.

1 0

Android client crashes
by Tom Parker 05 Nov '17

05 Nov '17

I found a couple of new android client crashes. One was caused by the TPMS message which I've sent a pull request to fix. The other crash is in the GPS message. The v2 car module's car_drivemode is a hex encoded char. In v3 this has turned into a string which defaults to 'standard'. The android client crashes on receipt of this message. I'm not sure how to fix this, the field is only used by the twizzy (as a bit field) and I'm not sure the intention of the ms_v_env_drivemode string metric is. In the meantime this patch avoids the crash diff --git a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp index 9d3a6ad..eddb89f 100644 --- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp +++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp @@ -558,7 +558,7 @@ void OvmsServerV2::TransmitMsgGPS(bool always) else buffer.append(StandardMetrics.ms_v_pos_speed->AsString("0",Mph).c_str()); buffer.append(","); - buffer.append(StandardMetrics.ms_v_env_drivemode->AsString("standard").c_str()); + buffer.append("0"); // car_drivemode buffer.append(","); buffer.append(StandardMetrics.ms_v_bat_power->AsString("0",Other,1).c_str()); buffer.append(",");

2 1

V3 Renault Twizy 0.1.0
by Michael Balzer 04 Nov '17

04 Nov '17

…just pushed. I've also made some minor changes & extensions to the framework, hopefully helpful. This is very basic support (~10%). It covers CAN processing and battery / power monitoring. Just metrics output for now, no commands or notifications. Free RAM is down to 36.6 K after loading the module. I've removed the "v." from the "x.rt.v." metrics names, as nearly all "x.rt" metrics are (of course) vehicle metrics. "x.rt.m.version" does not fit the scheme and breaks into the "motor" namespace, as "m." was in use before, maybe we should better use "mot." for motor metrics. Regards, Michael OVMS > config list x.rt x.rt autopower: yes autoreset: yes canwrite: no cap_act_prc: 87.4 cap_nom_ah: 108.0 chargelevel: 0 chargemode: 0 console: no kickdown: yes maxrange: 71 suffrange: 65 suffsoc: 85 OVMS > metrics list m.freeram 36644 m.hardware OVMS WIFI BLE BT cores=2 rev=ESP32/1 m.monotonic 541Sec m.net.mdm.iccid m.net.mdm.model m.net.provider WLAN-214677 m.net.sq m.net.type wifi m.serial 30:ae:a4:37:25:88 m.tasks 17 m.time.utc 546Sec m.version 3.0.0/factory/main build (idf v2.1-20-g88ab5d48) Oct 29 2017 09:15:17 s.v2.connected s.v2.peers v.b.12v.current 1.6A v.b.12v.voltage 0.527473V v.b.cac 94.392Ah v.b.current -36A v.b.energy.recd 0.000739342kWh v.b.energy.used 0kWh v.b.power -2.0224kW v.b.range.est 50Km v.b.range.full 68.2571Km v.b.range.ideal 49Km v.b.soc 71.92% v.b.soh 100% v.b.temp 15.4286°C v.b.voltage 56.2V v.c.charging yes v.c.climit v.c.current 36A v.c.duration.full 82Min v.c.duration.range 50Min v.c.duration.soc 25Min v.c.kwh 0.000739342kWh v.c.minutes 6Min v.c.mode standard v.c.pilot yes v.c.state charging v.c.substate go v.c.temp 25°C v.c.timermode v.c.timerstart v.c.type v.c.voltage 230V v.d.cp yes v.d.fl v.d.fr v.d.hood v.d.rl v.d.rr v.d.trunk v.e.alarm v.e.awake no v.e.c.config no v.e.c.login no v.e.charging12v yes v.e.cooling v.e.drivemode v.e.handbrake v.e.headlights v.e.heating v.e.hvac v.e.locked no v.e.on no v.e.parktime v.e.temp v.e.valet no v.i.temp v.m.temp 0°C v.p.altitude v.p.direction v.p.gpslock v.p.latitude v.p.longitude v.p.odometer 3456.51Km v.p.satcount v.p.speed 0Kph v.p.trip 3456.51Km v.tp.fl.p v.tp.fl.t v.tp.fr.p v.tp.fr.t v.tp.rl.p v.tp.rl.t v.tp.rr.p v.tp.rr.t v.type RT v.vin 7378280 x.rt.b.cell.01.voltage.act 4.025V x.rt.b.cell.01.voltage.max 4.025V x.rt.b.cell.01.voltage.maxdev 2.85712V x.rt.b.cell.01.voltage.min 4.02V x.rt.b.cell.02.voltage.act 4.015V x.rt.b.cell.02.voltage.max 4.015V x.rt.b.cell.02.voltage.maxdev 0.857117V x.rt.b.cell.02.voltage.min 4.01V x.rt.b.cell.03.voltage.act 4.015V x.rt.b.cell.03.voltage.max 4.015V x.rt.b.cell.03.voltage.maxdev 0.857117V x.rt.b.cell.03.voltage.min 4.01V x.rt.b.cell.04.voltage.act 4.01V x.rt.b.cell.04.voltage.max 4.015V x.rt.b.cell.04.voltage.maxdev 0.857117V x.rt.b.cell.04.voltage.min 4.005V x.rt.b.cell.05.voltage.act 4.015V x.rt.b.cell.05.voltage.max 4.015V x.rt.b.cell.05.voltage.maxdev 0.857117V x.rt.b.cell.05.voltage.min 4.01V x.rt.b.cell.06.voltage.act 4.015V x.rt.b.cell.06.voltage.max 4.015V x.rt.b.cell.06.voltage.maxdev -1.14288V x.rt.b.cell.06.voltage.min 4.005V x.rt.b.cell.07.voltage.act 4.015V x.rt.b.cell.07.voltage.max 4.015V x.rt.b.cell.07.voltage.maxdev 0.285706V x.rt.b.cell.07.voltage.min 4.01V x.rt.b.cell.08.voltage.act 4.01V x.rt.b.cell.08.voltage.max 4.01V x.rt.b.cell.08.voltage.maxdev -1.14288V x.rt.b.cell.08.voltage.min 4.005V x.rt.b.cell.09.voltage.act 4.01V x.rt.b.cell.09.voltage.max 4.01V x.rt.b.cell.09.voltage.maxdev -1.14288V x.rt.b.cell.09.voltage.min 4.005V x.rt.b.cell.10.voltage.act 4.01V x.rt.b.cell.10.voltage.max 4.01V x.rt.b.cell.10.voltage.maxdev -1.14288V x.rt.b.cell.10.voltage.min 4.005V x.rt.b.cell.11.voltage.act 4.015V x.rt.b.cell.11.voltage.max 4.015V x.rt.b.cell.11.voltage.maxdev 0.285706V x.rt.b.cell.11.voltage.min 4.01V x.rt.b.cell.12.voltage.act 4.01V x.rt.b.cell.12.voltage.max 4.01V x.rt.b.cell.12.voltage.maxdev -1.14288V x.rt.b.cell.12.voltage.min 4.005V x.rt.b.cell.13.voltage.act 4.01V x.rt.b.cell.13.voltage.max 4.01V x.rt.b.cell.13.voltage.maxdev -1.14288V x.rt.b.cell.13.voltage.min 4.005V x.rt.b.cell.14.voltage.act 4.025V x.rt.b.cell.14.voltage.max 4.025V x.rt.b.cell.14.voltage.maxdev 2.14288V x.rt.b.cell.14.voltage.min 4.015V x.rt.b.cell.15.voltage.act 0V x.rt.b.cell.15.voltage.max 0V x.rt.b.cell.15.voltage.maxdev 0V x.rt.b.cell.15.voltage.min 0V x.rt.b.cell.16.voltage.act 0V x.rt.b.cell.16.voltage.max 0V x.rt.b.cell.16.voltage.maxdev 0V x.rt.b.cell.16.voltage.min 0V x.rt.b.cell.cnt 14 x.rt.b.cmod.01.temp.act 16°C x.rt.b.cmod.01.temp.max 16°C x.rt.b.cmod.01.temp.maxdev 0.57143°C x.rt.b.cmod.01.temp.min 16°C x.rt.b.cmod.02.temp.act 15°C x.rt.b.cmod.02.temp.max 15°C x.rt.b.cmod.02.temp.maxdev -0.42857°C x.rt.b.cmod.02.temp.min 15°C x.rt.b.cmod.03.temp.act 16°C x.rt.b.cmod.03.temp.max 16°C x.rt.b.cmod.03.temp.maxdev 0.57143°C x.rt.b.cmod.03.temp.min 16°C x.rt.b.cmod.04.temp.act 15°C x.rt.b.cmod.04.temp.max 15°C x.rt.b.cmod.04.temp.maxdev -0.42857°C x.rt.b.cmod.04.temp.min 15°C x.rt.b.cmod.05.temp.act 16°C x.rt.b.cmod.05.temp.max 16°C x.rt.b.cmod.05.temp.maxdev 0.57143°C x.rt.b.cmod.05.temp.min 16°C x.rt.b.cmod.06.temp.act 15°C x.rt.b.cmod.06.temp.max 15°C x.rt.b.cmod.06.temp.maxdev -0.42857°C x.rt.b.cmod.06.temp.min 15°C x.rt.b.cmod.07.temp.act 15°C x.rt.b.cmod.07.temp.max 15°C x.rt.b.cmod.07.temp.maxdev -0.42857°C x.rt.b.cmod.07.temp.min 15°C x.rt.b.cmod.08.temp.act -40°C x.rt.b.cmod.08.temp.max -40°C x.rt.b.cmod.08.temp.maxdev 0°C x.rt.b.cmod.08.temp.min -40°C x.rt.b.cmod.cnt 7 x.rt.b.pack.1.temp.stddev.max 0.495093°C x.rt.b.pack.1.voltage.max 56.2V x.rt.b.pack.1.voltage.min 56.1V x.rt.b.pack.1.voltage.stddev.max 0.00586302V x.rt.b.pack.cnt 1 x.rt.m.version 0.1.0 Oct 29 2017 10:44:20 x.rt.p.stats.acc.dist 0Km x.rt.p.stats.acc.recd 0kWh x.rt.p.stats.acc.spdavg 0Kph/s x.rt.p.stats.acc.used 0kWh x.rt.p.stats.cst.dist 0Km x.rt.p.stats.cst.recd 0.000739342kWh x.rt.p.stats.cst.spdavg 0Kph x.rt.p.stats.cst.used 0kWh x.rt.p.stats.dec.dist 0Km x.rt.p.stats.dec.recd 0kWh x.rt.p.stats.dec.spdavg 0Kph/s x.rt.p.stats.dec.used 0kWh x.rt.p.stats.ldn.dist 0Km x.rt.p.stats.ldn.hsum 0m x.rt.p.stats.ldn.recd 0kWh x.rt.p.stats.ldn.used 0kWh x.rt.p.stats.lup.dist 0Km x.rt.p.stats.lup.hsum 0m x.rt.p.stats.lup.recd 0kWh x.rt.p.stats.lup.used 0kWh -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 6

Revised memory diagnostics code
by Stephen Casner 04 Nov '17

04 Nov '17

WARNING! I have revised the memory diagnostics code in the app and in esp-idf such that both need to be updated at the same time if you have enabled CONFIG_OVMS_DEV_DEBUGRAM and CONFIG_OVMS_DEV_DEBUGTASKS. See the commit messages for details. -- Steve

3 6

Big git commit - logging levels
by Mark Webb-Johnson 03 Nov '17

03 Nov '17

I’ve just pushed a big git commit to standardise the support for logging levels in OVMS v3. These notes should help keep things organised: All OVMS code should now have this near the top of it’s code: #include "ovms_log.h" static const char *TAG = “<some-tag>"; Please don’t use esp_log.h directly, but instead always use ovms_log.h. Please do use just one tag for your module - something short, sweet, unique, easy to type, and descriptive. This ovms_log.h module redefines the standard ESP_LOG? macros to something more useful for our environment. In particular, they move the implementation of logging level control from compile-time to run-time. ESP has five logging levels. The intended use of these levels is as follows: ESP_LOGE(TAG, format, values…) Intended for logging errors. Non-recoverable, or otherwise serious, issues that should be shown to users. ESP_LOGW(TAG, format, values…) Intended for logging warnings. Recoverable, or minor, issues that should be shown to users. ESP_LOGI(TAG, format, values…) Informational messages. Primarily intended for developers or advanced users of the system, providing an insight into the state of the code paths. ESP_LOGD(TAG, format, values…) Debug messages. Intended for developers, or people debugging issues, these provide detailed diagnostic information. ESP_LOGV(TAG, format, values…) Verbose messages. Extremely detailed, intended for developers only. The default logging level is set in menuconfig (Component -> Log -> Default log verbosity). In sdkconfig.default, this is now set to ‘warning’ (ESP_LOGW) and is configured as such during system boots. Log messages of severity equal to, or above, this log level will be displayed. The log level can be set at runtime with the console ‘level’ command. In particular, it can be set globally (for tag ‘*’), or per-tag. You can also put these level commands in a script if you want it set to anything other than the default (so, for example, I could have the vehicle module I am working on at debug log level, but everything else at warnings only). I hope that the above is understandable and useful. It may not be perfect, and may need some tuning over time, but it should be workable now. Regards, Mark.

1 0

RAM
by Mark Webb-Johnson 02 Nov '17

02 Nov '17

With our default menuconfig (plus memory debugging enabled), I get: I (0) cpu_start: App cpu up. I (2206) heap_alloc_caps: Initializing. RAM available for dynamic allocation: I (2229) heap_alloc_caps: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (2249) heap_alloc_caps: At 3FFCA290 len 00015D70 (87 KiB): DRAM I (2270) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (2291) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (2313) heap_alloc_caps: At 400955AC len 0000AA54 (42 KiB): IRAM OVMS > module memory ============================ Free 8-bit 77696/218088, 32-bit 18608/43580, numafter = 872 task=Asy total= 0 0 24972 change= +0 +0 +24972 task=tiT total= 352 0 0 change= +352 +0 +0 task=Hou total= 20192 24444 0 change= +20192 +24444 +0 task=mai total= 9488 26948 0 change= +9488 +26948 +0 task=IDL total= 72 0 0 change= +72 +0 +0 task=ipc total= 9320 0 0 change= +9320 +0 +0 task=eve total= 41440 0 0 change= +41440 +0 +0 If I turn off bluetooth in menuconfig, I get: OVMS > module memory ============================ Free 8-bit 150548/290912, 32-bit 18628/43600, numafter = 872 task=Asy total= 0 0 24972 change= +0 +0 +24972 task=tiT total= 352 0 0 change= +352 +0 +0 task=Hou total= 44592 0 0 change= +44592 +0 +0 task=mai total= 36436 0 0 change= +36436 +0 +0 task=IDL total= 72 0 0 change= +72 +0 +0 task=ipc total= 9320 0 0 change= +9320 +0 +0 task=eve total= 41468 0 0 change= +41468 +0 +0 72KB RAM seems a bit ridiculous for a bluetooth stack. I really hope this is not Espressif loading those binary blobs from libbtdm_app.a into RAM. If I configure a minimal (for our needs) bluetooth (BLE only), I get: --- Bluedroid Bluetooth stack enabled (3072) Bluetooth event (callback to application) task stack size (NEW) [ ] Bluedroid memory debug (NEW) [ ] Classic Bluetooth (NEW) [*] Release DRAM from Classic BT controller [*] Include GATT server module(GATTS) (NEW) [ ] Include GATT client module(GATTC) [*] Include BLE security module(SMP) (NEW) [*] Close the bluedroid bt stack log print (NEW) (2) BT/BLE MAX ACL CONNECTIONS(1~7) (NEW) OVMS > module memory ============================ Free 8-bit 106312/246720, 32-bit 18576/43548, numafter = 872 task=Asy total= 0 0 24972 change= +0 +0 +24972 task=tiT total= 352 0 0 change= +352 +0 +0 task=Hou total= 21840 22776 0 change= +21840 +22776 +0 task=mai total= 36436 0 0 change= +36436 +0 +0 task=IDL total= 72 0 0 change= +72 +0 +0 task=ipc total= 9320 0 0 change= +9320 +0 +0 task=eve total= 41476 0 0 change= +41476 +0 +0 With just classic bluetooth enabled: OVMS > module memory ============================ Free 8-bit 77696/218096, 32-bit 18608/43580, numafter = 872 task=Asy total= 0 0 24972 change= +0 +0 +24972 task=tiT total= 352 0 0 change= +352 +0 +0 task=Hou total= 20200 24444 0 change= +20200 +24444 +0 task=mai total= 9488 26948 0 change= +9488 +26948 +0 task=IDL total= 72 0 0 change= +72 +0 +0 task=ipc total= 9320 0 0 change= +9320 +0 +0 task=eve total= 41440 0 0 change= +41440 +0 +0 Turning off our memory and task debugging features, and enabling BLE GATT server + security (2 connections), gives me 122KB in metric m.freeram. That should include bluetooth requirements, but no wifi running yet. With wifi, it drops to 82KB. That should be what end-users of OVMS will see, and I’m happy with that, so have committed that as a default config for the moment. With memory and stack debugging enabled (as developers will most likely use), it drops 122KB-> 106KB. I did see some comments in the forums about this. For example: https://www.esp32.com/viewtopic.php?t=3139 <https://www.esp32.com/viewtopic.php?t=3139> It seems that IDF 3.0 changes the way this works (dynamic, rather than static as per menuconfig), and in the documentation for that they mention 70KB. It looks like a minimal bluetooth for us is going to cost 40KB RAM or so. Regards, Mark.

3 9

RE tool for OBDII
by Mark Webb-Johnson 01 Nov '17

01 Nov '17

RE tool for OBDII: OVMS > re start OVMS > re obdii standard 7df 7df Set OBDII standard ID range 7df-7df OVMS > obdii ecu start can3 OBDII ECU has been started I (38897) events: Signal(power.can3.on) I (38997) obd2ecu: Using custom scripting for pid#99 OVMS > power ext12v on Power mode of ext12v is now on I (44127) ext12v: Powering on external 12V devices (Wait a bit …) OVMS > re list key records ms last can3/7df:O2Qm1:0 2 11500 02 01 00 00 00 00 00 00 can3/7df:O2Qm1:12 18 1277 02 01 0c 00 00 00 00 00 can3/7df:O2Qm1:13 14 1642 02 01 0d 00 00 00 00 00 can3/7df:O2Qm1:16 14 1642 02 01 10 00 00 00 00 00 can3/7df:O2Qm1:32 1 23000 02 01 20 00 00 00 00 00 can3/7df:O2Qm1:47 13 1769 02 01 2f 00 00 00 00 00 can3/7df:O2Qm1:5 14 1642 02 01 05 00 00 00 00 00 can3/7df:O2Qm1:64 1 23000 02 01 40 00 00 00 00 00 You start the RE tool, and give it the ID range to monitor for standard frames OBDII. You can also optionally give ‘re obdii extended …’ for extended frames as well. The RE tool will then treat messages on those IDs as OBDII requests/responses and key appropriately. The keys are O2Q for query, and O2P for reply. The “m1” is mode #1. The final digits (after the “:”) is the PID requested/replied. This should work for both OBDII requests and replies (although only standard mode requests tested so far). At the moment, I’m monitoring frames inbound (can rx) only. We could monitor tx as well, without too much difficulty. Here is what a O2 vehicle module on the box, talking to an external OBDII ECU simulator, looks like: OVMS > re obdii standard 7df 7ef Set OBDII standard ID range 7df-7ef OVMS > vehicle module O2 I (593927) v-obdii: Generic OBDII vehicle module I (593927) events: Signal(power.can1.on) OVMS > re list key records ms last can1/7e8 3 19666 22 37 32 35 32 33 36 37 can1/7e8:O2Pm1:12 6 9833 04 41 0c 3c 13 00 00 00 can1/7e8:O2Pm1:13 5 11800 03 41 0d 5b 00 00 00 00 can1/7e8:O2Pm1:15 2 29500 03 41 0f 41 00 00 00 00 can1/7e8:O2Pm1:47 2 29500 03 41 2f 80 00 00 00 00 can1/7e8:O2Pm1:5 2 29500 03 41 05 40 00 00 00 00 can1/7e8:O2Pm1:70 2 29500 03 41 46 3c 00 00 00 00 can1/7e9:O2Pm1:12 6 9833 04 41 0c 3c 13 00 00 00 can1/7e9:O2Pm1:13 5 11800 03 41 0d 5b 00 00 00 00 can1/7e9:O2Pm1:5 2 29500 03 41 05 40 00 00 00 00 can1/7ea:O2Pm1:13 5 11800 03 41 0d 5b 00 00 00 00 Committed, and pushed. Regards, Mark.

1 0