Hello,
Since I was in the last stable version of deconz, https://phoscon.de/discover show me only [] and not the information of my deconz gateway. Am I alone in this case ?
You’re not, I am getting exactly the same today.
My previously configured apps (both Phoscon PWA in the browser and Hue Essentials on Android) work correctly – they can connect to the gateway (deconz-rest), read Conbee II firmware version, control the lights, etc – even after restarting Raspberry Pi.
However https://phoscon.de/discover only returns this empty array (and 200 OK). Which kills my other app, which relies on GW discovery rather than a stored config.
This used to work some 3-4 days ago…
Thoughts?
1 Like
What do you mean about : “Which kills my other app, which relies on GW discovery rather than a stored config.” ?
I have one application that doesn’t work. It doesn’t work because the first thing it does is looking for a gateway in the local network, by invoking the discover url. The other applications have configuration stored locally, they know where the gateway is so they don’t need to invoke the discover URL when I use them.
Sorry for being unclear.
Ok. For me I’m in a local network and it just show [] even if I trie it on the local machine. So wait and see ^^
deconz is working ?
You have not firewall rule that block the deconz request ? (I think it s visible on logs)
If you want to block it you can use the local IP, if you can set yourself the IP instead of letting the application use the discover link.
Yes, it is. The previously configured PWA and other apps successfully connect to it and are able to perform actions.
No, there is no firewall, the request isn’t getting blocked:
curl -v https://phoscon.de/discover 2>&1 | grep -Fv -e 'X-AppEngine-' -e 'X-Public-Ip'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 144.76.96.194:443...
* Connected to phoscon.de (144.76.96.194) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [224 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4028 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=phoscon.de
* start date: Nov 7 22:40:18 2021 GMT
* expire date: Feb 5 22:40:17 2022 GMT
* subjectAltName: host "phoscon.de" matched cert's "phoscon.de"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
> GET /discover HTTP/1.1
> Host: phoscon.de
> User-Agent: curl/7.77.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.14.2
< Date: Wed, 29 Dec 2021 17:45:27 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 2
< Connection: close
< Access-Control-Allow-Origin: *
<
{ [2 bytes data]
100 2 100 2 0 0 11 0 --:--:-- --:--:-- --:--:-- 12
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
} [2 bytes data]
[]
Not sure what you mean here. That I can look for ways to avoid relying on the https://phoscon.de/discover functionality? If so then I’d rather not, it’s convenient for me to use it.
It used to work perfectly but it is now broken and I am trying to find out why.
On deconz log, I can be wrong but it seem there is some debug about the discovering, visible with the flag 'info"
DBG_Printf(DBG_INFO, "Announced to internet %s\n", qPrintable(gwAnnounceUrl));
DBG_Printf(DBG_INFO, "discovery network reply error: %s\n", qPrintable(reply->errorString()));
So the error is probably visible.
I don’t speak when you make the request yourself phoscon.de/discover, but I think deconz make a request itself to the phoscon server.
Edit:
The link https://phoscon.de/discover is broken ATM here too, probably server issue. You need to use the local IP to access to phoscon.
But why you need it ? you can set a fixed IP in the application that need it ?
Now I get it, thank you. I was looking at https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/discovery.cpp and by the looks of it, it registers (announces) the gateway with a phoscon.de service (and this information is then retrievable via /discover). There is indeed some relevant log info in this file however none of it shows in my deconz logs. I was about to check how to restart deconz with a logging level that would print those out but then I read your message below:
Thanks for your confirmation! Outages happen of course so I will be waiting for this to get fixed. It would be great if Dresden Elektronik/ Phoscon didn’t return 200 OK to the discover (and potentially announce) calls in this scenario.
UPnP discovery still works (as expected, as it is fully local and does not depend on any Phoscon provided service).
As I said, one of my apps depends on this. Since it’s included in the documentation (Discovery - deCONZ REST-API) I was expecting it to work, especially that the way it’s phrased, it’s the most reliable discovery method.
Yeah, I know I m using it too, realy helpfull, but for the sensible part I m using the fixed ip my myself.
Thanks for your confirmation! Outages happen of course so I will be waiting for this to get fixed. It would be great if Dresden Elektronik/ Phoscon didn’t return 200 OK to the discover (and potentially announce) calls in this scenario.
Yeah, right again, I m agree, but I realy don’t have information on what happen and if it was normal, I will ask to dev channel by curiosity.
Hello,
I have just noticed that calling https://phoscon.de/discover seems required for the web application? I am running the stable pwa docker community container and if I block the url the container keeps restarting and can’t control the devices until that url is available again.
Is there a setting where I can deactivate that behavior? (to not require it)
Hello, so you are using the local ip for phoscon, and it don’t work in local mode ?
With the rest api you can disable this:
https://dresden-elektronik.github.io/deconz-rest-doc/endpoints/configuration/#modify-configuration
1 Like
Since a few versions you can also disable the discovery service with the Phoscon App under “Settings → Gateway” (does the same thing as the REST-API call).