Zigbee Heal - hub off vs zigbee radio disable?

destructure00 · January 1, 2019, 4:55pm

I moved some Zigbee devices around recently...outlets, motion sensors, and contact sensors. I'm wanting to do a Zigbee heal to address this. Does it matter if I completely power down the hub or just disable the Zigbee radio for 15+ minutes?

bobbles · January 1, 2019, 5:01pm

I've not done it on HE, but the process I used on ST is as you have described. Turn hub off for 15 minutes so that the devices go into 'panic' mode. I always left it for 30 mins though just to be sure.
Cannot think of any reason why doing the same on HE will not have the same results as ST.

destructure00 · January 1, 2019, 5:03pm

Thanks, I'm wondering specifically if there's any difference between completely powering down the hub and just disabling the Zigbee radio. If disabling the Zigbee radio will do the same thing, it seems like overkill to turn off the hub completely.

Cobra · January 1, 2019, 6:10pm

The reason the devices ‘panic’ is because they can no longer contact the controller.
Turning off zigbee for 15-20 mins should be sufficient.

Andy

patrick · January 1, 2019, 6:12pm

There should be no reason to force the zigbee devices into "Panic mode". All you are doing is draining batteries doing this.

Zigbee self heals over time. It's built into the protocol. Just give them time to check in and build the new route tables.

Cobra · January 1, 2019, 6:16pm

Unfortunately, the xiaomi devices seem to fail to update routes normally.
I find they tend to keep old routes even if a new router is placed next to one of these devices.

Amdy

destructure00 · January 1, 2019, 6:26pm

The trigger for me to do this was that I was having some problems getting one of my Sengled RGBW bulbs to turn on last night. A few days ago I moved a repeater from between the hub and bulb to the other side of the house. It's far enough away that I'd have concerns about range, but it also may still be reachable by the bulb...not sure. My uneducated assumption was that this could be part of the problem. So I decided to give the "panic" method a shot.

I won't claim to understand exactly how all of the repeating and self-healing works, but it seemed to me that other than some battery drain, it couldn't hurt to force everything to rebuild routes from scratch since I have moved a bunch of stuff around in the past few weeks. Repeaters have been moved due to taking down Christmas decorations, and I've been experimenting with new motion sensors in various places, and moving them to different rooms based on whether or not I like the results.

FWIW, the RSSI number for the Sengled bulb with the intermittent problem has gone from -78 to -56 in the hour since I did this. I could be totally off base on all of this, but it seems like it might have helped.

@JDRoberts had a great explanation over on the ST forum that prompted me to do this instead of relying on self-healing.

JDRoberts:

It’s one of those “can’t hurt, might help” kinds of suggestions.

While zigbee mesh is self healing, it doesn’t mean quite the same thing as the full zigbee heal, Which is what happens when the coordinator (hub) is powered down.

“Self healing” in this context simply Means that if a preferred message route is unavailable, the sending node will try an alternate route. There are multiple steps involved in all of that, but that’s really all it means. No human intervention is required in order to get a message to take a different path. And this process, as you guessed, is very quick, usually less than a minute.

The problem comes in educating the nodes as to what potential paths are available, and the depth of the network at each repeater (Different model devices support different numbers of children, so if a parent that could support five children goes bad and the only alternative available only supports three children, you can be left with “orphans“. )

If you rely solely on zigbee self healing, It’s quite possible to end up with “orphan nodes” which know they belong to this network, but which have no parent to repeat messages for them, even though there are parents with available child slots.

Also, in some cases when potential parents were added to the network after the children already existed, those parents end up never being considered as possible substitutions. This just gets complicated.

When you temporarily remove the hub (the coordinator) from a zigbee network, The other devices assume that the network is being physically moved and that none of the previous paths can be relied upon. Consequently, when the coordinator comes back, everybody starts over in building their preferred paths. This will generally pick up any orphans and also improve efficiency if new parents are available who would be a better first choice than the old ones.

So in this sense “healing“ (sometimes called “forced healing”) Is a much more thorough process and allows every end device to consider every possible repeater as a parent candidate. This process can take much longer than a self heal, Sometimes hours, to complete, so field techs usually don’t check for the full results until the next day.

Self-healing just occurs when a sender tries to get a message through, the message doesn’t get through, and the sender asks itself “hmmm, do I know of any other paths to that destination?“ self-healing does not normally assign new parents to orphan devices.

So self-healing is a good thing, and helps keep the network operating When there are temporary problems along an individual message route such as local interference. But a full heal Essentially rebuilds the whole network and causes more efficient parent/child assignment, as well as picking up any orphans.

I’m sorry, I don’t know of any really simple explanation for this, but here’s A good technical paper which describes the difference between what happens when the coordinator (hub) goes off-line versus what happens when an individual repeater like a light switch goes off-line.

The one thing to note is that in their example it’s a sensor net which is choosing a new coordinator. In the zigbee home automation profile, which is what smartthings uses, there’s only one potential coordinator, a hub, and it’s either there or it isn’t. But the distinctions between the types of failures are similar, particularly with regard to orphan nodes.

The following paper was published in a peer reviewed journal, the International Journal of Computer Science Engineering and Technology (IJCSET)

http://www.ijcset.net/docs/Volumes/volume3issue3/ijcset2013030309.pdf

This is the key distinction

When a device is found orphaned {during a forced heal}, a realignment or a channel re-scan process will be invoked.

That will happen only when the coordinator (hub) is powered off for at least 15 minutes and then on again.It does not happen in self healing.

Ryan780 · January 1, 2019, 7:36pm

I've read that article from JD before...and my take-away was this:
If you are just adding devices or moving things around a little bit, let the self-heal work it's magic and everything will be fine. No need for a "force-heal" (what I'll call the power-pull process). But, if you add a repeater or move around a LOT of devices or notice that things are taking a long time to respond or not responding at all, it might be time for a "force-heal". Would that be accurate @patrick? Others?

stephack · January 1, 2019, 7:37pm

That was precisely my takeaway.

Ryan780 · January 1, 2019, 8:00pm

One question that i don't think was answered though, can you just disable the zigbee radio via settings and get the same result? Or do you have to pull power from the whole hub?

stephack · January 1, 2019, 8:12pm

I can't see how it would be any different. My understanding is that once the devices can't find the hub for 20 minutes they enter panic mode. Pulling the power or disabling the zigbee radio should be identical from the point of view of the zigbee clients.

Of course that is just using my own logic. The zigbee engineers probably don't drink from the tap like I do.

Navat604 · January 2, 2019, 2:56am

This is very true. Don't do zigbee heal unless there is a reason. Half of my battery devices went almost dead when I shutoff the hub for about an hour. Costed me an arm for batteries. Zigbee mesh changes constantly when looking at my xbee. This probably is self healing.