# iHost not receiving contact sensor updates from Zigbee Bridge in Node-RED **URL:** \ **Category:** Free talk\ **Tags:** zigbee\ **Created:** [July 8, 2025, 2:19pm UTC](https://forum.ewelink.cc/t/ihost-not-receiving-contact-sensor-updates-from-zigbee-bridge-in-node-red/190085 "2025-07-08T14:19:11Z")\ **Posts on this page:** 4\ **Page:** 2
**Author:** ![SuiKa](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.ewelink.cc/suika/32/8656_2.png) [@SuiKa](https://forum.ewelink.cc/u/SuiKa)\ **Post date:** [July 17, 2025, 7:18am UTC](https://forum.ewelink.cc/t/ihost-not-receiving-contact-sensor-updates-from-zigbee-bridge-in-node-red/190085/21 "2025-07-17T07:18:35Z")
After confirming with our development team, the reconnection logic between the SNZB-04P sensor and the ZBB-U is as follows: 1. **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. 2. **Manual Reconnection:** Pressing the reset button briefly will immediately trigger a 30-second reconnection attempt. ---
**Author:** ![FeliceM](https://avatars.discourse-cdn.com/v4/letter/f/ec9cab/32.png) [@FeliceM](https://forum.ewelink.cc/u/FeliceM)\ **Post date:** [July 17, 2025, 2:18pm UTC](https://forum.ewelink.cc/t/ihost-not-receiving-contact-sensor-updates-from-zigbee-bridge-in-node-red/190085/22 "2025-07-17T14:18:01Z")
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. ---
**Author:** ![SuiKa](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.ewelink.cc/suika/32/8656_2.png) [@SuiKa](https://forum.ewelink.cc/u/SuiKa)\ **Post date:** [July 18, 2025, 6:38am UTC](https://forum.ewelink.cc/t/ihost-not-receiving-contact-sensor-updates-from-zigbee-bridge-in-node-red/190085/23 "2025-07-18T06:38:07Z")
> [@FeliceM](#): > > 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. 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. * * * > [@FeliceM](#): > > - Flag the device as **offline** after a defined timeout 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. ---
**Author:** ![FeliceM](https://avatars.discourse-cdn.com/v4/letter/f/ec9cab/32.png) [@FeliceM](https://forum.ewelink.cc/u/FeliceM)\ **Post date:** [July 18, 2025, 7:03am UTC](https://forum.ewelink.cc/t/ihost-not-receiving-contact-sensor-updates-from-zigbee-bridge-in-node-red/190085/24 "2025-07-18T07:03:25Z")
Hi SuiKa > [@SuiKa](#): > > 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. 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 . [Previous page](https://forum.ewelink.cc/t/ihost-not-receiving-contact-sensor-updates-from-zigbee-bridge-in-node-red/190085.md?page=1)