Hi All,
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.