[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