C8 - losing connection to Zigbee device (Hue Outdoor Motion Sensor)

Add me to the list of people with hue motion sensor issues. I have two ourdoor sensors, 1 that works great and 1 that fell off less than a day after migrating to the C-8. I added it back in yesterday around noon and it fell off again about 2 hours later.

An update on mine. I was having the sensor drop off every few hours, with it never going more than 11 hours.

I connected it to my hue hub to attempt a firmware update, but I was already on the latest. I reconnect back to HE and also updated to 109. It’s been online for almost 2 days now.

I also connected my Hue outdoor sensor to my hue hub to check for an update, but it was on the latest firmware. I reconnected it to my C-8 and it dropped in about 20 minutes.

Fortunately it's not up on a ladder, but I'm not having fun standing in the rain to take it down and remount it multiple times every day. I finally gave up. I connected it to my C-5 and meshed it back to the C-8. It's been rock solid on the C-5 for 24 hours.

This is, obviously, not an ideal solution, and not one I'd want to use for all of my zigbee devices. But, strangely enough, the outdoor Hue is the only one that keeps dropping off. The indoor Hue sensors have been fine. In fact there's one that used to drop off the C-5 every now and then that's been just fine on the C-8.

It's a mystery... hopefully soon to be solved.

And now I have a strange, unknown, null child showing up with an address that's not on my Zigbee details list. It's also not the outdoor sensor that's paired to the C-5.

FWIW, yesterday I pulled "Outlet - Dogain LR" because it had outcast = 7 and it wasn't being used as a repeater. Later I decided to put it back. But I grabbed a never-used Dogain outlet that was in the same box and paired it instead. Later I rebooting my zigbee, and I must say that the neighbor table looks a lot better this morning. Even the LR Dogain is happy. I'm not ready to move the outdoor sensor back yet, though.

Just noticed my Hue Dimmer Switches which were paired directly to the C8 have also been dropping off. As with the motion sensors, I pair them to the C8 and they drop off after an hour or so.

The child data section of this report is broken on a C8.
We've looked into it and currently do not have a fix for it.

In regards to the Hue motions.
A little over a week ago I needed to rejoin two of the four outdoor units I have in production on my C8.
All four have been online since with no issue, I did also drop the power down to 8 from the previous value of 16.

2 Likes

• I migrated from my C7 unit to the C8 a few weeks ago. Since then I have had zigbee drop out issues with random devices in my setup. I currently run about 54 zigbee devices 20 of which are wall mounted GE light switches (Jasco firmwareMT: 1124-0054-00000003) as well as 8 wall sockets to act as repeaters placed around the house.
• My issue is that I am chasing what appears to be random zigbee devices dropping off the zigbee net. I have to perform a zigbee pairing operation to get them back (they are recognized as existing devices when re-paired). I have tried re-applying power to the C8, rebooting it, rebooting the zigbee radio and rebuilding the zigbee network many times. A couple of times I have seen a device ‘come back’ after a network rebuild however one of those time Hubitat issues a turn on command after which it refused to issue any more commands to that device.
• To try and analyze the issue I use the ZBOSS zigbee sniffer setup with Wireshark which allows me to track zigbee comms and filter according to device zigbee ID or network mac ID etc. Using this setup I can track messaging to and from Hubitat through repeaters to the destination.
• The issue I am seeing is that when a device ‘drops’ it appears that the Hubitat radio forgets the device and never sends any commands to it at all. The device is still present in the Hubitat zigbee details web page with 64bit and 16 bit addresses listed but I cannot see any zigbee ID’d messages or mac addressed comms going to that device from Hubitat using the sniffer. I do see a constant heartbeat link status message every 20 seconds or so broadcast from the device but if I press any trigger button in Hubitat (on, off, configure, refresh etc) I see nothing coming from Hubitat in the sniffer. If I then go and put the device into pairing mode and use Hubitat to re-join it I see the joining comms in Wireshark (filtering with the 64 bit address), Hubitat reports existing device found, and then after that any trigger button pressed results in the usual zigbee commands being sent from Hubitat to the device and the device functions as it should.
• Having managed to get that device running I am then finding that another, previously working, device has now stopped working and, once again, the sniffer shows no messages from Hubitat to that device. I have not yet seen a pattern between the reconnected device and the new failing device.

5 Likes

it would be interested to see if there are any messages when it drops off.. my thinking is that the device tries to switch routes and that fubars somehow..

I also dropped the power down to 8 but no luck unfortunately. They continue to drop after an hour or so.

1 Like

My power is on 8 as well and I've had to re-join them multiple times since I first reported the problem maybe 5-6 weeks ago. I've basically stopped trying at this point since they're kind of a pain to get to, being outdoor and all. Same experience with some INNR plugs - more willing to experiment with them!

Pretty sure you'll find that address is the two least significant hex digits of the child device's 64-bit address (usually marked on the device; also listed on the Device details page). At least that's how they show up on my C-8's child table.

1 Like

You have described my EXACT situation. I too have Jasco switches. No pattern at all with the unpairing and it’s soooo frustrating. Sorry but c7 was much more stable for my setup...

That indeed appears to be the case! Thanks.

1 Like

Unfortunately this is not always the case, if so we would have fixed this already.

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.

1 Like

Thanks for letting me know; I tagged you in this observation a few days ago and didn't hear a confirm/deny so I kept spreading misinformation :wink:

1 Like

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 think you may be correct. Shutting down again causes the problem to re-occur with a different smattering of Zigbee devices connecting.