Harmony Hub unable to detect diyHue bridge #147

arachnetech · 2019-07-18T23:20:26Z

Describe the bug
I've set up diyHue on a raspberry pi, along with a simple test light. Running the Hue App on my iPad I can connect to the hub and switch my light on and off.

However, when I try to add the diyHue device from to my Harmony Hub (on the same network), it fails.

To Reproduce
Steps to reproduce the behavior:
In Harmony App:

Add Device
Home Control
Philips Hue

Shows: 'Scanning for Philips Hue bridge, Please wait...'
'Discovering Hue bridge'

Then fails with error: No Philips Hue bridge was detected !
Make sure your Harmony Hub and Hue bridge are connected to the same Wi-Fi network

My bridge is connected to the same through a wired connection to the same LAN as my Harmony Hub.

Expected behavior
Harmony Hub is documented as supported by diyHue, so I had expected it to be able to discover and connect to it.

Logs
No requests are seen from the Harmony Hub (192.168.10.227). 192.168.10.224 here is my iPad:

2019-07-19 00:08:21,300 - root - INFO - sync with lights
192.168.10.224 - - [19/Jul/2019 00:08:22] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:22] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:24] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:24] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:26] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:26] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:28] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:28] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:30] "GET /api/a7161538be80d40b3de98dece6e91f90/config HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:30] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:30] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:32] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:32] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:35] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:35] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
2019-07-19 00:08:36,358 - root - INFO - sync with lights
192.168.10.224 - - [19/Jul/2019 00:08:37] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:37] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:39] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:39] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:40] "GET /api/a7161538be80d40b3de98dece6e91f90/config HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:41] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:41] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:43] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:43] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:45] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:45] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:46] "GET /api/a7161538be80d40b3de98dece6e91f90/config HTTP/1.1" 200 -
2019-07-19 00:08:47,405 - root - INFO - sync with lights
192.168.10.224 - - [19/Jul/2019 00:08:47] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:47] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:49] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:49] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:51] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:51] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:53] "GET /api/a7161538be80d40b3de98dece6e91f90/lights HTTP/1.1" 200 -
192.168.10.224 - - [19/Jul/2019 00:08:53] "GET /api/a7161538be80d40b3de98dece6e91f90/groups HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:09:30] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:10:06] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:11:45] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:13:03] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:14:03] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:15:05] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:16:03] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:16:44] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 00:18:02] "GET /description.xml HTTP/1.1" 200 -

Additional context
Add any other context about the problem here.

The text was updated successfully, but these errors were encountered:

arachnetech · 2019-07-19T08:08:21Z

I've just tried using tcpdump to capture broadcast traffic from the Harmony Hub, and what I guess to be discovery query messages are received by the raspberry pi running diyHue:

pi@nodered:~ $ sudo tcpdump -i eth0 -n ether broadcast and ether multicast and host 192.168.10.227
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:04:44.489140 ARP, Request who-has 192.168.10.20 tell 192.168.10.227, length 46
09:04:44.761363 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:44.840881 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:44.917977 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:45.608520 ARP, Request who-has 192.168.10.204 tell 192.168.10.227, length 46
09:04:45.787728 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:45.866909 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:45.942009 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:46.819220 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:46.901243 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:46.975743 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:47.845409 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:47.925259 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:48.005354 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:49.889886 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:49.971559 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:50.049555 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:50.921366 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:51.003257 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:51.081439 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:51.957485 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:52.038400 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:52.117304 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:52.985355 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:53.065437 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:53.145363 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:55.025348 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:55.110309 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:55.189185 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:56.055578 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:56.133322 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:56.213529 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:57.086047 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:57.168620 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:57.246765 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:58.132096 IP 192.168.10.227.34255 > 255.255.255.255.56700: UDP, length 36
09:04:58.205433 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:04:58.285502 IP 192.168.10.227.34255 > 255.255.255.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
^C
38 packets captured
38 packets received by filter
0 packets dropped by kernel
2 packets dropped by interface
pi@nodered:~ $

Here is the corresponding diyHue debug output:

