- OvmsDev - Open Vehicles

Configuring notifations
by Chris van der Meijden 31 Aug '20

31 Aug '20

I just finished the implementation of the "charging detection" for the komfort-can VW e-Up. Works like charm :-) (Msg ID 0x61C, d2. No Ampere and Volt yet). Because I have email notifications activated I now receive mails when I start or end charging. For me it is enough to see the charging in the app and I would like to configure the notifications to not sent me messages on vehicle.charge.start, vehicle.charge.state and vehicle.charge.stop I found this thread from 2018: http://lists.openvehicles.com/pipermail/ovmsdev/2018-May/004980.html and I found the "Notification filtering" and "Event filtering" under Config -> Notifications, but I did not see a way to disable an specific notification. Or just do not understand how. Am I overlooking something? Thanx Chris

3 5

lost important event => aborting
by Mark Webb-Johnson 31 Aug '20

31 Aug '20

A customer is reporting: Last crash: abort() was called on core 1 Backtrace: 0x4008e627 0x4008e8c1 0x400f2be4 0x400f3145 0x4014a7d1 0x401538b0 0x401082be 0x401092ed 0x401082be 0x40108430 0x4010a3bb 0x4010647a 0x400fb63f 0x400fb6ed Event: ticker.1@EventScript 0 secs Version: 3.2.014/ota_0/main (build idf v3.3.2-881-g22d636b Aug 4 2020 16:26:20) He is running a Nissan Leaf, with 3.2.014 firmware. Both v2 and v3 servers enabled, as well as Abrp and pushover. Trace is: Using elf file: 3.2.014.ovms3.elf 0x4008e627 is in invoke_abort (/home/openvehicles/build/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() 0x4008e8c1 is in abort (/home/openvehicles/build/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[] = { 0x400f2be4 is in CheckQueueOverflow(char const*, char*) (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_events.cpp:339). 334 // We've dropped a potentially important event, system is instable now. 335 // As the event queue is full, a normal reboot is no option, so… 336 ESP_LOGE(TAG, "%s: lost important event => aborting", from); 337 MyCommandApp.CloseLogfile(); 338 vTaskDelay(pdMS_TO_TICKS(100)); 339 abort(); 340 } 341 } 342 343 static void SignalScheduledEvent(TimerHandle_t timer) 0x400f3145 is in OvmsEvents::SignalEvent(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*, void (*)(char const*, void*), unsigned int) (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_events.cpp:417). 412 413 if (delay_ms == 0) 414 { 415 if (xQueueSend(m_taskqueue, &msg, 0) != pdTRUE) 416 { 417 CheckQueueOverflow("SignalEvent", msg.body.signal.event); 418 FreeQueueSignalEvent(&msg); 419 } 420 } 421 else 0x4014a7d1 is in OvmsWebServer::DestroyWebSocketHandler(WebSocketHandler*) (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_websockethandler.cpp:502). 497 498 // clear unqueued notifications if any: 499 MyNotify.ClearReader(m_client_slots[i].reader); 500 501 ESP_LOGD(TAG, "WebSocket[%p] handler %p closed; %d clients active", nc, handler, m_client_cnt); 502 MyEvents.SignalEvent("server.web.socket.closed", (void*)m_client_cnt); 503 504 break; 505 } 506 } 0x401538b0 is in OvmsWebServer::EventHandler(mg_connection*, int, void*) (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:534). 529 530 case MG_EV_CLOSE: // connection has been closed 531 { 532 if (handler) { 533 if (nc->flags & MG_F_IS_WEBSOCKET) 534 MyWebServer.DestroyWebSocketHandler((WebSocketHandler*)handler); 535 else 536 delete handler; 537 } 538 } 0x401082be is in mg_call (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2368). 2363 } 2364 #endif 2365 if (ev_handler != NULL) { 2366 unsigned long flags_before = nc->flags; 2367 size_t recv_mbuf_before = nc->recv_mbuf.len, recved; 2368 ev_handler(nc, ev, ev_data MG_UD_ARG(user_data)); 2369 recved = (recv_mbuf_before - nc->recv_mbuf.len); 2370 /* Prevent user handler from fiddling with system flags. */ 2371 if (ev_handler == nc->handler && nc->flags != flags_before) { 2372 nc->flags = (flags_before & ~_MG_CALLBACK_MODIFIABLE_FLAGS_MASK) | 0x401092ed is in mg_ws_handler (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:9950). 9945 } 9946 } 9947 9948 MG_INTERNAL void mg_ws_handler(struct mg_connection *nc, int ev, 9949 void *ev_data MG_UD_ARG(void *user_data)) { 9950 mg_call(nc, nc->handler, nc->user_data, ev, ev_data); 9951 9952 switch (ev) { 9953 case MG_EV_RECV: 9954 do { 0x401082be is in mg_call (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2368). 2363 } 2364 #endif 2365 if (ev_handler != NULL) { 2366 unsigned long flags_before = nc->flags; 2367 size_t recv_mbuf_before = nc->recv_mbuf.len, recved; 2368 ev_handler(nc, ev, ev_data MG_UD_ARG(user_data)); 2369 recved = (recv_mbuf_before - nc->recv_mbuf.len); 2370 /* Prevent user handler from fiddling with system flags. */ 2371 if (ev_handler == nc->handler && nc->flags != flags_before) { 2372 nc->flags = (flags_before & ~_MG_CALLBACK_MODIFIABLE_FLAGS_MASK) | 0x40108430 is in mg_close_conn (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2435). 2430 mg_ssl_if_conn_close_notify(conn); 2431 } 2432 #endif 2433 mg_remove_conn(conn); 2434 conn->iface->vtable->destroy_conn(conn); 2435 mg_call(conn, NULL, conn->user_data, MG_EV_CLOSE, NULL); 2436 mg_destroy_conn(conn, 0 /* destroy_if */); 2437 } 2438 2439 void mg_mgr_init(struct mg_mgr *m, void *user_data) { 0x4010a3bb is in mg_socket_if_poll (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:4049). 4044 4045 for (nc = mgr->active_connections; nc != NULL; nc = tmp) { 4046 tmp = nc->next; 4047 if ((nc->flags & MG_F_CLOSE_IMMEDIATELY) || 4048 (nc->send_mbuf.len == 0 && (nc->flags & MG_F_SEND_AND_CLOSE))) { 4049 mg_close_conn(nc); 4050 } 4051 } 4052 4053 return (time_t) now; 0x4010647a is in mg_mgr_poll (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2538). 2533 LOG(LL_ERROR, ("cannot poll: no interfaces")); 2534 return 0; 2535 } 2536 2537 for (i = 0; i < m->num_ifaces; i++) { 2538 now = m->ifaces[i]->vtable->poll(m->ifaces[i], timeout_ms); 2539 } 2540 return now; 2541 } 2542 0x400fb63f is in OvmsNetManager::MongooseTask() (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:733). 728 729 // Main event loop 730 while (m_mongoose_running) 731 { 732 // poll interfaces: 733 if (mg_mgr_poll(&m_mongoose_mgr, 250) == 0) 734 { 735 ESP_LOGD(TAG, "MongooseTask: no interfaces available => exit"); 736 break; 737 } 0x400fb6ed is in MongooseRawTask(void*) (/home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:715). 710 #ifdef CONFIG_OVMS_SC_GPL_MONGOOSE 711 712 static void MongooseRawTask(void *pvParameters) 713 { 714 OvmsNetManager* me = (OvmsNetManager*)pvParameters; 715 me->MongooseTask(); 716 } 717 718 void OvmsNetManager::MongooseTask() 719 { It seems to be a web socket (web ui?) connection went away, a logging message was produced, and that overflowed the queue. Perhaps the user is just logging too much? Can you log at debug level to web uI (or does it cause the problem I mentioned earlier about debug logging the debug logs)? Any ideas? Regards, Mark.

2 6

Hyundai Kona 2019
by Mark Webb-Johnson 30 Aug '20

30 Aug '20

Can someone with experience of this car help this guy out? https://www.openvehicles.com/node/2579 <https://www.openvehicles.com/node/2579> Hello I have now used the OVMS with hologram sim for 4-5 weeks and i get information about the battery charge door locked TPMS etc fine fine :-) , BUT there is nothing i can activate, not possible to lock/unlock doors, change or stop charging etc etc I have activate the pincode and i have tried also to do it via the messages but it just say failure.... I have not got any notifications either but perhaps there have not been any? :-) ........I just now read the documentation that says change charge settings its not currently supported, but lock the doors should work? and when will there be more functions? I asked the same questions n the forum for 2-3 weeks ago but no replies Kindest Liss Sweden Thanks, Mark

1 0

Re: [Ovmsdev] v3 MQTT messaging
by Derek Caudwell 30 Aug '20

30 Aug '20

Hi Michael, If I've understood correctly, the websocket overflow simply means the remainder of the v3 metrics are not being reported in the shell or logs. They are still being transmitted to the mqtt server sepcified. Cheers Derek

1 0

v3 MQTT messaging
by Derek Caudwell 29 Aug '20

29 Aug '20

Hi all, I've noticed that my mqtt metric messages are getting truncated, ie some messages are not sent by TransmitAllMetrics(). From the logs it is generating an overflow condition: 2020-08-30 07:42:37 NZST W (481206) websocket: WebSocketHandler[0x3f866d34]: job queue overflow detected 2020-08-30 07:42:37 NZST W (481376) websocket: WebSocketHandler[0x3f866d34]: job queue overflow resolved, 30 drops A short delay eg 10-25ms in the TransmitMetric() function resolves it, but there is probably a better approach? Kind regards Derek

2 1

Re: [Ovmsdev] OBD/UDS Poller receiver rework
by Derek Caudwell 28 Aug '20

28 Aug '20

All, I've included the ability to switch can bus to the Poller rework by adding an extra field to the PIDPollList structure. It should not break any vehicle specific code, but will throw a compile warning if the bus is not specified in the list. Once Michael has reviewed it, appreciate retesting. Note the changes to 0x22 message length required a code change in the Leaf as it uses an incoming message length test. May be worth checking other vehicle types for this. Hopefully these changes will resolve some of the potential reasons for the Leaf crashing the ovms module. Looking good so far 👍 Cheers Derek

1 0

New OVMS & ABRP advocacy by Andrew Till
by Michael Balzer 28 Aug '20

28 Aug '20

https://www.youtube.com/watch?v=-Dzp9Hi_CCE Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

lost important event => aborting
by Derek Caudwell 25 Aug '20

25 Aug '20

Hi Mark This looks like the same issue I have been having/trying to debug (re: frequent crashes thread). I had not realised I could get a more detailed trace. Does it have to be enabled prior to crash or can you enable it afterwards? On my local build I have implemented Michael's suggested change in event script task priority to 19 and disabled Mcp2515 error logging on buffer overflow, which has helped but not entirely resolved the issue. There are also some issues relating to polling in the Leaf because of the two buses I am working on, I think these may be unrelated to the event ticker crash messages though (which can happen when not using web ui as well). Kind regards Derek

2 1

OVMS Data Cable for Later Tesla Model S/X
by Mark Webb-Johnson 24 Aug '20

24 Aug '20

Annoyed with overpriced cables using X437A connector for later Model S and X cars, we made our own. OVMS Data Cable for Later Tesla Model S/X <https://www.fasttech.com/products/0/10070138/9730443-ovms-data-cable-for-la…> US$14.50, including basic shipping. The cable provides access to the three most useful CAN buses, for later Tesla Model S and X vehicles using Sumitomo 6098-5622 (X437A) connector. It also exposes CAN2+Body bus (but requires custom replacement of DB9 connector to use). Pinout: OVT2 6098-5622 DB9-F Signal --------- -------- -------- 18 7 CAN0-H 2 8 CAN2-H 6 1 K-Line 13 5 CAN1-H 19 2 CAN0-L 3 6 CAN2-L 20 3 GND 1 9 +12V 14 4 CAN1-L 9 n/c CAN2+Body (no connection at DB9-F) 10 n/c CAN2-Body (no connection at DB9-F) Cable: 1m in length, 11 core DB9-F: Moulded 6098-5622 Heat-shrink tubing to protect end of cable Label: "OVT2" in black-on-white lettering, shrink to cable This cable can be used to connect OVMS to a later Model S or X, or for general CAN bus hacking on those cars. Enjoy.

1 0

Hacking TPMS
by Mark Webb-Johnson 24 Aug '20

24 Aug '20

I’ve been spending the last month or so hacking away at TPMS. This has been an ongoing project for the Tesla Roadster that is finally coming to fruition. About a year or so ago, we already made changes to: Modify the Tesla Roadster cable to connect the k-line pin on the diagnostic connector through to the DB9 connector on OVMS. We labelled this cable ‘OVT1’. Modify the OVMS module to connect that k-line pin to GEP7. I’m now working on an optional expansion board that will include a little TJA1027T transceiver and map it to EXP1 and EXP2 (for async comms) and EGPIO8 (for enable/disable) on the ESP32 and MAX. This board will include a jumpered option for K-line master (one diode + one resistor), as well as jumpered powered selection (5v from usb, 5v regulated from car 12v, or direct car 12v) for the K-line bus. The hand-soldered prototype, using our breakout boards, works well and the K-line async comms works. The screenshot shows OVMS sending a 19 byte request to the ECU (0x0f 0x04 .... 0xf0) and the ECU responding 19 bytes (0x0f 0x05 ... 0xf0) with the 4 tyre IDs. There is a similar command to re-program the ECU with new IDs. On the firmware side, I am implementing a new vehicle independent ’tpms’ subsystem within OVMS (enabled via configureable option). This will allow sets of tyres to be maintained in the config and read/written to the car's TPMS ECU. The following commands will be available: tpms status - show status of the system tpms list - list tyre id sets in config tpms read <set> - read IDs from tpms ecu and store in config tyre set tpms write <set> - write IDs to toms ecu from config tyre set tpms set <set> {<id>} - config a set of IDs manually tpms delete <set> - delete the specified tyre set The initial version will support Tesla Roadster, but the functionality is there for other vehicles to use if they need it (in particular for standard K-line implementations). Comments/suggestions welcome. Regards, Mark. +++Attachments+++ Bench setup, showing (from left to right): Tesla Roadster TPMS ECU opened up Breakout board (power, k, Lin, and can) OVMS for can decode Usb logic analyser Power supply (12v) K-line analysis tool (9010) Windows laptop running k-line software Mac running logic analyser and terminal to OVMS. Hand-soldered prototyping board Async comms over k-line.

4 9