I’m using a Sonoff Zigbee contact sensor paired with a Sonoff Zigbee Bridge Ultra, which is integrated with iHost. The sensor state shows correctly and updates in real time in the eWeLink app, so the Zigbee communication and cloud sync are clearly working.
However, in Node-RED running on iHost:
The get-devices node (Cube/Vibe) always reports contact: true, even when the door is open.
The event state node does not emit anything when the sensor is triggered.
I’ve rebooted iHost, re-triggered the sensor multiple times, and even accessed Node-RED from a different machine — same result.
So:
The bridge and sensor are working.
iHost receives no real-time updates into Node-RED.
This worked briefly when I first set it up yesterday, but then stopped.
It appears the iHost integration with the Zigbee Bridge is not reliably forwarding state changes to Node-RED.
Any guidance? Is this a known issue or a limitation of the current Cube/Vibe integration with Zigbee Bridge?
I’m using the built-in eWeLink CUBE OS on iHost, not Home Assistant.
Node-RED is running directly on iHost, but I’ve also tested the exact same flow on a separate Node-RED instance on my PC — same result in both cases.
The Sonoff Zigbee Bridge is not integrated with iHost — it’s a standalone Zigbee Bridge connected to the LAN, and all devices (including the contact sensor) are paired to it.
I’m using a valid eWeLink token in the Cube node to access the bridge-connected devices.
What’s happening:
The eWeLink app shows correct, live updates when the contact sensor changes.
But in Node-RED:
get-devices always returns contact: true
event state never emits anything
Reboots, re-pairing, or switching machines make no difference.
This setup worked briefly when I first added it, then stopped updating in Node-RED — even though eWeLink app still updates as expected.
It seems like live events from the Zigbee Bridge are not being pushed to Node-RED, or the token access is pulling from a stale cache.
I need to confirm some information in order to help troubleshoot the issue:
Is the Sonoff Zigbee Bridge Ultra integrated with iHost via the eWeLink Smart Home add-on?
Is the Sonoff contact sensor you are using model SNZB-04P or SNZB-04?
While the contact sensor status is displayed correctly in the eWeLink App, is it also displayed correctly and updated in real-time on the iHost device card? In other words, is it only Node-Red that isn’t updating the sensor status in real-time?
Please check if the get-devices node and event-state node in Node-Red are configured correctly. You can refer to the configuration in the image below.
Is the Sonoff Zigbee Bridge Ultra integrated with iHost via the eWeLink Smart Home add-on?
Yes it is.
Is the Sonoff contact sensor you are using model SNZB-04P or SNZB-04?
It is SNZB-04P
While the contact sensor status is displayed correctly in the eWeLink App, is it also displayed correctly and updated in real-time on the iHost device card?
Yes, correct. It is displayed correctly on both Ewelink and Ihost but not on nodered.
In other words, is it only Node-Red that isn’t updating the sensor status in real-time?
Yes, correct.
Please check if the get-devices node and event-state node in Node-Red are configured correctly. You can refer to the configuration in the image below.
Yes, it is configured correctly. The device is returning the information but it is not correct.
My application is to show the status of the garage doors on a display kiosk (Pi4 +Display) pointing at the UI on Ihost nodered flow because the doors are not visible from the house. It worked properly for the first few hours then 24 hours later I noted that the status open/closed wasn’t changing anymore and realised this issue as described above.
As at now looks like it is working again but I dint make any change in the flow, neither I rebooted devices or fiddled with the system.
Thanks again for your support. I’ve been doing some additional testing and wanted to share what I’ve observed — while keeping in mind that there may be technical details I’m not seeing from the outside.
It appears that the issue may be related to Zigbee signal reliability between the sensor and the Sonoff Zigbee Bridge(which is operating as a standalone bridge on the LAN). When the contact sensor is placed further from the bridge — possibly near the edge of signal range — the following behaviour occurs:
The eWeLink app continues to show the correct state changes.
In Node-RED (using the get-devices node), the contact status does not reflect the physical state of the sensor.
The event state node also does not emit any update when the contact changes.
What’s returned in Node-RED appears to be the last known contact state, not a live value.
When I moved the sensor closer to the Zigbee Bridge and triggered it a few times, the correct state was then reflected in Node-RED again. This suggests that when the device is out of good range, the bridge may be unable to retrieve the live status and instead returns a previously stored value.
That’s just my working theory based on observed behaviour — I fully appreciate that the internal design or fallback mechanisms may be more nuanced.
I would just add that this behaviour could potentially be misleading for automations if consumers of the API (like Node-RED) interpret stale values as live status. If feasible, it might be helpful if the API could distinguish between a confirmed state and a cached one — or indicate when a device is currently unreachable.
Open to any correction or advice on how best to handle this from your side.
We didn’t find unusual activities in your log.
Is the problem still persist?
Can you reproduce the problem and send the log again?
With the exact timing of the problem would be more helpful.
I have reproduced the issue and confirm that the issue show up when the sensor is at the edge of the ZigBee signal.
“When I moved the sensor closer to the Zigbee Bridge and triggered it a few times, the correct state was then reflected in Node-RED again. This suggests that when the device is out of good range, the bridge may be unable to retrieve the live status and instead returns a previously stored value.”
So, the issue doesnt show up on nodered logs as a anomaly.
Looking forward to improvements …
Kind regards and thanks a million for your support
Felice
As the post above, both the iHost and eWelink app continue to receive reports from the SNZB-04P; only Node-RED fails in this regard. And further more, since Node-RED receives all its data through iHost, iHost would necessarily be the first point of failure if this were a signal range issue - not Node-RED.
This leads me to think the problem likely originates within the Node-RED plugin implementation. However, without precise timestamps and corresponding log, we cannot pinpoint the proper cause.
Kindly reproduce the issue and submit the exact timing details along with relevant log.
Please allow me a couple of days to try and reproduce the issue. I’m currently away fly fishing for a long weekend and will be back on Monday. I’ll gladly assist from my side to help identify the cause. I plan to include timestamped logs from Node-RED showing if and when the data is received, so we can compare it with the expected events.
I’ll share the results as soon as I’ve run the test.
Wow, a pretty wild weekend.
Happy fishing!
Just hope your phone has better signal out there than that sensor does!
(But seriously, hope you catch a big one!)
I’ve successfully reproduced the issue under controlled conditions and can now describe a clear and repeatable procedure for your team to replicate it directly.
To avoid the complexity of reproducing the problem in the field, I tested a brand-new SNZB-04P sensor at home, paired with a Zigbee Ultra. Under normal conditions, the sensor reports correctly across iHost, the eWeLink app, and Node-RED via the iHost plugin — including full payload and accurate state transitions (open/close).
Replication procedure:
Pair a new SNZB-04P sensor and verify normal operation (contact open/close) across iHost and Node-RED.
Leave the sensor in a closed state.
Wrap the sensor completely in aluminium foil, simulating a strong RF isolation scenario.
While still wrapped, open the contact (separate the magnets).
Observe that:
iHost and the eWeLink app continue to display the sensor as closed and online.
Node-RED continues to receive the same (now stale) state from iHost.
This test simulates the exact condition a user would encounter when a sensor is placed at the edge of Zigbee coverage or suffers from intermittent or degraded signal quality — which is a realistic and frequent scenario in larger installations or in metal enclosures.
Importantly, once the foil is removed and the sensor is no longer RF-isolated, it does not automatically resume communication. The status remains stale until the physical button on the sensor is pressed, at which point it reconnects — but the contact state is updated only after the magnet is used again to re-trigger the contact.
This confirms that the system does not handle RF disconnection or sensor unavailability correctly:
The last-known state is retained and served to Node-RED, without any indication of communication loss.
No timeout or offline status is triggered.
And even after RF conditions are restored, status synchronization only resumes after manual intervention.
Given how straightforward it is to reproduce the issue with this method, I am not attaching logs — they would not provide any further insight beyond what you can observe directly using the steps above.
I trust this procedure will point you in the right direction, and I look forward to your findings and to any improvements you may implement to make device availability and state handling more robust in such scenarios.
By the way … I did catch a really big fish during the weekend
Just to clarify: the purpose of wrapping the SNZB-04P in aluminium foil is to simulate signal loss or degraded RF conditions, similar to what can happen when a sensor is at the edge of Zigbee coverage like in my case before I moved the Zigbee Bridge to solve the issue. In this case, iHost and the eWeLink app continue to display the sensor as “closed” and “online”, even though it is no longer reachable.
This is not a hardware fault, but rather a limitation in how device disconnection is handled. If a device becomes unreachable, the system should indicate relatively quickly it as “offline” and the status should be set to “unknown”, rather than continuing to display the last known state as if it were current.
I’ve focused on the SNZB-04P because that’s where I encountered the issue. I haven’t tested other devices under similar conditions. However, I just ordered a SONOFF DW2: WI-FI WIRELESS DOOR/WINDOW SENSOR which I intend to test in the same conditions. Will share the outcome.
