core: HomeKit Controller - Does not follow TCP port change
The problem
I use a Starling Home Hub as a HomeKit bridge for some Nest devices that aren’t (yet?) supported, such as door, alarm, and temperature sensors. When the Starling reboots (esp. after a firmware update), its TCP port being used for HomeKit integration may change. According to the developer, this is in line with the HomeKit specification, and connecting devices are supposed to use an mDNS query to look up the port for connecting.
It appears that for the HomeKit Controller component, however, the port is fixed in the core.config_entries file. In my log files you can see HA repeatedly trying to connect to the Starling hub on the old TCP port.
According to the Starling developer:
The right way to discover the port is to do an mDNS query for
_hap._tcpto the hub. The port number of the HomeKit service will be returned in the SRV record. This is what HomeKit itself does.
I’m unsure if this is a HomeKit Controller component issue, or an aiohomekit issue that’s causing it to not re-query the port.
And indeed, when I query the device I get back its new TCP port. I can manually update core.config_entries for the HomeKit Controller device and change the AccessoryPort property to the new port, restart HA, and it will start working again.
Example of how to query for the correct TCP port (converted from hex to decimal):
dig @192.168.X.X -p 5353 -t ptr _hap._tcp.local | grep SRV | awk '{print $7}' | echo "obase=10; ibase=16; $(cut -c9-12)" | bc
What is version of Home Assistant Core has the issue?
core-2021.6.4
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Core
Integration causing the issue
HomeKit Controller
Link to integration documentation on our website
https://www.home-assistant.io/integrations/homekit_controller/
Example YAML snippet
No response
Anything in the logs that might be useful for us?
2021-06-14 08:23:19 DEBUG (MainThread) [homeassistant.components.homekit_controller.connection] Starting HomeKit controller update: [redacted MAC]
2021-06-14 08:23:29 DEBUG (MainThread) [homeassistant.components.homekit_controller.connection] Called async_set_available_state with False for [redacted MAC]
2021-06-14 08:23:31 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.X.X:40313
2021-06-14 08:23:31 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Connecting to accessory failed. Retrying in 60 seconds
2021-06-14 08:24:19 DEBUG (MainThread) [homeassistant.components.homekit_controller.connection] Starting HomeKit controller update: [redacted MAC]
2021-06-14 08:24:29 DEBUG (MainThread) [homeassistant.components.homekit_controller.connection] Called async_set_available_state with False for [redacted MAC]
2021-06-14 08:24:31 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.X.X:40313
2021-06-14 08:24:31 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Connecting to accessory failed. Retrying in 60 seconds
Additional information
No response
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 38 (19 by maintainers)
Commits related to this issue
- Update homekit_controller to use async zeroconf Fixes #51851 — committed to bdraco/home-assistant by bdraco 3 years ago
I probably have another 2-3 days of cleanup work for zeroconf before release. Then I’ll start updating everything that depends on it
I’m probably going to be busy next week (not 100%, but it might slow down getting follow up patches merged).
I could increment the major version and do a release this week, then we can still get minor versions released (if needed) until we can get this into HA.
I know your testing stack for this stuff is way more brutal than anything I can throw at it so I’ll be happy to just pump any changes you need right through as well.
There is definitely an issue which will likely be fixed by the combination of https://github.com/Jc2k/aiohomekit/pull/39 and https://github.com/home-assistant/core/pull/51173 + the unreleased zeroconf 0.32.
MacBook should be a good test - i can see Hue devices on a different vlan from my mac (both on unifi switches). Its 11pm here so I won’t be around when you do that test.
Its possible we don’t match on port for the SRV record here https://github.com/jstasiak/python-zeroconf/blob/master/zeroconf/_services/__init__.py#L279
I think we will need to write a test in zeroconf to see if its the problem or not