[Ovmsdev] OTA Automatic updates (middle of the night)
Mark Webb-Johnson
mark at webb-johnson.net
Mon Apr 30 15:25:53 HKT 2018
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> 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:
>>
>> “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.
>>
>> “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 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3>
>>>>>>> Commit: 1a4301d7ca1c7ed619109dfcb2e832a599af7dda
>>>>>>> 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 <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 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/87d80c30825b...58fa1b57448d>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <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 <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 <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 <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
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180430/8e4caf08/attachment.htm>
More information about the OvmsDev
mailing list