DIY Automate Existing Light Switch: ESPHome on a Sonoff Basic in the gang box!

@OttoWinter: I’ve run into an issue that I thought I was cleverly avoiding. I assumed that if using reboot_timeout: 0s in the config that if the device failed to connect to wifi or api, it would continue functioning as normal.

What I’ve discovered in a power outage is my access points take longer to boot than the ESP, and the ESP can’t connect. Rather than still behave like a functional switch, it doesn’t seem to do anything at all unless it is power cycled (which for me involves cycling some breakers, bummer)

Is there a way to tell the platform “if you can’t connect, don’t bother trying and jump into the main loop”? That allows me to perform a manual reboot using the trick outlined above to get it to connect to wifi.

will adding ap: as a fallback prevent that?

You could make yourself a custom on-multi-click to initiate a reboot (for example 3 or 5 times in a row fast switching to force a reboot of your esp)

Yes, that’s exactly what i’m doing already, the issue is if there is a power failure, the ESP never connects to the access point, and then must be stuck in some kind of loop because the normal switching activity does nothing (not even activate a relay). Hoping to get that functionality somehow even if wifi fails to connect, and then my multi click reboot will work and the switch will still function even if my network goes down

My sonoff touch physical button is working. I can switch on and off whenever I want. The only thing driving us crazy is ghost switching. I read almost all the above posts but don’t know which part solves my problem. Any ideas?

from the link posted above
"Last summer I made a video about the quirks of the GPIO pins on the ESP8266, and as you can see, GPIO2 has two problems: First, the pin goes high during the boot process, so if you have a device that turns on/off when voltage is applied, it will kick on for about 400 milliseconds when your sonoff reboots. Second, you can see that if that pin is pulled low on boot (meaning it is attached to ground), the ESP8266 will go into one of it’s alternate boot modes, which won’t run the main program on your sonoff, and will therefore result in a non-working device.
I wonder if the problem is not the code, but rather the pin you used. also from further up in the thread, RX pin works as well, and might be a solution to your problem.

I have a configuration that changes a light colour depending on rf code received. It calls a HA service directly to control the light:

  - platform: remote_receiver
    id: remote_sw_II_1_on
    rc_switch_raw:
      protocol: 2
      code: "1000010110010"
    filters:
      - delayed_off: 100ms
    on_press:
      - homeassistant.service:
          service: light.turn_on
          data:
            entity_id: light.light1
            color_name: magenta
            brightness: 128
  - platform: remote_receiver
    id: remote_sw_II_1_off
    rc_switch_raw:
      protocol: 2
      code: "1000110110010"
    filters:
      - delayed_off: 100ms
    on_press:
      - homeassistant.service:
          service: light.turn_off
          data:
            entity_id: light.light1

Hope that helps

I don’t know how I missed your post, but i realized this was exactly the problem. Every time i had a power outage, the devices that didn’t come back up (i’ve used this code in four different locations now) had the physical switch on, (ie… IO2 to GND!) so the ESP was going into the flash programming mode! I am going to switch to the RX pin in future revisions and see if the problem goes away completely.