Bought zigbee repeaters - Devices still only connecting to the hub

Thanks guys.

The big question now: did I just waste 75$ by purchasing these powered zigbee switches?

Now being part of a better mesh, will my furthest sensor switch its connection to the repeater in case it goes down? Because it will… It did in the past by connecting to the same parent (hub). I believe it has to do with wifi interference. There is a wifi camera a few inches away plus a Lennox router 10 ft away (Lennox uses a router for some reason on their high-end furnace panels).

I was a network engineer working with Zigbee and zwave before I ever bought SmartThings for my own home. This stuff can get really complicated and zigbee and Z wave are different in this regard. It all depends on the sequencing for zigbee.

The OP said that they added the new orvibo switches as repeaters and then “reset” the sensors.

A Z wave device can be “factory reset” without changing its internal address tables. That’s why there is a Z wave repair utility.

Zigbee is different. Zigbee provides multiple ways to “reset” The device. If you do it through a network command (a faculty that smartthings does not provide), then indeed the neighbor tables would remain intact. Zigbee calls these “persistent data.”

However, if you reset the device “locally,” meaning through physical manipulation of the device itself, such as the reset mechanism for most ZHA sensors, then, for a zigbee device – – but not a Z wave device – – The device will in fact be fully reset, including wiping out the existing neighbor tables. Then when you add it back to the network again, entirely new neighbor tables are built, which in the example we’ve been discussing would indeed cause the sensors to consider the new Orvibo switches as potential parents, because the switches existed on the network at the times the sensor was added back. That’s why no heal is required in this specific situation.

You’re absolutely right that if the Orvibo switches had been added to the network and the sensors had not been reset, then a heal would be required to get all the neighbor tables updated.

But because the reset was done on the individual sensor, the heal becomes one of those “can’t hurt, might help” things.

Like I said, most people wouldn’t care about this level of detail, it’s very technical. And there’s no problem with just doing the heal every time you add in some new devices. And if this were a Z wave sensor, you would have to do a network repair. But as it is, assuming that the zigbee sensor was in fact “reset” after the Orvibo Switch had been added to the network, you don’t need a heal to force the sensor to consider a new parent: the reset already did that.

See section 9.5 in the following:

Things are complicated even a little further by the fact that this is the recommended behavior, rather than the required behavior, and there are, for example, some security systems which are sold as a set where the persistent information is not Cleared by a local reset. That’s done for security purposes. But I’ve never heard of a zigbee home automation device that was built in that way. It’s possible, but usually a reset is a reset on those. :sunglasses:

I hope that helps clears up any confusion. Again, as I said, this stuff can get really technical and I know most people don’t care about it one way or the other.


Since they weren’t working, can’t we assume that something else has to be done? I mean, if the reset of the devices would have been the solution, then they would have worked. Your answer is very long winded but I fail to see where you answer the question I posed. What would you have recommended to do instead? Your post doesn’t really address that. In fact, your pages long answer doesn’t either. In fact, you didn’t really offer any advice on what to do next.

As I mentioned, I don’t think you can force the sensors to choose a different parent than the hub if they are within 1 hop of the hub unless you first fill up all the child slots on the hub, and I’m not sure that would really make sense anyway. So that was my response to the question in the first post of “Any idea why?” The why is because the hub will always be the preferred parent for most devices if it is within range and has child slots available.

With regard to the Orvibo switches frequently rejoining, as I said, I have no idea why that’s happening. Which is why I suggested getting in touch with Orvibo as a next step.

The question of whether having additional repeaters nearby would help in the event of Wi-Fi interference is one I hadn’t addressed yet, but the short answer is yes, it should. Even though the hub will be the preferred parent, the sensor should try an alternate route if it’s not able to get through to the hub directly. I can’t say whether it would solve the problem altogether, that just depends on how bad the interference is, but in general, the more available repeaters the better. :sunglasses:

At 40 feet, the hub is probably right on the edge of being reachable, so it makes perfect sense if sometimes messages get through directly and sometimes they don’t. Having an alternate route available through the Orvibo switch sounds like a very good idea. Even if they’re not needed all the time, if they are there to help out when interference prevents the direct message, that’s a good thing. :+1:

