Skip to content
This repository has been archived by the owner on Oct 1, 2021. It is now read-only.

How do you want me to approach Yeelight bulbs? #59

Closed
jjensn opened this issue Oct 27, 2016 · 5 comments
Closed

How do you want me to approach Yeelight bulbs? #59

jjensn opened this issue Oct 27, 2016 · 5 comments

Comments

@jjensn
Copy link
Contributor

jjensn commented Oct 27, 2016

Hi,

Yeelight bulbs listen on a different port for SSDP callouts (1982 vs 1900).

M-SEARCH * HTTP/1.1\r\n HOST: 239.255.255.250:1982\r\n MAN: "ssdp:discover"\r\n ST: wifi_bulb\r\n

And they respond:

HTTP/1.1 200 OK\r\n Cache-Control: max-age=3600\r\n Date:\r\n Ext:\r\n Location: yeelight://192.168.1.239:55443\r\n Server: POSIX UPnP/1.0 YGLC/1\r\n id: 0x000000000015243f\r\n model: color\r\n fw_ver: 18\r\n support: get_prop set_default set_power toggle set_bright start_cf stop_cf set_scene cron_add cron_get cron_del set_ct_abx set_rgb\r\n power: on\r\n bright: 100\r\n color_mode: 2\r\n ct: 4000\r\n rgb: 16711680\r\n hue: 100\r\n sat: 35\r\n name: my_bulb

So, while it kind of works like normal SSDP, it doesn't follow many standards.

Instead of adding a bunch of if code to support the bulbs in the ssdp.py module, I made a separate module. The thing is, most of the code comes from the ssdp module, just with minor changes.

If there was an interest in adding auto-discovery support for these bulbs, how would you want to approach it?

Here's the PR if you are interested in what I've added: https://github.com/peeepers/netdisco/commit/c5d3dbbfdc2004e50e2ec87117060c834a92e66e

@balloob
Copy link
Collaborator

balloob commented Oct 27, 2016

It looks like Netdisco will end up with a collection of all the poor engineering choises in the world 😢

Anyway, you're right in not hacking SSDP but add it as a standalone. Make sure it is clearly described why it is not inside SSDP in the module description . Also remove all reference to the name SSDP to prevent confusion.

@balloob
Copy link
Collaborator

balloob commented Oct 27, 2016

It should also not re-use any SSDP discoverable etc

@rytilahti
Copy link
Contributor

I created #77 which uses mDNS instead of SSDP. This however doesn't allow detecting the supported features among other metadata which is sadly available only through SSDP.

@jjensn
Copy link
Contributor Author

jjensn commented Dec 18, 2016

I think your changes are far more elegant than mine. The Yeelight python module that does the heavy lifting queries the bulb API, so I don't think it matters if the discovery part doesnt get a list of features

@rytilahti
Copy link
Contributor

Agreed, we can let the library do that. We can get the type of the bulb from its hostname which is now reported onwards.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants