Relay: use relative time comparisons, runtime settings for flood window and delays

[mcspr]

New user configurable options:

• delay on and off times (relayDelayOnN, relayDelayOffN)
• interlock delay time (relayDelayInterlock)
• flood window time and countt (relayFloodTime, set to 0 will always trigger default case of setting fw_count = 1. relayFloodCount)

Try to use relative time instead of assuming timestamps are always sequential.
Flood window is managed exactly the same when switching without sync modes.
RELAY_SYNC_ONE and RELAY_SYNC_NONE_OR_ONE now delays the transition to ON for relayDelayInterlock time (ms) if any other relay is ON.

fix #1510 ? (interlock)
fix #1594 (flood window configuration)

[mcspr]

I don't know if this truly solves the interlocking, but this ensures the ordering but not direct dependencies. I also wonder how / why / where delay mechanics is used, since none of the presets have it set. A different solution could use a global delay setting a-la "relayInterlockTime" and apply the delay only when sync mode requires it. But then what to do with on / off delays?

A more complex sync mechanics, like specifying mask of other relays state / lock state ₁ that we want per each relay, could use of lock property. Fitting it here is a bit tricky since we already force the correct state via relaySync action, and disabling other relay state change is a bit silly for SYNC_ONE case, because we will indirectly turn the other one anyway doing either action. Perhaps a different UI element could help though, combining multiple switches into one. CLI / API still depend on low-level actions.
(₁ something like relayMask0 => 0b011 -> if relay0 is off set relay1 and relay2 to ON. or use ON / OFF in the key and just skip the current relay mask via the use of 0)

[mcspr]

@oscarsan1 I have added a single setting relayDelayInterlock with RELAY_DELAY_INTERLOCK token as default value. When appropriate sync modes are active, this delay is added to the relay that is changing to ON only when no other relay is ON at the same time, effectively postponing it's change after the other relay is OFF.

I guess we could have this per relay... but then we need to set it for both relays to work properly in the most common case.

[oscarsan1]

I test Sonoff T1 2 gangs with the Espurna 1.14.0 for control blinds. It works very well. I don't understand all the new code added, but the result is ok.
I've configure RELAY_DELAY_INTERLOCK with 500 ms, and when a relay is on and the other button is pressed, first turn off the delay, wait 500 ms and then turn on the new relay. This time is good for motor and blinds stops before start moving in the other direction, and more important never put both realys on when control blinds motors.
If none of the relays are on there are no delay in the reponse on button press.
For configure this in flags in platformio.ini add:
build_flags = .... -DRELAY_SYNC=RELAY_SYNC_NONE_OR_ONE -DRELAY_PULSE_MODE=RELAY_PULSE_OFF -DRELAY_DELAY_INTERLOCK=500
Then configure "Pulse time (s)" in the web with the time going up or down.
It will be usefull to configure RELAY_DELAY_INTERLOCK through web interface. And also to block the possibility of changing "Switch sync mode" accidentally in the web and burn the blinds motors turning both realys on.

[mcspr]

Thanks for testing!

I do agree I went a bit overboard with timers and I think I also introduced a bug with pulse mode where locks would never allow toggle to work... WIP on a bit different approach by using a different set of timers which should be part of 1.14.2
Web is missing both delays and interlock setting, but you can still use set relayDelayInterlock 500 in debug terminal.

Settings lock might work as a new settings key? Setting settingsLock => 1 (1 for ON, 0 for OFF) would lock any further settings modification. Only possible key to change would be the lock itself. So, if the system reads settings at boot and sees the key, we will not be able to change any setting. Only way to reset would be to use HTTP /config, which erases the flash and writes new config, or to manually use WebUI or terminal and set settingsLock 0 and reload

[oscarsan1]

Thanks to you for your great job!!
Yes, it works well with setting key as you mention.
I test it in hard conditions, multiple buttons pressed at a little time, flooded window, etc.. It works well and respects always the Delay Interlock. I haven't found the bug in my testing.