September 2020 - OvmsDev

Fwd: [ovms:2576] Multiple crashes/not responding - less than one day old
by Derek Caudwell 11 Sep '20

11 Sep '20

Just submitted a PR to fix for NL's that lock on driving.

1 0

Fwd: [ovms:2576] Multiple crashes/not responding - less than one day old
by Mark Webb-Johnson 11 Sep '20

11 Sep '20

Nissan Leaf owner reporting the module cannot detect if he is driving (car on) or not. So he gets notifications about flatbed theft. Any ideas? > Begin forwarded message: > > From: help(a)openvehicles.com > Subject: [ovms:2576] Multiple crashes/not responding - less than one day old > Date: 11 September 2020 at 2:31:21 PM HKT > To: mark(a)openvehicles.com > > ethan.rose has updated the ticket 'Multiple crashes/not responding - less > than one day old': > https://www.openvehicles.com/node/2576#comment-6952 > State: active > Priority: normal > > You can visit the following URL to update this ticket: > https://www.openvehicles.com/node/2576#comment-form > > Update text: > ------------------------------ > > <pre id="output"> > On my way home tonight, > > # <kbd>metrics list v.e</kbd> > v.e.alarm > v.e.aux12v > v.e.awake no > v.e.c.config > v.e.c.login > v.e.cabin.fan 1 > v.e.cabin.fanlimit 7 > v.e.cabin.intake > v.e.cabin.setpoint 20°C > v.e.cabin.vent windscreen > v.e.cabinfan > v.e.cabinintake > v.e.cabinsetpoint > v.e.cabintemp 14.5°C > v.e.cabinvent > v.e.charging12v > v.e.cooling yes > v.e.drivemode > v.e.drivetime 0Sec > v.e.footbrake 0% > v.e.gear 1 > v.e.handbrake no > v.e.headlights yes > v.e.heating yes > v.e.hvac yes > v.e.locked yes > v.e.on no > v.e.parktime 679Sec > v.e.regenbrake > v.e.temp 12.5°C > v.e.throttle 0% > v.e.valet</pre> > > ------------------------------ > Unsubscribe from this ticket: > https://www.openvehicles.com/support/2576/unsubscribe/1/75ddbac9b7f6a451cdd… > Unsubscribe from all tickets: > https://www.openvehicles.com/support/all/unsubscribe/1/c4ca4238a0b923820dcc… > >

1 0

Reset Standard Metrics on vehicle change
by Soko 11 Sep '20

11 Sep '20

Hi again, Another issue reported is about (persistent) metrics who keep there value after vehicle change. First I thought the vehicles need to address this. But wouldn't it be better that all standard metrics get a reset on every vehicle change? Soko

4 7

Which value for SoC?
by Soko 10 Sep '20

10 Sep '20

Hey guys, I'm currently discussing with a user the correct calculation/display of the SoC... I'm displaying 1:1 the value of the ECU at the moment. Which is not corresponding to the gauge of the VW eUp: When the eUp gauge shows full (1/1) on the dashboard, the ECU reports ~95% SoC. Gauge at exactly 1/4, the ECU reports ~30% SoC. I can't tell if this is due to nominal <=> usable capacity of the battery. Or if its an internal threshold so the battery is never fully charged or discharged... Anyhow... how do other vehicle address this problem? Is the OVMS SoC always the same as the vehicle's "official" one? For my part - as a technician - I would prefer the "real" value... so 1:1 the value from the ECU. The user thinks it should be the value the dashboard gauge is showing... thanks Soko

2 1

VEHICLE_POLL_TYPE_READSCALING @ VWUP.OBD
by Soko 09 Sep '20

09 Sep '20

Hi, I've tried the new poller type "ReadScaling" with no luck. First I've tried it for the BatteryManager ECU (7E5) and the voltage-PID (1E3B) which should deliver just a division by 4 as formula for the scaling: D (57865) vehicle: PollerSend(1): send [bus=1, type=24, pid=1E3B], expecting 7e5/7ed-7ed V (57865) canlog-monitor: 1599579609.443101 1T11 7E5 03 24 1e 3b 00 00 00 00 V (57875) canlog-monitor: 1599579609.453040 1R11 7ED 03 7f 24 11 aa aa aa aa D (57875) vehicle: PollerReceive[7ED]: process OBD/UDS error 24(1E3B) code=11 So 7F is "serviceNotSupportedInActiveSession" as far as I can tell. So I did swap to the Charger ECU (744) with efficiency-PID (15D6) and loss-PID (15E1) as I'm already have there a extended diag session working: EXTENDED DIAG SESSION: D (24865) vehicle: PollerSend(1): send [bus=1, type=10, pid=3], expecting 744/7ae-7ae V (24865) canlog-monitor: 1599581491.143704 1T11 744 02 10 03 00 00 00 00 00 V (24865) canlog-monitor: 1599581491.144423 1R11 7AE 06 50 03 00 32 01 f4 00 D (24865) vehicle: PollerReceive[7AE]: process OBD/UDS response 10(3) frm=0 len=4 off=0 rem=0 READING EFFICIENCY VALUE: D (24865) vehicle: PollerSend(0): send [bus=1, type=22, pid=15D6], expecting 744/7ae-7ae V (24865) canlog-monitor: 1599581491.147379 1T11 744 03 22 15 d6 00 00 00 00 V (24875) canlog-monitor: 1599581496.164030 1R11 7AE 04 62 15 d6 fe 74 09 00 D (24875) vehicle: PollerReceive[7AE]: process OBD/UDS response 22(15D6) frm=0 len=1 off=0 rem=0 TRY READ SCALING FOR EFFICIENCY: D (24875) vehicle: PollerSend(0): send [bus=1, type=24, pid=15D6], expecting 744/7ae-7ae V (24875) canlog-monitor: 1599581491.158798 1T11 744 03 24 15 d6 00 00 00 00 V (24885) canlog-monitor: 1599581491.164311 1R11 7AE 03 7f 24 11 ae 74 09 00 D (24885) vehicle: PollerReceive[7AE]: process OBD/UDS error 24(15D6) code=11 READING LOSS VALUE: D (24885) vehicle: PollerSend(0): send [bus=1, type=22, pid=15E1], expecting 744/7ae-7ae V (24885) canlog-monitor: 1599581491.165854 1T11 744 03 22 15 e1 00 00 00 00 V (24895) canlog-monitor: 1599581491.174851 1R11 7AE 04 62 15 e1 00 74 09 00 D (24895) vehicle: PollerReceive[7AE]: process OBD/UDS response 22(15E1) frm=0 len=1 off=0 rem=0 TRY READ SCALING FOR LOSS: D (24895) vehicle: PollerSend(0): send [bus=1, type=24, pid=15E1], expecting 744/7ae-7ae V (24895) canlog-monitor: 1599581491.178916 1T11 744 03 24 15 e1 00 00 00 00 V (24905) canlog-monitor: 1599581491.184240 1R11 7AE 03 7f 24 11 ae 74 09 00 D (24905) vehicle: PollerReceive[7AE]: process OBD/UDS error 24(15E1) code=11 It still says 7F :( Do I do something wrong here? Any suggestions? Thanks Soko

2 2

OBD/UDS Poller receiver rework
by Michael Balzer 08 Sep '20

08 Sep '20

