Core: Yeelight: Bulb closed the connection. (Yeelight 1S YLDP13YL color4)
The problem
Getting lots of errors in logs regarding light connection. Lights turn on/off for a split second periodically at random intervals. Voice assistants sometimes say they are unable to control the lights. Have a strong wifi signal; doesn't seem to be a LAN issue.
Using latest Yeelight 1S color bulbs YLDP13YL. Device model name: color4 (not listed in integration page)
Environment
- Home Assistant Core release with the issue: 0.109.3
- Last working Home Assistant Core release (if known):
- Operating environment (Home Assistant/Supervised/Docker/venv): Supervised
- Integration causing this issue: Yeelight
- Link to integration documentation on our website: https://www.home-assistant.io/integrations/yeelight
Problem-relevant configuration.yaml
discovery:
ignore:
- yeelight
yeelight:
devices:
192.168.0.12:
name: Desktop Light
192.168.0.13:
name: Living Room Light
192.168.0.14:
name: Kitchen Light
192.168.0.15:
name: Bedroom Light
Traceback/Error logs
Log Details (ERROR)
Logger: homeassistant.components.yeelight
Source: components/yeelight/__init__.py:160
Integration: Yeelight (documentation, issues)
First occurred: May 2, 2020, 9:23:37 PM (136 occurrences)
Last logged: 12:03:45 PM
Unable to update device 192.168.0.13, Living Room Light: Bulb closed the connection.
Unable to update device 192.168.0.14, Kitchen Light: Bulb closed the connection.
Unable to update device 192.168.0.15, Bedroom Light: Bulb closed the connection.
Unable to update device 192.168.0.13, Living Room Light: A socket error occurred when sending the command.
Additional information
Have not attempted to turn off Music Mode connection method, but would rather keep that on so 60 commands per minute limit is bypassed. (edit: Default state of integration does not use Music Mode)
Using stock firmware which is 1.3.2_0018. Latest firmware I can update to is 2.0.6_0027 but I'm wary of updating because I hear many complaints of connection/color accuracy issues with newest firmware?
Hukuma1
All 67 comments
yeelight documentation
yeelight source
(message by IssueLinks)
![probot-home-assistant[bot] picture](https://avatars2.githubusercontent.com/in/36093?v=4&s=40)
probot-home-assistant[bot]
on 4 May 2020
Hey there @rytilahti, @zewelor, mind taking a look at this issue as its been labeled with a integration (yeelight) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)
probot-home-assistant[bot]
on 4 May 2020
Correction: Was never using music mode. (didn't realize default setting is music mode off)
Even updated router to a robust OpenWRT setup. Still same issue.
Hukuma1
on 13 May 2020
Same issue here as well.
ceesvanegmond
on 13 May 2020
Same issue here as well, also with
Yeelight JIAOYUE YLXD02YL 650
perseus177
on 17 May 2020
Can you all also please post your firmware versions for your devices? Just curious if same issues happening and you're on latest fw.
Hukuma1
on 17 May 2020
Seeing this as well. Have got fairly solid wifi and have actually replaced wifi with a ubiquti access point. I use zigbee switches for them but I haven't seen any delay.
It seemed to be working far better in the past and nothing had really changed bar updating firmware/updating HA.
Seeing a lot of this in the logs
Unable to update device yee-bedroomstrip, Strip2: Bulb closed the connection.
Unable to update device yee-kitchen1, Light2: A socket error occurred when sending the command.
Unable to update device yee-lounge1, Light5: A socket error occurred when sending the command.
Unable to update device yee-gym1, Gym Light 1: A socket error occurred when sending the command.
Unable to update device yee-ensuite, Light1: A socket error occurred when sending the command.
V2 bulbs are at 2.0.6_0065
V1 bulbs are at 1.4.2_0076
Critical-Impact
on 19 May 2020
same here. Aso using unifi and ubiquiti stuff. All my b2 bulbs are on latest version which is 2.0.6_0065
ceesvanegmond
on 19 May 2020
Got it after update to 110
Logger: homeassistant.components.yeelight
Source: components/yeelight/__init__.py:160
Integration: Yeelight (documentation, issues)
First occurred: 19:26:53 (83 occurrences)
Last logged: 20:38:07
Unable to update device 192.168.50.243, Моя спальня: Bulb closed the connection.
Worked fine in 109.
PS Problem was fixed by physical reset yeelight.
kukachik
on 22 May 2020
Resetting yeelight isn't working here. Constant I get this error:
'A socket error occurred when sending the command.'
ceesvanegmond
on 26 May 2020
Home Assistant 0.110.3
2020-05-26 07:38:05 ERROR (SyncWorker_16) [homeassistant.components.yeelight] Unable to update device 192.168.1.17, Bedroom Wall Light Left: Bulb closed the connection.
2020-05-26 08:09:04 ERROR (SyncWorker_6) [homeassistant.components.yeelight] Unable to update device 192.168.1.17, Bedroom Wall Light Left: Bulb closed the connection.
2020-05-26 08:10:31 ERROR (SyncWorker_6) [homeassistant.components.yeelight] Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
2020-05-26 08:31:10 ERROR (SyncWorker_3) [homeassistant.components.yeelight] Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
2020-05-26 08:37:51 ERROR (SyncWorker_0) [homeassistant.components.yeelight] Unable to update device 192.168.1.16, Bedroom Light: A socket error occurred when sending the command.
2020-05-26 08:39:24 ERROR (SyncWorker_17) [homeassistant.components.yeelight] Unable to update device 192.168.1.16, Bedroom Light: A socket error occurred when sending the command.
2020-05-26 08:42:04 ERROR (SyncWorker_16) [homeassistant.components.yeelight] Unable to update device 192.168.1.16, Bedroom Light: Bulb closed the connection.
2020-05-26 09:17:44 ERROR (SyncWorker_17) [homeassistant.components.yeelight] Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
2020-05-26 10:11:55 ERROR (SyncWorker_2) [homeassistant.components.yeelight] Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
2020-05-26 10:27:23 ERROR (SyncWorker_5) [homeassistant.components.yeelight] Unable to update device 192.168.1.17, Bedroom Wall Light Left: Bulb closed the connection.
2020-05-26 10:30:54 ERROR (SyncWorker_7) [homeassistant.components.yeelight] Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
2020-05-26 10:41:11 ERROR (SyncWorker_11) [homeassistant.components.yeelight] Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
2020-05-26 10:44:54 ERROR (SyncWorker_8) [homeassistant.components.yeelight] Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
2020-05-26 10:49:56 ERROR (SyncWorker_5) [homeassistant.components.yeelight] Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
2020-05-26 11:34:23 ERROR (SyncWorker_14) [homeassistant.components.yeelight] Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
2020-05-26 11:53:59 ERROR (SyncWorker_9) [homeassistant.components.yeelight] Unable to update device 192.168.1.17, Bedroom Wall Light Left: Bulb closed the connection.
2020-05-26 12:07:47 ERROR (SyncWorker_11) [homeassistant.components.yeelight] Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
2020-05-26 12:14:36 ERROR (SyncWorker_1) [homeassistant.components.yeelight] Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
2020-05-26 12:34:14 ERROR (SyncWorker_12) [homeassistant.components.yeelight] Unable to update device 192.168.1.17, Bedroom Wall Light Left: Bulb closed the connection.
2020-05-26 12:37:20 ERROR (SyncWorker_17) [homeassistant.components.yeelight] Unable to update device 192.168.1.17, Bedroom Wall Light Left: Bulb closed the connection.
2020-05-26 13:06:13 ERROR (SyncWorker_4) [homeassistant.components.yeelight] Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
2020-05-26 13:12:50 ERROR (SyncWorker_4) [homeassistant.components.yeelight] Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
2020-05-26 13:13:27 ERROR (SyncWorker_10) [homeassistant.components.yeelight] Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
2020-05-26 13:21:37 ERROR (SyncWorker_7) [homeassistant.components.yeelight] Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
2020-05-26 13:31:31 ERROR (SyncWorker_1) [homeassistant.components.yeelight] Unable to update device 192.168.1.17, Bedroom Wall Light Left: Bulb closed the connection.
2020-05-26 14:17:24 ERROR (SyncWorker_9) [homeassistant.components.yeelight] Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
Did you enable the LAN mode after reseting the bulb? Does yeecli work on the devices?
rytilahti
on 26 May 2020
I can only speak for myself but I have LAN mode on on all devices. The issue I'm getting is intermittent. Basically I turn a light on and it might take a few seconds for it to come on. Then if I switch it on and off and works fine. Come back 30 minutes to an hour later and the switch again is delayed.
I'm getting those same messages in the log.
Critical-Impact
on 27 May 2020
LAN mode is on. yeecli works fine. The issue is the bulb just breaks connection and would sometimes drop commands if you catch it in that broken state I assume. Firmware issue I'm guessing. :/
root@DietPi:~# yee --ip=192.168.1.14 toggle
Toggling the bulb...
root@DietPi:~# yee --ip=192.168.1.14 toggle
Toggling the bulb...
root@DietPi:~# yee --ip=192.168.1.14 turn on
Turning the bulb on...
root@DietPi:~# yee --ip=192.168.1.14 rgb ff00ff
Setting the bulb to RGB ff00ff...
root@DietPi:~# yee --ip=192.168.1.14 brightness 100
Setting the bulb to 100 brightness...
root@DietPi:~# yee --ip=192.168.1.14 toggle
Toggling the bulb...
Yeah same here yeelink.light.color4 firmware 1.3.2_0018
ekozan
on 27 May 2020
Any chance someone can take a look into if it's because the Yeelight phones home (China) and maybe a latency issue of some sort? I'm in the US. Wondering if ultimately an emulated Yeelight cloud of sorts has to be implemented to keep the cloud completely contained to your network. I don't think LAN mode routes all Yeelight traffic to stay local.
Hukuma1
on 2 Jun 2020
@Hukuma1 That's not the issue. I've blocked all outgoing connections of Yeelight and I'm having the same issues. Also when not blocking the connection = same problem.
ceesvanegmond
on 3 Jun 2020
Yikes. So even Wiresharking packets would be useless to further debug this?
Hukuma1
on 3 Jun 2020
@Hukuma1 I don't know man. I'm not that technical. Its so a weird error. Dont know what to do with it. U have Ubiquiti stuff as well?
ceesvanegmond
on 7 Jun 2020
I've got a Ubiquiti AP acting as my only wireless
I've been able to fix this myself by doing a few things(not sure which actually fixed the errors).
1) Make sure the 2.4ghz and 5ghz APs have different names
2) Make sure the 2.4ghz AP has a specific channel set rather than being on auto. I'm thinking maybe the lights don't like to switch channels and ubiquiti has some sort of channel switching built in?
3) Disabled a brother printer integration I had as I generally had the printer offline and it was spamming errors in the log
Critical-Impact
on 10 Jun 2020
I don't have a Ubiquiti device. But I do have a merged 2.4/5ghz network name. Could that really be it? Will also try keeping constant channel.
Will report back if this changes anything. Thanks!
Hukuma1
on 10 Jun 2020
I don't have a Ubiquiti device. But I do have a merged 2.4/5ghz network name. Could that really be it?
I've been using that for the past years and it hasn't caused issues on my end.
Yesterday I upgraded to 0.111 which was not working properly (for me) so I reverted back to 0.110.7.
However, after that all of my Yeelight devices (a bulb, the bedside lights & the meteorite) were all showing up as "Unavailable" in HA and the "Bulb has closed the connection" message in the logs.
Powercycling the bulbs didn't work just like keeping one offline for a few hours. Result is that all bulbs still show as unavailable.
The strange thing is that it works just fine in the Yeelight app and even with this:
from yeelight import Bulb
bulb = Bulb("192.168.110.12")
bulb.turn_on()
'ok'
The bulb turns on just fine. turn_off works too. get_properties() shows all attributes. This uses the very same Yeelight library as HASS is so I would assume there is something wrong in that part?
My desk light is acting up too:
>>> from yeelight import Bulb
>>> bulb = Bulb("192.168.110.27")
>>> bulb.turn_on()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<decorator-gen-7>", line 2, in turn_on
File "/srv/hass/lib/python3.8/site-packages/yeelight/main.py", line 128, in _command
result = self.send_command(method, params).get("result", [])
File "/srv/hass/lib/python3.8/site-packages/yeelight/main.py", line 455, in send_command
raise BulbException(response["error"])
yeelight.main.BulbException: Bulb closed the connection.
>>> bulb.turn_off()
'ok'
>>> bulb.turn_on()
'ok'
>>> bulb.turn_off()
'ok'
The part where it gave the "closed connection" message it still turned on. Could it be that the component considers the bulb unavailable when it gets one of the closed connections and simply doesn't attempt querying it again?
Edit:
Actually, I think I'm on to something here! I simply deleted the entities from HASS and restarted. Afterwards my devices show up fine and are controllable again. So ISTM that something in the entity store has been corrupted.
syphernl
on 11 Jun 2020
I can add that following Yeelight upgrade to version 2.x, I have had a lot of problems. It seems that when the devices are blocked from accessing the internet, they ignore DHCP lease times, and renew every five minutes. When they renew (without altering their IP, and still responding to ping) the Yeelight devices "disappear" from HA for a few seconds, and then return, with a "device closed connection" log message. I have had to open their Internet access (which I do not like) just to work around this, because every five minutes is intolerable to me...
ezaton
on 15 Jun 2020
I had mine start dropping out again and I think it's possible by Ubiquiti configuration reset. I noticed that turning "Enable multicast enhancement (IGMPv3)" on appeared to make all the lights work properly again. Not sure if there is an equivalent for other routers/wifi.
Critical-Impact
on 1 Jul 2020
I'm also having issues with V2 bulbs (2.0.6_0065) similar to what others are reporting. Bulbs constantly unavailable and disappearing.
Varjo1
on 2 Jul 2020
Same issue here with model yeelink.light.color4, MAC ADDR begins with 44:23:7C...
I have 2 others yeelink.light.color4 that are working perfectly, (those one the MAC ADDR begins with 5C:E5...)
All those lights are using 2.0.6_0065 firmware.
yeecli works, tried to hard reset the faulty bulb, the issue is still here.
Bashy
on 5 Jul 2020
yea, same here. yeelink.link.color4
Happens a lot, makes setting up scenes an absolute pain in the butt. If this is a firmware issue, please let us know, so we can contact yeelight's support and annoy them into fixing their shit :D
Edit
I dug through a huge Yeelight forum thread where they apparently managed to fix the issue. They released version 2.0.6_0065 of the firmware. However, it seems that our light bulbs (Model YLDP13YL) didn't get the update and now we're stuck on 2.0.6_0027 until Yeelight finally fixes their shit...
Updating to 2.0.6_0027 at least fixed the wifi drop-outs for me. Unfortunately, they still become unavailable every now and then (every 2 hours, it seems...).
Observations:
_The bug(s) mainly affects the model YLDP13YL (at least for me)_
- After updating to 2.0.6_0027 the bulbs stay connected to wifi (before that, they lost wifi connection entirely)
- Auto-Discovery doesn't work anymore Reason
- The bulbs become unavailable for roughly 30 seconds while showing this error message
Unable to update device 192.168.178.69, Couch Light: A socket error occurred when sending the command.
3:45:05 PM – Yeelight (ERROR)
- Sending too many commands in a short period of time causes the same behavior with a different error message
Unable to update device 192.168.178.69, Couch Light: {'code': -1, 'message': 'client quota exceeded'}
4:31:11 PM – Yeelight (ERROR)
Note
I had to change the server region to mainland China in order for the app to show the firmware update (2.0.6_0027).
david-kalbermatten
on 18 Jul 2020
@david-kalbermatten Firmware 2.0.6_0027 messes with HomeKit brightness. You cannot achieve same level of brightness unless you fire up Yeelight app. I have reported the issue over 2 months ago and they assured me I would be added to beta firmware whitelist. At this rate they'll release a new version bulb and not even fix this one. As seems to be the case of the V2 bulbs before 1S came out. Very annoyed. Wish someone would hack the firmware on these. The hardware is very capable, the software is so buggy.
Hukuma1
on 22 Jul 2020
@Hukuma1 yea, it's a shame. Fortunately, I was still able to RMA it and got myself a LIFX mini bulb. More expensive, but damn does it work smoothly with Home Assistant. The brightness and color saturation are still unrivaled :D
imho, it's worth to spend the extra on LIFX and have something that works properly. Just having the rate limit for LAN control with Yeelight is a deal-breaker already.
david-kalbermatten
on 22 Jul 2020
Got the same issues with pretty much all of my yeelight products. LED strip, ceiling lights, pendant light.
Wish there was some sort of esphome for yeelight bulbs to flash it with custom firmware and stop those issues once and for all
flamewow
on 30 Jul 2020
Everyone that’s having issues, I opened a ticket with creator of Yeelight-CLI. Could you please help debug in case this is something that can be patched up on that end? (Still unsure if the issue is HA, YCLI, or firmware right now, so trying to narrow it down since HA devs here haven’t chimed in for a long while...)
Hukuma1
on 30 Jul 2020
The real upstream for the library used by homeassistant is here https://gitlab.com/stavros/python-yeelight . Looks like yeelight-cli is rust implementation of the API, but I recall reading somewhere (a post by @stavros of python-yeelight fame) that this is likely a firmware issue on those bulbs.
It could potentially be beneficial to make the python-yeelight logging on socket errors more verbose, at least to give out what sort of socket error it got. Any takers? The relevant part is here, I think: https://gitlab.com/stavros/python-yeelight/-/blob/master/yeelight/main.py#L452
rytilahti
on 30 Jul 2020
Ah oops, mixed up my Yeelight libraries. Looks like this is the firmware issue in question: https://gitlab.com/stavros/python-yeelight/-/issues/37
Those list firmware 2.0.6_0051. I've got bulbs with factory 1.3.2_0018 and 1 that got updated to 2.0.6_0027. People above in this thread wrote that 2.0.6_0065 seems to be the magic firmware that fixes their issues. Unfortunately not every bulb has this firmware available to update to? :/
@rytilahti I think you may have tagged the wrong Stavros? But thank you for linking to the correct Yeelight library!
Hukuma1
on 1 Aug 2020
Ah yep, I'm the proper Stavros, though the other one is a friend. I have debugged this, the bulb just never returns a confirmation and the library waits until it times out.
I think I have a workaround in mind, I might be able to implement it in a few days, though if someone wants to try it out before that, please do:
We should be able to send an "info" command after every command, and the latter should always return a response (it did in my testing). Then, all the library needs to do is ignore the second confirmation and return normally.
skorokithakis
on 2 Aug 2020
I'm not a coder, but I could easily try to help running whatever commands you want. If you could just please provide a step-by-step of what to try, I can paste the outcome from my testing as well. Thanks for the quick reply!
Hukuma1
on 2 Aug 2020
I don't remember the commands off the top of my head now, unfortunately, but it's basically sending one command, the carriage return/line feed combo, then immediately a second command with another crlf.
skorokithakis
on 2 Aug 2020
Gotcha. Will wait if there's a test build once you have a chance and report back to what my bulbs do.
Hukuma1
on 2 Aug 2020
I have a potential fix:
diff --git a/yeelight/main.py b/yeelight/main.py
index f446626..adb7291 100644
--- a/yeelight/main.py
+++ b/yeelight/main.py
@@ -494,7 +494,8 @@ class Bulb(object):
_LOGGER.debug("%s > %s", self, command)
try:
- self._socket.send((json.dumps(command) + "\r\n").encode("utf8"))
+ cmd = json.dumps(command) + "\r\n" + '{"id": 0, "method": "get_prop", "params": []}\r\n'
+ self._socket.send((cmd).encode("utf8"))
except socket.error as ex:
# Some error occurred, remove this socket in hopes that we can later
# create a new one.
Can someone with a bulb that doesn't currently work perform the following steps?
- Use whatever yeelight library you have now, or install the latest one.
- Try to toggle the bulb.
- Verify that the "bulb closed the connection" error is thrown.
- Apply the above patch to your yeelight installation.
- Try to toggle the bulb again.
- Verify that the error is not thrown.
All my bulbs work so I can't really test this, I'd appreciate help if anyone has a broken bulb.
skorokithakis
on 3 Aug 2020
Thanks, @skorokithakis! Made the file change and here's the log:
root@DietPi:~# yee --ip=192.168.1.16 toggle
Toggling the bulb...
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/yeelight/main.py", line 448, in s end_command
self._socket.send((cmd).encode("utf8"))
File "/usr/local/lib/python3.7/dist-packages/yeelight/main.py", line 242, in _ socket
self.__socket.connect((self._ip, self._port))
socket.timeout: timed out
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/bin/yee", line 10, in <module>
sys.exit(cli())
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 829, in __ca ll__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 1259, in inv oke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 1066, in inv oke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 610, in invo ke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/yeecli/cli.py", line 147, in togg le
bulb.toggle()
File "<decorator-gen-9>", line 2, in toggle
File "/usr/local/lib/python3.7/dist-packages/yeelight/main.py", line 125, in _ command
result = self.send_command(method, params).get("result", [])
File "/usr/local/lib/python3.7/dist-packages/yeelight/main.py", line 454, in s end_command
raise_from(BulbException("A socket error occurred when sending the command." ), ex)
File "/usr/local/lib/python3.7/dist-packages/future/utils/__init__.py", line 4 03, in raise_from
exec(execstr, myglobals, mylocals)
File "<string>", line 1, in <module>
yeelight.main.BulbException: A socket error occurred when sending the command.
Finally got around to issuing command on an unresponsive bulb. I did have to re-start the bulb from the socket to get it to be responsive again. But hopefully the above gives some more info.
Hukuma1
on 8 Aug 2020
Hmm, thanks @Hukuma1. Did the bulb actually toggle?
skorokithakis
on 9 Aug 2020
It did not. :/
Hukuma1
on 9 Aug 2020
Try the same command without the change? It should toggle with or without the change, I'm wondering if the bulb was frozen or something. Even when you get the original error, the bulb still responds to the command, no?
skorokithakis
on 9 Aug 2020
Without the change it just sits and doesn't say anything else. This happened to a bulb that I didn't even need to restart from the socket. It became 'available' shortly after and then the toggle worked again.
root@DietPi:~# yee --ip=192.168.1.16 toggle
Toggling the bulb...
It doesn't say "bulb closed the connection"?
skorokithakis
on 9 Aug 2020
Nothing in terminal when using yeecli. I get a bunch of those in logs from HA:
Unable to turn the bulb on: Bulb closed the connection.
5:39:56 PM – Yeelight (ERROR)
and
Unable to update device 192.168.1.18, Bedroom Wall Light Right: Bulb closed the connection.
Unable to update device 192.168.1.12, Desktop Light Left: Bulb closed the connection.
Unable to update device 192.168.1.14, Living Room Light: Bulb closed the connection.
Unable to update device 192.168.1.12, Desktop Light Left: A socket error occurred when sending the command.
Unable to update device 192.168.1.15, Kitchen Light: Bulb closed the connection.
@skorokithakis - I am facing the same issue with the yeelight bulbs on HA. So, I am interested to find a solution to this.
On my macOS, I installed your yeecli using pip and tried yee --ip=192.168.2.209 toggle (without making any changes to the code in the packages). I got almost exactly the same error posted by @Hukuma1 . The bulbs do not toggle.
Toggling the bulb...
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/yeelight/main.py", line 447, in send_command
self._socket.send((json.dumps(command) + "\r\n").encode("utf8"))
File "/usr/local/lib/python3.7/site-packages/yeelight/main.py", line 242, in _socket
self.__socket.connect((self._ip, self._port))
socket.timeout: timed out
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/bin/yee", line 8, in <module>
sys.exit(cli())
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/yeecli/cli.py", line 147, in toggle
bulb.toggle()
File "<decorator-gen-9>", line 2, in toggle
File "/usr/local/lib/python3.7/site-packages/yeelight/main.py", line 125, in _command
result = self.send_command(method, params).get("result", [])
File "/usr/local/lib/python3.7/site-packages/yeelight/main.py", line 453, in send_command
raise_from(BulbException("A socket error occurred when sending the command."), ex)
File "/usr/local/lib/python3.7/site-packages/future/utils/__init__.py", line 403, in raise_from
exec(execstr, myglobals, mylocals)
File "<string>", line 1, in <module>
yeelight.main.BulbException: A socket error occurred when sending the command.
The yeelight bulbs work perfectly with the Yeelight app, and they are all on the 2.0.6_0065 firmware (v2 bulbs).
Please let me know if there is anything I could do to help troubleshoot.
t-anjan
on 9 Aug 2020
Could you apply the patch upthread and try the command again, and let me know what happens? Thanks!
skorokithakis
on 9 Aug 2020
Should I make the changes in the /usr/local/lib/python3.7/site-packages/yeelight/main.py file?
========= UPDATE ===============
I made the change in the above file and re-ran the same toggle command. But I got the same error.
Toggling the bulb...
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/yeelight/main.py", line 449, in send_command
self._socket.send((cmd).encode("utf8"))
File "/usr/local/lib/python3.7/site-packages/yeelight/main.py", line 242, in _socket
self.__socket.connect((self._ip, self._port))
socket.timeout: timed out
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/bin/yee", line 8, in <module>
sys.exit(cli())
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/yeecli/cli.py", line 147, in toggle
bulb.toggle()
File "<decorator-gen-9>", line 2, in toggle
File "/usr/local/lib/python3.7/site-packages/yeelight/main.py", line 125, in _command
result = self.send_command(method, params).get("result", [])
File "/usr/local/lib/python3.7/site-packages/yeelight/main.py", line 455, in send_command
raise_from(BulbException("A socket error occurred when sending the command."), ex)
File "/usr/local/lib/python3.7/site-packages/future/utils/__init__.py", line 403, in raise_from
exec(execstr, myglobals, mylocals)
File "<string>", line 1, in <module>
yeelight.main.BulbException: A socket error occurred when sending the command.
I wonder if it is because of 2.4GHz vs 5GHz WiFi. My MacBook is connected to the 5GHz AC wifi, while the bulbs (I am guessing) are connected to the 2.4GHz 802.11 "n" WiFi. The SSID and password are the same for both frequencies.
t-anjan
on 9 Aug 2020
I got 2.4/5 wifi with same credentials for both as well. But it technically shouldn't matter since the bulbs can only connect to 2.4, right?
Hukuma1
on 9 Aug 2020
Yeah, that shouldn't matter. It's odd that it's timing out, since all it's doing is sending an extra command. It should just execute both, that's what it was doing in my own tests.
skorokithakis
on 10 Aug 2020
Can you all check your Uptime that's listed by Yeelight app itself for the devices?
I'm thinking the devices simply turn off frequently (on older firmware). On my older firmware I see uptime of 2 hours right now. Will check later today to see if it resets. On newer firmware a bulb is saying 951 hours. However that can't be truly accurate since I had a power surge/outage last week. So not sure how a bulb could have uptime of almost 40 days with that (no UPS).
Edit: Does Yeecli have ability to see the same info? Uptime?
Edit 2: Yep, just saw one lightbulb flicker and unavail and then checked uptime. Now 17 minutes. (older firmware)
Hukuma1
on 10 Aug 2020
The uptime on all my Yeelight bulbs are being reported correctly in the Yeelight app. I have been monitoring it and it also updates correctly when I check after a few minutes.
t-anjan
on 14 Aug 2020
@t-anjan Are you experiencing the disconnecting issues that show up in HA logs like the people above?
e.g. Unable to update device 192.168.0.13, Living Room Light: Bulb closed the connection.
Hukuma1
on 14 Aug 2020
Yes, I do see a lot of such errors:
Unable to update device 192.168.2.210, yeelight-guest-br-twin-1: Bulb closed the connection.
Unable to update device 192.168.2.210, yeelight-guest-br-twin-1: A socket error occurred when sending the command.
=================
UPDATE:
So, I turned off all 6 of my yeelight bulbs and changed the static DHCP allocation to use completely new IP addresses (just to start from scratch). Turned them back on. Now, the yee CLI toggle command is working reliably. Even without the change suggested by @skorokithakis . No error messages on my command line.
Still, the bulbs are not detected in Home Assistant. Both automatic discovery and manual discovery not working. Not sure what is happening and how to fix it.
t-anjan
on 15 Aug 2020
Still, the bulbs are not detected in Home Assistant. Both automatic discovery and manual discovery not working. Not sure what is happening and how to fix it.
Are you on newer firmware?
"It now uses custom SSDP-like discovery instead of the mDNS discovery since mDNS discovery is removed in new firmware (#26574)"
Hukuma1
on 15 Aug 2020
I'm also having this issue, fairly new to Home Assistant but I'm getting the bulbs go unavailable throughout the day:
A socket error occurred when sending the command.
jjbrunton
on 24 Aug 2020
Are you on newer firmware?
"It now uses custom SSDP-like discovery instead of the mDNS discovery since mDNS discovery is removed in new firmware (#26574)"
37191
@Hukuma1 - If I have configured the bulbs manually in the HA configuration, using the manual Yeelight setup, does it really matter if the "discovery" is working or not? Shouldn't HA just pick up the bulb IP addresses from the configuration files and send commands to it? It does not need to "discover" the bulbs, right?
t-anjan
on 25 Aug 2020
I am noticing the same issue this week - latest firmware
k-rock
on 1 Sep 2020
Same here issues started about 4 days ago on rgb v1 and v2 latest firmware (0065 and 0072), bulb closed connection, did reset, changed servers - no luck
cpuks
on 14 Sep 2020
My DeskLamp started few days ago, too; it constantly closes the connection, but then it's available in HA again without intervention from my side. Maybe interesting part: the loss of connection re-occurs nearly every 8 minutes.
Unable to update device 192.168.2.205, Desk Lamp: Bulb closed the connection.
4:58:10 PM – Yeelight (ERROR) - message first occurred at 11:03:09 AM and shows up 48 times
sysadmama
on 21 Sep 2020
I've been having similar issues as @sysadmama I believe.
I have connected two yeelight bulbs (1S Color) on HA. Yeelights are on latest firmware (as reported by the app): 1.3.2_0018.
While the bulbs are open, they randomly flash (close and then open again). HA Reports loosing connection:
9:32:08 PM Yeelight Living Room 1 turned on
9:31:43 PM Yeelight Living Room 1 changed to unavailable
9:27:38 PM Yeelight Living Room 3 turned on
9:27:13 PM Yeelight Living Room 3 changed to unavailable
9:20:08 PM Yeelight Living Room 1 turned on
9:19:43 PM Yeelight Living Room 1 changed to unavailable
9:09:08 PM Yeelight Living Room 3 turned on
9:08:43 PM Yeelight Living Room 3 changed to unavailable
thanpolas
on 21 Sep 2020
fwiw it appears Xiaomi staff have confirmed the issue and promised to issue a new firmware for Yeelight S1 lights "soon": https://forum.yeelight.com/t/topic/20100
thanpolas
on 22 Sep 2020
Soon is today for me I guess. USA server. I'm seeing an update to version 2.0.6_0030. Was brave enough to update only 1 bulb so far (the one that was previously on 2.0.6_0027).
Changelog states:
- Optimize light effect.
- Optimizing network stability.
Fingers crossed. Anyone else update? Will report back to see if there are any changes to connectivity.
Possibly this update also has Razer Chroma integration that will be announced tomorrow at Razer's event. While that's neat, I really hope the disconnection issues are fixed once and for all. ;)
Btw @thanpolas beware, once you update past your initial factory 1.3.2_0018 firmware you will lose some brightness. If possible, can you please check wattage output of the bulb? I know they're rated at 8.5w, but when I plugged in my factory firmware ones they do over 11w at the wall. Once I upgraded to 2.x firmware the watts went down to 8 and I'm assuming that's how brightness fell too. :P What I really wish someone could do is test if the lumen output fell below advertised 800 rating now because of that... (or if lumen output was higher than 800 at factory firmware)
Hukuma1
on 10 Oct 2020
Found a related issue. Originally I thought it was only for specific firmware/models, but it seems gradually all Yeelight models are affected as firmware changes: https://github.com/home-assistant/core/issues/26186
New firmware Yeelight 1S 2.0.6_0030:
Old firmware Yeelight 1S 1.3.2_0018:
The new firmware bulb always seems to be responsive via Yeelight app though. So next I'm going to try to simply bypass HA and see if I ever have issues via HomeKit/telnet directly. I know Yeelight said it was a Home Assistant issue at one point, wondering if something else changed or if the issue is on BOTH ends.
Hukuma1
on 11 Oct 2020
For anyone using pfSense + pfblockerNG I found that having "Register DHCP leases in the DNS Resolver" enabled would basically cause the lights to drop out due to a loss of DNS resolution. I've got other lights that are from lifx that do not have the same issue though it's possible they handle the loss of DNS resolution more gracefully.
From my understanding the issue arises when a device attempts to connect to the wireless, it gets added to the DNS resolver and the DNS resolver restarts. When restarting and pfblockerNG has it's list of blocked domains in the DNS resolver it'll actually take a few seconds for the reboot. This means there is a period where DNS resolution fails and I guess the lights have a fit?
This is probably not a common case but what set me off to investigate this was loss of DNS resolution on a wired PC. It suggested to me something was rebooting the DNS resolver.
Critical-Impact
on 13 Nov 2020
Blocking internet will cause it to release and renew DHCP every 5 minutes. Tried it with firewall rule on internet. LAN access worked from HA. Yeelight app showed both lights as offline. Then I startet getting:
2020-11-13 11:40:34 ERROR (SyncWorker_63) [homeassistant.components.yeelight] Unable to update device 10.0.107.31, yeelight_ceiling10_0x00000000065b8886: Bulb closed the connection.
When I disabled firewall rule, all was back to normal. Maybe I blocked too much? Anyone knows exactly what to block? I also have Pi Hole and tried few Xiaomi/Yeelight lists, but cloud was still working.
I can see in Pi Hole that it is trying to reach de.ots.io.mi.com and de.ot.io.mi.com.
thehijacker
on 13 Nov 2020
Py
ffffaaasl
on 27 Nov 2020
Related issues
arangates
·
3Comments
flsabourin
·
3Comments
YellowMonster76
·
3Comments
i-am-shodan
·
3Comments
sibbl
·
3Comments