I've added support for the level metrics to the Twizy. Regarding the array metrics, that would be a nice way to avoid the memory overhead. It will add some transmission overhead though, as the array can only be updated as a whole. They may also need some sort of transaction control, to avoid inconsistent / premature updates if values are updated in chunks (as by a series of OBD2 requests to query them). Regards, Michael Am 29.05.2018 um 03:21 schrieb Mark Webb-Johnson:
A better scheme would be to supply these as general / abstract "levels", i.e.
v.b.c.level.min v.b.c.level.max
So this can be either an SOC or an SOH or a normalized voltage or resistance level, whatever is appropriate and available for a vehicle. It just needs to be in the range 0-100%, so min and max can be put in relation. And we also should add…
v.b.c.level.avg v.b.c.level.stddev
I think that would work better than "soc". Comments?
OK. Done. Committed and pushed.
That also leaves the namespace v.b.c.* for whatever we do with individual cell voltages and temperatures. My preference for that seems to be an OvmsMetricArrayFloat type (the AsString result of which could be a comma-separated list, but we can provide individual value set/get functions for OVMS code). Roadster has 99 cells, and I really don’t want to create 198 metrics for this. What do you think?
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26