[Ovmsdev] OTA Automatic updates (middle of the night)
Michael Balzer
dexter at expeedo.de
Mon Apr 30 15:47:27 HKT 2018
How about:
* init the SD unmounting on the ShuttingDown event, so there's plenty of time
* to avoid blocking the "system.shuttingdown" event for downstream listeners, fire a separate "sd.shuttingdown" event for this and do the synchronous
"sd.unmount.prep" in that event's listener
If the SD unmounting does not finish within 20 seconds, bad luck -- you probably have to do a hard shutdown anyway in that case.
Regards,
Michael
Am 30.04.2018 um 09:25 schrieb Mark Webb-Johnson:
> Not sure how we can do this, in a generic way, without a delay. Let’s look at the “ShutDown” event:
>
> * The “module reset” goes through the first part (ShuttingDown), then sends the ShutDown event. We can use a ‘done’ callback to know when that event has
> been delivered.
> * The SD CARD process picks up on ShutDown, and issues it’s own “sd.unmount.prep” event. It too can use a ‘done’ callback to know when that event has been
> delivered.
> * Now that the ShutDown event has been delivered, the ‘done’ callback for that is fired and “module reset” things everything is shutdown.
> * But, the “sd.unmount.prep” event has not been delivered yet, and the sd card has not been unmounted.
>
>
> This is different to the “sd unmount” case, where sending “sd.unmount.prep” and then doing the actual unmount on the callback is fine. Although, I am still
> unsure of how that will work in practice; as we really need to keep the command blocked until that unmount has run to completion.
>
> Ideas? Without making it overly complex?
>
> Regards, Mark
>
>> On 30 Apr 2018, at 3:13 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Sorry for not being clear, it's early over here. My point was:
>>
>> Unmounting the SD card should be a separate process, usable without doing a complete shutdown.
>>
>> Regarding a fixed delay, I would rather proceed to the actual unmount as soon as the "unmounting" event has been processed by all listeners, i.e. on the
>> event's done callback. Unmounting listeners just need to close their files, no need to introduce delays there.
>>
>> Regards,
>> Michael
>>
>>
>> Am 30.04.2018 um 08:41 schrieb Mark Webb-Johnson:
>>>
>>> That is why I was thinking of two signals:
>>>
>>> 1. “ShuttingDown”. This would be sent when the shutdown process was initiated. My suggestion is to then delay 20 seconds (to give peripherals time to
>>> cleanly shutdown) before proceeding to the next stage. The signal is intended to ask peripherals and systems to cleanly prepare for shutdown.
>>>
>>> 2. “ShutDown”. This would be sent 5 seconds before the actual shutdown. The signal is intended to ask peripherals and systems to prepare for shutdown now.
>>>
>>>
>>> I will implement the basics of this tonight.
>>>
>>> Regards, Mark.
>>>
>>>> On 30 Apr 2018, at 2:32 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>> Yes, a general shutdown signal scheme makes sense, but still also a separate SD unmounting signal to be able to remove just the SD card with a single command.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 30.04.2018 um 04:28 schrieb Mark Webb-Johnson:
>>>>> Writing the code last night, it seemed that the shutting down of wifi/simcom/etc was messy.
>>>>>
>>>>> Perhaps we need to have new signals “ShuttingDown” and “ShutDown”, then make the components responsible for this? So, for example, wifi powers off, server
>>>>> v2 disconnects, logging stops logging to SD, etc, on “ShuttingDown”. Then SD unmounts on “ShutDown”.
>>>>>
>>>>> A better solution?
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>>> On 30 Apr 2018, at 6:31 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>>
>>>>>> Attention: performing an AutoFlash just killed my SD filesystem.
>>>>>>
>>>>>> Possibly just by chance and I was lucky all the reboots before, but I think we really need to close all SD files before reboot -- see issue #97.
>>>>>>
>>>>>> FYI: the SD could be restored by a simple fsck, no data loss. My Linux system also could mount the SD before the fsck. The module was stuck in the mount
>>>>>> attempt.
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Am 29.04.2018 um 16:39 schrieb Mark Webb-Johnson:
>>>>>>>
>>>>>>> The last piece of the puzzle falls into place.
>>>>>>>
>>>>>>> OVMS# config set auto ota yes
>>>>>>>
>>>>>>> OVMS# config set ota auto.hour 2
>>>>>>>
>>>>>>>
>>>>>>> Module will wake up sometime between 2am and 3am, and if wifi is available it will check the available server version (according to OTA tag and server
>>>>>>> url). If the server has a later version, the module will download and flash that new version then reboot into it.
>>>>>>>
>>>>>>> I’ve also brought in the strverscmp function for GNU library, which is generally useful for comparing versions.
>>>>>>>
>>>>>>> Enjoy.
>>>>>>>
>>>>>>> Regards, Mark.
>>>>>>>
>>>>>>>> Begin forwarded message:
>>>>>>>>
>>>>>>>> *From: *GitHub <noreply at github.com <mailto:noreply at github.com>>
>>>>>>>> *Subject: **[openvehicles/Open-Vehicle-Monitoring-System-3] 1a4301: Bring in GNU strverscmp component, and test comman...*
>>>>>>>> *Date: *29 April 2018 at 10:23:54 PM HKT
>>>>>>>> *To: *mark at webb-johnson.net <mailto:mark at webb-johnson.net>
>>>>>>>> *Reply-To: *GitHub <noreply at github.com <mailto:noreply at github.com>>
>>>>>>>>
>>>>>>>> Branch: refs/heads/master
>>>>>>>> Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3
>>>>>>>> Commit: 1a4301d7ca1c7ed619109dfcb2e832a599af7dda
>>>>>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/1a4301d7ca1c7ed619109dfcb2e832a599af7dda
>>>>>>>> Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>>>>>> Date: 2018-04-29 (Sun, 29 Apr 2018)
>>>>>>>>
>>>>>>>> Changed paths:
>>>>>>>> A vehicle/OVMS.V3/components/strverscmp/component.mk
>>>>>>>> A vehicle/OVMS.V3/components/strverscmp/src/strverscmp.c
>>>>>>>> A vehicle/OVMS.V3/components/strverscmp/src/strverscmp.h
>>>>>>>> M vehicle/OVMS.V3/main/test_framework.cpp
>>>>>>>>
>>>>>>>> Log Message:
>>>>>>>> -----------
>>>>>>>> Bring in GNU strverscmp component, and test command
>>>>>>>>
>>>>>>>>
>>>>>>>> Commit: 58fa1b57448d3491889e3d1d3f487e475d036c92
>>>>>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/58fa1b57448d3491889e3d1d3f487e475d036c92
>>>>>>>> Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>>>>>> Date: 2018-04-29 (Sun, 29 Apr 2018)
>>>>>>>>
>>>>>>>> Changed paths:
>>>>>>>> M vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp
>>>>>>>> M vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.h
>>>>>>>>
>>>>>>>> Log Message:
>>>>>>>> -----------
>>>>>>>> AutoFlash implementation:
>>>>>>>> Config auto[ota]=yes
>>>>>>>> Config ota[auto.hour]=2
>>>>>>>>
>>>>>>>>
>>>>>>>> Compare: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/87d80c30825b...58fa1b57448d
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>> _______________________________________________
>>>>>> 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
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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/20180430/d68735a8/attachment-0001.html>
More information about the OvmsDev
mailing list