Since adding devices back after the mass delete, I am beginning to have Z-Wave device issues (Not all but some) going offline or not reporting status updates correctly. I’ve performed the standard troubleshooting steps with support below:
Support has “escalated” to next level support but things are going down the drain quickly… This is not an app issue it is something else…
More info:
Use browser api to check and screen capture the details screen for each you list above.
One more question to add to @jkp’s excellent list: what’s the Z wave security level of the devices that are going off-line and of the repeaters they are likely using?
I ask because we have had a couple of community members recently who ran into problems because at the time they first built their network S2 security was not fully supported on smartthings, but now it is, and when they had to remove and re-add a device It got a different security level than it had previously.
That’s probably not what’s going on, but it would be good to be able to rule it out. 
I had to re-add all my devices so these are ones that have been added back using Edge drivers. They are the following
Schlage Lock
Inovelli Switch
GE Light Switch
GE Fan Switch
Ecolink Motion Sensors
Monoprice Motion Sensots
Ecolink plug in module
GE Plug in Module
Zooz Zen20 V3
These devices all worked perfectly before the recent mass delete. They are not coming back online after being offline (Smartthings wanted me to exclude/include again). Here are a few of the API+ device details.
Some of the device came back online but not all. Tried to read some of them and they add but then stop being able to communicate…
I’m having offline problems with one S2 Zwave device and kinda at wits end trying to figure out why. It’s a GE Jasco Zwave Plus 46204 smart toggle scene controller switch using @philh30 Edge driver. I have several in my house but since the past 3 weeks this one keeps getting reported as offline in ST after some 45 minutes from when I last use the device (i.e., in the App even tho its listed as offline, I can still control it, and if I manually turn on the switch at the device, the app sees it as online for around 45 minutes).
Since it is ZWave plus, I am assuming that only another plus device would be in its mesh/repeat for it. I have been turning off breakers/unplugging devices to see if anything changes, but nothing does.
How does Zwave offline algorithm work? I thought powered devices are sending a hearbeat? What is odd to me is that if ST is able to get the status update when I turn on the light, why isn’t it getting the heartbeat, too? Seems like it would not be a repeater issue, but something else…
It’s all one mesh. Non-Plus devices can repeat for Plus devices and vice versa. Plus devices have a larger range so are more likely to be able to home run to your hub, but may still repeat through another device (including non-Plus) if necessary.
Thanks, that was never clear to me if it was a transmit power or frequency. I guess it’s power. Have you ever seen the symptoms I describe, where ST flags a device offline, yet you can still control it, or if you make a change at the device it reflects in ST (and then ST flags it as online).
If it were the mesh, then nothing would get through, right? Also, if I pull down in the device UI sheet on the app, doesn’t this refresh action cause the hub should reach out to the device for an update? Could the device simply be bad? I know I did a factory reset before joining it.
The other thing i noticed about these new GE scene control devices, the Air Gap switch (the piece of plastic that you pull out to disable load output) seems to leave the Zwave logic/radio in the switch online and just cuts out the load. To me this is unusual and a downside to these switches, as you can’t hard boot them using the air gap, but you have to flip the breaker. Do you see this behavior as well? Could it be because the line/load lugs are not specifically defined? It makes no sense.
“Offline” has nothing to do with the actual Z wave protocol. It’s not part of the independent third-party specifications. It’s something that smartthings made up for its own use, and it’s based on whether a device has been reported into the cloud in a set period of time that smartthings engineers think is relevant.
The device is almost never off-line in the sense of being off power.
It may sometimes be “unreachable“ (a technically much more accurate term, and the one most other platforms use), but maybe not.
Just as an example, if you unplug your hub from the Internet, everything on your Z wave mesh is still operating fine, and communicating with each other, and with the hub, but because the hub is not talking to the cloud, eventually all the devices will get marked “off-line.” Which they are not.
So to my mind as an engineer, it is both a useless and misleading identifier. But it’s not my call.
The one thing I can tell you is, don’t try to use it as an indicator of anything that’s happening with the zwave mesh. That’s not what it corresponds to. It corresponds to the hub’s communications to the cloud about that device.
A much more meaningful statistic, and one that we used to have under the IDE but I think we don’t have any more, was the number of failed message transmissions from the hub to the device. That has meaningful diagnostic content.
Not really those symptoms, though most of my devices are off ST at this point. I don’t remember ever seeing a post in the community describing what exactly goes into determining when a z-wave device is considered offline these days. In practice what I’ve seen for mains powered devices is if they fail to respond to commands. With your switch it could be something in the background, like messages being dropped when it’s being used as a repeater or it failing to respond to S2 nonce messages. You might be able to troubleshoot and figure out the cause with a zniffer and a whole lot of patience, but I’m betting the eventual solution would be to exclude/include the offending switch. I didn’t see in your post any mention of trying that so that’s my suggestion (taking whatever action is currently necessary to preserve your automations first).
If you have other nodes that truly are offline (unpowered) and will be that way long term, it might also help to remove them from your mesh (particularly if they’re repeaters). It could be that those are somehow messing with this switch.
Another thing you could look at is my Z-Wave Explorer driver, which is available in the same channel as Masquerade. It will show the transmitted/received/failed statistics for that node as well as what ST has stored as the route (which is questionably meaningful). Again, take precautions before swapping drivers if ST is still deleting automations when device capabilities change.
I would note that many people have from time to time reported hue devices attached to a hue bridge being marked “offline” in the smartthings app, while being fully functional in both the Hue app and with one of the voice assistants. I know that’s a different protocol and a different integration structure then a Z wave device, but I think it does demonstrate that “off-line” is not a description of what’s happening at the protocol level. FWIW…
Actually, Phil, this got me thinking. As I mentioned, air-gap’ing the switch doesn’t seem to kill the Zwave electronics, so I threw the breaker. After that, the switch has stayed online for the past handful of hours.
That’s hard to read! Your contributions have been great, don’t want to lose you! Especially since I’m using so much of your labor (of love?) in my house. The experience with scene control would not be the same with the lame ST drivers that treat everything as nothing special at all.
Well, since I have this useless Zooz S2 700 stick that won’t bind to my ST hub with the right driver (since I missed the boat by a few weeks on the DTH needed to add it as a secondary and Zooz seems to have no Edge driver that connects with S2), I’ll get Zniffing next time this happens. Looks like it has route information that may also provide some clues as to what’s going on.
I’m guessing that somehow the Zwave guts of the switch just stopped responding to any kind of “ping” from the hub, or keepalives/heartbeats were not being sent. Thanks as always for the detailed and helpful backgrounder on offline @JDRoberts
