Very interesting; I'm using the C-8 with just one end device and a router, and the only time I can get an end device to reset/rejoin as 'previously found' is if the join happens in range of the router (and the router gives it a new device id); it 'drops back' into its automations as expected without problems. Reset it and try joining it in range of the hub, however, and sniffer shows that hub gives it the same device ID (as it had before the reset) along with the 'acceoted' join response... the attempt always ends with 'it looks like you're having trouble joining a device', and the device apparently doesn't function.
Trying this with the lone router and rejoining it always has apparently failed-- yet I can verify that the router device itself is functionally joined (it's a GE Zigbee dimmer plug that can still be controlled by its device page, according to the light bulb I have on it, yet the hub doesn't appear to log events or update the device page). I also see sniffer trace shows data exchange between C-8 and 'failed' device (again, it can be controlled from device page, but not automations, in this state-- that state being the deviceID did not change during the attempted rejoin) and the C-8 doesn't log events in history or update on/off state on the page).
I haven't tried with more than a single router; AFAIK in the usual join process, a router joining via another router would also get a randomized device ID on rejoin (and by my reckoning would work normally). Could be the reason why in your environment most times the reset/rejoins result in 'device found', and when I try resetting a lone router, the rejoin never produces 'previously found'. Yet (if I can generalize from what I have seen with just a single router and end device) any device that is reset and rejoins via the hub (router or end device, makes no difference) will have issues.
I dropped the power down to 8, removed the Hue outdoor sensor from my c-5, factory reset it, and joined it to the C-8. I joined it in place, instead of bringing it in out of the cold. So far it's still OK — we'll see what tomorrow brings — but look where it's showing up in the routing. I expected that to be momentary, but the neighbor table has looked like this for over an hour now.
I wonder if this means that it's connecting directly to the hub but isn't showing up in the child data because that's broken?
Another to add to the list in addition to the hue woes. Had a power failure and when the hub booted up again, I noticed that previously joined zigbee contact sensors, motion sensors etc. didn't re-connect (I have about 80 zigbee devices and only 10 or so reconnected). Pairing them again got them working.
I just did a controlled shutdown and turned the Hub back on again to test whether the same thing would happen, and it did. Some previously joined devices did not reconnect. Curiously, some devices which were not connected because they had dropped off, also reconnected. Seems to be no discernable pattern as to what drops off etc.
Naturally this will get old very quick - particularly with the almost daily updates to the Hub at the moment necessitating a Hub reboot. I appreciate the Hubitat team is working on the issues but does anyone know if the root cause has been identified and a fix in the works? Just wondering whether I need to cut my losses for the time being and manually try and transfer back all the Zigbee devices to the C5 if a fix is likely to be some time away (I have a c5 and c7).
this wouild also point to what i am guessing is going on,.. during an outage they would all try to get a new route.. and something in that process locks them out
should be easy enough to test.. turn of power main for a few minutes without or without your hub om battery backjup.. if most zigbee are no longer working than this is most likely the issue.
I switched out my C8's antenna with this one. It seems to have fixed my signal issues at least according to the zigbee logs. Cool thing about the antenna is it comes with an 11' cable and a magnet base if you want to use it. Running power level 12 atm
https://www.amazon.com/gp/product/B011A4UZFY?ref=ppx_pt2_dt_b_prod_image
I'll change out one of my Xbee 3's to see what the signal is really doing. I'm sure they need firmware updates anyways.
I'm thinking about switching the C8 to channel 15. I tried that yesterday things ran great. Anything wrong with going to channel 15?
I do not think our issues are connected in this case.
At the most basic level my question is, why is there a zigbee device in the Hubitat zigbee details list with a 2 byte ID that, if I send a command of any type from Hubitat, does not result in ANY traffic to that destination device from Hubitat. Even if the device is offline or not available in some way there is (normally) always comms from Hubitat if only for rout discovery or repeated command send attempts.
All I can do is guess, but it seems at some level something has broken where the correspondence is kept between a devices' MAC address and it's device ID instance that is exposed via the user interface.
Hence when you try to issue a command from the UI based on that device ID, it may involve another layer of translation that hasn't tracked that device ID correctly so nothing gets transmitted on the radio.
I have produced this condition and made it go away with only two devices, the C-8 (and also c-7, with latest firmware) and any other Zigbee device. One wrinkle is that you cannot have any other joined routers in the mix or they introduce variables that are harder to isolate:
Join a device to the c8 the first time and it completes okay, reset it and try to rejoin it and it won't work properly from the UI. Remove its instance from the database, try it again and it will succeed.
The c8/c7 now remember the original device IDs they distributed on an initial join and reissue them when they see that devices Mac again during a subsequent join, even if it has been reset. The second time around that process doesn't seem to work correctly hence the problems until you actually remove it via the device details page and try it again. That apparently fixes the match up again because the device then works even with the same reissued device ID.
When a device joins through a router, on the other hand, it (the router) issues a randomized device ID every time. That masks the problem that only surfaces when devices join directly via the hub, get reset and subsequently rejoined via the same device ID.
The only thing that changes a remembered device ID issued by the hub is resetting the Zigbee radio.
Again this is the behavior that I can repeat with a small set of devices on c8 and c7. Feel free to correct me @mike.maxwell if you see something different on your end with a similar experiment.
I'm unable to test this on the c-3 because it's running my house and I can't isolate it as easily.
One observation I have made is that my 3 Sonoff dongles now seem to be playing a much larger role in routing end devices on my C-8. I rarely saw them routing on my C-5’s table, even though one of the dongles is plugged in 2 feet from the hub. That routing table was dominated by Samsung plugs, but now it seems that devices are more evenly distributed. I also haven’t had any devices drop since the Iris V2 motion sensor that dropped off right after the initial migration. That one had to be deleted and reset to get it to join and function properly. Even though everything is currently working, there’s obviously something amiss because every time the hub is rebooted, I open the ui to see a “Zigbee radio is offline” message, and the Zigbee settings page shows the radio rebooting. Fortunately, it has always resolved itself and everything works fine after a few minutes, but it is a little concerning.
Could be the newer Zigbee stack in the C-8 (assuming there is one; I think so because of the extra parameter now seen in C-8's EzspGetParentChildParametersResponse from the now-broken getChildandRouteInfo page) may use a better way of calculating LQI. Evidently determining LQI isn't standardized and some implementations just use raw RSSI (including noise); some track actual error rates/resends and fold that into LQI.
That affects how devices choose parents/neighbors (and how routing paths get chosen, since LQI gets mapped to an inCost number).
However the C-8 is calculating it, it seems to correlate with what devices are reporting (using the Ikea signal repeater driver), whereas there was a huge difference with what the C-5 reported versus what devices were reporting.
I think similar for me...the SonOff dongles appear to be busier than they were on the C-7. That's interesting given the more powerful Zigbee signal on the C-8.
I backed my power back down to 8 . I noticed one of my two gardenspot lights was missing commands.. so i set it to change color every 2 minutes to monitor. i believe either the signal was too high with too much noise or more likely the c8 or device thinks the signal is good to go direct to the hub but it really isn't and should be using a repeater. During the time the gardenspot was missing commands the hue outdoor near it also was not working. Ie i turned the outdoor light on and it didn't report a brightness change.
When i backed the Power down i also clicked rebuild the zigbee and the hue started working again.
I believe this is happening with indoor motions as well (pretty sure they're the same hardware in different casings so that makes sense).
I've been able to re-join them, but based on this thread, I'm not confident they will stay up. I have noticed in my route table that they are ALL going through repeaters no matter their distance from the hub (some are in the same room).
Oddly enough, the only direct neighbor I see in my route table is an Aqara FP1...
I lowered the zigbee power to 8, removed the Hue Outdoor Sensor from the C-5, and repaired it to the C-8. It's been connected and reporting for over 24 hours, so [fingers crossed] it may be OK. In a leap of faith I unmeshed the two hubs and turned the C-5 off again. I'm not ready to put it back in the drawer, though... just in case. Rebooting the hub removed the Hue sensor from the Neighbor Table. It's been routing consistently through the kitchen, (Dogain K), which makes sense given the placement. All of my inside sensors have been OK. I still have the weird null child, but understand that the child table is broken.
I got confident that my sensor was working after 3 days of uptime so I moved it back outside to the permanent location. Within 10 hours it lost connection.
I have an original Hue Motion that keeps leaving the network over and over again. This controls the main kitchen lights and is not making the wife happy.
firmwareMT: 100B-010D-42006BB7
manufacturer: Philips
model: SML001
softwareBuild: 42006BB7
Zigbee settings
Current channel: 0x14 (20)
Current power level: 16
