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