https://dresden-light.appspot.com/discover doesn't work over IPv4 about deconz-rest-plugin HOT 2 CLOSED

Improving this is tricky, to support both (for v6 enabled hosts) the gateway would need to send two requests to the discover site since on the server the incoming external host address is used for matching. Hence the v4 and v6 external addresses need to be known to generate matches.

Albeit the discover service is convenient it will be deprecated in the future, in favour of a more advanced local discovery.

In the past the main reason to provide the discover service was ability to easily open the web app without knowing the ip address (especially non-technical users). But this only works when internet is available, IPv4/v6 are used equally by gateway and browser, no fancy proxy settings are in place and internet discovery is enabled in the web app. UPnP doesn't work in browsers either due the missing UDP support and has further issues in corporate networks with multiple subnets.

We are currently quite busy developing a progressive web app (PWA) — oh these buzz words — which doesn't rely on a server based discover service and instead scans the local network for gateways. Thanks to javascript Service Workers and CORS this works even without internet connection and in proxy environments. Safari browser doesn't implement Service Workers yet, but I guess they will support it in a timely manner, until then app cache will be used for Safari.

https://jakearchibald.github.io/isserviceworkerready/

The documentation will be updated on how to discover local gateways via scanning, with a javascript example, since using javascript in browsers is the most tricky method.

In the end local scanning is more complicated than a single request to discover service, but it turns out to be much more reliable in our experience. In support feedback we often hear that users appreciate it a lot that the gateway doesn't rely on cloud and vendor services.
— Offline is a feature.

from deconz-rest-plugin.

Thanks for the explanation, Manuel. It's making sense to me, now.

to support both (for v6 enabled hosts) the gateway would need to send two requests to the discover site

Definitely tricky, but not impossible: send the same request twice, but force IPv4 on the second request. Alternatively, bluntly remove the IPv6 DNS entry for dresden-light.appspot.com. The Philips Hue portal, www.meethue.com doesn't resolve to IPv6 either. I doubt there's any IPv6-only consumers on the Internet, and even if there are, they couldn't use this discovery method, as the gateway registers its internal IPv4 address.
Out of interest: why doesn't the gateway register its (internal, link local) IPv6 address instead?

To testify to the tricky: it took me a couple of hours to find a trick to force IPv6 in NodeJS. Somehow NodeJS prefers IPv4 over IPv6 when a hostname resolves to addresses from both families, where all the other programmes (deCONZ, Safari, Chromium, curl) on macOS and RaspBian seem to favour IPv6 (as they should).

Unfortunately, even with this trick, I still cannot use this discovery method, as the id registered differs from the GWID.phoscon.de advertised with UPnP (I recognise each bridge / gateway by its ID, to cope with changing addresses and/or names).
Could this be fixed in the next beta, together with the config.bridgeid (and config.modelid) attributes? What about the unauthenticated GET /api/config?

In the end local scanning is more complicated than a single request to discover service, but it turns out to be much more reliable in our experience. In support feedback we often hear that users appreciate it a lot that the gateway doesn't rely on cloud and vendor services.

Yes, I definitely prefer local discovery over a cloud-based solution, both from a reliability as well as from a security perspective. I'm not too keen on a brute-force full network scan, though. As a fall back, the gateway's local address:port could be specified in some config file or settings/preferences. In either scenario, you need the unauthenticated GET /api/config to retrieve the ID (as the username and other gateway-specific parameters are stored under the ID, to cope with changing addresses and/or names).

I tried UPnP discovery (SSDP) over IPv6 (using [FF02::C] instead of 239.255.255.250), but only Sonos and Fritz!, seem to support it.
Did you ever consider using Bonjour (DNS-SD)? I realise it still has an Apple ring to it, but it works quite reliably and supports IPv6. And there is an open source implementation for Linux. On the other hand, it also uses local network multicasts, so it might not work in corporate environments either, nor over (routing) VPNs.

from deconz-rest-plugin.