Miio and yeelight rgb bulbs behavior

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.

IMG_8209

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!

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

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

then you have better luck with the binding maintener :slight_smile:

I think/hope I tagged him :slight_smile:

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.

1 Like

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:

you’re lucky :slight_smile:

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

1 Like

How come? :slight_smile:

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 :smiley:
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 :slight_smile:

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

1 Like