-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ZigBee devices Remote Randomness Control Failure #99187
Comments
Hey there @dmulcahey, @Adminiuga, @puddly, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) zha documentation |
To clarify, you see this behavior with the Sonoff -P dongle but not with the -E? Some questions:
|
1.The version of the coordinator we are using is At present, we have a dedicated HA environment to reproduce and track this issue. I will share more detailed information with you to analyze the problem |
You can try Z-Stack
Do note that many people report coordinator freezes/crashes after a couple of days/weeks, so that version might not be entirely stable. But you should be able to test if your problem persists on that version. Edit: Upon looking closer at your issue, I'm not sure it's related. I'd still give that new version a go though. |
|
I restarted the raspberry , but it didn't have much effect
But it's strange that the other devices below me can be controlled normally, and only this device has been unable to synchronize properly, and local control cannot synchronize properly |
Restarting won't help because the radio firmware reports 2.4GHz interference and is refusing to transmit. Make sure your coordinator is on a USB extension cable and away from interference sources such as USB 3.0 ports, SSDs, WiFi routers, etc. |
If the interference fails, it is indeed invalid to restart, but what I want to say is that there are other switch devices in the same position under this dongle that are working normally |
This behavior is not controlled via software, unfortunately. All that happens is ZHA asks the firmware to send a packet and the firmware says it cannot because the firmware sees too much interference. |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
The problem
We have discovered some abnormal control phenomena during long-term use:
Some controllers based on low-power implementation have the problem of remote control issue failure
Eg:
For single line devices such as sonoff zbminil2, the control of the device depends on the corresponding control instructions given to it by the coordinator after the device data request
However, during prolonged use, I have noticed that this device may experience a period of time when the local control is normal and can be updated normally, but the page control is malfunctioning
From Zigbee's packet capture:
usb dongle was sonoff dongle-p
The response to the frame pending bit in the device ack should be 'No', but in reality, the dongle sent out the control command, causing the device to not receive the command and the control failed
What version of Home Assistant Core has the issue?
core-2023.8.4
What was the last working version of Home Assistant Core?
core-2023.8.4
What type of installation are you running?
Home Assistant OS
Integration causing the issue
No response
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
From our testing results, it can be seen that:
Devices with frequent data requests have experienced this issue, such as No necessary required switch, Window Covering
Replacing sonoff dongle-E has not caused this problem for a long time
The text was updated successfully, but these errors were encountered: