Would you please white list me. MI 624787947 - US Server
1 个赞
My bad copy paste mistake, correct firmware version is : 2.0.6_0051
I have updated my post with correct version now.
My mistake! 
Hi,
I got a yeelight bulb v1 and a lightstrip.
As i explained some weeks ago, both have the same problem with home assistant : When i switch the color (or the brightness) 4 or 5 times quickly, they become unavailable.
You said me the limit was 60 changes in 60 seconds. 60 should be correct for my use, but 4 or 5 is much too restrictive to use correctly my devices.
I would like to buy 10 others lightstrips and 5 others bulbs to equip the rest of my house, but i won’t buy others yeelight devices while this issue is here. If the bug is’nt fixed quickly, i will have to get philips or innr devices…
Please can you answer about a fix ?
Thank you
Best regards
facing the same problem…please redtube someone help…!!! 
That’s because HA’s implementation is not decent enough. I captured the traffic between HA & Yeelight device once and I found when you issue some command through HA, it will first send “get_prop”, then send the actual command and then “get_prop” again. This means within one minute, you can only do at most 60/3 = 20 commands.
Per our design, if some controller want to know the latest state of the bulb, it should listen for “prop_change” message from bulb instead of keep polling it.
Maybe it’s asked to much, but can you help the devs out?
Here is the code: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/yeelight/light.py
Would be amazing, if you could create a PR for it, so the implementation is finally correct (and people are happy again)
Would you please white list me. 1714047707 - Chinese Server
My bulbs (0062 FW) just became unavailable in Home Assistant after working without issues for about a week.
What’s interesting to note here is that this coincided with my Xiaomi Gateway (which I use for other sensors and switches) also being unreachable from HA at the same time. It wasn’t discovered anymore and I had to power cycle it to get it discovered again.
Could this be related? Perhaps the (unsuccessful) repeated gateway discovery requests by HA in the network also made the bulbs go unavailable, e.g. because they received too many of these messages?
Can you update to build 0065 and see how that goes?
Has anyone else updated to that (0065) version? How is it working for others? Any disconnections or bulbs becoming unavailable on that build? Please report your experiences.
Thanks.
If there is no issue reported then we would release the firmware officially.
@weiwei Please give it a couple of more days, probably at least a week. As we can see sometimes it takes a while before the issue is encountered.
To others, please let it be known if you’re testing the latest firmware (0065) and report back with your results. If you’re not on the latest build please update to participate in testing it.
I’ll update all my bulbs to 0065 tonight and will post an update here if any issue arises.
Some update from me, while using 62 firmware, I decided to flash my router firmware from openwrt to tomatousb. And after tomatousb the issue is gone… Today is my 4th days with tomato firmware with my yeelight uptime since then.
Did you experience any issues with FW 62 when your router was running on OpenWrt?
Yes, it turned not available in HA after few hours of rebooting
What do you mean? Rebooting what?
I couldn’t agree more. I share the goal of “home automation that belongs to the home owner and not wedontcare megacorp” and the understanding that we (particularly those of us with computing skills) have a great part in this.
To end users with skills in other areas, I see your frustration but please do what you can to note any circumstances you may notice. Mentioning anything, no matter how inane, is just fine. I’ve put forth ideas right in this forum that have turned out wrong, oh well, it ticks that idea off the list and we move forward.
I’ve been writing my own stuff here, which at this point, is running very smoothly but is not feature rich. I’ll give home assistant a download and get myself up speed. Hopefully it will be an easy task to load it up in a LXC container, once familiar, there really shouldn’t be anything that can’t be examined closely in the container. Given that I’ve already made so many self educational mistakes in the journey of writing of my own code, I’m hoping those lessons will be applicable.
Re the posted code:
I have posted here before that the communications logic in both the Yeelight and yeelib public libraries are broken (treating the protocol as a chat rather than an asynchronous and treating sockets a message queues rather than streams). I see they are not being used in the posted code, the posted code (at a skim) appears to be mostly the formatting of messages. If it were incorrect it would certainly fail reliably (yeah, I love that term too). As such, I doubt that there is anything in the posted program fragment that would be at issue. So I’ve decided I need to get HA up and running here to help out.
PS. regarding “can be fixed”. Comments about 1% brightness notwithstanding, that probably has more to do with the voltage and pulse width modulation frequency ratios vs heat dissipation although, I admit, I’ve no intimate knowledge of the hardware, I only want to make it clear that I really don’t think these other problems are hardware issues, rather, most likely a software interaction issue.
2 个赞
In my case the automations on Mi Home stopped working with the light bulbs v2.
But for now and after a couple of days with fw .65 everything seems to work as it was doing it on 1.4.2 for me. They don’t stop working after some hours so I don’t need to reset them
Thanks for everyone’s patience and assistance for this issue, we decide to publish the 65 firmware officially soon as there is no issue reported since we released the beta version days ago. Also hereby I want to explain this issue in detail because we think every user suffers from this issue has the right to know it.
Issue was reported after we published the 2.0.x firmware to support Apple Homekit through the newly introduced soft-auth method. This feature brings into 3 major changes: a) Apple’s Bonjour protocol which is built on mdns protocol. b) Internal resource increases since the device need to run one more protocol stack in parallel. c) 2.0 SDK changes, to be specific, the cloud monitor (phone home) thread. The 3 changes bring all the issues we didn’t expect and we hadn’t found in our lab (and also Apple’s lab).
For change a), we removed our old mdns code and stopped announcing “miio.udp” which is exactly HA uses to auto-discover Yeelight devices. In our interworking spec, we clearly state that one SSDP like discover protocol should be used and no other discovery mechanism is promised, therefore, we didn’t make mistake on this one and we think HA should improve on their side.
For change b), this is the major cause of the hang issue. As we are using embedded system instead of “high-level” OS like Linux, all the internal resources need to be fine-tuned. The hang is caused by UDP socket resources and one internal semphore resource problem. If the system once runs out of the semphore, one task just intentionally hang the system and makes the bulb freeze. This is successfully reproduced in our network environment when there are lots of mdns traffic while 4 local TCP clients are connected. After this finding, we published some beta firmware and we did see some improvement. Regarding the UDP socket resource issue, it’s the final one, even now we still can’t reproduce this problem locally, but thanks to our nice and kind user @chrisnwh05 who let us running our test firmware with debugging information on his device, again and again, we were finally able to conclude this problem is caused by UDP resource leakage. One task is opening a UDP socket, but it somehow doesn’t call “recvfrom” when socket is readable, which causes TCP/IP stack running out of UDP buffer. Because UDP is also used internally for command response from main control task to local control task, that’s why you can still command the bulb through HA, but get no response from the bulb. We finally fix this issue by tunning the UDP resource a bit to make it more tolerant under some network environment.
For change c), this is introduced to solve the offline issue frequently reported by mesh router users. For some mesh router, if we don’t bounce the WiFi interface intentionally when the bulb switches from mesh node A to B, the bulb can never be online again. We didn’t expect lots of users would block their internet traffic for the bulb and the lesson is that we need to think twice before introducing the behavior change next time. This logic is removed from the new firmware.
That’s basically the entire story and issue analysis and we apologize for our mistakes. We also want to say thanks to all our users who are always supportive.
5 个赞