`web_server` bricks Sonoff Basic

[wsw70]

The problem

Adding the component web_server and flashing a Sonoff Basic bricks the device (no connection to the defined WiFi, a rescue AP is created but it is impossible to connect to it).

This is a follow-up to https://github.com/esphome/issues/issues/1688

Which version of ESPHome has the issue?

at least since 1.15.3, including 2022.10.1

What type of installation are you using?

Docker

Which version of Home Assistant has the issue?

N/A

What platform are you using?

ESP8266

Board

Sonoff Basic

Component causing the issue

web_server

Example YAML snippet

substitutions:
  name: switch02
esphome:
  name: switch02
  build_path: .esphome/build/switch02
  platformio_options: {}
  includes: []
  libraries: []
  name_add_mac_suffix: false
  min_version: 2022.10.1
esp8266:
  board: esp8285
  framework:
    version: 3.0.2
    source: ~3.30002.0
    platform_version: platformio/espressif8266 @ 3.2.0
  restore_from_flash: false
  early_pin_init: true
  board_flash_mode: dout
binary_sensor:
- platform: gpio
  pin:
    number: 0
    mode:
      input: true
      pullup: true
      analog: false
      output: false
      open_drain: false
      pulldown: false
    inverted: true
  name: switch02
  on_press:
  - then:
    - switch.toggle:
        id: relay
  disabled_by_default: false
switch:
- platform: gpio
  name: switch02
  pin:
    number: 12
    mode:
      output: true
      analog: false
      input: false
      open_drain: false
      pullup: false
      pulldown: false
    inverted: false
  id: relay
  disabled_by_default: false
  restore_mode: RESTORE_DEFAULT_OFF
  interlock_wait_time: 0ms
status_led:
  pin:
    number: 13
    inverted: true
    mode:
      output: true
      analog: false
      input: false
      open_drain: false
      pullup: false
      pulldown: false
sensor:
- platform: wifi_signal
  name: switch02
  update_interval: 60s
  disabled_by_default: false
  force_update: false
  unit_of_measurement: dBm
  accuracy_decimals: 0
  device_class: signal_strength
  state_class: measurement
  entity_category: diagnostic
wifi:
  domain: REDACTED_MYDOMAIN
  reboot_timeout: 15min
  ap:
    ssid: switch02
    ap_timeout: 5min
  power_save_mode: NONE
  fast_connect: false
  output_power: 20.0
  networks:
  - ssid: WUSR
    password: REDACTED_PASSWORD
    priority: 0.0
  use_address: switch02.REDACTED_MYDOMAIN
captive_portal: {}
logger:
  baud_rate: 115200
  tx_buffer_size: 512
  deassert_rts_dtr: false
  hardware_uart: UART0
  level: DEBUG
  logs: {}
  esp8266_store_log_strings_in_flash: true
ota:
  safe_mode: true
  port: 8266
  reboot_timeout: 5min
  num_attempts: 10
time:
- platform: homeassistant
  id: homeassistant_time
  timezone: UTC0
  update_interval: 15min
api:
  port: 6053
  password: ''
  reboot_timeout: 15min

Anything in the logs that might be useful for us?

No response

Additional information

The configuration above works. It is adding the line

web_server:

to the YAML configuration file that bricks the device (after a successful flashing from the esphome web interface).

I also tried to disable captive_portal in case it would conflict with web_server but the device is bricked as well.

The device never connects to the WiFi network (confirmed on the AP) with web_server enabled.

[bkaufx]

I have never had this issue and just double checked the sonoff basic I'm using has the web server enabled and working fine. Maybe only certain hardware versions have the issue? Logs would probably be good here. If the logs don't show anything interesting I'd build with verbose and/or very_verbose logging level and see what we can learn.

Have you tried lowering the wifi power? ESPHome's default of 20 is pretty aggressive. Tasmota defaults to 17 which is what I use for all my devices. I've had issues with the captive portal crashing devices with wifi power 20 so who knows what other weird side effects might be caused.

[wsw70]

Have you tried lowering the wifi power?

THANK YOU. I just flashed the same device with the power reduced to 17dB and, behold, it connected to the WiFi and exposed its web server! It also shows much better results on the AP ("connection quality", whatever it is, was 60 before, now 100)

I would have never found out without your help.

In the meantime, I was testing with the captive portal and it was extremely unstable. I will now simulate a WiFi loss and see if it works better.

EDIT: yes, the captive portal seems more stable as well.

Thank you again for this great help - I will envision to upgrade my switches with less stress and the family may very well still have lights tonight :)

[bkaufx]

Sweet, glad it worked!