[Ovmsdev] v2 android clients crashes while v3 is charging
Michael Balzer
dexter at expeedo.de
Wed Nov 8 06:40:22 HKT 2017
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 at expeedo.de <mailto:dexter at 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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171107/9f59759c/attachment.htm>
More information about the OvmsDev
mailing list