I don’t know who flagged you, but it wasn’t me.

I didn’t say a zigbee heal wasn’t the right thing to do, I just don’t think it’s going to change the outcome as far as the sensors choosing the hub for a parent. The good news is that the sensors choosing the hub as a parent isn’t necessarily a problem. They should still use the alternate route if the direct route to the hub is unavailable. And as long as an actual local reset was done on the sensors, they should be aware of the alternate routes.

Whether or not that alternate route will help with the dropoffs, I can’t say for sure. If the problem is Wi-Fi interference, it’s just going to depend on how strong that interference is.

I can’t answer the question about the frequent rejoins, that’s why I suggested contacting Orvibo about those.

The original question was why didn’t the sensors show the switch as the parent. And the answer to that is that if they can reach the hub, they generally will choose the hub as the parent even if it is physically farther away than another repeater. The zigbee parent selection algorithm does that because it makes for the most efficient network.

But because the hub is probably right at the outer limits of the range that they can reach In one hop, it is certainly good to have other repeaters available nearby for those times when a message can’t get through to the hub directly.


Some updates guys.


  • executing a mesh heal
  • manually resetting the Visonic window/door sensors
  • replacing the batteries for the most unstable ones
  • trying two different device handlers (the most popular custom one, and the local one provided by ST)

Half of the Visonic sensors are dead again this morning.

The most erratic one is the one that actually did achieve to connect to a repeater. It will report maybe 20% of the events (ex.: opened but no closed, then no event for 1 hour).

I see two possible root causes:

  1. The ST firmware update from last Sunday, because “shit hit the fan” at this exact moment after about 4 months of perfectly working sensors
  2. Since the ST firmware killed my hub for about 8 hours, this triggered a mesh heal, now including repeaters that were added the week before and that are unreliable

Very, very frustrating. I’ve spent over 15 hours on this so far. I’m about to get rid of my 30+ sensors, drop SmartThings and go z-wave.

1 Like

Wow, I’m sorry you’re dealing with all of that!

There’s definitely been something weird going on with zigbee on the smartthings platform over the last few months, although I don’t think anyone’s been able to pin it down. Lots of concerns about devices being marked unavailable And devices, including the smartthings branded ones, dropping off the network frequently.

Because smartthings is a cloud – based multiprotocol platform which allows for literally dozens of different device configurations, it can be really difficult to tell exactly what’s going on.

So I wish I had a simple answer, but I don’t. The firmware update definitely seems like a candidate, but there were also some platform updates around the same time, so who knows?

This is absolutely the thing I hate worst about any platform, but particularly this one: when things that worked on Monday just stop working on Tuesday without the end-user haven’t changed anything.

One other thought: zigbee bulbs as a potential problem

One other question we haven’t asked yet: do you have any zigbee bulbs, any brand, connected directly to the smartthings hub? I ask that because most of the brands have proven to be unreliable repeaters. They can get a kind of “buffer overflow” condition where they will drop messages, which can make it look like a sensor is having problems when in fact the sensor is fine and it’s that the bulb isn’t passing its messages along. (Devices connected to a hue bridge don’t have this issue, just ones connected directly to the smartthings hub.)

This is a known issue, confirmed by SmartThings staff, but nobody has a fixed yet other then some tricks to keep the sensors from using the bulbs as repeaters. And those tricks can get overridden in situations like the one you mentioned where it’s the hub itself that goes off-line for a while.

That may not have anything to do with the issues you’re saying, but I just wanted to mention it as it does create similar issues.

The sensor…

Back to your specific issue…

The only other thing I can think of at this point is to start a new thread with the sensor brand and model in the title that says they keep dropping off line and see if anybody has found any tricks specific to that device. I don’t have any of those and I haven’t really looked at them. You never know: somebody in the community may have some suggestions.

Zwave as an alternative?

I don’t know if this helps any, but you’re not the only person in the last four months or so who said they’ve switched over to Z wave to improve reliability In a SmartThings context.

I do feel confident that it’s not the zigbee protocol itself: there are lots of other systems, including ones at hospitals and utility companies, based on zigbee which run really well. And for that matter the Phillips hue zigbee system doesn’t seem to have any of these issues even when it’s in the same house. So I do feel a little protective of the protocol in that sense, I hate to see “zigbee” get a bad name because of a specific platform implementation. :disappointed_relieved:

At the same time, I believe the people absolutely when they say their zwave devices are working more reliably in this context. (on the other hand, there are some people in the same timeframe who have had all their Z wave devices stop working, but there do seem to be fewer of those.)

Again, I just wish I had a better answer. So I know it doesn’t help any, but I do feel your pain. :scream:


Before you go nuclear, could you assign a different channel for 2.GHz in your router? You may have some interference with zigbee.

I also had some issues after the upgrade that was solved after two router reboots. But automation suffered for about two days more.

1 Like

My router is set on channel 1, versus channel 15 on the ST hub. Looking at the frequency bands for wifi and zigbee, I came to the conclusion that there was no conflict. I’ll still give it a shot.

Do you mean wifi router reboot, or ST hub reboot?

1 Like

Thank you JDRoberts. Unlike some other members, I find your input extremely valuable and complete.

I don’t have zigbee bulbs directly connected to the hub. I only have Phillips Hues connected to the Phillips hub.

I’ll give a new thread a try, this time specifying the brand/model in the title.


Zigbee channel 15 is in “sideband lobe” for WiFi channel 1, meaning you can get some occasional bleedover interference, although it shouldn’t be too bad unless you have a lot of heavy continuous Wi-Fi streaming. But you would get more separation if you changed your Wi-Fi channel to 11.

See the following:

And this article about sidebands:

You might also check the zigbee channel on your hue bridge. That one’s really easy to change if needed.

Thanks JDRoberts.

I did some modifications yesterday:

  • relocated my hub 20ft away from the wifi router. It used to be 1ft away
  • turned off my Hue and Lutron hubs
  • triggered a mesh heal
  • reset the devices that wouldn’t connect despite the mesh heal

It seems to have improved the situation.

One question. I see some devices ZBJOINing parent FFFF. What is it? It is not a repeater and the hub is 0000.

1 Like

Tagging @tpmanley

The primary reason the parent is FFFF in the zbjoin message is if the device is a router and not an end device. End devices have a parent on the network that does all the routing for them but routers do not. There are a couple of other situations where the FFFF will show up including a minor bug I found recently that only affects populating that parent field but doesn’t have any other downstream effects. In general the parent field is helpful but should not be treated as 100% accurate because the parent can change without a zbjoin event. Improving the accuracy of this information is something we are working on.


Just for clarity, “router” in this case is a zigbee term meaning repeater. So your new Orvibo switches are zigbee “routers” since the manufacturer says they repeat. Your existing battery operated zigbee sensors are not–those are “end devices.” :sunglasses:

Thanks guys for the input.

New updates: 50+% of my zigbee sensors went down yesterday after 3 days of great stability.

I scratched my head really hard on what could have caused it. Well, at this exact moment was the first “Netflix streaming” time in 3 days. The signal goes all across the house (router and 2.4gHz Chromecast being at the two opposite sides).

My router is set on channel 1, versus channel 15 on the ST hub. As recommended by JDRoberts, I’ll switch my Wi-Fi to channel 11. I’m not a big fan of this idea because upper Wi-Fi channels interfere with my Panasonic microwave… But let’s give it a shot.

@tpmanley Tom, that’s useful information (re:FFFF). I wonder, could you shed some light on “joinType”? (I think I’ve seen 0, 1, 255). I’ve been trying to figure that one out without any luck.

Thanks in Advance!

This comes from the status field in the Update Device Zigbee command. 0 is secured rejoin, 1 is unsecured rejoin, 3 is unsecured join and we use 255 for unknown.


@tpmanley Tom - really appreciate the answer - you’re great! (I’m troubleshooting xbee zbjoins and this really helps!)

1 Like

You’re welcome :slight_smile:

Let me know if there is something specific you are wondering about with your XBee and I can try to help. We can get a little more info than just what you see in the zbjoin message.