ESP8266 + SCD41 Resets after 10-20 minutes

ESPHome
,
1

I have built a CO2 sensor using an ESP8266, SCD41 sensor, and TM1637 display. After adding it to ESPHome, it works as planned, except the ESP8266 periodically resets. The period is approximately every 15 minutes, but it varies, occasionally running for up to 30 minutes. I built another one with identical components, and it exhibits the same issue. Suggestions on where to look would be appreciated.

Here is the ESPhome configuration:

esphome:
  name: master-br-environment
  friendly_name: Master BR Environment

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "****"

ota:
  - platform: esphome
    password: "*****"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Master-Br-Environment"
    password: "*****"

captive_portal:

mqtt:
  broker: 192.168.0.18
  port: 1884
  reboot_timeout: 0s
  birth_message:
    topic: SFOhome/mbr/env_status
    payload: online
  will_message:
    topic: SFOhome/mbr/env_status
    payload: offline
    
i2c:
  sda: GPIO4
  scl: GPIO5
  scan: false

sensor:
  - platform: scd4x
    co2:
      name: "MBR CO2"
      id: "co2"
      accuracy_decimals: 0
      state_topic: SFOhome/mbr/co2
#    temperature:
#      name: "MBR Temperature"
#      id: "temp"
#      accuracy_decimals: 1
#      device_class: "temperature"
#      filters:
#        - multiply: 1.8
#        - offset: 12
#      unit_of_measurement: "ºF"
#      state_topic: SFOhome/mbr/temperature
    humidity:
      name: "MBR Humidity"
      id: "humidity"
      accuracy_decimals: 1
      state_topic: SFOhome/mbr/humidity
    update_interval: 2min
    automatic_self_calibration: False
    altitude_compensation: 1727m

display:
    platform: tm1637
    id: tm1637_display
    clk_pin: GPIO14
    dio_pin: GPIO12
#    update_interval: 6s
    inverted: False
    intensity: 0
    length: 4
    lambda: |-
      if ((id(humidity).state > 0) and (id(humidity).state < 100)) {
        it.printf(0, "%4.0f", id(humidity).state);
      }
2

Esphome logs.
What’s the last thing there before it resets.

3

Post a ESPHome compile & run log here (formatted please).
esp-idf or arduino?
Have you considered a ESP32 instead as you may he running short of resources on the ESP8266?

4

Running MQTT and API together has been known to cause problems. You don’t need both…do you really?

1 Like
5

ESP8266 has a weaker wifi stack than the ESP32. They’re a little better than the Libretiny chips, but not by much. Some things you can try doing on your network to help with stability are forcing the device to the closest AP using MAC filtering. Enabling IGMP snooping on your wifi SSID, enabling multicast to unicast, disabling packet steering, and disabling inactivity polling if any of these things are options on your router/AP. Of course these things don’t come without their advantages/disadvantages and as such I always recommend investigating each topic to understand what you are enabling/disabling.

6

reboot_timeout (Optional, Time): The amount of time to wait before rebooting when no client connects to the API. This is needed because sometimes the low level ESP functions report that the ESP is connected to the network, when in fact it is not - only a full reboot fixes it. Can be disabled by setting this to 0s. Defaults to 15min.

As @Spiro asked, are you sure you need/want api. I will bet that is the problem. But, as @Karosm said the logs will tell you. You need the serial log directly from the device to see the reboot due to no connection.

7

As Spiro said, it definitely looks like you are not actually using the api: component, which explicitely makes your device to reboot every 15 minutes.

image
image1121×265 14 KB

That warning should definitely be at least duplicated in the API section of the ESPHome doc :wink:

8

Dropping the api did not make a difference. Using ESPhome for over a year, I was unaware the ramifications of using it with MQTT or not using it at all. That really needs to be documented. I’ve left it in since I usually pick up the values from the api for HA screens - the MQ posts are for other systems.

Moving to a ESP32 did solve the problem. I left it on an ESP8266 because it didn’t seem to need a ESP32 and I try to use the smaller ones - mostly just to use them up.

This was meant to be a quick solution (yes, I’m acquainted with Mr. Murphy) - I’ll try to debug the ESP8266 issue later when i have time.

Thanks for all the suggestions.