[Ovmsdev] Double updates - Normal?

Thu Jan 30 20:00:11 HKT 2020

Some time the m.version not set on Mitsubishi i-Miev .

2020. január 30., csütörtök dátummal Thomas Heuer <egon at heuer-humfeld.de>
ezt írta:

> The issue was on boot, the events: SignalEvent: queue overflow, event
> 'system.start' dropped in some case.
>
>
>
> the problem was the egpio settings in OvmsVehicleSmartED::ConfigChanged(OvmsConfigParam*
> param)
>
>
>
> https://github.com/Dimitrie78/Open-Vehicle-Monitoring-System-3/commit/
> 21e1a0339c029adf5c746dfd6fecddbc9455a947#diff-
> 9106f33dff1f6160884b2e78d145607fL155-L160
>
> line 155 – 160
>
>
>
> *Von:* OvmsDev <ovmsdev-bounces at lists.openvehicles.com> *Im Auftrag von *Mark
> Webb-Johnson
> *Gesendet:* Donnerstag, 30. Januar 2020 11:35
> *An:* OVMS Developers <ovmsdev at lists.openvehicles.com>
> *Betreff:* Re: [Ovmsdev] Double updates - Normal?
>
>
>
> Just had a thought.
>
>
>
> Events used to be synchronous, but we switched to deliver in a different
> task. Maybe the startup sequence relies on that in some way.
>
>
>
> On 30 Jan 2020, at 6:32 PM, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
> 
>
> Seems identical. The changes don’t seem to affect the dispatch of the
> system.start event.
>
>
>
> I think it must be a race condition.
>
>
>
> Mark
>
>
>
> On 30 Jan 2020, at 5:56 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> 
>
> 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>
> 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> 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> 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
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> 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
> 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 <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> 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
>
>

-- 
Üdvözlettel:
Kovács Tamás
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200130/0a529507/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4190387F-2092-4C58-954F-315D5860AE57.png
Type: image/png
Size: 384261 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200130/0a529507/attachment-0002.png>