search

Aircoookie / WLED

Control WS2812B and many more types of digital RGB LEDs with an ESP8266 or ESP32 over WiFi!
https://kno.wled.ge
MIT License
14.19k stars 3.03k forks source link

WLED to announce itself on a ssdp:discover request #1068

Open Lord-Grey opened 3 years ago

Lord-Grey commented 3 years ago

Is your feature request related to a problem? Please describe. User-Story: I as a hyperion.ng and WLED user would like to discover my WLED network devices during the WLED-Device configuration in hyperion.ng (Wizard).

and I as a hyperion.ng developer would like to implement the WLED-wizard benefiting from WLED devices being ssdp-discoverable...

Describe the solution you'd like WLED to clearly respond to a ssdp:discover request as a WLED device (e.g. via the ST record, "wled") and not as a "fake" Hue-Bridge as per today.

Describe alternatives you've considered Using mDNS discovery, but hyperion.ng does not support it as a generic discovery way, yet.

Additional context If I am no mistaken this was raised by @tpmodding to @Aircoookie before.

Thank you for your support in advance!

Aircoookie commented 3 years ago

Thank you, I agree that having SSDP available for discovery in addition to mDNS is a good idea and it would be useful for at least two integrations. One issue we have to solve is that faking a Hue bridge in the response is key for successful discovery by Alexa devices. I don't really want to add a checkbox for toggling between the fake and real response as this is something that should work without user intervention. Maybe it it possible to detect Alexa devices via their user agent and conditionally send them the fake response, we should look into that!

Lord-Grey commented 3 years ago

@Aircoookie Thanks for the feedback. I do not see a specific conflict here. The WLED device could answer on a ssdp:all request with the Hue signature AND with a second answer as ST:wled. It will just response that the device supports two service endpoints. If you like you could also respond with a Wled hyperion service given that this service is running on a different port. While writing... this may be the even cleaner solution. Plus that would not require a toggle checkbox for differentiation, as the answers will be given, if the searched service is available/configured. I think, I see the same behavior when my router responses. There are many individual responses related to all the services provided.

Just food for thought...What do you think?

Lord-Grey commented 3 years ago

The issue can be treated with low priority from hyperion perspective, as I am on my way using Bonjour for WLED device discovery, which is already supported by WLED.