I have a bunch of Zigbee (ThirdReality brand) Door Contact and Motion Sensor devices that seem to have automatically migrated to the new Edge drivers, which is nice. I recently added a bunch of Zigbee (also ThirdReality brand) Smart Outlets, which supposedly act as Zigbee repeaters.
Is there a way under the new platform to verify that the Zigbee Smart Outlets are in “repeater” mode? Is this something you can do via the CLI?
Thank you!
If they are designed to be Zigbee repeaters, they should automatically repeat as soon as they join the network, you don’t have to do anything special, and you can’t turn off that capability. So they should be fine.
Last I heard, we didn’t get routing information from the new architecture, I don’t know if that has changed. 
We should also note that Zigbee assigns a specific parent to each device, which Z wave does not.
That may mean the devices that were already on your network before you added the third reality plugs will not use them as repeaters.
If you want your existing devices to consider the third reality plugs as candidate repeaters, you have to “heal“ the Zigbee network, to get it to recalculate the neighbor tables.
Fortunately, this is easy.
First add all your devices to your network.
Next, take your hub, and only your hub, off power, including taking out batteries if it has those. Leave it off power for about 20 minutes. This will cause all of the other devices to go into “panic mode“ because they can’t find the hub.
When you power on the hub again, all the devices will rebuild their neighbor tables. This will potentially allow them to select new parents if new repeaters have been added to the network.
This process can take a little while, so you may not see results until the next day, but once it’s done, every device that can efficiently use the new repeaters should be using them. 
I wonder why their is not a menu driven way to do that like you can with z-wave devices with the z-wave repair process.
“Zwave repair” is a utility defined in the independent third-party specifications, and is started by a special instruction to the hub. That’s why it needs a menu option.
Zigbee works differently. No instruction to the hub is required. You just have to take it off power for about 20 minutes and then everything works automatically.
Thanks for the explanation. I would prefer a menu driven way rather than having to unplug the hub, particularly when you are remote from the hub, but obviously not possible.
I understand, but the other thing about the zwave repair is it doesn’t require taking the hub off-line, so it can just continue going. Since the Zigbee protocol requires taking the hub off power, there’s no way to get it back on again in network. It’s just not part of the specification.
The other thing is that almost the only time you need this is when you are adding new devices, and again, the protocol requires that you be physically present to do those. So since you’re on location adding the new devices, you’re on location to power down the hub.
Zwave is different because it allows for bench pairing, and a network repair is often initiated remotely. It’s just a different network design.
If you really think you would need to do a Zigbee heal more often when you aren’t adding new devices, plug the hub into a Wi-Fi smart plug which can be operated independently of smartthings and then you can turn it on and off remotely as long as the Internet is operating.
Again thanks for taking the time to explain it so thoroughly, makes sense. No worries, I was just trying to understand why their was no menu driven way to do it. I know why now.
A better way would be to be able to turn off the Zigbee transmitter in the hub then. This could be done remotely, by app.
Even if you only need it when adding new devices or changing setups, it feels very outdated to need to unplug the device, wait 20(!) minutes and plug it back in. Not to mention it means that in the mean time possible Z-wave devices aren’t functioning either. I even think it’s a bit silly that all other Zigbee devices need to lose control for probably only 1 device to find a better route.
Having a way to send out a “reset connection” request to all devices would be the most preferred option of course.
Certainly it’s arguable for a multi protocol hub to have that kind of option. There are just a lot of other things I’d like to see SmartThings work on first. JMO, of course. 
also, just a nitpicky engineering note, but in a mesh network like Zigbee we try really hard to avoid any “all devices respond“ commands. A lot of the battery operated devices may be asleep when the command goes out, and any extra command can use up extra battery life. Instead, when you take the hub off-line you’re pretty certain that at some point in that 20 minutes, the device, or at least its parent, tried to contact the hub, and then realized it wasn’t there, which initiates the later rebuild.
.
Zigbee was designed from a network standpoint to allow the creation and deployment of inexpensive low power devices. Mostly to enable cheap sensornets. As smart devices go, Zigbee devices are pretty dumb, but that’s what keeps them cheap and low power.
.
Making every individual device smarter (and therefore more expensive) to enable an “all devices” command which you’re hardly ever going to use in the field just doesn’t really fit the paradigm.
.
An individual radio restart, however, particularly in a multi protocol hub, is more doable: but again, in a multi protocol hub, do you really want only one protocol’s devices turned off at a time? Isn’t that more likely to introduce confusion and potential safety issues for your typical mass-market consumer?
.
A heal should be part of system maintenance. Personally, as the field tech who has to explain things to the on-site customer, who may not even know which of their devices are Zigbee and which are zwave, let alone which routines mix devices of multiple protocols, I’m OK with saying “I have to take the system off-line for about 30 minutes to do some maintenance.” But that’s just me.