Why is status_led flashing?

Relative noob here - while I’m a professional with 37 years of embedded software development experience, I’m quite new to using Home Assistant and ESPHome. While I have several ESPHome projects working, I don’t have a lot of experience with HA or ESPHome.

I’m running into an issue with a couple recent projects: they include a status_led or status_light output, and some of them are frequently flashing, while most are only flashing when unable to connect to the Home Assistant server, as expected. For the problematic projects, as long as I have the node’s Logs window open, the status_led is off, but when I close the log, it starts flashing again.

I can’t figure out WHY some of my projects are flashing when I don’t have the log window open. It’s probably something stupid I’ve done in the configuration, but I don’t see it.

In an effort to figure it out, I created a simple project and added a sensor that reports App.get_app_state() which reports:

  • 2 when the Logs window is open (status_led is off)
  • 258 when the Logs window is closed (status_led is flashing slowly)

The node is connected to WiFi, it shows up in Home Assistant, and is connected to the MQTT broker - the status value updates in HA and I can see MQTT updates from the node. Nothing in the node’s log output jumps out at me that might explain the warning.

So, the status_led (and also status_light) output is properly showing the status, but WHY is the 256 bit being set? How can I figure this out?

Configuration of my simplified test node that exhibits this behavior:

esphome:
  name: test
  platform: ESP32
  board: nodemcu-32s
  
debug:

wifi:
  ssid: !secret iot_ssid
  password: !secret iot_password
  fast_connect: true

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: !secret fallback_password

ota:
  password: !secret fallback_password

web_server:
  port: 80

mqtt:
  broker: !secret mqtt_broker
  username: !secret mqtt_user
  password: !secret mqtt_pass

# System status LED
status_led:
  pin: GPIO16

sensor:
  - platform: template
    name: test status text
    id: uptime_human
    lambda: |-
      return App.get_app_state();
    update_interval: 5s

According to the docs it’s triggered by warnings and errors. I understand this is a minimal config but what is the log output saying? Is it logging errors or warnings?

Yes, it’s clearly reporting a warning, but there is nothing in the logs to indicate what that might be. When I open the log window, there is the initial flurry of [C] level configuration messages, then the [D] level debug messages that give the initial startup information, then periodic reports of the status value. No errors, no warnings.

INFO Reading configuration /config/esphome/test.yaml...
INFO Starting log output from test.local using esphome API
INFO Successfully connected to test.local
[14:28:09][I][app:102]: ESPHome version 2021.12.1 compiled on Dec 29 2021, 13:54:44
[14:28:09][C][status_led:019]: Status LED:
[14:28:09][C][status_led:020]:   Pin: GPIO16
[14:28:09][C][wifi:488]: WiFi:
[14:28:09][C][wifi:350]:   Local MAC: 3C:61:05:2A:F3:30
[14:28:09][C][wifi:351]:   SSID: [redacted]
[14:28:09][C][wifi:352]:   IP Address: 10.42.210.127
[14:28:09][C][wifi:354]:   BSSID: [redacted]
[14:28:09][C][wifi:355]:   Hostname: 'test'
[14:28:09][C][wifi:357]:   Signal strength: -68 dB ▂▄▆█
[14:28:09][C][wifi:361]:   Channel: 6
[14:28:09][C][wifi:362]:   Subnet: 255.255.255.0
[14:28:09][C][logger:233]: Logger:
[14:28:09][C][logger:234]:   Level: DEBUG
[14:28:09][C][logger:235]:   Log Baud Rate: 115200
[14:28:09][C][logger:236]:   Hardware UART: UART0
[14:28:09][C][template.sensor:023]: Template Sensor 'test status text'
[14:28:09][C][template.sensor:023]:   State Class: ''
[14:28:09][C][template.sensor:023]:   Unit of Measurement: ''
[14:28:09][C][template.sensor:023]:   Accuracy Decimals: 1
[14:28:09][C][template.sensor:024]:   Update Interval: 5.0s
[14:28:09][C][web_server:162]: Web Server:
[14:28:09][C][web_server:163]:   Address: test.local:80
[14:28:09][C][ota:082]: Over-The-Air Updates:
[14:28:09][C][ota:083]:   Address: test.local:3232
[14:28:09][C][ota:086]:   Using Password.
[14:28:09][C][api:134]: API Server:
[14:28:09][C][api:135]:   Address: test.local:6053
[14:28:09][C][api:139]:   Using noise encryption: NO
[14:28:09][C][mqtt:063]: MQTT:
[14:28:09][C][mqtt:065]:   Server Address: 10.42.210.20:1883 (10.42.210.20)
[14:28:09][C][mqtt:066]:   Username: [redacted]
[14:28:09][C][mqtt:067]:   Client ID: [redacted]
[14:28:09][C][mqtt:069]:   Discovery prefix: 'homeassistant'
[14:28:09][C][mqtt:070]:   Discovery retain: YES
[14:28:09][C][mqtt:072]:   Topic Prefix: 'test'
[14:28:09][C][mqtt:074]:   Log Topic: 'test/debug'
[14:28:09][C][mqtt:077]:   Availability: 'test/status'
[14:28:09][C][mdns:084]: mDNS:
[14:28:09][C][mdns:085]:   Hostname: test
[14:28:09][C][mqtt.sensor:027]: MQTT Sensor 'test status text':
[14:28:09][C][mqtt.sensor:031]:   State Topic: 'test/sensor/test_status_text/state'
[14:28:09][D][debug:036]: ESPHome version 2021.12.1
[14:28:09][D][debug:042]: Free Heap Size: 230024 bytes
[14:28:09][D][debug:072]: Flash Chip: Size=4096kB Speed=40MHz Mode=DIO
[14:28:09][D][debug:106]: Chip: Model=ESP32, Features=WIFI_BGN,BLE,BT, Cores=2, Revision=1
[14:28:09][D][debug:108]: ESP-IDF Version: v3.3.5-1-g85c43024c
[14:28:09][D][debug:110]: EFuse MAC: 3C:61:05:2A:F3:30
[14:28:09][D][debug:162]: Reset Reason: Software Reset CPU
[14:28:09][D][debug:205]: Wakeup Reason: Unknown
[14:28:09][D][sensor:113]: 'test status text': Sending state 2.00000  with 1 decimals of accuracy
[14:28:14][D][sensor:113]: 'test status text': Sending state 2.00000  with 1 decimals of accuracy
[14:28:19][D][sensor:113]: 'test status text': Sending state 2.00000  with 1 decimals of accuracy
[14:28:24][D][sensor:113]: 'test status text': Sending state 2.00000  with 1 decimals of accuracy

