FAQ: Mapping your ZigBee network with Digi's XCTU

Paul, battery powered devices (child devices) have a single parent that is a router or hub/router. Their parents (the routers) do the routing for them and the traffic may have multiple paths to travel. That is why you see multiple routes between routers. You wont see a child device connected to multiple routers, they only have one parent. However, a child device can re-home its-self to another router if that router is down and another one is available.

So if your “thing” is a battery powered device its traffic will be handled by a router that can take advantage of multiple routes. It is a little confusing because a “thing” in the SmartThings cloud can be a child device or a router.

2 Likes

Thanks @JohnR. I must be going blind because I could swear I’d seen a map with a battery device routed through multiple paths back to the hub, but of course you’re right.

Anyone know the timings of a child device deciding to pick a new parent? Does it happen fairly instantly on the first fail?

And can the reverse happen? If a child is moved from the range of one parent to another, can the new parent initiate the relationship, or do you have to wait for the child to ‘call home’ and find the original parent missing?

I know in most cases ‘things’ don’t move, but Presence Sensors do, and I’m trying to understand some strange behaviour here. (Well, other than the fact that presence sensors are a bit rubbish - I have one where the battery level is 1% one minute, then 45% the next!).

In addition to @JohnR 's excellent explanation, if you are adding a new zigbee repeater and you really want to get a specific battery powered device to use it as its parent, after adding the repeater you can then remove the battery-powered device, factory reset it, and re-add it to your network. Now it will look for its best parent from all the candidates (including the new repeater) and likely choose the one with the best signal strength. But that’s a lot more work and isn’t usually necessary.

1 Like

If only there was an easy way to do that in ST, without first removing the device from all of your smart apps, then adding it back in again afterwards.

What we need is a RE-connect option for existing devices.

P.

@JDRoberts I will let you respond to this. -smile-

Oh, thanks! :stuck_out_tongue_winking_eye:

I suspect what John is alluding to here is that different devices have different behaviors in this circumstance. But since each zigbee device has its own permanent ID, it’s usually quite possible to simply reset the device and then re-add it without telling the network that you reset it. That way you don’t have to change any of your smartapps ( which use the network ID to identify the device). In most cases for a battery powered zigbee device this will cause it to choose a new parent if the selection of repeaters is different then the first time it joined.

(Note that this does NOT work for zwave devices, because their network ID is assigned by the hub when they join. For Z wave, you would use the “replace” utility in a similar situation. But you don’t need that utility for zigbee because the device’s ID is always the same anyway. )

People do this a lot for GE Link bulbs since those have a firmware flaw which can cause them to lose contact. The point here is simply that it’s very easy to reset them and add them a second time without making any smart app changes and everything will work just fine.

John can add more details if I’ve left something out for a SmartThings network.

1 Like

I had a long post here about specific issues with the smartthings presence sensor, but since you asked the same question in a different thread, I’m going to respond over there. :sunglasses:

1 Like

As usual @JDRoberts nails it!! Not that he needs me to confirm what he says!! The main reason I wanted JD to answer is he gives great detailed explanations!! My answer would have been more along the lines of: SmartApps don’t care what parent your device is using. There is no need to reset them!!

1 Like

All has been working great until yesterday. 2 presence sensors left the building and never came back! When I check with xctu to see what is going on get ‘ACTION REQUIRED Reset your radio module’

Also, the recovery procedure does not work - same error.

https://docs.digi.com/display/XCTU/Recovery+tool

Any ideas why it all died yesterday (xigbee network and xstick) all lights and sockets not working from smartthings…

Update/ Even a hardware reset http://knowledge.digi.com/articles/Knowledge_Base_Article/Location-of-the-reset-line-on-an-XStick
doesn’t work. Have to send it back i suppose…

Very strange. I haven’t seen anything like this. The most likely time to brick your xstick is when you first configure it. Once it is configured and working okay I have never seen it do this. About the only thing I can think of that would cause all this is some type of massive RF interference on the same ZigBee channel. Have you added a WiFi router / access-point lately or moved one of your WiFi routers / access-points? Try moving your xBee far away from possible interference and see if you can communicate with it. Maybe shut your hub off and see if you can talk to your xstick. To knock all your ZigBee devices off the network it may not even be a WiFi hub it may be some type of malfunctioning radio in one of your devices. But I’m just guessing, very strange!! It is possible to send a leave network command to all ZigBee devices but that wouldn’t prevent your from communicating with your xstick. So I dont think it is that. I’m favoring some type of RF interference.

Thanks for the advice - No not touched a thing

I rebooted the smartthings hub and eventually all the devices came back and are now working.
I’ve also eventually manged to hardware reset the xstick and have recovered it, so that’s working also!

Lets see if it happens again!!

1 Like

Has anyone tried this with a UK smartthings setup?

The scan isn’t working for me, and so I wondered whether it needs a tweak to the XML profile file.

My ST hub (at least, I assume that’s what it’s found) shows up as discovered, but unreachable.

P.

Sorry for ‘content free’ response but hopping between other stuff - yes, I did this in the UK, following the original instructions several months ago, with success - could see all the nodes etc.
I did do it on a V1 UK hub though.

1 Like

I don’t think there was a V1 UK hub was there?

Fixed it!

Sorry.

1 Like

First, thanks for this FAQ. Second, sorry for reviving an old topic, however I really felt it was the right place to do it. I was hoping to get some additional information on deciphering the information once this is set up and running. There are clearly devices that seem to “snooze” more than others. Specifically I am seeing my cree connect and osram lightify being particularly temperamental. The icons turning red, and long red arrows with xx/xxx. For example 29/42 for one particular bulb connected to another device. People who have played with this extensively, what are your lessons learned or advice? I’m considering just replacing all my cree and lightify with hue, as I have a hub and they seem rock solid, and don’t seem to cause my other sensors to be flaky (this is just a theory on my part regarding the cree and osram stuff) Thanks in advance.

1 Like

This has piqued my interest in trying to better understand my (problematic) ZigBee mesh. One question, please: I see two variants of the xStick, the “ZB” model and the “802.15.4” model. Should I get the former, latter or either?

I use this one: http://www.mouser.co.uk/Search/ProductDetail.aspx?R=XU-Z11virtualkey58170000virtualkey888-XU-Z11

1 Like

Same here.

1 Like

My X-Stick arrived today and I’m looking at the graph. Interesting stuff hidden in there. It would be really useful if XCTU provided a device “alias” capability - something like a table to map ZigBee ID’s to friendly names. I don’t see it, so probably not, but maybe someone can tell me if it’s hidden away.