August 2020 - OvmsDev - Open Vehicles

Netmanager priority issue solved
by Michael Balzer 05 Jul '23

05 Jul '23

TL;DR: you need to pull my latest esp-idf changes. I've finally found & solved the strange priority changes for our netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the bug was in the esp-idf posix threads mutex implementation. I had suspected the mutex priority inheritance for a while, so added a way to retrieve the internal mutex hold count for our task list. Using this I noticed the hold count would always & only raise by 2 whenever any kind of mongoose connection was closed. That lead me to checking the thread concurrency protection for mongoose mbufs, because every mongoose connection has two mbufs associated (rx & tx), each having a posix mutex. The bug was: posix mutexes were deleted after locking (taking) them. FreeRTOS mutexes must not be deleted while being taken, that breaks the priority inheritance (more precisely the disinheritance), with the visible effect being the mutex hold count not returning to zero. As a side effect, this may also solve the strange event task starvations (hope so…). I was investigating this as I suspected some busy loop in the netmanager context. With the netman running at prio 22, that would effectively block almost all other processing including the timer service. I've found & fixed one potential busy loop trigger in the netman that would have been caused by the netman task still running while all interfaces had been lost -- not sure if that could happen, but it would explain the effects. So please watch your crash debug info & report if the issue still turns up. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

ESP32 CAN controller hardware bug / interrupt issue
by Michael Balzer 03 Apr '21

03 Apr '21

