Same thing here. “Repair Z-Wave” seems like snake oil. Doesn’t even show up in the IDE logs as completing.
I think you can do the same via the app, but more info in the IDE…
https://graph-na02-useast1.api.smartthings.com/
If you go into the IDE below…My Hubs --> View Utilities --> Repair Z-Wave Network, it will say “Z-Wave network repair initiated - Click to view progress”
You click for progress and for me at least, I never see the repair complete. Below is what shows in the IDE…
many users will not be on the same shard as you. always best to point folks to:
https://account.smartthings.com
Thanks. Good to know.
Is the eventual IDE endpoint (i.e. the address I originally posted) simply a load balanced address (i.e. can change for same hub), or does each hub get assigned an specific static DB instance (i.e. shard) at signup? Seeking to understand. Thanks.
Did you ever figure out the issue? I bought 6 GE Z-wave Plus Paddle switches and dimmers and am having the exact same issue. I can connect to them after a very long time, but can’t control them.
It’s not about depleting the batteries. This is a specific zigbee network trigger. If you take the hub completely off power, including removing its batteries if any, and leave it off power for at least 15 minutes while all of your other zigbee devices remain on power, Then your other devices will go into “panic mode” because they can’t reach the hub. Then when the hub comes back online, the other zigbee devices will do what is called a “network heal” Which causes each individual device to reassess who it’s best neighbor is for repeating its own messages and rebuild its local address tables. This process can take a little while, so you may not see improvements until the next day, but sometimes it’s the only way to get your zigbee network operating efficiently again.
Cutting power to the hub for 15 minutes will also cause it to re-sync with the cloud account when it comes back online, which can also improve some latency issues.
None of that is specific to Z wave devices however. We accomplish the same thing for zwave by running the “zwave repair” utility. And again you may not see the full improvements until the next day.
So in this particular case, I’m not sure power off will help at all, but it’s one of those “can’t hurt might help” kind of troubleshooting steps. 
Multiple people have reported multiple kinds of errors in this thread, but I did just want to mention that the single most common reason why A switch might work from the wall but not respond to the app is that it’s out of range of the hub.
If it’s a zwave switch, Then the zwave repair may either help or at least show you where messages are failing to get through.
If the utility itself is failing, I would definitely get in touch with support, as there are also things that they can see from their side.
You can also try reading post 11 in the following FAQ, and then go up and reading the thread from the top:
I haven’t figured it out. I have the hub three feet from the switches and can’t figure it out. I contacted support and they suggested moving it close to the switches and away from the router, which I’ve already done.
Thanks for trying to help here. Tried all that and all switches are within 5 feet of each other and all is within feet from the hub - the end result is each switch does whatever it likes, at random. I don’t think this is the usual CTRL-ALT-DEL fix. Something is clearly jacked up on the ST Platform and these problems became more apparent after the last FW update. I had ZERO issues before recent changes (FW Update?) made by SmartThings. 40 devices not skipping a beat. Something changed on the ST end
Here is more irony…… SmartThings app says my switch is off, yet I’m staring at the switch, fully energized and powered ON. This morning the ST app said the switch was off, so I togged it ON via the app, the app said it was ON. I verify it was ON. I close the app, reopen to verify, the app now says its OFF again, yet it is still physically on and energized. At best, status is out of sync (says off when it’s really on) in the IDE as well as in the ST iOS/Android App.
The bonus round… You’d think logs or key events (i.e. device is on) would be the same between an app which is simply pulling the logs from the cloud and what the IDE logs (THE CLOUD) says - NOPE… Total disparity of events, and we’re not talking the useless stuff, but key events like “on command was sent to [Insert Device Here]” I check the logs between IDE and ST App, neither match. Key triggered events show in one (i.e. Switch is ON), but not in the other.
EXAMPLE:
–Why would only 1 out of 4 on/off triggers match between log display sources?
–To me, this points toward cloud/synchronization issues on the ST end
–Other ideas, theories are welcome
Right now it’s pretty much impossible to troubleshoot anything because they’re having major platform problems.
So until that settles down there’s no way to know what’s going on. 
Thanks for the link. Good to know I’m not alone here. I’ve engaged support and I’m sending them examples. Below is a quick summary of my issue for others to compare against as they contextually see fit.
SUMMARY OF MY (and others i’m sure) ISSUE (THUS FAR):
• Log display in ST iOS App does not match or correspond to IDE Log (same source, different output)
• Log entries are present for actions (on/off) that I DID NOT TRIGGER (or any known app would have triggered)
• Log entries are missing for actions that either I performed, or did not perform
• Physical device status is ON, yet ST App visually indicates the device is OFF
• Last entry in IDE log (which does not show in ST App log), shows the device is ON, which is correct and matches the physical state of the device HOWEVER, IDE device status shows as “OFF”
• Actions are being ignored, missed, or delayed at random (20 second delay to complete ignoring of actions)
Preaching to the choir…
What kills me is companies never learn. I’ll bet someone rushed code out, untested, before code-lock (my presumption), given that’s how big companies roll (i.e. gotta hit the date at all costs - sink or swim!) and the consequence is crap like this where all of us, and I’m sure the non-decision makers within SmartThings are spinning their wheels running around in a circles not knowing what is going wrong.
The concept of “measure twice, cut once” seems to escape the startup and corporate worlds nowadays. It’s all about hitting some stupid arbitrary date, irrespective of consequence, rather than actually ensuring a product is properly tested and working. “Edge Case”, and “One-Off” comments I’m sure consume internal discussions only to have a big fat “I told you so” from the one or so person that pushed back…
In retrospect, this all reminds of NEST a few years back before Google bought them. Gen 1 thermostat owner. Someone rushed out FW update before holiday code lock (Nov Time-frame) and ALL hell broke loose - homes went offline, pipes froze at certain properties - with pitchforks in hand, people were pissed. All kinds of drama - all thanks likely to devs and business owners being pushed to hit stupid dates which drove a rushed FW release. While I didn’t own Nest Protect, I’m sure similar behaviors such as those above drove the recall of the product. Not good when your smoke detector fails to notify you when your home is on fire… Which again, I’ll blame of rushed time-frames because every company wants to be FIRST rather the RIGHT - which is entirely the wrong approach.
Sorry, I know I preaching to the choir here, but this is beyond frustrating for all of us.
