Miio and yeelight rgb bulbs behavior

Pedro_Liberal · May 8, 2022, 5:55pm

Hi everyone. This an old post that I created but did not get any traction. Since I’m still having the same issue I’m updating it:

I have the miio binding and a bunch of first gen yeelight Wi-Fi bulbs.
They work mostly fine, but I have one small annoyance with them on the miio binding which I did not have with the Yeelight binding before. If I turn the lights off, immediately after, the brightness value will change from 0 to 100. Karaf simply gets an update, off, light turns off, then the values get updated, the color stays the same, but the brightness changes from 0 to 100. The bulb stays off mind you, so that’s fine, but in the UI the bulbs appear as on. This behavior is … weird, and in google home I see the same behavior, where lights pop back on after turning them off - but the light stays off.

I thought that perhaps one of my automations was acting out, but even with node red killed, I get the same behavior. The lights were reset a bunch of times as well, and I even (unknowingly) upgraded openHAB to v4.0.1 and the issue is still present.

Again, the log console does not show anything aside from the updated values.

Anyone able to help? What more information can I share to try and diagnose this?

@marcel_verpaalen sorry for tagging you, I think I have put my post in the wrong place. If there’s anything else I may provide to help please let me know. Thank you!

stamate_viorel · September 13, 2023, 6:46pm

Sound like a good read for you
https://community.openhab.org/t/autoupdate-a-primer/101509
Try it and post your result here

Pedro_Liberal · September 14, 2023, 1:58pm

Hi! Thank you for the suggestion, I did try it, but no luck. The rgb channel still goes back up to 100

stamate_viorel · September 14, 2023, 2:07pm

then you have better luck with the binding maintener

Pedro_Liberal · September 14, 2023, 4:24pm

I think/hope I tagged him

marcel_verpaalen · September 14, 2023, 8:52pm

The miio binding is somewhat simplistic in the way it deals with the yeelights…
The reported RGB values are simply shown what the lightbulb reports it is without any further ‘smartness’ to look at the values of other parameters like the power.

Maybe it is possible to fix this, there are limited possibilities to change values that are reported by the device in the binding… So help me understand well, the desired logic is to have the RGB all reporting 0 if the power is off, or does the brightness need to be 0?

Note: could be helpful to see the debug log of the binding while switching on & off to see what is your light exactly returning as value.

Pedro_Liberal · September 14, 2023, 10:07pm

Ah, Nice detail you mention.
There’s the behavior I see in the physical world and what I see in the openHAB UI.
In the physical world I send the command OFF and the light turns off. Perfect.
When I turn it back ON, both the color and the brightness are the same as they were before the OFF. That’s perfect.

But in the openHAB UI when I send the command “OFF”, the light goes OFF, the UI changes to OFF too, but then a second later the switch of the rgb color wheel of the UI goes back to ON. That is the issue I’m seeing.

So my expectation is that only the brightness goes to zero. And, when I turn the light back ON it will be back to the same brightness % and color as it was before the off.
Because I tend to keep lights on the same color and brightness levels all the time (weirdly enough, seeing as they are rgb…).
Example:
Light on at yellow 30%
Send command: OFF
Light off.
Send command: ON
Light on at yellow 30%.

Right, let me try that… I think I got it down to the transformation that happens right at the end. Got a bunch of examples too.


22:31:59.993 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Could not identify channel for set_power. Device miio:generic:052BEA9C has 0 commands in queue.
22:32:02.927 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Periodic update for 'miio:generic:052BEA9C' (miio:basic)
22:32:02.929 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Skip refresh of channel delayoff for miio:generic:052BEA9C as it is not linked
22:32:02.931 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Skip refresh of channel colorTemperature for miio:generic:052BEA9C as it is not linked
22:32:02.934 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Skip refresh of channel colorMode for miio:generic:052BEA9C as it is not linked
22:32:02.935 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Skip refresh of channel colorflow for miio:generic:052BEA9C as it is not linked
22:32:02.938 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":9558,"method":"get_prop","params":["power","bright","rgb","name"]} -> 192.168.2.168 (Device: 86764188 token: (removed) Queue: 1).
22:32:02.939 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Custom Refresh for device 'miio:generic:052BEA9C': 0 channels 
22:32:03.005 [DEBUG] [.internal.handler.MiIoAbstractHandler] - Received response for device 052BEA9C type: GET_PROPERTY, result: ["off","98","16448210",""], fullresponse: {"result":["off","98","16448210",""],"id":9558}
22:32:03.007 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Transformed with 'addBrightToHSV': RGB Color "16448210" -> "60.001,16.00000,98" 
22:32:23.332 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Periodic update for 'miio:generic:052BEA9C' (miio:basic)
22:32:23.335 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Skip refresh of channel delayoff for miio:generic:052BEA9C as it is not linked
22:32:23.343 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Skip refresh of channel colorTemperature for miio:generic:052BEA9C as it is not linked
22:32:23.345 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Skip refresh of channel colorMode for miio:generic:052BEA9C as it is not linked
22:32:23.346 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Skip refresh of channel colorflow for miio:generic:052BEA9C as it is not linked
22:32:23.348 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":9559,"method":"get_prop","params":["power","bright","rgb","name"]} -> 192.168.2.168 (Device: 86764188 token: (removed) Queue: 1).
22:32:23.350 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Custom Refresh for device 'miio:generic:052BEA9C': 0 channels 
22:32:23.353 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":9560,"method":"miIO.info","params":[]} -> 192.168.2.168 (Device: 86764188 token: (removed) Queue: 2).
22:32:23.437 [DEBUG] [.internal.handler.MiIoAbstractHandler] - Received response for device 052BEA9C type: GET_PROPERTY, result: ["off","98","16448210",""], fullresponse: {"result":["off","98","16448210",""],"id":9559}
22:32:23.439 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Transformed with 'addBrightToHSV': RGB Color "16448210" -> "60.001,16.00000,98"

