I am working on an app (iOS, iPadOS & macOS (Mac Catalyst)) for a Home Automation device. I am using HomeKit APIs to access commissioned devices and provided APIs to get a MatterNodeID and then a MTRBaseDevice so I can query the device. Since the current APIs for accessing Matter devices this way do not support subscriptions I am using the readAttributes() method of the MTRBaseDevice to get information from the device. There can be significant lag time in these reads and I realize my network speed and congestion can contribute to this.
The time lag makes me wonder how readAttributes() obtains the data? Does the method query the Home hub which replies using cached data, or does the hub in turn query the device to insure it is providing the latest data? I am pretty sure all this communication goes through the hub because it works whether I am on the same network as the device or in a location far, far away.
I am working on an app (iOS, iPadOS & macOS (Mac Catalyst)) for a Home Automation device. I am using HomeKit APIs to access commissioned devices and provided APIs to get a MatterNodeID and then a MTRBaseDevice so I can query the device. Since the current APIs for accessing Matter devices this way do not support subscriptions, I am using the readAttributes() method of the MTRBaseDevice to get information from the device. There can be significant lag time in these reads, and I realize my network speed and congestion can contribute to this.
What are the final endpoints you're interacting with and, in particular, are they using Thread? On top of the "fixed" cost (more on that shortly), Thread accessories tend to increase latency. Part of that is that extra "layer" of the thread bridge and lower bandwidth, but most of that is that the accessory itself, particularly for things like battery-powered sensors or buttons. In concrete terms, there is a pretty big performance spectrum between:
-
A wall-powered Matter over WiFi accessory.
-
A wall-powered Matter over Thread accessory.
-
A battery-powered Matter over Thread accessory.
...with significant variation within those categories. I'll also note that comparing category #3 accessories to HAP accessories can be misleading, as most battery-powered HAP accessories were still built as "full" HAP accessories with relatively fairly high power usage. For example, most HAP locks are relatively responsive because they're WiFi accessories and use large batteries to compensate for the power cost. That makes them FAR more like #1 than #3.
I am pretty sure all this communication goes through the hub because it works whether I am on the same network as the device or in a location far, far away.
Assuming a HomeHub is active then, yes, commands get routed through the HomeHub. If thread is involved, that also adds an additional requirement and configuration complexity.
The time lag makes me wonder how readAttributes() obtains the data? Does the method query the Home hub, which replies using cached data, or does the hub in turn query the device to ensure it is providing the latest data?
There may be some variance based on the accessory type (particularly sensors), but in general, yes, the read goes to the endpoint instead of using cached data.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
