ESP-01/01S Relay Board

gandalf8266 · March 23, 2025, 11:34am

Hello, I have an ESP-01 relay board with the following configuration:

esphome:

name: releias-esp01

friendly_name: Releias esp01

esp8266:

board: esp01_1m

# Enable logging

logger:

# Enable Home Assistant API

api:

encryption:

key: ‘T3DLEYqi+gdeJxTs2GhcA1TsPLMnqP3FcN+QPHFh4HQ=’

ota:

- platform: esphome

password: ‘cd10edf1b8fddaf9f8ccd01c17fad7e0’

wifi:

ssid: !secret wifi_ssid

password: !secret wifi_password

# Enable fallback hotspot (captive portal) in case wifi connection fails

ap:

ssid: ‘Releias-Esp01 Fallback Hotspot’

password: ‘Uo3QlTc3NK9C’

captive_portal:

switch:

- platform: gpio

id: Role

name: Role

pin:

number: GPIO0

inverted: True

In principle it works, but it always ‘toggles’ after it is de-energised. You could say it’s not bad now, but if I want to build a gate control, for example, the gate always opens or closes after a reboot of the ESP.
I once experimented with HAA and there was a configuration where this was not the case, which means that it should work in principle.
I hope there is a solution to this.
vg
Chris

jojo99 · March 23, 2025, 2:32pm

Hi,
if it is this classic relais board, I’m affraid that it is not possible to prevent relais triggering on power-up.

This is a helpful conversation about finding the cause and I think it didn’t change until now.
https://www.letscontrolit.com/forum/viewtopic.php?t=8924

ShadowFist · March 23, 2025, 3:21pm

Not sure if it will work, but try adding the below:

  on_boot:
    priority: 800
    then:
      - switch.turn_off: GPIO0

neel-m · March 23, 2025, 3:47pm

It is unlikely that you will find a solution to what is arguably a very bad hardware design choice. There is a limit to what can be fixed in software.

There is a weak pull-up on GPIO 0 (or the esp8266 will enter flashing mode) on boot. This is a requirement of the esp8266, you cannot change that. That means on reboot, the signal goes:

from being driven LOW (normal operation relay turned off)
to reset (GPIO 0 is now an input, so weak pull-up takes effect, and it is now HIGH)
to startup (GPIO 0 becomes an output LOW)

That WILL glitch the relay. There is no SW fix for this bad HW design. For many projects a glitch doesn’t matter much. If it does for yours, you need to make sure both the HW and SW design are good for the requirements you need.

Karosm · March 23, 2025, 4:14pm

With Esp-01 it’s little bit more difficult, because it doesn’t have any rock solid (on boot) gpios exposed. You can try with GPIO0 or GPIO2, mut even those fluctuate little bit on boot.
Add this to your switch code:
restore_mode: RESTORE_DEFAULT_OFF
and on esp8266:
early_pin_init: false

neel-m · March 23, 2025, 6:17pm

This is likely the board and design: ESP-01S 1 Channel Relay | devices.esphome.io

This design is FLAWED. It WILL glitch on reset. There is no SW fix that will solve it. See above for the reason.

If glitches are something the rest of your project can’t tolerate, you will need a better design for this portion. That means selecting a different relay board, one that has a good HW and SW design and is known to NOT glitch. This one is known to glitch. So far, no one has come up with a SW solution to a relay that is active HIGH on GPIO 0.

If the relay was active LOW, it could be possible to make it work across a reset of the esp8266. But it might have undefined behavior on first power on, as the power turns on.

If glitches matter to the design of your project, you HAVE to do a really good design. For many projects, these short glitches don’t really matter, which is why the design can be just mediocre (the bar is it “it worked the one time I tested it”).

stevemann · March 23, 2025, 6:23pm

I’m not sure what you mean here, but the relay is on GPIO0 which is high on boot.

neel-m · March 23, 2025, 6:37pm

the rest of the sentence you quoted had the necessary context.

