[Ovmsdev] Registering / Web pages for Scripted Implementation

[Michael Geddes]

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 at 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 at 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 at 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 at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20260208/14c360a8/attachment-0001.htm>