Understanding Zigbee on Hubitat


#1

I am a convert from SmartThings and when I moved over to Hubitat I brought all my baggage, meaning several old time GE-Link bulbs and Cree. I knew about the warnings of repeating zigbee bulbs but paid no attention because things seems to be running OK most of the time. No better or no worse than on SmartThings. I found a deal on a bunch of zigbee bulbs which are non repeating and replaced all my older bulbs. WOW! Much improvement. Response times are snappier and haven't had a dropped device or command for the past week.

I have purposely reduced the number of Centralite cube outlets (SmartThings branded) down to two. One in a detached garage (50 foot from hub) and one in the basement (25 foot from hub).
The hub is centrally located on the first floor near most of my devices.

I powered down the hub for 35 minutes to force a new network mesh. After powering back on nearly all zigbee devices showed up as child sleepy end devices, which I assume those are direct connects to the hub?

I have 34 zigbee devices (all working) but I can't seem to find all of them posted in the snapshot obtained from http://192.168.x.x/hub/zigbee/getChildAndRouteInfo

What is the hard limit of devices connected directly to the Hubitat hub?
I've read its 32 but I have 34 with one coming through repeater in the garage.

Is there a reason some are not showing in the getChildAndRouteInfo?


#2

My experience is that some devices don't show in that table because they are connected through a parent which don't repeat all data (the device might work though). So they are not in the table, but they are working fine through the repeater in HE.

About the limit, it's not a hard set limit. It's only known to be on the safe side, so you might experience drop offs when you go over the limit. Also I believe the limit is only for battery operated devices directly connected to HE. And as the team also said in the last Hubitat Live their recommendation for battery operated devices is about 1 repeater for every 6 battery operated devices (in the range of those 6 devices of course).


#3

There is a limit of 32 devices that can communicate directly to Hubitat and don't got through another router. There is virtually no limit of number of devices as long as you have sufficient routers installed in your mesh.

Rule of thumb is to have 1 router for every 6 devices. It does depend a bit on which router you use and where the devices are located.

Battery devices might drop from the getChildAndRouteInfo as they go to sleep to preserve energy. So you shouldn't see all devices at once there anyhow


#4

Thanks for the input. After getting rid of all the repeating zigbee bulbs that is when I seen the huge spike of child sleepy end devices. Before with the bulbs there may have been 5 devices that ever showed in there.

I have several centralite repeating outlets that I can plug back in. I removed them trying to see how the devices react. My end goal is to understand how battery powered devices react when they are normally repeated through a repeating device and power is suddenly removed (ie. power failure) Will the battery powered device fail to communicate back to the hub if suddenly all powered centralite repeating outlets loose power?


#5

Yes they will fail, if the distance between the next repeating or hub is to far away. But it's always good to test. Keep in mind that they do take a while to find a new repeater if one drops (max 48 hours I believe).

I have some repeaters for my ground floor (i'm living in a fairly small building) on a UPS to to provide at least the ones that are important for HSM.


#6

Yes, plug these centralites back in now that your bulbs are gone. That will build a good mesh.
All devices know their routing neighbors, that is covered by the Zigbee stack. On power failure, the battery devices will try to send and will fail. They will continue to try to connect to a previously known router until the power has restored and they are successful to send a packet. But don't worry, they won't drain the battery, they will just give up sending if it fails and then send again where there is a change or on a periodic time. All if this is handled by the Zigbee specification and is not depending on Hubitat.


#7

So if I understand correctly if the battery powered devices have been working well for several days without the assistance of any nearby repeating device, they would still work if they were routed through a nearby repeating device and the repeating device lost power.


#8

Yes, that is exactly the benefit of a mesh network that Zigbee is build upon


#9

Good information to know. That is what I will do. Thanks much.


#10

I'm really curious how this would be possible?


#11

I guess if the sleepy end device knew of multiple pathways to communicate to the hub and it primarily communicated through a repeating device and that device failed, it would fallback to using the alternate path, and if that path is within range then it would pass it's date through.

That is one of the reasons I have purposely reduced the repeating devices to see how well things worked. I am assuming that if they work well without repeaters they would benefit even more with them.


#12

The way that Zigbee works is that devices know several paths back to the coordinator. That is why it is called a mesh network. If one path fails, the Zigbee stack will re-route the packet through a different path.

Obviously, if there is only a single path to the coordinator and the device is too far away to reach the coordinator directly, the transmission will fail.

Distribute your routers throughout your house to build a good coverage so each device knows more than one path.

Also, on last nights live episode, the Hubitat team went over how a mesh network works. Take a look here:


#13

The 'repeater' designation of an always on Zigbee device obscures one of its key functions (and the reason for the hard limit of child devices supported by a router or coordinator). It has to do with the finite resources allocated to dedicated buffers for each of its potential child devices; these battery powered devices are 'asleep' most of the time and only periodically wake up and check for message packets which are stored in the parent that they are joined to.

Any transmission from the hub to an end device gets buffered at the parent (this includes the hub for its directly associated child devices) and only is received by the end device when it wakes up and polls for it. The wakeup schedule is specified by the application, hence the incompatibility between Xiaomi devices and many routers. The rate at which the sleepy device polls its parent can be as short as 3 seconds or as long as one hour-- that's the maximum poll interval defined by the Home Automation Profile (the end device can transmit any time it wants to). If a router hasn't been polled by its child within the expected interval, the router 'evicts' the child to make room for another potential connection to an end device.

The end devices don't really know or need to know anything about the network other than the status of the link to their parent router. It's the routers job to determine which paths are available to the hub. The end device's job is to know when it is successfully joined to its parent (or told to leave the network) and rejoin if its poll attempts fail.


#14

I guess if I seen this video before posting I wouldn't have needed to ask the question. LOL! Thanks for the video link. I have four centralites plugged in around the outside perimeter of the house. North, South, East and West with the hub in the center. I'll let it be for a week and see how it goes, but getting rid of those old bulbs really seem to make things run a lot better.


#15

Check, I saw the episode. But I didn't understand your sentence right. I read that a repeater, despite being powerless, still routes the messages through. But that is not what you meant, you meant that a device would hop to the nearest repeater that does have power. :slight_smile: