Translations extended & fixed: _states_: case 1: code = "charging"; break; case 2: code = "topoff"; break; case 4: code = "done"; break; case 13: code = "prepare"; break; case 14: code = "timerwait"; break; case 15: code = "heating"; break; case 21: code = "stopped"; break; default: code = ""; _substates_: case 0x01: code = "scheduledstop"; break; case 0x02: code = "scheduledstart"; break; case 0x03: code = "onrequest"; break; case 0x05: code = "timerwait"; break; case 0x07: code = "powerwait"; break; case 0x0d: code = "stopped"; break; case 0x0e: code = "interrupted"; break; default: code = ""; Regards, Michael Am 07.11.2017 um 02:57 schrieb Mark Webb-Johnson:
Probably best to double-check in the iOS and Android Apps for what they use.
For iOS, all I see is a check for chargesubstate == 0x07. Same for Android.
I think it is ok just to use those substates for the moment. Long-term, we don’t really want/need this substate metric anyway.
Regards, Mark.
On 7 Nov 2017, at 6:01 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I've just pushed a rework of the v2 stat message including some more metrics and automatic code/key translations for charge state & mode.
It works well on my test vehicle. The translation utilities can also be used to set the code metrics if you stick to the integer keys internally.
Still missing is the substate. From the v2 code it can have these values:
- 0 = undefined - 1 = charge stop request - 3 = charging by request - 7 = cable not connected - 14 = charge interrupted
That's a bit mixed scope… are these all substates to support?
Regards, Michael
Am 06.11.2017 um 18:37 schrieb Michael Balzer:
I also sent another pull request for a minimal implementation of the charger state related values in the v2 protocol, and some small leaf fixes. This pull request ( https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7 ) is still outstanding I think deriving the car_chargestate string from the charge flags is not correct. We've currently got…
OvmsMetricString* ms_v_charge_state; // charging, topoff, done, preparing, heating, stopped OvmsMetricString* ms_v_charge_mode; // standard, range, performance, storage OvmsMetricString* ms_v_charge_substate; // tba...
…but no longer their numerical equivalences as metrics -- assuming they are no longer necessary. Are they? I.e. do we need the numerical values other than for the old V2 protocol?
I'd else translate the old codes to their old numerical values just for the "S" msg.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26