
<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Michael,<div><br></div><div>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.</div><div><br></div><div>My thoughts on how this should work are:</div><div><br></div><div><ol class="MailOutline"><li>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.</li><li>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(…).</li><li>The ‘auto’ system, and ‘vehicle module’, ‘vehicle list’, etc, commands, then just treat these javascript vehicles the same as any other.</li><li>Obviously all the base vehicle class functions would need to have callbacks / exposed to javascript implementations.</li><li>For CAN bus, I see two options:</li><ol class="MailOutline"><li>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.</li><li>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.</li></ol><li>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?</li></ol></div><div><br></div><div>I suggest to just focus on passive listening (DBC and an optional CAN ID callback). Fist build the registration functions callable from Javascript.</div><div><br></div><div>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.</div><div><br></div><div>Regards, Mark.<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Feb 7, 2026, at 8:17 AM, Michael Geddes via OvmsDev <ovmsdev@lists.openvehicles.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">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.<div><br></div><div>To clarify - I'm not sure about all these pieces- they are just suggestions that I would love some feedback on.</div><div><br></div><div><ul><li> Have a special 'Duktape' vehicle that then can be set to load up a special folder location containing all the pieces</li><ul><li>Add in an extra folder for events? (cf requiring DukTape event registration)</li></ul><li>Be able to set the vehicle name (for the menu)</li><li>Allow adding the standard battery monitor page (I have code for updating the bms code nearly ready to ship)</li><li>Adding custom configuration pages (I'm thinking a call-back to fetch the page layout or a callback object or something?)</li><li>Defining ranges for the main dashboard</li><li>Can already add duktape implemented commands - should there be a specific folder for vehicle implementation or leave as-is?</li></ul>What other pieces are we missing to be able to handle new vehicles in duktape?</div><div><br></div><div>//.ichael</div><div><div><br></div></div><div>. </div><div><br></div><div><br></div></div>

_______________________________________________<br>OvmsDev mailing list<br>OvmsDev@lists.openvehicles.com<br>http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br></div></blockquote></div><br></div></body></html>