- OvmsDev - Open Vehicles

Coding help
by Shane ＠ Kilve Engineering 05 Apr '21

05 Apr '21

can any one help me with a bit of code to retrieve ve some data from ecu can1/6f2 00 4c 00 00 01 97 bc 00 as i cant poll this ecu it just broadcasts when its active, ive tried polling it but does not respond, i need to choose one byte and allocate it to a PID.

3 22

List of MQTT commands for Leaf
by Pedro Pinheiro 04 Apr '21

04 Apr '21

Hello to all, thank you for accepting me into the list. I have developed a Node-RED/Mosquitto system to allow us to interact with our cars, chargers, energy meters, to allow me to limit the SoC to a certain percentage, change the wallbox available power dynamically depending on how much power the rest of house installation is drawing, programmed charging, and to start/stop charging. I’m now adding functions to start/stop the remote climate control (done), and now I’m trying to lock/unlock the doors via my system. I have looked far and wide, I have tried to find it in the source code, but I cannot find if I can find if I can publish to a MQTT topic to lock/unlock the doors of a Leaf. If anyone could point me in the right direction, I would be very grateful. Warm regards, and thank you for all the work you have put into the project! Pedro Pinheiro

1 0

Re: [Ovmsdev] Coding help
by henrik.scheel＠spjeldager.dk 04 Apr '21

04 Apr '21

2 1

ESP32 CAN controller hardware bug / interrupt issue
by Michael Balzer 03 Apr '21

03 Apr '21

Second finding & commit: TL;DR: * ESP32 CAN controller is broken, delivers trashed & duplicated RX frames * we need to optimize interrupt latency Users have been reporting occasional false BMS readings on the Twizy for more than a year. The error always trashed the reading of voltage #10 and/or temperature #8, so I initially thought that must be a variant of the SPIRAM/cache bug. But the SPIRAM fix didn't help, and the bug still occured with all BMS data in internal RAM. The issue correlated with high load situations and the SIMCOM UART issue. On testing the latest changes by Marko, my car module began showing that issue regularly, so I could take a closer look. It turned out the wrong data came from the CAN bus. Checking with a CAN logger didn't show any wrong data on the bus. So I scanned our CAN driver for potential issues, found & solved some (even a serious race condition) but that didn't fix it. I then added debug dumps of all frames read, dug into the SJA1000 spec sheet and found this: The SJA1000 RX FIFO has a capacity of 64 bytes. It's supposed to work as a ring buffer, with frames wrapping around as necessary. If no space is left in the FIFO for a new frame coming in, that frame should be discarded completely, not counted, just the overflow indicator should be set & the according interrupt be generated. Reality differs. The frame causing the overflow is added to the FIFO partially. It's also counted both in the RMC register and indicated by RBS as a valid frame when retrieving the FIFO contents. The read buffer delivers the partial frame + some trashed bytes up to the nominal frame length. In the BMS frame sequence it would normally trash bytes 7 & 8 on the sixth frame of length 8 in a sequence. A standard frame needs a 3 byte header + the data bytes in the FIFO, so 6 frames would add up to 66 bytes => 64 + 2 trash. The first trash byte normally is "08", the second "84" or "2a" or sometimes "ab", possibly some internal SJA1000 data. Better yet, if you rely on the indicators of the SJA1000 when reading the FIFO, the SJA1000 will repeat the first frame within the FIFO after the invalid frame. Mostly once or twice, and sometimes 7 times or more: inv_msg: framecnt=13, invindex=6 inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 24 04 00 00 11 40 10 22 37 55 00 37 | 4..?........$....@."7U.7 inv_msg: 25 04 00 00 0a 1b 44 ff fe 4e 01 26 | 4..?........%.....D..N.& inv_msg: 54 05 00 00 37 37 37 37 37 37 37 00 | 4..?........T...7777777. inv_msg: 56 05 00 00 31 63 14 31 53 14 31 4a | 4..?........V...1c.1S.1J inv_msg: 57 05 00 00 31 43 14 31 53 15 *08 2a* | 4..?........W...1C.1S..* ^^^^^ trashed bytes … followed by 7 repetitions of the first frame: inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n If you had occasional strange false readings leading to strange effects, this may be the explanation. Note: the SJA1000 FIFO bug may need specific circumstance to occur in addition to the overflow, maybe the overflow happening on a specific byte position in the FIFO -- I haven't tried to determine that. I've tried clearing the overflow ASAP, looping on the IR indicator and looping on the RMC, the fault is always the same. The workaround I've now done is adding up the message lengths read during a FIFO run and discard all frames exceeding the 64 byte border. Not pretty, but functional. That keeps the trashed frames from being forwarded to the OVMS application level. As with the SIMCOM UART, these overflows wouldn't happen if the interrupt handler would react fast enough. It seems we've got a general interrupt latency issue. And just as with the SIMCOM I saw a reduction of overflows when allocating the CAN IRQ on core #0, another one with raising the IRQ level to 3, so that's also part of my commit. The esp-idf CAN driver apparently has the same issue even in the latest release, I'll contact the author about this or post another issue to Espressif. So our interrupt allocation is now: Task Run# Lvl ISR# Usage Source ---------------------------------------------------------------------------------------- - 0 1 0 RTC Core ETS_RTC_CORE_INTR_SOURCE esp_timer 0 1 0 RTOS esp_timer ETS_TIMER2_INTR_SOURCE ipc0 0 1 0 RTOS Scheduler Core0 ETS_FROM_CPU_INTR0_SOURCE ipc1 1 1 1 RTOS Scheduler Core1 ETS_FROM_CPU_INTR1_SOURCE main 0 1 0 RTOS Watchdog ETS_TG0_WDT_LEVEL_INTR_SOURCE OVMS Events 1 1 1 Peripherals (GPIO ISR) ETS_GPIO_INTR_SOURCE OVMS Events 1 1 1 MAX7317 (spi_nodma) ETS_SPI3_INTR_SOURCE *esp32can init 0 3 0 ESP32 CAN ETS_CAN_INTR_SOURCE** **OVMS SIMCOM 0 2 0 SIMCOM UART ETS_UART1_INTR_SOURCE* OVMS Events 1 1 1 USB console (UART) ETS_UART0_INTR_SOURCE OVMS Events 1 1 1 SD card ETS_SDIO_HOST_INTR_SOURCE ---------------------------------------------------------------------------------------- I think we need to find the source of the interrupt latency and/or find some better scheme to distribute the tasks & interrupts over the cores. I still don't know why core #1 already got an issue with just our 6 interrupts. This may be related to the SPIRAM fix adding overhead, but I've seen the FIFO overflows before applying the fix, and the CAN issue also has been present for over a year. My working hypothesis is some task/driver disabling interrupts for too often / too long, or non-IRAM ISRs getting delayed for too often / too long. And it seems this is an issue especially on core #1. Please verify & comment. Regards, Michael PS: a little side mystery: the netmanager task starts with priority 5, then gets raised to 22 (probably a mutex priority inheritance), but never gets lowered back to 5 afterwards. A FreeRTOS bug? -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 11

