FAQ: Mapping your ZigBee network with Digi's XCTU

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.

I’m considering if I have any control over the configuration of the mesh. For instance, I have one troublesome device that, at least as I look at the XCTU mesh at the moment, goes through a repeater. If I turn off that repeater and rebuild the mesh, then I’d have a chance that the device would directly connect to the hub. But, my question is, what happens if I turn that repeater back on? Does the mesh see it and possibly rebuild in a way I don’t want? Or, will the mesh stay static until the next ZigBee complete rebuild?

If you power off the problematic router (e.g. GE Link bulb or whatever it is) the device will end up with a new parent which might be the hub/coordinator (pretty much whichever router responds first to the association request). If this parent is the hub I do not believe messages should ever route through another router as long as that relationship remains.

If at some point the device is unable to reliably communicate directly with the hub (or whatever router is in use) it may select a new parent and inform the network. There isn’t really anything that can be done to avoid this, but it should not happen if the device is in good RF range of the hub.

We have discussed various ideas about trying to improve ZigBee network health on the hub side by controlling the join process more carefully but most every thing we have discussed has had some drawbacks. Ideally, all devices on the network would behave well, but that isn’t the case. We do have ideas on reporting and exposing additional network information to the end user from SmartThings (similar to some of what is shown with XCTU) but it, like many things, has to compete for development time with other projects/priorities.

The XBee and XCTU are very useful tools – Prior to SmartThings, I worked at Digi for a number of years and worked with several of the engineers who both work on the XBee product and the XCTU software.

5 Likes

@posborne , in case you haven’t been following this particular case in the other thread, the devices in question are two ceiling fans with zigbee controllers in the fan canopies. In my experience, ceiling fans are always tricky unless you can put a repeater on the floor above. The moving blades are a frequent source of physical interference and consequent dropped messages. Just tricky. :tornado: :tornado:

Thank you @posborne and @JDRoberts. JD, here’s a curiosity: if you recall, my fan blades are metal, greatly exacerbating the problem; but in the last week, the only two times the fan controller dropped off was when the fan was off.

Another topic for @posborne - In the case of a misbehaving ZigBee device, do you recommend turning system Device Health on or off?

@JDRoberts Going above the fans is not impossible in my case, but I’m hesitant because it would require I run power to a new attic outlet and then to leave the repeater in a 160°F torture chamber. One other possibility to which you might opine: The fans are 2’ below the ceiling, so I could place a repeater at ceiling level triangularly placed 8’ away from each but with LOS to the ZigBee controller above the blades.

Another footnote to the mesh configuration. After the last failure, I one again moved the ST hub under the fans (WAF plummeting) and rebuilt. To my horror, the mesh came back configured to reach out 40’ through my front door to an Osram GardenSpot before hitting the fans just 10’ away.

We’re getting pretty off-topic for this particular thread, which is an FAQ on mapping, so I suggest you start a new one under Devices and we can discuss the particulars of this specific situation there. :sunglasses: Maybe call it “Zigbee Fan Controller Issues” or something like that.

https://community.smartthings.com/c/devices-integrations/connected-things

I think the discussion is a good one, it just doesn’t belong in this thread.

The one ontopic thing I would say is that zigbee devices choose their parents based on a number of factors, including signal strength. With a fan, when it’s moving it makes it hard to get signal through, but even when it’s stationary where the blades stop may be different than where they stopped at the time of joining. And that will change the perceived signal strength for other devices. This is one reason you’ll see weird route selection, as well as differing route selection if you remove and re-join a different time. But a discussion of what to do about that issue belongs in another thread.

You’ll also see this kind of variation in parent selection in a building where doors are sometimes left open and sometimes not, and in buildings with large metal equipment like forklifts which may be left in different places on different days. When a device keeps choosing a different parent, it’s most often because something in the environment keeps changing.

1 Like

Turning device health on/off will remove the health indications you might see on mobile but it won’t really impact network health – this seems to be a misnomer bouncing around the community that AFAIK doesn’t have any real validity. For most supported devices, the determination of device health is just based on periodic reports that would already be pushed from the devices. Some of these values may have changed some when device health was first rolled out, but I do not believe that turning off the feature really impacts what messages we send to devices (or the configured reporting intervals).