During my network debugging efforts, I came across an intriguing observation related to the two Hubitat devices on our network. The logs below illustrate the unexpected mDNS queries they generated:1. Query for Airplay Devices
- 12 0.788177995 192.168.55.11 → 224.0.0.251 MDNS 130 Standard query 0x0000 PTR _airplay._tcp.local, "QM" question PTR Hubitat._hubitat._tcp.local
14 0.791018733 192.168.55.11 → 224.0.0.251 MDNS 127 Standard query 0x0000 PTR _http._tcp.local, "QM" question PTR Hubitat._hubitat._tcp.local
Surprisingly, the Hubitat devices were seeking Airplay and web server devices, even though I only utilized them for Z-Wave and Zigbee devices, and have not installed the Airplay application. This behavior caused issues, as the queries and responses were transmitted across VLANs, leading to a flood of broadcast packets during high query volumes.
To address this, I opted to move the Hubitat devices to a VLAN where mDNS queries aren't forwarded to the other networks. The process was straightforward: I changed the native VLANs on the ports connected to the Hubitat devices and updated the Hubitat integration configuration in Home Assistant to reflect the new IP address.
However, after the move, I encountered integration issues. While toggling controls in Home Assistant affected device states, the updated state didn't reflect back into Home Assistant. The key difference between the old and new VLANs was that the latter didn't allow incoming connections to the Home Assistant server's VLAN.
To resolve this, I adjusted the firewall rules to permit incoming connections from the Hubitat's IP address to the Home Assistant server. Following this update, everything began functioning correctly.
No comments:
Post a Comment