A bunch of devices all called "Thing" appeared suddenly (20 July 2019)

I noticed that like 65 devices, all called “Thing” appeared suddenly. I had added a Leviton Z-wave+ switch a day or so before but had otherwise not changed any setup in ST or messed with any Z-wave or ZigBee devices. Everything seems to be working as expected otherwise. Any ideas what could cause this? What should I do about it?

Perhaps a bug in the ide?
Do your devices show correctly also, or are they all showing as Thing in device list?

If it isn’t causing trouble, i would not try to “fix” this.

Well, the ST Classic mobile app and the IDE show the same. All my “real” Z-wave and ZigBee devices seem all still be there and functional.

I’m hesitant to just start deleting them as I’m not sure if they are actually causing an issue other than making things load slow as I now have 172 devices instead of the expected 105.

Hey @LLwarrenP, I’d be very interested in looking into this for you. Could you send me a PM with the email address associated with your account so that I may look into what’s going on here?


So just as an update for anyone else not involved but interested, engineering seems to have found a small issue in the ZigBee code and will release a fix in an upcoming FW release. Thanks to all for the quick response!

Also, supported separately added a note to a case I opened:

This issue seems to happen quite frequently when using an IRIS keypad. Next time when you try adding a device, you may want to try it with the keypad powered off.

Support also deleted all the 67-odd “Thing” devices which was a nice time saver for me.


So all my ZigBee devices went offline this evening, and hopefully that is because of this issue, I mean I can’t control any of light bulbs now, but z-wave lock and switch still works fine.

That sounds like a different sort of issue as I never had anything go offline - just a bunch of junk showing up unexpectedly.

While I am not really sure what could be going on in your case, I would probably try a hard reset of the hub and let it come back up and rebuild the ZigBee network. All the devices should rejoin. If not, assuming the hub hasn’t moved to a place where none can reach it, the only other thing I would check is the ZigBee “Insecure/Unsecure Rejoin” settings to ensure that it isn’t set to the most restrictive settings - you can find this in the hub properties in either the mobile app or the Graph API web interface.

@alextheangel I would suggest reaching out to support and they can walk you through debugging your hub if you are seeing the issue persist.

I would probably try a hard reset of the hub and let it come back up and rebuild the ZigBee network. All the devices should rejoin.

If you are referring to a factory/hard reset of the hub I would actually advise against this since this will require the user to set up their hub and all devices again manually. If you are referring to a power cycle then I would agree that this could be a potentially good debug step to take :slight_smile:

Either way, this is most certainly unrelated to the issue mentioned in the original post.


Yes, I agree. I just meant a reboot (or power cycle) of the hub, not a true wipe reset - the intent is to only have the ZigBee radio stop and restart. I’ve just found that since ZigBee devices tend to talk to the strongest device available, dropping the hub out will encourage them to talk to a neighbor instead of directly to the hub.

Best advice is as you say though - open a case!

1 Like

To update the zigbee mesh you need to leave the hub unpowered for 20 minutes or so. This will cause your devices to enter what I think is referred to as “panic mode” in their hunt to find a path back to the hub.


@BroderickCarlin. Just wondering if you might have some ideas on when that fix might go GA and get pushed? Reason I ask is that after deleting all the devices, today they are back again to the tune of 120 extraneous devices! This time it is a bunch of the “Thing” devices again but there are also like 20 devices called TH1123ZB-TH1124ZB" which is one of my 2 Sinope Thermostats.

FWIW, I’d say based on this that Support’s opinion about turning off things during a join doesn’t pan out since I’ve added nothing.

1 Like

@LLwarrenP, the fix will go out to the public with the first 27.x release. I can not provide a date for when this will be expected. We are also looking into ways to fix this that do not involve a hub FW update but do not have any estimates for this yet.

Support’s thoughts aren’t exactly right but they also aren’t far off. Without diving too deep into the technical details, a couple of your devices actually are doing a re-join which is for all intensive purposes nearly identical to a normal device join (There are some slight differences for obvious security reasons, but still). When a device joins the Zigbee network it is assigned a Device Network ID or DNI which is the unique 16bit address for the device (think of it like a sort of IP address). When a device goes through a rejoin it also can get assigned a new DNI. This is where the issue comes in. You have one specific device (a Sinope Thermostat) that is going through the rejoin flow and half way through something is causing the device to rejoin again and get a new DNI. Normally this wouldn’t be an issue as we would just start the discovery of the device again but for this specific device it starts to respond to our previous requests from it’s new DNI before we even begin the discovery process. This ends up causing some confusion to the hub as it sees this new device that joins and is sending info so it attempts to handle the situation by creating a new device record on your account. The hub tries to be proactive and start the discovery of this “new device” (aka the thermostat) and the process repeats itself ad nauseam. If you look in graph/IDE at these ‘thing’ devices you will see that they have almost no information associated with them (no model, manuf, fw version) since the thermostat reset before we could get any new information from it that would allow us to realize it was just the thermostat again.

Hopefully my ramble makes at least a bit of sense :stuck_out_tongue:

I don’t want to say that you should remove your thermostats from your Zigbee mesh but I do believe that would cause this issue to cease until we can get the fix(s) out to handle this. We are going to be starting our public beta in ~2weeks for the 27 release which would have the fix in place so I would recommend signing up for that!


@oldcomputerwiz Thanks for that, as that was what I did to solve this issue. I unplug my Hub before go to sleep , and plug back in the morning, things start to function. Also, searching through , I finally decide to move all Philips Hue back to hue bridge, rather directly to ST hub. and also change my wifi (2.4Ghz) channels, amd re set Arlo station to get its wifi channel change. So only time would tell. but at least I know how to solve in the future.

1 Like