Disconnected Device - impact on Piston

bug
#1

I have a lot of issues with Zigbee and Z-Wave devices dropping off of ST. At the moment, not specifically looking to solve that. However the biggest problem is the ripple effect on downstream pistons. For example, I have a Good Night piston that calls a bunch of lights and turns them off. If one of those lights drop offline, the piston simply fails to execute that step, IE no lights turn off.

Example of an offline device in piston:

image
image.png1004×93 5.18 KB

Clearly my FR Rear Fan has disconnected.

In this state this entire ‘DO’ (off) command is skipped.

A) this is normal, expected behavior
B) Feature request: can webcore be changed to simply skip that dropped device and behave otherwise normally? IE, still turning off the rest of the items.

#2

A) Yes
You are told right on your screen when you remove a device from ST that you are supposed to remove it from any SmartApps first.
B) That’s been asked at least a dozen times since i’ve been using ST. There’s no way for webCore to know that it’s dropped. It shows up that way in the GUI but that’s always the way the device looks to the code of WebCore. It just loses it’s display name when you remove it. Since this has been an issue forever I’m guessing it’s a lot harder to fix than you’re assuming.

#3

Well, an answer. Not the answer I wanted - but an answer. Thanks.

…Now to figure out why things drop from ST on their own (I did not remove the switch). :slight_smile:

#4

I am just thinking outside the box here, but I wonder what would happen if that device was in it’s own block… I am unable to test this, but I wonder if it would only skip the one block, and continue to process the other commands to the other devices when you have a drop…

#5

It totally unpaired itself? Or did you remove it from supported devices for webCoRE?
Because even if a device disconnects it will still show up in webCoRE.

#6

Everything below that block doesn’t work. It only saves the piston if it’s the last statement.

I’m migrating to Hubitat so it’s been happening to me A LOT. LOL

#7

Aww phewey… I don’t have any devices dropping, but it sounded logical in my head, LOL

#8

I have zigbee and zwave devices that ‘100% on their own, with zero interaction from me’ drop off ALL THE TIME. :frowning:

I did nothing to this device. It is just gone, unpaired as you say.

#9

When you think about it, it is logical. It works up to the point that it can’t figure it out and then drops the piston. The alternative would be to get stuck in a loop and lock the ST servers. Which isn’t good for anybody!

#10

I would call support. Disconnecting happens. Unpairing and removing should not happen at all.

It’s not the device dropping off your network…it’s smrartthings deleting them that causes devices to show up this way. The device disconnecting would not cause ST to delete it from your hub. You’re talking two different things.

#11

As I noted, I figured out that it was a device for a fan. Specifically “FR Rear Fan”. A screen shot of that room, after disconnect.

The devices were alphabetical, though I put the light over the fan. It was Front Light, Front Fan, Rear Light, Rear Fan. FWIW, the “2” you see on there on various devices, is a renaming I was using as I have re-connected devices over time. In that 1 screen shot, there are several.

image
image.jpg281×529 26.9 KB

The Fans are the GE Fan switches. The light switches are HS-WD100+

Thanks for the review/discussion. Gives me things to think about.

FYI, I am also moving to hubitat…but the HS-WD100+ are giving me a hard time. They are not managed correctly by any driver I can find. Sigh.

#12

I don’t know if this will work for you or not. I don’t see devices unpairing for me unless I actually delete a device and then need to update my pistons accordingly. With that being said. This ‘might’ help?

image
8444BFA6-3B47-4607-AF04-DF01BD750A63.jpeg2212×1274 494 KB
image
B88091F1-6F80-4849-875D-A7E0ED580EBF.jpeg2493×1223 716 KB

I posted both a green snapshot so that you could import it, and an example of a test run. It did turn off the lights that were online.

#13

Beautiful strategy @Gopack2 !

I agree the general focus should be on WHY it is dropping and how to resolve…
(I often draw the floor plan from an aerial view, and make a red dot next to each Zigbee device, and a blue dot next to each Z-wave device. This lets me easily see where I can add one or two more devices to cover any holes in the respective mesh network)

#14

I wonder if the temp from your original post is an old reference to a device that you have now recreated and renamed…

#15

Unfortunately, no. It was a live and working device earlier this week. This piston is a daily use piston (going to bed). Too busy to get into it this week, until today - but I noticed sometime this past week that the piston was failing.

Thanks for the pistons @Gopack2. I will give them a try later. However, to be honest, if they developed a temp entry - feels like they would fail too. But, harmless to try! Cheers.

#16

PS: I am also dropping all my zigbee devices and switching to z-wave to see if I can solidify one network. Most are battery devices (contact), so useless from a mesh network point of view, but some are plug in devices/repeaters. As they change to z-wave, hopefully the switches will stay connected better.

#17

Yes, sorry, I should have clarified. Only AC powered devices act as repeaters. I draw ‘squares’ to represent powered devices and ‘circles’ to represent the battery devices. Sometimes a hole in the mesh can be solved by simply adding a new lightbulb. (as long as that bulb has power 24/7)