Sonoff S31 Outlet running ESPHome - Any way to prevent relay cycling (on>off>on) after firmware upload?

ESPHome
1

Every time I upload a new firmware to my s31 outlets that are on, the relay goes from on to off and back to on super fast. In my tests, it appears that this only happens if the relay is on. If off, then the upload finishes and unless the default restore setting tells it to turn on, it just stays off.

Is there any way to prevent the toggle if the relay was in the same state the restore mode tells it to be? In other words, if the outlet powering my PC is set to be ALWAYS_ON (see example below), is there a way to prevent it from turning off right after a firmware upload, and then back on? My PC is on a UPS so no harm done, but it is very annoying on other devices around the house. It also limits what devices I use this on, or when I can do my updates.

Is there any hw or sw way to prevent this?

  restore_mode_setting: ALWAYS_ON
  #restore_mode: Control how the relay attempts to restore state on bootup.
  #RESTORE_DEFAULT_OFF          - Attempt to restore state and default to OFF if not possible to restore.
  #RESTORE_DEFAULT_ON           - Attempt to restore state and default to ON if not possible to restore.
  #RESTORE_INVERTED_DEFAULT_OFF - Attempt to restore state inverted from the previous state and default to OFF.
  #RESTORE_INVERTED_DEFAULT_ON  - Attempt to restore state inverted from the previous state and default to ON.
  #ALWAYS_OFF                   - Always initialize the pin as OFF on bootup.
  #ALWAYS_ON                    - Always initialize the pin as ON on bootup.

  switch:
    - platform: gpio
      name: "${friendly_devicename}"
      icon: "mdi:power-socket-us"
      pin: GPIO12
      id: relay
      restore_mode: ${restore_mode_setting}
1 Like
2

I’m experiencing the same ‘blip’ on the relay during reboot, but so far it hasn’t been of a duration that has mattered to any of the things plugged-into the Sonoff.

However, I have also incorporated this into my YAML, and have never used the ‘official’ way which you are using. It may be that the ‘restore_mode’ action occurs far later in the bootup process than the below code, causing you a larger ‘blip’ in power than I’m seeing.
One would presume that the ‘official’ method would be more effective, and perhaps the below is redundant and not better than restore_mode.

So, I offer this bit of code, in case it improves things for you:

esphome:
  on_boot:
    priority: 700.0
    then:
      - switch.turn_on: the_relay
3

@glyndon - I actually have that too but at 600.0:

  on_boot:
    priority: 600.0
    then:
      - switch.turn_on: relay

The relay toggles really fast but I would really prefer it not toggle at all. I thought someone said that Tasmota firmware doesn’t have this issue so that is why I still have hope it can be done in ESPHome and that it is not a hardware design issue instead.

4

I too would prefer no toggles, but I don’t know if the machine is capable of preserving a GPIO state while booting.
(Guessing that most micros are going to neutralize every output at boot)
So barring a machine-supported option, I believe the best we can hope for is to put it back on as early in the boot cycle as possible.

5

Agreed… I just need to confirm whether Tasmota is able to as I recall reading, if so, then it is just a sw issue, otherwise it is just like you said (more likely, but hope is last to die :wink: )

The real issue here is my allergy towards “Update Available” :wink: I can’t stop myself from clicking the ‘Update’ button…

6

A thought experiment…:
What if one were to wire the relay using its normally-closed contacts, and configure it as ‘inverted’ in the YAML. That way, the normal state of the entire circuit is supplying power to the outlet, unless the software raises that control line to turn it off. During machine reset the control line would remain low, and when software takes over, and is config’d to set it low for ‘on’, nothing actually changes.
No blip.

7

@glyndon I had the same thought but if I were to do that, I’d rather do it by designing a replacement PCB, something that I have yet to learn how to do…

If ESPHome had a way to tidy up the main page, for example supporting folders where you can stow away devices by type, room or whatever, then I may survive longer without pressing the update button every month even though it adds nothing to the outlets’ functionality :wink:

8

I’ve got the same issue, and the underlying cause is indeed the ESP8266 setting the GPIO output to ‘low’ when it is reset. If the ESPHome code starts up quickly enough it can set the output ‘high’ before the relay actually opens, but if you add more content to your ESPHome configuration it will delay that process and the relay blip will come back (I’m dealing with this now). There is no way to convince the ESP8266 to leave the GPIO in its current state during reset.

I’m going to open up one of mine this weekend and find out whether it is practical to use the N/C contacts instead of the N/O contacts, since that’s the best fix. If it is not, I’ll find way to just energize the relay coil permanently, regardless of the state of the GPIO.

9

What about a capacitor on the GPIO’s output to keep it high a bit longer? Long enough for the relay not to deenergize in that super short blip when the chip is reset?

10

I’ve been informed by a friend that the relay in the S31 does not have N/C contacts, so that is not an option.

I suspect in my situation, where I have no need of the relay at all, I’ll just remove it and connect its load-side pads with a wire.

11

@kpfleming Did you consider adding a cap? If the GPIO is high to turn on the relay, then adding a cap should delay it turning off. Sized properly, this may hold it on for long enough to survive the on-off-on that it does. By the sound of it, it is less than a second.

12

Did you try this configuration already :question: :point_down:

  • early_pin_init (Optional, boolean): Specifies whether pins should be initialised as early as possible to known values. Recommended value is false where switches are involved, as these will toggle when updating the firmware or when restarting the device. Defaults to true.
5 Likes
13

I did not, since its default is true and that’s what I would want :slight_smile:

I’m fairly certain at this point that I’m just going to solder 14AWG jumper wires across the ‘load’ terminals on the relays, so that it won’t matter whether the relay coil is energized or not (power will always flow). Easy to do, and easy to reverse should I ever want to.

14

OK, I apologize for replying too hastily to @orange-assistant; early_pin_init isn’t the fix for this problem, it’s the cause of this problem!

When early_pin_init is set to true (which is the default) all output GPIOs in the ESPHome configuration are initailized to their off state before the configuration’s components are initialized. This happens much earlier than the earliest possible on_boot automations too. In my testing, this is the reason why the GPIO driving the relay goes low for a split-second before the configuration sets it to high.

Adding early_pin_init: false to the esp8266 section of the configuration has resolved the problem for me; no need for any hardware changes.

3 Likes
15

That indeed fixes the issue! Finally! Now I can use this outlet for many more devices that before. I have one on my computer but every time I flashed it, the UPS would kick in… now no more!

For easier reference for others wanting to adjust their code, see below:

esphome:
  name: ${devicename}
  comment: ${device_description}
  friendly_name: ${friendly_devicename}

esp8266:
  board: esp01_1m
  early_pin_init: false

Thanks @orange-assistant @kpfleming !!

5 Likes
16

Amazing, thank you! , I was looking for this for my S31 outlets, that I have doing power monitoring for my servers, indeed does work, great find!

1 Like