HomeKit Controller devices become unavailable

[dgrove]

The problem

I have regular issues with HomeKit devices (often, but not always, a Sensibo Air) becoming unavailable. Once they become unavailable, the only way that I am able to get them back is by restarting Home Assistant.

What version of Home Assistant Core has the issue?

2023.1.2

What was the last working version of Home Assistant Core?

(several months ago - I update regularly)

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Homekit

Link to integration documentation on our website

https://www.home-assistant.io/integrations/homekit/

Diagnostics information

've attached a verbose log file below.

The HomeKit device "Exercise Room Thermostat" was reported unavailable 1/15/2023 23:56:30

This device is 192.168.86.59 in the log, and you can see the failures in the verbose logging below:

2023-01-15 23:56:18.907 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Connection HomeKitConnection(host='192.168.86.59', port=80) lost. 2023-01-15 23:56:19.098 DEBUG (MainThread) [aiohomekit.controller.ip.connection] 192.168.86.59: raw response: bytearray(b"\x06\x01\x02\x03 \x0c\xb5\xcd\xa1\xdc~B\xd6{\x07\xcf\xd4\xed\xe6i\x9d\x93\xad\xdf\xb6\x053\x00\\x12*\x16\xcd,\xbd\xdcZ\x05e\rm\xc1\xec\xef`\x821X{\x99R%\xe8O\xcc\xd0\xc1\x03!.\xf1B\x85\x87\xde6O\x96\xeat\xb9pS\xa7#LqO\x1a\xf1D\x7f9>\xf0\r\x9a^\x19\xf3\xf4\xaa]\xf3!\xb7\xb1A%\x9b\xc5\x95[\xfd\x1dS3\x8d\xcf\xa9\xa7\xbb\xe0'\x1f\xbf\x9e\x15\x8a\xad\xa0\x052\xa6l\x10w\xae\xca\xe5\xbcx\\x86+V\x04\xf2o\xb1") 2023-01-15 23:56:19.817 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:5010 2023-01-15 23:56:21.609 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:5010 2023-01-15 23:56:22.253 DEBUG (MainThread) [aiohomekit.controller.abstract] [192.168.86.59:5010] (id=B7:C8:05:85:95:1D): Accessories cache loaded (c#: 0) (gsn: None) (has broadcast_key: False) 2023-01-15 23:56:22.253 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Starting reconnect loop to 192.168.86.59:5010 2023-01-15 23:56:22.253 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:5010 2023-01-15 23:56:23.128 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:5010 2023-01-15 23:56:24.197 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:5010 2023-01-15 23:56:24.323 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:5010 2023-01-15 23:56:26.025 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:5010 2023-01-15 23:56:28.595 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:5010 2023-01-15 23:56:30.206 DEBUG (MainThread) [homeassistant.components.homekit.accessories] New_state: <state climate.exercise_room_thermostat=unavailable; hvac_modes=[<HVACMode.OFF: 'off'>, <HVACMode.HEAT: 'heat'>, <HVACMode.COOL: 'cool'>, <HVACMode.HEAT_COOL: 'heat_cool'>], min_temp=50, max_temp=100, friendly_name=Exercise Room Thermostat, supported_features=ClimateEntityFeature.TARGET_TEMPERATURE @ 2023-01-15T23:56:30.203886-08:00>

One thing I noticed earlier in the log is this: 2023-01-15 23:55:20.200 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Host changed from 192.168.86.26 to 192.168.86.59 2023-01-15 23:55:20.200 DEBUG (MainThread) [aiohomekit.controller.ip.connection] Attempting connection to 192.168.86.59:80

All of the homekit devices have static IP's, so I don't understand what this means (192.186.86.26 is a different homekit device).

If there's any more that I can do to help debug this, please let me know.

homekit-disconnect.log

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @bdraco, mind taking a look at this issue as it has been labeled with an integration (homekit) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of homekit can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Change the title of the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign homekit Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

homekit documentation homekit source _{^{(message by IssueLinks)}}

[dgrove]

A few other debugging steps I took:

1. Reboot the homekit device and reload integration in HA. No improvement.

2. Then I reconnected the hk device to wifi, and reloaded the integration. No improvement.

3. Then I restarted HA, and the device became available immediately.

[mattsains]

I am having this problem too, after updating to 2023.1.4. restarting hass works, but not reliably. It can also take less than 20 minutes to become unavailable again after a restart

[LordNex]

Ditto here. I haven't used the Home Kit for a while but thought I'd see if it was better with 2023.1.4. It pulled in a bunch of devices at first and seemed like communication was working but then everything went unavailable. I'm wondering if I'm going to need to setup my iPad as a hub and make sure it's on and home all the time.

[mgguinne]

I read on another forum post that the version of the home hub could be the reason, aka if they are on different versions. I started getting this issue only after upgrading my iPhone/iPad to 16.3. I'm Going to upgrade all my Apple TV's now.

Funny thing for me is that my garage door works fine, but all my MQTT fans show as "No Response" :(

[mgguinne]

Sorry I got that wrong, I had 2 Home Assistant servers running (I was going to migrate, so restored my backup to it), once I deleted home from the 2nd one (The one I was not going to migrate to), it started working again :(

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[home-assistant[bot]]

homekit documentation homekit source

[home-assistant[bot]]

Hey there @jc2k, mind taking a look at this issue as it has been labeled with an integration (homekit_controller) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of homekit_controller can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign homekit_controller Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

homekit_controller documentation homekit_controller source _{^{(message by IssueLinks)}}

[iLuckyW]

Did you find a fix for that problem @dgrove ? I am having the same issue.

[JHPWBN]

Hi, I am relatively new to Home Assistant and working my way thru all the Integrations which I could use. I have installed the HomeKit Integration yesterday and test-wise added an EVE Door/Window Sensor to it. This morning it was unavailable. I open and closed the sensor, which was shown in HA Overview, then the Sensor became unavailable again. After restarting HA it is now shown as available. I’ll monitor and report any changes when they occur. Let me know if (and how) I can send a log-file.

P.S. I have a large EVE Installation. If anyone knows of a better way to integrate EVE instead of each individual component thru HomeKit I would be much obliged. I have looked at the Thread Integration which needs URL to connect to my AppleTV, but I can not get that to work.

[JHPWBN]

I checked this morning and the EVE Door/Window Sensor became unavailable yesterday afternoon. I opened and closed it, this was shown in HA Overview, but again it became unavailable immediately thereafter. I tried to reload the HomeKit Device integration. This failed: “Failed to unload”. It looks like this Integration is not going to work for me as I can not depend on it.

Is anyone reading these comments?

[Jc2k]

For your device I'd say upgrade to matter. Matter development is more active. HA Matter has people paid to work on it. Homekit does not.

[JHPWBN]

Good morning and thanks for your suggestion. I will give that a try, the issue is that most of my EVE Equipment are Thermostats and Water, which can not be upgraded to Matter yet. The Window Sensor was only meant as a test.

[Jc2k]

That's a real shame. I have 6 Eve devices that work mostly fine with thread. (5 thermo, 1 energy). My other Eve devices are still on Bluetooth. Things here are much more stable compared to yours, but that's thread for you.

If thread is unstable with those devices and you can't wait for matter or for me to have oodles of free time, the best I can suggest is that homekit bluetooth should be more stable than thread right now, and you can use esphomes bluetooth proxies as range extenders. Then upgrade to matter when the firmware updates come out.

[JHPWBN]

Thanks Jc2k, I have only started with HA last week and am in the process of learning whats is possible (lots of learning to do :-)). Until now I manage my Thermostats in Apple Homekit and will leave it like that until they are Matter capable and HA Matter is out of Beta status.

[littlecake]

Did someone find any solution?

[bdraco]

2023-01-15 23:56:14.885 DEBUG (MainThread) [aiohomekit.zeroconf] cd:d3:21:63:6a:bb: Notifying pairing of description update: HomeKitService(name='Sensibo-9AE3C8', id='cd:d3:21:63:6a:bb', model='Sensibo Air', feature_flags=<FeatureFlags.SUPPORTS_SOFTWARE_AUTHENTICATION: 2>, status_flags=<StatusFlags.0: 0>, config_num=2, state_num=612, category=<Categories.THERMOSTAT: 9>, protocol_version='1.1', type='_hap._tcp.local.', address='192.168.86.26', addresses=['192.168.86.26', '169.254.201.227', '192.168.86.151', '192.168.86.59', '192.168.86.18', 'fe80::36ab:95ff:fe91:cddc', 'fe80::963c:c6ff:fe4e:d610', 'fe80::8ece:4eff:fe9a:e3c8'], port=80)

[bdraco]

2023-01-15 23:54:38.119 DEBUG (MainThread) [zeroconf] Received from '::ffff:192.168.86.59':5353 [socket 15 (('::', 5353, 0, 0))]: <DNSIncoming:{id=0, flags=33792, truncated=False, n_q=0, n_ans=3, n_auth=0, n_add=2, questions=[], answers=[record[a,in-unique,MyHost-2.local.]=120/119,192.168.86.59, record[quada,in-unique,MyHost-2.local.]=120/119,fe80::8ece:4eff:fe9a:e3c8, record[srv,in-unique,Sensibo-9AE3C8._hap._tcp.local.]=120/119,MyHost-2.local.:80, record[a,in-unique,MyHost-2.local.]=120/119,192.168.86.59, record[quada,in-unique,MyHost-2.local.]=120/119,fe80::8ece:4eff:fe9a:e3c8]}> (164 bytes) as [b'\x00\x00\x84\x00\x00\x00\x00\x03\x00\x00\x00\x02\x08MyHost-2\x05local\x00\x00\x01\x80\x01\x00\x00\x00x\x00\x04\xc0\xa8V;\xc0\x0c\x00\x1c\x80\x01\x00\x00\x00x\x00\x10\xfe\x80\x00\x00\x00\x00\x00\x00\x8e\xceN\xff\xfe\x9a\xe3\xc8\x0eSensibo-9AE3C8\x04_hap\x04_tcp\x05local\x00\x00!\x80\x01\x00\x00\x00x\x00\x08\x00\x00\x00\x00\x00P\xc0\x0c\xc0\x0c\x00\x01\x80\x01\x00\x00\x00x\x00\x04\xc0\xa8V;\xc0\x0c\x00\x1c\x80\x01\x00\x00\x00x\x00\x10\xfe\x80\x00\x00\x00\x00\x00\x00\x8e\xceN\xff\xfe\x9a\xe3\xc8']

[bdraco]

Looks like a mdns issue.

It seems like multiple sensibo devices are getting mixed together.

Is there some type of mdns forwarding going on?

[bdraco]

It looks like the device likely isn't handling record conflicts correctly. That's not normally an issue because it will eventually fix itself but since the debouncer holds on to the records past the TTL it never evicts them until the device falls off the network or you restart HA

https://github.com/Jc2k/aiohomekit/blob/fa14889191003aeabc1bdf9deaa229e839561a2e/aiohomekit/zeroconf.py#L263