Tried it at different brightness levels:

100%


22:42:23.749 [DEBUG] [.internal.handler.MiIoAbstractHandler] - Received response for device 052BEA9C type: GET_PROPERTY, result: ["off","100","16777215",""], fullresponse: {"result":["off","100","16777215",""],"id":9675}
22:42:23.751 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Transformed with 'addBrightToHSV': RGB Color "16777215" -> "0,0,100"

51%


22:43:24.309 [DEBUG] [.internal.handler.MiIoAbstractHandler] - Received response for device 052BEA9C type: GET_PROPERTY, result: ["off","51","8553090",""], fullresponse: {"result":["off","51","8553090",""],"id":9712}
22:43:24.309 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Transformed with 'addBrightToHSV': RGB Color "8553090" -> "0,0,51"

20% ~


22:45:23.752 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":9775,"method":"miIO.info","params":[]} -> 192.168.2.168 (Device: 86764188 token: (removed )
Queue: 2).
22:45:23.803 [DEBUG] [.internal.handler.MiIoAbstractHandler] - Received response for device 052BEA9C type: GET_PROPERTY, result: ["off","18","3026478",""], fullresponse: {"result":["off","18","3026478",""],"id":9774}
22:45:23.804 [DEBUG] [iio.internal.handler.MiIoBasicHandler] - Transformed with 'addBrightToHSV': RGB Color "3026478" -> "0,0,18"

So I may have missed something but this happens after the OFF command and it seems to be what it raising the brightness back up.
Transformed with ‘addBrightToHSV’: RGB Color “16777215” → “0,0,100”

Seems to be restoring the previous values to the light, before the off, at least the brightness levels.
When it does that, the light does stay off in the physical world - but the openHAB UI understands that as the light coming back on and that is my issue, the UI seeing the light on when it’s off (the rgb switch. The normal switch stays off)

Here’s a screenshot. The switches are off and that is correct. But the rgb color wheels below are all “ON” because the brightness value was updated I assume - switches vs control sections

OpenHAB ui screenshot:

marcel_verpaalen · September 15, 2023, 9:38am

you’re lucky

Please try this version of the binding (uninstall the regular binding, add the file to the addon folder) . See if it resolves the issue. It has the logic to put the brightness to 0 in the hsv output when the power is off
https://www.verpaalen.com/openhab2/org.openhab.binding.miio-4.1.0-SNAPSHOT.jar

let me know if this is fixing your issue, than I can push it to github for inclusion

Pedro_Liberal · September 15, 2023, 2:02pm

How come?

I’ve only had 20 minutes to do a quick test, but I believe it’s fixed! Both the openHAB ui and google home now stay off and when on it reverts to the correct brightness values
I’ll try a couple more tests as I have some lights boxed that still apear as on but that might be because the binding does not see them.

Exciting!!

Update : I’ve just rummaged through my boxes and found two additional Yeelight bulbs. Added them and they are working great. Damn I’m happy

marcel_verpaalen · September 17, 2023, 8:44am

that I had just Eclipse open and some time to quickly fix this…

DrRSatzteil · September 27, 2024, 8:52pm

Sorry to dig this out again but I observe pretty much the same thing but only for a rather special device: I have a yeelight pendant light in my dining area which has a main light pointing down at the table and an ambient light pointing at the ceiling (model yeelink.light.ceiling10).

When the ambient light is off, the channels for power and brightness of the main light behave normally. When the ambient light is on however I see the same thing that Pedro reported here earlier: When I switch the main light off the lamp reacts accordingly and the item gets updated to state OFF just to return to the state ON after a second or so (the actual lamp stays off). The same happens with the brightness channel. When I switch off the ambient light only, everything is behaving as expected though.

So apparently the main lamp channels always report ON if any of the lamps (main or ambien) are ON though since there are separate channels for the main and ambient lights they should only report the state of the corresponding light. Is this something that could be fixed or is this a flaw of the device?

marcel_verpaalen · September 30, 2024, 6:20pm

Indeed, by for miio:basic things, default behaviour is that the binding just shows what the device is reporting without any smartlogic applied

The discussed change in the above topic tries to improve the default behaviour by looking at the powerand changes the ‘brighness’ channel accordingly. The ’ linked’ channel name power is hardcoded

From your desciption indeed seems the power is reporting ON if any ofthe lamps are on…
Can you see in the mihome app the 2 lights separately? If yes, maybe there is yet another channel for the main light that I’m not aware of. In that case.

DrRSatzteil · September 30, 2024, 6:30pm

Yes in the app there are two sections with separate power buttons and both of them just reflect the state of the corresponding light (see screenshots).

I also thought it might just be the power switch, but unfortunately the brightness channel of the main lamp behaves the same so this is not really an alternative.

DrRSatzteil · October 2, 2024, 7:17am

These logs are not related I guess. I see these on OH startup (also for other yeelights):


2024-10-02 03:23:04.896 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'miio:generic:177DB39D' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2024-10-02 03:23:04.897 [WARN ] [core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'miio:generic:177DB39D': {thing/channel=Type description miio:YEELINK_LIGHT_CEILING10_power for miio:generic:177DB39D:power not found, although we checked the presence before.}

Pedro_Liberal · October 3, 2024, 7:56am

I don’t have much to add to the discussion aside from the fact that after you applied the change I requested my lights have been working without an issue since then!

(Except for the fact that two have dropped out of the network and refuse to sync again, regardless if I use mobile data, another router, or any other method, but that’s besides the point! XD)

So once again thank you very much!