- OvmsDev - Open Vehicles

Vibe submissions
by Michael Balzer 21 Dec '25

21 Dec '25

Everyone, I've just added a section on "vibe" ("AI" generated) submissions to our README's developer guidelines: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3?tab=readme… I'm really fed up with having to sort out some LLM hallucinated bullshit. This has already been causing issues in other projects, and now becomes a major problem here as well. Dear young fellow developers: know your tool's limits! When thinking about how often LLM generated nonsense may already make it into production untested at places where it really matters, and how that will be amplified by maintainers using "AI" to validate submissions, I get a very bad feeling about our future. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

battery drain
by Tamás Kovács 03 Dec '25

03 Dec '25

Hi guys! I have a problem with my ioniq 28kwh car, use ovms over 2 years, and now drain my battery last day i found the following, if i set the vehicle module to none, the drain is stop. i use the edge fw. In night the auto update fw is run and after the reboot the battery drain is continue. In the picture can see, 15:15 set vehucle module to none, auto update is run at ~3:02 (vehicle module to hyundaivfl) and i woke up at ~5:20 and set the vehicle module to none I attach a log and a screenshot of battery voltage What can is do? Problem with a OBD cable? I detached the ovms from the car for a couple off hours but when is reconnect it not connect to the wi-fi network, but when i connect a computer or a powerbank, the wi-fi connection is established, after usb disconnect network works fine, but i have many can errors. On charging i get many ovms messages, charge stopped, started....... -- Thanks: Kovács Tamás

2 2

Introduction to OVMS DMQ
by david muñoz quiroz 16 Oct '25

16 Oct '25

Hi everyone, My name is David Muñoz Quiroz, I would like to be part of this incredible group and help with the creation of OVMS project(s), I am currently Senior Software Architect in Joyson Safety Systems (Automotive industry), it has become to my attention be part of something bigger than my current organization and I was starting to create my own module to learn and have fun with my vehicles when I realized about this incredible open source project, I feel myself identified with this group and I hope I can be accepted and I can contribute with some of my knowledge and absolutely learn from each other, Best regards, David Munoz

2 4

Public OVMS Servers
by Mark Webb-Johnson 23 Sep '25

23 Sep '25

I’m trying to compile a full list of public OVMS servers, and in particular their capabilities. Here is what I would like to collect: Title Location Intended geographic coverage Access policy Access domain name User Registration URL V2 offered? V2 Type V2 Version V2 standard service port (if offered) V2 SSL server port (if offered) V2 HTTP API standard service port V2 HTTPS API standard service port V2 is WebSocket available on HTTP/HTTPS API service port? V3 offered? V3 Type V3 Version V3 MQTT authentication V3 MQTT standard service port V3 MQTT SSL service port V3 MQTT websocket standard service port V3 MQTT websocket SSL service port Notifications supported? APNS (Apple IOS) supported? GCM (Android firebase) supported? MAIL (eMail) supported? EXPO supported? Notes/comments Grateful if you could reply to this eMail with details of any public OVMS servers that you operate, use, or know-of. Obviously best if the operators could reply directly as they know the capabilities best. As an example, for api.openvehicles.com <http://api.openvehicles.com/> here are the corresponding details: Title: Open Vehicles Location: Hong Kong Intended geographic coverage: Globally available Access policy: unrestricted public access for OVMS use only Access domain name: api.openvehicles.com <http://api.openvehicles.com/> User Registration URL: https://www.openvehicles.com/ V2 offered?: yes V2 Type: https://github.com/openvehicles/Open-Vehicle-Server/tree/master/v3/server V2 Version: master head, unmodified (currently 3.0.001-74-gb19aaac) V2 standard service port (if offered): tcp/6867 V2 SSL server port (if offered): tcp/6870 V2 HTTP API standard service port: tcp/6868 V2 HTTPS API standard service port: tcp/6869 V2 is WebSocket available on HTTP/HTTPS API service port?: yes V3 offered?: yes V3 Type: mosquitto V3 Version: 1.6 V3 MQTT authentication: same username+password as #6 V3 MQTT standard service port: tcp/1883 V3 MQTT SSL service port: tcp/8883 V3 MQTT websocket standard service port: not available V3 MQTT websocket SSL service port: tcp/8083 Notifications supported?: Yes APNS (Apple IOS) supported?: Yes GCM (Android firebase) supported?: Yes MAIL (eMail) supported?: Yes EXPO supported?: Yes Notes/comments: none Thanks, and Regards, Mark

3 2

Re: [Ovmsdev] GNUMAKEFLAGS
by Chris van der Meijden 28 Aug '25

28 Aug '25

Perhaps directly in the Makefile? https://www.cmcrossroads.com/article/basics-getting-environment-variables-g… Am Mittwoch, dem 27.08.2025 um 10:15 -0700 schrieb Craig Leres: > On 8/27/25 02:42, Chris van der Meijden wrote: > > I checked the second link and it seems to be a gmake 4.4.x problem. > > > > The last sentence in that link is > > > > "A workaround is to always provide (an empty) GNUMAKEFLAGS > > environment > > variable." > > > > so before the make command I entered > > > > export GNUMAKEFLAGS= > > > > and it compiles without warnings. > > > > I will not put the environment variable in my profile, so I can > > watch > > the further development in updates of gmake. > > What I was hoping for is to find the place in one of the ovms .mk > files > to stick GNUMAKEFLAGS=

1 0

GNUMAKEFLAGS
by Chris van der Meijden 27 Aug '25

27 Aug '25

After some time I today compiled the newest code. For the first time on Debian Trixie. I got loads of warnings about a missing variable "GNUMAKEFLAGS" . Am I missing something? Regards Chris

2 2

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

09 Aug '25

Craig, regarding your previous log, I wrote: > […] your log shows there are wifi reconnects to the same network every > four minutes. > > With the running v3 client, each reconnect means a full retransmission > of all metrics, as also logged. If that 4 minute period also occurs > while on cellular, that's your culprit. When Wifi gets disconnected the module switches to cellular if available. So if your Wifi situation has changed, i.e. if there are no or few reconnects now, that would also explain your new observation. You can tell by checking your logs. Regards, Michael Am 08.08.25 um 02:05 schrieb Craig Leres: > On 8/1/25 15:20, Craig Leres wrote: > >> You could also try a smaller keepalive value (e.g. a minute?) or > >> determine and apply the keepalive interval of your MQTT hub. > > > > I built and booted 3.3.005-20-g60be058e. Did I set the keep alive to > one > > minute correctly? > > That seemed to do the trick; I have all three of my modules running > with that version and my daily hologram.io usage has stayed under 1MB. > > I'm still curious why there can be so much cellular data when the unit > is in range of wifi. > > Craig -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

Fwd: Firmware release 3.3.005 / CAN SAE timing
by Craig Leres 09 Aug '25

09 Aug '25

[I never saw this hit the mailing list and do not see it in the archives...] -------- Forwarded Message -------- Subject: Re: [Ovmsdev] Firmware release 3.3.005 / CAN SAE timing Date: Thu, 7 Aug 2025 17:05:07 -0700 From: Craig Leres <leres(a)xse.com> To: Michael Balzer <dexter(a)expeedo.de>, OVMS Developers <ovmsdev(a)lists.openvehicles.com> On 8/1/25 15:20, Craig Leres wrote: >> You could also try a smaller keepalive value (e.g. a minute?) or >> determine and apply the keepalive interval of your MQTT hub. > > I built and booted 3.3.005-20-g60be058e. Did I set the keep alive to one > minute correctly? That seemed to do the trick; I have all three of my modules running with that version and my daily hologram.io usage has stayed under 1MB. I'm still curious why there can be so much cellular data when the unit is in range of wifi. Craig

1 0

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