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