Recently, apple released iOS 16.2 (tvOS 16.2, iPadOS 16.2, MacOS 13.1), which includes a “new architecture” for Apple Home, which according to this page, basically boils down to “home hubs are periodically polling accessories for state, and push it all in one go to devices who need it”
Can anyone here maybe verify that they upgraded their home to the new architecture, and that their homekit integration with Apple Home kept on working? Or what kind of experiences have you had, following that upgrade?
I’m trying to decide if I should pull the trigger or not, or if I should wait for dust to settle.
Facing the same challenge with all thread connected eve thermostats. All disconnected and no chance to add them back.
My procedure ws to first update iPhone, then have it upgrade my home, realised homekit controller device wobt function, rebooted, no change, updates Apple TV to 16.2 and tried again. Still same issue.
Same problem here. Almost all Thread devices are no longer accessible via the HomeKit controller. For me, this also affects the majority of Eve thermostats. Are there already solutions to the issue here? Is it actually known whether you can manage those devices without the HomeKit controller in the future, with Eve devices that will support Matter (Eve Thermo?)?
I did the Home architecture update yesterday. Only have HA accessories and Apple devices.
Yesterday it worked fine after couple of minutes (and a restart).
Today the HA accessories often don’t react, are not available or updating for a long time.
When trying again (~after an hour) it may suddenly start working again after some tries.
Have power cycled the Apple TV and HomePods and restarted HA. 🤷
It’s essentially unusable.
Thread devices not being accessible is actually significant for me, as i check their reachability often with pings, and apple closing off their subnet to them seems counterproductive?
I remember a lot of talk about how thread is just accessible to the home network as a ipv6 subnet, and the homepods would just advertise themselves as routers, so they probably either forgot it, or specifically closed off that avenue.
Currently (while not upgraded), i see openthread.thread.home.arpa in my network tab in Finder, which iirc corresponds to the effective domain of thread devices, so something is advertising it.
For reference, I only currently have a HomePod Mini, a NanoLeaf essentials light, and some eve rooms and eve plugs (and an eve door+switch) connected to the thread network.
I did a full reset using the Reddit factory reset link for Home. Rebuild all from the scratch.
A little bit annoying because of cameras and doorlock which where directly connected to Home and HA at the same time because of redundancy.
Now everything is working again
Same issue for me… After the update to 16.2 on ATV and HomePods, all devices surfaced via Home Assistant have “No Response”. Restarting the integration or rebooting HA does not resolve.
After 16.2 homekit upgrade, it seems that the pairing code for hass bridge changes after some time.
Right after the upgrade, everything seemed to be working fine. Next day, i suddenly got a “No response” error.
I deleted hass bridge and readded it to home app yesterday.
Now running into a “No response” error again - and notifications shows hass bridge pairing code which is different from what I had used yesterday.
Edit: I just updated hass bridge config to add a new light and the devices went into “No response” state again.
The bridge pairing code in notifications is again different from what I had used an hour ago while re-adding
Is there any way to lock the pin/ configure it in HA to assign it a static PIN as a workaround?
Hi @J0J0 - It seems that Apple Home eventually updates. It does take forever to do so and the slow process repeats itself after each new device is added or there is a restart of HA.
Interestingly import of entities into HA (HomeKit Controller) is working fine, however, the AppleTV integration is definitely broken…
But if Apple Homekit Hub change, all accessories are inaccessible and the log of HAS appears:
de gen. 07 13:18:44 raspberrypi hass[4366]: 2023-01-07 13:18:44.781 ERROR (MainThread) [pyhap.hap_handler] (‘192.168.1.36’, 54915): Client xxx attempted pair verify without being paired to HASS Bridge first.
de gen. 07 13:18:44 raspberrypi hass[4366]: 2023-01-07 13:18:44.804 ERROR (MainThread) [pyhap.hap_handler] (‘192.168.1.36’, 54916): Client xxx attempted pair verify without being paired to HASS Bridge first.
de gen. 07 13:18:56 raspberrypi hass[4366]: 2023-01-07 13:18:56.509 ERROR (MainThread) [pyhap.hap_handler] (‘192.168.1.58’, 59159): Client xxx attempted pair verify without being paired to HASS Bridge first.
de gen. 07 13:18:56 raspberrypi hass[4366]: 2023-01-07 13:18:56.537 ERROR (MainThread) [pyhap.hap_handler] (‘192.168.1.58’, 59160): Client xxx attempted pair verify without being paired to HASS Bridge first.
de gen. 07 13:18:56 raspberrypi hass[4366]: 2023-01-07 13:18:56.610 ERROR (MainThread) [pyhap.hap_handler] (‘192.168.1.58’, 59161): Client xxx attempted pair verify without being paired to UE32J5500 first.
de gen. 07 13:18:56 raspberrypi hass[4366]: 2023-01-07 13:18:56.635 ERROR (MainThread) [pyhap.hap_handler] (‘192.168.1.58’, 59162): Client xxx attempted pair verify without being paired to UE32J5500 first.
de gen. 07 13:18:56 raspberrypi hass[4366]: 2023-01-07 13:18:56.680 ERROR (MainThread) [pyhap.hap_handler] (‘192.168.1.58’, 59163): Client xxx attempted pair verify without being paired to UE40F7000 first.
de gen. 07 13:18:56 raspberrypi hass[4366]: 2023-01-07 13:18:56.705 ERROR (MainThread) [pyhap.hap_handler] (‘192.168.1.58’, 59164): Client xxx attempted pair verify without being paired to UE40F7000 first.
