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
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
[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?
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.
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
Probably doesn’t happen when I don’t use adaptive lighting w/ esphome
Problem doesn’t seem to happen with Tasmota and adaptive lighting.
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.
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.
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.