I have 2 bulbs v1.
The 2 of them have firmware: 2.0.6_0029
I don’t see any update at Germany server neither China server.
Any help ?
Hi weiwei and thanks a lot for the update and detailed explanation, as a developer it is always nice to be informed about lessons learned!
Is Apple’s Bonjour then completely removed, or just replaced with a newer implementation? If the latter, the most straightforward fix for HA would be to leverage the new mdns advertisements. See also my answer below wrt. “misusing” mdns.
To be fair, yeelight integration for homeassistant is already a bit aged and from the time homeassistant was very young. In the old times there was no sane way to support custom discovery protocols, so that’s why the the _miio._udp was used as it was simple enough and provided enough basic information. The implementation was very simple: https://github.com/home-assistant/netdisco/blob/master/netdisco/discoverables/yeelight.py
However, now that it is possible to introduce custom discovery protocols to homeassistant, it is just implementation effort that is holding back using the custom discovery. If the regular SSDP would be used, then this would be a really simple adjustment (Integration manifest | Home Assistant Developer Docs) so that’s why I have been pestering about it.
That being said, leveraging python-yeelight’s discovery is not that big deal either, it’s merely lack of man power that is holding it back. It will be made in the near future though, if no one steps up I’m going to make it happen.
I like to think that yeelight devices are favored by many due to that possibility. I know I do – it was thanks to your local API and freely available API docs that I got my first bulbs years ago.
I think this is the music mode, right?
@scampbell if you want to contribute, one potential starting point would be to to improve the backend library and its support for music mode, see Implement a notification system (#4) · Issues · Stavros Korokithakis / python-yeelight · GitLab .
“prop_change” is reported to each connected clients whenever there is some property changing. For example, if the lights is off, then “toggle” command make it on and meanwhile each socket will get prop_change method from the bulb with key = power, value = on.
Regarding Apple’s Bonjour protocol, we didn’t remove it. Actually in order to support Homekit, we introduce this protocol and use a totally new mdns stack. What we do remove is the miio.udp service in our mdns since it’s no longer used by our App.
For the discovery method, since all our products are already used the customized & simplified SSDP-like protocol, if we want to change it, we need to publish maybe over 50 firmware updates, that would be the nightmare for our dev & testing team and we really can’t afford that effort. For HA integration, if you don’t have enough resource to do that, we could help.
Ok, so this is https://gitlab.com/stavros/python-yeelight/issues/4 . That’s definitely a better way than polling the device and I hope we will have that in the near future for HA.
Ok, great! Homekit detection should also be easier to integrate than the custom, so I’ll look into that first. Homeassistant uses only the type of the light and the IP address of the device at the moment. Should 1.4.2_0076 (RGB bulb, yeelink-light-color1) be homekit enabled, or is it just for newer devices / is this FW too old? I just upgraded, but I’m only seeing the old miio.udp service.
edit: updated my bedside light (yeelink-light-bslamp1) to 1.6.6_0172, but the same thing applies.
Fair enough, that would be too much indeed. I will see how the homekit discovery protocol looks like and see if we can make use of it (i.e., do we get enough information directly). Otherwise we will fallback to using the custom SSDP-like protocol. What could be helpful to know is if details of the device are queryable via homekit discovery, or is the SSDP-like a better choice for that? Type of the bulb (i.e., what features it supports, RGB or not) and a unique ID (like id in SSDP announcement) would be necessary.
I’m gettting myself up to speed. Installing in a container went smoothly (I think I installed like 5 times until I was able to do it with no stumbles, took less than an hour to get up and running).
It’s not music mode, nor is it actually the notification messages (those are broadcast messages and are infrequent). It data coming in asynchronously from the (As I see the server to bulb connection is maintained open) connection. It’s possible HA already facilities to handle this, I’m in learning curve right now. Music mode will be more interesting because the trick will be to pair an incoming connection to it’s request (or whatever is applicable in HA). I’ll catch up soon.
I just updated to .51 and looking for the changelog I found this thread. I only updated one of four of my bulbs. What’s the ETA for official .65 final firmware? I’m on United States server.
In a week.
Only devices with Homekit supported will announce Bonjour services, color1 & bslamp1 doesn’t support Homekit due to resource limitation.
The SSDP-like protocol is actually very easy and simple. It does contain enough information to help identify the device. For example, the response to discover request contains device ID which is unique across all our devices, it also contains all the method this device supports, it also contains the ip and port the bulb is listening on. Please check the interworking spec for more details.
3 个赞
Ah, makes sense, so that won’t work in this case, so the SSDP-like is the one we should be using.
Yes, I’m familiar with the discovery protocol, and it itself is supported by the upstream library. There is one problem though: the ID is not available via the API (i.e. without discovery), so this would close the ability to use statically configured IP addresses inside homeassistant, which is useful for those having their devices in different networks than where the discovery process is running. Also, some HA users also prefer to simply use static IP addresses to avoid any sort of discovery processes for various reasons, so removing that functionality is a no-go for us.
That being said, I just did some testing and from the looks of it the discovery stack on my devices will also answer to unicast discovery calls (as mandated by the SSDP spec, but not stated explicitly in the yeelight spec), which seems to be a promising way to make this work (i.e., we could send a discovery on all statically configured bulbs). Could you confirm if we can expect this to work on the whole range of yeelight products? Because if yes, my next steps will be to start making the necessary changes across the stack to make it happen 
1 个赞
Hi,
Could you please whitelist my ID for firmware. 65?
1904782641
Thank you.
The same problem here. The latest firmware available is 2.0.6_0029
Telnet connection to 55443 is closed within few minutes.
Which additional tests may help?
And, btw, at some moments bulb is available in HA, but not available in yeelight app, at some times vice versa.
Could you also add me to the beta group?
MI ID: 4165917779
Server Russia
Thank you!
Could I get added to the whitelist, please?
MI ID: 1585813037
Many thanks
Ah, I see your point. I can confirm that unicast address can also take the discover request and send response.
2 个赞
Hello,
Could you please add me to whitelist?
ID = 1600523622
Can you please add me to the whitelist as well?
ID: 1889255637
I’ve run into the same issue with the FW update not cooperating with HomeAssistant. It’s troubling that homekit discovery in HA cannot be disabled or sequence of discovery controlled (as it seems once homekit discovers unpaired devices, yeelight HA component does not enumerate same homekit devices) … but that’s not a topic for these forums.
That being said, I want to thank @baroudeur for a workaround to at least bring the lightbulbs back into HA and be usable, later timeouts notwithstanding. At least the house is back up and running to a large degree.
Also, I would like to thank @weiwei for stepping in and owning the problem like I’ve never seen a manufacturer do before. 
Makes me like these products even more despite current challenges. I am looking forward to the fix.
1 个赞
I mean power cycle the yeelight. So anyone here using openwrt without problem? I miss the feature in openwrt…
Can you please add me to the whitelist as well?
ID: 1763341038