pi@nodered:/opt/hue-emulator $ sudo ./HueEmulator3.py --debug
2019-07-19 09:04:16,837 - root - INFO - Using Host 192.168.10.40:80
2019-07-19 09:04:16,895 - root - INFO - b827eb283cbd
2019-07-19 09:04:16,897 - root - INFO - IP range for light discovery: 0-255
2019-07-19 09:04:16,897 - root - INFO - 127.0.0.1
2019-07-19 09:04:16,903 - root - INFO - Config loaded
2019-07-19 09:04:16,911 - root - INFO - sync with lights
2019-07-19 09:04:16,960 - root - INFO - Starting httpd...
2019-07-19 09:04:16,982 - root - INFO - Starting ssl httpd...
192.168.10.20 - - [19/Jul/2019 09:05:39] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 09:06:15] "GET /description.xml HTTP/1.1" 200 -
192.168.10.20 - - [19/Jul/2019 09:07:48] "GET /description.xml HTTP/1.1" 200 -

arachnetech · 2019-07-19T08:12:53Z

Here are some messages in more verbose format from tcpdump:

09:09:55.120376 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 78)
    192.168.10.227.37965 > 255.255.255.255.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x1234
OpCode=0
NmFlags=0x11
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=PowerView-Hub   NameType=0x20 (Server)
QuestionType=0x20
QuestionClass=0x1


09:09:56.014711 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 64)
    192.168.10.227.37965 > 255.255.255.255.56700: [udp sum ok] UDP, length 36
09:09:56.072720 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 78)
    192.168.10.227.37965 > 255.255.255.255.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x1234
OpCode=0
NmFlags=0x11
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=PDBU-Hub3.0     NameType=0x00 (Workstation)
QuestionType=0x20
QuestionClass=0x1


09:09:56.161498 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 78)
    192.168.10.227.37965 > 255.255.255.255.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x1234
OpCode=0
NmFlags=0x11
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=PowerView-Hub   NameType=0x20 (Server)
QuestionType=0x20
QuestionClass=0x1

... which is odd, as "Hunter Douglas Powerview Hub" is another home control device supposedly supported by Harmony - and most definitely not "Philips Hue". Logitech, what have you done?

Curiously when I scan for the Hue bridge from the official Hue app, I don't get any of these broadcast packets anyway - so perhaps this is all irrelevant?

arachnetech · 2019-07-19T11:55:23Z

What protocol does hue bridge discovery use, out of interest?

mariusmotea · 2019-07-19T19:32:23Z

Hi,

The discovery process is this:

SSDP discover packet is send to the network.
Hue emulator catch this and reply with device data and url address of description.xml file. In your output this happen if Harmony ip is 192.168.10.20.
Next step is to send a http request to get more details to /api/nouser/config (nouser i believe is not mandatory, can be any invalid user).
After this the app has all details for pairing so it must request you to press the link button.

in you case the detection stop at description.xml. Can you block Harmony to access the internet? One simple methods Philips provide to developers is to send an http request to https://www.meethue.com/api/nupnp and this reveal the details of hue bridges connected to the same network (based on source ip address). If Harmony use this method we cannot do anything.

arachnetech · 2019-07-19T19:47:31Z

Thanks. That’s helpful. I think (if you look at my last set of tcpdump output above) that Harmony have broken the discovery mechanism. It appears to be trying to discover a Hunter Douglas Powerview Bridge when asked to discover the Hue Bridge - the messages are the same.

The requests from 192.168.10.20 are from a PC running Plex. My Harmony Hub is at 192.168.10.227.

David

mariusmotea · 2019-07-19T19:52:38Z

Nothing regarding 192.168.10.227 in your output. This means that very likely the Harmony switched to cloud based detection. Can you try to temporary cut the internet during the detection? Maybe it will fallback to regular detection.

arachnetech · 2019-07-19T21:02:02Z

You don't find the presence of those "PDBU-Hub3.0" and "PowerView-Hub" strings (which Google identifies as relating to the Hunter Douglas Powerview Hub - https://www.google.com/search?q=%22PDBU-Hub3.0%22 and https://www.google.com/search?q=%22PowerView-Hub%22) suspicious? I see the exact same messages when asking Harmony to scan for a Hunter Douglas Powerview Hub. I think Logitech have simply broken their scanning!

I added firewall rules to block access to the internet from the Harmony Hub, and it does try to establish a connection to 54.93.254.234 during discovery. However, it sadly doesn't fall back to local hue bridge detection.

Update: actually it tries to establish connectivity to this address and 54.93.254.233 regularly - both are in AWS. I'm not sure that this is even related to the discovery process.

"PDBU-Hub3.0" - Google Search