Multi frame query
by didier＠ernotte.com 02 Apr '21

02 Apr '21

Hi, I am investigating some PID with very long data. I am using the PID scanner for this.When I turn on the log level debug , I can see this as the first repy D (1456677) obd2ecu: Rcv 7ec: 8 (15 df 62 48 83 0 0 0) >From the Canbus doc, I understand that the first "1x (15)" tells me that this is the first frame of a multi frame, and the length is "5df" . The Pid scanner seems to return only "df", not "5df" data, and I can see in the log that I have around 1500 byte returned, not 220. Any explanation ? anyone see this problem as well ? The scan command is (I had to hack the code to allow timeout > 10sec) re obdii scan start 1 7e4 4883 4883 -r500-7ff -t22 -x30 Didier

5 16

Need some git school
by Stephen Casner 30 Mar '21

30 Mar '21

I haven't gotten any traction on my request for people to test the updated mongoose-wolfssl branch, so I thought it might help to rebase to the current master. I did that without complaint in my local repository, but I can't push that back to github: auge92> git push To github.com:openvehicles/Open-Vehicle-Monitoring-System-3.git ! [rejected] mongoose-wolfssl -> mongoose-wolfssl (non-fast-forward) error: failed to push some refs to 'github.com:openvehicles/Open-Vehicle-Monitoring-System-3.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. I have all the same changes on my local repo as on github, but I observe that all the commits I made since branching (beginning with 04fafb83a3cc5563a5feb70a4bb7922457d58893) have a different commit id than what is in my local mongoose-wolfssl repo for the same changes. This is what causes the complaint above. I must have done something wrong back at the beginning of working on this branch. Any idea what I might have done? Would this be an appropriate scenario to use "git push --force" to correct the problem? -- Steve

3 20

New vehicle: Hyundai Ioniq vFL
by Michael Balzer 25 Mar '21

25 Mar '21

Everyone, by request of Henri Bachmann on the german GoingElectric forum, I've added the Hyundai Ioniq vFL (28 kWh). The implementation is based on the reverse engineering data published by the EVNotify project: https://github.com/EVNotify/EVNotiPi/blob/master/car/ioniq_bev.py Module Documentation: https://docs.openvehicles.com/en/latest/components/vehicle_hyundai_ioniqvfl… Henri has tested the module, but more tests from other Ioniq drivers are welcome. One of the PIDs needs more data/logs: the "driveMotorSpeed" didn't match the actual speed on Henri's tests. That PID isn't used by the EVNotify system so may be wrong, or could be RPM. If you can help with logs on this, enable file logging and do a test drive with level verbose on module v-hyundaivfl. Try to maintain a fixed maximum speed for 20 seconds for reference. Send me the logs and the max speed. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 2

Defective voltage regulator
by Chris van der Meijden 24 Mar '21

24 Mar '21

Hi all Yesterday I got my new OVMS from Fasttech for my new VW e-Golf project. All very well, but it won't boot from 12v DB9. 5v USB boots. In the WebUI->Status it shows always 3.2v as 12v voltage value. We believe the voltage regulator is faulty. I wrote Fasttech and they responded that I should contact the manufacturer "openvehicles" for warranty ??? Does anyone here have experience in warranty replacement of the OVMS? Who do I have to contact? How is the process of replacement? Thanx for help in advance. Regards Chris

2 2

3.2.016 released to EAP
by Michael Balzer 16 Mar '21

16 Mar '21

Everyone, I've just tagged the 3.2.016 release, uploaded it to my "eap" directory and published the info on my site. * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases/t… <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases/t…> * https://dexters-web.de/firmware-release-3.2.016-text_98.en.htm <https://dexters-web.de/firmware-release-3.2.016-text_98.en.htm> Mark, I suggest you do the same on openvehicles.com. If no issues turn up, we should aim at the "main" release in about 1-2 weeks. _Summary of changes:_ - New vehicle: VW e-Up via OBD-II Port (VWUP.OBD) - New vehicle: MG ZS EV via OBD-II Port (MGEV) - New vehicle: BMW i3/i3s via OBD-II Port (BMWI3) - VW e-Up: combined T26A & OBD module, extended standard metrics coverage, charge notifications & durations (OBD), enhanced cabin pre-heating (T26) - VW e-UP T26A: add climate control and charging detection - VW e-Up: BMS cell monitoring (@OBD) - VW e-Up: CCS (DC) charge detection & data New metrics: xvu.c.ccs.u -- CCS charger supplied voltage [V] xvu.c.ccs.i -- CCS Charger supplied current [A] xvu.c.ccs.p -- CCS Charger supplied power [kW] - VW e-Up: replaced MFD range based CAC/SOH by charge coulomb count based Removed metrics: xvu.b.cap.range xvu.b.cap.chg.ah.norm xvu.b.cap.chg.ah.norm xvu.b.cap.chg.kwh.norm xvu.b.cap.chg.kwh.abs New metrics: xvu.b.energy.range -- MFD range estimation energy [kWh] xvu.b.cap.kwh.range -- … usable battery capacity derived [kWh] xvu.b.cap.ah.abs -- Charge coulomb based capacity [Ah] xvu.b.cap.ah.norm -- … normalized (usable) [Ah] xvu.b.cap.kwh.abs -- Charge energy based capacity [kWh] xvu.b.cap.kwh.norm -- … normalized (usable) [kWh] - MG ZS EV: Add Charging Metrics page. - MG ZS EV: Add support for ms_v_charge_kwh, ms_v_bat_energy_used and ms_v_bat_coulomb_used metrics - Volt/Ampera: BMS cell monitoring (CAN1 polling), fast CAN polling when waking up, estimated range gets from CAN instead of calculation, lock/unlock status processing fixed for Volt 14MY; New standard metrics: trip (this charge), energy used (this charge), HV battery capacity (CAC, Ah), transmission temp, doors, trunk, hood, lightings; - Volt/Ampera: new xva metrics: xva.v.p.trip.ev = trip using electric, km; xva.v.e.fuel = fuel tank level, %; - Renault Twizy: new metrics to reflect extended lock & valet modes: xrt.v.e.locked.speed -- Speed limit [kph] set for Twizy lock mode xrt.v.e.valet.odo -- Odometer limit [km] set for Twizy valet mode - Renault Twizy: support additional OBD/UDS request types & arguments on "xrt obd request" - ZOE: BMS cell monitoring (PH1) - SmartED: add Drivmode for Brabus - Nissan Leaf: invert batt current sign to match standard metrics definition, populate charger power/efficiency - Vehicle framework: generic single OBD2/UDS request shell command & API call New commands: obdii can[1-4] request device [-t<timeout_ms>] [-e] txid rxid request obdii can[1-4] request broadcast [-t<timeout_ms>] request - BMS: optional cell voltage & temperature logging New configs: [vehicle] bms.log.voltage.interval Interval [s] for cell voltage logging, default 0=disable [vehicle] bms.log.temp.interval Interval [s] for cell temperature logging, default 0=disable - BMS: detection of inconsistent voltage series by gradient & stddev average deviation thresholds, added pack metrics to battery monitor web UI, change cell warning & alert thresholds to be applied exceeding stddev level New metrics: v.b.p.voltage.grad Cell voltage - gradient of current series [V] New configs: [vehicle] bms.dev.voltage.maxgrad Max gradient for a valid series [vehicle] bms.dev.voltage.maxsddev Max stddev deviation from average for valid series - Notifications: added optional long term trip & grid (charge/generator session) server logs. See https://docs.openvehicles.com/en/latest/userguide/notifications.html for details. New configs: [notify] log.trip.storetime Trip log storage time in days, 0/empty = off (default) [notify] log.trip.minlength … minimum trip length in km, default 0.2 km [notify] log.grid.storetime Grid log storage time in days, 0/empty = off (default) - Metrics: extended reboot persistence: most vehicle state and long term counter metrics will now retain their values over a reboot (e.g. OTA update) - Metrics: new standard metrics for grid integration (V2G) / generator role New standard metrics: v.c.kwh.grid Energy drawn from grid during running session v.c.kwh.grid.total Energy drawn from grid total (life time) v.g.generating True = currently delivering power v.g.climit Maximum generator input current (from battery) v.g.current Momentary generator input current (from battery) v.g.duration.empty Estimated time remaining for full discharge v.g.duration.range … for range limit v.g.duration.soc … for SOC limit v.g.efficiency Momentary generator efficiency v.g.kwh Energy sum generated in the running session v.g.kwh.grid Energy sent to grid during running session v.g.kwh.grid.total Energy sent to grid total v.g.limit.range Minimum range limit for generator mode v.g.limit.soc Minimum SOC limit for generator mode v.g.mode Generator mode (TBD) v.g.pilot Pilot signal present v.g.power Momentary generator output power v.g.state Generator state (TBD) v.g.substate Generator substate (TBD) v.g.temp Generator temperature v.g.time Duration of generator running v.g.timermode True if generator timer enabled v.g.timerstart Time generator is due to start v.g.type Connection type (chademo, ccs, …) v.g.voltage Momentary generator output voltage - TPMS: metrics rework & standard alert notifications on new v.t.alert metric. Replaced metrics… v.tp.fl.p TPMS front left pressure v.tp.fl.t TPMS front left temperature v.tp.fr.p TPMS front right pressure v.tp.fr.t TPMS front right temperature v.tp.rl.p TPMS rear left pressure v.tp.rl.t TPMS rear left temperature v.tp.rr.p TPMS rear right pressure v.tp.rr.t TPMS rear right temperature …by… v.t.pressure TPMS tyre pressures vector (fl,fr,rl,rr) v.t.temp TPMS tyre temperatures vector New standard metrics: v.t.alert TPMS tyre alert levels [0=normal, 1=warning, 2=alert] v.t.health TPMS tyre health states - New standard metrics for total (life time) energy and coulomb - Events: added automatic events on v.e.aux12v changes. New events: vehicle.aux.12v.on vehicle.aux.12v.off - Location: add metric for name of current location New metrics: v.p.location -- Name of current location if defined - Server V3 improvements: a) On first connection to MQTT broker we used to send all metrics. Now we only send metrics for which we have a value. b) New config settings: "updatetime.on" which sets updatetime when the car is on (driving) "updatetime.charging" which sets updatetime when the car is charging "updatetime.awake" which sets updatetime when the car is awake If unset the server uses the "idle" or "connected" interval as before c) New config setting "updatetime.sendall". If you set this we will publish _all_ valid metrics at this interval. Helpful to keep a steady flow of values for charting. PLEASE NOTE: These settings will increase OVMS' data usage. - Wifi: option to immediately disconnect/reconnect on bad signal level New config: [network] wifi.bad.reconnect [bool], default no - WiFi: replace fixed scan times by config instances New configs: [network] wifi.scan.tmin Min scan time per channel [ms], default 120 ms [network] wifi.scan.tmax Max scan time per channel [ms], default 120 ms - Updated wolfssh and wolfssl so the restriction of clients to use aes128-cbc cipher is no longer required. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 4

External Wifi antenna
by Michael Balzer 15 Mar '21

15 Mar '21

Some info for those in need of a better Wifi signal than achievable with the builtin ESP32-WROVER antenna: A friend of mine on the german Twizy forum had severe signal issues, using an external router antenna he saw an improvement of ~10 dB. Basics: - https://www.esp32.com/viewtopic.php?t=1635 …view on the OVMS module: Here's a video by him on the topic (in German, try automatic translation) – but sadly not showing the actual soldering process, more the afterworks: https://www.youtube.com/watch?v=4Uv71HiBPpg Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 22