- OvmsDev - Open Vehicles

Re: [Ovmsdev] Firmware release 3.3.005 / CAN SAE timing
by Michael Balzer 26 Jul '25

26 Jul '25

Craig, as you suspect the issue originating with the MQTT keepalive config or the clock event optimization, did you test those? As a theory: if the clock events were the only transmissions keeping your MQTT connection from dropping while parked, the effect could be due to the retransmission of all metrics on reconnect. You could easily test that by re-enabling the clock events, or by sending a custom event every minute from a script. You could also try a smaller keepalive value (e.g. a minute?) or determine and apply the keepalive interval of your MQTT hub. Regards, Michael Am 24.07.25 um 20:04 schrieb Craig Leres: > On 7/13/25 14:23, Michael Balzer wrote: >> I know of no other reports regarding increased traffic. But there are >> few using MQTT, who also need to monitor their data volume, so maybe >> you're just the only one noticing. >> >> Yet I still think testing in chronological order is not going to >> produce sensible results, as you mix unfinished intermediate commits >> from different development branchs, their commit order normally does >> not match the chronological order of each other or of the master >> branch. As written before, you need to concentrate on single branches >> when doing that. The recommended tool for narrowing down bugs by >> commits is git bisect. >> >> In your case, 78a49a59 is not a master commit, it's one part of pull >> request #1081. Just as an example, commit >> 98606bb5304a5c2b832ffbb0d26391a632e5fc17 is dated after 78a49a59 but >> was added to master before. So it doesn't make any sense to test >> 78a49a59, unless you're on the #1081 development branch. Use gitk, >> git log -- graph, or similar to view the branch/commit associations. > > Ok, I learned how to use git bisect. I think 47097936 is the last > "good" version and 0be0490e is the first "bad" version: > > sea 4 % git bisect bad > 0be0490e8b3a7224aaee8190dd8dc42bb4a71540 is the first bad commit > commit 0be0490e8b3a7224aaee8190dd8dc42bb4a71540 (HEAD) > Author: chris8086 <chris-github(a)ee.eclipse1.net> > Date: Sat Nov 16 07:23:10 2024 +0000 > > Add configurability of MQTT keepalive timer, and prevent clock > events being published every minute > > vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp | 4 ++++ > vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.h | 1 + > 2 files changed, 5 insertions(+) > > But there the diff between these two hashes have a LOT of changes so > I'm not sure how to proceed. > > I also interacted with hologram support (I had a couple of days while > running a "bad" version with zero traffic seen by any sim!). The csr > volunteered: > > I also wanted to point out there are some zero byte sessions > occurring. This can be common, but if not, please review this > information. > > > https://support.hologram.io/hc/en-us/articles/360040668834-Find-and-trouble… > > > I attached a screen grab for the "recent sessions" tab for the sim on > the module running 0be0490e. Not sure if this is interesting (but this > is another way to see lots of cellular data for a module that has been > parked and on wifi for almost a month). > > Suggestions for my next move? I'm still not understanding why there > would be so much cellular traffic for a module that is parked and on > wifi for many days in a row. > > I also included my git bisect log. > > Craig > > sea 9 % git bisect log > git bisect start > # status: waiting for both good and bad commits > # bad: [78a49a596792e2da5338d5c4f1d719490a674164] Add ability to > disable legacy topic. Add new configs to web UI and changes.txt. > git bisect bad 78a49a596792e2da5338d5c4f1d719490a674164 > # status: waiting for good commit(s), bad commit known > # good: [bc1f75c950ae7d85b62bff589e1571ba83df3e62] Merge branch > 'openvehicles:master' into SmartEQ > git bisect good bc1f75c950ae7d85b62bff589e1571ba83df3e62 > # good: [470979369be56fe18eae0df90f1619afdd27e850] Manual: fix syntax > & spelling errors > git bisect good 470979369be56fe18eae0df90f1619afdd27e850 > # bad: [aa6c73978bf43ebd16ba396a989b30a7f6fbece1] Merge branch > 'openvehicles:master' into optimise-mqtt > git bisect bad aa6c73978bf43ebd16ba396a989b30a7f6fbece1 > # bad: [0be0490e8b3a7224aaee8190dd8dc42bb4a71540] Add configurability > of MQTT keepalive timer, and prevent clock events being published > every minute > git bisect bad 0be0490e8b3a7224aaee8190dd8dc42bb4a71540 > # first bad commit: [0be0490e8b3a7224aaee8190dd8dc42bb4a71540] Add > configurability of MQTT keepalive timer, and prevent clock events > being published every minute -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

