Third-party apps have been mentioned a few times, so I wanted to clarify what's going on there. Let me start by going back to the post that started all of this to explain what's actually happening here:
When I launch the app, it indicates that the hub is not responding, and all of my devices are unavailable.
One of the fundamental problems with all network applications is that:
a) Users want to "know" whether or not something will "work" before they perform that action.
b) Networking is an inherently high-latency activity with unpredictable results.
Putting that in concrete terms, how does an app "know" that an accessory (or any network connection) is "working", given that a hammer, shovel, or power outage could destroy the device or infrastructure the app is relying on? The app can "check" whether or not something is working by doing some kind of communication, but ALL that will tell that app is that the connection... worked in the past. It won't actually guarantee ANYTHING about the operation you're doing "now".
The answer is that it doesn't know. That is, ANY app that's showing some kind of "status" is relying on some combination of:
-
Showing you "old" state that it retrieved.
-
Periodically communicating to determine what the "current" state of things "is".
That dynamic is what explains behavior like this:
Siri is also able to consistently control my devices without an issue.
The difference here is that Siri doesn't try to retrieve any state; it just sends the command and waits to see what happens. It's also willing to wait a bit longer for a given command, since it's focused on that specific command, not updating a full interface.
Similarly:
However, on the menu bar at the bottom, if I switch to "Automation" and back to “Home," the pop-up goes away, and my devices are accessible again (sometimes this takes a few attempts).
...if you pay very close attention to Home.app's interface, you can actually see it "Updating" accessory state. It doesn't do this at every app open, but it will trigger on some interface interaction, "cold" app launches, opening after delays, etc.
The "Automation" case above is actually a funny example of this, as what actually triggered the update was going INTO "Automation", NOT returning to the Accessory list. HomeKit is designed around a distributed database architecture which stores ALL accessory data (including Automations) and which is then shared among all clients. So, step #1 of viewing your Automation list is "checking to see if it is up to date"... which means communicating with the Home Hub. If it's able to establish communication, the Home Hub often sends up sending the full accessory state as well, updating the UI.
FYI, if you touch an unresponsive device, Home.app will actually retry communication with that accessory.
With all that context, let me go back to here:
All home hubs are on iOS 26.2. Native apps for my HomeKit devices all work fine (IKEA, Meross, Eve, Aqara, Fibaro) both locally and remotely.
But I've been able to reproduce the issue outside of the Home app. Yesterday, I downloaded and installed an app called HomeCare.
The difference you're seeing here is primarily a question of interface design, not underlying functionality. The specifics depend entirely on the app’s implementation but, for example:
-
Some apps use HMCharacteristic.value (which can return a cached value) instead of issuing their own readValue()
-
Some apps automatically retry read failures, which will tend to "mask"
-
Many apps poll faster than Home.app, as faster polling makes the app appear faster/more responsive, at the cost of wasted network I/O.
Note that all of these are really design choices without any fundamentally right or wrong answer. There's a pretty broad implementation range where I could flip a coin and make a very strong case both for and against that particular implementation.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
