[Ovmsdev] chatty v2 server comms

Mark Webb-Johnson mark at webb-johnson.net
Sun Dec 17 19:28:29 HKT 2017


Thanks!

I have found v3 to be exceptionally easy to debug and test these things. Having the metrics so easy to change and simulate different events is really cool. Looking forward to being able to expose those metrics directly via MQTT and GATT.

Regards, Mark

> On 17 Dec 2017, at 7:16 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> That makes sense, I'll change the listener accordingly…
> 
> 
>> Am 17.12.2017 um 11:56 schrieb Mark Webb-Johnson:
>> The “design” of the v2 peers check for environment is to send an environment message immediately the environment changes (when one or more apps are connected).
>> 
>> It is meant to display a door opening, on a connected App, immediately the door opens, rather than having to wait a minute.
>> 
>> But, it should only do the actual transmission if something in the environment -actually- changes. Perhaps that is the issue?
>> 
>> I’m travelling for the next 24 hours, so won’t be able to check. Does the above “clue” help any?
>> 
>> Regards, Mark
>> 
>>> On 17 Dec 2017, at 6:42 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>> 
>>> Tom,
>>> 
>>>>> Am 17.12.2017 um 11:00 schrieb Tom Parker:
>>>>> On 10/12/17 00:31, Michael Balzer wrote:
>>>>> I fixed a minor bug in the v2 server code that caused much more data updates to be sent than necessary, can you please check if your data usage drops with
>>>>> that fix?
>>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/ca6f4200d6f40ab2e11e5cb6f2b7ec9d1ab33097
>>>> I don't think changing from boolean to bitwise "or" would make a difference? I'm seeing a lot of messages, multiple per second, see below.
>>> A logic or ("||") only gets evaluated up to the first "true", so it makes a difference if the function called does a modification -- IsModifiedAndClear() clears
>>> the modifier bit.
>>> 
>>>> I think the problems are in components/ovms_server_v2/src/ovms_server_v2.cpp. In OvmsServerV2::ServerTask, the m_now_stat and similar logic will always be
>>>> true in a real car. At a minimum we have 4 significant figures on the 12v measurement, and the park timer will count up every second.
>>>> 
>>>> I changed the logic to only check once per minute and it's a lot less chatty, but this is probably not the right solution:
>>> I agree, that doesn't look right…
>>> 
>>> OK, I found it: the frequent "D" updates are caused by the V2 server metrics listener setting m_now_environment to true on any (!) metrics change when peers are
>>> connected.
>>> 
>>> I think these lines can just be removed from the listener:
>>> 
>>> if (StandardMetrics.ms_s_v2_peers->AsInt() > 0)
>>>   m_now_environment = true; // Transmit environment message if necessary
>>> 
>>> …as it checks for immediate update triggers (charge state etc.) before, and the main loop logic takes care of per minute update frequency when peers are connected.
>>> 
>>> Can you verify that?
>>> 
>>> A higher update frequency will only be needed for the location streaming mode (todo).
>>> 
>>> Regards,
>>> Michael
>>> 
>>> -- 
>>> 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
>>> 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
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



More information about the OvmsDev mailing list