after a reboot of the ESP.

This is EXPECTED behavior with a relay that is active HIGH on GPIO 0, which MUST be HIGH for normal boot on an esp8266.

The behavior is by design (the design is flawed if your requirements don’t allow glitching the relay on boot, and you will need a new/better design, of the HW, since this is NOT a problem than can be fixed by software.)

Karosm · March 23, 2025, 8:29pm

OP has not been present on this topic anymore, but the code he posted had active low trigger. Of course it could be mistake.

neel-m · March 23, 2025, 9:00pm

Good point.

I suspect what is happening is then slightly different.

After reset:

GPIO becomes input and pull-up makes pin go HIGH
esphome sets pin as output, but does not set the state, so pin goes LOW
esphome sets pin HIGH (since it is inverted)

Still get the glitch.

This issue supports my contention.

github.com/esphome/feature-requests

Initial state for output GPIO pins

opened 08:34PM - 05 Nov 24 UTC

ntqbit

**Describe the problem you have/What new integration you would like** Set ini…tial state (high/low) before configuring a GPIO pin as output. **Please describe your use case for this integration and alternatives you've tried:** I use SN74HC595 shift register to extend the number of outputs. For my application it is important that outputs of the shift register are never in high state unless explicitly enabled. When powered, sn74hc595 outputs will be enabled (in undefined state) if OE pin is low, even if the shift register nor latch register were not initialized. To ensure that outputs are not in high state until initialized from the mcu, I pull up the OE pin with external resistor. Here is the standard configuration I use for sn74hc595 component: ``` sn74hc595: - id: "sr" data_pin: GPIO25 clock_pin: GPIO14 latch_pin: GPIO27 oe_pin: GPIO26 ``` When the component is being set up, even before the shift register is initialized with defined state, the OE is pin is pulled low for a brief moment. `components/sn74hc595.cpp`: ``` void SN74HC595Component::pre_setup_() { ESP_LOGCONFIG(TAG, "Setting up SN74HC595..."); if (this->have_oe_pin_) { // disable output this->oe_pin_->setup(); this->oe_pin_->digital_write(true); } } ``` Calling `setup` on a GPIOPin (and ESP32InternalGPIOPin, one of its implementations) only initializes the mode (input, output, etc), but not the level. The default voltage level, in most cases, is low. That is, after `this->oe_pin_->setup()`, the OE pin is pulled low until the GPIO is set up to its "initial" state with `digital_write(true)`, causing the outputs of the shift register to enable for a brief moment. This brief moment with undefined output state, in my case, is unacceptable. **Workaround** One possible workaround is to first configure the GPIO connected to the OE pin as input, to ensure that it is in high impedance state and not pulling the line down: ``` output: - platform: gpio id: "output_enable" pin: number: GPIO26 mode: INPUT ``` Enable the output whenever ready: ``` on_boot: priority: 500 then: # do some initialization, ensure shift register initialized, etc # only then configure OE GPIO as output in low state # mode could be OUTPUT_OPEN_DRAIN or OUTPUT_PUSH_PULL - lambda: |- pinMode(26, OUTPUT_OPEN_DRAIN); digitalWrite(26, LOW); ``` **Additional context** I don't have experience with other frameworks and microcontrollers like rp2040, but as far as I know, in arduino you can just use `digitalWrite(initialState)` before using `pinMode(OUTPUT)` to ensure that the pin is not initialized to wrong voltage level. The changes required (such as adding a variable `initial_state` defaulting to `low` in pin schema) are backward compatible.

This could be an issue that can be solved by SW.

Karosm · March 23, 2025, 9:13pm

Yep, it was already suggested here to play with on_boot and I added
restore_mode: RESTORE_DEFAULT_OFF.

But if issue is pin voltage fluctuation, they don’t resolve the problem.
Maybe strong external pullup could help (in case relay really is active low).

https://rabbithole.wwwdotorg.org/2017/03/28/esp8266-gpio.html