Second finding & commit: TL;DR: * ESP32 CAN controller is broken, delivers trashed & duplicated RX frames * we need to optimize interrupt latency Users have been reporting occasional false BMS readings on the Twizy for more than a year. The error always trashed the reading of voltage #10 and/or temperature #8, so I initially thought that must be a variant of the SPIRAM/cache bug. But the SPIRAM fix didn't help, and the bug still occured with all BMS data in internal RAM. The issue correlated with high load situations and the SIMCOM UART issue. On testing the latest changes by Marko, my car module began showing that issue regularly, so I could take a closer look. It turned out the wrong data came from the CAN bus. Checking with a CAN logger didn't show any wrong data on the bus. So I scanned our CAN driver for potential issues, found & solved some (even a serious race condition) but that didn't fix it. I then added debug dumps of all frames read, dug into the SJA1000 spec sheet and found this: The SJA1000 RX FIFO has a capacity of 64 bytes. It's supposed to work as a ring buffer, with frames wrapping around as necessary. If no space is left in the FIFO for a new frame coming in, that frame should be discarded completely, not counted, just the overflow indicator should be set & the according interrupt be generated. Reality differs. The frame causing the overflow is added to the FIFO partially. It's also counted both in the RMC register and indicated by RBS as a valid frame when retrieving the FIFO contents. The read buffer delivers the partial frame + some trashed bytes up to the nominal frame length. In the BMS frame sequence it would normally trash bytes 7 & 8 on the sixth frame of length 8 in a sequence. A standard frame needs a 3 byte header + the data bytes in the FIFO, so 6 frames would add up to 66 bytes => 64 + 2 trash. The first trash byte normally is "08", the second "84" or "2a" or sometimes "ab", possibly some internal SJA1000 data. Better yet, if you rely on the indicators of the SJA1000 when reading the FIFO, the SJA1000 will repeat the first frame within the FIFO after the invalid frame. Mostly once or twice, and sometimes 7 times or more: inv_msg: framecnt=13, invindex=6 inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 24 04 00 00 11 40 10 22 37 55 00 37 | 4..?........$....@."7U.7 inv_msg: 25 04 00 00 0a 1b 44 ff fe 4e 01 26 | 4..?........%.....D..N.& inv_msg: 54 05 00 00 37 37 37 37 37 37 37 00 | 4..?........T...7777777. inv_msg: 56 05 00 00 31 63 14 31 53 14 31 4a | 4..?........V...1c.1S.1J inv_msg: 57 05 00 00 31 43 14 31 53 15 *08 2a* | 4..?........W...1C.1S..* ^^^^^ trashed bytes … followed by 7 repetitions of the first frame: inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n inv_msg: 55 01 00 00 07 98 50 54 54 20 00 6e | 4..?........U.....PTT .n If you had occasional strange false readings leading to strange effects, this may be the explanation. Note: the SJA1000 FIFO bug may need specific circumstance to occur in addition to the overflow, maybe the overflow happening on a specific byte position in the FIFO -- I haven't tried to determine that. I've tried clearing the overflow ASAP, looping on the IR indicator and looping on the RMC, the fault is always the same. The workaround I've now done is adding up the message lengths read during a FIFO run and discard all frames exceeding the 64 byte border. Not pretty, but functional. That keeps the trashed frames from being forwarded to the OVMS application level. As with the SIMCOM UART, these overflows wouldn't happen if the interrupt handler would react fast enough. It seems we've got a general interrupt latency issue. And just as with the SIMCOM I saw a reduction of overflows when allocating the CAN IRQ on core #0, another one with raising the IRQ level to 3, so that's also part of my commit. The esp-idf CAN driver apparently has the same issue even in the latest release, I'll contact the author about this or post another issue to Espressif. So our interrupt allocation is now: Task Run# Lvl ISR# Usage Source ---------------------------------------------------------------------------------------- - 0 1 0 RTC Core ETS_RTC_CORE_INTR_SOURCE esp_timer 0 1 0 RTOS esp_timer ETS_TIMER2_INTR_SOURCE ipc0 0 1 0 RTOS Scheduler Core0 ETS_FROM_CPU_INTR0_SOURCE ipc1 1 1 1 RTOS Scheduler Core1 ETS_FROM_CPU_INTR1_SOURCE main 0 1 0 RTOS Watchdog ETS_TG0_WDT_LEVEL_INTR_SOURCE OVMS Events 1 1 1 Peripherals (GPIO ISR) ETS_GPIO_INTR_SOURCE OVMS Events 1 1 1 MAX7317 (spi_nodma) ETS_SPI3_INTR_SOURCE *esp32can init 0 3 0 ESP32 CAN ETS_CAN_INTR_SOURCE** **OVMS SIMCOM 0 2 0 SIMCOM UART ETS_UART1_INTR_SOURCE* OVMS Events 1 1 1 USB console (UART) ETS_UART0_INTR_SOURCE OVMS Events 1 1 1 SD card ETS_SDIO_HOST_INTR_SOURCE ---------------------------------------------------------------------------------------- I think we need to find the source of the interrupt latency and/or find some better scheme to distribute the tasks & interrupts over the cores. I still don't know why core #1 already got an issue with just our 6 interrupts. This may be related to the SPIRAM fix adding overhead, but I've seen the FIFO overflows before applying the fix, and the CAN issue also has been present for over a year. My working hypothesis is some task/driver disabling interrupts for too often / too long, or non-IRAM ISRs getting delayed for too often / too long. And it seems this is an issue especially on core #1. Please verify & comment. Regards, Michael PS: a little side mystery: the netmanager task starts with priority 5, then gets raised to 22 (probably a mutex priority inheritance), but never gets lowered back to 5 afterwards. A FreeRTOS bug? -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 11

ELM327 codes to
by Soko 27 Nov '20

27 Nov '20

Heya, Another thing I can't figure out at the moment. I have to poll the VWeUp and I figured out (hopefully) how to do that. But I have no clue how to translate the "usual" ELM327 Header+PID to one entry for the OvmsVehicle::poll_pid_t The only value I've understood is the polltime. On my OBD2 interfaces I use a PID of 0x22028C for SoC. But PID is here only 16 bit! Where do I put the header 7E5? What is txmoduleid and rxmoduleid? I can't believe that I'm the first one with this issue ;) Couldn't find any doc though :( So I'm very thankful for any pointing in the correct direction/doc/example. thanks Soko

7 88

Plugin Repository
by Mark Webb-Johnson 20 Oct '20

20 Oct '20

I feel that our plugin system offers a missed opportunity. By making small extensions to available functionality, we can use this system to do so much - and with a much lower complexity and barrier to entry compared to C++ ESP IDF development. There are a couple of things I would like to now do: Implement a mechanism for plugins to directly extend the console command language (other than the current ’script exec PLUGIN.fn’). Implement a plugin repository, and command line tools for managing plugins. We simply need to have a store and directory of available plugins, a way of searching/listing those, and a uniform way to install/remove plugins. Once this is done, perhaps someone can handle the web UI side of this, and perhaps that can even be done as a plugin :-) I’m already working on #1. Just an extension to the existing script system to allow plugins to register commands, and to have the command register/deregister done automatically on plugin load/unload. However, #2 is a little more tricky and I’m looking for feedback on the design of this. My idea is: Store the plugins in a new github/openvehicles/Open-Vehicle-Monitoring-System-3/plugins folder. Eventually the /plugin folder will all be migrated to here. Each plugin has a unique name; the directory in /plugins. Within each plugin directory, there is a <name>.json file (JSON format) with defined tags to describe the plugin. If the plugin delivers a web extension, that is in the ‘web’ subdirectory. If the plugin delivered a script extension, that is in the ’script’ directory. Documentation (in rst format) is in the ‘docs' directory. The JSON file would need the following, at a minimum: Name: The plugin ID Title: One line title Group: Group for the plugin Version: The version string of the plugin Description: Longer textual description of the plugin Prerequisites: Prerequisites to be checked (Each plugin installed provides name=version, the system provides system-level ones such as the version of firmware, and then the prerequisites is simple a list of <name><operator><version> as required) We can automatically build the documentation, and list, for all plugins for our docs.openvehicles.com <http://docs.openvehicles.com/> (in a similar way to how it is done for /plugin now). On a repository server, as part of a nightly build job, we can automatically build a single directory JSON file from the <name>,json descriptors. We can publish this, as well as a git export/checkout of the plugins, on a http download site. On the module, we can store a list of repository servers (allowing the user to add/remove as they require). Contributors/authors of plugins simply GitHub clone our repository, and issue pull requests as appropriate. They can also have their own private repository servers (just need to host the directory json file and associated code files) and add it to their modules. The ‘plugin’ command tree on the module will provide commands for: List installed repositories Add a new repository Remove a repository List installed plugins List/Search available plugins Install a plugin Remove a plugin Update a plugin I would like to try to unify the web and script plugin systems a bit more closely. They are really two sides of the same coin (with some plugins providing both). Does that make sense? Any suggestions/comments? Regards, Mark.

4 7

Refactoring MODEM/SIMCOM for v3.3
by Mark Webb-Johnson 10 Oct '20

10 Oct '20

I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected: Component simcom (major changes) New component ovms_modem introduced ovms_webserver/dev/commands.htm ovms_webserver/src/web_cfg_init.cpp ovms_webserver/src/web_cfg.cpp Component powermgmt And several other components mentioning Simcom, but only very minor changes I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult. Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on. Regards, Mark. P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.

4 17

USB port fragility
by Michael Balzer 10 Oct '20

10 Oct '20

Mark, I've had multiple cases now of damaged and broken off USB ports. I've added a fragility warning to the user guide: https://docs.openvehicles.com/en/latest/userguide/components.html#the-ovms-… Maybe we should add that to the multilingual quick start info sheet coming with the module as well? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

8 12

Duktape Persistent Function References
by Mark Webb-Johnson 28 Sep '20

28 Sep '20

@Michael this is probably for you. I am trying to implement javascript command registration. The idea is that a javascript module can call something like: OvmsCommand.Register(basecommand, name, title, callbackfn, usage, min, max) Then we reflect that into MyCommandApp.RegisterCommand, and keep a track of which command is for which javascript callbackfn. When the command is executed, we pass it into duktape. I also have tracking for javascript module loading and unloading, so I can DeregisterCommand() if duktape is reloaded (and also protected against commands being registered in short-lived scripts run from the command line). To implement this, I need to store the callbackfn as a persistent reference to a duktape javascript function. The issue with callback function references in duktape is summarised here: https://wiki.duktape.org/howtonativepersistentreferences <https://wiki.duktape.org/howtonativepersistentreferences> When a Duktape/C function is called, Duktape places the call arguments on the value stack. While the arguments are on the value stack, they're guaranteed to be reachable and the Duktape/C function can safely work with the arguments. However, when the Duktape/C function returns, the value stack is unwound and references in the function's value stack frame are lost. If the last reference to a particular value was in the function's value stack frame, the value will be garbage collected when the function return is processed. The standard approach is to store the reference back in the duktape duk_push_global_stash so it won’t get garbage-collected. But, that seems messy. I see that Michael has already implemented something that seems similar in ovms_script.{h, cpp}, for the async http callbacks. Presumably to avoid this issue. But, the approach seems very different, and I am not sure if it is stopping _all_ garbage collection for the duration of the async query, or just that particular object being garbage collected. The work seems extensive (quite a few objects involved). So @Michael, any suggestions for this? I don’t want to reinvent the wheel... Regards, Mark.

