Hubitat was powered off then back on and then left overnight.
The next day nothing had changed in that inoperative devices of the previous day had not healed themselves however I went through and re-paired all inoperative devices (note all the inoperative devices were not being issued commands by Hubitat either before or after the upgrade).
Each device that I re-paired was checked and now nearly all of them connected indirectly with at least 1 hop. All switches re-paired without issue, the Sengled light bulb was problematic as it did not seem to complete the pair operation and if I kept pressing the add-device button (without touching the light) each time Hubitat would declare the bulb as an existing device that has been found. I continued re-pairing other devices and eventually the Sengled seemed to complete and start working.
Things are much better now, thank you, however there is still the occasional period where a device becomes inoperable, it is difficult to trace since when they fail to operate it is because Hubitat is not sending a command however, so far, if I leave them alone for a few minutes Hubitat starts sending the commands and the devices work. I do not know what information is relevant for this however when Hubitat stops issuing commands for a device I usually go to the route screen and I can not see the problem device in either the Neighbor or Route Table lists then if I go back to the device screen Hubitat starts issuing the commands again if I then go back to the route screen I see the device in one or other of the lists.
Out of interest why is the routing table limited to 32 devices (16 Neighbor Table and 16 Route Table) I have over 32 devices (nearer 54 at the moment) and thought I would see an entry for each of them.
The routes are dynamic and have a short time-to-live. I think the idea is they turn-over quickly enough that there is no need to cache a lot of them. I wonder if the route calculation is being slowed by something . . .
You will not. The devices listed are the 16 nearest neighbors of the hub, which seem to be the strongest repeaters. Routes listed are only those that are 1 hop away. I have 100 Zigbee devices on my C-8 and many of them I have never seen listed, but they all work fine.
This version is still dropping devices (Hubitat not sending the commands to the selected device). I periodically test all the switches in my house using the Hubitat web dashboard and device pages and, so far, 5 out of 28 that I test have dropped out. The sniffer shows no commands being issued to them. I had one odd situation yesterday during a test where the light turned on but then would not turn off (about 2 seconds later) and upon checking, once again, Hubitat was no longer issuing commands to that device.
After each upgrade of the Hubitat version I try re-pairing any devices that Hubitat seems to have āforgottenā and get them working again.
When a device stops working I note it and check it periodically, a few of them start working again for no apparent reason. When looking at the sniffer trace, so far, all of the re-working devices seem to have a direct link to the Hubitat hub (no repeaters).
One of those from this morning has just started working and it is a direct link to the Hubitat (no repeaters involved) and maybe a minute later Hubitat had stopped sending the commands once again.
If I take a router snapshot before and after an event I can see the previously unresponsive device suddenly appear on the Neighbor Table entry list and one of the items on that list drops off. When that device becomes unresponsive again the list no longer contains that device and Hubitat no longer issues commands to it.
I know I am stumbling around in the dark here (pun intended I guess) if you need a more specific test or some extra logging please let me know and I will try and help.
It took longer but Hubitat had stopped communicating with 6 of the JASCO light switches and one Sengled light bulb this morning. I had not seen this issue with the C7 system. I took a look on the Jasco website to see if there was a firmware upgrades for these zigbee devices but cannot find any, their firmware support seems to focus on z-wave devices only.
Does anyone know why, when the Hubitat zigbee radio stops issuing commands to a switch, the Hubitat log shows no activity when turning that device on and off? I have the ādescription text loggingā switch on. The device is in the Hubitat device list, it is using the device web page interface I would have thought that pressing the buttons should show up on the log activity page. If I turn on the āenable debug loggingā I do get a debug entry indicating an on and off operation but not the usual info entries (like āBack Light Low was turned off [digital]ā) describing the switch name and operation.
Your post reminded me that I had swapped out my classic whites for the color and brighter bulbs at some point. So I haven't had any of those on my mesh for a while.
Is there any progress on the C8 zigbee issue please? The disruption in my house is annoying with the random nature of the issue stopping lights turning on or off in an unpredictable fashion, some days a certain automation may work then later it will stop working. Apart from the zigbee issue the C8 appears to be working well, the rules and 3rd party apps I had installed in the C7 transferred without issue, it is just a shame I have such a reliance on zigbee. Some idea of a timescale for a fix would be appreciated. Thanks. If you need anymore zigbee wireshark logs please let me know.
All of hubitats drivers issue events based on state changes issued by the devices, since the commands aren't being sent to the device, the device isn't responding, hence no info entries in the live logs.
with debug logging enabled most drivers will show that the given driver method is being called.
In regards to the sengleds, I'll set one of the multi colors up and watch it.
We are also currently testing a build with some fixed for devices dropping off and not being able to rejoin the network.
Any info on what causes the random zigbee radio reboots? Iām not seeing many (unlike some reports), just wondering what could be causing it to reboot on its own.
So, some people have more magic than others? That makes as much sense to me as anything else
Iām only seeing it happen about once a week, so itās just whatever for me.
Hubitat version V 2.3.5.123
Installed this new version, running it over the weekend.
No noticeable improvement in device operation. Hubitat is still not issuing commands to those devices that are not working yet I can see Link Status and Device Announcement reports from those devices. I tried re-pairing a Sengled Color light and was unable to. The light reported pairing mode (multi color flash) then, sometime later, reported pairing in operation (Hubitat would report found existing device) then there would be a pause of about 20 seconds and the Sengled would go back to reporting In Pairing mode (multi color flashing). If I kept re-pressing the Hubitat Start Pairing mode button then after a minute or two the Sengled bulb would report pairing once again, Hubitat would acknowledge an existing device and the cycle would repeat. Unfortunately I tried for about half an hour but was unable to get that bulb to complete pairing successfully with Hubitat again. The bulb was working prior to the version upgrade. I managed to re-pair a JASCO switch without a problem.
I tried .123 but found that my devices started dropping again after having been relatively stable from dropping on the past release. Reverted back to the previous firmware and the devices dropping off the zigbee network stopped.
Zigbee radio still turns on and off regularly every hour or so (sometimes several times an hour).
Since this Hubitat zigbee issue seems to be a major problem that is going to take some time to resolve I have come up with (for me) a work around. Hubitat and HomeAssistant have some great integrations (Hubitat has the āHome Assistant Device Bridgeā and Home Assistant has the Hubitat integration) so both systems can share each otherās devices quite happily. I have been playing with Home Assistant (it has some nice integrations to handle house plant monitoring and other odd things) so I powered up their zigbee/MQTT subsystem and linked the more important (to me) lights that Hubitat was forgetting. Using the Hubitat bridge I can see and control those lights and so put them into my existing Hubitat rules and presto my light automations are back up and running reliably again.
One feature request I would make is the Hubitat āSwap Apps Devicesā feature currently does not seem to recognize the child devices in the Home Assistant parent so I have to hand edit each rule to add the new Home Assistant light (it is odd that the Home Assistant devices show up in the Hubitat device list when editing rules etc. but not the Swap list). It would have been nicer to use the swap feature to simply identify the Hubitat device, swap to the Home Assistant device then, when the Hubitat bug is fixed I could switch back just as easily.
Both the JASCO switches and the Sengled color bulbs zigbee paired to Home Assistant immediately. So far I have transferred 8 devices to this indirect mode of operation, I was hoping that it may stabilize the remaining devices still connected to Hubitat but unfortunately there has still been erratic drops and reconnects occurring and when I check Hubtat has stopped sending commands to the ādroppedā devices.
This is by design, as not all parents will handle child devices swapped out from under them without problem:
(Sometimes the parent app or device may provide a way for you to do a swap within the app or driver, or have an "unofficial" method of doing so via DNI swaps, as long as the parent--which you cannot change--remains the same, but that depends on the device. I've rarely seen one that offers any "official" way of doing even that.)
is the Hubitat āSwap Apps Devicesā feature currently does not seem to recognize the child devices in the Home Assistant parent so I have to hand edit each rule to add the new Home Assistant light (it is odd that the Home Assistant devices show up in the Hubitat device list when editing rules etc. but not the Swap list). It would have been nicer to use the swap feature to simply identify the Hubitat device, swap to the Home Assistant device then, when the Hubitat bug is fixed I could switch back just as easily.
