If the lock's status changes while the device is powered off, causing a mismatch between the lock and the Apple Hub, how can I immediately update the status upon powering on?
If the lock's status changes while the device is powered off, causing a mismatch between the lock and the Apple Hub, how can I immediately update the status upon powering on?
Hello,
If the real life state is different than the lock -- a write interaction on the LockState attribute is needed. If the Door Lock device is offline and has the correct state, a read interaction or a subscribe interaction is needed on reconnection to the hub. See the relevant sections in the Matter Specification, i.e. Chs. 8.2.2-8.2.4 in R1.3.
Best regards,
Maria
I tried to update the device status to the Hub when powering on, but it actually made the situation worse. It now takes even longer to connect to the Hub. As per your suggestion, how can I know when the device has reconnected to the network?
Hello,
SunHuang said:I tried to update the device status to the Hub when powering on, but it actually made the situation worse. It now takes even longer to connect to the Hub.
Could you tell me a bit more about how you implemented this? Your question indicates that you are on a good track with finding the reconnection state. Once the lock is connected to the hub, the attribute can be performed updated.
On power cycles, the device state can be unknown until the next actuation and still follow the Matter specification (Application Cluster R1.4 Ch. 5.2.9.1).
You can also look into using the LockOperation Event when there state on the device is different from the last recorded state (Matter Application Cluster specification R1.4 Ch. 5.2.11.3).
SunHuang said:how can I know when the device has reconnected to the network?
You can make use of the DefaultMatterEventHandler function which will be called when there is a connectivity event. When isNetworkProvisioned is true, the device is connected to the network.
Best regards,
Maria
Hi,
Sorry for the delayed response. My testing method involves cutting power to the lock device and then changing its state(lock device), causing the device and the Apple Home App to be out of sync. I tested the isNetworkProvisioned parameter as you suggested, but it does not guarantee a stable network connection. This is because, at that moment, I observed that the Apple Home App had not yet synchronized with the device
Hi,
You can also use the Thread state to check when the device is attached. When the state is detached, Thread is enabled but the device is not connected to a network. Once it changes from detached to child, router, or leader, it has connected to the Thread network.
So you can add something similar to this for the kThreadStateChange case in the DefaultMatterEventHandler():
case DeviceEventType::kThreadStateChange:
if (event->ThreadStateChange.RoleChanged) {
switch (otThreadGetDeviceRole(openthread_get_default_context)) {
case OT_DEVICE_ROLE_CHILD:
case OT_DEVICE_ROLE_ROUTER:
case OT_DEVICE_ROLE_LEADER:
// child, router or leader means the device is connected
break;
case OT_DEVICE_ROLE_DISABLED:
case OT_DEVICE_ROLE_DETACHED:
default:
// disabled or detached means the device is not connected
break;
}
}
Please note that the role can change between child, router, and leader while the device is connected to the network. Therefore, I recommend adding some logic to check if the device is already connected or verify that it is the first time it has changed to one of those three roles after a reboot so that you only change the lock state when the device connects to the network and not if the role changes while it is already connected.
Best regards,
Marte
Hi,
You can also use the Thread state to check when the device is attached. When the state is detached, Thread is enabled but the device is not connected to a network. Once it changes from detached to child, router, or leader, it has connected to the Thread network.
So you can add something similar to this for the kThreadStateChange case in the DefaultMatterEventHandler():
case DeviceEventType::kThreadStateChange:
if (event->ThreadStateChange.RoleChanged) {
switch (otThreadGetDeviceRole(openthread_get_default_context)) {
case OT_DEVICE_ROLE_CHILD:
case OT_DEVICE_ROLE_ROUTER:
case OT_DEVICE_ROLE_LEADER:
// child, router or leader means the device is connected
break;
case OT_DEVICE_ROLE_DISABLED:
case OT_DEVICE_ROLE_DETACHED:
default:
// disabled or detached means the device is not connected
break;
}
}
Please note that the role can change between child, router, and leader while the device is connected to the network. Therefore, I recommend adding some logic to check if the device is already connected or verify that it is the first time it has changed to one of those three roles after a reboot so that you only change the lock state when the device connects to the network and not if the role changes while it is already connected.
Best regards,
Marte