3 18

OBD/UDS Poller receiver rework
by Michael Balzer 08 Sep '20

08 Sep '20

Everyone, I've just pushed the poller receiver changes I announced into the new "poller-rework" branch: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/0b3… OBD/UDS Poller Receiver Rework: - Fix race condition between CAN RX and PollerReceive - Separation of ISO-TP & OBD/UDS layer meta data analysis - Fix incomplete meta data validation - Allow single/multi frame responses on all service types - Validate multi frame response sequences - Fix single frame payload lengths - Fix type 0x22 first frame payload offset & overall length - Add negative response code handling → IncomingPollError() - Add response frame timing control → PollSetResponseSeparationTime() This rework has been on my list for some time before, as the previous solution had some general shortcomings, especially by it's hard coded coupling of the expected response transport form with the request type, which fails already on some type 0x01 requests. The major bug in the receiver that now triggered the rework was in the overall payload length calculation and the first frame payload passing of the type 0x22 (VEHICLE_POLL_TYPE_OBDIIEXTENDED) multi frame response handling. That up to now basically only turned up as a visible issue for the Smart ED, as all other vehicles either don't get multi frame responses on 0x22 queries or (like the Kia) generally discard the first frame and don't use the overall length at all. On the Smart ED, all handlers have been deliberately written assuming the bug was a feature -- all payload addressing is shifted by one byte. This needs to be rewritten now. All other vehicles should not see any difference and should not need to change any code. Except maybe in the UpMiiGo development, which isn't yet part of the master. Other bugs like the missing frame sequence validation and late response detection may have been the causes for some spurious and hard to track crashes and data errors. We should try to get this change tested short term on "edge", so we can see if this actually improves stability as I hope. As this is a major rework (mainly of the PollerReceive() method), audits and tests are very welcome. I can only test on the Twizy, which doesn't make much use of the poller yet. You can see what the new poller does by raising the log level for "vehicle" to debug. Example of some Twizy regular polling: D (136323) vehicle: PollerSend(1): send [type=10, pid=C0], expecting 743/763-763 D (136343) vehicle: PollerReceive[763]: process OBD/UDS response 10(C0) frm=0 len=0 off=0 rem=0 V (136343) v-twizy: OBD2: ignored reply [10 c0] D (137323) vehicle: PollerSend(1): send [type=21, pid=81], expecting 743/763-763 D (137343) vehicle: PollerReceive[763]: process OBD/UDS response 21(81) frm=0 len=4 off=0 rem=15 D (137373) vehicle: PollerReceive[763]: process OBD/UDS response 21(81) frm=1 len=7 off=4 rem=8 D (137403) vehicle: PollerReceive[763]: process OBD/UDS response 21(81) frm=2 len=7 off=11 rem=1 D (137423) vehicle: PollerReceive[763]: process OBD/UDS response 21(81) frm=3 len=1 off=18 rem=0 D (137433) v-twizy: OBD2: got VIN='XXXXXXXXXXXXXXXXX' D (138323) vehicle: PollerSend(1): send [type=21, pid=13], expecting 743/763-763 D (138343) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=0 len=4 off=0 rem=106 D (138373) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=1 len=7 off=4 rem=99 D (138403) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=2 len=7 off=11 rem=92 D (138423) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=3 len=7 off=18 rem=85 D (138453) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=4 len=7 off=25 rem=78 D (138483) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=5 len=7 off=32 rem=71 D (138513) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=6 len=7 off=39 rem=64 D (138543) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=7 len=7 off=46 rem=57 D (138563) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=8 len=7 off=53 rem=50 D (138593) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=9 len=7 off=60 rem=43 D (138623) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=10 len=7 off=67 rem=36 D (138653) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=11 len=7 off=74 rem=29 D (138683) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=12 len=7 off=81 rem=22 D (138703) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=13 len=7 off=88 rem=15 D (138733) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=14 len=7 off=95 rem=8 D (138763) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=15 len=7 off=102 rem=1 D (138793) vehicle: PollerReceive[763]: process OBD/UDS response 21(13) frm=16 len=1 off=109 rem=0 W (141323) v-twizy: OBD2 Cluster DTC NEW #01: 4/21 rev0 G1 INT MEM Ef| @ 57871km 11kph SOC=60% BV=14V TC=0 IC=255 W (141333) v-twizy: OBD2 Cluster DTC NEW #02: 4/1 rev0 G1 MEM| @ 57892km -1kph SOC=86% BV=14V TC=0 IC=255 W (141343) v-twizy: OBD2 Cluster DTC NEW #03: 1/37 rev0 G1 INT MEM Ef| @ 57892km -1kph SOC=86% BV=14V TC=0 IC=255 W (141353) v-twizy: OBD2 Cluster DTC NEW #04: 3/59 rev0 G2 INT MEM| @ 57926km 34kph SOC=78% BV=14V TC=0 IC=255 W (141363) v-twizy: OBD2 Cluster DTC NEW #05: 4/40 rev0 G2 MEM Ef| @ 57926km 35kph SOC=78% BV=14V TC=0 IC=255 W (141373) v-twizy: OBD2 Cluster DTC NEW #06: 3/58 rev0 G2 INT MEM| @ 58711km 41kph SOC=46% BV=14V TC=0 IC=255 A manual multi frame poll: I (147723) webcommand: HttpCommandStream[0x3f8540f4]: 3801804 bytes free, executing: x o r bm 2104 D (148323) vehicle: PollerSend(1): send [type=21, pid=4], expecting 79b/7bb-7bb D (148343) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=0 len=4 off=0 rem=70 D (148353) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=1 len=7 off=4 rem=63 D (148393) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=2 len=7 off=11 rem=56 D (148433) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=3 len=7 off=18 rem=49 D (148473) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=4 len=7 off=25 rem=42 D (148513) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=5 len=7 off=32 rem=35 D (148553) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=6 len=7 off=39 rem=28 D (148593) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=7 len=7 off=46 rem=21 D (148633) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=8 len=7 off=53 rem=14 D (148673) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=9 len=7 off=60 rem=7 D (148713) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4) frm=10 len=7 off=67 rem=0 OVMS# x o r bm 2104 Response: 08 cc 3c 08 d4 3c 08 cb 3c 08 d6 3c 08 ce 3c 08 | ..<..<..<..<..<. d1 3c 08 d2 3c ff ff ff ff ff ff ff ff ff ff ff | .<..<........... ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ................ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ................ ff ff ff ff ff ff ff ff 3c 3c | ........<< An example of the new error response handling: I (165023) webcommand: HttpCommandStream[0x3f8479f4]: 3791052 bytes free, executing: x o r bm 221405 D (165323) vehicle: PollerSend(1): send [type=22, pid=1405], expecting 79b/7bb-7bb D (165343) vehicle: PollerReceive[7BB]: process OBD/UDS error 22(1405) code=11 OVMS# x o r bm 221405 ERROR: request failed with response error code 11 Code 11 = "serviceNotSupported" (see ISO 14229 Annex A.1 for more codes) Feedback is welcome. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 15

Issues since latest update (3.2.0.14)
by Sébastien Darveau 01 Sep '20

01 Sep '20

Hello, Anyone else is having connection issues since latest update? I’m constantly loosing contact with the device and haven’t been able to open a console with USB but this time, I can still access it with the Web interface and noticed it can’t connect to server. E (72178423) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address E (72178423) ovms-server-v2: Status: Error: Connection failed W (72180093) simcom: UART hw fifo overflow W (72192873) gsm-mux: Frame overflow (2048 bytes) E (72238423) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address E (72238423) ovms-server-v2: Status: Error: Connection failed E (72298463) ovms-server-v2: mg_connect(api.openvehicles.com:6870) failed: cannot parse address E (72298463) ovms-server-v2: Status: Error: Connection failed Address looks good though. Sebastien Darveau sebastien.darveau(a)synnoetic.com

3 6

Configuring notifations
by Chris van der Meijden 01 Sep '20

01 Sep '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