- OvmsDev - Open Vehicles

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 03 Nov '17

03 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 01 Nov '17

01 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

Terrible Network Manager
by Tom Parker 31 Oct '17

31 Oct '17

Hi, I've been driving around with the v3 hardware in my car for a couple of weeks using my phone's wifi hotspot. I found that it wouldn't re-connect to my phone after I turned off the hotspot and it wouldn't connect to my house wifi when the car is at home. So fixed it with a terrible network manager: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/ma… This network manager is terrible: * it doesn't scan for available wifi and try to connect to only those that are available * it tries to connect to the next network once per minute, meaning it can take several minutes to connect * it iterates through a list of 3 networks, if you don't have 3 networks, you still have to wait * it's implemented using a mixture of events, scripts and terrible C++ code * it should use string concatenation to make the event names, rather than 3 hard coded names, but if it did that then the terrible C++ code wouldn't be so terrible * you can't turn it on or off except in sdkconfig. If it's compiled in, it tries to connect every minute * it doesn't connect to my office wifi, I haven't looked in to why, maybe it is because there is a space in the SSID name on that network Despite being so terrible, it's been pretty reliable for me. I'm not sure if you want a pull request for this thing, or perhaps someone could re-write it "properly". The obvious thing to do is to scan for available networks, look at the list of configured SSID-Password pairs and if any are in range, trigger the wifi connection directly rather than triggering an event that runs a script that attempts to connect to the network. If you want to try it out, I wrote some instructions: Beware that the following advice appends to files, but does not confirm they are empty before doing so, be sure you don't end up with unexpected scripts or script content, as unexpected things could happen. Store the credentials for your wifi network(s) with config set wifi.ssid <ssid> <password> Create a script to stop the v2 server when the network goes down (note the "network.down" doesn't fire, so use system.wifi.sta.disconnected): vfs mkdir /store/events/system.wifi.sta.disconnected vfs append "server v2 stop" /store/events/system.wifi.sta.disconnected/shutdown Create a script to start the v2 server client when the network comes up: vfs mkdir /store/events/network.up vfs append "server v2 start" /store/events/network.up/startmeup Create a script to select a vehicle on startup: vfs mkdir /store/events/system.start vfs append "vehicle module NL" /store/events/system.start/startmeup Create scripts to connect to your wifi network in response to the terrible network manager events: vfs mkdir /store/events/tnm.connect.0 vfs append "wifi mode client <ssid_1>" /store/events/tnm.connect.0/connect vfs mkdir /store/events/tnm.connect.1 vfs append "wifi mode client <ssid_2>" /store/events/tnm.connect.1/connect vfs mkdir /store/events/tnm.connect.2 vfs append "wifi mode client <ssid_3>" /store/events/tnm.connect.2/connect

3 3

V3 progress
by Tom Parker 29 Oct '17

29 Oct '17

