I have done this twice already. Once yesterday, and once today. Thanks again though.
Are you 100% sure that you have the JV setting correct? You went back in after flashing and set it to disable? I was seeing something very similar and it was because the settings were incorrect on my Xbee. I had set them but they didn't "take".
Here is the zigblee child/parents page.
The first yellow is the current zigbee device ID.
The one underneath is the previous device ID from 5 mins ago, and is now no longer valid.
I'm seeing the same behaviour for the tradfri routers as well, which would make me think it's not the XBee's setup. Although I've been wrong before.
Wait....your neighbor table only has one entry....Do you have any zigbee routers attached to this hub other than the xbee?
I did, but they were doing the same thing, so I removed them to try to figure it out.
Edit: with multiple routers with null entries, my network became unstable.
yes, twice, and also re-add to HE.
Changed again. On this page, the device page, and the zigbee logs.
Edit: again.
Edit: 27 times in just this one log page. Something is borked.
In order to remove all user error, I removed the XBee device, and re-added the tradfri repeater that was also exhibiting the same problem yesterday. The tradfri repeater has no settings that can be changed by the user. Same thing.
Shot in the dark: Is the hub staying on the same Zigbee channel that you expect? There have been reports of anomalous channel changes before, so far unexplained (happened to me once, though the hub went back to its assigned channel after rebooting). If the hub issues the appropriate network management command for a channel change, all your routers would rescan and rejoin, getting new device ID's.
3 Likes
I had that happen once...but it was associated with a lockeup as the zigbee radio was "dying". It didn't actually change channels, at least in my case. It just looked like it did.
What was the fix?
Once i rebooted, the hub came back up and the zigbee radio was reporting it was back on the correct channel. I suspect that the freq never actually changed...I just happened to be looking at the UI during the start of a lockup and happened to notice that particular thing. The zigbee radio is the first thing to be lost (for a c-4 hub at least).
1 Like
I have similar problem in the past. In my case, I find that I have a rouge device that send packet with short Zigbee NWK ID of my router.
I found this issue by sniffing my zigbee packets. Zigbee packet is encrypted. But, to track this issue, you do not need to decrypted the packets. The packets will print the 64bit mac address and the short address. When the router change ID, i notice a packet with the same short NWK ID with different MAC address.
In Zigbee, there is a mechanism to resolve conflicting addresses. This mechanism kicked in when the router receive a packet with the same short network id from a packet that does not have the same mac as its own.
My device that generate this packet is a Bosch Motion sensor. From my observation, it start doing this when it is low on battery.
I am not sure whether you have the same issue. This is what did happen to me.
6 Likes
Interesting.
I have 4 Bosch motion detectors. Yesterday with all my Zigbee shenanigans, I noticed one had dropped off. Low battery. And so yesterday, I replaced the batteries in it.
Today, the zigbee device ID is still changing. I have other Bosch motion detectors, but they all report 100% battery. I will remove all 4 Bosch MD's and see if it becomes stable.
You were indeed correct. Removed all 4 (showing 100% battery) and problem vanished.
@mike.maxwell are you able to fix/modify the official Bosch motion detector driver? It's been ther cause behind my major zigbee issues. When I removed the 4 Bosch MD's from my network, everything works as it should.
4 Likes
Theres nothing we can do with a device that goes full on stupid under low battery conditions...
2 Likes
There probably should be an advisory to change out all batteries when migrating devices to Hubitat. The batteries will probably take a pretty good hit before the mesh has stabilized and people will blame Hubitat for their issues.
1 Like
Also, that battery levels reported are often inaccurate adding to the issue.
I would be very hesitant to issue such an advisory. It has the potential of scaring away a lot of potential customers.
