How to retain states after reboot

[lblokland]

Operating environment/Installation (Hass.io/Docker/pip/etc.):

Home Assistant, Hass.io and ESPHome with Sonoff
ESP (ESP32/ESP8266, Board/Sonoff):

Using a Sonoff 4Ch pro r2, basic config
Affected component:

https://esphome.io/devices/sonoff_4ch.html

Description of problem:

When the Sonoff has been rebooted in HA the device (and switches etc) become unavailbe until it gets back online.
When it gets back online, all states are returned to default (relays off, blue led off).
during the downtime the states become 'unavailable' so i think that's were it fails.
Would it be possible to keep the states until the device gets back online, and then update the states if the uptime of the device is more then - lets say - 5 minutes from the device (maybe some interaction was done on the device.
If the uptime is less then those 5 minutes keep the states.

on the other hand, when the device boots it should look at the states and use them to set the pins etc after a reboot.

Problem-relevant YAML-configuration entries:

PASTE YAML FILE HERE

esphome:
  name: sonoff_4pro_1
  platform: ESP8266
  board: esp01_1m
  
web_server:
  port: 80

wifi:
  ssid: "10"
  password: ""
  manual_ip:
    static_ip: 192.168.178.17
    gateway: 192.168.178.1
    subnet: 255.255.255.0
    dns1: 192.168.178.1
    
binary_sensor:
  - platform: gpio
    pin:
      number: GPIO0
      mode: INPUT_PULLUP
      inverted: True
    name: "Sonoff 4pro1 Button 1"
    on_press:
      then:
        - switch.toggle: sonoff4pro1r1
  - platform: gpio
    pin:
      number: GPIO9
      mode: INPUT_PULLUP
      inverted: True
    name: "Sonoff 4pro1 Button 2"
  - platform: gpio
    pin:
      number: GPIO10
      mode: INPUT_PULLUP
      inverted: True
    name: "Sonoff 4pro1 Button 3"
  - platform: gpio
    pin:
      number: GPIO14
      mode: INPUT_PULLUP
      inverted: True
    name: "Sonoff 4pro1 Button 4"
  - platform: status
    name: "Sonoff 4pro1 Status"

switch:
  - platform: gpio
    name: "Sonoff 4pro1 Relay 1"
    pin: GPIO12
    id: sonoff4pro1r1
  - platform: gpio
    name: "Sonoff 4pro1 Relay 2"
    pin: GPIO5
  - platform: gpio
    name: "Sonoff 4pro1 Relay 3"
    pin: GPIO4
  - platform: gpio
    name: "Sonoff 4pro1 Relay 4"
    pin: GPIO15

output:
  # Register the blue LED as a dimmable output ....
  - platform: esp8266_pwm
    id: blue_led
    pin: GPIO13
    inverted: True

light:
  # ... and then make a light out of it.
  - platform: monochromatic
    name: "Sonoff 4pro1 Blue LED"
    output: blue_led

debug:
# Enable logging
logger:
  level: debug


# Enable Home Assistant API
api:
  password: ''

ota:
  password: ''

Traceback (if applicable):

Additional information and things you've tried:

[glmnet]

You are using GPIO switches.
Read the docs here https://esphome.io/components/esphome.html#esphome-esp8266-restore-from-flash
and here https://esphome.io/components/switch/gpio.html (restore_mode) to see if you can make this behavior fit your needs.
Make a more specific question otherwise.

[lblokland]

Hi Guillermo, Thanks! I was looking into that as well but what I’m wondering might just be a nice addition to the already long list of possibilities. As I’m not much of a programmer all I can do is give a suggestion. I’ll try to explain what I mean. In my example I’ve created an automation in the Sonoff so that when I press the button, the relay switches on and when I press the button again it switches off. Using ESPHome integration Home Assistant communicates just fine with the sonoff. However in the event of downtime with the Home Assistant or the Sonoff I tihink it would be nice to have some extra logic using the states on both ends. Example 1: When the HA is down, for maintenance, network issues or whatever reason we can still switch the relay with the automation in the Sonof. So, there is a real possibility that the state of the relay changes during the HA downtime. When the HA gets back up it would be nice to first take a look at the Sonoff and asks the state of the relay, and adjusts (if needed) the state of the relay in HA to match the state in the Sonoff. That way there is no change in the relay when starting Home Assistant after a power down. Example 2: When the Sonoff is down for whatever reason it should look at the current state for that relay in the Home Assistant when powering up. That should be the last known setting, or maybe another state if some event in Home Assistant has occurred to switch the relay. Maybe combined with some logics with time to see when the last switch has occurred. Hope it’s a nice addition for the programmers. This way you can use the Sonoff standalone and with the Home Automation (Assistant) in the best way possible I think. Would this explanation help? Cheers, Leon

…

________________________________ Van: Guillermo Ruffino <notifications@github.com> Verzonden: Wednesday, April 17, 2019 2:30:39 PM Aan: esphome/issues CC: lblokland; Author Onderwerp: Re: [esphome/issues] How to retain states after reboot (#240) You are using GPIO switches. Read the docs here https://esphome.io/components/esphome.html#esphome-esp8266-restore-from-flash and here https://esphome.io/components/switch/gpio.html (restore_mode) to see if you can make this behavior feet your needs. Make a more specific question otherwise. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#240 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AulFMLp5fk8b_GFfQeUexuqKwfcJju6Iks5vhxPvgaJpZM4czsal>.

[glmnet]

I believe Example 1 is exactly as it works out of the box, please advice otherwise.
At least when using the native api:. I cannot tell if using mqtt will behave differently.

Example 2 is a lot more complicated:
May be someone with more background than me can explain better why it works this way, however it does a good job telling you something is not ok.
For sure your particular requirement can be done with some automation working on ha or esphome, or together.
No solution seems trivial to me though.
One thing I implemented, but not with esphome specifically was about setting a relay on, but while comm is ok, if the comm is lost relay switches off. To do that I create a template switch on ha, then in the device you poll the ha switch state every few seconds and then set the relay state according to feedback.
I know none of this is what you need, but if you need something to be included it will have to be an issue that benefits many people.

What I see you want is a 'last intent win' scenario, so you could do this yourself with custom automation, I doubt something like this would be implemented anytime soon.

perhaps some configuration like restore_mode: api and another one with keep_ha_switch_enabled would do the trick magically, and a bit unpredictably too 😄

[lblokland]

Hi Guillermo, That is exacly what I want, how do we get that on the whislist? (example 1 works, didn’t even try that first, my bad) Cheers, Leon Van: Guillermo Ruffino<mailto:notifications@github.com> Verzonden: woensdag 17 april 2019 23:11 Aan: esphome/issues<mailto:issues@noreply.github.com> CC: lblokland<mailto:modernmovement@hotmail.com>; Author<mailto:author@noreply.github.com> Onderwerp: Re: [esphome/issues] How to retain states after reboot (#240) I believe Example 1 is exactly as it works out of the box, please advice otherwise. At least when using the native api:. I cannot tell if using mqtt will behave differently. Example 2 is a lot more complicated: May be someone with more background than me can explain better why it works this way, however it does a good job telling you something is not ok. For sure your particular requirement can be done with some automation working on ha or esphome, or together. No solution seems trivial to me though. One thing I implemented, but not with esphome specifically was about setting a relay on, but while comm is ok, if the comm is lost relay switches off. To do that I create a template switch on ha, then in the device you poll the ha switch state every few seconds and then set the relay state according to feedback. I know none of this is what you need, but if you need something to be included it will have to be an issue that benefits many people. What I see you want is a 'last intent win' scenario, so you could do this yourself with custom automation, I doubt something like this would be implemented anytime soon. perhaps some configuration like restore_mode: api and another one with keep_ha_switch_enabled would do the trick magically, and a bit unpredictably too 😄 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#240 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ALUUKMHCWJKAHFSUUDMZGSDPQ6HBLANCNFSM4HGOY2SQ>.

[OttoWinter]

No, any such solution would be incredibly complicated and error-prone. There are just so many edge cases, like what happens when there's an automation on the ESP that triggers an update. And how should they know what state came first? The ESP doesn't have a reliable clock source that is held up with batteries when power goes down like most computers do.

See other discussions here about restoring state from MQTT - it just gets too complicated. Any such state restoration should be done with HA/esphome automations (that's definitely possible to do, just a bit of work).