Skip to content
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

Closed
liangjia2019 opened this issue Aug 28, 2023 · 11 comments
Closed

ZigBee devices Remote Randomness Control Failure #99187

liangjia2019 opened this issue Aug 28, 2023 · 11 comments

Comments

@liangjia2019
Copy link
Contributor

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
lQLPJwUO9-6BQrzNAoDNApywPB5235x_dT8E4Gd1c8CRAA_668_640

From Zigbee's packet capture:
usb dongle was sonoff dongle-p
image

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:

  1. Devices with frequent data requests have experienced this issue, such as No necessary required switch, Window Covering

  2. Replacing sonoff dongle-E has not caused this problem for a long time

@home-assistant
Copy link

Hey there @dmulcahey, @Adminiuga, @puddly, mind taking a look at this issue as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of zha can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Renames the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign zha Removes the current integration label and assignees on the issue, add the integration domain after the command.

(message by CodeOwnersMention)


zha documentation
zha source
(message by IssueLinks)

@puddly
Copy link
Contributor

puddly commented Aug 29, 2023

To clarify, you see this behavior with the Sonoff -P dongle but not with the -E?

Some questions:

  1. What firmware version is your -P running?
  2. Have you tried the most recent Z-Stack build?
  3. It looks like the device is a child of the coordinator. Does this still happen if you add a router and make the device a child of the router?

@liangjia2019
Copy link
Contributor Author

liangjia2019 commented Aug 30, 2023

To clarify, you see this behavior with the Sonoff -P dongle but not with the -E?

Some questions:

  1. What firmware version is your -P running?
  2. Have you tried the most recent Z-Stack build?
  3. It looks like the device is a child of the coordinator. Does this still happen if you add a router and make the device a child of the router?

1.The version of the coordinator we are using is
From:https://github.com/Koenkk/Z-Stack-firmware
Tag:Z-Stack_ 3. x.0 coordinator 20221226
It is not the latest, I will upgrade it to the latest to reproduce the problem
Or what other recommended firmware versions do you have to try
2.The device currently experiencing the problem is a direct coordinator, and I can try to place it under a router device

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

@TheJulianJES
Copy link
Member

TheJulianJES commented Aug 30, 2023

You can try Z-Stack 20230507. From the changelog:

Increase message timeout from 7 to 8 seconds to increase message delivery success rate for devices using a 7.5 seconds poll interval (Koenkk/zigbee2mqtt#13478 (comment))

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.

@liangjia2019
Copy link
Contributor Author

liangjia2019 commented Sep 11, 2023

I have been using the dongle firmware of KK 0507 for over a week, and it seems that there have been no local reports of normal situations, but abnormal situations have been issued:

A certain Lumi device is unable to control and synchronize local status,but other devices run well
image

I tried to restart and power on this device, but it did not resume service. It can only be used by pairing again

@puddly
Copy link
Contributor

puddly commented Sep 11, 2023

MAC_CHANNEL_ACCESS_FAILURE is a problem with your environment, there is too much interference and the CCA check fails.

@liangjia2019
Copy link
Contributor Author

I restarted the raspberry , but it didn't have much effect

MAC_CHANNEL_ACCESS_FAILURE is a problem with your environment, there is too much interference and the CCA check fails.

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

@puddly
Copy link
Contributor

puddly commented Sep 11, 2023

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.

@liangjia2019
Copy link
Contributor Author

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

@puddly
Copy link
Contributor

puddly commented Sep 11, 2023

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.

@issue-triage-workflows
Copy link

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.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@issue-triage-workflows issue-triage-workflows bot closed this as not planned Won't fix, can't repro, duplicate, stale Dec 17, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Jan 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants