was not. is now 
.
1 个赞
Could I get added to the whitelist, please?
MI ID: 1695898683
many thanks
Do we have only 1 failure reported?
APPSCB, perhaps power cycle your bulbs and give it one more go. It’s possible there was a timer or something left over after the update.
Thank you! I have now the last beta version but I have still the same issue
Hello, Still waiting for the beta access… been 3 days since requesting nothing…
My ID is 6242949933
I’ve updated to latest firmware but unfortunately the issue still there
Did to one of my bulbs same result, became unavailable after some time.
Really mystifying. I really thought .62 removal of restart was going to get most of this. It’s of no comfort to you but I’ve had zero issue since .62.
Do you guys block the internet for the bulbs? Currently (since the update) I did not block them and now they seem to work fine. I will block the internet and have a look, if it’s still solved for me…
Hello,
Can I be whitelisted to the beta?
Thanks!
MI ID: 169651806 Server: Germany
Could I get added to the whitelist, please?
MI ID: 1695898683
many thanks
Block internet? why ? No my bulbs are connected on my Ubiquiti AP… and they are not work with Home Assistant with the last beta .62
It’s mostly me that isn’t giving them internet (although I’ve seen a few others mention it). .62 fixed my issues but I’ve been really active on the list looking for the problems the others have and I’m usually mention that I’m oddball in not having internet to them.
This is a bit long winded but there’s some great clues here. Both Yeelight staff and 3rd party application programmers please read through this post. And please take a grain of salt, I’m bullet pointing somethings that may or may not be true of code out there. The bullet points are intended as food for thought.
Writing all my own code I got to thinking “what am I doing different that is working since .62” so I skimmed out some of the 3rd party yeelight stuff in pip (python public libraries). Checking through the python yeelib (2.1.10) and python yeelight (0.5.0) I found a couple of pretty big problems that might help sort this out more.
Applications not implementing the async protocol:
Both of these popular python libraries are treating the Yeelight protocol as a chat protocol rather than a true asynchronous protocol (even though the Yeelib one is actually written in using asyncio). They send a command then read until they find a message that is the response from their command. The problem here is that, when they aren’t sending a command, they are not servicing the socket which means all of the status messages just stack up. In a true asynchronous service the application should always be servicing (reading) messages as they arrive.
I made a bulb ‘hang’ this way:
I opened a connection to a bulb and just left it idle, not reading the socket. Then I looped around sending commands to the bulb. At one point, I drove one my bulbs into the mode where it was performing commands but not sending responses. I can’t create that situation reliably yet but this looks promising.
Two takeaways from this:
-
Yeelight folks, take a look at how you handle a clogged socket. We don’t really want 1 bad actor to be able to interfere with everyone else.
-
Application folks, fix your code so you don’t clog sockets. You must service messages on sockets as they arrive.
Application libraries are assuming sockets are message queues:
Both libraries I looked at make the mistake of assume that they will receive on ‘message’ per read. Sockets are streams, not message queues. I often see 2 messages in a single read. When the bulb sends it’s response code and the update message, if the application doesn’t read them fast enough then the application gets both messages and considers it malformed and continue reading looking for their response which they missed so they are now stuck in their read loop.
And the takeaway from this one
- Application programmers, you need to handle multiple messages on a single read.
Suggestion: have a rcv buffer, when a message comes in append it to the rcv buffer then scan that buffer looking for messages terminated by ‘\r\n’, service them an remove those bytes from the rcv buffer. Loop until “\r\n” is not found and leave whatever data is left in the rcv buffer. It actually is possible, though unlikely, for you get a partial message as well as multiple messages. The socket has no concept of line termination, it’s just a stream.
It has been more than 10 days and out of 8 yeelight II bulbs I am using, only 1 appeared to be unavailable for 2 or 3 times this bulb is the farthest away from the access point (outside house) and signal strength varies between -74 to -76 with 60 to 70 retries per 5 minutes which will cause packet loss on network and probably that’s why this bulb has shown issues.
Other bulbs which are inside the house shows the signal strength around -45 ~ -50 with around 1 or 2 retries per 5 minutes and have not shown any disconnections yet.
I have ubiquiti AC AP and there are around 25 devices connected to it
All the bulb are using Firmware 2.0.6_0051
So anyone who is trying to recreate the problem maybe introduce a lot of packet loss (iptables netem or move bulb to a low signal area) to force bulbs to batch/something else and may reproduce the issue, I will try to do it if I get any free time.
The type of bulb discussed in this thread uses firmware 2.0.6_XXXX not 1.4.2_XXXX. What bulb are you using?
Hi team!
I updated with the latest Beta .65
unfortunately the issue is still present…
Hi, several issues were discussed in this thread. Please specify. Thanks.
Yes of cours.
So, when I reboot my home assistant I just can see my strip yeelight but not my bulbs:
But I have this notification:
It’s surprising because I do not have HomKit
My bulbs Yeelight are in 2.0.6_0065 : not working
My strip Yeelight are in 1.4.2_0050 : works well
You are talking about discovery, as we have mentioned in previous comments, you need to raise this issue to HA team since they didn’t implement the discovery of Yeelight device following our Spec.
1 个赞