"PowerView-Hub" - Google Search

mariusmotea · 2019-07-19T21:15:59Z

check the output:

marius@marius-XPS:~$ curl https://www.meethue.com/api/nupnp
[]
marius@marius-XPS:~$ curl http://54.93.254.233/
[]marius@marius-XPS:~$

in both cases is returning an empty json list. I can confirm it 100% if i will power my original hue bridge, that will change the output at last on meethue.com. If the Synapse don't perform ssl validation i can make the hue emulator to return the correct json and with a simple dns overide for www.meethue.com the detection will work.

arachnetech · 2019-07-19T21:33:51Z

That is certainly a coincidence! I get the same here.
Interestingly, www.meethue.com resolves to 35.201.97.239 here though (and on https://mxtoolbox.com/SuperTool.aspx?action=a%3awww.meethue.com&run=toolpage) - so I don't know where that IP address is coming from.

mariusmotea · 2019-07-19T21:41:38Z

Yes, coincidence.

marius@marius-XPS:~$ curl https://54.93.254.233/ -v -k
* Expire in 0 ms for 6 (transfer 0x55f2ee53c5c0)
*   Trying 54.93.254.233...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55f2ee53c5c0)
* Connected to 54.93.254.233 (54.93.254.233) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* NPN, negotiated HTTP1.1
* 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, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Next protocol (67):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: OU=Domain Control Validated; CN=*.pubnub.com
*  start date: Jun 21 19:13:02 2017 GMT
*  expire date: Jun 21 19:08:00 2020 GMT
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=Starfield Technologies, Inc.; OU=http://certs.starfieldtech.com/repository/; CN=Starfield Secure Certificate Authority - G2
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: 54.93.254.233
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 404 Nothing
< Date: Fri, 19 Jul 2019 21:40:13 GMT
< Content-Type: text/javascript; charset="UTF-8"
< Content-Length: 2
< Connection: keep-alive
< Cache-Control: no-cache
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET

But are you sure no other addresses are accessed by Harmony?

arachnetech · 2019-07-19T22:01:45Z

I see regular connection attempts every few seconds like:

Jul 19 22:57:38 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=55051 DF PROTO=TCP SPT=48998 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:57:41 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=55052 DF PROTO=TCP SPT=48998 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:57:47 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=55053 DF PROTO=TCP SPT=48998 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:57:59 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=55054 DF PROTO=TCP SPT=48998 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:58:23 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=55055 DF PROTO=TCP SPT=48998 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:58:24 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=35.201.97.239 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=43768 DF PROTO=TCP SPT=51027 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:58:27 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=35.201.97.239 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=43769 DF PROTO=TCP SPT=51027 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:58:33 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=35.201.97.239 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=43770 DF PROTO=TCP SPT=51027 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:58:46 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=3395 DF PROTO=TCP SPT=34003 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:58:49 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=3396 DF PROTO=TCP SPT=34003 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:58:55 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=3397 DF PROTO=TCP SPT=34003 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 19 22:59:07 USG kernel: [LAN_IN-4012-D]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=3398 DF PROTO=TCP SPT=34003 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

... but they appear no more frequent during discovery. However, I do see a lot of UDP traffic during discovery only (like the fragment above).

arachnetech · 2019-07-19T22:03:54Z

Ah! DST=35.201.97.239 IS the www.meethue.com address! So maybe it is trying that. Apologies, missed that one earlier.

mariusmotea · 2019-07-20T07:42:46Z

Are you able to override the local dns for this url? If yes i can create a test version that will output the needed json.

arachnetech · 2019-07-20T11:15:55Z

Yes, I can - I've pointed it at the pi running hue-emulator:

On my desktop:

Pinging www.meethue.com [192.168.10.40] with 32 bytes of data:
Reply from 192.168.10.40: bytes=32 time=1ms TTL=63

However, I can't see any requests from the Harmony Hub to the hue emulator as a result - either in diyHue's debug output or in my firewall logs. I've power-cycled the hub to ensure its DNS cache is flushed, but it still doesn't seem to be trying to resolve www.meethue.com unfortunately.

Oddly it's no-longer trying to connect to 35.201.97.239 either:

