Has anyone ever got the set_music command to work on the Yeelights?
It needs to declare a Server + port for the signal income.
My first attempt was to plug a microphone into my Pi and start the command, but didn’t work sadly.
Would have been to easy.
I’ve read that something called “FFT” is needed to interpret frequencies.
Working on it but help is appreciated 
In the meantime I switched to mihome-binding to control my yeelight2, but I would prefer the yeelight-binding, cause then I could also use the alexa yeelight skill and set colors with it.
If I would have some spare time I give it a try.
Alright. In theory it should be working fine, since I am also using it with my Yeelight 2 color bulb without problems. Let me know your experiences, if you had time for testing!
After upgrading to openHAB 2.4 on a Rapsberry I wanted to give this binding another try.
I managed to add the things for a mono (“dolphin”) and color (“wonder”) bulb.
But there are only the brightness channel for “dolphin” / color and colortemperature for “wonder”.
I’m aware that switching off the mono bulb (dolphin) via yeelight app openhab logs it as:
YeelightWhiteLED1_Brightness changed from 14 to 0
So, is it right that there is no switch available?
Untortunately I don’t have the brightness channel for “wonder” - how can one switch this bulb on/off and adjust the brightness? This workaround doesn’t work 
When switching off the “wonder” bulb via yeelight app I got the following output:
2019-01-11 20:53:33.755 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=true, r=255, g=0, b=0, color=16711680, brightness=100, ct=3908, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]
After playing for a while with the yeelight app and openhab sitemap I found out that the color picker item will work as switch.
“Arrow up” turns on the light and “arrow down” turns it off.
So far so good - but how to change the brightness?
Currently my openHAB setup is broken, so I cannot test myself. But:
It is completely intended to only have brightness / color channel available. It the same as used for other bindings like the hue binding afaik.
For the mono dolphin bulb: See the example of the LIFX binding: https://www.openhab.org/addons/bindings/lifx/#demo-items
Switch Kitchen_Toggle { channel="lifx:whitelight:kichen:brightness" }
For the color bulb you should be able to use the brightness slider from the color picker. The linked workaround is supposed to work (maybe it doesn’t). Also see https://www.openhab.org/addons/bindings/hue/#demo-items
Switch Light1_Toggle { channel="hue:0210:1:bulb1:color" }Thanks for your reply. Unfortunately the switch item does not work 
Are there different versions of the Yeelight Binding? I’m using the native one which comes via oH 2.4 binding “market”
I also use the version from the market now, although I am running on the snapshot builds of openHAB. Are you experiencing this with dolphin and color or only color?
I just tested creating a switch item linked to the color channel of my bulb in PaperUI and it worked without problems.
However: Are you using the first or second generation color bulb? I am using the second generation.
I think it’s the fitst generation:
It is. You are only experiencing this with color, dolphin is ok, right? Might be something wrong in the binding then.
I tried again with the switch code.
For the mono bulb it works now - reason could be that it the first attempt there were no space between the bracket.
Switch Mono_Toggle (Gyeelight,Glicht) { channel="yeelight:dolphin:0x000000000xxxxx:brightness" }
Log:
Item 'Mono_Toggle' received command ON
Mono_Toggle predicted to become ON
Mono_Toggle changed from OFF to ON
[INFO ] [light.internal.lib.device.DeviceBase] - ######### this is control command response, don't need to notify status change!
[INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=0, g=0, b=0, color=0, brightness=100, ct=4000, hue=0, sat=0, isFlowing=false, delayOff=-1, mFlowItems=null, mode=null, isMusicOn=false, name=]
[vent.ItemStateChangedEvent] - YeelightWhiteLED1_Brightness changed from 0 to 100
But for the color bulb it doesn’t work:
Switch Color_Toggle (Gyeelight,Glicht) { channel="yeelight:wonder:0x000000000xxxxx:colorTemperature" }
Log:
[ome.event.ItemCommandEvent] - Item 'Color_Toggle' received command ON
[nt.ItemStatePredictedEvent] - Color_Toggle predicted to become ON
[vent.ItemStateChangedEvent] - Color_Toggle changed from OFF to ON
Thanks for testing. What I suggest you to do now:
- Create an issue on GitHub in the openhab2 addons repo with your findings
- If you want you can try setting the logs to give more details, that might help tracking this down
- Wait or
- Try to find the problem in the code yourself and commit it to the addons repo with a PR (if experienced enough)
Thanks. This will hopefully make it easier to track the issue.
Not sure if I’m not kicking a dead horse but:
- You can change hue and saturation of yee using Color channel. Third parameter (brightness, value, whatever) gets silently ignored.
- You can set brightness by sending only one number to the Color channel.
- You can never change anything at all if the bulb is not lit (ON).
I did quite a long research on this since I bought a pile of yeelights and have been having trouble since. Also, it’s not exactly an error of the binding since you can’t do the same even using udp packets sent raw with their own developer’s kit. If I understand the issue correctly, it’s a matter of using RGB instead of HSB as a communication format, while using HSB internally.
Thanks for your investigation! However I think it is possible to turn the bulb on by changing the brightness, correct?
Hi All,
Just opened an issue in git to explore the possibility for adding effect and duration support for yeelight. Any comments/ideas would be helpful.
Thanks,
Joe
1 Like
Yes, that is correct. It’s not possible to turn off yellow light and turn on red light in one go. You will see brief yellow flash.
Also, sometimes the bulbs get lost. From what I have learned, when a bulb is off for a prolonged period of time, it gets “forgotten” by the binding and never rediscovered. But this is purely theoretical, I have no proof, just my reading.
So that might be some points that can be improved for the binding, right?
Indeed. It took me some time to realize you are the one who wrote it, sorry
You will probably have to immitate the brightness handling with two calls - one to change hue and saturation and another one to change brightness afterwards.
Also, there is sometimes loss of brightness info when using Temperature channel but I guess that is the problem of Yee and not the binding. It depends whether you want to simply allow usage or correct the mistakes in Yee design.
Another flaw (I was getting since forever) is that sometimes the bulbs go offline and are never found again (inbox OR the already added things). After restarting whole openHAB, a random set of lights is discovered, so after an infinite restarts, you should be able to find all the lights. If it helps you in any way, homeassistant does not seem to have these issues, maybe you can get some ideas there?
If I can be of any help, feel free to PM me.
I did not write the binding. I just made slight adjustments to it so it could finally get merged into openHAB after the original developer from Yeelight did not respond for about two years and some other unsuccessful attempts from others to get it merged.
Regarding your points I think they can be categorized into bugs/flaws of the binding and problems with the Yeelight design which the binding might be able to circumvent. I encourage you to create issues for them (at least the bugs but also feature requests) on the openHAB addons GitHub repo so there is a place to track them. This will raise a bit more of awareness that the binding still has flaws.
Maybe someone with development skills can then track them down and fix the binding.