February 2026 - OvmsDev - Open Vehicles

Firmware size approaching 4 MB limit
by Michael Balzer 19 Apr '26

19 Apr '26

Everyone, with the latest vehicle additions, the firmware size has now grown to 4,015,328 bytes in build 3.3.005-485-gc4664881. Our flash partitioning scheme is currently designed to provide three firmware partitions (factory, ota_0 & ota_1) of 4MB = 4,194,304 bytes each. So we've now got 178,976 bytes = ~4% left. Options beyond the 4 MB limit: a) split features, e.g. vehicle support, into two or more builds b) repartition into two firmware partitions of 6 MB each, reusing the factory partition for OTA c) switch to an ESP32 WROOM module with 32 MB flash (possible?) We've got some time left, new vehicles normally don't need that much space, I just wanted to raise awareness. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

5 43

Re: [Ovmsdev] Firmware size approaching 4 MB limit
by Craig Leres 26 Feb '26

26 Feb '26

[I'm having trouble with dkim, *only* with lists.openvehicles.com ...] On 2/25/26 12:10, Michael Balzer wrote: > your backtrace is in is_safe_write_address() -- is it possible you > forgot to change your sdkconfig? > >> One big âgotchaâ I found was that we need to >> set CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ABORT= >> and CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ALLOWED=y in our >> sdkconfig - otherwise the partition table cannot be re-flashed. Of course you're right... Ok, that works better. The only nit I have is that it left me with the boot partition set to factory, not sure what happens if you try booting with that set after the factory partition was renamed. Craig

2 1

Re: [Ovmsdev] Registering / Web pages for Scripted Implementation
by Michael Balzer 08 Feb '26

08 Feb '26

Michael, ideally most metrics logic would already be in the DBC, and I don't think a user will normally need to load more than two, maybe three vehicle plugins. Even if so, we've got plenty of SPIRAM left to assign to Duktape. Default is 512 KB, and can be changed by the user via config module duktape.heapsize. We wouldn't have any issues with raising the default to 1 MB. For reference: baseline memory usage of Duktape with our builtin libs (PubSub etc) is currently ~130 KB. The current ECU toolkit plugin for the UpMiiGo adds ~70 KB to that. ABRP probably is in the same ballpark, similar complexity. Rather RAM hungry is the aux battery monitor, as the 24 hour per minute recording of 5 float metrics actually uses quite some RAM. There's certainly a more efficient way to implement that, especially the array slice operations need to copy the whole array. Regards, Michael Am 08.02.26 um 14:17 schrieb Michael Geddes: > Answers below > > On Sun, 8 Feb 2026, 16:52 Michael Balzer, <dexter(a)expeedo.de> wrote: > > You're right, if the DBC engine or poller need some extra > variables, these must not be JS variables. Metrics OTOH should be > used only for vehicle or system states & sensor readings that are > meant to be exposed to all components & users, so some extra > internal variable container shared between DBC/polling and JS > makes sense. > > Ok. Will add something for that. > > > I don't yet see the issue with the duktape vehicle objects & > commands, can you elaborate on this, or provide an example of the > issue you see? > > The plugin way would make scripted vehicles simply extend the list > of available vehicle types, enabling adding multiple of these as > needed and switching between these without an additional level / > separate way to configure these. From a user perspective they > should behave just like native vehicle modules. > > Ok. Makes sense to have the extra modules in the list.. I was thinking > that we wouldn't want to have loaded the extra modules into duktape. > Hence the idea of a manifest we could include in the list. Then when > that was selected it could load the plugin... or make it available. > Also then it could be unloaded similarly. > > > I think using standard `PubSub` event handlers for a scripted > vehicle is most convenient, as these enable direct access to the > plugin's internal model & methods, so these don't need to be > exposed via an export. > > The Tasmota Smart Plug plugin is probably a good example for a > plugin including event handling, configuration & a status plugin > with a live update stream. > > Regards, > Michael > > > Am 08.02.26 um 09:17 schrieb Michael Geddes: >> On temporary variables: I was more thinking of the ones that are >> set from the poller and dbc engine, not other scripting ones >> (which I agree can be just duktape variables). >> >> Regular polls should not be calling back into the scripting >> engine directly. If, for example, there is an OBD value that >> needs more than a simple factor or unit conversion (which can be >> handled directly) you could use a non-persisted metric as a >> stepping stone to set a more concrete metric. If this is NOT >> acceptable, then we would need a mechanism or prefix or >> something, that would allow us to store the value in a shared >> std::map which could be made available to the duktape interface. >> So a target in DBC of _temp_myvariable could then have >> 'myvariable' available in duktape somehow. >> >> I see what you mean by the standard plugin.. but then there are >> certain duktape objects and commands that require an active >> vehicle.. which is why I was thinking that a special vehicle >> object could activate this plugin on load. We could still >> leverage off standard plugin stuff (which makes sense, I should >> have a look at that), but it could be enabled/disabled by the >> special vehicle type. The vehicle plugins could have a standard >> registration file so that we could then have a drop-down with the >> available plugin-vehicles specified, allowing you to switch >> between different 'plugin vehicles'. >> >> In the example of having scripted event files, I was thinking >> that this could be on top of javascript events (if, for example, >> you wanted to use shared variables). >> >> //.ichael >> >> >> On Sun, 8 Feb 2026 at 15:52, Michael Balzer via OvmsDev >> <ovmsdev(a)lists.openvehicles.com> wrote: >> >> I think JS addable custom metrics are a crucial element here, >> as most vehicles provide extended info not covered by the >> standard metrics. But metrics should not be the means to >> implement vehicle internal temporary variables. >> >> IMO a scripted vehicle should be basically a standard plugin. >> >> That way we have a simple way of adding these, and we also >> already have the web plugins bundled to cover custom config & >> monitoring pages of a scripted vehicle. >> >> The plugin's JS module then provides an internal object scope >> for any temporary variables and event handlers needed in one >> place. I.e. not separate files for actions / handlers, but >> load & parse all necessary code on JS init, and especially no >> need to use metrics for internal temporary variables. >> >> The vehicle factory would get a JS API to register/deregister >> a scripted vehicle, and the module would export a defined >> standard set of entry points to be called by the vehicle >> factory to load/unload a scripted vehicle (and what else >> might be needed). >> >> The load call would then do all the necessary metrics & event >> & command registrations, load the DBC file and install a >> custom polling list, and enable the plugin's web pages & >> hooks (these should be disabled until then, that may need an >> extension to the plugin definition, and probably an API call >> to avoid having to change the web plugin config directly). >> >> Btw, regarding plugin web pages, especially for configuration >> pages it would be nice (but not crucial) to have some JS >> based form input widget rendering helpers similar to the >> `PageContext` utils. Currently a web plugin needs to include >> the HTML code, which really isn't that complicated with the >> bootstrap components, so this really is more of a nice2have. >> >> Regards, >> Michael >> >> >> Am 08.02.26 um 01:20 schrieb Michael Geddes via OvmsDev: >>> Just a thought, but being able to add custom metrics would >>> do a lot. Non-persisting metrics would handle temporary >>> variables too no? >>> >>> Responding to temporary metric change events would then >>> allow Responding to changes to polled variables. >>> >>> Also note that the poller.Add requires a unique id which >>> means the same one added twice will just overwrite the >>> previous one. >>> //. >>> >>> >>> On Sat, 7 Feb 2026, 21:44 Michael Geddes, >>> <frog(a)bunyip.wheelycreek.net> wrote: >>> >>> The active polling is already implemented with >>> OvmsPoller.Poll.Add() which hooks into my poller stuff >>> (which was pretty much the whole reason I started down >>> that road). >>> >>> This allows you to send polled messages and either let >>> DBC files handle the listening, or it has its own decode >>> function. The decode system actually uses the DBC code, >>> but multiframe responses are handled with slightly >>> different buffers. >>> >>> OvmsPoller.Poll.Request() also allows you to do one-off >>> calls with a call back for the response (so not blocking). >>> >>> Have a look at the scripting help.. it's all there. >>> >>> I was thinking we could have a special >>> OvmsVehicleScripted() that when selected loads files >>> from a certain configured directory. Like >>> >>> /sd/vehicles/Ioniq5/ >>> init.js >>> shutdown.js >>> events/ >>> ticker1.js >>> >>> Then the init.js could call back to provide the vehicle >>> a name, and set up some events and polling. >>> >>> We could add in events/ so that there's a choice >>> between adding the events in init.js or responding by >>> running js or other scripts. >>> >>> At the moment we have special targets in dbc/ or decode >>> {} sections that are metrics, and I'm just adding in the >>> ability to handle the battery voltage/temp averaging >>> code bms.v.1 and to set elements in vector metrics. >>> >>> We could have other types of special targets that could >>> be in-memory and then be either polled or triggered >>> events on change or something. >>> >>> So anyway, much of that stuff you were talking about is >>> already done. >>> >>> //.ichael >>> >>> On Sat, 7 Feb 2026, 21:23 Mark Webb-Johnson, >>> <mark(a)webb-johnson.net> wrote: >>> >>> Michael, >>> >>> Happy to support you with this. I am currently >>> completing my work on the partition rearrangement, >>> and when done I can assist with this. Perhaps I can >>> try to implement a vehicle type in pure Javascript? >>> My current daily driver Model 3 is well documented, >>> but only has stubbed OVMS support. >>> >>> My thoughts on how this should work are: >>> >>> 1. The vehicle base class should have a companion >>> helper class for pure javascript vehicle >>> implementations (extend the current >>> vehicle_duktape). This would be in the >>> components/vehicle directory. >>> 2. Javascript vehicles are implemented as plugins, >>> and they can call that companion class to >>> register their vehicle type and callback >>> functions. So plugin loads, registers itself >>> with vehicle_duktape, which in turn does >>> the MyVehicleFactory.RegisterVehicle(…). >>> 3. The ‘auto’ system, and ‘vehicle module’, >>> ‘vehicle list’, etc, commands, then just treat >>> these javascript vehicles the same as any other. >>> 4. Obviously all the base vehicle class functions >>> would need to have callbacks / exposed to >>> javascript implementations. >>> 5. For CAN bus, I see two options: >>> 1. For passive listening, DBC files are >>> primarily used. Just need an ability (may >>> already exist) for the javascript vehicle to >>> attach one to the CAN bus. >>> 2. For active polling, we would need to either >>> come up with some new format (I know torque >>> and other such apps have a proprietary >>> definition file format for PIDs that we >>> could adapt from) or just define the polling >>> table from javascript. >>> 6. In both options, we would also need to be able >>> to override and have particular passively >>> listened CAN IDs, or actively polled PIDs, >>> callback to javascript for custom processing. I >>> suspect it would be helpful to have a time limit >>> on these callbacks - so if for example you >>> specify 1000ms then you would only get the >>> callback at most once a second. Javascript will >>> be much more overhead than C++ handling these >>> CAN messages, and in most cases we don’t need >>> them updated that regularly. Think of a battery >>> SOC - does it really need to update 10 or 100 >>> times a second for our purposes? >>> >>> >>> I suggest to just focus on passive listening (DBC >>> and an optional CAN ID callback). Fist build the >>> registration functions callable from Javascript. >>> >>> After I'm done with partitions, I’ll have a look at >>> this code in more detail as it has been a while >>> since I’ve worked on that part. >>> >>> Regards, Mark. >>> >>>> On Feb 7, 2026, at 8:17 AM, Michael Geddes via >>>> OvmsDev <ovmsdev(a)lists.openvehicles.com> wrote: >>>> >>>> With this talk about running out of space on the >>>> devices, I wanted to open up a discussion about how >>>> we might organise a vehicle implementation in Duktape. >>>> >>>> To clarify - I'm not sure about all these pieces- >>>> they are just suggestions that I would love some >>>> feedback on. >>>> >>>> * Have a special 'Duktape' vehicle that then can >>>> be set to load up a special folder location >>>> containing all the pieces >>>> o Add in an extra folder for events? (cf >>>> requiring DukTape event registration) >>>> * Be able to set the vehicle name (for the menu) >>>> * Allow adding the standard battery monitor page >>>> (I have code for updating the bms code nearly >>>> ready to ship) >>>> * Adding custom configuration pages (I'm thinking >>>> a call-back to fetch the page layout or a >>>> callback object or something?) >>>> * Defining ranges for the main dashboard >>>> * Can already add duktape implemented commands - >>>> should there be a specific folder for vehicle >>>> implementation or leave as-is? >>>> >>>> What other pieces are we missing to be able to >>>> handle new vehicles in duktape? >>>> >>>> //.ichael >>>> >>>> . >>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev(a)lists.openvehicles.com >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>> >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev(a)lists.openvehicles.com >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> >> -- >> Michael Balzer *Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gma…> >> Fon 02330 9104094 * Handy 0176 20698926 >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev(a)lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> > > -- > Michael Balzer *Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gma…> > Fon 02330 9104094 * Handy 0176 20698926 > > -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

Registering / Web pages for Scripted Implementation
by Michael Geddes 08 Feb '26

08 Feb '26

With this talk about running out of space on the devices, I wanted to open up a discussion about how we might organise a vehicle implementation in Duktape. To clarify - I'm not sure about all these pieces- they are just suggestions that I would love some feedback on. - Have a special 'Duktape' vehicle that then can be set to load up a special folder location containing all the pieces - Add in an extra folder for events? (cf requiring DukTape event registration) - Be able to set the vehicle name (for the menu) - Allow adding the standard battery monitor page (I have code for updating the bms code nearly ready to ship) - Adding custom configuration pages (I'm thinking a call-back to fetch the page layout or a callback object or something?) - Defining ranges for the main dashboard - Can already add duktape implemented commands - should there be a specific folder for vehicle implementation or leave as-is? What other pieces are we missing to be able to handle new vehicles in duktape? //.ichael .

