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

ZNP / CCxxxx - unable to send command/message to a Battery based end device operating with polling #1341

Closed
pipiche38 opened this issue Nov 8, 2022 · 3 comments

Comments

@pipiche38
Copy link
Collaborator

pipiche38 commented Nov 8, 2022

When sending message/command to a end device which is doing polling time to time, commands are most of the time failing to be sent.

The typical example is with a Wiser VACT which is doing polling during 5 seconds after sending a report. When sending the command at that time most of the time it is failing. ZNP is doing several retries but all fails.

I understood that @Koenkk firmware are based on a ACK_APS of 1 second (instead of the 6 seconds default). That could be a reason, but I think ZNP is also doing some timeout at the same time.

When doing the same setup with an elelabs or SonOff E dongle based on Silicon Labs, all work like a charm

Screenshot 2022-11-08 at 16 28 27
Screenshot 2022-11-08 at 16 28 55

@pipiche38
Copy link
Collaborator Author

@badzz @deufo if you want to investigate, but for me something is weird
@puddly if you have any ideas to investigate let me know

@pipiche38
Copy link
Collaborator Author

pipiche38 commented Nov 8, 2022

In the here attached Sniff you'll get

  • up to packet 9967 a communication between zzh and wiser vact
  • from backet 9967 a communication between elelabs and wiser vact

In short the boths coordinators behaviours are visible on the same sniff

Problem ZNP VACT.pcapng.zip

@MattWestb
Copy link

The reactivating the disabled Zigbee 3 end device handling shall being OK now but they is have some other problems and in the IT firmware.
Also you is very likely getting problem with normal and source routing with them then its broadcast storming the network then they still have illegal broadcast settings in the firmware and then the routers if being flooded they is blocking broadcast and the routing discovery is not working longer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants