RFC: Introduce yeelight discovery by SSDP on a non standard port (1982) #193
Conversation
|
Previous discussion on yeelight discovery for reference: #59 . To add, I'm not generally a fan of the idea of having X weird implementations & ports. I'm wondering if yeelight people would be responsive wrt. feature requests to add 1) fetching meta information from the bulbs, or 2) adjusting to use standard ssdp port, or 3) adding necessary meta information to mdns payloads, considering they are quite active on their forum. |
|
Wow. It's a hard way to bring the yeelight support forward. |
|
I have the same issue with Ericsson's Mediaroom Set-up-boxes They too use a non standard port (8082) |
|
Have you tried joining the multicast group to see if those devices regularly notify the listeners for availability? I suppose that could be much more feasible than polling X different ports with the requests, but it would require revamping the detection system (which I for one would welcome) to simply listen in the background instead of actively polling. This would facilitate immediate discovery & detection of shutdown, similarly to what I have done here: https://github.com/rytilahti/homeassistant-binarysensor-upnp |
|
Closing this because of #230 |
"Different from SSDP protocol, we choose to send multi-cast messages to port 1982 instead of
standard SSDP port 1900. This is to avoid excessive multi-cast messages being received by
both smart LED and 3rd party devices. It's especially important if the 3rd party device is powerconsumption-sensitive (e.g. smart watch powered by battery)."
cp. http://www.yeelight.com/download/Yeelight_Inter-Operation_Spec.pdf, page 4
The code is untested. I just want to know my approach is fine. The present mDNS discovery of the yeelights isn't sufficient to collect important details about the device capabilities.