[Ovmsdev] Double updates - Normal?

Thu Jan 30 17:54:51 HKT 2020

Mark,

a similar issue was happening on some Smart ED and fixed by Dimitrie later on:

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/293

I thought that was a Smart specific issue, maybe I was wrong.

Regards,
Michael

Am 30.01.20 um 06:17 schrieb Mark Webb-Johnson:
> Still stumped…
>
> The OTA code doesn’t call GetOVMSVersion(), but instead just looks at StandardMetrics.ms_m_version (which we know is blank). That is why this
> is happening.
>
> But why is StandardMetrics.ms_m_version empty (as is the hardware value as well).
>
> The ovms_version code hooks into ’system.start’ event, and sets the version and hardware metrics. So, obviously that is not being called. That
> event is raised just after ’Starting USB console…”. The event is also listened to be ovms_time, ovms_mdns, and swcan.
>
> MDNS outputs “Starting MDNS” when it sees that. The ovms_time sets the environment variable TZ. Your car is showing:
>
>     ovms> time status
>     ...
>     Vehicle Response:
>       Time Zone:  Not defined
>       UTC Time:   2020-01-30 05:00:53 UTC
>       Local Time: 2020-01-30 05:00:53 GMT
>       Provider:   None
>
>
> So looks like TZ is not being set. Presumably that means the call is not happening. I had a look at the ovms_events code, but can’t find
> anything obvious.
>
> So, tried a hacky test:
>
>     ovms> metric list version
>     ...
>     Vehicle Response:
>       m.version
>
>     ovms> event raise system.start
>     ...
>     Vehicle Response:
>       Raising event: system.start
>
>     ovms> metric list version
>     ...
>     Vehicle Response:
>       m.version                                3.2.008-121-g4c6c9fe/ota_0/edge (build idf v3.3-beta3-775-gdc1ca69 Jan 29 2020 00:00:52)
>
>     ovms> ota status
>     ...
>     Vehicle Response:
>       Firmware:          3.2.008-121-g4c6c9fe/ota_0/edge (build idf v3.3-beta3-775-gdc1ca69 Jan 29 2020 00:00:52)
>       Running partition: ota_0
>       Boot partition:    ota_0
>       Factory image:     3.1.001
>       OTA_O image:       3.2.008-121-g4c6c9fe
>       OTA_1 image:       3.2.008-121-g4c6c9fe
>       Server Available:  3.2.008-121-g4c6c9fe (no update required)
>
>
> 🤢
>
> Can you try to boot from USB (module reset) and provide the serial boot log? Particularly around the lines ’Starting USB console’.
>
> Maybe a race condition at startup, or some other issue delivering events early on?
>
> Only other thing I see are some scripts on /store/events regarding vehicle on/off - perhaps you can try disabling those to see if they trigger
> the issue? I tried recreating them on my box, but couldn’t repeat your problem.
>
> Regards, Mark.
>
>> On 30 Jan 2020, at 11:55 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>
>> Greg,
>>
>> It seems your car can’t pickup currently running firmware version:
>>
>>     ovms> open ROADSTER834B
>>     Connected and logged in to ROADSTER834B
>>     ovms> metric list version
>>     ...
>>     Vehicle Response:
>>       m.version
>>
>>
>> By comparison, here’s mine:
>>
>>     ovms> metric list version
>>     ...
>>     Vehicle Response:
>>       m.version                                3.2.008-121-g4c6c9fe/ota_1/edge (build idf v3.3-beta3-775-gdc1ca69 Jan 29 2020 00:00:52)
>>     ovms> ota status
>>     ...
>>     Vehicle Response:
>>       Firmware:          3.2.008-121-g4c6c9fe/ota_1/edge (build idf v3.3-beta3-775-gdc1ca69 Jan 29 2020 00:00:52)
>>       Running partition: ota_1
>>       Boot partition:    ota_1
>>       Factory image:     3.2.002
>>       OTA_O image:       3.2.008-120-gcfb7864
>>       OTA_1 image:       3.2.008-121-g4c6c9fe
>>
>>
>> Your m.hardware metric is also blank.
>>
>> I’ll keep looking, but at the moment this seems bizarre.
>>
>> Regards, Mark.
>>
>>> On 30 Jan 2020, at 11:21 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>>
>>> Hi Mark, Michael,
>>>
>>> Seems like what is happening is that the module keeps thinking a new
>>> update is available.  Today was especially active for some reason.
>>> Screenshot of the Android application's log screen, attached.  All
>>> versions appear to be the same.  The car has simply been sitting in the
>>> garage on WiFi; no transitions of network access.
>>>
>>> Output of 'ota status' attached as well.
>>>
>>> Sorry, but I don't appear to have logging enabled. What specifically
>>> would you like logged?
>>>
>>> Greg
>>>
>>>
>>> Mark Webb-Johnson wrote:
>>>> Not normal. Can you send us the logs. Also the output of ‘ota status’ would be helpful.
>>>>
>>>> Are you sure this isn't just a notification of the update, and is the update itself? Perhaps a screenshot of the double notifications you
>>>> receive?
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 25 Jan 2020, at 11:35 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>>>>
>>>>> Hi folks,
>>>>>
>>>>> I moved my car's OVMSv3 to the Edge firmware a bit ago, and notice that
>>>>> every update seems to be doubled.  Besides being a bit annoying, it ends
>>>>> up without a previous version to fall back to since both partitions end
>>>>> up being the same.
>>>>>
>>>>> Is this behavior normal?  Can it be prevented?
>>>>>
>>>>> I'm only on Edge because of the bug in obd2ecu, and will probably move
>>>>> to EAP after we get an EAP build with the fix in it.  Is the behavior
>>>>> the same there?
>>>>>
>>>>> I used to be on Main, and all seemed fine there.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Greg
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> <Repeated updates.png><Repeated updates ota status output.txt>_______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/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/20200130/883f2143/attachment.htm>