Everyone, I've just pushed the poller receiver changes I announced into the new "poller-rework" branch: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/0b3… OBD/UDS Poller Receiver Rework: - Fix race condition between CAN RX and PollerReceive - Separation of ISO-TP & OBD/UDS layer meta data analysis - Fix incomplete meta data validation - Allow single/multi frame responses on all service types - Validate multi frame response sequences - Fix single frame payload lengths - Fix type 0x22 first frame payload offset & overall length - Add negative response code handling → IncomingPollError() - Add response frame timing control → PollSetResponseSeparationTime() This rework has been on my list for some time before, as the previous solution had some general shortcomings, especially by it's hard coded coupling of the expected response transport form with the request type, which fails already on some type 0x01 requests. The major bug in the receiver that now triggered the rework was in the overall payload length calculation and the first frame payload passing of the type 0x22 (VEHICLE_POLL_TYPE_OBDIIEXTENDED) multi frame response handling. That up to now basically only turned up as a visible issue for the Smart ED, as all other vehicles either don't get multi frame responses on 0x22 queries or (like the Kia) generally discard the first frame and don't use the overall length at all. On the Smart ED, all handlers have been deliberately written assuming the bug was a feature -- all payload addressing is shifted by one byte. This needs to be rewritten now. All other vehicles should not see any difference and should not need to change any code. Except maybe in the UpMiiGo development, which isn't yet part of the master. Other bugs like the missing frame sequence validation and late response detection may have been the causes for some spurious and hard to track crashes and data errors. We should try to get this change tested short term on "edge", so we can see if this actually improves stability as I hope. As this is a major rework (mainly of the PollerReceive() method), audits and tests are very welcome. I can only test on the Twizy, which doesn't make much use of the poller yet. You can see what the new poller does by raising the log level for "vehicle" to debug. Example of some Twizy regular polling: D (136323) vehicle: PollerSend(1): send [type=10, pid=C0], expecting 743/763-763 D (136343) vehicle: PollerReceive[763]: process OBD/UDS response 10(C0) frm=0 len=0 off=0 rem=0 V (136343) v-twizy: OBD2: ignored reply [10 c0] D (137323) vehicle: PollerSend(1): send [type=21, pid=81], expecting 743/763-763 D (137343) vehicle: PollerReceive[763]: process OBD/UDS response 21(81) frm=0 len=4 off=0 rem=15 D (137373) vehicle: PollerReceive[763]: process OBD/UDS response 21(81) frm=1 len=7 off=4 rem=8 D (137403) vehicle: PollerReceive[763]: process OBD/UDS response 21(81) frm=2 len=7 off=11 rem=1 D (137423) vehicle: PollerReceive[763]: process OBD/UDS response 21(81) frm=3 len=1 off=18 rem=0 D (137433) v-twizy: OBD2: got VIN='XXXXXXXXXXXXXXXXX' D (138323) vehicle: PollerSend(1): send [type=21, pid=13], expecting 743/763-763 D (138343) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=0 len=4 off=0 rem=106 D (138373) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=1 len=7 off=4 rem=99 D (138403) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=2 len=7 off=11 rem=92 D (138423) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=3 len=7 off=18 rem=85 D (138453) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=4 len=7 off=25 rem=78 D (138483) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=5 len=7 off=32 rem=71 D (138513) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=6 len=7 off=39 rem=64 D (138543) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=7 len=7 off=46 rem=57 D (138563) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=8 len=7 off=53 rem=50 D (138593) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=9 len=7 off=60 rem=43 D (138623) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=10 len=7 off=67 rem=36 D (138653) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=11 len=7 off=74 rem=29 D (138683) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=12 len=7 off=81 rem=22 D (138703) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=13 len=7 off=88 rem=15 D (138733) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=14 len=7 off=95 rem=8 D (138763) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=15 len=7 off=102 rem=1 D (138793) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=16 len=1 off=109 rem=0 W (141323) v-twizy: OBD2 Cluster DTC NEW #01: 4/21 rev0 G1 INT MEM Ef| @ 57871km 11kph SOC=60% BV=14V TC=0 IC=255 W (141333) v-twizy: OBD2 Cluster DTC NEW #02: 4/1 rev0 G1 MEM| @ 57892km -1kph SOC=86% BV=14V TC=0 IC=255 W (141343) v-twizy: OBD2 Cluster DTC NEW #03: 1/37 rev0 G1 INT MEM Ef| @ 57892km -1kph SOC=86% BV=14V TC=0 IC=255 W (141353) v-twizy: OBD2 Cluster DTC NEW #04: 3/59 rev0 G2 INT MEM| @ 57926km 34kph SOC=78% BV=14V TC=0 IC=255 W (141363) v-twizy: OBD2 Cluster DTC NEW #05: 4/40 rev0 G2 MEM Ef| @ 57926km 35kph SOC=78% BV=14V TC=0 IC=255 W (141373) v-twizy: OBD2 Cluster DTC NEW #06: 3/58 rev0 G2 INT MEM| @ 58711km 41kph SOC=46% BV=14V TC=0 IC=255 A manual multi frame poll: I (147723) webcommand: HttpCommandStream[0x3f8540f4]: 3801804 bytes free, executing: x o r bm 2104 D (148323) vehicle: PollerSend(1): send [type=21, pid=4], expecting 79b/7bb-7bb D (148343) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=0 len=4 off=0 rem=70 D (148353) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=1 len=7 off=4 rem=63 D (148393) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=2 len=7 off=11 rem=56 D (148433) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=3 len=7 off=18 rem=49 D (148473) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=4 len=7 off=25 rem=42 D (148513) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=5 len=7 off=32 rem=35 D (148553) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=6 len=7 off=39 rem=28 D (148593) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=7 len=7 off=46 rem=21 D (148633) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=8 len=7 off=53 rem=14 D (148673) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=9 len=7 off=60 rem=7 D (148713) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=10 len=7 off=67 rem=0 OVMS# x o r bm 2104 Response: 08 cc 3c 08 d4 3c 08 cb 3c 08 d6 3c 08 ce 3c 08 | ..<..<..<..<..<. d1 3c 08 d2 3c ff ff ff ff ff ff ff ff ff ff ff | .<..<........... ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ................ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ................ ff ff ff ff ff ff ff ff 3c 3c | ........<< An example of the new error response handling: I (165023) webcommand: HttpCommandStream[0x3f8479f4]: 3791052 bytes free, executing: x o r bm 221405 D (165323) vehicle: PollerSend(1): send [type=22, pid=1405], expecting 79b/7bb-7bb D (165343) vehicle: PollerReceive[7BB]: process OBD/UDS error 22(1405) code=11 OVMS# x o r bm 221405 ERROR: request failed with response error code 11 Code 11 = "serviceNotSupported" (see ISO 14229 Annex A.1 for more codes) Feedback is welcome. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 15