admin@USG:~$ tail -f /var/log/messages | grep LAN
Jul 20 12:09:49 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=47138 DF PROTO=TCP SPT=50746 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 20 12:09:49 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=47139 DF PROTO=TCP SPT=50746 DPT=443 WINDOW=2920 RES=0x00 ACK URGP=0
Jul 20 12:09:50 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=47151 DF PROTO=TCP SPT=50746 DPT=443 WINDOW=8680 RES=0x00 ACK RST URGP=0
Jul 20 12:09:50 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=61447 DF PROTO=TCP SPT=50747 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 20 12:09:50 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=50746 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
Jul 20 12:09:50 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61448 DF PROTO=TCP SPT=50747 DPT=443 WINDOW=2920 RES=0x00 ACK URGP=0
Jul 20 12:09:51 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=61461 DF PROTO=TCP SPT=50747 DPT=443 WINDOW=8680 RES=0x00 ACK RST URGP=0
Jul 20 12:09:51 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=50747 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
Jul 20 12:10:23 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=192.168.49.1 LEN=375 TOS=0x00 PREC=0xC0 TTL=63 ID=10359 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.49.1 DST=192.168.10.227 LEN=347 TOS=0x00 PREC=0x00 TTL=64 ID=54047 DF PROTO=UDP SPT=60000 DPT=43545 LEN=327 ]
Jul 20 12:11:16 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=31267 DF PROTO=TCP SPT=54781 DPT=80 WINDOW=5840 RES=0x00 ACK URGP=0
Jul 20 12:11:16 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=31268 DF PROTO=TCP SPT=54781 DPT=80 WINDOW=5840 RES=0x00 ACK FIN URGP=0
Jul 20 12:11:18 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=49415 DF PROTO=TCP SPT=35953 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 20 12:11:18 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=49416 DF PROTO=TCP SPT=35953 DPT=80 WINDOW=5840 RES=0x00 ACK URGP=0

Connections to 52.203.122.90 were all while checking for hub updates.
Strange connection attempt to 192.168.49.1 (which isn't one of my networks) was during scan.
Connections to 54.93.254.233 were afterwards.

Retrying scan now (12:15) there are no further external connection attempts.

No connections to diyHue:

pi@nodered:/opt/hue-emulator $ sudo ./HueEmulator3.py  --debug
2019-07-20 12:09:16,576 - root - INFO - Using Host 192.168.10.40:80
2019-07-20 12:09:16,630 - root - INFO - b827eb283cbd
2019-07-20 12:09:16,632 - root - INFO - IP range for light discovery: 0-255
2019-07-20 12:09:16,632 - root - INFO - 127.0.0.1
2019-07-20 12:09:16,637 - root - INFO - Config loaded
2019-07-20 12:09:16,645 - root - INFO - sync with lights
2019-07-20 12:09:16,658 - root - INFO - Starting httpd...
2019-07-20 12:09:16,707 - root - INFO - Starting ssl httpd...

mariusmotea · 2019-07-20T11:27:43Z

Must be because the ssl fail as i don't have a trusted certificate for that domain. Only option remain to hack the Harmony device and install your own ca certificate there. You may try, but i don't know exactly how to block just 443 port and it may fallback to http. At last this is the behaviour for original Hue Bridge.

arachnetech · 2019-07-20T12:06:32Z

Could be, although my firewall logging should have detected that. Not sure I’m up to hacking the harmony hub!

What we really need is to find out the protocol used by the Philips hub to register itself with https://www.meethue.com/api/nupnp. That would allow diyHue to register itself with the real server (with its real certificate).

mariusmotea · 2019-07-20T12:47:45Z

I hacked my hue bridge and saw Philips secured the communication to cloud servers with sso authentication. Every hue bridge has an unique login key.

arachnetech · 2019-07-20T12:49:32Z

Bother! This isn’t going to be easy... 😀

mariusmotea · 2019-07-20T12:56:24Z

Try iptables rule on hue emulator host to drop connections frpm Harmony ip on port 443, maybe will fallback to http.

arachnetech · 2019-07-21T10:34:55Z

I tried running diyHue with its --no-serve-https option which I think is equivalent, and still no requests of any type went to it during discovery:

admin@USG:~$ tail -f /var/log/messages | grep SRC
Jul 21 11:23:30 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=32643 DF PROTO=TCP SPT=39433 DPT=80 WINDOW=5840 RES=0x00 ACK URGP=0
Jul 21 11:23:30 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=32644 DF PROTO=TCP SPT=39433 DPT=80 WINDOW=5840 RES=0x00 ACK FIN URGP=0
Jul 21 11:23:31 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=3584 DF PROTO=TCP SPT=39840 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 21 11:23:31 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=3585 DF PROTO=TCP SPT=39840 DPT=80 WINDOW=5840 RES=0x00 ACK URGP=0
Jul 21 11:26:39 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=47945 DF PROTO=TCP SPT=49605 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 21 11:26:39 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=47946 DF PROTO=TCP SPT=49605 DPT=443 WINDOW=2920 RES=0x00 ACK URGP=0
Jul 21 11:26:40 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=47960 DF PROTO=TCP SPT=49605 DPT=443 WINDOW=7240 RES=0x00 ACK RST URGP=0
Jul 21 11:26:40 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=19831 DF PROTO=TCP SPT=49606 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 21 11:26:40 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=49605 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
Jul 21 11:26:40 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=19832 DF PROTO=TCP SPT=49606 DPT=443 WINDOW=2920 RES=0x00 ACK URGP=0
Jul 21 11:26:41 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=19845 DF PROTO=TCP SPT=49606 DPT=443 WINDOW=7240 RES=0x00 ACK RST URGP=0
Jul 21 11:26:41 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=52.203.122.90 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=49606 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
Jul 21 11:27:11 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=192.168.49.1 LEN=375 TOS=0x00 PREC=0xC0 TTL=63 ID=14558 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.49.1 DST=192.168.10.227 LEN=347 TOS=0x00 PREC=0x00 TTL=64 ID=63205 DF PROTO=UDP SPT=60000 DPT=48713 LEN=327 ]
Jul 21 11:28:11 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=3588 DF PROTO=TCP SPT=39840 DPT=80 WINDOW=5840 RES=0x00 ACK URGP=0
Jul 21 11:28:11 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.233 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=3589 DF PROTO=TCP SPT=39840 DPT=80 WINDOW=5840 RES=0x00 ACK FIN URGP=0
Jul 21 11:28:12 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=43511 DF PROTO=TCP SPT=46215 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Jul 21 11:28:12 USG kernel: [LAN_IN-4012-A]IN=eth1 OUT=pppoe0 MAC=f0:9f:c2:18:91:7e:c8:db:26:0d:1e:80:08:00 SRC=192.168.10.227 DST=54.93.254.234 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=43512 DF PROTO=TCP SPT=46215 DPT=80 WINDOW=5840 RES=0x00 ACK URGP=0

