Esphome bulb crashes w/ using Adaptive Lighting Integration

I am using the esphome dev branch on my bulb (RGB bulb but only configured for white) w/ the new adaptive lighting integration via HACS. The bulb seems to “crash” (goes unavailable) at some point during the day every day - although not always at the same… Sometimes (although rare) it makes it through out the whole day (8a-9p). I dont have any issues w/ I dont use the adaptive lighting addon

Anyways ideas how I can troubleshoot this?


esphome:
  name: ${device_name}
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: ${wifi_ssid}
  password: ${wifi_password}

# Enable Logs from the device
logger:

# Enable Home Assistant API
api:

# Enable Over-The-Air updates
ota:

output:
  - platform: esp8266_pwm
    id: output_red
    pin: GPIO4
  - platform: esp8266_pwm
    id: output_green
    pin: GPIO12
  - platform: esp8266_pwm
    id: output_blue
    pin: GPIO14
  - platform: esp8266_pwm
    id: output_warm_white
    pin: GPIO13
    #frequency: 2000 Hz
  - platform: esp8266_pwm
    id: output_cold_white
    pin: GPIO5
   # frequency: 2000 Hz
# Define a light entity
# light:
#   - platform: monochromatic
#     name: $device_name
#     id: $device_name
#     output: output_warm_white




light:
  - platform: cwww
    name: $device_name
    id: $device_name
  #  output: output_warm_white
    cold_white: output_cold_white
    warm_white: output_warm_white
    cold_white_color_temperature: 6536 K
    warm_white_color_temperature: 2000 K
    default_transition_length: 0.5s
    cold_white_color_temperature: 6200 K
    
    restore_mode: RESTORE_DEFAULT_OFF

Where are your logs?

Dumb question - but logs only seem to stream when the device is online… Is there somewhere to check?

Left the logs in streaming and didnt see anything interesting…
I

NFO Connecting to office_ben_desk_lamp.local:6053 (192.168.0.117)

INFO Successfully connected to office_ben_desk_lamp.local

WARNING Disconnected from API: Timeout while waiting for message response!

WARNING Error resolving IP address of office_ben_desk_lamp.local. Is it connected to WiFi?

WARNING (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)

WARNING Couldn't connect to API (Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -5] No address associated with hostname). Trying to reconnect in 1 seconds

WARNING Error resolving IP address of office_ben_desk_lamp.local. Is it connected to WiFi?

WARNING (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)

WARNING Couldn't connect to API (Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -5] No address associated with hostname). Trying to reconnect in 1 seconds

WARNING Error resolving IP address of office_ben_desk_lamp.local. Is it connected to WiFi?

WARNING (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)

WARNING Couldn't connect to API (Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -5] No address associated with hostname). Trying to reconnect in 2 seconds

Will move to INFO

Here are the logs… nothing super helpful…

[15:26:30][D][light:265]: 'office_ben_desk_lamp' Setting:
[15:26:30][D][light:278]:   Brightness: 100%
[15:26:30][D][light:282]:   Color Temperature: 321.0 mireds
[15:26:30][D][light:287]:   Red=100%, Green=100%, Blue=100%
[15:26:30][D][light:304]:   Transition Length: 45.0s
[15:28:00][D][light:265]: 'office_ben_desk_lamp' Setting:
[15:28:00][D][light:278]:   Brightness: 100%
[15:28:00][D][light:282]:   Color Temperature: 324.0 mireds
[15:28:00][D][light:287]:   Red=100%, Green=100%, Blue=100%
[15:28:00][D][light:304]:   Transition Length: 45.0s
[15:29:30][D][light:265]: 'office_ben_desk_lamp' Setting:
[15:29:30][D][light:278]:   Brightness: 100%
[15:29:30][D][light:282]:   Color Temperature: 328.0 mireds
[15:29:30][D][light:287]:   Red=100%, Green=100%, Blue=100%
[15:29:30][D][light:304]:   Transition Length: 45.0s
[15:31:00][D][light:265]: 'office_ben_desk_lamp' Setting:
[15:31:00][D][light:278]:   Brightness: 100%
[15:31:00][D][light:282]:   Color Temperature: 331.0 mireds
[15:31:00][D][light:287]:   Red=100%, Green=100%, Blue=100%
[15:31:00][D][light:304]:   Transition Length: 45.0s
WARNING Disconnected from API: Timeout while waiting for message response!
INFO Connecting to office_ben_desk_lamp.local:6053 (192.168.0.117)
WARNING Couldn't connect to API (Error connecting to 192.168.0.117: timed out). Trying to reconnect in 1 seconds
INFO Connecting to office_ben_desk_lamp.local:6053 (192.168.0.117)
WARNING Couldn't connect to API (Error connecting to 192.168.0.117: timed out). Trying to reconnect in 1 seconds
INFO Connecting to office_ben_desk_lamp.local:6053 (192.168.0.117)
WARNING Couldn't connect to API (Error connecting to 192.168.0.117: [Errno 113] No route to host). Trying to reconnect in 2 seconds
INFO Connecting to office_ben_desk_lamp.local:6053 (192.168.0.117)
WARNING Couldn't connect to API (Error connecting to 192.168.0.117: [Errno 113] No route to host). Trying to reconnect in 3 seconds
WARNING Error resolving IP address of office_ben_desk_lamp.local. Is it connected to WiFi?
WARNING (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)
WARNING Couldn't connect to API (Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -5] No address associated with hostname). Trying to reconnect in 5 seconds
WARNING Error resolving IP address of office_ben_desk_lamp.local. Is it connected to WiFi?

Anyone with any advice?

It looks more like a wifi problem.

Doesnt seem likely. I was an access point a few feet away and the problem always happens after the bulb is on for about 6-7 hours. Also, no other devices are experiencing any wifi issues…

I will probably switch to Tasmota to test if the problem sticks around.

Couple of added notes:

  1. Definitely not wifi - unless the wifi driver behavior changes when the bulb is on. I say this because I can leave the light off for multiple days without issue. It’s only once it’s run for multiple hours that this happens
  2. Probably doesn’t happen when I don’t use adaptive lighting w/ esphome
  3. Problem doesn’t seem to happen with Tasmota and adaptive lighting.

You could try to reduce the update frequency of adaptive lighting. Maybe it is too often for esp?

I’m at 90s… I could try it. I really like esphome, so hopefully I can get this to be stable

Maybe a bit late for an answer, but anyways this could give a hint for other users affected with a similar problem.

On my LSC Filament E14 “candle-style” bulbs (bought from ACTION in Germany) I had to restrict the power output of the (two) white channels. Otherwise, when the circadian lighting component transitions from e.g. 100% cold white to 100% warm white, in the middle of the transition we got 100% power output on both channels for a while. In my case this always led to the integrated ESP8266 loosing connection to the wifi and rebooting/boot-looping. Maybe because of overheating issues in the small bulb or overloading the tiny builtin power supply.

Here the corresponding config lines:

light:
  - platform: cwww
    name: "Laterne"
    cold_white: output_component1
    warm_white: output_component2
    cold_white_color_temperature: 3500 K
    warm_white_color_temperature: 2000 K
    default_transition_length: 3s

output:
  - platform: esp8266_pwm
    id: output_component1
    pin: 14
    max_power: 0.6
  - platform: esp8266_pwm
    id: output_component2
    pin: 12
    max_power: 0.6

I know that this solution leads to a reduction of total brightness in both channels when transitions are over (limiting to 60% each), but since I use these bulbs more like decorative lights, this does not really matter to me (I guess there must be even better config options maintaining 100% output power in total at all times, but wanted to keep it simple and this suffices my needs).

You may also have success using the constant_brightness parameter in the cwww light’s definition.
That param, if set true, will prevent the color-balancing code from ever turning both channels on to full power simultaneously.

1 Like

I have just discovered a workaround for the reboots.
While observing one of the affected devices on the serial port log, I saw a wdt-initiated reboot when the brightness/color were midrange. The devices were stable at either end of the range - only resetting when the colors were about equal.
So, I looked around and found that the call shown below will ‘feed’ the watchdog timer sufficiently to prevent the random rebooting.

esphome:
  on_loop:
    then:
      - lambda: |-
          ESP.wdtFeed(); return;