This log is from the device’s log window. It is reporting a status of 2, which is no warning. But when I close the log window, and look at the log on the serial port, it is reporting a status of 258 - the warning bit is set.

Interesting… Looking at the serial port output, and closing the Home Assistant/ESPHome log window while the serial port is still open, shows this on the serial port:

[D][sensor:113]: 'test status text': Sending state 2.00000  with 1 decimals of accuracy
[D][sensor:113]: 'test status text': Sending state 2.00000  with 1 decimals of accuracy
[W][api.connection:082]: ESPHome Logs 2021.12.1 (10.42.210.20): Connection closed
[D][sensor:113]: 'test status text': Sending state 258.00000  with 1 decimals of accuracy
[D][sensor:113]: 'test status text': Sending state 258.00000  with 1 decimals of accuracy

So, it looks like it is showing a warning when the log connection is closed. But the node is still connected to HA and MQTT - I can see the updates whether the log window is open or closed.

However, if I do the same thing on a node where the status_led behaves as expected, I can see the same warning on the serial port when closing the log window, and yet the status_led does not flash - as expected. So I don’t think the above warning about closing the log connection should trigger the status_led? If that were the case, then shouldn’t ALL of my ESPHome projects flash the status_led? They don’t, only a few of them do so.

The docs say slow flash for a warning, once per second. Fast for an error, multiple per second. I’m not sure the typical behavior, as I don’t use the component. So I’m not sure if the error/warning will clear after a certain period.

Disconnection of a logger will throw a warning. For the particular node above does the light start to flash when you shut the logger and is it a slow flash? If yes, if you power down the board and power back up without opening a log, does it stay off? Alternatively you could just add a reboot button to your config.

Yes, it is clearly the warning flash. Looking at the App.get_app_state(), which returns 0x102, the warning bit (0x100) is set, which confirms that the node is complaining about a warning. The question is what is triggering the warning state?

For my other nodes, I will get the slow flash if they have trouble connecting to WiFi, or if HA is down (rebooting, for example) but all of the others stop flashing as soon as the connection is established. Opening/closing the log window has no effect on the status light for these nodes that work as expected. I can let the node run for days, and the flashing never stops.

Yes, it is the slow warning flash when I close the logger window. But it only happens on a couple of recently created nodes, and on one node that never showed a problem before but it does now after making some recent minor changes. On most of my nodes, closing the log window does show a warning message to that effect on the serial port, but the status_led does not flash.

No. On power up, it immediately starts flashing. When I open the log window, it stops flashing, and then starts flashing again when I close the log window.

I do have a reset button in all of my nodes. It doesn’t help for these nodes.


I’m continuing to investigate. Comparing the log output of this node to one that doesn’t have this odd behavior, I noticed that this simple test node (config in my first post) didn’t define the captive_portal. I added it, and now it won’t connect to the MQTT broker. At least that’s a legitimate warning. And now, on the ESPHome page, that node is now showing as offline. Ugh.

I’m sure it’s some silly oversite in my configuration, but I have not yet been able to find it. :frowning_face:

Still working on it…