pi@nodered:/opt/hue-emulator $ sudo ./HueEmulator3.py --no-serve-https --debug
2019-07-21 11:25:43,423 - root - INFO - Using Host 192.168.10.40:80
2019-07-21 11:25:43,479 - root - INFO - b827eb283cbd
2019-07-21 11:25:43,480 - root - INFO - IP range for light discovery: 0-255
2019-07-21 11:25:43,481 - root - INFO - 127.0.0.1
2019-07-21 11:25:43,486 - root - INFO - Config loaded
2019-07-21 11:25:43,494 - root - INFO - sync with lights
2019-07-21 11:25:43,506 - root - INFO - Starting httpd...

I think I'm reluctantly going to have to give up on using Hue to integrate my Homekit/Homebridge/NodeRed-based home automation stuff with Harmony. The only other proper Home Control option which it looks like I might be able to fake is LIFX Smart Bulbs. There's some documentation on the protocol (which I think is all local) around, and a rather old 'fake bulb' implementation at https://github.com/area3001/esp8266_lifx. If all else fails, I could just build an ESP with an IR receiver and put it next to the Harmony - but as I understand it I'll then only be able to use the home control buttons when remapped from within an activity.

Thanks for all your help trying to get this to work though - it's greatly appreciated.

David

GitHub
area3001/esp8266_lifx
LIFX emulator with the esp8266. Contribute to area3001/esp8266_lifx development by creating an account on GitHub.

nervalo88 · 2019-07-21T14:11:28Z

Hello,
I'm also looking forward to drive lights from harmony hub, and to this issue !
Just found a workaround, using https://github.com/bwssytems/ha-bridge

Seems not to be impacted by latest Logi changes as the emulated hue is recognized.

Renaud

arachnetech · 2019-07-21T14:15:37Z

Interesting! So ha-bridge can discovered successfully by the Harmony Hub?

mariusmotea · 2019-07-21T14:21:29Z

