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@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@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@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@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@webb-johnson.net

Reply-To: GitHub <noreply@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@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@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@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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev