Thoughts on Metrics - new 'standard metric' candidates and right drive cars
Hi all, I started this thought following up on my Ioniq 5 thread - but figured it might be worth a new conversation. Michael B talked about having some new standard metrics (and also some consistent metric names in my i5 code: patch coming now that I understand a bit better why those exist). The Door Locked series is obviously a good start - the candidate names being pretty straight forward imho. v.d.l.fl v.d.l.fr v.d.l.rl v.d.l.rr Most cars these days would have seatbelt sensors - so they might also be a candidate. v.sb.fl etc. That being said, I have some issues related to 'right-hand-drive' vehicles which are quite popular in Australia ;). For a start, there's no metric for it; obviously some cars implementations will have a setting. For the Hyundai this is important as it seems many left/right settings are actually based on drive/passenger side in the OBD bits. Sooo.. I was considering some of the issues: 1) When it's on a diagram or in a user message, we want left/right because that's how we want to deal with it. 2) In general scared scripts, we probably care more about whether it is drive/passenger side rather than left/right! Could we have some metric alias's for left/right metrics that would be drive/passenger that would allow * Setting via either metric * Reading via either metric * Adding events based on either metric. For eg v.d.l.fl links to * v.d.l.fd (front driver) for Left-hand drive and * v.d.l.fp (front passenter) for Right-hand drive cars. I mean we could set both metrics.. but would that work? Thoughts on this? //.ichael
Michael, I also had some thoughts on this, some first feedback from these on yours: * I'd place seatbelt sensors in a new name space "v.s." for vehicle safety & security related metrics. That would also become the place for airbag & emergency braking sensors, traction control & emergency lights and the like. * I'd decouple the "driver" & "passenger" roles from the physical allocation, because this may become a property that can be changed on the fly even during driving, as soon as all vehicle controls are digital. * The "driver" metric may then also be assigned to a special value to represent autonomous driving modes. * I also think about arrays instead of fixed geometric layouts, as vehicles come in a variety of door & seat arrangements. Regards, Michael Am 05.11.22 um 11:07 schrieb Michael Geddes:
Hi all, I started this thought following up on my Ioniq 5 thread - but figured it might be worth a new conversation.
Michael B talked about having some new standard metrics (and also some consistent metric names in my i5 code: patch coming now that I understand a bit better why those exist).
The Door Locked series is obviously a good start - the candidate names being pretty straight forward imho. v.d.l.fl v.d.l.fr <http://v.d.l.fr> v.d.l.rl v.d.l.rr Most cars these days would have seatbelt sensors - so they might also be a candidate. v.sb.fl etc.
That being said, I have some issues related to 'right-hand-drive' vehicles which are quite popular in Australia ;). For a start, there's no metric for it; obviously some cars implementations will have a setting. For the Hyundai this is important as it seems many left/right settings are actually based on drive/passenger side in the OBD bits.
Sooo.. I was considering some of the issues:
1) When it's on a diagram or in a user message, we want left/right because that's how we want to deal with it. 2) In general scared scripts, we probably care more about whether it is drive/passenger side rather than left/right!
Could we have some metric alias's for left/right metrics that would be drive/passenger that would allow * Setting via either metric * Reading via either metric * Adding events based on either metric. For eg v.d.l.fl links to * v.d.l.fd (front driver) for Left-hand drive and * v.d.l.fp (front passenter) for Right-hand drive cars. I mean we could set both metrics.. but would that work?
Thoughts on this? //.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
I like the idea of the v.s.* namespace. We could just have 'v.driver' = Left/Right/Auto - since really it's the Driver roll that is possibly the one that would be scripted on. I'm still not sure how you would then easily get at the 'driver-side-door' or 'driver-side-seatbelt' values. How would you manage the arrays and make it easy to work with in extracting left/right/centre front/back etc? Associative array could work .. though that's not that different from the current *.fl *.fr etc. //.ichael On Sat, 5 Nov 2022 at 18:32, Michael Balzer <dexter@expeedo.de> wrote:
Michael,
I also had some thoughts on this, some first feedback from these on yours:
- I'd place seatbelt sensors in a new name space "v.s." for vehicle safety & security related metrics. That would also become the place for airbag & emergency braking sensors, traction control & emergency lights and the like. - I'd decouple the "driver" & "passenger" roles from the physical allocation, because this may become a property that can be changed on the fly even during driving, as soon as all vehicle controls are digital. - The "driver" metric may then also be assigned to a special value to represent autonomous driving modes. - I also think about arrays instead of fixed geometric layouts, as vehicles come in a variety of door & seat arrangements.
Regards, Michael
Am 05.11.22 um 11:07 schrieb Michael Geddes:
Hi all, I started this thought following up on my Ioniq 5 thread - but figured it might be worth a new conversation.
Michael B talked about having some new standard metrics (and also some consistent metric names in my i5 code: patch coming now that I understand a bit better why those exist).
The Door Locked series is obviously a good start - the candidate names being pretty straight forward imho. v.d.l.fl v.d.l.fr v.d.l.rl v.d.l.rr Most cars these days would have seatbelt sensors - so they might also be a candidate. v.sb.fl etc.
That being said, I have some issues related to 'right-hand-drive' vehicles which are quite popular in Australia ;). For a start, there's no metric for it; obviously some cars implementations will have a setting. For the Hyundai this is important as it seems many left/right settings are actually based on drive/passenger side in the OBD bits.
Sooo.. I was considering some of the issues:
1) When it's on a diagram or in a user message, we want left/right because that's how we want to deal with it. 2) In general scared scripts, we probably care more about whether it is drive/passenger side rather than left/right!
Could we have some metric alias's for left/right metrics that would be drive/passenger that would allow * Setting via either metric * Reading via either metric * Adding events based on either metric. For eg v.d.l.fl links to * v.d.l.fd (front driver) for Left-hand drive and * v.d.l.fp (front passenter) for Right-hand drive cars. I mean we could set both metrics.. but would that work?
Thoughts on this? //.ichael
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
The arrays would go along the scheme of the recent similar transition for the TPMS, with the names factored out into a common vehicle configuration: * http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/2206... Factoring out the configuration solves the need for metric value structures getting more complex than arrays. In this scheme, more properties can be added simply by additional array metrics (as was needed by the TPMS extension), and a runtime configuration change (e.g. when towing a trailer or reconfiguring a family van seat rows) is a simple array size change. The "driver" could be the seat array index in this scheme, or -1 for "no driver". There is an open todo regarding a general query scheme for vehicle configurations like these. This also applies to e.g. the battery pack layout, and also to the features / commands supported etc.. We formerly called these "capabilities" (in the OVMS V2 framework), but the capabilities data model was too limited for V3. There was no real need to implement a V3 approach for this previously, but as we're now about to extend the metrics / vehicle configuration dependencies, this should maybe addressed now as well. Initial thoughts on this: In the V3 scheme, vehicle configurations & features could be seen & implemented as read-only configuration instances, i.e. reusing the existing naming & querying & API scheme for user configurations. The user interface would be a read-only config parameter "vehicle.config" (or "vehicle.features" or "vehicle.support" for the functional coverage?) for standard configurations, likewise vehicle specific ones as "<vehicleprefix>.config" as needed. Example: // 5 seat car with a driver, a small child on the FR seat (airbag disabled) and another child on the RR: v.s.seat.load 67,12,0,0,32kg v.s.seat.belt 1,1,0,0,1 v.s.seat.airbag 1,2,1,0,1 // FL seat heating on level 2, RR level 1: v.e.seat.heating 2,0,0,0,1 // Driver is person on FL seat: v.e.driver 0 // Query vehicle configuration: OVMS# config list vehicle.config vehicle.config (readable) tpms.layout FL,FR,RL,RR seat.layout FL,FR,RL,RM,RR … // Query vehicle feature support: OVMS# config list vehicle.support vehicle.support (readable) ctrl.chg mode,current,start,stop,limit,timer ctrl.env climate,doors,valet,homelink ctrl.sys wakeup info.bat soc,range,soh,energy,bms info.chg mode,current,state,duration,limit info.env temps,doors,tpms … Comments? Regards, Michael Am 05.11.22 um 12:11 schrieb Michael Geddes:
I like the idea of the v.s.* namespace.
We could just have 'v.driver' = Left/Right/Auto - since really it's the Driver roll that is possibly the one that would be scripted on. I'm still not sure how you would then easily get at the 'driver-side-door' or 'driver-side-seatbelt' values.
How would you manage the arrays and make it easy to work with in extracting left/right/centre front/back etc? Associative array could work .. though that's not that different from the current *.fl *.fr etc.
//.ichael
On Sat, 5 Nov 2022 at 18:32, Michael Balzer <dexter@expeedo.de> wrote:
Michael,
I also had some thoughts on this, some first feedback from these on yours:
* I'd place seatbelt sensors in a new name space "v.s." for vehicle safety & security related metrics. That would also become the place for airbag & emergency braking sensors, traction control & emergency lights and the like. * I'd decouple the "driver" & "passenger" roles from the physical allocation, because this may become a property that can be changed on the fly even during driving, as soon as all vehicle controls are digital. * The "driver" metric may then also be assigned to a special value to represent autonomous driving modes. * I also think about arrays instead of fixed geometric layouts, as vehicles come in a variety of door & seat arrangements.
Regards, Michael
Am 05.11.22 um 11:07 schrieb Michael Geddes:
Hi all, I started this thought following up on my Ioniq 5 thread - but figured it might be worth a new conversation.
Michael B talked about having some new standard metrics (and also some consistent metric names in my i5 code: patch coming now that I understand a bit better why those exist).
The Door Locked series is obviously a good start - the candidate names being pretty straight forward imho. v.d.l.fl v.d.l.fr <http://v.d.l.fr> v.d.l.rl v.d.l.rr Most cars these days would have seatbelt sensors - so they might also be a candidate. v.sb.fl etc.
That being said, I have some issues related to 'right-hand-drive' vehicles which are quite popular in Australia ;). For a start, there's no metric for it; obviously some cars implementations will have a setting. For the Hyundai this is important as it seems many left/right settings are actually based on drive/passenger side in the OBD bits.
Sooo.. I was considering some of the issues:
1) When it's on a diagram or in a user message, we want left/right because that's how we want to deal with it. 2) In general scared scripts, we probably care more about whether it is drive/passenger side rather than left/right!
Could we have some metric alias's for left/right metrics that would be drive/passenger that would allow * Setting via either metric * Reading via either metric * Adding events based on either metric. For eg v.d.l.fl links to * v.d.l.fd (front driver) for Left-hand drive and * v.d.l.fp (front passenter) for Right-hand drive cars. I mean we could set both metrics.. but would that work?
Thoughts on this? //.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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ 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
Ah. Starting to see it. So you are having the whole of vehicle.config as returning an associative array of config values? I guess that keeps that bit of it separate. makes sense even if a bit of work. Can we return an associative array to duktape? When I introduce 'metric get' (which is just waiting some finessing of the Duktape code) it would be modified to allow indexes into arrays... so metric get v.s.seat.load[0] or metric get v.s.seat.load[FL] and metric get vehicle.support[info.bat] Is that the kind of idea? //.ichael On Sun, 6 Nov 2022, 6:19 pm Michael Balzer, <dexter@expeedo.de> wrote:
The arrays would go along the scheme of the recent similar transition for the TPMS, with the names factored out into a common vehicle configuration:
- http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html - https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/2206...
Factoring out the configuration solves the need for metric value structures getting more complex than arrays. In this scheme, more properties can be added simply by additional array metrics (as was needed by the TPMS extension), and a runtime configuration change (e.g. when towing a trailer or reconfiguring a family van seat rows) is a simple array size change.
The "driver" could be the seat array index in this scheme, or -1 for "no driver".
There is an open todo regarding a general query scheme for vehicle configurations like these. This also applies to e.g. the battery pack layout, and also to the features / commands supported etc.. We formerly called these "capabilities" (in the OVMS V2 framework), but the capabilities data model was too limited for V3.
There was no real need to implement a V3 approach for this previously, but as we're now about to extend the metrics / vehicle configuration dependencies, this should maybe addressed now as well.
Initial thoughts on this:
In the V3 scheme, vehicle configurations & features could be seen & implemented as read-only configuration instances, i.e. reusing the existing naming & querying & API scheme for user configurations.
The user interface would be a read-only config parameter "vehicle.config" (or "vehicle.features" or "vehicle.support" for the functional coverage?) for standard configurations, likewise vehicle specific ones as "<vehicleprefix>.config" as needed.
Example:
// 5 seat car with a driver, a small child on the FR seat (airbag disabled) and another child on the RR: v.s.seat.load 67,12,0,0,32kg v.s.seat.belt 1,1,0,0,1 v.s.seat.airbag 1,2,1,0,1
// FL seat heating on level 2, RR level 1: v.e.seat.heating 2,0,0,0,1
// Driver is person on FL seat: v.e.driver 0
// Query vehicle configuration: OVMS# config list vehicle.config vehicle.config (readable) tpms.layout FL,FR,RL,RR seat.layout FL,FR,RL,RM,RR …
// Query vehicle feature support: OVMS# config list vehicle.support vehicle.support (readable) ctrl.chg mode,current,start,stop,limit,timer ctrl.env climate,doors,valet,homelink ctrl.sys wakeup info.bat soc,range,soh,energy,bms info.chg mode,current,state,duration,limit info.env temps,doors,tpms …
Comments?
Regards, Michael
Am 05.11.22 um 12:11 schrieb Michael Geddes:
I like the idea of the v.s.* namespace.
We could just have 'v.driver' = Left/Right/Auto - since really it's the Driver roll that is possibly the one that would be scripted on. I'm still not sure how you would then easily get at the 'driver-side-door' or 'driver-side-seatbelt' values.
How would you manage the arrays and make it easy to work with in extracting left/right/centre front/back etc? Associative array could work .. though that's not that different from the current *.fl *.fr etc.
//.ichael
On Sat, 5 Nov 2022 at 18:32, Michael Balzer <dexter@expeedo.de> wrote:
Michael,
I also had some thoughts on this, some first feedback from these on yours:
- I'd place seatbelt sensors in a new name space "v.s." for vehicle safety & security related metrics. That would also become the place for airbag & emergency braking sensors, traction control & emergency lights and the like. - I'd decouple the "driver" & "passenger" roles from the physical allocation, because this may become a property that can be changed on the fly even during driving, as soon as all vehicle controls are digital. - The "driver" metric may then also be assigned to a special value to represent autonomous driving modes. - I also think about arrays instead of fixed geometric layouts, as vehicles come in a variety of door & seat arrangements.
Regards, Michael
Am 05.11.22 um 11:07 schrieb Michael Geddes:
Hi all, I started this thought following up on my Ioniq 5 thread - but figured it might be worth a new conversation.
Michael B talked about having some new standard metrics (and also some consistent metric names in my i5 code: patch coming now that I understand a bit better why those exist).
The Door Locked series is obviously a good start - the candidate names being pretty straight forward imho. v.d.l.fl v.d.l.fr v.d.l.rl v.d.l.rr Most cars these days would have seatbelt sensors - so they might also be a candidate. v.sb.fl etc.
That being said, I have some issues related to 'right-hand-drive' vehicles which are quite popular in Australia ;). For a start, there's no metric for it; obviously some cars implementations will have a setting. For the Hyundai this is important as it seems many left/right settings are actually based on drive/passenger side in the OBD bits.
Sooo.. I was considering some of the issues:
1) When it's on a diagram or in a user message, we want left/right because that's how we want to deal with it. 2) In general scared scripts, we probably care more about whether it is drive/passenger side rather than left/right!
Could we have some metric alias's for left/right metrics that would be drive/passenger that would allow * Setting via either metric * Reading via either metric * Adding events based on either metric. For eg v.d.l.fl links to * v.d.l.fd (front driver) for Left-hand drive and * v.d.l.fp (front passenter) for Right-hand drive cars. I mean we could set both metrics.. but would that work?
Thoughts on this? //.ichael
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Michael, configs are no metrics, access would be by "config" / 'OvmsConfig', but yes, there are API calls there as well to retrieve sets of entries as objects: https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsconfig The config registry already provides read-only params. These could still be written to internally, i.e. by the vehicle module, or be completely under control of the vehicle module -- details need to be cleared. The main question is if this scheme fits from the system design perspective, or if we should add something like a dedicated vehicle config/features registry with a separate set of commands & APIs. The question here is, if we define "configuration" strictly as "module configuration", or if we extend that to "module & vehicle configuration". If read-only config params fit, the next question is if the proposed naming & value scheme would be OK. Functional coverage e.g. could also be spread out into single boolean instances, and for… metric get v.s.seat.load[FL] …"metric get" would either need to know the config instances defining names for metrics, or the instances would need to imply their metrics association somehow (by their name?), so this can be done in a generic way. OTOH, I don't think accessing metric values and especially array elements from the shell will become common, listing metrics is normally all you need on the shell. If you're working with specific metric values, you'll rather use Javascript. Regards, Michael Am 07.11.22 um 05:58 schrieb Michael Geddes:
Ah. Starting to see it.
So you are having the whole of vehicle.config as returning an associative array of config values? I guess that keeps that bit of it separate. makes sense even if a bit of work. Can we return an associative array to duktape?
When I introduce 'metric get' (which is just waiting some finessing of the Duktape code) it would be modified to allow indexes into arrays... so metric get v.s.seat.load[0] or metric get v.s.seat.load[FL]
and metric get vehicle.support[info.bat]
Is that the kind of idea? //.ichael
On Sun, 6 Nov 2022, 6:19 pm Michael Balzer, <dexter@expeedo.de> wrote:
The arrays would go along the scheme of the recent similar transition for the TPMS, with the names factored out into a common vehicle configuration:
* http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/2206...
Factoring out the configuration solves the need for metric value structures getting more complex than arrays. In this scheme, more properties can be added simply by additional array metrics (as was needed by the TPMS extension), and a runtime configuration change (e.g. when towing a trailer or reconfiguring a family van seat rows) is a simple array size change.
The "driver" could be the seat array index in this scheme, or -1 for "no driver".
There is an open todo regarding a general query scheme for vehicle configurations like these. This also applies to e.g. the battery pack layout, and also to the features / commands supported etc.. We formerly called these "capabilities" (in the OVMS V2 framework), but the capabilities data model was too limited for V3.
There was no real need to implement a V3 approach for this previously, but as we're now about to extend the metrics / vehicle configuration dependencies, this should maybe addressed now as well.
Initial thoughts on this:
In the V3 scheme, vehicle configurations & features could be seen & implemented as read-only configuration instances, i.e. reusing the existing naming & querying & API scheme for user configurations.
The user interface would be a read-only config parameter "vehicle.config" (or "vehicle.features" or "vehicle.support" for the functional coverage?) for standard configurations, likewise vehicle specific ones as "<vehicleprefix>.config" as needed.
Example:
// 5 seat car with a driver, a small child on the FR seat (airbag disabled) and another child on the RR: v.s.seat.load 67,12,0,0,32kg v.s.seat.belt 1,1,0,0,1 v.s.seat.airbag 1,2,1,0,1
// FL seat heating on level 2, RR level 1: v.e.seat.heating 2,0,0,0,1
// Driver is person on FL seat: v.e.driver 0
// Query vehicle configuration: OVMS# config list vehicle.config vehicle.config (readable) tpms.layout FL,FR,RL,RR seat.layout FL,FR,RL,RM,RR …
// Query vehicle feature support: OVMS# config list vehicle.support vehicle.support (readable) ctrl.chg mode,current,start,stop,limit,timer ctrl.env climate,doors,valet,homelink ctrl.sys wakeup info.bat soc,range,soh,energy,bms info.chg mode,current,state,duration,limit info.env temps,doors,tpms …
Comments?
Regards, Michael
Am 05.11.22 um 12:11 schrieb Michael Geddes:
I like the idea of the v.s.* namespace.
We could just have 'v.driver' = Left/Right/Auto - since really it's the Driver roll that is possibly the one that would be scripted on. I'm still not sure how you would then easily get at the 'driver-side-door' or 'driver-side-seatbelt' values.
How would you manage the arrays and make it easy to work with in extracting left/right/centre front/back etc? Associative array could work .. though that's not that different from the current *.fl *.fr etc.
//.ichael
On Sat, 5 Nov 2022 at 18:32, Michael Balzer <dexter@expeedo.de> wrote:
Michael,
I also had some thoughts on this, some first feedback from these on yours:
* I'd place seatbelt sensors in a new name space "v.s." for vehicle safety & security related metrics. That would also become the place for airbag & emergency braking sensors, traction control & emergency lights and the like. * I'd decouple the "driver" & "passenger" roles from the physical allocation, because this may become a property that can be changed on the fly even during driving, as soon as all vehicle controls are digital. * The "driver" metric may then also be assigned to a special value to represent autonomous driving modes. * I also think about arrays instead of fixed geometric layouts, as vehicles come in a variety of door & seat arrangements.
Regards, Michael
Am 05.11.22 um 11:07 schrieb Michael Geddes:
Hi all, I started this thought following up on my Ioniq 5 thread - but figured it might be worth a new conversation.
Michael B talked about having some new standard metrics (and also some consistent metric names in my i5 code: patch coming now that I understand a bit better why those exist).
The Door Locked series is obviously a good start - the candidate names being pretty straight forward imho. v.d.l.fl v.d.l.fr <http://v.d.l.fr> v.d.l.rl v.d.l.rr Most cars these days would have seatbelt sensors - so they might also be a candidate. v.sb.fl etc.
That being said, I have some issues related to 'right-hand-drive' vehicles which are quite popular in Australia ;). For a start, there's no metric for it; obviously some cars implementations will have a setting. For the Hyundai this is important as it seems many left/right settings are actually based on drive/passenger side in the OBD bits.
Sooo.. I was considering some of the issues:
1) When it's on a diagram or in a user message, we want left/right because that's how we want to deal with it. 2) In general scared scripts, we probably care more about whether it is drive/passenger side rather than left/right!
Could we have some metric alias's for left/right metrics that would be drive/passenger that would allow * Setting via either metric * Reading via either metric * Adding events based on either metric. For eg v.d.l.fl links to * v.d.l.fd (front driver) for Left-hand drive and * v.d.l.fp (front passenter) for Right-hand drive cars. I mean we could set both metrics.. but would that work?
Thoughts on this? //.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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ 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
participants (2)
-
Michael Balzer -
Michael Geddes