Bought zigbee repeaters - Devices still only connecting to the hub

General Discussion
1

Hello there.

I’m currently setting up my SmartThings environment with different devices including Visionic door/window sensors.

The house is a fairly large (64ft wide) 3-storey cottage and due to cabling limitations, the SmartThings hub is located on one extremity (3rd floor, far left).

Due to connectivity issues on the other extremity (basement, far right) and the absence of powered zigbee devices, I bought some zigbee repeaters: Orvibo ZigBee Light Switches marketing the following product highlight: “Mesh network, each device is a router. There is not distance limited in network”

When I reset a sensor (ex.: Visionic) located less than 5ft away from the repeater (and about 40ft away from the hub), if I look at the hub events log, it seems like the sensor is still connecting directly to the hub:
zbjoin: {“dni”:“BC4D”,“d”:“000D6F000B111BA2”,“capabilities”:“80”,“endpoints”:[{“simple”:“01 0104 0402 00 07 0000 0001 0003 0402 0500 0020 0B05 01 0019”,“application”:“01”,“manufacturer”:“Visonic”,“model”:“MCT-340 E”}],“parent":"0000”,“joinType”:0}

Any idea why?

Also, when looking at the log, I see that the repeaters are constantly zbjoining every 3 to 5 minutes:
zbjoin: {“dni”:“0A17”,“d”:“00124B00092B1D0D”,“capabilities”:“8E”,“endpoints”:[{“simple”:“01 0104 0000 00 04 0000 0005 0004 0006 01 0000”,“application”:“10”,“manufacturer”:"\u6B27\u745E\u535A",“model”:“545df2981b704114945f6df1c780515a”}],“parent”:“FFFF”,“joinType”:255}

What is parent FFFF? Why are they rejoining? They are very stable, I can reliably remotely trigger the switches at any time.

Thanks!
Yan

2

Zigbee devices use multiple factors when deciding what device to choose as a parent. Signal strength is one factor, for example. So it’s not unusual for them to find a parent which is physically further away than another.

Another factor is literally whether or not the coordinator has a child slot available. Almost all of the devices will choose to connect directly to the hub if they can – – that’s going to be the most efficient network. Why take a mesh bounce if you don’t have to?

If you want to force a device to use a particular repeater, you will first have to move it more than one hop away from the hub. Or fill up all the child slots on the hub (32 in this case).

But in general, if a zigbee device can use the hub as a parent, that’s considered a good thing.

As for the re-joining, I don’t know. I would start by asking Orvibo.

3 Likes
3

Do a full mesh network heal. Unplug the hub and remove the batteries. Leave unplugged for 15 minutes or more. Then plug back in and insert the batteries. Then your devices should re-assign to the nearest node. This is king of like doing a z wave network repair.

4

It never hurts to do a heal, but the algorithm to select the parent isn’t based on “nearest.” It’s based on signal strength and some other factors. They will probably still choose the hub if the hub is available as a parent.

1 Like
5

Yes but it also won’t recognize the new devices until you do a heal. It will use existing nodes even if the connection strength is low. It won’t automatically choose the best route with the strongest strength. So, what would you recommend the OP do to get the existing devices to recognize the repeater?

6

I think @JDRoberts is agreeing that doing a heal won’t hurt, might help, but it won’t necessarily result in a connection to a nearby repeater based on the context he provided. What I like to call violent agreement. :slight_smile:

2 Likes
7

I disagree. And it’s not that it will help, it’s required for the device to recognize the new node. Otherwise it will use the one it already has.

8

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).

9

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:

http://www.zigbee.org/wp-content/uploads/2014/10/docs-13-0402-13-00zi-Base-Device-Behavior-Specification-2.pdf

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.

6 Likes
10

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.

11

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:

14

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.

2 Likes
15

Some updates guys.

After:

  • 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
17

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:

2 Likes
18

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
19

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
20

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.

2 Likes
21

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.

22

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
23

Tagging @tpmanley