- OvmsDev - Open Vehicles

Urgent server issue: Apple push notification API deprecated
by Michael Balzer 20 May '25

20 May '25

A user just reported he no longer gets any iOS notifications, seems to have begun ~2-3 days ago. The log shows: 2025-05-19 12:50:32.140969 +0200 info main: - - - msg apns processing queue for gateway.push.apple.com 2025-05-19 12:50:32.571275 +0200 error main: - - - connection to apns FAILED: EOF during handshake 2025-05-19 12:50:32.571384 +0200 error main: - - - msg apns processing ABORT for gateway.push.apple.com: connection closed I've found this forum entry: https://developer.apple.com/forums/thread/784585?answerId=839840022#8398400… So it seems Apple has finally adopted the Google way of deprecating established services without need. Mark, I assume this affects your server as well, if not now then in the near future. Probably the iOS App doesn't need an update, but I haven't checked that. Is anyone able to help with updating the server to the new APNS API? I don't have any iOS devices, so testing is difficult for me. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

2 3

Re: [Ovmsdev] System diagram?
by Dave Pawson 28 Apr '25

28 Apr '25

On Mon, 28 Apr 2025 at 03:35, Mark Webb-Johnson < mark.johnson(a)network-box.com> wrote: > Dave, > > We have: > > https://www.openvehicles.com/developers > > > as a starting point, > which provides a basic system hardware diagram, though it's rather heavy on acronyms! Are all parts used? A-D & D-A, encryption, touch sensor - I'm guessing this diagram is from the makers literature? > and the developer’s guide: > > > https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWE… > > > has detailed information on each hardware component. > > But I’m not aware of any system / software architecture diagrams. > I had hoped for a modular structure to see how the sw interfaced, perhaps to pick up on some lesser parts to get into it. I worked with low level stuff 40 years ago, asm and C. More recently Python and scripting on my Fedora box. What sort of development environment do you use please? Are there data sets available for different cars for testing? regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ.

2 5

System diagram?
by Dave Pawson 28 Apr '25

28 Apr '25

New to this project. Are there any system / software architecture diagrams around please, to let a newbie get his/her head round the software and hw interfaces? Thanks -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ.

2 2

Nissan Leaf ZE1 - Total loss of power
by Wayne Love 12 Apr '25

12 Apr '25

Just want to report another incident with a Leaf. My wife was driving to work this morning, according to her the Leaf started to display warning messages and then did a full HV power shutdown with a "Service EV System" "No Power" error. When I was able to get to her there were a number of DTC's being reported, I was not able to clear these with LeafSpy even with the OVMS module unplugged and had to disconnect the 12v battery. This behavior is consistent with the symptoms that I saw when the OVMS was crashing with a buffer overrun. I'll have a look at the logs when she gets home tonight to see if there are any indicators as to what is going on. Let me know if there are any specific investigative steps that I should be following. Thanks Wayne

4 6

Integration of Simcom 7670 and changes to Simcom Powering
by Info Zeitnitz 07 Apr '25

07 Apr '25

Dear all, I finished to integrate the Simcom 7670 modem into the OVMS code. See https://github.com/zbchristian/Open-Vehicle-Monitoring-System-3.git branch update_cellular. Modem Powering =============== I had problems to get the 7670 working with the current code. The modem was stuck in a power cycle loop. I checked the Simcom documentation for the 4 models 5360, 7000 series, 7600, 7670 and the powering procedure via the PWRKEY pin is the same, but with different on/off timing. Depending on the hardware, the PWRKEY can be inverted as well. This is the case for my Lilygo TCall board, but I think not for the OVMS HW versions. At least version 3.1 connects the corresponding MAX7317 pin directly to the modem. Assuming, that all hardware versions use the PWRKEY procedure for powering, I streamlined the code and moved the corresponding functions into separate files (simcom_powering.cpp and simcom_powering.h). This avoids the duplication of the code. All this leads to substantial changes in ovms_cellular and ovms_cellular_modem_driver as well. The code works now perfectly for the 7670, but testing is required for all other models. If my assumptions about the OVMS HW versions are not correct, or the modems do not work as documented, some modifications might be needed. GNSS Location ============ The 7670 no longer accepts the currently used AT commands to obtain the location as a GRMC sentence. So, I added code to the new 7670 class to request the location via the AT+CGNSSINFO command. Since this has to be send explicitly again and again, I implemented a corresponding call in the StatusPoller of the 7670. All the NMEA related code has been adapted to handle the corresponding CGNSSINFO response. In conclusion, before doing a pull request, it would make sense that the code is tested with the other hardware and modem models. So, tell me what you think and if the general strategy of the mods make sense to you. Best regards Christian

