[Ovmsdev] Duktape support for polling lists - p/r submitted.

Michael Geddes frog at bunyip.wheelycreek.net
Sun Apr 6 16:06:44 HKT 2025


Hi All,
This is the P/R here:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1126

This is really where I was heading with the Poller implementation, in that
it allows user-space additions to the polling infrastructure.  The
complexity of the specification means that it's really more appropriate to
Duktape than to a cli script.

It is definitely "a lot", and I suspect/suggest that it would be deferred
until a release is made.

I'm quite pleased with this implementation which has already been very much
improved by people's observations and suggestions:
* The Once-Off command call is the only one that calls back to duktape
* The Decoding re-uses the DBC internals to achieve programmatic decoding.
* It extends the various Duktape functions to control/interact with various
aspects of the vehicle and poller (while giving necessary isolation).

For anybody interested in the idea of being able to make a vehicle
implementation in Duktape, this is worth having a look at!

I do have some DBC Duktape commands ready to go as well.

There is still some bits to do with the battery v/temp arrays that I've not
quite covered. I have some ideas but they are not quite there yet.
In the implementation I have already abstracted the destination 'Metric'
and this is where this would fit in - ie the ability to populate the v/t
array separately and then have some way of triggering the storing of those
values.
The internals are the BmsRestartCellTemperatures() and
BmsSetCellTemperature( ) and other related functions which would need to be
somehow called.

//.ichael G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250406/5af5eb6a/attachment.htm>


More information about the OvmsDev mailing list