Re: [Ovmsdev] Issues since latest update (3.2.0.14)
by Derek Caudwell 08 Sep '20

08 Sep '20

Hi, Looking at the differences between 3.2.0.14 and earlier it looks like the use of EV Can rather than CAR Can to enable battery monitoring on the Leaf was the main trigger for frequent event crashes (fixed 31/8 in commit 07f25e3).The polling being turned on (when vehicle ON was set) being more noticeable than at other times as both buses have a lot of traffic - but still not guaranteed to cause a crash as reported by GlynHudson in issue #409. Based on my own experience this issue could still occur randomly but less frequently when the vehicle was off/not polling. The issue would still occur even if enable canwrites were set to off as reported by GlynHudson in #409, as canwrite logic was not implemented in the Leaf code until 19/8 in commit 41ac2f1. A temporary workaround was also implemented in the Leaf code to switch buses prior to polling on 16/8 in commit 32db785. The subsequent poller rework has enabled the Leaf to direct polls to the correct bus, allowing the PID polls originally defined (but not working depending on the car state) to function when the vehicle is on or off and charging. Also the IncomingPollReply code was tidied up and aligned with that used for the Twizy. The vehicle poller extra frame request delay was also originally fixed at 25ms uneccessarily slowing down large replies such as the battery cell voltage responses, now set to 0. These changes mean the polling for the Leaf is now working as it should. The current edge version appears to be stable and allows PID polling reliably to both buses without causing crashes. I have been running it for 24h with 6 start/stop events without issue. If others agree could 3.2.0.15 be staged for EAP release to move Leaf users off 3.2.0.14? A note could be to 3.2.0.14 stating there is a known stability issue on the Leaf and to use 3.2.0.15 or similar. GlynHudson and others on other Leaf models can test to ensure we are back to a stable release with the required polling functionality working. Kind regards Derek

3 5

Re: [Ovmsdev] OvmsMetricVector<string> causing console.log error
by Derek Caudwell 07 Sep '20

07 Sep '20

Thanks Michael, The offending metrics appear to have been in the Nissan Leaf code base for a while now, but do not appear to be used. If they were the issue with them blocking all custom 'xnl' metrics from plugins/web pages should have been picked up by now. Until I (or someone else requiring the vector string functionality) has time to look at extending the metrics code I will comment these out and add a note to the NL code. Cheers Derek

1 0

Re: [Ovmsdev] Highcharts help
by Derek Caudwell 07 Sep '20

07 Sep '20

Thanks Michael, I hadn't realised $('#idreceiver') didn't pass a chart object. As suggested I used 'this' in the chart load to set a variable and then referenced that in the update function. New app works well on a Samsung S10, it is more responsive than the previous one. Cheers

1 0

Re: [Ovmsdev] OvmsDev Digest, Vol 104, Issue 14
by Glyn Hudson 07 Sep '20

07 Sep '20

Hi Michael, Nice work doing the Android release. I've just tested 3.17.1 and it's working fine for me on a pixel 3. I have several vehicles connected on the app and switching between them and viewing map location works fine, just as before. No issues as yet 👍 On Sun, 6 Sep 2020 at 09:03, <ovmsdev-request(a)lists.openvehicles.com> wrote: > Send OvmsDev mailing list submissions to > ovmsdev(a)lists.openvehicles.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openvehicles.com/mailman/listinfo/ovmsdev > or, via email, send a message with subject or body 'help' to > ovmsdev-request(a)lists.openvehicles.com > > You can reach the person managing the list at > ovmsdev-owner(a)lists.openvehicles.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OvmsDev digest..." > > > Today's Topics: > > 1. Android App 3.17.1 (Michael Balzer) > 2. Re: OBD/UDS Poller receiver rework (Chris van der Meijden) > 3. Re: OBD/UDS Poller receiver rework (Michael Balzer) > 4. Re: OBD/UDS Poller receiver rework (Michael Balzer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 6 Sep 2020 09:31:42 +0200 > From: Michael Balzer <dexter(a)expeedo.de> > To: ovmsdev(a)lists.openvehicles.com > Subject: [Ovmsdev] Android App 3.17.1 > Message-ID: <817aeb85-73de-1f8a-c6b9-6840dfcfdbe9(a)expeedo.de> > Content-Type: text/plain; charset=utf-8 > > Everyone using Android, please test the new Android App release: > > > https://github.com/openvehicles/Open-Vehicle-Android/raw/master/release/Ope… > > https://github.com/openvehicles/Open-Vehicle-Android/wiki/History > > This includes migration to the new Android Studio 4 and the new AndroidX > support libraries, so I'd prefer some test feedback before actually > uploading this to the Play store? > > Thanks & regards, > Michael > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > > > > ------------------------------ > > Message: 2 > Date: Sun, 06 Sep 2020 09:39:35 +0200 > From: Chris van der Meijden <chris(a)arachnon.de> > To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> > Subject: Re: [Ovmsdev] OBD/UDS Poller receiver rework > Message-ID: <1599377975.2221.4.camel(a)arachnon.de> > Content-Type: text/plain; charset="utf-8" > > I see some strange behaviour on the T26A e-Up with the new code. I > don't get all values from the bus after a fresh reboot (mostly no VIN, > sometimes also no SOC)). I have to sent a wakeup call first: > I (160137) ovms-server-v2: Send MP-0 > S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,- > 1,0,0,0,0,0,0,0,0.00,0.00,0I (160137) ovms-server-v2: Send MP-0 > D0,0,5,0,0,0,0,0,0,159,0,0,0,0,11.83,0,12.6,0,0,0,0I (160147) ovms- > server-v2: Send MP-0 F3.2.015-42-g2ab8d062/ota_0/main (build idf > v3.3.2-881-g22d636b7b Sep??6 2020 09:04:40),,18,1,VWUP.T26,CWLANI > (169127) webserver: HTTP POST /api/executeI (169147) webcommand: > HttpCommandStream[0x3f852fcc]: 3964692 bytes free, executing: wakeupI > (171147) v-vweup-t26: Sent Wakeup Command - stage 1I (171267) v-vweup- > t26: Sent Wakeup Command - stage 2OVMS# wakeupVehicle has been wokenI > (193527) v-vweup-t26: Comfort CAN calls for sleepI (221137) ovms- > server-v2: Send MP-0 > S100.0,K,0,0,stopped,standard,260,241,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0 > ,-1,0,0,0,0,0,0,0,0.00,0.00,0I (221147) ovms-server-v2: Send MP-0 > D0,0,5,16,0,0,0,36030,0,220,25,0,1,1,11.47,0,12.6,0,0,0,0I (221147) > ovms-server-v2: Send MP-0 F3.2.015-42-g2ab8d062/ota_0/main (build idf > v3.3.2-881-g22d636b7b Sep??6 2020 > 09:04:40),xxxxxxxxxxxxxxxx,18,1,VWUP.T26,CWLAN > I did not change my code and have never seen this before. Perhaps a > problem with the new polling code? > Regards > Chris >

1 0