Added restore last schedule support

[foxman69]

I have added an option to restore the last schedule state on the device boot.

This option is useful in case of power loss or any kind of device reset that you still want your schedules to continue as usual.

At the moment if the device had a "down time" while a scheduled action should have happen, your action wont get applied, with this new feature the device will check for the closest schedule action that should have happened before boot, and restore its state to the desired schedule action state.

I have also added an option in the "SWITCHES" menu to choose on which relay you would like this feature to run on.

Disclaimer: it only counts "Turn ON" and "Turn OFF" actions and ignores toggle actions

[mcspr]

Can you explain a bit the algorithm for finding the missed schedule? How far does it go is hard-coded?
There could also be a small issue when dst is happening, causing utc timestamp to be invalid in that instance

[foxman69]

Basically what it does, is enumerating the schedules, checking the different options of them (enabled or not, UTC or not) and for each schedule check if it supposes to happen in the current day.
If so, check the minutes left to the schedule from current time (_schMinutesLeft) and if its less then 0 and bigger than the last value i saved (minimum_restore_time), then i update the saved value and the saved action. (I call this function recursively to check for the missing schedule in the days before, in case i didn't found a schedule for the specific relay at the current day).
At the end of the enumeration, it supposes to have the missing schedule's action saved in the saved_action variable.
The function supposed to be called for maximum 7 times (checking each day of the week).

About the DST, it could be problematic but i`m not sure what is the proper solution for that. (It also affects the current scheduling algorithm if there is a schedule between 1:00-2:00 or 2:00-3:00 when DST is happening).

[mcspr]

Ah, thank you for that. I missed the part where it moves the timestamp back.

Maybe instead of using part of schCheck it should be inside of schCheck itself via bool param / look_back=N-days param + timestamps as params? Since lights are also handled that way and it is not dependant on relays

Following that idea, would it make sense to have things per-schedule instead of per-relay and have schLookBack<ID> <N-days-to-look-back> / schLookBack<ID> 0/1 to force initial schCheck to do the backwards search? I am not sure about adding things specific to the scheduler into relay struct & switches tab.
edit: typo

[foxman69]

I have merged the RestoreLastScheduleState function into the _schCheck function

I think its makes more sense to have things per-relay and not per-schedule as you mentioned...

[foxman69]

Thank you for your code changes and popping the issue about the light provider.
I have tested the new code on my Sonoff CH4 PRO, the changes caused a few issues but i fixed them in my last commits and now everything seems to work great.
About the light provider issue (with sch_action != 2) I don't have such device to check it with, but i have added another check to the switch type before calling the _schAction and now it should work on that too, if you have such device please check it...

[mcspr]

Lights work, thanks! See naming comments.

[mcspr]

I was also thinking about boot modes and about how this could be a separate setting for boot mode, since we already depend on relay id for doing things?
For example, replacing the relayLastSch setting with a new relayBoot type, similar to the current ones ON, OFF, TOGGLE, LOCK ON, LOCK OFF and finally this one.
Or would it be more complicated that way?

[foxman69]

I have changed all the variables naming like you said.
About the boot mode, I have thought about it even before (during this feature implementation), in my opinion these two features are orthogonal and needs to be separate in order to give the users more possibilities of configuring their device, with these 2 features separately the user have more control of what he wants to do with each relay during boot than just give them one option at a time.

[mcspr]

Note that this should probably be p- -> pure-, gulp will shorten it afterwards.
Opening things locally breaks styling.

Since everything else is done, I'd rebuild the webui files and add them here + this fix.