Closed kezarjg closed 2 months ago
Not sure I follow. The whole point of OVMS is that there is a consistent set of metric names that are used. There are some specific additional properties that are vehicle specific that have been created in some cases. Eg there's some Nissan Leaf specific behavior coded for based on peculiarities with that vehicle for when the standard metrics are updated in a power off and charging state.
I acknowledge the intention of OVMS to provide a consistent framework, there may be cases where certain vehicles have unique behaviors or properties that could benefit from specific metrics. These additional metrics could be implemented selectively for vehicles with particular characteristics, like the Nissan Leaf example you mentioned. This way, the standardized metrics can still serve as a baseline, while accommodating the specific needs of certain vehicles.
I believe this approach could enhance the flexibility and adaptability of OVMS without compromising its overall consistency. It would allow for a more comprehensive and accurate representation of vehicle data, catering to the diverse requirements of different vehicle models.
Currently the Nissan Leaf example is coded into without option to excluded that from other vehicles.
Currently the Nissan Leaf example is coded into without option to excluded that from other vehicles.
The Nissan Leaf elements are somewhat baked in. Removing those to a v.type
based section should be straightforward if there are other car types using this script that additionally need their own enriched behaviour. The current implementation should still function correctly for any vehicle that returns standard OVMS metrics that are used as the Nissan Leaf scoped metrics (prefixed with xnl.
) would be undefined in the metrics request so fall through to the standardized ones when being mapped for the ABRP payload.
I've started on a smaller abstraction that allows for all standard metrics to be used and then extended by any specific vehicle type behaviour. I'll move out the existing Nissan Leaf specific logic as part of that. Unlikely to have time around work commitments until the end of the week to push. I may push some earlier, potentially not necessarily working, code earlier.
I've started on a smaller abstraction that allows for all standard metrics to be used and then extended by any specific vehicle type behaviour. I'll move out the existing Nissan Leaf specific logic as part of that. Unlikely to have time around work commitments until the end of the week to push. I may push some earlier, potentially not necessarily working, code earlier.
Pull request #18 might be simliar to what you are describing. Please review and comment.
It seems like some vehicles have different sets of metrics available. Would it make sense to insert vehicle-specific metrics and mappings and use the 'v-type' metics to switch them out?