Firmware release 3.3.005
by Michael Balzer 26 Jul '25

26 Jul '25

Everyone, I'd say release 3.3.005 is due. 3.3.004 was 03/2024, we've since collected quite some fixes and new features, including extensions for Smart EQ & the new MG4 support. There are lots of new Smart users now, as Mercedes have stopped support for the official Smart EQ App (see https://www.smart-emotion.de/article/415-mercedes-discontinues-smart-eq-app…) The current state is also very stable, I had no issue reports. Any objections / open fixes or additions that should be included in 3.3.005? Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

4 10

Android App release 5.1.0
by Michael Balzer 18 Jul '25

18 Jul '25

Everyone, release 5.1.0 of the Android App is now in review by Google and will be published automatically unless they ask for changes. Main changes since 4.4.1: * New vehicles: Hyundai Ioniq5, Kia EV6, Energica Motorcycles, * Redesigned user interface * Finnish translation * Customizable quick action buttons incl. custom command support * Extended Smart EQ feature support * Add VW e-Up charger settings (needs firmware >=3.3.004) * General fixes & optimizations Google are pushing for an update required by their new "target SDK needs to be newer than 2 years" policy. There are remaining issues with the new UI, but none that need to be resolved now. Target & build SDK is now API level 36 (Android 16 / "Baklava"). Min SDK remains API level 21 (Android 5.0), which hopefully will be accepted. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

OVMS Server v3 WebSockets
by Mark Webb-Johnson 18 Jul '25

18 Jul '25

I’ve made, committed, and pushed, a couple of (hard to find but easy to fix) changes to OVMS Server v3. Proper handling of non-textual, non-binary, websocket messages. This issue caused garbage to be received when some websocket clients disconnected nicely (with connection close messages badly handled). The fix is to only treat text and binary messages as OVMS v2 protocol, and to ignore the other purely-control messages. The websocket library we use may UTF-8 encode incoming messages leading to garbage messages being sent to connected cars/apps and disconnections. The fix made is simply to treat the messages as streams of bytes (not UTF-8 encoded). With these changes made, all my tests of websocket clients (and apps) are complete and pass. Hopefully this should be stable to use in production now. It is certainly very easy to use. Car: $ websocat -E wss://<server>:6870/apiv2 MP-C 1 <user> <password> <vehicleid> MP-S 1 <user> <vehicleid-list> Z0 Z1 C7,stat c7,1,all ok Z0 App: $ websocat -E wss://<server>:6870/apiv2 MP-A 1 <user> <password> <vehicleid> MP-S 1 <user> <vehicleid-list> Z1 F1.5.0,VIN123456789012345,5,1,TRDM, S80,K,220,13,charging,standard,282,253,13,18,0,0,5,1,0,0,0,1 D124,8,4,10,20,5,0,9930,50,0,0,0,1,1,12.0,0 L22.337297,114.187969,90,0,1,1 W29,2,40,6,29,2,40,6,1 T15 C7,stat c7,1,all ok This new code is running at api.openvehicles.com <http://api.openvehicles.com/> already, and I recommend anyone running their own server to upgrade if they need websocket (or new unified app) support. Regards, Mark.

1 0

A call for help with photoshop
by Mark Webb-Johnson 17 Jul '25

17 Jul '25

With reference to my previous message on the unified OVMS App, I am asking for volunteers - people familiar with photoshop - to help out now. The current iOS and Android apps simply include all colour variants of every car as three images (map, top down, and 3/4 side view for the main screen). That becomes massive and unworkable. The Android App currently has about 19MB of vehicle images, and iOS is 32MB. It has gotten so bad that a while ago we stopped accepting any new images (for the iOS app at least). I recognize that the car image matching your actual vehicle is important to users. Having the wrong image, while seemingly trivial, can be frustrating. People are proud of their vehicles and customization (colors, wraps, accessories, etc) is common. To solve this in the unified app we have a base vehicle image as well as a transparent background grayscale mask of the painted areas. We can then overlay the mask over the base, and programmatically colorize the mask to match standard / custom colors. These are for each of the three images of the vehicle (main 3/4 view, map, and top down), and for each car type. I’ve attached some samples for the Tesla Roadster. [ note that we’ll also offer the option for the user to simply upload their own images from camera roll, but that is another topic, as 99% of users have standard cars ] You can see a working example of this in action here: https://snack.expo.dev/@ovmsmark/masked-colorizer This approach should be able to bring the size down to perhaps 1/6th of what we have today. What we are looking for is volunteers familiar with photoshop to help organize and create these vehicle images. The task would be to take whatever graphics we have now, organize and standardize them, then use photoshop to convert to layers (one for the base vehicle, and another for the paint) for each of the three views. It has also been discussed to perhaps create another layer for headlights and taillights (so we could easily switch these on/off to match the car state itself). Doing this work on the white variant color of each vehicle type seems to produce the best results. So, any volunteers? Regards, Mark

1 0

Unified OVMS App
by Mark Webb-Johnson 17 Jul '25

17 Jul '25

For a while now (something like a decade), I’ve had a dream of a single unified OVMS App. A rough list of some of the pain points I have wanted to solve includes: Free and open source - both the project and the tools. One app running on the web, as well as mobile iOS, Android, etc. Multi-platform - taking the virtual vehicle module concept from our module firmware out into the App, and allowing vehicles to be added to the app using ‘platforms' (such as OVMS v2 API, OVMS v3 MQTT, Tesla Fleet Api, and possibly others like Smartcar, Tessie, etc). Solve the vehicle image problem once and for all. Customizable screens / dashboards. Allow for reliable custom server push notifications (ie; not just api.openvehicles.com <http://api.openvehicles.com/> and dexter’s). Support for native extensions (watch apps, etc). Having tried more than half a dozen cross platform development environments, a year ago we started using the Expo environment (based on react native) at my day job, and that was a game changer. It finally made React Native usable, with real-time prototyping, cloud builds, simplified distribution, push notifications, cloud (not App Store) updates, and much more. Still painful, but usable. However, the real impetus was pursuading my son to help out as a summer internship. Expo is pretty cool. You can develop locally, then build iOS and Android apps in the cloud (no need for windows or Mac locally). It has it's own push notification system using it's own tokens, and so long as you know the token any server can push notifications out to the apps (even under iOS) - that can be locked down with a secret or left open. It is still cumbersome (Javascript / typescript with a heavy load of libraries), but imho the best that there is out there for stuff like this. For projects like ours it is effectively free, and while commercial it is open source and nothing would stop us from moving to pure react native at a later date (should Expo start behaving badly). We’ve now built a prototype of this App, and I’ve attached some screenshots below. The UI is far from complete, but we have the all important virtual vehicle metrics, OVMS v2 API (SSL/TLS over websockets), location streaming on a map, vehicle commands, and a few others things all working well. We are targeting having something usable for others to be able to look at and play with by next month - August - although if you wanted to see it now I don’t think it would be too hard for you to find it on GitHub (just don’t expect any help from me for the moment as it breaks on a daily basis). Hint: it is *not* Open-Vehicle-React-App. Long term I am not sure if (but hope that) this App can replace both the existing ones. It is certainly better than the iOS App today, even in it’s current prototype form. We don’t need help with the App development for the moment, as things change too frequently to make a bigger team worthwhile. But we do need help with the vehicle images, and I will eMail separately regarding that topic. Regards, Mark

1 0

Lilygo T-Call support - Configuration in OVMS
by Info Zeitnitz 22 Jun '25

22 Jun '25

Dear all, coming back to Marks suggestions, how to configure the Lilygo T-Call module, or in general alternative mappings of the GPIOs in OVMS. To move away from a single config to enable/disable the Lilygo support, I introduced now a new choice to enable alternative GPIO mappings. - Select default hardware base (e.g. HW31) - Use the default or an alternative GPIO mapping (new choice) - in case an alternative GPIO mapping is enabled, a file has to be specified, which contains the #define statements for all needed GPIOs and the modem control. This file is included into ovms_peripherals.h, if the alternative mapping is enabled. This way, there is no explicit dependence on a specific hardware in the configuration, or the code. Of course, there is the assumption that the hardware is compatible with the standard hardware base of the OVMS module, e.g. the modem is supported. I had to make some assumptions, how to handle the naming of the EGPIO/MAX7317 pins, in case the MAX7317 is not existing (MODEM_EGPIO_PWR -> MODEM_GPIO_PWR, MAX7317_CAN1_EN -> ESP32CAN_PIN_RS etc). All specific components for the alternative hardware have to be explicitly enabled/disabled in menuconfig (modem,ESP32CAN, SD Card, OTA update, extension port ...). This is now implemented in https://github.com/zbchristian/Open-Vehicle-Monitoring-System-3-Lilygo-Supp… (branch Lilygo-GPIO-remapping). The only Lilygo dependence is existing in some additional files: - example sdkconfig file in the support folder: sdkconfig.lilygo-tc - three GPIO mapping files in components/gpio_maps/ for different versions of the Lilygo T-Call and the corresponding motherboard. This folder is added to the include path. I think, that this method is simple and very flexible. For an alternative module to be added, just a GPIO map file and an example sdkconfig have to be provided. No change in the configuration or code is required. What do you think? Best regards Christian

1 0

ESP32CAN - CAN bus interferences
by Info 13 Jun '25

13 Jun '25

Dear all, I recently experienced some interferences between my OVMS module (Lilygo based) and the CAN bus of the car. The car was complaining once in while about problems with certain components. I first thought it might be related to my hardware. Checking some discussions, I realized, that, at least for the Smart EQ, this seems to be a common problem, independent of the used hardware. I traced this down to a crashing firmware (edge version), which leads to a disturbance of CAN1 (ESP32CAN). Actually I emulated a car (Smart EQ) with an Arduino and two CAN interfaces and recorded the bus errors and transmission problems. For this I crashed the firmware intentionally once a minute. The efficiency of occurring errors is pretty high, but not each crash leads to transmission problems. It actually does not help to disable the write access to the bus, since this is only implemented in software. The hardware listen-only mode of the CAN transceiver SN65HVD233 is not implemented yet (see below). In conclusion, CAN1 is inherently sensitive to to a crashing firmware due to the undefined GPIO transients on the ESP32CAN TX pin. What helps, is to switch the transceiver into the listen-only mode (RS pin high). In this case two pins have to conspire to achieve a dominant state on the bus. The MCP2515 based bus is not effected by crashes. I propose to implement the hardware based listen-only mode in case, that the write access is disabled anyway. I implemented this now for the ESP32CAN as well as for the MCP2515 code. See https://github.com/zbchristian/Open-Vehicle-Monitoring-System-3-Lilygo-Supp… This branch includes only the changes wrt to the switching of the listen-only mode. I will issue a corresponding pull request. In the code for the cars, the can bus mode has to be specified: if (write_is_enabled) RegisterCanBus(busno,CAN_MODE_ACTIVE, speed); else RegisterCanBus(busno,CAN_MODE_LISTEN, speed); In case the config changes: if (write_is_enabled) SetCanbusMode(busno,CAN_MODE_ACTIVE); else SetCanbusMode(busno,CAN_MODE_LISTEN); As an example, I implemented this for vehicle_smarteq in the above repo. Another measure of security would be to shift for newer hardware to a different CAN transceiver chip. I use now the TI TCAN330, which is pin and functionally compatible with the SN65HVD233, but has a feature called DOT (Dominant Time Out), which will return the bus to a recessive state after a few msecs, in case the dominant state is applied for a too long time. Best regards Christian

2 2

Inserting a Single OBD Request into the Poller
by solterra＠kezarnet.com 26 May '25

26 May '25

Could someone point me to an example of the correct way to insert a single OBD request into the poller? As an example, I’d like to request the VIN—but I only need to do this once, not on a recurring basis. I was previously using |PollSingleRequest|, but it no longer seems to be working as expected. Thank you in advance for your help!

3 4

How I got sphinx working on ubuntu 23.1 + WSL
by Michael Geddes 26 May '25

26 May '25

Firstly, thanks to Michael Balzer for fixing my errors in the rst files I checked in. (Also, apparently I can't spell Auxiliary - doh). I _had_ tried to get sphinx working recently and failed miserably, so I tried again this morning. The problem is that ubuntu: * Doesn't provide a package for m2r2 or sphinx-mdinclude (a fork of m2r2) * No longer allows you to pip install into the main python library path So first I got rid of the installed sphinx-doc sudo apt remove sphinx-doc Then I set up a sphinx virtual environment pipx install sphinx pipx inject sphinx sphinx_rtd_theme docutils mistune requests sphinx-mdinclude For some reason I was getting run-time python errors with m2r2 which is why I tried switching to mdinclude. In docs/source/conf.py I changed extensions = [ 'm2r2' ] to be 'sphinx_mdinclude' instead of 'm2r2' The pipx command creates a virtual execution environment for sphinx and puts a shim for sphinx in your local path that runs it in the virtual environment. //.ichael

9 31