Michael, detecting 12V indications for ECU operation is generally a framework candidate, as there have been multiple vehicles that (at least initially) needed to rely on this. It's in the same category of framework features as the 12V monitoring. Providing the info to the vehicle can be done using the same scheme as other vehicle framework hooks do, and if you include events for crossing the hysteresis boundaries, it's also easy for scripts to hook into this. Regarding a full Duktape based vehicle implementation, that needs more framework support, especially for automated CAN polling with preprocessing & storing the responses, as Duktape is too slow for high speed low level operations like this (there's also the single thread limit). The DBC vehicle is a precursor or possibly a base for this. The DBC approach currently supports defining a fixed message to metrics translation, which can provide basic vehicle data decoding. It lacks a way to define polling schemes and possibly poll state transitions. Poll state/list transition handling might then be delegated to the Duktape extension. Duktape can also be used to process CAN data/responses/states that are too complex for simple metrics translations, it just needs an intermediate data layer for this, and some event / callback scheme to be triggered only when there is a relevant change in the respective containers. I think the DBC vehicle also has some basic data layer support already, worth taking a look at. The DBC implementation was done by Mark. I wrote a DBC primer: https://docs.openvehicles.com/en/latest/components/vehicle_dbc/docs/dbc-prim... The initial Fiat 500 support was done using DBC. We also had some discussion about polling definition standards for DBC. Ludovic Lange created a kickoff issue for this on github: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/755 Regards, Michael Am 31.08.24 um 11:19 schrieb Michael Geddes via OvmsDev:
In a recent conversation with Mark we were talking about utilising Duktape more for perhaps even vehicle implementations.
I'm wondering if a better approach is to allow any vehicle to be extended via hooks in the base vehicle class or would it be better to have a duktape vehicle that could be extended.
There would necessarily be many bits to the puzzle. For example I have a class that allows us to know when blips to the 12V battery line might mean that somebody is interacting with the car so we should start polling the bus.. Should we put this (with a duktape interface) at the vehicle.h level?
//.ichael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26