#CC2652 joining issues
1 messages · Page 1 of 1 (latest)
I restored your NVRAM backup to one of my CC2652 coordinators and was able to join a device on my first try, no issues here.
The bug I mentioned yesterday would generate a bunch of warnings during the network backup, which I did not see happen with your NVRAM backup. I don't think your problem is related to it.
Can you run an energy scan https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md#energy-scan ? Maybe it's something RF related. I temporarily moved by CC2652R next to a USB 3 hub the other day and it rendered it completely useless, no data was being sent or received from sensors and bulbs in the same room with a clear line of sight to the coordinator.
I will try that
I was able to get them paired again by adding devices through the router instead of the coordinator, the router is further away so that's a little strange
How do you usually add devices?
I just click the add device button on Zha usually
That permits joins through every router on the network in addition to the coordinator, which is usually what you want to happen
yeah, I think there is something bizarre happening where that isn't being triggered for whatever reason
Going to do the energy scan, if I find a better channel. I know I have to reform a network if that is the case...does that mean manually re-pairing every zigbee device?
So it looks like 20 and 25 are good. Not sure what current channel is... (15 is default?)
Your network for some reason is on 11
What does the energy scan graph look like after five scans?
You may not have to change channels
Do you have a strong 2.4GHz WiFi network on channel 1 nearby?
yes
If it's yours, try moving it to 6 or 11. WiFi networks handle channel changes a whole lot better than Zigbee (which for the most part doesn't).
it is my neighbors, but they're pretty chill so I will see if I can get them to move it. Probably took 1 (moved in a week or two ago) because mine are on 6
Do you have debug logging enabled for ZHA?
If it's been running for a while, search for Request failed. Do you ever see MAC_CHANNEL_ACCESS_FAILURE as a failure reason?
That's what Z-Stack responds with when you try sending something and the channel is too congested
I'd let it run overnight and then try joining a device or something tomorrow, that should provide more context
I believe that's likely the case. Thinking back, my neighbors moved in recently and that could be the change- i hadn't put it together but that's why it's been wonky the last week or so
If your network is mostly routers, changing the Zigbee channel might work if you power cycle them but having nice neighbors is a lot easier
Here are some logs from recent: https://pastebin.com/d25ESZ0M
Verified that neighbors are not on channel 1, no significant wifi rssi anywhere in that range.
Any instances of MAC_CHANNEL_ACCESS_FAILURE in your log?