After upgrading from 2.2.0 to 2.3.0, my OVMS module started crashing/rebooting. Version 2.2.0 ran fine for a long time with no issues. The crash log points to the new ticker.10 → sendBulkTelemetry() bulk HTTP POST as the cause.
Environment
ovms-link version: 2.3.0
OVMS firmware: 3.3.006-168-g8af7d19a5/ota_0/eap
Modem: SIM7600
Cellular signal: weak/unstable in my usual driving area (Holagram SIM), probably related to switch between moded/phone's Hotspot.
Boot crash massage
Detected boot reason: Crash (12/12)
Reset reason: Task watchdog (6)
Crash counters: 1 total; 0 early
Last crash: abort() was called on core 0
Current task on core 0: IDLE0; 432 stack bytes free
Current task on core 1: IDLE1; 520 stack bytes free
Backtrace:
0x4008dd2e 0x4008dfc9 0x4010bd00 0x4008418e
Event: ticker.1@ovms-server-v2 46 secs
WDT tasks: OVMS DukTape
WDT tasks: OVMS DukTape shows the task watchdog fired on the script engine itself, and Event: ticker.1@ovms-server-v2 46 secs shows the DukTape task hadn't responded for 46 seconds. That lines up with the new code in 2.3.0:
subscribe('ticker.10', sendBulkTelemetry)
sendBulkTelemetry() calls HTTP.Request() with a POST body to /1/tlm/bulk every 10 seconds while active. The OVMS scripting docs note that HTTPS requests can take up to 12 seconds on an idle module — but on a weak/unstable cellular connection it can take much longer. Since HTTP.Request() runs on the same DukTape task that handles all other events (including ticker.1, which drives the rest of the plugin), a slow request blocks the whole script engine long enough for the task watchdog to trigger abort() and reboot the module.
In 2.2.0 there was no recurring bulk POST like this, which is probably why it never crashed for me.
Probabaly the most easier and quick fix is to adjust MAX_BULK_BATCH_SIZE but its still not fixing source caused by "SSL requests (https) can take up to 12 seconds on an idle module"
After upgrading from 2.2.0 to 2.3.0, my OVMS module started crashing/rebooting. Version 2.2.0 ran fine for a long time with no issues. The crash log points to the new ticker.10 → sendBulkTelemetry() bulk HTTP POST as the cause.
Environment
ovms-link version: 2.3.0
OVMS firmware: 3.3.006-168-g8af7d19a5/ota_0/eap
Modem: SIM7600
Cellular signal: weak/unstable in my usual driving area (Holagram SIM), probably related to switch between moded/phone's Hotspot.
Boot crash massage
WDT tasks: OVMS DukTape shows the task watchdog fired on the script engine itself, and Event: ticker.1@ovms-server-v2 46 secs shows the DukTape task hadn't responded for 46 seconds. That lines up with the new code in 2.3.0:
subscribe('ticker.10', sendBulkTelemetry)sendBulkTelemetry() calls HTTP.Request() with a POST body to /1/tlm/bulk every 10 seconds while active. The OVMS scripting docs note that HTTPS requests can take up to 12 seconds on an idle module — but on a weak/unstable cellular connection it can take much longer. Since HTTP.Request() runs on the same DukTape task that handles all other events (including ticker.1, which drives the rest of the plugin), a slow request blocks the whole script engine long enough for the task watchdog to trigger abort() and reboot the module.
In 2.2.0 there was no recurring bulk POST like this, which is probably why it never crashed for me.
Probabaly the most easier and quick fix is to adjust MAX_BULK_BATCH_SIZE but its still not fixing source caused by "SSL requests (https) can take up to 12 seconds on an idle module"