July 2025 - OvmsDev - Open Vehicles

Vehicle Capabilities, commands, etc
by Mark Webb-Johnson 28 Jul '25

28 Jul '25

Reviewing our current apps, and server v2 protocol, I’m seeing a problem. We never completed implementing the vehicle capability system, and feature creep seems to have added a bunch of things dependent on specific vehicles with specific capabilities (some standard and some custom). Not all of these are documented. Examples include: Does the vehicle have the ability to pre-heat / pre-cool? Custom OVMS v2 protocol commands > 200 haven’t been documented anywhere (but seem to be used in at least the Android App). In general, does a particular vehicle type support a particular feature? It seems that only option the apps have at the moment are to either include custom vehicle specific code in the app (acceptable when the particular function is only ever implemented by one specific vehicle, but imho a problem when it is generic enough that it starts applying to more than one vehicle type), or to just show the UI, fire off the command when the button is pressed, and handle the ‘not implemented’ response. It is pretty ugly to provide someone a button, but then give them a nasty error message when they press it. In protocol v2, we do (did?) have a car capabilities message: Car Capabilities message 0x56 “V” <https://docs.openvehicles.com/en/latest/protocol_v2/messages.html#car-capab…> This message is sent <cartoserver> “C”, or <servertoapp> “s”, and transmits the vehicle capabilities. It was introduced with v2 of the protocol. <data is comma-separated list of vehicle capabilities of the form: C<cmd> indicates vehicle support command <cmd> C<cmdL>-<cmdH> indicates vehicle will support all commands in the specified range But it seems never implemented in the v3 module firmware, not supported at all in MQTT, and not exposed to the vehicle.{h, cpp} at all. The old PIC based firmware did support it (with default being "C1-6,C40-41,C49” from what I can see in the old firmware). Unless anyone has any better ideas, I suggest we: Extended vehicle.{h, cpp} to provide a callback for vehicles to provide their capabilities. Extend ovms_server_v2 to generate the ‘V’ message from those capabilities. Create a standard metric to store these capabilities (for v3 mqtt protocol apps). Extend the apps to support the ‘V’ message and behave appropriately. Update each of the existing v3 firmware vehicle support code to set capabilities appropriately. Document (in v2 protocol guide) the custom commands. Perhaps consider what other things could be provided in these messages apart from ‘C’ (OVMS v2 protocol commands). For example, TPMS. Regards, Mark.

1 0

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