After confirming with our development team, the reconnection logic between the SNZB-04P sensor and the ZBB-U is as follows:
Automatic Reconnection: The sensor will periodically attempt to reconnect to the ZBB-U. The interval between attempts increases progressively — starting from 1 minute, then 5 minutes, and so on, up to a maximum of 720 minutes. Each reconnection attempt lasts for 30 seconds.
Manual Reconnection: Pressing the reset button briefly will immediately trigger a 30-second reconnection attempt.
Thanks for clarifying the reconnection mechanism — that makes sense and is appreciated. I have not tested it extensively on my side.
However, the core issue I’m raising is not about the reconnection intervals, but about how the system behaves during disconnection. After more than 30 minutes of the sensor being physically unreachable, the iHost and eWeLink app still display it as “closed” and “online”, even though the device is clearly offline and the contact is open.
In this state, the system continues to present stale data as if it were current. There’s no indication of a communication failure, no timeout, and the contact status is not marked as unknown.
This can lead to misleading information, especially in use cases like intrusion detection or door monitoring, where reliability matters. A user could assume everything is secure when the sensor is no longer communicating.
Ideally, the system should:
Flag the device as offline after a defined timeout
Mark its status as unknown
Update Node-RED and the UI accordingly
As it stands, the sensor cannot be trusted to reflect the actual state when communication is lost — which is a concern for any serious monitoring application.
Previously, you mentioned wrapping the SNZB-04P with aluminum foil and triggering the contact sensor while it was inside the foil. However, neither the iHost nor the eWeLink app received any reports.
Actually, the device did send the report, but the connection to the ZBB-U was interrupted due to the shielding effect of the aluminum foil. As a result, the message wasn’t successfully received. Moreover, the SNZB-04P does not have a mechanism to re-send the last reported state after reconnecting to the ZBB-U.
That’s why you didn’t receive any “open” report fron SNZB-04P.
Regarding the offline mechanism of the SNZB-04P, the ZBB-U currently has a timeout threshold of 5 hours for SNZB-04P. This means if the device does not report any data within a 5-hour window, the ZBB-U will then consider it offline and notify the eWeLink app accordingly.
As a result, the SNZB-04P will not be marked as offline immediately after disconnection or timeout.
The explanation above is intended to clarify any confusion you may have regarding the device mechanism. As for your frustration with this design, we completely understand.
We acknowledge that this mechanism may indeed lead to some inconvenience in actual use. We will internally review and discuss the current design, and consider whether adjustments or optimizations are necessary.
Thank you for taking the time to share your thoughts and raise the issue. Feedback like yours is incredibly valuable to us — it helps us better understand what we can improve. We truly appreciate it.
this is not what I experienced. I left the device wrapped in foil for more than 12 hours. It was still showing online and reporting the last known status.
However thanks for your kind followup. I agree that the mechanism of communication needs some good review .