[Ovmsdev] Registering / Web pages for Scripted Implementation
Michael Balzer
dexter at expeedo.de
Sun Feb 8 16:52:53 HKT 2026
You're right, if the DBC engine or poller need some extra variables,
these must not be JS variables. Metrics OTOH should be used only for
vehicle or system states & sensor readings that are meant to be exposed
to all components & users, so some extra internal variable container
shared between DBC/polling and JS makes sense.
I don't yet see the issue with the duktape vehicle objects & commands,
can you elaborate on this, or provide an example of the issue you see?
The plugin way would make scripted vehicles simply extend the list of
available vehicle types, enabling adding multiple of these as needed and
switching between these without an additional level / separate way to
configure these. From a user perspective they should behave just like
native vehicle modules.
I think using standard `PubSub` event handlers for a scripted vehicle is
most convenient, as these enable direct access to the plugin's internal
model & methods, so these don't need to be exposed via an export.
The Tasmota Smart Plug plugin is probably a good example for a plugin
including event handling, configuration & a status plugin with a live
update stream.
Regards,
Michael
Am 08.02.26 um 09:17 schrieb Michael Geddes:
> 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
>>> o 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 list
>> OvmsDev at lists.openvehicles.com
>> http://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
>
--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20260208/7f7e4e28/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20260208/7f7e4e28/attachment-0001.sig>
More information about the OvmsDev
mailing list