When a device joins the mesh network, it finds the strongest signal and utilizes it as a parent. That devices then locks onto that parent and always uses it, even if there is a stronger signal coming from another node. By pairing it right next to the hub, it’ll almost always lock onto the hub as its parent. Then, if you move it away and put it in its permanent location, you very likely will have a stronger, more reliable signal from another repeater, but it’ll never use it, it’ll stay locked to the hub. I’d think this would cause issues and potentially sporadic device unavailability.
I know the quick fix for this with zwave devices is to preform a zwave repair, but zigbee doesn’t have have same option. With zigbee you have to completely take down the entire zwave network for several minutes in order to force the devices to reestablish themselves with new parent nodes. This isn’t even really documented anywhere.
The non-Z-Wave plus controllers didn’t allow “on network” registration. The registration had to done with the controller only and then moved to final destination. Z-Wave plus allows the device to be anywhere within the network. Also Z-Wave Plus does it’s own self healing without any interaction needed.
I still bring battery type devices to the controller because some of them just don’t pair on network.
This process is called “bench pairing” And it’s been used from the beginning. There are multiple reasons for doing it this way. Remember that even as of 2017, the vast majority of these devices are installed by professional installers. (Z wave Alliance has said that 2/3 of the zwave devices in the US, for example, are professionally installed, usually by the “home automation as a service” companies like Time Warner, Xfinity Home, and ADT pulse.)
Here are just some of them:
One) it’s the fastest way to identify a defective device, which can happen. If you can’t get it to pair to the hub, it’s almost certainly just a problem with that device. when the system is being professionally installed, time is money for the field tech, and identifying these devices is critical. In fact, many of them are paired at the warehouse before being sent out to the home. This was where the term “bench pairing” Originally came from. One person in the warehouse pulled the inventory and paired everything, verifying that the devices were good, then put them back in the boxes and packed them up for delivery to the installer.
Two) it’s necessary for some devices in order to exchange security keys with the hub during the first time pairing. This is sometimes called “whisper distance.” This is typical of locks, both zigbee and Z wave, but also true of some other devices. Whisper distance is often much shorter than a single hop range for the protocol, sometimes only within a few feet.
Three) to be honest, it just makes it easier for support to troubleshoot if a pairing isn’t going well. this is a combination of one and two above, and applies to DIY installs as well as professional installers. It means the support person only has to deal with two devices, the new one and the hub, rather than all of the potential repeaters in between.
Both zigbee and Z wave have updated their protocols in the last few years to reduce the need for bench pairing, but it still the best practices position of many manufacturers. You do the pairings in the warehouse, you ship the equipment to the field tech, the field tech does the installs and runs the heal or the repair.
Looked at from the point of view of professional installation, it’s a pretty efficient method. Of course looked at from the point of view of a DIY person who is adding a new device one at a time every month or so, it can be annoying. But it is a market driven methodology, it’s just at the market isn’t the typical retail consumer.
does the z-wave network auto-heal like zigbee? if not, maybe it should be mention either by the device manufacturer or the Hub manufacturer to run a z-wave repair after joining every new z-wave device. But even then, that doesn’t help sleepy devices does it?
If you assume that most devices are installed by professionals, you leave it up to the professionals to decide how to maintain network efficiency. And in practice this has usually meant the manufacturer of the hub. Not the individual devices.
Smartthings is actually unusual in that it doesn’t have a best practices of running a network repair on a regular basis. Vera runs one every night. Homeseer makes it optional but recommends running it every night. Some systems run one once a week. Smartthings not only doesn’t automatically run one, it doesn’t even tell people they can unless support brings it up as part of troubleshooting.
Zigbee will self heal over time, but you can force it to heal sooner as part of troubleshooting by the unplug method.
The following article explains. “Router” in this context is a repeater.
The Zigbee network itself is constantly performing route discovery, updating neighbour tables, updating parent/child associations and many other tasks in a way that’s totally transparent to the application running on the Zigbee device.
Router nodes and the coordinator node are set-up to periodically broadcast route discovery requests, and maintain a (run-time established) table of routes to nearby router nodes, and end nodes (both sleepy end devices and end devices). So, if you lose a router node from the network (say, the router loses power and disconnects from the network), then other routers and coordinator will update their neighbour tables to reflect this, and will establish new routes that work around this lost router node.
Router nodes also assign route priority (when there are multiple paths for a packet to get from a source node to a destination node) based on a link quality metric (LQI). So, if you have an established Zigbee network and the currently preferred route sees a sudden decrease in LQI (say, you have two nodes near a microwave in your kitchen, and when you turn on the microwave there is a lot of interference on that specific hop in the network), then the routers will automatically re-assign this path through another set of hops that are more preferential from an LQI perspective. This is usually determined by the RSSI of the packets through a hop, and also on the number of MAC and APS retries needed to receive the ACK from the next node in the route.
For sleepy end devices, if the sleepy end device’s parent node (usually a router) drops off the network, then the sleepy end device will notice this the next time it attempts to poll the parent. Upon receiving no response the sleepy end device will leave and rejoin the network, and request a new parent node.
From the parent side, if there is a sleepy end device that fails to check-in (say the sleepy end device loses power), then the parent will age this device out of its child table, broadcast the ‘device leave’ to the other nodes on the network.
In these ways (and many others as well), the Zigbee network is already self-healing. You don’t really have to do anything to enable this functionality, as long as you have a high enough router density in your Zigbee network, these self-healing mechanisms will take place automatically in a way that’s transparent to your application.
Sleepy devices work differently In zwave, which is why you don’t typically see zwave presence sensors. Zigbee has a call and response check in at least once a minute and usually a little more often. Zwave does not.
However, sleepy doesn’t mean sleep for several minutes. It’s usually an interval in seconds, sometimes even milliseconds. And the repair is issued a couple of times. So you’ll typically get all the devices. You can see the ones you didn’t in the messages from the repair utility. I know a lot of field techs who will run two or three repairs in a row, but as a practical matter it’s probably not necessary.
Zwave Introduced “explorer frames” in STK 4.5, which was supposed to add the same kinds of self healing options that zigbee networks have. But it just isn’t as efficient for several different super complex reasons, including the fact that zwave requires that everything be backwards compatible. So you’ll see a lot of “may” clauses in the Z wave documentation. Not “will” like you see in the zigbee documentation. It’s definitely better than it used to be, but hasn’t removed the need to run the occasional repair utility manually.