[Ovmsdev] Registering / Web pages for Scripted Implementation
Michael Geddes
frog at bunyip.wheelycreek.net
Sun Feb 8 16:17:50 HKT 2026
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 at 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 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
>>>
>>>
>>>
> _______________________________________________
> OvmsDev mailing listOvmsDev at 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 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/0eb8d51d/attachment-0001.htm>
More information about the OvmsDev
mailing list