The device info was in the initial forum page 
however most of my devices are GE/JASCO light switches:
firmwareMT: 1124-0054-00000003
manufacturer: Jasco Products
model: 43084
softwareBuild: 0000000
And I have a few Sengled Zigbee bulbs:
firmwareMT: 1160-80CC-00000026
manufacturer: sengled
model: E21-N1EA
softwareBuild: 00000026
theres an update in beta currently that helps with join and rejoin issues.
I await with eager anticipation.....
Or join the beta and get it now!
How do you join the Beta ?
They may or may not have openings for new participants, but here's how you apply:
No guarantees that there are fixes for specific issues in the betas at any point, it's just an opportunity to help troubleshoot new hub firmware releases.
I put in a request to join over a week ago....no response.
I have been trying to monitor dropping and reconnecting devices to see if there is a pattern. I cannot see any indication as to which devices are going to drop but, so far, all that spontaneously start working again link directly to the hub (ie no repeater/routing is involved according to the ZBOSS Zigbee sniffer). Looking at a map I created using the sniffer I can currently see 19 devices being directly controlled by the hub (no repeaters involved) I am afraid I am not a Zigbee expert but I thought that I had read that the hub cannot support more than 16 direct zigbee connects so maybe I am misreading something?
I have 5 zigbee power sockets specifically intended for repeater duty (nothing plugged into them) and one more that is used to control some audio equipment:
endpointId: 01
application: 05
manufacturer: eWeLink
model: SA-003-Zigbee
powerCluster: none
4 of the sockets currently communicate directly to Hubitat and the other 2 have one hop through another device (1 is through one of the power sockets and the other is through a GE light switch). I would have expected more devices to be routed some devices are spaced quite far apart however unfortunately I did not study the topology when the C7 unit was controlling things. It does seem that the C8 system has a reluctance to control devices via repeaters. If any of your devs would like I can send the wireshark dump of the ZBOSS data to you, maybe it would assist in locating the issue. If you would like me to set filters for specific events I will try and do so,
I thought it was 32 directly connected devices . . .
OK thanks.
Installed V2.3.5.117 last night. Same issue with Hubitat not issuing commands to the non working devices despite having them registered in the Zigbee Details page. Will try re-pairing a couple later today and seeing what happens.
Power cycling (line or battery) the devices might bring them back without having to reset and rejoin them. Other people have reported this working for them.
Not keen on killing whole lighting circuits (to get the GE/JASCO wall switches) at the moment, it ought to be OK but..... I do unscrew the Sengled bulbs now and then to try getting them up and running. Anyway my main concern right now is Hubitat not issuing the commands to select devices when that is fixed I will reboot the house if necessary
Me neither. I would try manually turning them on and off first, maybe try hitting configure on the device page, then just pulling the disconnect tab under the switch (dimmers have this), before resorting to flipping breakers.
The connection/dropping issues appear to have a common thread-- C-8 seems to lose track of which end devices are in its own child table vs. child devices of other routers.
The way it's supposed to work is whenever an end device has something to report, it doesn't use routing; instead it transmits expecting to be heard (and acknowledged) in a single hop radius by its parent. If it doesn't have one or loses connection to it, it finds one through a join/rejoin process.
When the hub has data for an end device it knows to be direct connected (in its child table), it doesn't immediately send data on-air to that device; instead it holds the data internally in its 'MAC indirect queue' and waits for the sleepy device to wake up and poll for it (poll intervals are every few seconds for devices like locks and most motion & contact sensors). No routing is involved since its a direct connection.
On the other hand, if hub knows the end device to be a child of another router (one not in its own child table, or one it doesn't have a route table entry for), it should issue a 'route request' broadcast. From the response it can generate a routed message to the parent of the target end device (which then holds it in its indirect queue, waiting to be polled by the end device).
The process can break down if an end device loses connection to its parent and joins another without the original parent (hub) purging that end device from its own child table. Messages from the hub to the child never get sent (the hub expects to be polled for them).
Interesting that the uncontrollable device in your case is a GE/Jasco switch. If a router (whose device ID is transmitting on the network) is never the target of commands from the hub there could be a couple of causes. Either the C-8 doesn't have a route to it (should be issuing route request broadcasts, and getting replies) or the C-8 is mistakenly treating it as a child device (holding data for it in its indirect queue, expecting to be polled for data instead).
I saw a similar issue during the .117 upgrade process (I had sniffer running at the time) with small C-8 setup of 1 GE plug and 6 end devices. After reboot to .117, only 3 end devices (original child devices of C-8) still worked; even GE plug was not controllable from UI. I could see broadcasts from GE plug's device ID on the network, as well as data exchanges between it and the other 'dropped' end devices (previously child devices of C-8) which were now polling the plug for data. Yet C-8 never issued routed commands to GE plug, only broadcasts, and none of the child sensors of the GE plug appeared active on the UI.
More than an hour later (I had since stopped the trace) and with no other intervention, everything began working from the UI except a single motion sensor (earlier trace during f/w upgrade had shown the sensor issued multiple rejoin requests and received acknowledged responses, both from GE plug and C-8, before ultimately failing to rejoin and disappearing from the network). No idea what might have happened during the that time to apparently heal the setup other than speculating about some child table age-out interval that might have gotten things in sync again.
This morning I had one switch stop working (no Hubitat comms to it) and 2 start working (previously had no Hubitat comms but OK now) all checked with the sniffer. The re-joined devices are both (now) direct connect.
I have to admit I forgot about the hidden Hubitat zigbee routing table until now. Looking at that it matches the sniffer findings for the routed devices and their routing paths seem to change frequently but so far I can match sniffer to table.
All the inoperable devices have no entry in either the Neighbor Table Entry or the Route Table Entry sections so I think you are onto something in that Hubitat seems to forget them when it comes to routing commands. It would be nice to see a fail-safe in place such that if no path was found it just issued a direct message to its assigned ID but I guess that is a hack and would be unreliable, better to find out why their details are being dropped.
The route table is quite fluid, I took a snap shot of it to check all my lights and found one light (so far) that was not in the table at all but was working so I refreshed the table and the working light had gained an entry in the Route Table Entry section. Not sure if this is normal but it makes checking tough.
With reference to this suddenly working light switch, an entry for it popped up in the Neighbor Table Entry list the fun part here is that the Neighbor list is 16 entries and it was full so one of the previous entries was forced out. Since I had snapshots before and after I can now see that the ejected device is now non-operational. So I guess I caught a true device drop.
Routing in Zigbee is always dynamic; those route table entries (if not actively being used) are rapidly considered expired and new route discovery broadcasts get issued to avoid using stale routes; that's why 802.15.4 meshes are considered self healing. Neighbor table is also designed to 'evict' weaker neighbors in favor of stronger ones (hence the constant link status exchanges).
It's not like Z-Wave where the only time routes can change are when the hub requests neighbor updates, figures out adjacencies/new routes and distributes them (during repair or inclusion) or a previously used route permanently fails (after multiple retries) leading to explorer frame discovery). Z-Wave repeaters aren't routers; Zigbee repeaters are routers and can do route discoveries of their own (my opinion but I don't think Z-Wave 'routing' is capable of dealing with large meshes very well, probably why the incentive to dump it for Z-Wave LR and why direct paths via a strong radio/antenna setup seem to be the only workaround that helps with the current scheme).
Currently 99% of my house uses z-wave for sensor comms and (so far) that is still working well in Hubitat. The painful part is the zigbee lights/light switches (I have 2 z-wave light switches that have been operating faultlessly also).
Is this seen as a priority to fix by the Hubitat team? I am happy to help in any way that I can (I have volunteered for beta testing). I can run tests in my environment if you think that a larger number of devices is needed to track the problem just let me know what is needed. This situation is making me uncomfortably aware of how much zigbee automation I have running in my house . It is not an insurmountable problem since the switches are physically still operational but it no longer feels like home-automation anymore, more like a haunted house
They're actively working on the zigbee issues, but if you haven't upgraded to .117 already you might consider trying it to see if it resolves your issues.
Installed 2.3.5.117 last night. Thanks for the update.
Download the Hubitat app
