- OvmsDev - Open Vehicles

*.openvehicles.com scheduled maintainance
by Mark Webb-Johnson 18 Sep '20

18 Sep '20

We are planning to migrate the *.openvehicles.com <http://openvehicles.com/> server to a new data centre this Friday (18th Sep 2020). We’re going to take this opportunity to also update the core OS it is running on to the latest long-term support release. This will impact: Mailing lists eMail api.openvehicles.com <http://api.openvehicles.com/> server v2, for both apps and vehicles api.openvehicles.com <http://api.openvehicles.com/> server v3 (MQTT), for both apps and vehicles Push notifications www.openvehicles.com <http://www.openvehicles.com/> website IP address (202.52.42.188 => 175.45.17.222) We will try to minimise the time taken and downtime for each step of the migration, but there will be some impact (at least during DNS changeover) - usually less than an hour. The expected work time window is between 03:00 and 08:00 UTC. Regards, Mark.

2 3

Fwd: Peter.h started a conversation with you: "OVMS doc - Scripting for OBDII ECU"
by Mark Webb-Johnson 17 Sep '20

17 Sep '20

I got this feedback today from one of our users, and thought it worthwhile to share. Good to see this facility getting some use. Regards, Mark. P.S. I have made the documentation change he pointed out. > OVMS doc - Scripting for OBDII ECU <http://email.teslamotorsclub.com/c/eJxtTkFuxCAQe01yIwISyHLgsJf-YxgmDW1gVkC2…> > > > I finally got around to playing a bit with the OBDII ECU scripting facility - it's a great tool. > > I came across a minor error in the doc that had me tripped up for a while and I hope you could channel this to the right person to get it updated. > > I am referring to the Google doc "OVMS v3 Advanced User Guide" > > In the "Metrics scripts" section is the following example: > ret1=OvmsMetricFloat("v.p.speed"); > ret2=OvmsMetricFloat("v.b.power"); > out=0.0; > if (ret1 > 0) { out=ret2/ret1; } > out; > This fails since OvmsMetricFloat is undefined - it should say "OvmsMetrics.AsFloat" in the first two rows. > > I managed to get my Pioneer NEX radio to show a speedometer on the home screen at last - it turns out it can only show a subset of gauges on the home screen, and the speedometer is not one of them (it offers a tach and MAF). the MAF can be tweaked to show the correct range: by setting it to metric (g/s) the range can be adjusted to 0-120. Somehow I need to multiply v.p.speed by 1.6 to get the correct mph output (which doesn't make sense to me) and then divide it by 2.56 since the OBDII ECU only sends the hibyte of the MAF response, and this is parsed as (256 * A + B)/100. > > Thank you again for all the help (and the great work on OVMS!),

2 2

VW e-Up images for iOS app
by Chris van der Meijden 14 Sep '20

14 Sep '20

Hi Mark I just did a pull request on the iOS app. I integrated the e-Up images. I compiled the app with Xcode 8.1, so I needed to correct the Storyboards. Compiled without any problems. You can find a screenshot of the simulator here: https://www.goingelectric.de/forum/viewtopic.php?p=1355192#p1355192 I'm not "that" firm on iOS development, so I hope the pull request is OK. Any corrections are welcome. Greetinx Chris

2 2

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 10 Sep '20

10 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 10 Sep '20

10 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 08 Sep '20

08 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 07 Sep '20

07 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