[Ovmsdev] Registering / Web pages for Scripted Implementation
Michael Balzer
dexter at expeedo.de
Sun Feb 8 15:52:16 HKT 2026
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20260208/dce3cfff/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/dce3cfff/attachment-0001.sig>
More information about the OvmsDev
mailing list