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!)
