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@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@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@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@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 - 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev