Another connection issue thread with lots of research and will to help and test!

Hey there,

I know this is probably the 5000th issue in the forum about the connection issues with Yeelights and right from the start I also have to say: I’m so close to smash all of my lights, if these issues won’t be fixed.

So first: I am using the lamps with Home Assistant (HA), which made me aware how often these issues occur. But if a lamp is offline in HA, it’s also offline in the Yeelight app. So let’s not talk about the Yeelight app.
So like many people, I see multiple issues with my Yeelights, ending up in two different main issues:

1. Constant flapping state in Home Assistant: A bulb or Ceiling light suddenly gets unavailable in HA and then comes back the next scan interval, so ~30 seconds after.
2. Bulbs getting completely unresponsive, but still showing up in my router as connected device, but you can’t even Telnet to them. You have to power off and on. No way it ever comes back on its own

These are all my Yeelights / Mi Lights:

• 3x Color bulbs (color2)
• 2x Mi bedside Lamp 2 (bslamp2)
• 2x Ceiling lights (YLXD42YL)
• 1x Ceiling light (YLXD50YL)
• 1x Pendant Light (ceiling10)

The most painful are actually the Mi Bedside lamps: They go on/offline like every 5 minutes!!

Let’s start with #1:
Also as many people already posted, I can see this happening in the HA logs every few minutes:
2020-11-13 15:58:42 ERROR (SyncWorker_37) [homeassistant.components.yeelight] Unable to update device 192.168.178.35, [Bedroom] Bedside Lamp Andy: Bulb closed the connection.
or
2020-11-13 00:35:04 ERROR (SyncWorker_17) [homeassistant.components.yeelight] Unable to update device 192.168.178.35, [Bedroom] Bedside Lamp Andy: A socket error occurred when sending the command.

I also tried to do a simple Python script that uses the Yeelight Python library to simply open a socket connection and listen to events. The events come in and work but after like 3-5 minutes the socket connection goes stale; not a single event comes in anymore. Also no exception is happening, but that can be because I might not handle the exceptions well in my little test script. But ultimately, it’s the same HA sees: The “socket connection just breaks” (I don’t know how to correctly phrase that, as I don’t know what’s actually happening).

I’ve spend so much time to really knowing that it is 100% not my Wi-Fi:
That’s my Wi-Fi setup:

• Router: Fritz!Box 7530
  • The Fritz!Box is located pretty much in the middle of my 85qm² apartment
• Two TP-Link Powerline adapters, newest Gen, 1300MBit (effectively doing only 300-600, but whatever…).
  • They broadcast the same SSID as the router

What I did to ensure it is not my Wi-Fi:

• Removed all powerline adapters to ensure it’s not them: Issues still happening
• Bought two Fritz! 1300 Wi-Fi repeaters and have them instead of the powerline: Issues still happening
• Bought a complete new router(!!!): Issues still happening
• Back to my Fritz!Box and placing a Bedside lamp literally 1m away from the Fritz!Box: Issues still happening

It’s not my Wi-Fi. It is the Yeelight firmware or hardware. And again: even though I performed the tests only with a Bedside lamp, all lamps have this same issue #1. The Bedside lamps are just crazy insane with it.

Another issue I’m seeing mainly with the color bulbs, but also with the ceiling and pendant lights (not that much with the bedside lamps though. Actually not sure if I ever saw that happening for them), is:

Issue #2:
The bulbs go completely unresponsive, but still having a Wi-Fi connection: My Fritz!Box lists them as being actively connected. Over hours and days if I don’t do anything to them. But neither HA can connect to them, nor can I do a simple Telnet!
Look at this screen where I try to telnet to two color2 bulbs (.40 and .44, which are still listed as being actively connected in my Fritz!Box backend), but fail to connect. But another bulb (.37) works. I just did the connection to .37 to showcase that this telnet is actually working, if the bulb would respond:

image1673×625 61.6 KB

One thing I realized though was, that with the new router I (temporarily) bought, the issues were happening way less than before. So I thought what it might be, because it can’t be the signal strength: Remember the Bedside lamp next to the router.
I realized that I (as a kind of fan of privacy) have denied Internet access for all my smart devices in my home, incl. the Yeelights. And they don’t need to have internet access, as they all have LAN mode active and purely communicate locally through my HA. And that works, if they don’t decide to have connection issues all the time.
So I allowed internet access again for them and WOULD YOU LOOK AT THAT: The issues reduced by 90%! They are still happening but waaaaay less. Actually: #2 I have not seen yet with internet access activated. But #1 still happens, but again: way less.

So my conclusion is that all Yeelights at least hate it to not have internet, which is absolutely, utterly ridiculous!! Especially, if you offer a LAN mode, there is not a single reason for internet access, except Yeelight wanting to know if my lights are on or off!

But again: These issues still happen with internet access allowed so this is either not the only reason, or they keep to loose the connection for… god knows why.

I’m of course on the newest firmware 2.0.1. something or 2.1… I don’t know anymore and honestly: It doesn’t matter. This happens since 1.8 at least…

I’m really happy to try out debug builds you send me or anything else how I could help getting rid of these issues. I’m a developer, I’m quite experienced with a few things, incl the ESP8266 modules you’re using and the ESP tool to flash them. So I hope I can be a valuable resource of help to get this fixed!

At least: Do not require internet access / Do not have the lights restart (or whatever they do) if they can’t reach your servers!!

I really, really want to get this fixed finally. I spend so much money and work and time into these Yeelights and I like their look & feel. It would be a shame to dump them all and buy new ones…

Greetings,

Andy!

That is really strange. I have so many Yeelight devices, like several 1st gen bulbs, both withe and color, 2nd gen both tunable white and color, Led strip plus, ceiling 650 and 480, bat heater (which also has light) and filament bulb.

When you read posts here, a lot of people have problems. I had problems with my old router (ASUS RT12N) but since I bought Asus RT56 I have almost never experienced any disconnects!

Sometimes Xiaomi cloud is slow and unresponsive, but bulbs never go offline.

Since I bought all my stuff from different sellers it can;t be that I’m just lucky. It has to be something in router settings or the router. But I have internet enabled.

Some tips:

1. Have separate SSIDs for 2.4 and 5Ghz
2. Don’t use special characters or spaces in SSID name
3. Don’t use special characters or spaces in password
4. Don’t use WPA3
5. Don’t block internet
6. Use fixed IP addresses (reservations) for all smart home devices
7. Use Google DNS (8.8.8.8)
8. If possible, use separate router/access point for your smart home (don’t mix with PCs, phones etc)
9. Don’t use hidden SSID

D.

Hey @dalanik,

I want to say “thanks” for the reply, but honestly: No. This is nothing near a reply to what I said. This reads like a standard copy/paste reply. All your tips are nothing about my issue, with #5 actually pointing out the issue itself…

To react to it in detail:
#1: I do have that
#2, #3, #4, #9: How should that help? The lights connect to my Wi-Fi just fine, they just loose the connection all the time or reboot or whatever they do. So it’s not about anything about SSID or encryption/password.
#5: This is literally my main complaint! Why would they need internet in LAN mode?? And as I pointed out: They also have these connection issues with internet allowed, just less often.
#6: I also do have that
#7: I kinda do: I have a local DNS that filters ads and malicious / phishing links (“pi-hole”) but then forwards to Google DNS. But it does nothing to “normal” DNS requests. I also soo the DNS requests from the lights in there all the time being forwarded just fine. But the issues already existed before I had the pi-hole, so that doesn’t change anything. And again: This is my main complaint: The devices don’t need to resolve any non-local DNS names, if they are in LAN mode, so they don’t need Google DNS!
#8: I don’t have that, but the lights also have these issues at night, so they go unavailable all the time even when everybody sleeps and nothing is using the Wi-Fi, except my smart devices, incl. the Yeelights. So this won’t help either.

So I’m still offering to help with a build that fixes these constant unavailability issues. I can flash them to the light myself, if it can’t be done using the Yeelight app (like giving my account a special build). That said. Yes of course, I can give the lights internet for pulling a new build via the Yeelight app, no problem.

And I’m still hoping for an official reply if this is being investigated or absolutely unwanted. Then I will happily move on from Yeelights.
And again: It’s also happening if they have internet, just less often! So this is not only about “no internet access”

Thanks again and greetings,

Andy!

We discussed it in other threats. It seems that by whatever reason lights periodically (several times a day) drop IP and try to get it back from DHCP. In most cases - successfully (that is your 30 sec drops), but some times not. And if not - then you need to physically restart the lamp. That’s why any assignment of static IP from router - means nothing. Same as all other advises that @dalanik mentioned. At that moment light just cannot communicate with any server/service.
As I see the easiest solution - to allow users to do manual assignment of IP, or fixing this problem in firmware, but …

Hey @com_wolf,

ou that’s interesting! That could actually explain why they get unavailable even with internet and why they sometimes get completely stuck.
That it’s 30 seconds is actually how HA / the Yeelight discovery inside HA works, as it re-scans every 30 seconds. But yeah, that could be it.

Any official word from a Yeelight person on that?

@ezcGman, previously this question was discussed in this thread 吸顶灯总是掉线 and today I also mentioned same problem here: Why is there no support? and got an answer. Do not know what will be in the result, but who knows.

Currently I managed it through HA. I installed smart switches. And my HA monitors status of the Yeelight lights. In case they do not appear online in 5 minutes it just physically do power off/ power on. And connection restored in most cases. If not - repeat but ofcource it is not a best way to do it.

Hello,

I actually came to find a “solution” for the following errors.

2020-11-13 15:58:42 ERROR (SyncWorker_37) [homeassistant.components.yeelight] Unable to update device 192.168.178.35, [Bedroom] Bedside Lamp Andy: Bulb closed the connection.
or
2020-11-13 00:35:04 ERROR (SyncWorker_17) [homeassistant.components.yeelight] Unable to update device 192.168.178.35, [Bedroom] Bedside Lamp Andy: A socket error occurred when sending the command.

I’m using the Python Yeelight Library to control the bulbs and actually built my own application because I just feel it gives me more flexibility. If I’m not mistaken HomeAssistant and Openhab and other solutions use it too.

Somehow connections seem to get stuck. I was not really curios into checking the entire library and recode the “bad” parts as I’ve found a “quick and sloppy fix” which seems to work and didn’t have any problems for last 2 weeks. So it seems to be a consistent fix.

After sending out a command I just close the socket immediatly so it will never be able to get into error state. It is situated in the send_command function in main.py. It’s marked in the code below. Hopefully it will help you guys.

def send_command(self, method, params=None):
    """
    Send a command to the bulb.

    :param str method:  The name of the method to send.
    :param list params: The list of parameters for the method.

    :raises BulbException: When the bulb indicates an error condition.
    :returns: The response from the bulb.
    """
    command = {"id": self._cmd_id, "method": method, "params": params}

    _LOGGER.debug("%s > %s", self, command)

    try:
        self._socket.send((json.dumps(command) + "\r\n").encode("utf8"))
        **self.__socket.close()**  <------- Insert this into the main.py
    except socket.error as ex:

I also commented out this line

    if "error" in response:
        pass
        #raise BulbException(response["error"]) <----- Comment out this line.

best regards,
Thomas

Hello Dalanik,

No offense,

I will respond to every point from here and prove you that your list down there is total nonsense.

1. Have separate SSIDs for 2.4 and 5Ghz (FALSE)
   (I’m running on dual channel and don’t have any issues, I think the only issue with how Yeelights work for now is if you actually do Router Meshing)
2. Don’t use special characters or spaces in SSID name (FALSE)
   (I have spaces, no issues)
3. Don’t use special characters or spaces in password (FALSE)
   (I have special characters in password, no issues)
4. Don’t use WPA3 (Partially TRUE)
   (never tried, but this could be true, if the firmware does not support WPA3 authentication)
5. Don’t block internet (FALSE)
   (Not true, they work without connecting to internet)
6. Use fixed IP addresses (reservations) for all smart home devices (NOT MANDATORY)
   (That’s not mandatory, they work perfectly on DHCP without reservations)
7. Use Google DNS (8.8.8.8) (FALSE)
   (Why would the DNS make any difference in a Lan Control system which is adressed via local IP not Host Name.)
8. If possible, use separate router/access point for your smart home (FALSE)
   (No, just no. Doesn’t make any sense.)

You should stop posting 87.5% nonsense which is preventing users from finding real solutions for their problems.

best regards,
Thomas

OK, you have problems, I don’t. Go fix them yourself if you’re such a smart ass. And i like your “arguments” (doesn’t make any sense - woooow, that is a proof!)