Hi all, I got my USB CAN bus interface working with the OVMS v3 hardware on my desk, it turns out you need at least one terminator before the bus will work! I cargo culted (I've never written C++) my way through transposing the Leaf OVMS v2 can bus decoder into the v3 code. When I play a can bus recording I see the metrics update! I see that quite a few of the metrics used on the leaf are missing. Do I just add them to metrics_standard.cpp? None of them are particularly leaf specific, so this seems the right place. Is anyone working on the v2 server support code to send the S and D messages?

6 36

V3 CAN frames missing last four data bytes
by Michael Balzer 27 Oct '17

27 Oct '17

Is this a known problem? In all of my can1 frames bytes 5-8 are zero: OVMS > metrics list can d.can1.f.080 d.can1.f.155 07 97 cf 54 00 00 00 00 d.can1.f.196 00 ff e7 7f 00 00 00 00 d.can1.f.19f ff ff 7d 0f 00 00 00 00 d.can1.f.423 03 33 ff ff 00 00 00 00 d.can1.f.424 11 40 10 23 00 00 00 00 d.can1.f.425 2a 21 44 ff 00 00 00 00 d.can1.f.426 00 78 01 00 00 00 00 d.can1.f.436 00 07 7e d8 00 00 d.can1.f.554 36 36 36 36 00 00 00 00 d.can1.f.556 31 23 11 31 00 00 00 00 d.can1.f.557 31 03 10 31 00 00 00 00 d.can1.f.55e 31 23 12 31 00 00 00 00 d.can1.f.55f ff ff 73 00 00 00 00 00 d.can1.f.597 00 95 08 41 00 00 00 00 d.can1.f.599 00 00 b7 b2 00 00 00 00 d.can1.f.59b 20 00 64 00 00 00 00 00 d.can1.f.59e 00 00 0c 8d 00 00 00 00 d.can1.f.5d7 00 00 04 7c 00 00 00 d.can1.f.627 00 00 00 d.can1.f.628 00 00 00 d.can1.f.629 00 00 00 d.can1.f.659 ff ff ff ff d.can1.f.69f f0 82 87 37 d.can1.f.701 05 Trace mode: … CAN rx origin can1 id 080 (len:0) CAN rx origin can1 id 196 (len:8) 00 ff e7 7f 00 00 00 00........ CAN rx origin can1 id 155 (len:8) 07 97 ce 54 00 00 00 00...T.... CAN rx origin can1 id 19f (len:8) ff ff 7d 0f 00 00 00 00..}..... CAN rx origin can1 id 196 (len:8) 00 ff e7 7f 00 00 00 00........ CAN rx origin can1 id 155 (len:8) 07 97 ce 54 00 00 00 00...T.... CAN rx origin can1 id 5d7 (len:7) 00 00 04 7c 00 00 00 ...|... CAN rx origin can1 id 19f (len:8) ff ff 7d 0f 00 00 00 00..}..... CAN rx origin can1 id 080 (len:0) CAN rx origin can1 id 196 (len:8) 00 ff e7 7f 00 00 00 00........ CAN rx origin can1 id 599 (len:8) 00 00 b7 b2 00 00 00 00........ CAN rx origin can1 id 436 (len:6) 00 07 7e f2 00 00 ..~... CAN rx origin can1 id 155 (len:8) 07 97 ce 54 00 00 00 00...T.... CAN rx origin can1 id 69f (len:4) f0 82 87 37 ...7 CAN rx origin can1 id 19f (len:8) ff ff 7d 0f 00 00 00 00..}..... CAN rx origin can1 id 196 (len:8) 00 ff e7 7f 00 00 00 00........ CAN rx origin can1 id 423 (len:8) 03 33 ff ff 00 00 00 00.3...... CAN rx origin can1 id 426 (len:7) 00 78 01 00 00 00 00 .x..... … -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

7 18

V3 distance/speed units
by Michael Balzer 26 Oct '17

26 Oct '17

Trying to catch up… a) I'd love to get rid of those km→miles→km conversions in V3. How about introducing a metric "v.units" instead to hold the units used by the vehicle, and make conversions at the user level if necessary? b) Regarding the standard metrics currently defined, I'd need to introduce own copies again for higher precision. I.e. SOC, SOH, speed and ranges all are integers now, and some more I'd like to be able to set at higher precision. How about making all these be floats now? I.e. everything that can require more than integer precision. The server_v2 can output the values as integers for v2 client compatibility. c) I haven't seen a recommendation on naming vehicle specific metrics. My proposal: use the vehicle code as the prefix, then try to reuse similar paths from the standard metrics, adding detail as necessary. For example, the vehicle module version on the Twizy ("RT") is "rt.m.version", and for the min & max battery voltage I've got "rt.v.b.voltage.min" & "rt.v.b.voltage.max". OVMS > metrics list rt. rt.m.version 1.0.0 Oct 23 2017 11:45:31 rt.v.b.soc rt.v.b.temp.m1 rt.v.b.temp.m2 rt.v.b.temp.m3 rt.v.b.temp.m4 rt.v.b.temp.m5 rt.v.b.temp.m6 rt.v.b.temp.m7 rt.v.b.voltage.max 0 rt.v.b.voltage.min 0 That way a path component can be used to list all related metrics: OVMS > metrics list b.voltage rt.v.b.voltage.max 0 rt.v.b.voltage.min 0 v.b.voltage d) I think most of the temperature metrics have wrong names: v.b.temp.ambient v.b.temp.battery v.b.temp.charger v.b.temp.motor v.b.temp.pem …as "b." should be reserved for "battery". How about… v.e.temp v.b.temp v.c.temp v.m.temp v.i.temp …introducing "m." for motor and "i." for inverter? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 11

Feedback request: HUD sleep behavior work-around
by Greg D. 23 Oct '17

23 Oct '17

2 4