I know in the past Harmony was working with diyhue, but now it seams they switched to cloud detection so not sure how ha-bridge can work. From what i see in readme they state that Harmony is using hue api for detection and for sure this is not happening now. The best i thing is to ask Logitech how to control with Harmony an offline hue bridge.

arachnetech · 2019-07-21T14:27:21Z

I came to the same conclusion from the ReadMe!

Renaud, do you have ha-bridge working under control of a Harmony Hub as a Home Automation device? If so, what version of the Harmony Hub and which remote are you using? Thanks.

arachnetech · 2019-07-21T14:36:59Z

It is these home control buttons which I am hoping to use. As you can see, I have managed to assign one to a fake LIFX light - but I’d prefer a Hue solution if I can get discovery working.

nervalo88 · 2019-07-21T15:27:27Z

I have done it few minutes ago.
OK with ha-bridge, NOK with diyhue
My system is based on domoticz, for home automation. was able to attach API http requests to remote presses

My hub version, using the elite remote :

if it can help, the tcpdump of the pairing process (192.168.0.18 is the hub, .0.33 is the bridge) :

ha-bexp.zip

arachnetech · 2019-07-21T16:43:06Z

Thanks, I’ll give it a try later...

I’m on the same hub software version but a slightly later app version (although I’m on iOS - you may be on Android). My iOS app version is 5.6.2, build 53. This shouldn’t be significant though, assuming that the hub does the discovery not the mobile device.

nervalo88 · 2019-07-21T18:36:13Z

I don't know what kind of magic is in use by Logitech to perform the discovery, no SSDP packet trace found... hence no description.xml emitted by the bridge.

I only found those HTTP transactions which I was able to replay through curl :

curl -X POST http://192.168.0.33/api
[{"success":{"username":"e084816123ba480c921d708a8d9a0e8e"}}]
curl -X GET http://192.168.0.33/api/e084816123ba480c921d708a8d9a0e8e/lights
{"100":{"state":{"on":false,"bri":0,"xy":[0.0,0.0],"alert":"none","colormode":"xy","reachable":true},"type":"Dimmable light","name":"LampeSalon","modelid":"LWB007","manufacturername":"Philips","uniqueid":"00:17:88:5E:D3:64-00","swversion":"66012040"},"101":{"state":{"on":false,"bri":0,"xy":[0.0,0.0],"alert":"none","colormode":"xy","reachable":true},"type":"Dimmable light","name":"LampeBureau","modelid":"LWB007","manufacturername":"Philips","uniqueid":"00:17:88:5E:D3:65-00","swversion":"66012040"}}
curl -X GET http://192.168.0.33/api/e084816123ba480c921d708a8d9a0e8e/groups
{}

mariusmotea · 2019-07-21T21:26:51Z

Any output while accessing https://discovery.meethue.com/ ? Maybe ha-bridge somehow register with cloud servers.

arachnetech · 2019-07-21T22:19:01Z

I started https://github.com/bwssytems/ha-bridge on my network (without any configuration), and my Harmony Hub discovered it (without any lights). A very interesting step in the right direction though...

No output ([]) at https://discovery.meethue.com/ here still.

GitHub
bwssytems/ha-bridge
Home automation bridge that emulates a Philips Hue light system and can control other systems such as a Vera, Harmony Hub, Nest, MiLight bulbs or any other system that has an http/https/tcp/udp int...

arachnetech · 2019-07-21T22:41:12Z

... and after a bit of messing around in the ha-bridge web interface, my Logitech Hub is talking to ha-bridge which is talking to diyHue which is talking to my FakeHue node.js script. Three raspberry pis for a virtual light! :-)

arachnetech · 2019-07-21T22:49:44Z

Confirming no output from https://www.meethue.com/api/nupnp:

So it would appear that ha-bridge is somehow supporting a local hue bridge discovery mechanism used by the harmony hub which diyHue doesn't support directly.

The great news for me is that I have something I can use, but it would be fascinating to know why this works when diyHue alone doesn't.

mariusmotea · 2019-07-24T11:00:29Z

I forget one thing. The Hue Bridge broadcast every 30 seconds 6 SSDP notification messages. Maybe Harmony is looking for these. These SSDP messages are also implemented in the Hue Emulator but maybe the new updates to hue api changed the output format. Can you check with Wireshark what SSDP messages are broadcast by HA-Bridge and compare them to Hue-Emulator? Also i saw https://www.meethue.com/api/nupnp is deprecated now is used https://discovery.meethue.com.

