CL and (Xiaomi) Yeelight RGB bulb shenanigans - (but also quite possible HW failure)

[gsotiriou]

Hi @claytonjn first of, thank you for all your hard work and effort that you (and all the other contributors) have put into this custom component. Highly appreciated!

Before presenting my issue (which is pretty much summed up in the title - allow me to present what I run and how I run it.

System

version	core-2021.11.1
installation_type	Home Assistant Container
dev	false
hassio	false
docker	true
user	root
virtualenv	false
python_version	3.9.7
os_name	Linux
os_version	5.10.60-qnap
arch	x86_64
timezone	Europe/Athens

Home Assistant Community Store

GitHub API	ok
Github API Calls Remaining	5000
Installed Version	1.17.1
Stage	running
Available Repositories	909
Installed Repositories	16

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Lovelace

dashboards	1
resources	14
views	9
mode	yaml

Hardware related to the issue

Four identical Yeelight RGB Gen2 bulbs and 1 Yeelight RGB Gen1 lightstrip, with fully updated firmware on the European (aka German) Yeelight server.

configuration.yaml

yeelight: !include integrations/yeelight.yaml

integrations/yeelight.yaml

devices:
  192.168.1.62:
    name: TV lightstrip
  192.168.1.63:
    name: Armchair lamp
  192.168.1.64:
    name: Shelf lamp
  192.168.1.65:
    name: Floor lamp
  192.168.1.66:
    name: Table lamp

CL configuration

configuration.yaml

circadian_lighting:
switch: !include_dir_merge_list switches/

switches/circadian_lighting_switches.yaml

- platform: circadian_lighting
  name: Living room circadian
  lights_ct:
    - light.floor_lamp
    - light.table_lamp
    - light.armchair_lamp
    - light.tv_lightstrip
    - light.shelf_lamp

Issues

With the exception of the lightstrip I have faced many different issues with the bulbs above when using the provided configuration of CL. I would also like to highlight that the following issues occur only when CL is used and the bulbs (seem to) work fine otherwise.

Issue No.1 - The armchair black sheep

Under "normal" circumstances (to see the definition of ab-normal see below the pink madness issue ), during evening and night times the 3 out of 4 bulbs (floor , table , shelf) have the same hue whereas the 4th (armchair) has a way more orange-ish hue, way different than the others. I am not in a position to determine which hue was the correct one, but it is very weird that same bulbs, under the same CL switch/sensor do not seem to produce the same hue and have such a vast difference.

If I had to guess, which the correct hue is, I would say that the armchair hue is the correct one and the other 3 are wrong. Because I ran CL some years ago with 4 Yeelight GEN1 bulbs and they all "agreed" on this more orange-like hue.

Issue No.2 - The morse code

Again during evening and night times I can clearly see prolonged moments of my shelf and armchair flickering intensely. This is quite irritating and tiring for my eyes.

Issue No.3 - The pink-stuck madness

After a specific hour, every day, the shelf_lamp turns pink! As time progresses it only gets pinker and pinker. Now here comes the really weird part. As long as the bulb is in this (pink-stuck) state (regardless if CL switch is ON or OFF) it will not change color no matter how I command it (via HA), with the exception of green color. So, in that state, blue is pink , red is pink , yellow is pink and the only exception is green which produces green - don't ask me why!

This is something that cannot be amended or reverted and the only "solution" is to turn off the lamp, cut the power from it, restart HA and turn on the lamp, at which point the lamp will assume the "correct" color for some moments but on the next update (assuming CL is ON) it will become pink-stuck again with all the same effects described above.

Another "solution" I recently found to very temporarily fix this issue is to turn off CL and use the official Yeelight application. Using the Yeelight app I turn off the lamp, turn it back on and put it on flow for a while. It will respond much slower at first to the Yeelight app (as if it's ... stuck) but once it starts flowing and changing all possible colors of the rainbow once, then it comes back to normal. Of course if I open CL again, it will become pink-stuck, with all the same effects described above.

I am seriously considering faulty hardware since I searched this repository even in closed tickets and never found something similar. However , since the lamp(s) do not produce any of these issues with CL off and (in case of Issue No.3) the lamp is able to assume all possible hues when it is not in this pink-stuck state, I was also wondering if we could consider a possible bug in CL causing the lamp to glitch.

I have enabled logging at the time of writing this and I will be back with as much as I can:

logger:
  default: error
  logs:
    custom_components.circadian_lighting: debug
    custom_components.circadian_lighting.sensor: debug
    custom_components.circadian_lighting.switch: debug

Let me know if I need to enable anything additionally to help you out - I would really like your feedback on this.
Update: Added logs file
logs.log

[claytonjn]

I have to start with an apology because this actually made me laugh out loud, kudos to you for putting up with this crazy behavior. 😂

Unfortunately I don't think I'm going to be able to give you a good answer, but I'm going to explain my initial "hunch" and try to give you some ideas to try that might allow you to modify the CL configuration to prevent these issues. Turning on the logging is a great first step, but they aren't going to be particularly useful by themselves, you really need to watch them as the behavior is happening (i.e. when the behavior is weird, toggle the CL switch off/on which will trigger it to "act", and watch what's logged)

Issue No.1 - The armchair black sheep

I can't offer any good explanation for why identical model bulbs would behave differently with the configuration you provided. My only suggestions here are to look through the logs when CL sets the bulbs in this state to confirm that it is in fact passing the same settings for each bulb. You should see lines like [custom_components.circadian_lighting.switch] Scheduling 'light.turn_on' with the following 'service_data': {'entity_id': 'light.floor_lamp', 'transition': 1.0, 'brightness': 35, 'color_temp': 400} for each of the 5 lights, and the service_data should match, with the exception of entity_id. Assuming that CL is setting the same values, I would try turning off CL and executing the same service call directly from Home Assistant developer dashboard. I would expect that the results would be the same as when the values are set by CL. Those steps would confirm that the bulbs are getting the same commands from CL/HA, and if they don't all appear the same then there's definitely an issue either in the Yeelight integration of the bulbs with Home Assistant or with the bulbs themselves. One thing you could try to mitigate this would be to change the CL configuration to list the bulbs under lights_rgb or lights_xy instead of lights_ct. The results won't be quite as precise in terms of the bulbs matching natural color temperature, but at least the bulbs might all match!

Issue No.2 - The morse code

My best guess here is that CL is trying to set values outside of the "acceptable" range of the bulbs. I would confirm that min and max colortemps are within the available range of the bulbs and would try playing with transition and brightness as well. Again, you can look at the logs to see what values CL is setting when this occurs and do the same service call directly in HA to help rule out if it's a CL issue or a HA issue.

Issue No.3 - The pink-stuck madness

My guess for this is the same as issue 2, that CL is trying to set the bulbs to a value outside their range. I have no idea why this would effect one particular bulb and not others, but I would follow the same basic troubleshooting steps.

In general it seems that even though these bulbs are the same generation, perhaps they're a different hardware revision or have some other differences that aren't exposed to you. I'm not sure how much I've helped in actually resolving the issues but let me know if you made any progress or have any updates...

[gsotiriou]

Update:
While Issues No.1 and No.2 still exist and manifest from time to time I think I have made a breakthrough with Issue No.3 (the pink madness).

1. I replaced the bulb in the shelf_lamp socket with a brand new Yeelight RGBW 1S
2. I made this new bulb what HA and CL would recognize as shelf_lamp (by adjusting IP/MAC in my router etc.)
3. I transferred the original shelf_lamp bulb (from now on called faulty_lamp ) to another socket AND , named it faulty_lamp inside of HA , AND put it in its very own CL switch.

After those actions were performed the following were observed:

1. The new (Yeelight 1S) shelf_lamp does obey the CL much better , however , some particular hours within the day I can swear that it's yellow hues aren't that yellow but contain a little red/pink inside. Also backed up by my girlfriend's vision which is far superior than mine.
2. The faulty_lamp was put into a master chandelier on a separate room. The reason I chose the chandelier and not some other lamp-socket that is plugged to a wall socket is because the chandelier is connected directly to the central board relay and theoretically doesn't get to be interfered by anything else.
3. The faulty_lamp - now screwed to the chandelier - initially turned on PINK during the evening hours , HOWEVER , after a reset , it has been working flawlessly for more than a week now assuming all proper hues at the right time and NO PINK in sight.

What may be happening here is a faulty socket on the shelf_lamp (hosting the shelf bulb)?
And if a faulty socket is the culprit how could it affect a lamp like that?
I'd expect that an improper electrical supply would end up not producing the full brightness capability of the LED - as that's how I know LEDs work.

I'll observe some more and return - possibly to close this one down, as it clearly is a hardware issue but not RGB-bulb hardware issue as I originally suspected.

[gsotiriou]

Update: The new Yeelight RGBW 1S turned RED this morning when lighting up (and while being adjusted by CL). Managed to find an error in the logs at that time.

Logs:

Logger: homeassistant.core
Source: components/yeelight/light.py:257
First occurred: 5:37:04 AM (1 occurrences)
Last logged: 5:37:04 AM

Error executing service: <ServiceCall light.turn_on (c:3f7849ea6adc01c754663bc074b3c857): entity_id=['light.shelf_lamp'], params=transition=60.0, brightness=124, color_temp=400>
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/yeelight/light.py", line 250, in _async_wrap
    return await func(self, *args, **kwargs)
  File "/usr/src/homeassistant/homeassistant/components/yeelight/light.py", line 627, in async_set_brightness
    await self._bulb.async_set_brightness(
  File "/usr/local/lib/python3.9/site-packages/yeelight/aio.py", line 36, in wrapper
    cmd = await self.async_send_command(
  File "/usr/local/lib/python3.9/site-packages/yeelight/aio.py", line 72, in async_send_command
    response = await asyncio.wait_for(future, TIMEOUT)
  File "/usr/local/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/core.py", line 1511, in catch_exceptions
    await coro_or_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1530, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 209, in handle_service
    await self.hass.helpers.service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 663, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 896, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 700, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 494, in async_handle_light_on_service
    await light.async_turn_on(**filter_turn_on_params(light, params))
  File "/usr/src/homeassistant/homeassistant/components/yeelight/light.py", line 790, in async_turn_on
    await self.async_set_brightness(brightness, duration)
  File "/usr/src/homeassistant/homeassistant/components/yeelight/light.py", line 257, in _async_wrap
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: Timed out when calling async_set_brightness for bulb Shelf lamp at 192.168.1.64: <class 'asyncio.exceptions.TimeoutError'>