music mode will be aborted if you turn off the bulb. toggle command is an automatic power on/off, therefore it will break the music channel if you “toggle the light off”.
I have adjusted my logic to handle such a case; therefore the bed lamp doesn’t turn off the music mode so it’s inconsistent across your products ;-).
As you said, indeed, I have noticed this thing this morning that music mode is turn off when it’s power off or toggle (to off), but therefore, it’s pity that set_rgb doesn’t turn it to black (power off without really turning off the bulb).
Also, notice that if you are pushing the music mode to fast to the bulb/stripe (after your turning off the device to dim light to black) you are crashing them forcing your to power off / power off manually. It is what produces for me timeout of the bulb, now following this limitation it avoids it.
The workaround of that is to respect a window of 150ms (for the bulb) / 200ms (for the stripe) before you are sending back the instruction.
I really believe you should follow one of these two implementations
- Option 1, allow set_rgb to dim more the light to reach even “black” which mean no color
- Option 2, an additional music mode parameter to make it persistent:
set_music 0: turn off music mode
set_music: 1: turn on music mode (power down device will turn off mode)
set_music: 2: turn on persistent mode (mode has to be manually turned off)
A small edit, to notify you about your documentation (https://www.yeelight.com/download/Yeelight_Inter-Operation_Spec.pdf) that is not accurate to your current statement:
NOTE: When control device wants to start music mode, it needs start a TCP server firstly and then call “set_music” command to let the device know the IP and Port of the TCP listen socket. After received the command, LED device will try to connect the specified peer address. If the TCP connection can be established successfully, then control device could send all supported commands through this channel without limit to simulate any music effect. The control device can stop music mode by explicitly send a stop command or just by closing the socket.
Thank you for your support,
In order to reproduce the issue you described, we downloaded home-assistant and run it successfully in VirtualBox. The management portal is working, however, I can’t find how to enable Yeelight plugin (or addon). Please give us some hint.
I can help on wechat if you would like? wechat id: danedwards_fin
Yeelight component is already on Home assistant.
If it is not finding your bulbs automatically. You can add them to your configuration.yaml like this, obviously with the bulb IP
yeelight: devices: 192.168.1.25: name: Living Room
This should force Home Assistant to try to connect to the bulb, without discovering it automatically.
Also I found these messages in the error logs
Unable to update device 192.168.10.196, Bedroom: Bulb closed the connection. 1:51 PM components/yeelight/__init__.py (ERROR) - message first occured at 1:40 AM and shows up 26 times Unable to update device 192.168.10.138, Entrance: Bulb closed the connection. 1:49 PM components/yeelight/__init__.py (ERROR) - message first occured at 1:25 AM and shows up 25 times Unable to update device 192.168.10.196, Bedroom: A socket error occurred when sending the command. 1:46 PM components/yeelight/__init__.py (ERROR) - message first occured at 1:18 AM and shows up 11 times Unable to update device 192.168.10.69, Living room: Bulb closed the connection. 1:10 PM components/yeelight/__init__.py (ERROR) - message first occured at 1:57 AM and shows up 17 times Unable to update device 192.168.10.138, Entrance: A socket error occurred when sending the command. 11:56 AM components/yeelight/__init__.py (ERROR) - message first occured at 4:31 AM and shows up 8 times Unable to update device 192.168.10.69, Living room: A socket error occurred when sending the command. 11:28 AM components/yeelight/__init__.py (ERROR) - message first occured at 1:21 AM and shows up 12 times
More info here:
I have been debugging with @weiwei for a few hours now and have made progress.
I will be running an update overnight to test stability and if they stay connected. Looks promising right now.
I’ll report back tomorrow.
For who may want to try it out earlier, the mentioned patch is included in beta version 2.0.6_0054.
I have the same problem and want to try the beta, please whitelist 1838416723 (mainland China)
MI ID: 1894820299
I would like to test v 2.0.6_0054, can you please add me to the whitelist?
Thanks to everyone for trying to resolve this problem!
MI ID: 1906418033
I would like to test v 2.0.6_0054, can you please add me to the whitelist?
Tried since the firmware published 12 hours ago, however it only appeared in home assistant for 2-3 hours and changed to not available.
Noticed it also caused home assistant having issue connect to mijia hub. After remove the yeelight from HA this will back to normal.(not sure is this same issue from Yeelight?)
I have the same problem (i use Home assistant) BUT only if i cut out the yeelights from the internet (lan mode enabled)! I had every 20 minutes errors from the 4 Yeelights stripes and 2 Bulbs (which had the homekit update) - after i put the yeelight back to let them talk to the cloud (which is not my intention) they put no more errors in the logs!
Why can‘t we use them offline with no problems?? I hate those cloud based things…
Hey, I am a Domoticz user and also having problems after firmware upgrade. Please downgrade me. MI ID: 1595636961.
Yeelight is really messed up my IoT… now i have to keep on reboot my Mi gateway to make it available. I don’t know which day i will get mad and smash the light.
Time to switch to Hue light maybe
Calm down dude.
Tell us about your setup. Are you using autodiscovery or manually adding your bulbs to Home Assistant?
Also, the mi gateway shouldn’t have anything to do with yeelight wifi bulbs from what I understand.
Before that I’m using autodiscovery, after the firmware upgrade everything break.
So i setup manually with ignore discovery of yeelight. The manual setup will only make the light available in HA for 1-2 hours. After that just show me light not available.
I also have the light mapped to the gateway of course, when i turn on the light from gateway, it just some time no response, or keep on & off the light multiple times. When I try to manage my other staff in gateway, they will not respond, the only way is to power cycle the gateway…
Hi, my bulbs are not exposed to the internet i use lan-mode in all my home automation.
I am experiencing the same problem as KoltesPunti my bulbs with firmware 2.0.6_0051 are going on and offline, at some point thy become unavailable that i have to power cycle the bulbs to turn on.
this morning i exposed the bulbs to the internet it looks like they are working fine for now .(this is not my intention i want to keep home automation of the internet)
Bulbs with firmware v 1.4.2_0038 are experiencing no problems.
Yeelight is it possible to make firmware v 1.4.2_0038 available so we can downgrade from 2.0.6_0051?
Kind regards. S
ilya@irt:/data$ telnet 192.168.1.40 55443 Trying 192.168.1.40... Connected to 192.168.1.40. Escape character is '^]'. ^]quit telnet> quit Connection closed. ilya@irt:/data$ telnet 192.168.1.43 55443 Trying 192.168.1.43... Connected to 192.168.1.43. Escape character is '^]'. ^]quit telnet> quit Connection closed. ilya@irt:/data$ telnet 192.168.1.41 55443 Trying 192.168.1.41... ilya@irt:/data$ telnet 192.168.1.42 55443 Trying 192.168.1.42... ilya@irt:/data$
192.168.1.40, 192.168.1.43 - ceiling lights.
192.168.1.41, 192.168.1.42 - Yeelight Color Bulbs with latest firmware [2.0.6_0051]
All lights have Lan Control enabled.
Yeelight team, what else do you need to publish updated and fixed firmware?
If you really think, that “there could be a slim chance that incorrect development version was exposed to your device”, so fix it with firmware update pushed to all our devices as soon as possible.