nervalo88 · 2019-07-26T13:23:55Z

ha-bridge seems to emit a M-SEARCH * HTTP/1.1 SSDP at the startup of the service, no else SSDP found within the 15 following minutes, I'll keep a long running dump to know more...

diy-hue issue 6x NOTIFY * HTTP/1.1 approx. every minute.

detailled ha-bridge SSDP packet content

Frame 586: 159 bytes on wire (1272 bits), 159 bytes captured (1272 bits)
    Encapsulation type: Ethernet (1)
    Frame Length: 159 bytes (1272 bits)
    Capture Length: 159 bytes (1272 bits)
    [Protocols in frame: eth:ethertype:ip:udp:ssdp]
Internet Protocol Version 4, Src: 192.168.0.33, Dst: 239.255.255.250
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 145
    Identification: 0xecdb (60635)
    Flags: 0x4000, Don't fragment
        0... .... .... .... = Reserved bit: Not set
        .1.. .... .... .... = Don't fragment: Set
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 1
    Protocol: UDP (17)
    Header checksum: 0xdbbc [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.0.33
    Destination: 239.255.255.250
User Datagram Protocol, Src Port: 1900, Dst Port: 1900
    Source Port: 1900
    Destination Port: 1900
    Length: 125
    Checksum: 0x8e5c [unverified]
    [Checksum Status: Unverified]
    [Stream index: 12]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
Simple Service Discovery Protocol
    M-SEARCH * HTTP/1.1\n
        [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\n]
            [M-SEARCH * HTTP/1.1\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: M-SEARCH
        Request URI: *
        Request Version: HTTP/1.1
    HOST: 239.255.255.250:1900ST: urn:schemas-upnp-org:device:CloudProxy:1\n
    MAN: "ssdp:discover"\n
    MX: 3
    [Full request URI: http://239.255.255.250:1900ST: urn:schemas-upnp-org:device:CloudProxy:1*]
    [HTTP request 1/1]

stale · 2019-08-02T13:36:33Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 2 days if no further activity occurs. Thank you for your contributions.

stale · 2019-08-04T14:11:09Z

This issue has been automatically closed as it has not had any recent activity. Thank you for your contributions.

clutwo · 2019-12-09T08:36:59Z

Is this being worked on? I would really love to get the pairing with my Harmony Hub

mariusmotea · 2019-12-09T15:15:13Z

you need to debug the pair process by youreself. Something is not working but i cannot figure what and i don't have Harmony Hub.

alexyao2015 · 2020-05-11T19:58:01Z

@mariusmotea
Was this ever fixed? If not, I can probably work on it as I have a harmony hub. Home assistant also has harmony hub support through hue integration, so it is definitely possible if not currently working.

imcfarla2003 · 2020-05-11T20:16:55Z

I have just stumbled across this and I think fixed it by reducing the sleep on the ssdpBroadcast function to .5s

--- /home/iain/src/diyHue/BridgeEmulator/functions/ssdp.py      2020-05-11 15:25:59.928282834 +0100
+++ ./ssdp.py   2020-05-11 21:06:08.184540264 +0100
@@ -32,7 +32,7 @@
                 logging.debug("Sending M-Search response to " + address[0])
                 for x in range(3):
                    sock.sendto(bytes(Response_message + "ST: " + custom_response_message[x]["st"] + "\r\nUSN: " + custom_response_message[x]["usn"] + "\r\n\r\n", "utf8"), address)
-        sleep(1)
+        sleep(0.5)

 def ssdpBroadcast(ip, port, mac):
     logging.debug("start ssdp broadcast")

mariusmotea · 2020-05-12T15:26:09Z

@alexyao2015 can you please test the suggestion made by @imcfarla2003 and reduce the sleep to 0.5s?

bjaminp · 2020-07-07T23:17:40Z

@imcfarla2003 That seemed to fix it for me too. Thanks

Maarten-s92 · 2024-03-16T14:20:28Z

Hi, im running Diy Hue in Home assistant and can't get the connection with my Harmony. Also cant find teh fix suggested by [imcfarla2003]

stale bot added the stale This issue is stale, and will be closed label Aug 2, 2019

stale bot closed this as completed Aug 4, 2019

alexyao2015 reopened this May 11, 2020

stale bot removed the stale This issue is stale, and will be closed label May 11, 2020

alexyao2015 added the enhancement label May 11, 2020

imcfarla2003 mentioned this issue May 11, 2020

Add hascolor parameter to domoticz lights to allow for just plain dim… #396

Merged

alexyao2015 mentioned this issue Sep 15, 2020

Correctly return response for Hue #463

Closed

alexyao2015 closed this as completed Sep 15, 2020

alexyao2015 reopened this Sep 15, 2020

alexyao2015 added Verified Is on the roadmap for future implementation Feature Request and removed enhancement labels Nov 23, 2020

mariusmotea closed this as completed Jun 7, 2022

Harmony Hub unable to detect diyHue bridge #147

Harmony Hub unable to detect diyHue bridge #147

Comments

arachnetech commented Jul 18, 2019

arachnetech commented Jul 19, 2019

arachnetech commented Jul 19, 2019 • edited Loading

arachnetech commented Jul 19, 2019

mariusmotea commented Jul 19, 2019 • edited by unfurl-links bot Loading

arachnetech commented Jul 19, 2019

mariusmotea commented Jul 19, 2019

arachnetech commented Jul 19, 2019 • edited Loading

mariusmotea commented Jul 19, 2019 • edited Loading

arachnetech commented Jul 19, 2019

mariusmotea commented Jul 19, 2019

arachnetech commented Jul 19, 2019

arachnetech commented Jul 19, 2019

mariusmotea commented Jul 20, 2019 • edited Loading

arachnetech commented Jul 20, 2019

mariusmotea commented Jul 20, 2019

arachnetech commented Jul 20, 2019 • edited by unfurl-links bot Loading

mariusmotea commented Jul 20, 2019

arachnetech commented Jul 20, 2019

mariusmotea commented Jul 20, 2019

arachnetech commented Jul 21, 2019 • edited Loading

nervalo88 commented Jul 21, 2019 • edited Loading

arachnetech commented Jul 21, 2019

mariusmotea commented Jul 21, 2019

arachnetech commented Jul 21, 2019

arachnetech commented Jul 21, 2019

nervalo88 commented Jul 21, 2019 • edited Loading

arachnetech commented Jul 21, 2019 • edited Loading

nervalo88 commented Jul 21, 2019 • edited Loading

mariusmotea commented Jul 21, 2019 • edited by unfurl-links bot Loading

arachnetech commented Jul 21, 2019 • edited Loading

arachnetech commented Jul 21, 2019

arachnetech commented Jul 21, 2019 • edited by unfurl-links bot Loading

mariusmotea commented Jul 24, 2019 • edited by unfurl-links bot Loading

nervalo88 commented Jul 26, 2019 • edited Loading

stale bot commented Aug 2, 2019

stale bot commented Aug 4, 2019

clutwo commented Dec 9, 2019

mariusmotea commented Dec 9, 2019

alexyao2015 commented May 11, 2020

imcfarla2003 commented May 11, 2020 • edited Loading

mariusmotea commented May 12, 2020

bjaminp commented Jul 7, 2020

Maarten-s92 commented Mar 16, 2024

arachnetech commented Jul 19, 2019 •

edited

Loading

mariusmotea commented Jul 19, 2019 •

edited by unfurl-links bot

Loading

arachnetech commented Jul 19, 2019 •

edited

Loading

mariusmotea commented Jul 19, 2019 •

edited

Loading

mariusmotea commented Jul 20, 2019 •

edited

Loading

arachnetech commented Jul 20, 2019 •

edited by unfurl-links bot

Loading

arachnetech commented Jul 21, 2019 •

edited

Loading

nervalo88 commented Jul 21, 2019 •

edited

Loading

nervalo88 commented Jul 21, 2019 •

edited

Loading

arachnetech commented Jul 21, 2019 •

edited

Loading

nervalo88 commented Jul 21, 2019 •

edited

Loading

mariusmotea commented Jul 21, 2019 •

edited by unfurl-links bot

Loading

arachnetech commented Jul 21, 2019 •

edited

Loading

arachnetech commented Jul 21, 2019 •

edited by unfurl-links bot

Loading

mariusmotea commented Jul 24, 2019 •

edited by unfurl-links bot

Loading

nervalo88 commented Jul 26, 2019 •

edited

Loading

imcfarla2003 commented May 11, 2020 •

edited

Loading