100%

Thanks, do now know how to use it right now, but will consider for next steps.

Thanks for this, btw. While I think commenting out the throwing of the exception is not helpful, because that’s just ignoring the issue The force closing of the socket may fix it. It’s not nice, but what do you do if the Yeelights just can’t handle longer running socket connections. I’ll give it a try!

That’s why I said it’s a quick and sloppy solution.
But for me it works for using all the basic functionalities.
Power, Colour, Brightness, Temperature, Flows.
In my usage scenarios I don’t need to keep sockets open.

Thank you for leaving with your useless information Dalanim

yeah same. Using a differnt / own fork of the yeelight py lib is not so trivial with hassio. I did a quick look, but didn’t yet find an easy way. Maybe with a custom component that ships directly with the py lib… Will give it a try the next days.

However @Yeelight: This still doesn’t solve the initial issue and I would still appreciate any feedback to my initial post! Thanks!

Hello,
I actually came to discover something interesting.

Telnet works perfectly fine with commands which do an action. Like Power ON and Power OFF.
But when trying {“id”: 100000000, “method”: “get_prop”, “params”: [“power”, “bright”]}
it will just not answer.

Yeelight Team, any ideas?

best regards,
Thomas

This is interesting, though we failed to reproduce. How does this issue happen? Does it happen the moment you telnet to it or after some exchange of commands and responses? When the device failed to response to ‘get_prop’, did ‘set_prop’ have any effect on the device, and did it send back any response message?

Hi, Andy. Sorry for all the troubles and pains you’ve gone through. We are working to understand and find a solution for the issues you mentioned.

It seems the key issue here is, bulbs go offline much more easily when internet access was cut off. Althrough the main intention of LAN mode was not to let the device run cloud-less, but to allow 3rd party integrations, the bulbs should not behave like that (go offline).
We will try reproduce in our lab and find a solution. Be back soon.

As for the HA issue. We are not aware how the HA pluggin works as we did not develop that. Something may ring a bell is that as a method of traffic-control, the bulbs only allows 60 requests per minute. Does the HA flood a bunch of requests to the bulb by any chance before it complained connect loss? Or does HA have any tuning of TCP layer, like changing the keepalive parameters? Does HA read from the socket from time to time even when it’s not sending any requests? It could cause congestion in the bulbs sending queue which in time affects all traffic when bulbs’ (very limited) memory runs out.

Your Wi-Fi setup is of no significance to this issue, I do agree

Hello,

let me answer step by step.
First of all I want to say that I’m really happy with those bulbs. From how the light looks, the connectivity, the multiple commands we can use, built-in Wifi. This lights are far better than many of their competitors.

How does this issue happen?
Reproduction is fairly easy.

1. Open up 4 terminals to same bulb and test get_prop command on each terminal. Works fine
2. Now open a 5th connection which gets refused as per documentation. Close Terminal
3. Close all other 4 terminals
4. Open up a new terminal and get_prop will not work anymore. All other commands work fine.

So I think somehow the connection limit function within the firmware is somehow making the response for get_prop return either and empty string or none/null.

SET_PROP works fine as all other commands.
set_prop returns {“id”:100000000, “error”:{“code”:-1, “message”:“method not supported”}}

This is also what makes Bulbs become unavaible in Homeassistant, thus making all people cry on the forum.
Homeassistant executes this command (get_prop) and waits for response in order to show lights available.
I was able to work my way around this by changing the part with get_prop and actually use SSDP disovery to get the properties which works fine.

I’m not writing on this forum because I can’t get past the issues, but because there are much people which don’t have either the technical knowledge or time to get past this issue.
If you are able to change this part in the firmware people will be very very happy and you won’t have the forum clogged with topics regarding homeassitant.

best regards,
Thomas

Hello,

the rate is not what is affecting Homeassistant.
Homeassistant is opening up a socket and listening to it. It is not asking from time to time for changes in the bulb, it just gets them. So means it just sends 1 single command at startup/initial connections.
Everytime it changes the light it sends 1 command, not multiple.

So there is no way it send more than 60 commands per minute, except when there’s somebody pressing the buttons like crazy.

There is also no changes in keepalive parameters which could flood the connection.

best regards,
Thomas Barbut