Chris,

The best option to capture anything going on with the bus over the night is activating an unfiltered can log to the SD card.
Do you mean setting the global log level to verbose?

No, I mean activating a CAN logger. You can simply start one on the monitor channel, which outputs the CAN log to the system log:

OVMS# log level verbose canlog-monitor
OVMS# can log start monitor crtd

For more info on CAN logging, see the user guide: https://docs.openvehicles.com/en/latest/crtd/can_logging.html

I've now added output of the TX queue fill level to the CAN status outputs, that should help identifying the effect. Hint: you can use "git pull --rebase --autostash" to merge this with your local changes.

On my UpMiiGo (which switches off the bus), the ESP32CAN most of the time recognizes an immediate failure for a TX with the vehicle being off. That means the TX buffer (in the controller) gets cleared immediately, with an immediate "TX_Fail" result for the frame. Ideally that would be the case always while the bus is off.

But the ESP32CAN controller sometimes tries to send the frame, waiting for an ack, repeating the transmission and then ending up in the frame being stuck in the TX buffer. Then the TX queue (software) gets filled with the status ping request frame from there, up to the 30 frames capacity of the TX queue, then counting TX overflows.

This continues until the ESP32CAN, due to unknown reasons, thinks it could send the frame. The TX queue then gets flushed immediately, with the frames appearing as being sent successfully (although there is no ECU active, the bus is still off).

After the queue has been cleared, this loop starts over.

So it may happen, that the TX queue gets filled, and the ESP32CAN thinks it can send frames, even while the bus is shut off.

Reading the Leaf code, I don't see any regular status ping polling, but it may still be, the Leaf queued some TX packets just before switching off the vehicle. Those would stick in the queue until the ESP32CAN enters the state described above, so actually tries to send the frames queued.

You should be able to determine if that's the case from the TX fill level being logged & displayed in the status output.

Regards,
Michael


Am 28.01.25 um 00:20 schrieb Chris Box:

On 2025-01-27 21:50, Michael Balzer via OvmsDev wrote:

0x8048d9 was logged twice last night while parked and locked, with nothing going on

So please verify there really was nothing going on. Maybe you didn't see the vehicle was actually active due to reduced log levels or missing log entries in the leaf code?
 
 
Logging to SD card was globally at info level, except with debug for can, esp32can, mcp2515 & events. Here's all I saw:
 

2025-01-26 19:56:25.997 GMT I (92702057) housekeeping: 2025-01-26 19:56:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285676)
2025-01-26 20:01:25.997 GMT I (93002057) housekeeping: 2025-01-26 20:01:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285644)
2025-01-26 20:03:57.337 GMT E (93153387) can: can1: intr=4800273 rxpkt=4799065 txpkt=900 errflags=0x8048d9 rxerr=0 txerr=128 rxinval=0 rxovr=5 txovr=0 txdelay=51 txfail=281 wdgreset=0 errreset=0
2025-01-26 20:03:58.337 GMT E (93154387) can: can1: intr=4800319 rxpkt=4799065 txpkt=901 errflags=0x8048d9 rxerr=0 txerr=135 rxinval=0 rxovr=5 txovr=0 txdelay=51 txfail=282 wdgreset=0 errreset=0
2025-01-26 20:06:05.337 GMT E (93281387) can: can1: intr=4800334 rxpkt=4799065 txpkt=902 errflags=0x8048d9 rxerr=0 txerr=134 rxinval=0 rxovr=5 txovr=0 txdelay=51 txfail=289 wdgreset=0 errreset=0
2025-01-26 20:06:26.007 GMT I (93302057) housekeeping: 2025-01-26 20:06:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285676)
2025-01-26 20:11:25.997 GMT I (93602057) housekeeping: 2025-01-26 20:11:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285612)

2025-01-26 23:16:26.017 GMT I (104702057) housekeeping: 2025-01-26 23:16:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285488)
2025-01-26 23:21:26.017 GMT I (105002057) housekeeping: 2025-01-26 23:21:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285456)
2025-01-26 23:23:04.347 GMT E (105100387) can: can1: intr=4801533 rxpkt=4799065 txpkt=903 errflags=0x8048d9 rxerr=0 txerr=131 rxinval=0 rxovr=5 txovr=0 txdelay=51 txfail=888 wdgreset=0 errreset=0
2025-01-26 23:26:26.017 GMT I (105302057) housekeeping: 2025-01-26 23:26:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285488)
2025-01-26 23:31:26.017 GMT I (105602057) housekeeping: 2025-01-26 23:31:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285456)


The best option to capture anything going on with the bus over the night is activating an unfiltered can log to the SD card.
 
Do you mean setting the global log level to verbose?
 
 
The normal behaviour of a parked car is doing 12V battery maintenance every few hours, i.e. topping up the 12V battery from the main battery. That will normally also cause a limited CAN wakeup of the ECUs taking part in that process.
 
With the MQTT metrics I observe charging of 12V ceased at 18:40. The battery then went into gradual decline starting at 12.8V until it reached 12.4V the next morning.
 
Another option is some plugin or script doing a wakeup to query values.
 
The only activity I have is an MQTT idle update interval of 10 minutes. Overnight this just sends things like free memory, 12V voltage and signal strength.
 
As you don't see any issues yet, proceed with both buses active to see if the new timing solved that.
 
Both buses now set to active.

Thanks
Chris

-- 
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926