So, I am once again unable to add new lights from Doconz if i use Hue Essentials. I tried re-installing the stock Hue app and that can’t even find my bridge anymore. Any ideas on this one? Or do I have to start all over again for the 8th time?
My config.json can be found here: https://pastebin.com/muHxjG4R
I also loaded the default config.json file and was still not able to find my bridge in the Hue app.
Are you using the docker container? Have you cleared stored app data on your phone before searching? Can you post logs when you perform the search.
I am not using docker, I’m using the host install. I have cleared the app data on my phone. I also tried from my tablet which has never had the Hue app installed on it before.
There is nothing in the debug logs for a response to my request from my phone. Now, I do see a lot of M-search responses from my tower, but I assume that’s because it is using UPNP for other services.
2019-12-14 11:39:21,939 - root - INFO - Using Host 192.168.1.17:80
2019-12-14 11:39:22,008 - root - INFO - b827ebdbe8fb
2019-12-14 11:39:22,009 - root - INFO - IP range for light discovery: 0-255
2019-12-14 11:39:22,009 - root - INFO - 127.0.0.1
2019-12-14 11:39:22,010 - root - INFO - Online Discovery/Remote API Enabled!
2019-12-14 11:39:22,014 - root - INFO - Config loaded
2019-12-14 11:39:22,019 - root - DEBUG - starting ssdp...
2019-12-14 11:39:22,022 - root - DEBUG - start ssdp broadcast
2019-12-14 11:39:22,031 - root - INFO - sync with lights
2019-12-14 11:39:22,032 - root - DEBUG - tasmota: <get_light_state> invoked!
2019-12-14 11:39:22,074 - root - INFO - Starting httpd...
2019-12-14 11:39:22,079 - urllib3.connectionpool - DEBUG - Starting new HTTP connection (1): 192.168.1.110:80
2019-12-14 11:39:22,092 - root - INFO - Starting ssl httpd...
2019-12-14 11:39:22,113 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): discovery.diyhue.org:443
192.168.1.2 - - [14/Dec/2019 11:39:22] "GET /description.xml HTTP/1.1" 200 -
2019-12-14 11:39:22,246 - urllib3.connectionpool - DEBUG - http://192.168.1.110:80 "GET /cm?cmnd=Status%2011 HTTP/1.1" 200 None
2019-12-14 11:39:22,615 - root - DEBUG - tasmota: <get_light_state> invoked!
2019-12-14 11:39:22,644 - urllib3.connectionpool - DEBUG - Starting new HTTP connection (1): 192.168.1.115:80
2019-12-14 11:39:22,738 - urllib3.connectionpool - DEBUG - http://192.168.1.115:80 "GET /cm?cmnd=Status%2011 HTTP/1.1" 200 None
2019-12-14 11:39:22,816 - root - DEBUG - tasmota: <get_light_state> invoked!
2019-12-14 11:39:22,832 - urllib3.connectionpool - DEBUG - Starting new HTTP connection (1): 192.168.1.116:80
2019-12-14 11:39:22,915 - urllib3.connectionpool - DEBUG - http://192.168.1.116:80 "GET /cm?cmnd=Status%2011 HTTP/1.1" 200 None
2019-12-14 11:39:22,942 - urllib3.connectionpool - DEBUG - https://discovery.diyhue.org:443 "POST / HTTP/1.1" 200 6
{"ok"}
192.168.1.2 - - [14/Dec/2019 11:39:23] "GET /description.xml HTTP/1.1" 200 -
192.168.1.25 - - [14/Dec/2019 11:39:23] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
192.168.1.25 - - [14/Dec/2019 11:39:25] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
192.168.1.25 - - [14/Dec/2019 11:39:27] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
2019-12-14 11:39:28,231 - root - DEBUG - Sending M-Search response to 192.168.1.2
192.168.1.25 - - [14/Dec/2019 11:39:29] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
2019-12-14 11:39:29,733 - root - DEBUG - Sending M-Search response to 192.168.1.2
192.168.1.25 - - [14/Dec/2019 11:39:31] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
2019-12-14 11:39:31,136 - root - DEBUG - Sending M-Search response to 192.168.1.2
192.168.1.2 - - [14/Dec/2019 11:39:33] "GET /description.xml HTTP/1.1" 200 -
192.168.1.25 - - [14/Dec/2019 11:39:33] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
2019-12-14 11:39:33,704 - root - DEBUG - Sending M-Search response to 192.168.1.2
192.168.1.25 - - [14/Dec/2019 11:39:35] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
192.168.1.5 - - [14/Dec/2019 11:39:36] "GET /api/nouser/config HTTP/1.1" 200 -
2019-12-14 11:39:36,704 - root - DEBUG - Sending M-Search response to 192.168.1.2
192.168.1.25 - - [14/Dec/2019 11:39:37] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
192.168.1.25 - - [14/Dec/2019 11:39:39] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
2019-12-14 11:39:39,105 - root - DEBUG - Sending M-Search response to 192.168.1.2
192.168.1.25 - - [14/Dec/2019 11:39:41] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
192.168.1.2 - - [14/Dec/2019 11:39:43] "GET /description.xml HTTP/1.1" 200 -
192.168.1.25 - - [14/Dec/2019 11:39:43] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
2019-12-14 11:39:43,926 - root - DEBUG - Sending M-Search response to 192.168.1.2
192.168.1.25 - - [14/Dec/2019 11:39:45] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -
^X^C2019-12-14 11:39:45,857 - root - INFO - config saved
Traceback (most recent call last):The larger issue though is that I am not able to add any new lights from Deconz. I just got connected to deconz with the clean config file and it still does not discover any of the lights in my deconz config.
I did see an error for the first time tough:
192.168.1.2 - - [14/Dec/2019 11:48:46] "GET /api/hueessd61e8f11ea9d39b827ebdbe8fb/groups HTTP/1.1" 200 -
192.168.1.2 - - [14/Dec/2019 11:48:46] "GET /api/hueessd61e8f11ea9d39b827ebdbe8fb/lights HTTP/1.1" 200 -
Exception in thread Thread-5:
Traceback (most recent call last):
File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "/opt/hue-emulator/functions/lightRequest.py", line 219, in syncWithLights
for light in addresses:
RuntimeError: dictionary changed size during iteration
192.168.1.25 - - [14/Dec/2019 11:48:47] "GET /api/645395661e3311eaaa25b827ebdbe8fb/lights HTTP/1.1" 200 -Try the “beta” branch. It’s really not a beta branch anymore and I probably will end up renaming it to stable instead. It hasn’t been updated in sometime and has been mostly working.
I assume I would do that by installing via this command instead of the standard one?
curl -s https://raw.githubusercontent.com/diyhue/diyHue/beta/BridgeEmulator/easy_install.sh | sudo bash /dev/stdin
If so, that didn’t help. Still not able to discover anything from Deconz or to discover the Hub on the Hue app.
Please provide the output of following commands:
ip a
and
curl https://127.0.0.1/api/nouser/config -k -v
Did you tried to reinstall the Hue app?
ip a:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:db:e8:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.1.17/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::fc46:1d65:8784:b558/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether b8:27:eb:8e:bd:ae brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::6a0c:d1a4:e51a:f52a/64 scope link flags 800
valid_lft forever preferred_lft forever
6: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:b5:99:62:72 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet 169.254.226.71/16 brd 169.254.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::f29:52e0:40f8:7dba/64 scope link
valid_lft forever preferred_lft forever
8: vethd796fea@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 72:5c:dd:75:fb:b4 brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet 169.254.222.156/16 brd 169.254.255.255 scope global vethd796fea
valid_lft forever preferred_lft forever
inet6 fe80::37:6da6:e25d:7a95/64 scope link
valid_lft forever preferred_lft forever
curl https://127.0.0.1/api/nouser/config -k -v:
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=NL; O=Philips Hue; CN=b827ebfffe59c220
* start date: Jul 14 17:49:50 2019 GMT
* expire date: Jul 11 17:49:50 2029 GMT
* issuer: C=NL; O=Philips Hue; CN=b827ebfffe59c220
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /api/nouser/config HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 18 Dec 2019 14:38:07 GMT
< Content-type: application/json
< Content-Length: 227
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, OPTIONS, POST, PUT, DELETE
< Access-Control-Allow-Headers: X-Requested-With
< Access-Control-Allow-Headers: Content-Type
<
* Curl_http_done: called premature == 0
* Connection #0 to host 127.0.0.1 left intact
{"datastoreversion":70,"bridgeid":"B827EBFFFEDBE8FB","swversion":"1935074050","starterkitid":"","apiversion":"1.35.0","mac":"b8:27:eb:db:e8:fb","replacesbridgeid":null,"factorynew":false,"modelid":"BSB002","name":"Philips hue"}
I have re-installed the hue app many times and I have cleared app data several times. I should point out that it has become more apparent that the app does find the hub but only flashes for a second that the hub is found then immediately switches to no hubs found.
So you’re saying it entirely won’t connect at all? Nothing relating to deconz?
Btw you cannot use easy install for the beta branch, you just use the manual install method as outlined in the docs. My guess is that this problem stems from a recent commit.
No, it can control existing lights defined in Deconz. I just cannot discover new lights that have been added to Deconz.
I tried a fresh install on another Pi, and that was able to connect to the Hue App. So, as far as connection to the Hue App, that problem is either related to my setup or my config file. I have not moved my Conbee over to it yet so I don’t know if that is related as well. I am going to try moving my config.json to the new setup next to see if the problem follows it or not.
So, I will try to update to the Beta branch as well.
So, I tried using the beta branch the way that you said. I was still unable to get the light to discover in DIYHue. However, I was able to manually add the light to my DIYHue config.json. When I paired the bulb with Deconz, it told me what number it was. I was then able to use that number in the address in the config file. I just copied another replica of the same light over for the light definition. It is working perfectly. However, I would be interested to figure out how to fix this for the long term. Any information you want me to provide, I would be happy to.
I did notice that in my config file, there is a section at the top with the Deconz information but this doesn’t match the light address down below. Does that matter?
Config can be found here: https://pastebin.com/7VChfwne
Well I don’t use deconz nor do I know how it works so I cannot help with anything deconz related. If it relates to diyhue in general or esphome I can help.
Here is your problem:
Main interface where the requests are received is eth0 with mac address b8:27:eb:db:e8:fb and ip 192.168.1.17. From the certificate we see CN=b827ebfffe59c220 witch is related to mac address b827eb59c220 and this is not correct. You need to delete the current certificate and generate new one based on current mac address. Also reinstall the Hue app as the old certificate is cached and need to be deleted. Try to bring down all VPN interfaces you have durring certificate generation. If is not too hard to start from skratch delete the /opt/hue-emulator folder and run again the installation script. If you want to preseve the configuration just backup the config.json file and restore it after installation is completed.
There is nothing in the config.json that I have to delete or change?
And to be clear, is this going to fix the problem with the Hue app or with Deconz? Or with both?
UPDATE: I was able to get it paired with the Hue app after re-installing using my existing config.json. I am hesitant to remove any of my existing lights from Deconz to see if new ones will be added during the normal process unless you say that it should have fixed that issue as well. Thanks!
I was forced to rebuild my whole RPi server because of a different issue and concequently had to rebuild my DIYHue config as well. I’m now able to add lights from Deconz and they are recognized instantly in DIYhue. So, I got some setting wrong somewhere along the line but it is fixed now.