3 12

Duktape support for polling lists - p/r submitted.
by Michael Geddes 06 Apr '25

06 Apr '25

Hi All, This is the P/R here: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1126 This is really where I was heading with the Poller implementation, in that it allows user-space additions to the polling infrastructure. The complexity of the specification means that it's really more appropriate to Duktape than to a cli script. It is definitely "a lot", and I suspect/suggest that it would be deferred until a release is made. I'm quite pleased with this implementation which has already been very much improved by people's observations and suggestions: * The Once-Off command call is the only one that calls back to duktape * The Decoding re-uses the DBC internals to achieve programmatic decoding. * It extends the various Duktape functions to control/interact with various aspects of the vehicle and poller (while giving necessary isolation). For anybody interested in the idea of being able to make a vehicle implementation in Duktape, this is worth having a look at! I do have some DBC Duktape commands ready to go as well. There is still some bits to do with the battery v/temp arrays that I've not quite covered. I have some ideas but they are not quite there yet. In the implementation I have already abstracted the destination 'Metric' and this is where this would fit in - ie the ability to populate the v/t array separately and then have some way of triggering the storing of those values. The internals are the BmsRestartCellTemperatures() and BmsSetCellTemperature( ) and other related functions which would need to be somehow called. //.ichael G.

1 0

Another incident
by Chris Box 05 Apr '25

05 Apr '25

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

4 12

TCP/IP Assertion fail / stack trace
by Michael Geddes 29 Mar '25

29 Mar '25

