Thanks Michael, . That's helped a lot in refocusing my approach 12v Aux Monitor: ----------------------- I have been looking at the 12v Aux monitor code, in addition to simplifying the monitor to use 2 smoothed averages (a shorter one and a longer one), I've also looked at using my smoothing class at the source of the battery voltage measurement (smoothing the source integer value). Interestingly, I notice that there are a couple of vehicle implementations that are setting that value as well.. which I'm not sure is a good thing!? For the 12V monitor I have a version that I'm working on that tries to match the other 12V events and messages. It might be worth me just submitting that as the p/r. I have the following events: vehicle.aux.12v.normal vehicle.aux.12v.charging vehicle.aux.12v.charging.dip vehicle.aux.12v.charging.blip vehicle.aux.12v.blip vehicle.aux.12v.dip vehicle.aux.12v.low . with these 'dip' is where the voltage has a bit of a trough, and 'blip' indicates there is a spike. Extended DBC ----------------------- I take your point about the speed, so I'm working on a better idea). I have been going over the DBC stuff.. I've been implementing the extended multiplexers (m98M), which is necessary _if_ the DBC file is going to interpret the multi-frame reponses. I've also consolidated so there is only one piece of code (now on the DBC Signal) interpreting the Muxed data, which handles either going to metrics or to a writer. Extended Multiplex example (with M, m98M and m256) and the SG_MUL_VAL to link and provided extended ranges. BO_ 1979 Temperature: 54 Vector__XXX SG_ IndoorTemperature m256 : 79|8@0+ (0.5,-40) [-50|50] "degC" Vector__XXX SG_ response m98M : 23|16@0+ (1,0) [0|0] "unit" Vector__XXX SG_ service M : 15|8@0+ (1,0) [0|0] "" Vector__XXX SG_ OutdoorTemperature m256 : 87|8@0+ (0.5,-40) [-50|50] "degC" Vector__XXX SG_ VehicleSpeed m256 : 271|8@0+ (1,0) [0|200] "kmh" Vector__XXX SG_MUL_VAL_ 1979 IndoorTemperature response 256-256; SG_MUL_VAL_ 1979 response service 98-98; SG_MUL_VAL_ 1979 OutdoorTemperature response 256-256; SG_MUL_VAL_ 1979 VehicleSpeed response 256-256; I have it now that the UNITS specified in the DBC file are used when setting the value. If they match our internal unit strings they will be set using that unit. I also implemented the VAL_TABLE_ lookup (which seems to have been partially implemented) to store status strings. I'm yet to find time to test all this to make sure nothing is broken and that the new stuff works as intended!! The interesting part of that is that looking at a DBC implementation I noticed that there's a difference between how the DBC wants to look at the multi-frame data and how we look at the data coming in (which is similar to the Torque+ one), which is that DBC files see the multi-frame data as all the 8 bytes of frame packet data concatenated together (which includes the PIDs), whereas the other way looks at it as a PID plus the concatenation of the payload (5 + 7 + 7 or whatever it is). Also the DBC file looks at bits rather than bytes. (Torque+ specification has the ability to get flags out of a byte). What do you think of the idea of moving the DBC interpreting to the Poller class away from the DBC vehicle implementation? The DBC vehicle can still auto-load the files but the poller would be responsible for seeing a DBC pointer and interpreting the signals. It kind of has to because of the multi-frame data. For multi-frame data I'm looking at a variation to ObdRequest() call that would cause the extended packets to be sent to the DBC file to interpret (sending the concatenated 8 byte packets of payload). Extending DukTape OdbRequest() ----------------------- The ObdRequest() duktape calls should probably reside on the Poller rather than the vehicle. It might be preferable to be able to call ObdRequest() with a call-back rather than the blocking call that happens now. The non-blocking one-off OBD calls are supported by the new poller framework. I'm also thinking that it would be good to have a separate mechanism that could add entries to the poller list. I'm also wondering whether a different way of specifying the data would be useful (via DukTape).. using the Payload concatenated bytes, the great thing is we could still use the DBC code to interpret the signals. (we could have a map of dbcSignal per address + PID). Thoughts? //.ichael -----Original Message----- From: OvmsDev <ovmsdev-bounces@lists.openvehicles.com> On Behalf Of Michael Balzer via OvmsDev Sent: Sunday, 1 September 2024 4:04 PM To: ovmsdev@lists.openvehicles.com Cc: Michael Balzer <dexter@expeedo.de> Subject: Re: [Ovmsdev] Duktape Vehicle 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