I think I’m making progress. The nodes that are giving me trouble are all using NodeMCU modules, and all of the nodes using that module are showing this behavior. My nodes that are based on other ESP32 modules (mostly the Adafruit HUZZAH32 breakouts) are all working as expected. Of course, correlation is not causation, but there is a 100% correlation here, which is highly suspicious.

I noticed that rebooting the NodeMCU nodes wrote these lines out the serial port:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac
[E][esp32-hal-misc.c:111] disableCore1WDT(): Failed to remove Core 1 IDLE task from WDT
[I][logger:214]: Log initialized

I’m highly suspicious of that initial flash read error message. And it looks like that error is then causing a watchdog reset? On on my other nodes, it just outputs this on boot:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac
[E][esp32-hal-misc.c:111] disableCore1WDT(): Failed to remove Core 1 IDLE task from WDT
[I][logger:214]: Log initialized

Note that all of these lines appear in the first set of output, but only after the initial flash error and WD reboot messages. It appears that the problematical nodes are booting twice? Once to throw the initial errors, and then booting again normally? They consistently do this on every power up.

I changed the board type in the configuration for my test node from nodemcu-32s to featheresp32 (which is what I used for most of the other boards) and now I don’t get the flash error message, and the status LED works as expected. But of course, I’m concerned about what might not be working properly because of using the wrong board type.

The boards I’m using (the ones where I have a problem) exactly match the pictures on the ESPHome NodeMCU ESP32 page, except for slight differences in the CE markings on the ESP32 itself. But when I use the recommended “nodemcu-32s” board type, I get the flash error and constantly flashing status LED.

My first node using the NodeMCU board didn’t do this until recently. I had made some very minor changes (just changing sensor names) but also updated to the most recent HA and ESPHome versions. I’m beginning to suspect that something in the newest version of ESPHome broke support for the nodemcu-32s board type? I don’t recall the previous version I was running, but it was a few versions old as I had skipped a few updates.

Now that I have a better idea of what’s going on, I’m going to look for any known issues with the nodemcu-32s board type and flash errors. Does anybody know of any issues offhand?

Well, that wasn’t it. :frowning_face:

Just to test the theory, I switched my two nodes back to a board type of nodemcu-32s, and reinstalled the code into them. If the board type theory is correct, they should start flashing the status_led again. They don’t - the status_led still works as it should. So that wasn’t it.

All of my boards are working properly now, but I don’t understand why. How frustrating!

I guess I can’t do any testing on this until it starts to act up again - if it does act up in the future, hopefully I’ll realize what I changed to trigger it.

Thanks for your help, @Mikefila! But I guess this is a dead issue for the time being.

I have just flashed a Sonoff Basic, and noticed that my Status LED is flashing.
The moment I open logs (HA->ESPHome → device logs) the flashing stops!

Just using the standard config from: Using With Sonoff Basic — ESPHome

My setup:
Hardware: Sonoff Basic R1
Config:

esphome:
  name: sonoff-basic-example
  platform: ESP8266
  board: esp8285

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

api:

logger:

ota:

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO0
      mode:
        input: true
        pullup: true
      inverted: true
    name: "Sonoff Basic Button"
    on_press:
      - switch.toggle: relay

switch:
  - platform: gpio
    name: "Sonoff Basic Relay"
    pin: GPIO12
    id: relay

status_led:
  pin:
    number: GPIO13
    inverted: yes

@source_creator, I’m sorry to hear that you are having the same problem. At least I know I’m not alone.

I just built and programmed eight copies of a new board design, and one board of another design, programmed them up with ESPHome, and all nine were all blinking. :face_with_symbols_over_mouth:

Then I saw the new device notification in the Home Assistant side bar, clicked “check it out” which took me to the integrations page, with all of my new nodes listed as newly discovered. I clicked on “Configure” and adopted each one, the status light blinking stopped. D’oh!

So, in my case, it looks like the status LED will be blinking until the node is actually integrated into Home Assistant.

Probably a noob step, but like I said at the beginning of this thread, I’m relatively new to Home Assistant/ESPhome, and very new to using the status_led and status_light components.

Up above, when my initial boards stopped blinking, and I thought it was because I changed the board type, I probably had gone ahead and integrated the board, without thinking about the repercussions.

So, the solution is: finish integrating the node in the Home Assistant - the slow flash is the warning indicator, and apparently not being integrated into Home Assistant is considered a warning.

3 Likes

The default behavior of esphome, when it is not connected to either mqtt or the api, it goes into a boot loop. It assumes it needs to restart in order to reconnect. The reboot behavior can be adjusted via but it’s rarely necessary.

Good to know @Mikefila.

It wasn’t in a boot loop, but then again, it WAS successfully connected to MQTT. And looking back, it makes sense that with the log window open, it did have an HA connection, so the light was off. But on closing the log window, without the node being configured into HA, it no longer had an HA connection, so the warning came back.

Once you realize what’s going on, it makes perfect sense.