Hi,
It's happened again. Yesterday while driving the Leaf lost drive mode, forcing pulling over. I couldn't reengage gear until I had disconnected the 12v battery.
Looking at the evidence today, the incident can't be explained by writing random bytes in CommandWakeup(), nor by having the wrong timing. It actually suggests that OVMS locked up ten minutes before the car was impacted.
Here's what happened.
13:15 to 13:17 I drove off from home, but forgot an item so quickly returned back there.
The sd log records this activity just fine, and the last entries before the suspected hang were these:
2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432)
There should have been the next housekeeping message at 13:27:29 but none was recorded on the sd. Log flushes are configured to occur after 30 seconds.
The last MQTT metric update my server received was around 13:27:50. This showed it was connected to home wifi.
At 13:28 I unlocked the car, started it and drove off without noticing anything unusual. None of this activity appears in the log.
During the drive there should have been a connection via Hologram to my server, but none was received.
Ten minutes later at 13:38 I was driving when a yellow warning light came on and the car moved to neutral. Essentially the same symptoms as in January: turning off and on would not clear the fault; it couldn't detect brake status meaning it told me to press brake pedal when I already was. Also showed I-key system error.
As I was stranded I used the only option I knew of to clear the fault, and I disconnected the 12v battery. On restoring power and dismissing the fault notice, it was happy to drive.
The log shows this cold start SNTP was at 13:44. On returning home, unfortunately 'boot status' says nothing about a crash, presumably because any information was lost when I pulled power.
So it seems there is some mechanism by which OVMS can lock up, without watchdog oversight. And that ten minutes later it can do something that becomes a critical issue for the car systems.
Chris
Relevant log entries below, all part of the same file. 1970 follows immediately after 13:22:29.184.
2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: Queue SetState() 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: PollState(0) 2025-02-07 13:17:50.184 GMT D (93622984) events: Signal(vehicle.off) 2025-02-07 13:17:51.144 GMT D (93623944) events: Signal(vehicle.aux.12v.charging.dip) 2025-02-07 13:17:53.144 GMT D (93625944) events: Signal(vehicle.aux.12v.dip) 2025-02-07 13:17:54.824 GMT E (93627624) can: can2: intr=15711227 rxpkt=15730955 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:17:56.754 GMT D (93629554) events: Signal(vehicle.locked) 2025-02-07 13:17:59.744 GMT E (93632544) can: can2: intr=15716706 rxpkt=15736447 txpkt=100 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:09.144 GMT D (93641944) events: Signal(vehicle.charge.12v.stop) 2025-02-07 13:18:10.144 GMT I (93642944) powermgmt: No longer charging 12V battery.. 2025-02-07 13:18:33.174 GMT D (93665944) events: Signal(vehicle.aux.12v.normal) 2025-02-07 13:18:33.764 GMT E (93666534) can: can2: intr=15754521 rxpkt=15774368 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Connection is <redacted> 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Status: Connecting... 2025-02-07 13:18:45.224 GMT D (93677994) events: Signal(server.v3.connecting) 2025-02-07 13:18:48.624 GMT I (93681394) ovms-server-v3: Connection successful 2025-02-07 13:18:48.644 GMT I (93681414) ovms-server-v3: Status: OVMS V3 MQTT login successful 2025-02-07 13:18:48.644 GMT D (93681414) events: Signal(server.v3.connected) 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Subscribe to MQTT topics 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Transmit all metrics 2025-02-07 13:18:49.464 GMT I (93682234) ovms-server-v3: Subscription acknowledged 2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432) 1970-01-01 00:00:08.424 GMT I (7994) command: OpenLogfile: now logging to file '/sd/logs/log' 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.event) 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:19.424 GMT I (18984) cellular: State: Enter Identify state 1970-01-01 00:00:19.434 GMT I (18994) cellular: Identified cellular modem: SIM7600/Experimental support for SIMCOM SIM7600 1970-01-01 00:00:19.434 GMT I (18994) cellular: Set modem driver to 'SIM7600' 1970-01-01 00:00:19.434 GMT I (18994) cellular: State: Enter PoweredOn state 1970-01-01 00:00:19.424 GMT D (18994) events: Signal(system.modem.installed) 1970-01-01 00:00:19.434 GMT D (19004) events: Signal(system.modem.poweredon) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.event) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.event) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:39.434 GMT I (38994) cellular: State: Enter MuxStart state 1970-01-01 00:00:39.444 GMT I (39004) gsm-mux: Start MUX 1970-01-01 00:00:39.444 GMT D (39004) events: Signal(system.modem.muxstart) 1970-01-01 00:00:39.444 GMT I (39014) gsm-mux: Channel #0 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #1 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #2 is open 1970-01-01 00:00:39.474 GMT I (39034) gsm-mux: Channel #3 is open 1970-01-01 00:00:39.484 GMT I (39044) gsm-mux: Channel #4 is open 1970-01-01 00:00:40.414 GMT I (39984) cellular: State: Enter NetWait state 1970-01-01 00:00:40.414 GMT D (39984) events: Signal(system.modem.netwait) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.event) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:46.054 GMT D (45624) events: Signal(vehicle.awake) 1970-01-01 00:00:50.444 GMT I (50014) cellular: Network Registration status: RegisteredRoaming 1970-01-01 00:00:51.414 GMT I (50984) cellular: State: Enter NetStart state 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(vehicle.aux.12v.blip) 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(system.modem.netstart) 1970-01-01 00:00:51.444 GMT D (51004) events: Signal(vehicle.charge.12v.start) 1970-01-01 00:00:51.434 GMT I (51004) cellular: Network Mode: LTE,Online 1970-01-01 00:00:52.414 GMT I (51984) powermgmt: Charging 12V battery.. 1970-01-01 00:00:52.464 GMT I (52034) cellular: PPP Connection is ready to start 1970-01-01 00:00:53.424 GMT I (52984) cellular: State: Enter NetMode state 1970-01-01 00:00:53.424 GMT I (52984) gsm-ppp: Initialising... 1970-01-01 00:00:53.434 GMT D (52994) events: Signal(system.modem.netmode) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.event) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: StatusCallBack: None 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: status_cb: Connected 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our_ipaddr = 100.83.212.151 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: his_ipaddr = 10.64.64.64 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: netmask = 255.255.255.255 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: DNS#0 = 8.8.8.8 1970-01-01 00:00:53.584 GMT I (53154) gsm-ppp: DNS#1 = 8.8.4.4 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our6_ipaddr = :: 1970-01-01 00:00:53.594 GMT D (53154) events: Signal(network.interface.up) 1970-01-01 00:00:53.604 GMT D (53164) events: Signal(system.modem.gotip) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Interface priority is pp2 (100.83.212.151/255.255.255.255 gateway 10.64.64.64) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Set DNS#2 0.0.0.0 1970-01-01 00:00:53.594 GMT I (53164) netmanager: MODEM up (with WIFI client down): starting network with MODEM 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.modem.up) 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.up) 1970-01-01 00:00:53.604 GMT I (53174) time: Starting SNTP client 1970-01-01 00:00:53.604 GMT D (53174) events: Signal(network.interface.change) 1970-01-01 00:00:53.614 GMT D (53174) events: Signal(network.mgr.init) 1970-01-01 00:00:53.614 GMT I (53174) webserver: Launching Web Server 2025-02-07 13:44:08.584 GMT I (53184) webserver: Binding to port 80 (http) 2025-02-07 13:44:08.584 GMT I (53184) ssh: Launching SSH Server
Hi Chris,
Not sure if you’ve investigated the I-key system error , but thought I’d add my experience here. I have been receiving the same I-key system error in my 2012 leaf, with all the same symptoms and resolution as yours. This leaf doesn’t have OVMS installed at the moment, so maybe your issue is not due to OVMS. If you google I-key system error , you’ll find posts on issues with the BCM, which have been resolved with cleaning contacts on bcm (if there’s been moisture issues), and others replacing 12v acc battery. I’m pretty sure I’ve narrowed it down to 12v battery issues in my case, after inspecting BCM behind glove box in RHD edition, finding no issue, recharging 12v, and removing any known 12v drain like OVMS or odb dongle, just waiting for a recurrence to confirm. Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it. The OVMS log also shows 12v dip around the same time as your issue. This may explain OVMS shutdown as well if you’ve got it set to shut down due to low 12v battery, although I though that might be more graceful.
Cheers Dan
On 9 Feb 2025, at 8:35 am, Chris Box via OvmsDev <ovmsdev@lists.openvehicles.com> wrote:
Hi,
It's happened again. Yesterday while driving the Leaf lost drive mode, forcing pulling over. I couldn't reengage gear until I had disconnected the 12v battery.
Looking at the evidence today, the incident can't be explained by writing random bytes in CommandWakeup(), nor by having the wrong timing. It actually suggests that OVMS locked up ten minutes before the car was impacted.
Here's what happened.
13:15 to 13:17 I drove off from home, but forgot an item so quickly returned back there.
The sd log records this activity just fine, and the last entries before the suspected hang were these:
2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432)
There should have been the next housekeeping message at 13:27:29 but none was recorded on the sd. Log flushes are configured to occur after 30 seconds.
The last MQTT metric update my server received was around 13:27:50. This showed it was connected to home wifi.
At 13:28 I unlocked the car, started it and drove off without noticing anything unusual. None of this activity appears in the log.
During the drive there should have been a connection via Hologram to my server, but none was received.
Ten minutes later at 13:38 I was driving when a yellow warning light came on and the car moved to neutral. Essentially the same symptoms as in January: turning off and on would not clear the fault; it couldn't detect brake status meaning it told me to press brake pedal when I already was. Also showed I-key system error.
As I was stranded I used the only option I knew of to clear the fault, and I disconnected the 12v battery. On restoring power and dismissing the fault notice, it was happy to drive.
The log shows this cold start SNTP was at 13:44. On returning home, unfortunately 'boot status' says nothing about a crash, presumably because any information was lost when I pulled power.
So it seems there is some mechanism by which OVMS can lock up, without watchdog oversight. And that ten minutes later it can do something that becomes a critical issue for the car systems.
Chris
Relevant log entries below, all part of the same file. 1970 follows immediately after 13:22:29.184.
2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: Queue SetState() 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: PollState(0) 2025-02-07 13:17:50.184 GMT D (93622984) events: Signal(vehicle.off) 2025-02-07 13:17:51.144 GMT D (93623944) events: Signal(vehicle.aux.12v.charging.dip) 2025-02-07 13:17:53.144 GMT D (93625944) events: Signal(vehicle.aux.12v.dip) 2025-02-07 13:17:54.824 GMT E (93627624) can: can2: intr=15711227 rxpkt=15730955 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:17:56.754 GMT D (93629554) events: Signal(vehicle.locked) 2025-02-07 13:17:59.744 GMT E (93632544) can: can2: intr=15716706 rxpkt=15736447 txpkt=100 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:09.144 GMT D (93641944) events: Signal(vehicle.charge.12v.stop) 2025-02-07 13:18:10.144 GMT I (93642944) powermgmt: No longer charging 12V battery.. 2025-02-07 13:18:33.174 GMT D (93665944) events: Signal(vehicle.aux.12v.normal) 2025-02-07 13:18:33.764 GMT E (93666534) can: can2: intr=15754521 rxpkt=15774368 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Connection is <redacted> 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Status: Connecting... 2025-02-07 13:18:45.224 GMT D (93677994) events: Signal(server.v3.connecting) 2025-02-07 13:18:48.624 GMT I (93681394) ovms-server-v3: Connection successful 2025-02-07 13:18:48.644 GMT I (93681414) ovms-server-v3: Status: OVMS V3 MQTT login successful 2025-02-07 13:18:48.644 GMT D (93681414) events: Signal(server.v3.connected) 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Subscribe to MQTT topics 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Transmit all metrics 2025-02-07 13:18:49.464 GMT I (93682234) ovms-server-v3: Subscription acknowledged 2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432) 1970-01-01 00:00:08.424 GMT I (7994) command: OpenLogfile: now logging to file '/sd/logs/log' 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.event) 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:19.424 GMT I (18984) cellular: State: Enter Identify state 1970-01-01 00:00:19.434 GMT I (18994) cellular: Identified cellular modem: SIM7600/Experimental support for SIMCOM SIM7600 1970-01-01 00:00:19.434 GMT I (18994) cellular: Set modem driver to 'SIM7600' 1970-01-01 00:00:19.434 GMT I (18994) cellular: State: Enter PoweredOn state 1970-01-01 00:00:19.424 GMT D (18994) events: Signal(system.modem.installed) 1970-01-01 00:00:19.434 GMT D (19004) events: Signal(system.modem.poweredon) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.event) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.event) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:39.434 GMT I (38994) cellular: State: Enter MuxStart state 1970-01-01 00:00:39.444 GMT I (39004) gsm-mux: Start MUX 1970-01-01 00:00:39.444 GMT D (39004) events: Signal(system.modem.muxstart) 1970-01-01 00:00:39.444 GMT I (39014) gsm-mux: Channel #0 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #1 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #2 is open 1970-01-01 00:00:39.474 GMT I (39034) gsm-mux: Channel #3 is open 1970-01-01 00:00:39.484 GMT I (39044) gsm-mux: Channel #4 is open 1970-01-01 00:00:40.414 GMT I (39984) cellular: State: Enter NetWait state 1970-01-01 00:00:40.414 GMT D (39984) events: Signal(system.modem.netwait) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.event) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:46.054 GMT D (45624) events: Signal(vehicle.awake) 1970-01-01 00:00:50.444 GMT I (50014) cellular: Network Registration status: RegisteredRoaming 1970-01-01 00:00:51.414 GMT I (50984) cellular: State: Enter NetStart state 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(vehicle.aux.12v.blip) 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(system.modem.netstart) 1970-01-01 00:00:51.444 GMT D (51004) events: Signal(vehicle.charge.12v.start) 1970-01-01 00:00:51.434 GMT I (51004) cellular: Network Mode: LTE,Online 1970-01-01 00:00:52.414 GMT I (51984) powermgmt: Charging 12V battery.. 1970-01-01 00:00:52.464 GMT I (52034) cellular: PPP Connection is ready to start 1970-01-01 00:00:53.424 GMT I (52984) cellular: State: Enter NetMode state 1970-01-01 00:00:53.424 GMT I (52984) gsm-ppp: Initialising... 1970-01-01 00:00:53.434 GMT D (52994) events: Signal(system.modem.netmode) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.event) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: StatusCallBack: None 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: status_cb: Connected 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our_ipaddr = 100.83.212.151 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: his_ipaddr = 10.64.64.64 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: netmask = 255.255.255.255 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: DNS#0 = 8.8.8.8 1970-01-01 00:00:53.584 GMT I (53154) gsm-ppp: DNS#1 = 8.8.4.4 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our6_ipaddr = :: 1970-01-01 00:00:53.594 GMT D (53154) events: Signal(network.interface.up) 1970-01-01 00:00:53.604 GMT D (53164) events: Signal(system.modem.gotip) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Interface priority is pp2 (100.83.212.151/255.255.255.255 gateway 10.64.64.64) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Set DNS#2 0.0.0.0 1970-01-01 00:00:53.594 GMT I (53164) netmanager: MODEM up (with WIFI client down): starting network with MODEM 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.modem.up) 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.up) 1970-01-01 00:00:53.604 GMT I (53174) time: Starting SNTP client 1970-01-01 00:00:53.604 GMT D (53174) events: Signal(network.interface.change) 1970-01-01 00:00:53.614 GMT D (53174) events: Signal(network.mgr.init) 1970-01-01 00:00:53.614 GMT I (53174) webserver: Launching Web Server 2025-02-07 13:44:08.584 GMT I (53184) webserver: Binding to port 80 (http) 2025-02-07 13:44:08.584 GMT I (53184) ssh: Launching SSH Server
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Just fyi a 'dip' is 12v voltage decreasing momentarily. A blip is the reverse. Charging.dip is dipping while charging.
There's a separate low voltage state for the 12v monitor.
//.ichael
On Sun, 9 Feb 2025, 06:35 Dan Edwards via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
Hi Chris,
Not sure if you’ve investigated the I-key system error , but thought I’d add my experience here. I have been receiving the same I-key system error in my 2012 leaf, with all the same symptoms and resolution as yours. This leaf doesn’t have OVMS installed at the moment, so maybe your issue is not due to OVMS. If you google I-key system error , you’ll find posts on issues with the BCM, which have been resolved with cleaning contacts on bcm (if there’s been moisture issues), and others replacing 12v acc battery. I’m pretty sure I’ve narrowed it down to 12v battery issues in my case, after inspecting BCM behind glove box in RHD edition, finding no issue, recharging 12v, and removing any known 12v drain like OVMS or odb dongle, just waiting for a recurrence to confirm. Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it. The OVMS log also shows 12v dip around the same time as your issue. This may explain OVMS shutdown as well if you’ve got it set to shut down due to low 12v battery, although I though that might be more graceful.
Cheers Dan
On 9 Feb 2025, at 8:35 am, Chris Box via OvmsDev < ovmsdev@lists.openvehicles.com> wrote:
Hi,
It's happened again. Yesterday while driving the Leaf lost drive mode, forcing pulling over. I couldn't reengage gear until I had disconnected the 12v battery.
Looking at the evidence today, the incident can't be explained by writing random bytes in CommandWakeup(), nor by having the wrong timing. It actually suggests that OVMS locked up ten minutes before the car was impacted.
Here's what happened.
13:15 to 13:17 I drove off from home, but forgot an item so quickly returned back there.
The sd log records this activity just fine, and the last entries before the suspected hang were these:
2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432)
There should have been the next housekeeping message at 13:27:29 but none was recorded on the sd. Log flushes are configured to occur after 30 seconds.
The last MQTT metric update my server received was around 13:27:50. This showed it was connected to home wifi.
At 13:28 I unlocked the car, started it and drove off without noticing anything unusual. None of this activity appears in the log.
During the drive there should have been a connection via Hologram to my server, but none was received.
Ten minutes later at 13:38 I was driving when a yellow warning light came on and the car moved to neutral. Essentially the same symptoms as in January: turning off and on would not clear the fault; it couldn't detect brake status meaning it told me to press brake pedal when I already was. Also showed I-key system error.
As I was stranded I used the only option I knew of to clear the fault, and I disconnected the 12v battery. On restoring power and dismissing the fault notice, it was happy to drive.
The log shows this cold start SNTP was at 13:44. On returning home, unfortunately 'boot status' says nothing about a crash, presumably because any information was lost when I pulled power.
So it seems there is some mechanism by which OVMS can lock up, without watchdog oversight. And that ten minutes later it can do something that becomes a critical issue for the car systems.
Chris
Relevant log entries below, all part of the same file. 1970 follows immediately after 13:22:29.184.
2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: Queue SetState() 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: PollState(0) 2025-02-07 13:17:50.184 GMT D (93622984) events: Signal(vehicle.off) 2025-02-07 13:17:51.144 GMT D (93623944) events: Signal(vehicle.aux.12v.charging.dip) 2025-02-07 13:17:53.144 GMT D (93625944) events: Signal(vehicle.aux.12v.dip) 2025-02-07 13:17:54.824 GMT E (93627624) can: can2: intr=15711227 rxpkt=15730955 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:17:56.754 GMT D (93629554) events: Signal(vehicle.locked) 2025-02-07 13:17:59.744 GMT E (93632544) can: can2: intr=15716706 rxpkt=15736447 txpkt=100 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:09.144 GMT D (93641944) events: Signal(vehicle.charge.12v.stop) 2025-02-07 13:18:10.144 GMT I (93642944) powermgmt: No longer charging 12V battery.. 2025-02-07 13:18:33.174 GMT D (93665944) events: Signal(vehicle.aux.12v.normal) 2025-02-07 13:18:33.764 GMT E (93666534) can: can2: intr=15754521 rxpkt=15774368 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Connection is <redacted> 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Status: Connecting... 2025-02-07 13:18:45.224 GMT D (93677994) events: Signal(server.v3.connecting) 2025-02-07 13:18:48.624 GMT I (93681394) ovms-server-v3: Connection successful 2025-02-07 13:18:48.644 GMT I (93681414) ovms-server-v3: Status: OVMS V3 MQTT login successful 2025-02-07 13:18:48.644 GMT D (93681414) events: Signal(server.v3.connected) 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Subscribe to MQTT topics 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Transmit all metrics 2025-02-07 13:18:49.464 GMT I (93682234) ovms-server-v3: Subscription acknowledged 2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432) 1970-01-01 00:00:08.424 GMT I (7994) command: OpenLogfile: now logging to file '/sd/logs/log' 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.event) 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:19.424 GMT I (18984) cellular: State: Enter Identify state 1970-01-01 00:00:19.434 GMT I (18994) cellular: Identified cellular modem: SIM7600/Experimental support for SIMCOM SIM7600 1970-01-01 00:00:19.434 GMT I (18994) cellular: Set modem driver to 'SIM7600' 1970-01-01 00:00:19.434 GMT I (18994) cellular: State: Enter PoweredOn state 1970-01-01 00:00:19.424 GMT D (18994) events: Signal(system.modem.installed) 1970-01-01 00:00:19.434 GMT D (19004) events: Signal(system.modem.poweredon) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.event) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.event) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:39.434 GMT I (38994) cellular: State: Enter MuxStart state 1970-01-01 00:00:39.444 GMT I (39004) gsm-mux: Start MUX 1970-01-01 00:00:39.444 GMT D (39004) events: Signal(system.modem.muxstart) 1970-01-01 00:00:39.444 GMT I (39014) gsm-mux: Channel #0 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #1 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #2 is open 1970-01-01 00:00:39.474 GMT I (39034) gsm-mux: Channel #3 is open 1970-01-01 00:00:39.484 GMT I (39044) gsm-mux: Channel #4 is open 1970-01-01 00:00:40.414 GMT I (39984) cellular: State: Enter NetWait state 1970-01-01 00:00:40.414 GMT D (39984) events: Signal(system.modem.netwait) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.event) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:46.054 GMT D (45624) events: Signal(vehicle.awake) 1970-01-01 00:00:50.444 GMT I (50014) cellular: Network Registration status: RegisteredRoaming 1970-01-01 00:00:51.414 GMT I (50984) cellular: State: Enter NetStart state 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(vehicle.aux.12v.blip) 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(system.modem.netstart) 1970-01-01 00:00:51.444 GMT D (51004) events: Signal(vehicle.charge.12v.start) 1970-01-01 00:00:51.434 GMT I (51004) cellular: Network Mode: LTE,Online 1970-01-01 00:00:52.414 GMT I (51984) powermgmt: Charging 12V battery.. 1970-01-01 00:00:52.464 GMT I (52034) cellular: PPP Connection is ready to start 1970-01-01 00:00:53.424 GMT I (52984) cellular: State: Enter NetMode state 1970-01-01 00:00:53.424 GMT I (52984) gsm-ppp: Initialising... 1970-01-01 00:00:53.434 GMT D (52994) events: Signal(system.modem.netmode) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.event) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: StatusCallBack: None 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: status_cb: Connected 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our_ipaddr = 100.83.212.151 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: his_ipaddr = 10.64.64.64 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: netmask = 255.255.255.255 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: DNS#0 = 8.8.8.8 1970-01-01 00:00:53.584 GMT I (53154) gsm-ppp: DNS#1 = 8.8.4.4 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our6_ipaddr = :: 1970-01-01 00:00:53.594 GMT D (53154) events: Signal(network.interface.up) 1970-01-01 00:00:53.604 GMT D (53164) events: Signal(system.modem.gotip) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Interface priority is pp2 (100.83.212.151/255.255.255.255 gateway 10.64.64.64) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Set DNS#2 0.0.0.0 1970-01-01 00:00:53.594 GMT I (53164) netmanager: MODEM up (with WIFI client down): starting network with MODEM 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.modem.up) 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.up) 1970-01-01 00:00:53.604 GMT I (53174) time: Starting SNTP client 1970-01-01 00:00:53.604 GMT D (53174) events: Signal(network.interface.change) 1970-01-01 00:00:53.614 GMT D (53174) events: Signal(network.mgr.init) 1970-01-01 00:00:53.614 GMT I (53174) webserver: Launching Web Server 2025-02-07 13:44:08.584 GMT I (53184) webserver: Binding to port 80 (http) 2025-02-07 13:44:08.584 GMT I (53184) ssh: Launching SSH Server
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I'd consider the "dips" logged here as false positives.
Michael, correct me if I'm wrong: your new 12V monitor doesn't yet implement a calmdown phase after charging. The voltage decline after the DC converter switches off is logarithmic, so can easily trigger the "dip" detection in the beginning. That fits these log entries:
13:17:50.184 (vehicle.off) assumption: DCDC off 13:17:51.144 (vehicle.aux.12v.charging.dip) [12vmon] 12v > 14.0 && < 0.09 under avg 13:17:53.144 (vehicle.aux.12v.dip) [12vmon] 12v <= 14.0 && < 0.25 under avg 13:17:56.754 (vehicle.locked) 13:18:09.144 (vehicle.charge.12v.stop) [leaf] 12v <= 12.8 13:18:33.174 (vehicle.aux.12v.normal) 13:19:59.174 (vehicle.asleep) [leaf] off since 120-130 seconds (awake stale)
Generally I think all aux.12v log entries shortly after a vehicle.off
should currently be ignored with regards to 12V diagnosis. (@Michael:
check m_12v_ticker for my calmdown implementation for the reference
voltage measurement)
The same may apply to the start of a 12V charging phase, depending on the way the vehicle detects that state.
IOW, Chris, you should look for "dip" log entries well within a parking / driving / charging phase, when the 12V level should be more or less constant.
You should also have a look at the general 12V level behaviour, e.g. using the 12V chart plugin or creating a chart from the MQTT metric. The V2 Android App also has a 12V chart, if you use V2. When using V2/MQTT, consider raising the update interval to get a higher time resolution.
Btw, also consider shortening the file logging sync period, 30 seconds is rather high.
On the 12V shutdown: even with 30 seconds log flushing, you would have seen the log entries for a shutdown condition, unless you configured the shutdown delay to 0 (default is 2 minutes).
That is, if the 12V level wasn't suddenly getting drastically low, i.e. too low within seconds to keep the ESP32 in operation. That could explain the freeze. Not sure how low that would need to have been.
I'd check for another potential source of such a sudden voltage drop: a mechanical/electrical issue with the OBD connector or cable.
If for example there is a lose wire in the connection, that occasionally causes a short circuit, that would both explain the module freeze and the car fault.
Regards, Michael
Am 09.02.25 um 04:45 schrieb Michael Geddes via OvmsDev:
Just fyi a 'dip' is 12v voltage decreasing momentarily. A blip is the reverse. Charging.dip is dipping while charging.
There's a separate low voltage state for the 12v monitor.
//.ichael
On Sun, 9 Feb 2025, 06:35 Dan Edwards via OvmsDev, <ovmsdev@lists.openvehicles.com> wrote:
Hi Chris, Not sure if you’ve investigated the I-key system error , but thought I’d add my experience here. I have been receiving the same I-key system error in my 2012 leaf, with all the same symptoms and resolution as yours. This leaf doesn’t have OVMS installed at the moment, so maybe your issue is not due to OVMS. If you google I-key system error , you’ll find posts on issues with the BCM, which have been resolved with cleaning contacts on bcm (if there’s been moisture issues), and others replacing 12v acc battery. I’m pretty sure I’ve narrowed it down to 12v battery issues in my case, after inspecting BCM behind glove box in RHD edition, finding no issue, recharging 12v, and removing any known 12v drain like OVMS or odb dongle, just waiting for a recurrence to confirm. Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it. The OVMS log also shows 12v dip around the same time as your issue. This may explain OVMS shutdown as well if you’ve got it set to shut down due to low 12v battery, although I though that might be more graceful. Cheers DanOn 9 Feb 2025, at 8:35 am, Chris Box via OvmsDev <ovmsdev@lists.openvehicles.com> wrote: Hi, It's happened again. Yesterday while driving the Leaf lost drive mode, forcing pulling over. I couldn't reengage gear until I had disconnected the 12v battery. Looking at the evidence today, the incident can't be explained by writing random bytes in CommandWakeup(), nor by having the wrong timing. It actually suggests that OVMS locked up ten minutes before the car was impacted. Here's what happened. 13:15 to 13:17 I drove off from home, but forgot an item so quickly returned back there. The sd log records this activity just fine, and the last entries before the suspected hang were these: 2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432) There should have been the next housekeeping message at 13:27:29 but none was recorded on the sd. Log flushes are configured to occur after 30 seconds. The last MQTT metric update my server received was around 13:27:50. This showed it was connected to home wifi. At 13:28 I unlocked the car, started it and drove off without noticing anything unusual. None of this activity appears in the log. During the drive there should have been a connection via Hologram to my server, but none was received. Ten minutes later at 13:38 I was driving when a yellow warning light came on and the car moved to neutral. Essentially the same symptoms as in January: turning off and on would not clear the fault; it couldn't detect brake status meaning it told me to press brake pedal when I already was. Also showed I-key system error. As I was stranded I used the only option I knew of to clear the fault, and I disconnected the 12v battery. On restoring power and dismissing the fault notice, it was happy to drive. The log shows this cold start SNTP was at 13:44. On returning home, unfortunately 'boot status' says nothing about a crash, presumably because any information was lost when I pulled power. So it seems there is some mechanism by which OVMS can lock up, without watchdog oversight. And that ten minutes later it can do something that becomes a critical issue for the car systems. Chris Relevant log entries below, all part of the same file. 1970 follows immediately after 13:22:29.184. 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: Queue SetState() 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: PollState(0) 2025-02-07 13:17:50.184 GMT D (93622984) events: Signal(vehicle.off) 2025-02-07 13:17:51.144 GMT D (93623944) events: Signal(vehicle.aux.12v.charging.dip) 2025-02-07 13:17:53.144 GMT D (93625944) events: Signal(vehicle.aux.12v.dip) 2025-02-07 13:17:54.824 GMT E (93627624) can: can2: intr=15711227 rxpkt=15730955 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:17:56.754 GMT D (93629554) events: Signal(vehicle.locked) 2025-02-07 13:17:59.744 GMT E (93632544) can: can2: intr=15716706 rxpkt=15736447 txpkt=100 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:09.144 GMT D (93641944) events: Signal(vehicle.charge.12v.stop) 2025-02-07 13:18:10.144 GMT I (93642944) powermgmt: No longer charging 12V battery.. 2025-02-07 13:18:33.174 GMT D (93665944) events: Signal(vehicle.aux.12v.normal) 2025-02-07 13:18:33.764 GMT E (93666534) can: can2: intr=15754521 rxpkt=15774368 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Connection is <redacted> 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Status: Connecting... 2025-02-07 13:18:45.224 GMT D (93677994) events: Signal(server.v3.connecting) 2025-02-07 13:18:48.624 GMT I (93681394) ovms-server-v3: Connection successful 2025-02-07 13:18:48.644 GMT I (93681414) ovms-server-v3: Status: OVMS V3 MQTT login successful 2025-02-07 13:18:48.644 GMT D (93681414) events: Signal(server.v3.connected) 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Subscribe to MQTT topics 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Transmit all metrics 2025-02-07 13:18:49.464 GMT I (93682234) ovms-server-v3: Subscription acknowledged 2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432) 1970-01-01 00:00:08.424 GMT I (7994) command: OpenLogfile: now logging to file '/sd/logs/log' 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.event) 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:19.424 GMT I (18984) cellular: State: Enter Identify state 1970-01-01 00:00:19.434 GMT I (18994) cellular: Identified cellular modem: SIM7600/Experimental support for SIMCOM SIM7600 1970-01-01 00:00:19.434 GMT I (18994) cellular: Set modem driver to 'SIM7600' 1970-01-01 00:00:19.434 GMT I (18994) cellular: State: Enter PoweredOn state 1970-01-01 00:00:19.424 GMT D (18994) events: Signal(system.modem.installed) 1970-01-01 00:00:19.434 GMT D (19004) events: Signal(system.modem.poweredon) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.event) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.event) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:39.434 GMT I (38994) cellular: State: Enter MuxStart state 1970-01-01 00:00:39.444 GMT I (39004) gsm-mux: Start MUX 1970-01-01 00:00:39.444 GMT D (39004) events: Signal(system.modem.muxstart) 1970-01-01 00:00:39.444 GMT I (39014) gsm-mux: Channel #0 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #1 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #2 is open 1970-01-01 00:00:39.474 GMT I (39034) gsm-mux: Channel #3 is open 1970-01-01 00:00:39.484 GMT I (39044) gsm-mux: Channel #4 is open 1970-01-01 00:00:40.414 GMT I (39984) cellular: State: Enter NetWait state 1970-01-01 00:00:40.414 GMT D (39984) events: Signal(system.modem.netwait) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.event) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:46.054 GMT D (45624) events: Signal(vehicle.awake) 1970-01-01 00:00:50.444 GMT I (50014) cellular: Network Registration status: RegisteredRoaming 1970-01-01 00:00:51.414 GMT I (50984) cellular: State: Enter NetStart state 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(vehicle.aux.12v.blip) 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(system.modem.netstart) 1970-01-01 00:00:51.444 GMT D (51004) events: Signal(vehicle.charge.12v.start) 1970-01-01 00:00:51.434 GMT I (51004) cellular: Network Mode: LTE,Online 1970-01-01 00:00:52.414 GMT I (51984) powermgmt: Charging 12V battery.. 1970-01-01 00:00:52.464 GMT I (52034) cellular: PPP Connection is ready to start 1970-01-01 00:00:53.424 GMT I (52984) cellular: State: Enter NetMode state 1970-01-01 00:00:53.424 GMT I (52984) gsm-ppp: Initialising... 1970-01-01 00:00:53.434 GMT D (52994) events: Signal(system.modem.netmode) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.event) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: StatusCallBack: None 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: status_cb: Connected 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our_ipaddr = 100.83.212.151 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: his_ipaddr = 10.64.64.64 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: netmask = 255.255.255.255 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: DNS#0 = 8.8.8.8 1970-01-01 00:00:53.584 GMT I (53154) gsm-ppp: DNS#1 = 8.8.4.4 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our6_ipaddr = :: 1970-01-01 00:00:53.594 GMT D (53154) events: Signal(network.interface.up) 1970-01-01 00:00:53.604 GMT D (53164) events: Signal(system.modem.gotip) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Interface priority is pp2 (100.83.212.151/255.255.255.255 <http://100.83.212.151/255.255.255.255> gateway 10.64.64.64) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Set DNS#2 0.0.0.0 1970-01-01 00:00:53.594 GMT I (53164) netmanager: MODEM up (with WIFI client down): starting network with MODEM 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.modem.up) 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.up) 1970-01-01 00:00:53.604 GMT I (53174) time: Starting SNTP client 1970-01-01 00:00:53.604 GMT D (53174) events: Signal(network.interface.change) 1970-01-01 00:00:53.614 GMT D (53174) events: Signal(network.mgr.init) 1970-01-01 00:00:53.614 GMT I (53174) webserver: Launching Web Server 2025-02-07 13:44:08.584 GMT I (53184) webserver: Binding to port 80 (http) 2025-02-07 13:44:08.584 GMT I (53184) ssh: Launching SSH Server _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
A dip/blip is designed simply to say something is going on. It's not saying that there's a condition of any sort.. so it's not a false alarm.. as it's not really anything.
The low voltage level is different but not going on here.
//.ichael
On Sun, 9 Feb 2025, 17:24 Michael Balzer via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
I'd consider the "dips" logged here as false positives.
Michael, correct me if I'm wrong: your new 12V monitor doesn't yet implement a calmdown phase after charging. The voltage decline after the DC converter switches off is logarithmic, so can easily trigger the "dip" detection in the beginning. That fits these log entries:
13:17:50.184 (vehicle.off) assumption: DCDC off 13:17:51.144 (vehicle.aux.12v.charging.dip) [12vmon] 12v > 14.0 && < 0.09 under avg 13:17:53.144 (vehicle.aux.12v.dip) [12vmon] 12v <= 14.0 && < 0.25 under avg 13:17:56.754 (vehicle.locked) 13:18:09.144 (vehicle.charge.12v.stop) [leaf] 12v <= 12.8 13:18:33.174 (vehicle.aux.12v.normal) 13:19:59.174 (vehicle.asleep) [leaf] off since 120-130 seconds (awake stale)
Generally I think all aux.12v log entries shortly after a vehicle.off should currently be ignored with regards to 12V diagnosis. (@Michael: check
m_12v_tickerfor my calmdown implementation for the reference voltage measurement)The same may apply to the start of a 12V charging phase, depending on the way the vehicle detects that state.
IOW, Chris, you should look for "dip" log entries well within a parking / driving / charging phase, when the 12V level should be more or less constant.
You should also have a look at the general 12V level behaviour, e.g. using the 12V chart plugin or creating a chart from the MQTT metric. The V2 Android App also has a 12V chart, if you use V2. When using V2/MQTT, consider raising the update interval to get a higher time resolution.
Btw, also consider shortening the file logging sync period, 30 seconds is rather high.
On the 12V shutdown: even with 30 seconds log flushing, you would have seen the log entries for a shutdown condition, unless you configured the shutdown delay to 0 (default is 2 minutes).
That is, if the 12V level wasn't suddenly getting drastically low, i.e. too low within seconds to keep the ESP32 in operation. That could explain the freeze. Not sure how low that would need to have been.
I'd check for another potential source of such a sudden voltage drop: a mechanical/electrical issue with the OBD connector or cable.
If for example there is a lose wire in the connection, that occasionally causes a short circuit, that would both explain the module freeze and the car fault.
Regards, Michael
Am 09.02.25 um 04:45 schrieb Michael Geddes via OvmsDev:
Just fyi a 'dip' is 12v voltage decreasing momentarily. A blip is the reverse. Charging.dip is dipping while charging.
There's a separate low voltage state for the 12v monitor.
//.ichael
On Sun, 9 Feb 2025, 06:35 Dan Edwards via OvmsDev, < ovmsdev@lists.openvehicles.com> wrote:
Hi Chris,
Not sure if you’ve investigated the I-key system error , but thought I’d add my experience here. I have been receiving the same I-key system error in my 2012 leaf, with all the same symptoms and resolution as yours. This leaf doesn’t have OVMS installed at the moment, so maybe your issue is not due to OVMS. If you google I-key system error , you’ll find posts on issues with the BCM, which have been resolved with cleaning contacts on bcm (if there’s been moisture issues), and others replacing 12v acc battery. I’m pretty sure I’ve narrowed it down to 12v battery issues in my case, after inspecting BCM behind glove box in RHD edition, finding no issue, recharging 12v, and removing any known 12v drain like OVMS or odb dongle, just waiting for a recurrence to confirm. Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it. The OVMS log also shows 12v dip around the same time as your issue. This may explain OVMS shutdown as well if you’ve got it set to shut down due to low 12v battery, although I though that might be more graceful.
Cheers Dan
On 9 Feb 2025, at 8:35 am, Chris Box via OvmsDev < ovmsdev@lists.openvehicles.com> wrote:
Hi,
It's happened again. Yesterday while driving the Leaf lost drive mode, forcing pulling over. I couldn't reengage gear until I had disconnected the 12v battery.
Looking at the evidence today, the incident can't be explained by writing random bytes in CommandWakeup(), nor by having the wrong timing. It actually suggests that OVMS locked up ten minutes before the car was impacted.
Here's what happened.
13:15 to 13:17 I drove off from home, but forgot an item so quickly returned back there.
The sd log records this activity just fine, and the last entries before the suspected hang were these:
2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432)
There should have been the next housekeeping message at 13:27:29 but none was recorded on the sd. Log flushes are configured to occur after 30 seconds.
The last MQTT metric update my server received was around 13:27:50. This showed it was connected to home wifi.
At 13:28 I unlocked the car, started it and drove off without noticing anything unusual. None of this activity appears in the log.
During the drive there should have been a connection via Hologram to my server, but none was received.
Ten minutes later at 13:38 I was driving when a yellow warning light came on and the car moved to neutral. Essentially the same symptoms as in January: turning off and on would not clear the fault; it couldn't detect brake status meaning it told me to press brake pedal when I already was. Also showed I-key system error.
As I was stranded I used the only option I knew of to clear the fault, and I disconnected the 12v battery. On restoring power and dismissing the fault notice, it was happy to drive.
The log shows this cold start SNTP was at 13:44. On returning home, unfortunately 'boot status' says nothing about a crash, presumably because any information was lost when I pulled power.
So it seems there is some mechanism by which OVMS can lock up, without watchdog oversight. And that ten minutes later it can do something that becomes a critical issue for the car systems.
Chris
Relevant log entries below, all part of the same file. 1970 follows immediately after 13:22:29.184.
2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: Queue SetState() 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: PollState(0) 2025-02-07 13:17:50.184 GMT D (93622984) events: Signal(vehicle.off) 2025-02-07 13:17:51.144 GMT D (93623944) events: Signal(vehicle.aux.12v.charging.dip) 2025-02-07 13:17:53.144 GMT D (93625944) events: Signal(vehicle.aux.12v.dip) 2025-02-07 13:17:54.824 GMT E (93627624) can: can2: intr=15711227 rxpkt=15730955 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:17:56.754 GMT D (93629554) events: Signal(vehicle.locked) 2025-02-07 13:17:59.744 GMT E (93632544) can: can2: intr=15716706 rxpkt=15736447 txpkt=100 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:09.144 GMT D (93641944) events: Signal(vehicle.charge.12v.stop) 2025-02-07 13:18:10.144 GMT I (93642944) powermgmt: No longer charging 12V battery.. 2025-02-07 13:18:33.174 GMT D (93665944) events: Signal(vehicle.aux.12v.normal) 2025-02-07 13:18:33.764 GMT E (93666534) can: can2: intr=15754521 rxpkt=15774368 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Connection is <redacted> 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Status: Connecting... 2025-02-07 13:18:45.224 GMT D (93677994) events: Signal(server.v3.connecting) 2025-02-07 13:18:48.624 GMT I (93681394) ovms-server-v3: Connection successful 2025-02-07 13:18:48.644 GMT I (93681414) ovms-server-v3: Status: OVMS V3 MQTT login successful 2025-02-07 13:18:48.644 GMT D (93681414) events: Signal(server.v3.connected) 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Subscribe to MQTT topics 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Transmit all metrics 2025-02-07 13:18:49.464 GMT I (93682234) ovms-server-v3: Subscription acknowledged 2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432) 1970-01-01 00:00:08.424 GMT I (7994) command: OpenLogfile: now logging to file '/sd/logs/log' 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.event) 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:19.424 GMT I (18984) cellular: State: Enter Identify state 1970-01-01 00:00:19.434 GMT I (18994) cellular: Identified cellular modem: SIM7600/Experimental support for SIMCOM SIM7600 1970-01-01 00:00:19.434 GMT I (18994) cellular: Set modem driver to 'SIM7600' 1970-01-01 00:00:19.434 GMT I (18994) cellular: State: Enter PoweredOn state 1970-01-01 00:00:19.424 GMT D (18994) events: Signal(system.modem.installed) 1970-01-01 00:00:19.434 GMT D (19004) events: Signal(system.modem.poweredon) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.event) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.event) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:39.434 GMT I (38994) cellular: State: Enter MuxStart state 1970-01-01 00:00:39.444 GMT I (39004) gsm-mux: Start MUX 1970-01-01 00:00:39.444 GMT D (39004) events: Signal(system.modem.muxstart) 1970-01-01 00:00:39.444 GMT I (39014) gsm-mux: Channel #0 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #1 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #2 is open 1970-01-01 00:00:39.474 GMT I (39034) gsm-mux: Channel #3 is open 1970-01-01 00:00:39.484 GMT I (39044) gsm-mux: Channel #4 is open 1970-01-01 00:00:40.414 GMT I (39984) cellular: State: Enter NetWait state 1970-01-01 00:00:40.414 GMT D (39984) events: Signal(system.modem.netwait) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.event) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:46.054 GMT D (45624) events: Signal(vehicle.awake) 1970-01-01 00:00:50.444 GMT I (50014) cellular: Network Registration status: RegisteredRoaming 1970-01-01 00:00:51.414 GMT I (50984) cellular: State: Enter NetStart state 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(vehicle.aux.12v.blip) 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(system.modem.netstart) 1970-01-01 00:00:51.444 GMT D (51004) events: Signal(vehicle.charge.12v.start) 1970-01-01 00:00:51.434 GMT I (51004) cellular: Network Mode: LTE,Online 1970-01-01 00:00:52.414 GMT I (51984) powermgmt: Charging 12V battery.. 1970-01-01 00:00:52.464 GMT I (52034) cellular: PPP Connection is ready to start 1970-01-01 00:00:53.424 GMT I (52984) cellular: State: Enter NetMode state 1970-01-01 00:00:53.424 GMT I (52984) gsm-ppp: Initialising... 1970-01-01 00:00:53.434 GMT D (52994) events: Signal(system.modem.netmode) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.event) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: StatusCallBack: None 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: status_cb: Connected 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our_ipaddr = 100.83.212.151 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: his_ipaddr = 10.64.64.64 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: netmask = 255.255.255.255 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: DNS#0 = 8.8.8.8 1970-01-01 00:00:53.584 GMT I (53154) gsm-ppp: DNS#1 = 8.8.4.4 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our6_ipaddr = :: 1970-01-01 00:00:53.594 GMT D (53154) events: Signal(network.interface.up) 1970-01-01 00:00:53.604 GMT D (53164) events: Signal(system.modem.gotip) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Interface priority is pp2 (100.83.212.151/255.255.255.255 gateway 10.64.64.64) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Set DNS#2 0.0.0.0 1970-01-01 00:00:53.594 GMT I (53164) netmanager: MODEM up (with WIFI client down): starting network with MODEM 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.modem.up) 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.up) 1970-01-01 00:00:53.604 GMT I (53174) time: Starting SNTP client 1970-01-01 00:00:53.604 GMT D (53174) events: Signal(network.interface.change) 1970-01-01 00:00:53.614 GMT D (53174) events: Signal(network.mgr.init) 1970-01-01 00:00:53.614 GMT I (53174) webserver: Launching Web Server 2025-02-07 13:44:08.584 GMT I (53184) webserver: Binding to port 80 (http) 2025-02-07 13:44:08.584 GMT I (53184) ssh: Launching SSH Server
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g> Fon 02330 9104094 * Handy 0176 20698926
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Michael,
Am 09.02.25 um 11:34 schrieb Michael Geddes:
A dip/blip is designed simply to say something is going on. It's not saying that there's a condition of any sort.. so it's not a false alarm.. as it's not really anything.
Thanks for the clarification.
I misinterpreted the dip/blip events as detecting unexpected/irregular pulse deviations, like the one here at 17:00:
But it's really just about detecting any significant sudden change.
In case there are others misinterpreting these (are there?), we can add some clarification to the manual.
Regards, Michael
The low voltage level is different but not going on here.
//.ichael
On Sun, 9 Feb 2025, 17:24 Michael Balzer via OvmsDev, <ovmsdev@lists.openvehicles.com> wrote:
I'd consider the "dips" logged here as false positives. Michael, correct me if I'm wrong: your new 12V monitor doesn't yet implement a calmdown phase after charging. The voltage decline after the DC converter switches off is logarithmic, so can easily trigger the "dip" detection in the beginning. That fits these log entries: 13:17:50.184 (vehicle.off) assumption: DCDC off 13:17:51.144 (vehicle.aux.12v.charging.dip) [12vmon] 12v > 14.0 && < 0.09 under avg 13:17:53.144 (vehicle.aux.12v.dip) [12vmon] 12v <= 14.0 && < 0.25 under avg 13:17:56.754 (vehicle.locked) 13:18:09.144 (vehicle.charge.12v.stop) [leaf] 12v <= 12.8 13:18:33.174 (vehicle.aux.12v.normal) 13:19:59.174 (vehicle.asleep) [leaf] off since 120-130 seconds (awake stale) Generally I think all aux.12v log entries shortly after a vehicle.off should currently be ignored with regards to 12V diagnosis. (@Michael: check `m_12v_ticker` for my calmdown implementation for the reference voltage measurement) The same may apply to the start of a 12V charging phase, depending on the way the vehicle detects that state. IOW, Chris, you should look for "dip" log entries well within a parking / driving / charging phase, when the 12V level should be more or less constant. You should also have a look at the general 12V level behaviour, e.g. using the 12V chart plugin or creating a chart from the MQTT metric. The V2 Android App also has a 12V chart, if you use V2. When using V2/MQTT, consider raising the update interval to get a higher time resolution. Btw, also consider shortening the file logging sync period, 30 seconds is rather high. On the 12V shutdown: even with 30 seconds log flushing, you would have seen the log entries for a shutdown condition, unless you configured the shutdown delay to 0 (default is 2 minutes). That is, if the 12V level wasn't suddenly getting drastically low, i.e. too low within seconds to keep the ESP32 in operation. That could explain the freeze. Not sure how low that would need to have been. I'd check for another potential source of such a sudden voltage drop: a mechanical/electrical issue with the OBD connector or cable. If for example there is a lose wire in the connection, that occasionally causes a short circuit, that would both explain the module freeze and the car fault. Regards, Michael Am 09.02.25 um 04:45 schrieb Michael Geddes via OvmsDev:Just fyi a 'dip' is 12v voltage decreasing momentarily. A blip is the reverse. Charging.dip is dipping while charging. There's a separate low voltage state for the 12v monitor. //.ichael On Sun, 9 Feb 2025, 06:35 Dan Edwards via OvmsDev, <ovmsdev@lists.openvehicles.com> wrote: Hi Chris, Not sure if you’ve investigated the I-key system error , but thought I’d add my experience here. I have been receiving the same I-key system error in my 2012 leaf, with all the same symptoms and resolution as yours. This leaf doesn’t have OVMS installed at the moment, so maybe your issue is not due to OVMS. If you google I-key system error , you’ll find posts on issues with the BCM, which have been resolved with cleaning contacts on bcm (if there’s been moisture issues), and others replacing 12v acc battery. I’m pretty sure I’ve narrowed it down to 12v battery issues in my case, after inspecting BCM behind glove box in RHD edition, finding no issue, recharging 12v, and removing any known 12v drain like OVMS or odb dongle, just waiting for a recurrence to confirm. Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it. The OVMS log also shows 12v dip around the same time as your issue. This may explain OVMS shutdown as well if you’ve got it set to shut down due to low 12v battery, although I though that might be more graceful. Cheers DanOn 9 Feb 2025, at 8:35 am, Chris Box via OvmsDev <ovmsdev@lists.openvehicles.com> wrote: Hi, It's happened again. Yesterday while driving the Leaf lost drive mode, forcing pulling over. I couldn't reengage gear until I had disconnected the 12v battery. Looking at the evidence today, the incident can't be explained by writing random bytes in CommandWakeup(), nor by having the wrong timing. It actually suggests that OVMS locked up ten minutes before the car was impacted. Here's what happened. 13:15 to 13:17 I drove off from home, but forgot an item so quickly returned back there. The sd log records this activity just fine, and the last entries before the suspected hang were these: 2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432) There should have been the next housekeeping message at 13:27:29 but none was recorded on the sd. Log flushes are configured to occur after 30 seconds. The last MQTT metric update my server received was around 13:27:50. This showed it was connected to home wifi. At 13:28 I unlocked the car, started it and drove off without noticing anything unusual. None of this activity appears in the log. During the drive there should have been a connection via Hologram to my server, but none was received. Ten minutes later at 13:38 I was driving when a yellow warning light came on and the car moved to neutral. Essentially the same symptoms as in January: turning off and on would not clear the fault; it couldn't detect brake status meaning it told me to press brake pedal when I already was. Also showed I-key system error. As I was stranded I used the only option I knew of to clear the fault, and I disconnected the 12v battery. On restoring power and dismissing the fault notice, it was happy to drive. The log shows this cold start SNTP was at 13:44. On returning home, unfortunately 'boot status' says nothing about a crash, presumably because any information was lost when I pulled power. So it seems there is some mechanism by which OVMS can lock up, without watchdog oversight. And that ten minutes later it can do something that becomes a critical issue for the car systems. Chris Relevant log entries below, all part of the same file. 1970 follows immediately after 13:22:29.184. 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: Queue SetState() 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll: Pollers: PollState(0) 2025-02-07 13:17:50.184 GMT D (93622984) events: Signal(vehicle.off) 2025-02-07 13:17:51.144 GMT D (93623944) events: Signal(vehicle.aux.12v.charging.dip) 2025-02-07 13:17:53.144 GMT D (93625944) events: Signal(vehicle.aux.12v.dip) 2025-02-07 13:17:54.824 GMT E (93627624) can: can2: intr=15711227 rxpkt=15730955 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:17:56.754 GMT D (93629554) events: Signal(vehicle.locked) 2025-02-07 13:17:59.744 GMT E (93632544) can: can2: intr=15716706 rxpkt=15736447 txpkt=100 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:09.144 GMT D (93641944) events: Signal(vehicle.charge.12v.stop) 2025-02-07 13:18:10.144 GMT I (93642944) powermgmt: No longer charging 12V battery.. 2025-02-07 13:18:33.174 GMT D (93665944) events: Signal(vehicle.aux.12v.normal) 2025-02-07 13:18:33.764 GMT E (93666534) can: can2: intr=15754521 rxpkt=15774368 txpkt=100 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 txqueue=0 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Connection is <redacted> 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3: Status: Connecting... 2025-02-07 13:18:45.224 GMT D (93677994) events: Signal(server.v3.connecting) 2025-02-07 13:18:48.624 GMT I (93681394) ovms-server-v3: Connection successful 2025-02-07 13:18:48.644 GMT I (93681414) ovms-server-v3: Status: OVMS V3 MQTT login successful 2025-02-07 13:18:48.644 GMT D (93681414) events: Signal(server.v3.connected) 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Subscribe to MQTT topics 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3: Transmit all metrics 2025-02-07 13:18:49.464 GMT I (93682234) ovms-server-v3: Subscription acknowledged 2025-02-07 13:19:59.174 GMT D (93751944) events: Signal(vehicle.asleep) 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping: 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560 SPI=3262992-3285432) 1970-01-01 00:00:08.424 GMT I (7994) command: OpenLogfile: now logging to file '/sd/logs/log' 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.event) 1970-01-01 00:00:13.474 GMT D (13034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:19.424 GMT I (18984) cellular: State: Enter Identify state 1970-01-01 00:00:19.434 GMT I (18994) cellular: Identified cellular modem: SIM7600/Experimental support for SIMCOM SIM7600 1970-01-01 00:00:19.434 GMT I (18994) cellular: Set modem driver to 'SIM7600' 1970-01-01 00:00:19.434 GMT I (18994) cellular: State: Enter PoweredOn state 1970-01-01 00:00:19.424 GMT D (18994) events: Signal(system.modem.installed) 1970-01-01 00:00:19.434 GMT D (19004) events: Signal(system.modem.poweredon) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.event) 1970-01-01 00:00:23.474 GMT D (23034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.event) 1970-01-01 00:00:33.474 GMT D (33034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:39.434 GMT I (38994) cellular: State: Enter MuxStart state 1970-01-01 00:00:39.444 GMT I (39004) gsm-mux: Start MUX 1970-01-01 00:00:39.444 GMT D (39004) events: Signal(system.modem.muxstart) 1970-01-01 00:00:39.444 GMT I (39014) gsm-mux: Channel #0 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #1 is open 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #2 is open 1970-01-01 00:00:39.474 GMT I (39034) gsm-mux: Channel #3 is open 1970-01-01 00:00:39.484 GMT I (39044) gsm-mux: Channel #4 is open 1970-01-01 00:00:40.414 GMT I (39984) cellular: State: Enter NetWait state 1970-01-01 00:00:40.414 GMT D (39984) events: Signal(system.modem.netwait) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.event) 1970-01-01 00:00:43.474 GMT D (43034) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:46.054 GMT D (45624) events: Signal(vehicle.awake) 1970-01-01 00:00:50.444 GMT I (50014) cellular: Network Registration status: RegisteredRoaming 1970-01-01 00:00:51.414 GMT I (50984) cellular: State: Enter NetStart state 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(vehicle.aux.12v.blip) 1970-01-01 00:00:51.434 GMT D (50994) events: Signal(system.modem.netstart) 1970-01-01 00:00:51.444 GMT D (51004) events: Signal(vehicle.charge.12v.start) 1970-01-01 00:00:51.434 GMT I (51004) cellular: Network Mode: LTE,Online 1970-01-01 00:00:52.414 GMT I (51984) powermgmt: Charging 12V battery.. 1970-01-01 00:00:52.464 GMT I (52034) cellular: PPP Connection is ready to start 1970-01-01 00:00:53.424 GMT I (52984) cellular: State: Enter NetMode state 1970-01-01 00:00:53.424 GMT I (52984) gsm-ppp: Initialising... 1970-01-01 00:00:53.434 GMT D (52994) events: Signal(system.modem.netmode) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.event) 1970-01-01 00:00:53.484 GMT D (53044) events: Signal(system.wifi.scan.done) 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: StatusCallBack: None 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: status_cb: Connected 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our_ipaddr = 100.83.212.151 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: his_ipaddr = 10.64.64.64 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: netmask = 255.255.255.255 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: DNS#0 = 8.8.8.8 1970-01-01 00:00:53.584 GMT I (53154) gsm-ppp: DNS#1 = 8.8.4.4 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our6_ipaddr = :: 1970-01-01 00:00:53.594 GMT D (53154) events: Signal(network.interface.up) 1970-01-01 00:00:53.604 GMT D (53164) events: Signal(system.modem.gotip) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Interface priority is pp2 (100.83.212.151/255.255.255.255 <http://100.83.212.151/255.255.255.255> gateway 10.64.64.64) 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Set DNS#2 0.0.0.0 1970-01-01 00:00:53.594 GMT I (53164) netmanager: MODEM up (with WIFI client down): starting network with MODEM 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.modem.up) 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.up) 1970-01-01 00:00:53.604 GMT I (53174) time: Starting SNTP client 1970-01-01 00:00:53.604 GMT D (53174) events: Signal(network.interface.change) 1970-01-01 00:00:53.614 GMT D (53174) events: Signal(network.mgr.init) 1970-01-01 00:00:53.614 GMT I (53174) webserver: Launching Web Server 2025-02-07 13:44:08.584 GMT I (53184) webserver: Binding to port 80 (http) 2025-02-07 13:44:08.584 GMT I (53184) ssh: Launching SSH Server _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev-- Michael Balzer *Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g> Fon 02330 9104094 * Handy 0176 20698926 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
On 2025-02-08 22:22, Dan Edwards wrote:
If you google I-key system error , you'll find posts on issues with the BCM, which have been resolved with cleaning contacts on bcm (if there's been moisture issues), and others replacing 12v acc battery.
Thanks for the pointer. I drove the car for a year without OVMS and didn't have an i-key error then. Did you experience switching to neutral while driving?
Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it.
I've now ordered a dongle to work with Leaf Spy.
On 2025-02-09 09:23, Michael Balzer via OvmsDev wrote:
IOW, Chris, you should look for "dip" log entries well within a parking / driving / charging phase, when the 12V level should be more or less constant.
I've checked the logs for the 7th, and below is the one such dip I can see. It occurs towards the end of the drive home.
2025-02-07 13:51:03.584 GMT D (468184) events: Signal(vehicle.awake) 2025-02-07 13:51:05.424 GMT D (470024) vehicle-poll: Pollers: Queue SetState() 2025-02-07 13:51:05.424 GMT D (470024) vehicle-poll: Pollers: PollState(1) 2025-02-07 13:51:05.424 GMT D (470024) events: Signal(vehicle.on) 2025-02-07 13:51:06.464 GMT D (471064) events: Signal(vehicle.charge.12v.start) 2025-02-07 13:51:08.384 GMT D (472984) events: Signal(vehicle.aux.12v.blip) 2025-02-07 13:51:11.114 GMT D (475714) vehicle-poll: Pollers: Queue SetState() 2025-02-07 13:51:11.124 GMT D (475724) vehicle-poll: Pollers: PollState(2) 2025-02-07 13:51:11.124 GMT D (475724) events: Signal(vehicle.gear.forward) 2025-02-07 13:51:16.394 GMT D (480994) events: Signal(vehicle.aux.12v.charging.blip) 2025-02-07 13:51:56.394 GMT D (520994) events: Signal(vehicle.aux.12v.charging) 2025-02-07 13:56:50.754 GMT D (815354) events: Signal(vehicle.headlights.on) 2025-02-07 13:56:56.904 GMT D (821504) events: Signal(vehicle.headlights.off) 2025-02-07 13:56:58.964 GMT D (823564) events: Signal(vehicle.headlights.on) 2025-02-07 13:57:05.164 GMT D (829764) events: Signal(vehicle.headlights.off) 2025-02-07 14:01:54.384 GMT D (1118984) events: Signal(vehicle.aux.12v.charging.dip) 2025-02-07 14:02:00.384 GMT D (1124984) events: Signal(vehicle.aux.12v.dip) 2025-02-07 14:02:30.384 GMT D (1154984) events: Signal(vehicle.aux.12v.normal) 2025-02-07 14:03:36.394 GMT D (1220994) events: Signal(vehicle.charge.12v.stop) 2025-02-07 14:03:46.394 GMT D (1230994) events: Signal(vehicle.charge.12v.start) 2025-02-07 14:04:06.394 GMT D (1250994) events: Signal(vehicle.charge.12v.stop) 2025-02-07 14:04:09.954 GMT D (1254554) events: Signal(vehicle.gear.reverse) 2025-02-07 14:04:16.394 GMT D (1260994) events: Signal(vehicle.charge.12v.start) 2025-02-07 14:04:28.064 GMT D (1272664) events: Signal(vehicle.gear.forward)
At 14:04:29 I connected to home wifi.
You should also have a look at the general 12V level behaviour, e.g. using the 12V chart plugin or creating a chart from the MQTT metric.
I recorded the attached 12v profile on the 7th via MQTT. It was 12.2 at 13:17, and briefly 11.4 at 13:43. The 14:02 dip is not visible. My battery was new in November 2023.
When using V2/MQTT, consider raising the update interval to get a higher time resolution.
What interval is sufficiently frequent? This is what I have set.
updatetime.charging: 60 updatetime.connected: 300 updatetime.idle: 600 updatetime.keepalive: 1780 updatetime.on: 120
Btw, also consider shortening the file logging sync period, 30 seconds is rather high.
I've now set log flush to 1 second.
On the 12V shutdown: even with 30 seconds log flushing, you would have seen the log entries for a shutdown condition, unless you configured the shutdown delay to 0 (default is 2 minutes).
I have no specific values set in vehicle.12v.*, so I'm using default behaviour. Which I think disables auto-shutdown.
That is, if the 12V level wasn't suddenly getting drastically low, i.e. too low within seconds to keep the ESP32 in operation. That could explain the freeze. Not sure how low that would need to have been. I'd check for another potential source of such a sudden voltage drop: a mechanical/electrical issue with the OBD connector or cable.
How would the V3.3 hardware react when power is completely removed (12V goes to zero) and then restored (back to 12V)? I would hope it treats it as a cold start, and begins to boot up. But I didn't see that in the log. This also raises the question of capacitance to ride out brief interruptions. It appears there is 470uF between 12V/5V and GND, if I'm reading it right. I'm not sure what time period that could supply power for.
If for example there is a lose wire in the connection, that occasionally causes a short circuit, that would both explain the module freeze and the car fault.
It would. In the Leaf the OBD port is plastic mounted on plastic, and not particularly robust. I haven't seen inside the cable.
Chris
Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it.
I did indeed have B2604-00, along with nineteen others. Most of these mention CAN errors, and it seems plausible that low 12v could be a common cause.
Do you think this rules out a poor OVMS OBDII connection? I'm thinking if I have high resistance in that connector, then OVMS will experience low voltage but the rest of the car modules will have good voltage.
However I see codes that suggest communication errors between Nissan modules: C118C-01 ABS Brake: Malfunction is detected in VCM system. Control module communication issue. B2064-00 BCM Shift PN Diag CAN: Park-Neutral position switch signal discrepancy C1A70-01 BRAKE: Malfunction is detected in ABS actuator control unit system U1266-02 MULTI AV: Malfunction is detected between the AV control unit and TCU U0428-00 AVM: Invalid data received from steering angle sensor module
So I'm thinking perhaps the whole car briefly had low voltage.
To try to fix this, I cleaned the 12v battery terminals and performed a long charge. After clearing the codes, I have only two codes that reappear.
P317E-00 EV/HEV HV Battery System EVC-249 (perhaps caused by #1061 [1]) U1A06-15 TCU Communication incorrect calibration (probably because I've removed its antenna)
Chris
Links:
[1] https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/1061
How are we going with this investigation?
I've been following along mostly and have been periodically going over the poller code trying to work out if there are any points where there could be timing issues with long-held mutexes (or even deadlocks). I did push up some small tweaks recently but there was no aha! moment.
I have been working on some changes that would move forward on the idea of building a vehicle implementation from duktape scripts... and I had been getting some points where ovms went berserk, kicked out the ssh session and stopped responding on ssh http but then eventually came back (without a reset) after some minutes. The script was simply adding a new PollSeriesEntry which then uses the dbc decoder (with improvements) to decode to metrics, noting that the script is setup only and that there are no call-backs into the duktape engine/task.
Anyway, those patches mentioned above seem to have resolved that issue with the hangups which is why I made the p/r.
BTW I have been running my Ioniq5 with the latest of the timing patches for a while now.
Because of the correlation of the bus issues with the poller changes, I am still concerned that the poller changes are contributing to the problem (even if not directly causing it), so would be happy to chase down any leads people might have.
//.ichael
On Sat, 22 Feb 2025 at 02:52, Chris Box via OvmsDev < ovmsdev@lists.openvehicles.com> wrote:
Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it.
I did indeed have B2604-00, along with nineteen others. Most of these mention CAN errors, and it seems plausible that low 12v could be a common cause.
Do you think this rules out a poor OVMS OBDII connection? I'm thinking if I have high resistance in that connector, then OVMS will experience low voltage but the rest of the car modules will have good voltage.
However I see codes that suggest communication errors between Nissan modules: C118C-01 ABS Brake: Malfunction is detected in VCM system. Control module communication issue. B2064-00 BCM Shift PN Diag CAN: Park-Neutral position switch signal discrepancy C1A70-01 BRAKE: Malfunction is detected in ABS actuator control unit system U1266-02 MULTI AV: Malfunction is detected between the AV control unit and TCU U0428-00 AVM: Invalid data received from steering angle sensor module
So I'm thinking perhaps the whole car briefly had low voltage.
To try to fix this, I cleaned the 12v battery terminals and performed a long charge. After clearing the codes, I have only two codes that reappear.
P317E-00 EV/HEV HV Battery System EVC-249 (perhaps caused by #1061 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/1061> ) U1A06-15 TCU Communication incorrect calibration (probably because I've removed its antenna)
Chris
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Michael,
are you aware of these new findings by Richard Taylor?
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980#...
Regards, Michael
Am 22.03.25 um 03:26 schrieb Michael Geddes via OvmsDev:
How are we going with this investigation?
I've been following along mostly and have been periodically going over the poller code trying to work out if there are any points where there could be timing issues with long-held mutexes (or even deadlocks). I did push up some small tweaks recently but there was no aha! moment.
I have been working on some changes that would move forward on the idea of building a vehicle implementation from duktape scripts... and I had been getting some points where ovms went berserk, kicked out the ssh session and stopped responding on ssh http but then eventually came back (without a reset) after some minutes. The script was simply adding a new PollSeriesEntry which then uses the dbc decoder (with improvements) to decode to metrics, noting that the script is setup only and that there are no call-backs into the duktape engine/task. Anyway, those patches mentioned above seem to have resolved that issue with the hangups which is why I made the p/r. BTW I have been running my Ioniq5 with the latest of the timing patches for a while now.
Because of the correlation of the bus issues with the poller changes, I am still concerned that the poller changes are contributing to the problem (even if not directly causing it), so would be happy to chase down any leads people might have.
//.ichael
On Sat, 22 Feb 2025 at 02:52, Chris Box via OvmsDev <ovmsdev@lists.openvehicles.com> wrote:
Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it.I did indeed have B2604-00, along with nineteen others. Most of these mention CAN errors, and it seems plausible that low 12v could be a common cause. Do you think this rules out a poor OVMS OBDII connection? I'm thinking if I have high resistance in that connector, then OVMS will experience low voltage but the rest of the car modules will have good voltage. However I see codes that suggest communication errors between Nissan modules: C118C-01 ABS Brake: Malfunction is detected in VCM system. Control module communication issue. B2064-00 BCM Shift PN Diag CAN: Park-Neutral position switch signal discrepancy C1A70-01 BRAKE: Malfunction is detected in ABS actuator control unit system U1266-02 MULTI AV: Malfunction is detected between the AV control unit and TCU U0428-00 AVM: Invalid data received from steering angle sensor module So I'm thinking perhaps the whole car briefly had low voltage. To try to fix this, I cleaned the 12v battery terminals and performed a long charge. After clearing the codes, I have only two codes that reappear. P317E-00 EV/HEV HV Battery System EVC-249 (perhaps caused by #1061 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/1061>) U1A06-15 TCU Communication incorrect calibration (probably because I've removed its antenna) Chris _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
Nope, I wasn't. Thanks. I'll get onto the work-around config.
I'm now subscribed to that thread.
//.ichael
On Sat, 22 Mar 2025 at 16:44, Michael Balzer via OvmsDev < ovmsdev@lists.openvehicles.com> wrote:
Michael,
are you aware of these new findings by Richard Taylor?
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980#...
Regards, Michael
Am 22.03.25 um 03:26 schrieb Michael Geddes via OvmsDev:
How are we going with this investigation?
I've been following along mostly and have been periodically going over the poller code trying to work out if there are any points where there could be timing issues with long-held mutexes (or even deadlocks). I did push up some small tweaks recently but there was no aha! moment.
I have been working on some changes that would move forward on the idea of building a vehicle implementation from duktape scripts... and I had been getting some points where ovms went berserk, kicked out the ssh session and stopped responding on ssh http but then eventually came back (without a reset) after some minutes. The script was simply adding a new PollSeriesEntry which then uses the dbc decoder (with improvements) to decode to metrics, noting that the script is setup only and that there are no call-backs into the duktape engine/task.
Anyway, those patches mentioned above seem to have resolved that issue with the hangups which is why I made the p/r.
BTW I have been running my Ioniq5 with the latest of the timing patches for a while now.
Because of the correlation of the bus issues with the poller changes, I am still concerned that the poller changes are contributing to the problem (even if not directly causing it), so would be happy to chase down any leads people might have.
//.ichael
On Sat, 22 Feb 2025 at 02:52, Chris Box via OvmsDev < ovmsdev@lists.openvehicles.com> wrote:
Check your DTCs with leafspy, if it shows a bunch of DTCs including a B2604 BCM Shift PN diag, then likely low 12v, try a 24 hr charge or replace it.
I did indeed have B2604-00, along with nineteen others. Most of these mention CAN errors, and it seems plausible that low 12v could be a common cause.
Do you think this rules out a poor OVMS OBDII connection? I'm thinking if I have high resistance in that connector, then OVMS will experience low voltage but the rest of the car modules will have good voltage.
However I see codes that suggest communication errors between Nissan modules: C118C-01 ABS Brake: Malfunction is detected in VCM system. Control module communication issue. B2064-00 BCM Shift PN Diag CAN: Park-Neutral position switch signal discrepancy C1A70-01 BRAKE: Malfunction is detected in ABS actuator control unit system U1266-02 MULTI AV: Malfunction is detected between the AV control unit and TCU U0428-00 AVM: Invalid data received from steering angle sensor module
So I'm thinking perhaps the whole car briefly had low voltage.
To try to fix this, I cleaned the 12v battery terminals and performed a long charge. After clearing the codes, I have only two codes that reappear.
P317E-00 EV/HEV HV Battery System EVC-249 (perhaps caused by #1061 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/1061> ) U1A06-15 TCU Communication incorrect calibration (probably because I've removed its antenna)
Chris
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 2025-03-22 02:26, Michael Geddes wrote:
How are we going with this investigation?
Good question. I've been quiet while I progressed the 12v theory. Currently the code only tracks average 12v, so I implemented code to also record the lowest 12v observed. This value is then reported as an MQTT metric, and also log entries are created every time it reaches a new low.
I observed this for a couple of weeks, and saw 12v dropping below 11.8 while the average was still up at 12.6 or more:
With normal OVMS only the green line's metrics are reported. The yellow one is what I've added.
I then replaced the conventional lead acid with a new AGM, to benefit from its low internal resistance.
The difference can be seen clearly. The change happened on 12th March.
Since I've been using the AGM I haven't experienced a dashboard error. It's early days of course; time will tell.
Since the tracking of lowest 12v seems to be useful, I plan to create a PR for this part.
Chris
On 2025-03-28 18:15, Chris Box via OvmsDev wrote:
Since the tracking of lowest 12v seems to be useful, I plan to create a PR for this part.
This is now published as PR#1125 [1].
Happy to make any tweaks needed.
Chris
Links:
[1] https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1125
participants (4)
-
Chris Box -
Dan Edwards -
Michael Balzer -
Michael Geddes