luminance
luminance copied to clipboard
404 when calling https://www.meethue.com/api/nupnp
I started Luminance for the first time in a while (including an upgrade to Ubuntu 20.04) and the app gets stuck searching for bridges. If I running from the terminal, I get the following:
$ luminance
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/luminance/views/setup.py", line 150, in search
data = requests.get('https://www.meethue.com/api/nupnp').json()
File "/usr/lib/python3/dist-packages/requests/models.py", line 897, in json
return complexjson.loads(self.text, **kwargs)
File "/usr/lib/python3/dist-packages/simplejson/__init__.py", line 518, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 370, in decode
obj, end = self.raw_decode(s)
File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 400, in raw_decode
return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/luminance/views/setup.py", line 159, in search
network_discovery = netdisco.discovery.NetworkDiscovery(
TypeError: __init__() got an unexpected keyword argument 'limit_discovery'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
self.run()
File "/usr/lib/python3.8/threading.py", line 870, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.8/site-packages/luminance/views/setup.py", line 190, in search
GLib.idle_add(cb, results)
UnboundLocalError: local variable 'results' referenced before assignment
And if I try to make the requests that appears on setup.py:150
with curl, I get a 404:
curl -v https://www.meethue.com/api/nupnp
* Trying 35.201.97.239:443...
* TCP_NODELAY set
* Connected to www.meethue.com (35.201.97.239) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=NL; ST=North Brabant; L=Eindhoven; O=Signify Netherlands B.V.; OU=Hue; CN=www.meethue.com
* start date: Jan 29 00:00:00 2020 GMT
* expire date: Feb 5 12:00:00 2021 GMT
* subjectAltName: host "www.meethue.com" matched cert's "www.meethue.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55d026ce1db0)
> GET /api/nupnp HTTP/2
> Host: www.meethue.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 404
< server: nginx
< date: Sun, 07 Jun 2020 08:47:43 GMT
< content-type: text/html
< content-length: 146
< via: 1.1 google
< alt-svc: clear
<
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host www.meethue.com left intact
Is that URL no longer working?
Indeed. This website does not exist any longer. In my honest opinion applications shouldn't rely on external resources/services that have a high risk of disappearing.
https://discovery.meethue.com doesn't exist either.
https://discovery.meethue.com doesn't exist either.
Strange, it works for me no problem:
[{"id":"XXX","internalipaddress":"XXX"}]
Maybe you need to be on the same network than a registered hub.
The issue appears to be that a recent version of netdisco
has a different API from how the package is calling it. If you pip instal netdisco==0.7
, that should solve the issue.
Maybe @craigcabrey can help us moving this forward.