is it just me or there’s a bug on version 2.6.0 of the ZBBridge-U where the status of the security mode reported via MQTT or MATTER is not updated if the change is triggered by a scene?
It gets updated in Home Assistant and MATTER fabrics if the change is made directly on the ZBBridge-U tile itself, but if triggered by an automated or manual scene the mode itself changes, but the MQTT/MATTER reported one is not and the status goes out of sync.
I think that the security mode is a cloud side thing, it doesn’t reside on the ZBBridge-U, therefore unless the change starts from the bridge itself there isn’t the code on the cloud to call back and tell the bridge to update the MQTT/MATTER statuses.
Can someone else check if it is the same on your side too?
I’ve been testing this function, and it works perfectly—both when the hub is connected to the internet and when it’s offline! It also worked correctly via MQTT in Node-RED.
That’s strange… in my case the value is updated if I change it manually, but it is not if the change is triggered by a scene. It’s consistent… any change made via the app or EWeLink web also updates the Matter and Mqtt entries, whilst if the change is made by a scene they are not updated. Maybe it is due to the type of bridge? I have a bridge-ultra..
You are speaking about Node-RED, so maybe you are using an iHost?
I actually have an iHost on the network, but I use a direct Node-RED connection via MQTT, and all changes made via MQTT are reflected correctly. Where do you create the scenes you’re talking about? I have scenes created via MQTT and Matter that use the Zb Ultra’s security system! I don’t use scenes created via eWeLink.
I believe that is the core idea.Scenes created on iHost or Home Assistant update the security system status correctly through Matter or MQTT because they modify it directly. The EWeLink scenes are where I encounter issues; they appear to alter the status only on the cloud side, failing to reflect it in local Matter and MQTT variables. You can test this quickly with an EWeLink scene, but not with an iHost, as that would operate locally. It seems only zbbridge u, max, and nspanels should be affected—at least if my intuition is accurate. Now if we could get someone from Sonoff on the thread to confirm this..
So, all my ZBULTRA scenes run locally!
However, I imagine that scenes created in the eWeLink app—unless they involve direct Zigbee-to-Zigbee communication—must rely on some cloud component!
Everything of mine on the ZBUltra is local, so I don’t experience any issues!
I only use the eWeLink app occasionally to trigger a device here or there, but I don’t keep any scenes set up in it. Because if you use anything involving timing or the like, that scene becomes dependent on the cloud!
Checked, no errors.. in fact the automation works fine and the status of the security system is changed. Only the matter and mqtt variables aren’t. This happens on all the clients in the matter fabric. I understand relying on EWeLink scenes is sub optimal but this still seems to be a bug
Hello, thank you for your feedback. We sincerely apologize for the unpleasant experience. To help us investigate this issue as soon as possible, please cooperate with the following steps:
Please trigger the scene again and send us the logs, and provide your ZBBridge-U Device ID.
Please provide the trigger conditions and actions of the automation scene, as well as the models of the devices involved in the scene.
Please submit the logs via the eWeLink App: go to “My” → “Problem Feedback”, select the corresponding ZBBridge-U device, and be sure to check “Upload logs”. After submitting, please let us know the approximate time.
Once we receive this information, our technical team will further investigate with the system logs. Thank you for your cooperation and support!
thank you for your reply and for the detailed instructions.
Unfortunately I wasn’t able to wait for a fix: I only had the last few days of my withdrawal period left, and since this feature was fundamental for my setup, I had to return the ZBBridge-U. In the meantime I’m handling everything with Home Assistant. As a result, I no longer have the device and can’t debug this with you or provide the logs and Device ID.
That said, the bug is very easy to reproduce on your side, so I hope this helps your team:
Set up the ZBBridge-U.
Connect it via Matter to a controller and expose the security mode.
Connect it via MQTT to Home Assistant and expose the security mode as well.
Create an automation in eWeLink Cloud (not local, not iHost) that changes the security mode.
When the automation runs, the change is not reflected in the variables exported via MQTT and Matter.
This doesn’t fix itself with time.
The opposite direction works correctly: if the security mode is changed from the MQTT or Matter side, the change is properly reflected in eWeLink Cloud.
So the problem seems limited to state changes triggered by eWeLink Cloud scenes and automations, which apparently don’t propagate to the local MQTT/Matter layers.
Thanks again for your support. I’d be happy to reconsider the device once this is fixed.
