<div dir="ltr">Hi All,<div>This is the P/R here: <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1126">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1126</a></div><div><br></div><div>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.</div><div><br></div><div>It is definitely "a lot", and I suspect/suggest that it would be deferred until a release is made.</div><div><br></div><div>I'm quite pleased with this implementation which has already been very much improved by people's observations and suggestions:</div><div>* The Once-Off command call is the only one that calls back to duktape</div><div>* The Decoding re-uses the DBC internals to achieve programmatic decoding.</div><div>* It extends the various Duktape functions to control/interact with various aspects of the vehicle and poller (while giving necessary isolation).</div><div><br><div>For anybody interested in the idea of being able to make a vehicle implementation in Duktape, this is worth having a look at!</div></div><div><br></div><div>I do have some DBC Duktape commands ready to go as well.</div><div><br></div><div>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.</div><div>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.</div><div>The internals are the BmsRestartCellTemperatures() and BmsSetCellTemperature( ) and other related functions which would need to be somehow called.</div><div><br></div><div>//.ichael G.</div></div>