I’m sure that’s very frustrating. There are some things you can do right now if you want to. I realize you may just want to wait for support.
One) go to the iDE, choose hubs, and look at the description of the zwave radio.
Obviously, your region should be different, but otherwise the values should be the same as this:
If “Z wave radio” detected, enabled, or functional are not “true” you have a problem that only support can help you solve.
If zwave SUCID is not “01” you need new zwave firmware.
So there’s not much you can do about any of that, but if you do see those issues, at least you’ll know there’s nothing you can do until support gets involved so you might at least save some time and aggravation.
- if everything from the above looks OK, if you have a minimote, or any other Z wave controller besides the SmartThings hub, you can use that to exclude individual devices. Duncan’s usual advice is to start with the Device most recently added, but since you had to stop the zwave repair in the middle of running, unfortunately, any device may have a corrupted address table. So it’s a little difficult to know where to start, but at least you could go ahead and exclude anything that you know has a problem. Since you’re likely to have to do that in the future anyway.
Three) I realize the odds of you having the necessary device for this third step are small or you would’ve done this already, but I did just want to mention it. If you have or can borrow an Aeon USB zwave controller stick and the values in step one above were OK, you could add the stick to the SmartThings hub as a secondary controller, and then use the stick’s utilities to map your zwave network. At least that way you could identify both ghost devices and individual devices with corrupted tables and start excluding them. This method is less work than four) below, but it’s also less precise.
This is one of the situations with the fact that SmartThings does not support controller replication can actually be helpful, because the less data is passed over from one controller to the other, the less likely it is that corrupted data will be passed.
- Another alternative here is to exclude every zwave device from SmartThings, add it to the stick as a primary controller, and run a zwave repair from the stick. I realize that’s a huge amount of work. You could add just two devices at a time and work as you go. Always let the zwave repair run until it’s finished, another good reason for only adding a few devices at a time. You can even add two devices, run the repair, and then exclude those two devices again. That will keep each future repair very short. The point is just that you will have much better diagnostic tools to identify any individual bad device.
conclusion
I would definitely do one) above. It’s just looking at your account on the web. And it could give you a lot of information if you do have a bad radio.
-
could be worth doing if you have added any new Z wave devices in the last week or so. Just exclude the new ones and see if that helps.
-
and 4) are both a lot of work, very technical, and still might not solve the problem. But you might get a lot of information that you won’t get any other way. So it’s really a mafter of how much of your own troubleshooting you want to do. The problem is that unless you can identify an individual bad device, they still isn’t going to be any solution that won’t require help from SmartThings support.
I wish I had an easy answer, but unfortunately I don’t think there is one.