3 6

Adding support for eGolf
by Erick Fuentes 06 Feb '26

06 Feb '26

Hello! I recently bought a 2019 eGolf and I'm interested in getting support for it in the project. Some folks on the OVMS Discord server have code that appears to work and I've volunteered to try to merge it. I've yet to run the code myself (I'm still waiting on a harness), but I thought I'd ask what the process might look like. Do you want small pull requests where each one covers a single, small feature? Are you okay with merging everything at once, provided it doesn't break other vehicles? Erick

3 5

Fwd: Mbed Platform End of Life in July 2026
by Mark Webb-Johnson 02 Feb '26

02 Feb '26

On the one hand, sad to see Mbed go. It was an interesting platform. On the other hand, in retrospect, glad we didn’t choose it for OVMS ;-) Regards, Mark > Begin forwarded message: > > From: mbed notifications <no-reply(a)mbed.com> > Subject: Mbed Platform End of Life in July 2026 > > > > Mbed Platform End of Life in July 2026 > We wanted to remind you that the Mbed platform and Mbed OS will reach end of life in July 2026. The Mbed website will no longer be accessible, and its online build tools will be discontinued. Mbed OS will remain open source and publicly accessible <https://github.com/ARMmbed/mbed-os>, but it will no longer be actively maintained by Arm. > > > What this means for you: > Please avoid starting any new commercial projects on Mbed and begin planning to migrate existing ones to alternative frameworks. > We recommend exporting any code or data you have on Mbed.com <http://mbed.com/> to another platform using the export tool available in your Mbed account. > Mbed OS support in Keil Studio Cloud will be removed. > For more details and guidance, you can read the full announcement here: Important Update on Mbed <https://os.mbed.com/blog/entry/Important-Update-on-Mbed/>. > > > > > Home <https://os.mbed.com/> | Account Preferences <https://os.mbed.com/account/edit/profile/> | Trademarks <https://www.arm.com/company/policies/trademarks> > > <https://www.linkedin.com/company/arm> <https://www.youtube.com/user/Armflix> <https://en-gb.facebook.com/Arm/> <https://x.com/Arm> > Copyright © 2026 Arm Limited (or its affiliates). >

1 0