ESP on_boot priority

ESPHome
1

Hello everyone - curious if there’s anyone that has ran into this issue.

I have some Wyze Outdoor Plugs that I reflashed. They are ESP32 devices and a great cheap design to run 15A 120v loads that are also outdoor capable.

Some of these devices drive higher amperage devices, and I’ve really struggled with getting them to boot with the switches by default set to off. I just did a generator test before winter and it amplified the issue as heaters engaged when they should have defaulted to off.

I have already set the restore state of the switches to ALWAYS_OFF, but even that doesn’t work. They start up on and I’ve found that the on_boot is the only way to address the state issue.

There’s so much more to unload, but I wanted to start with something more simple. Take the following:

esphome:
  name: backheaterplug
  platform: ESP32
  board: esp-wrover-kit
# Heat plugs default to off
  on_boot:
    priority: -100
    then:
      - switch.turn_off: relay1
      - switch.turn_off: relay2

The priority value is of particular interest for me. In the ESPHome documentation, the higher the value, with 800 being called during hardware initialization, the faster that the subsequent command should be…but in my case, it seems to be inverted. If I do a 800 priority, nothing happens, but if I do a -100, then it kind of works - the switches are on for a second and then turn off.

Any common observations on this that may explain the behavior?

2

Logs might help, although I am not sure when logging starts in this priority scheme. Probably 200 I think.

What sort of switch is it? I assume a gpio one, in which case you might want

restore_mode: ALWAYS_OFF

or ALWAYS_ON if it is inverted (I think).

3

Did you try 700? Or 600?

Perhaps the switches aren’t quite set-up yet if you turn them off at 800?

4

Thanks @nickrout for the reply - I did try the ALWAYS_OFF but that also didn’t behave the way I anticipated - I’m going to do some other tests as maybe it was inverted.

It is a GPIO device - GPIO 15 and 32 are the relay switches.

I just double checked and they are not inverted. I’ll need to setup a better test case.

Here’s the full config in case it helps:

substitutions:
  display_name: BackHeaterPlug
  # Higher value gives lower watt readout
  current_res: "0.001"
  # Lower value gives lower voltage readout
  voltage_div: "770"  
  
esphome:
  name: backheaterplug
  platform: ESP32
  board: esp-wrover-kit
# Heat plugs default to off
  on_boot:
    priority: -100
    then:
      - switch.turn_off: relay1
      - switch.turn_off: relay2

wifi:
  ssid: frappier-pbo
  password: password
  ap: 
    ssid: ${display_name}_AP
    password: password
    ap_timeout: 3min
    
captive_portal:

logger:

api: 
  password: "password"
  reboot_timeout: 0s
  
ota:
  password: "password"

time:
  - platform: homeassistant
    id: homeassistant_time

switch:
  - platform: gpio
    name: ${display_name} Relay1
    pin:
      number: GPIO15
      inverted: false
    id: relay1
    restore_mode: RESTORE_DEFAULT_OFF
    on_turn_on:
      - light.turn_on: relay1_led
    on_turn_off:
      - light.turn_off: relay1_led
  - platform: gpio
    name: ${display_name} Relay2
    pin:
      number: GPIO32
      inverted: false
    id: relay2
    restore_mode: RESTORE_DEFAULT_OFF
    on_turn_on:
      - light.turn_on: relay2_led
    on_turn_off:
      - light.turn_off: relay2_led
  - platform: restart
    name: ${display_name} Restart

output:
  - platform: gpio
    pin: GPIO19
    inverted: True
    id: relay1_led_gpio
  - platform: gpio
    pin: GPIO16
    inverted: True
    id: relay2_led_gpio

light:
  - platform: binary
    name: "Relay1 LED"
    id: relay1_led
    internal: true    
    output: relay1_led_gpio
  - platform: binary
    name: "Relay2 LED"
    id: relay2_led
    internal: true
    output: relay2_led_gpio

sensor:
  - platform: adc
    pin: GPIO34
    name: "${display_name} LUX"
    update_interval: 10s
    attenuation: 11db
  - platform: hlw8012
    sel_pin:
      number: GPIO25
      inverted: true
    cf_pin: GPIO27
    cf1_pin: GPIO26
    current_resistor: ${current_res}
    voltage_divider: ${voltage_div}
    change_mode_every: 3
    update_interval: 3s    
    current:
      name: "${display_name} Amps"
      unit_of_measurement: A
      accuracy_decimals: 2
    voltage:
      name: "${display_name} Volts"
      unit_of_measurement: V
      accuracy_decimals: 1
    power:
      name: "${display_name} Watts"
      id: plug_power
      unit_of_measurement: W
      accuracy_decimals: 0    
      filters:
        - calibrate_linear:
            - 0.0 -> 0.0
            - 134 -> 58 
  - platform: template
    id: plug_power_kw
    name: "${display_name} Kilowatts"
    unit_of_measurement: "kW"
    lambda: |-
      return id(plug_power).state * 0.001;
    accuracy_decimals: 4
    update_interval: 3s            
  - platform: total_daily_energy
    id: total_energy
    name: "${display_name} Total Daily Energy"
    power_id: plug_power_kw
    unit_of_measurement: kWh
    restore: false

binary_sensor:
  - platform: gpio
    internal: true
    pin:
      number: GPIO18
      mode: INPUT_PULLDOWN
      inverted: True
    name: ${display_name} Button1
    on_press:
      - switch.toggle: relay1
  - platform: gpio
    internal: true
    pin:
      number: GPIO17
      mode: INPUT_PULLDOWN
      inverted: True
    name: ${display_name} Button2
    on_press:
      - switch.toggle: relay2

status_led:
  pin:
    number: GPIO5
    inverted: true

web_server:
    port: 80
    auth:
      username: admin
      password: !secret sensor_password
5

@Mahko_Mahko - that’s a good idea - I’ll give it a try.

Interestingly, when I did a higher value it took longer to turn off. The documentation for the priority states that a higher value takes longer on a shutdown operation, but as this is a boot I assumed it wasn’t considered a shutdown operation…

1 Like
6

If I were you I’d try asking for support over on the ESPHome Discord. They are quick and very knowledgeable.

They may have ideas that may fix the root cause, rather than something which may just be managing symptoms.

Another random thought. Is it possible your binary sensors are toggling your relays during boot? Perhaps try commenting them out for testing?

7

I have tried with the light, and 1000 nothing happens, 700 works ok and even takes precedence to always_on settings, when i use 700, i do not see color that appears with always_on.