I've been having a few reboots due to aborts. Any ideas on where I might look at for this one which is in the TCPIP stack: //. ---8<------ 0x4008ddae is in invoke_abort (/home/michaelg/esp/esp-idf/components/esp32/panic.c:156). 151 #endif 152 while (1) { 153 if (esp_cpu_in_ocd_debug_mode()) { 154 __asm__ ("break 0,0"); 155 } 156 *((int *) 0) = 0; 157 } 158 } 159 160 void abort() 0x4008e049 is in abort (/home/michaelg/esp/esp-idf/components/esp32/panic.c:171). 166 * don't overwrite that. 167 */ 168 if (esp_reset_reason_get_hint() == ESP_RST_UNKNOWN) { 169 esp_reset_reason_set_hint(ESP_RST_PANIC); 170 } 171 invoke_abort(); 172 } 173 174 175 static const char *edesc[] = { 0x400925ff is in multi_heap_assert (/home/michaelg/esp/esp-idf/components/heap/multi_heap_platform.h:54). 49 #ifndef NDEBUG 50 if(!condition) { 51 #ifndef CONFIG_OPTIMIZATION_ASSERTIONS_SILENT 52 ets_printf(format, line, address); 53 #endif // CONFIG_OPTIMIZATION_ASSERTIONS_SILENT 54 abort(); 55 } 56 #else // NDEBUG 57 (void) condition; 58 #endif // NDEBUG 0x40092629 is in get_prev_free_block (/home/michaelg/esp/esp-idf/components/heap/multi_heap.c:187). 182 static heap_block_t *get_prev_free_block(heap_t *heap, const heap_block_t *block) 183 { 184 assert(!is_first_block(heap, block)); /* can't look for a block before first_block */ 185 186 for (heap_block_t *b = &heap->first_block; b != NULL && b < block; b = b->next_free) { 187 MULTI_HEAP_ASSERT(is_free(b), b); // Block should be free 188 if (b->next_free == NULL || b->next_free >= block) { 189 if (is_free(block)) { 190 /* if block is on freelist, 'b' should be the item before it. */ 191 MULTI_HEAP_ASSERT(b->next_free == block, &b->next_free); 0x40092a9a is in multi_heap_free_impl (/home/michaelg/esp/esp-idf/components/heap/multi_heap.c:484). 479 MULTI_HEAP_ASSERT(!is_first_block(heap, pb), pb); // block should not be first block 480 481 heap_block_t *next = get_next_block(pb); 482 483 /* Update freelist pointers */ 484 heap_block_t *prev_free = get_prev_free_block(heap, pb); 485 // freelist validity check 486 MULTI_HEAP_ASSERT(prev_free->next_free == NULL || prev_free->next_free > pb, &prev_free->next_free); 487 pb->next_free = prev_free->next_free; 488 prev_free->next_free = pb; 0x4009302e is in multi_heap_free (/home/michaelg/esp/esp-idf/components/heap/multi_heap_poisoning.c:225). 220 #ifdef SLOW 221 /* replace everything with FREE_FILL_PATTERN, including the poison head/tail */ 222 memset(head, FREE_FILL_PATTERN, 223 head->alloc_size + POISON_OVERHEAD); 224 #endif 225 multi_heap_free_impl(heap, head); 226 227 multi_heap_internal_unlock(heap); 228 } 229 0x4008449d is in heap_caps_free (/home/michaelg/esp/esp-idf/components/heap/heap_caps.c:268). 263 ptr = (void *)dramAddrPtr[-1]; 264 } 265 266 heap_t *heap = find_containing_heap(ptr); 267 assert(heap != NULL && "free() target pointer is outside heap areas"); 268 multi_heap_free(heap->heap, ptr); 269 } 270 271 IRAM_ATTR void *heap_caps_realloc( void *ptr, size_t size, int caps) 272 { 0x40084a91 is in _free_r (/home/michaelg/esp/esp-idf/components/newlib/syscalls.c:42). 37 return heap_caps_malloc_default( size ); 38 } 39 40 void IRAM_ATTR _free_r(struct _reent *r, void* ptr) 41 { 42 heap_caps_free( ptr ); 43 } 44 45 void* IRAM_ATTR _realloc_r(struct _reent *r, void* ptr, size_t size) 46 { 0x40118a48 is in mem_free (/home/michaelg/esp/esp-idf/components/lwip/lwip/src/core/mem.c:176). 171 LWIP_ASSERT("rmem == MEM_ALIGN(rmem)", (rmem == LWIP_MEM_ALIGN(rmem))); 172 #if LWIP_STATS && MEM_STATS 173 rmem = (u8_t*)rmem - MEM_LIBC_STATSHELPER_SIZE; 174 MEM_STATS_DEC_USED(used, *(mem_size_t*)rmem); 175 #endif 176 mem_clib_free(rmem); 177 } 178 179 #elif MEM_USE_POOLS 180 0x40118a9f is in do_memp_free_pool (/home/michaelg/esp/esp-idf/components/lwip/lwip/src/core/memp.c:432). 427 #endif 428 429 #if MEMP_MEM_MALLOC 430 LWIP_UNUSED_ARG(desc); 431 SYS_ARCH_UNPROTECT(old_level); 432 mem_free(memp); 433 #else /* MEMP_MEM_MALLOC */ 434 memp->next = *desc->tab; 435 *desc->tab = memp; 436 0x40118b17 is in memp_free (/home/michaelg/esp/esp-idf/components/lwip/lwip/src/core/memp.c:489). 484 485 #ifdef LWIP_HOOK_MEMP_AVAILABLE 486 old_first = *memp_pools[type]->tab; 487 #endif 488 489 do_memp_free_pool(memp_pools[type], mem); 490 491 #ifdef LWIP_HOOK_MEMP_AVAILABLE 492 if (old_first == NULL) { 493 LWIP_HOOK_MEMP_AVAILABLE(type); 0x4011e911 is in sys_timeouts_mbox_fetch (/home/michaelg/esp/esp-idf/components/lwip/lwip/src/core/timeouts.c:354). 349 if (handler != NULL) { 350 LWIP_DEBUGF(TIMERS_DEBUG, ("sct calling h=%s arg=%p\n", 351 tmptimeout->handler_name, arg)); 352 } 353 #endif /* LWIP_DEBUG_TIMERNAMES */ 354 memp_free(MEMP_SYS_TIMEOUT, tmptimeout); 355 if (handler != NULL) { 356 #if !NO_SYS 357 /* For LWIP_TCPIP_CORE_LOCKING, lock the core before calling the 358 timeout handler function. */ 0x401186f8 is in tcpip_thread (/home/michaelg/esp/esp-idf/components/lwip/lwip/src/api/tcpip.c:109). 104 LOCK_TCPIP_CORE(); 105 while (1) { /* MAIN Loop */ 106 UNLOCK_TCPIP_CORE(); 107 LWIP_TCPIP_THREAD_ALIVE(); 108 /* wait for a message, timeouts are processed while waiting */ 109 TCPIP_MBOX_FETCH(&mbox, (void **)&msg); 110 LOCK_TCPIP_CORE(); 111 if (msg == NULL) { 112 LWIP_DEBUGF(TCPIP_DEBUG, ("tcpip_thread: invalid message: NULL\n")); 113 LWIP_ASSERT("tcpip_thread: invalid message", 0);

1 0

Leaf AZE1 Can1 stuck after poll 7BB group 61
by Wayne Love 25 Mar '25

25 Mar '25

Using Leafspy I can see that it's using the following poll and response to get the SOH of the batteries 1742706668.884315 1R11 79B 02 21 61 00 00 00 00 00 1742706668.892602 1R11 7BB 11 4b 61 61 1a cc 23 70 However, when try to do the same poll with OVMS using the following code... static const OvmsPoller::poll_pid_t obdii_polls[] = { // BUS 2 { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, VIN_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // VIN [19] { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIEXTENDED, QC_COUNT_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // QC [2] { CHARGER_TXID, CHARGER_RXID, VEHICLE_POLL_TYPE_OBDIIEXTENDED, L1L2_COUNT_PID, { 0, 900, 0, 0 }, 2, ISOTP_STD }, // L0/L1/L2 [2] // BUS 1 { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // bat [39/41] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // battery voltages [196] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x06, { 0, 60, 0, 60 }, 1, ISOTP_STD }, // battery shunts [96] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x04, { 0, 300, 0, 300 }, 1, ISOTP_STD }, // battery temperatures [14] { BMS_TXID, BMS_RXID, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x61, { 0, 300, 0, 300 }, 1, ISOTP_STD }, // SOH for AZE1 POLL_LIST_END }; It results a CAN bus error 2025-03-23 13:48:10.648 AEDT E (11528) esp32can: can1 stuck bus-off error state (errflags=0x00040cab) detected - resetting bus I'm new to this but from what I can work out what I am doing should work. Any suggestions? Thanks Wayne

3 10

SDCard speeds.
by Michael Geddes 24 Mar '25

24 Mar '25

I while ago I was talking about issues with my SDCard, and I've just had a friend have some similar issues. Both these issues were fixed with setting the max frequency to 15MHz config set sdcard maxfreq.khz 15000 This does end up making things a bit slower, but at least it works. The reported max of my card is 25Mhz. I'm concerned that the default is misbehaving. Is this a software issue? or is it a hardware issue? //.ichael

3 2