search

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 interface. This is a compact impl to run on small format computers. This is impl started from this project https://github.com/armzilla/amazon-echo-ha-bridge.
Apache License 2.0
1.45k stars 198 forks source link

Upnp discovery not responding to Harmony HUB #1197

Open spiff972 opened 4 years ago

spiff972 commented 4 years ago

I've read through all of the issues related to Harmony Hub discovering ha-bridge, but none seem to answer my challenge.

My setup is Proxmox -> Centos 8 as KVM -> Java 11 -> ha-bridge 5.3.0 java 11 (also tried 5.3.1RC1).

I've checked with tcpdump that the VM is receiving the queries from Harmony Hub, but there are no traces of ha-bridge responding to these. -Only see Traceupnp: sendUpnpNotify notifyTemplate 1-3 in the log ha-bridge log and /var/log/messages on host VM.

Is there a know issue here, or is there something that I'm missing?

ha-bridge works perfectly for reading activities and devices from Harmony Hub, but the discovery does not work.

Is there a good way to truly verify if ha-bridge is receiving discovery packages? Just to clear out any networking issues, as I don't know which queries to expect to see from Harmony Hub.

bwssytems commented 4 years ago

Traceupnp shows the discovery packets if it is sent to it. Have you checked that the ha-bridge is listening on the correct interface? That is put out as part of trace upnp.

spiff972 commented 4 years ago

I've tried most settings combinations. -And yes it seems that it binds to the correct interface with "Use UPNP Address Interface Only" is set. Otherwise it also binds to some podman/docker interfaces running on my box.

Traceupnp: upnp config address: 192.168.201.29 -useIface: true on web server: 192.168.201.29:80 ... Traceupnp: Interface: ens18 matches upnp config address of IP address: /192.168.201.29 Traceupnp: Adding ens18 to our upnp join interface set.

And then periodically repeating: Traceupnp: sendUpnpNotify notifyTemplate1 Traceupnp: sendUpnpNotify notifyTemplate2 Traceupnp: sendUpnpNotify notifyTemplate3

No other traces.

From "tcpdump -i ens18 udp | grep 201.128" (.128 is the Hub) I only see this repeated: 20:13:52.050675 IP 192.168.201.128.33368 > 255.255.255.255.56700: UDP, length 36 20:13:52.227167 IP 192.168.201.128.33368 > 255.255.255.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 20:13:52.305949 IP 192.168.201.128.33368 > 255.255.255.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 20:13:52.467188 IP 192.168.201.128.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _lutron._tcp.local. (36) 20:13:52.546739 IP 192.168.201.128.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _lutron._tcp.local. (36) 20:13:52.626809 IP 192.168.201.128.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _lutron._tcp.local. (36) 20:13:52.708647 IP 192.168.201.128.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _appletv._tcp.local. (37) 20:13:52.787709 IP 192.168.201.128.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _airplay._tcp.local. (37)

So no responses - Or no proper requests?

Using netstat to verify which ports are in use: "netstat -tulpn | grep java" [root@localhost ~]# netstat -tulpn | grep java tcp 0 0 192.168.201.29:80 0.0.0.0: LISTEN 6516/java udp 0 0 0.0.0.0:50000 0.0.0.0: 6516/java udp 0 0 0.0.0.0:5353 0.0.0.0: 6516/java udp 0 0 0.0.0.0:5353 0.0.0.0: 6516/java udp 0 0 0.0.0.0:5353 0.0.0.0: 6516/java udp 0 0 192.168.201.29:1900 0.0.0.0: 6516/java

bwssytems commented 4 years ago

Well, the mdns messages are not upnp M-SEARCH messages. You'll need to see what is in the packet listed as "20:13:52.050675 IP 192.168.201.128.33368 > 255.255.255.255.56700: UDP, length 36"

spiff972 commented 4 years ago

I have no idea what to look for here, but did a Wireshark capture on my Windows machine, and got the following:

Datagram (Hex dump): 0000 ff ff ff ff ff ff 00 04 20 e8 6d 28 08 00 45 00 0010 00 40 00 00 40 00 40 11 b0 84 c0 a8 c9 80 ff ff 0020 ff ff a4 bc dd 7c 00 2c b8 02 00 24 00 34 6c 6f 0030 67 69 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 02 00 00 00 00 00 00 00 00 00 65 00 00 00

Where the data is: 0000 00 24 00 34 6c 6f 67 69 00 00 00 00 00 00 00 00 0010 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 0020 65 00 00 00

asquelt commented 4 years ago

i can replicate this problem. my java also listens on port 5353 and not port 56700. however, i did quick lookup and 56700 is LIFX, which also happens to by supported by Logitech Hub. so it might be that it just fire several discovery mechanisms at once (they also search for something with NETBIOS).

in my case it also fires several mdns requests which are not being responded:

11:18:36.946966 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 64)
    192.168.111.62.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? _lutron._tcp.local. (36)
E..@..@...h...o>.........,H.............._lutron._tcp.local.....
11:18:37.026908 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 64)
    192.168.111.62.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? _lutron._tcp.local. (36)
E..@..@...h...o>.........,H.............._lutron._tcp.local.....
11:18:37.109906 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 64)
    192.168.111.62.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? _lutron._tcp.local. (36)
E..@..@...h...o>.........,H.............._lutron._tcp.local.....
11:18:37.186815 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 65)
    192.168.111.62.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? _appletv._tcp.local. (37)
E..A..@...h...o>.........-i ............._appletv._tcp.local.....
11:18:37.269230 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 65)
    192.168.111.62.5353 > 224.0.0.251.5353: [udp sum ok] 0 PTR (QM)? _airplay._tcp.local. (37)
E..A..@...h...o>.........-].............._airplay._tcp.local.....

i can also confirm i can see no uPNP discovery from Harmony Hub (port 1900 and 1901), while i can see those from another network equipment on my segment.

bwssytems commented 4 years ago

I should remove mdns since it seems to be not used for the Hue. You will need to see if you can see the UDP MSEARCH messages as that is what is needed.

asquelt commented 4 years ago

no, there are no messages on port 1900 on the wire. they must have switched to some other discovery method.

bwssytems commented 4 years ago

@asquelt I think you are narrowing the port filter too much. look at udp traffic from the machine with the ha-bridge without specific port filtering. If you do not see any of the messages, then your system may be blocking them with firewall rules

asquelt commented 4 years ago

just a FYI: in my case it was switch blocking multicasts between its ports. after fixing that i can successfully pair my harmony with habridge.