Support for different UDP port used for SSDP multicast messages

[perisdr]

Hello,

Just wanted to ask if it would be a valid request to be able to define the port for multicast messages manually. The default port for SSDP is 1900 but the manufacturer of the device I wish to discover listens to 1982 port. As he states in his documentation:

Different from SSDP protocol, we choose to send multicast messages to port 1982 instead of standard SSDP port 1900. This is to avoid excessive multicast messages being received by both smart LED and 3rd party devices. It's especially important if the 3rd party device is power consumption sensitive (e.g. smart watch powered by battery).

I don't know if this is a common practice manufacturers decide to follow, but I am unable to use RSSDP because of that port decision. I didn't find anything in the source code that enables me to override the multicast port. Nevertheless as I stated that is the decision of a single manufacturer, that knowingly decided to differentiate from the SSDP protocol, so I am not sure if such a change to RSSDP would be worth it.

If you consider that adding the port as another user defined parameter does not offer any significant value, please close this issue.

Thank you

[Yortw]

Hi,

At the moment this isn't configurable, in theory it would be possible to change it though I haven't looked in detail. Is the port the only issue you have, or are there other differences too? What kind of devices are you trying to use this with?

See #48 for a prior discussion on this.

[Yortw]

Just to follow up, the Yeelight stuff has different schema, different protocol, and different port. At that point just changing the port in RSSDP isn't going to help much. Yes, you would be able to search for the device, but you wouldn't be able to download or deserialise the device description document due to the custom protocol/document format, and none of the publishing stuff would work. A fork of this library specifically for Yeelight and with appropriate changes made for the devices seems best if all that is true, but I am not planning one. Happy for you or someone else to do so.

If all you need is to be able to change the port, then that's a different story and maybe something I can do in RSSDP.

[perisdr]

Thank you Troy. #48 issue is exactly my case. This is my first time playing with SSDP, so I didn't realize that yeelight was different in more ways than just the port. I did change the port in the source code, but I still haven't been able to communicate with the lamp. Too bad, what could have been a walk in the park, suddenly needs re-eventing the wheel. I was under the impression that yeelight was implementing SSDP for the discovering/advertising part, before setting a TCP connection with the lamp for actually controlling it.

I will run a few tests to see what I can reuse from RSSDP awesomesauce.

[Yortw]

No problem. I really don't why they changed from the standard. SSDP already has protections in it to prevent overload from the UDP packets. Even if they did have a problem there, (apparently) abandoning the device description document format and using a custom protocol to retrieve it all breaks the standard significantly.

The good news is that, as far as search goes, a lot of the stuff in RSSDP should be reusable. After changing the port in use, it should be a matter of downloading the doc using the custom protocol and deserialising whatever they give you into sensible objects. The rest of the stuff should work, but I have none of these devices to test with.

Let me know if I can help further.

[perisdr]

Just a small follow up for anyone interested. I gave some feedback to the yeelight devs, who I must say are very eager in helping in every way. When I asked for future versions to support the proper SSDP standard, they gave some explanation around their decision for a custom protocol

Thanks for your comments and feedbacks!

Before we decide to develop the open API, we did some research. The result is: a full SSDP protocol implementation is too heavy for a embedded system, e.g. a WiFi bulb. The resource on a SoC is too constraint, the free RAM is normally around 6~8K in some low-end product. If too much SSDP packages are being received, it will impact the normal lighting control logic. Suppose we follow the standard SSDP in discovery part, then what about next step? How should we expose our control interface? Normally or per some standard method XML/SOAP or Restful API will be needed to control the device, but all of them are too heavy for us. You may wonder why Hue or Lifx or Wemo can handle this, because they use a much stronger processor with much more resources. Imagine we can implement Restful API or SOAP in our device, what about next step? Developer still need to check our spec and implement the API defined by us, pass each parameter carefully, which is way different than Hue/Lifx.

So current situation is: there is not a single standard in IOT world that everyone follows, that means developer has to build different handlers to handle devices from different vendors. We hope there will be some standard some day finally, but it will be a long way to go.

Hopefully you can understand my point. Currently, the IOT world is fragmented, we don't know which standard to follow, so we invented the standard that is most suitable for us.

It seems there is no way around the custom implementation for now. There are 2 or 3 C# working projects on github for controling yeelight bubls, so I am going to start from there.

[Yortw]

Thanks for posting the follow up, good luck with the other libs. It make sense to use low spec hardware for bulbs, and that they don't have the horse power to the full dependencies for the SSDP protocol. I was confused because I had previously understood they had concerns about the network, rather than their own hardware.