Dealing With Slow Responding Devices

#1

I have been trying to solve a problem with some devices being slow to respond to commands. This is an inconsistent issue in that sometimes a device, (say a Nest thermostat) will respond instantly, and other times it can take several seconds before the temperature at the thermostat is updated.

To deal with this problem I have been experimenting with in-line time delays and repeating a command, While loops. and Repeat loops. The Repeat loop appears to be the most promising, but I am not 100% convinced it is really doing what I think it is.

When a Repeat loop is run, the commands will be repeated until all of the conditions in the loop are satisfied. But are these conditions truly the state of the device? Or are they just responding to SmartThings saying “Got your command - thanks.”?

#2

Is this this a fairly new problem that has started in the last few days?

Take a look

#3

No. This has been an ongoing issue for many months. Not related to current issues.

#4

I am biting my tongue on this one…

#5

Please explain! I’m seeing all kinds of weird slow/not responding issues…so far as I started thinking it was my zwave network and trying to diagnose zwave. I’m starting to think absolutely not based on other action that aren’t zwave based. Is this a webcore or Smartthings platform problem?

#6

Just to clarify. I am not looking for a diagnosis for the slow response issue. Instead, I am trying to come up with some programming techniques to deal with it if and when it does happen.

To that end, I would like to better understand how the actual state of devices is communicated back to WebCore. E.g., is the device state reported to the Repeat command really the current device status?

#7

Well, for what it is worth, sending repeated commands in a loop often makes the hub less responsive.

For a real world example:
Visualize a waiting room with 100 people. Can you guess what will happen if someone asks the clerk every 5 seconds to check the computer and see if their number is up yet? It will slow down the entire waiting line, and everyone will have to wait longer…

My advice? Drop the looping, and be happy with waiting a few seconds for the Nest to update. It is still going to be faster than you getting up and walking over to it.

It might also be wise to check all your other pistons for run-away loops as well as making sure each motion sensor is only a trigger in one piston. That can have a huge impact on reliability.

#8

Thank you for the suggestions. You are correct. I did not consider that a fast repeating loop could overwhelm the hub.

But to further drill down into the issue that I am really trying to solve, it is not only that the device might take some period of time to update, but that in some cases it never does get updated for one reason or another.

What I am trying to do is to determine, with some degree of certainty, that the device,1.) Got the command. 2.) Implemented the command. And 3.) Lets my WebCoRE piston know that the command was received and correctly acted on.

So is there any reliable way to “close the loop”?

#9

For what it is worth, in all the thousands of pistons I have worked on, it has always been at least one of these reasons:

  1. Battery is getting low in the device
  2. Using an old outdated Device Handler
  3. Holes in a Mesh network / device too far away
  4. Poorly coded pistons
  5. Too many things happening at once

The only exception to the above is when I run BitTorrent, my entire network gets bogged down, since that is pulling TONS of data from all across the web. But that is my own fault, so I can not place the blame on my SmartHome.

Side note:
Once in a blue moon, SmartThings may have a hiccup, but it affects nearly everything, and usually “fixes itself”, so I am not counting those times…

#10

I am pretty sure that the problem is not the first three items on your list.

However, I have no doubt that the last two are prime suspects as 1.) I am a just a pretend programmer. 2.) I most certainly do have to many things happening at once. Which is something I am going to address.

But beyond that, surely there is some way for a WebCoRE piston to know with a reasonable amount of certainty that a command that it sent to some device was actually implemented by the device. No?

#11

It is usually the last two items from the list… (which often go hand-in-hand)

I think I will let others chime in to answer this one.
(I have a hard time forcing myself to use bandaids to “resolve” a deeper issue)

#12

Pause one piston at a time and see if you can isolate which piston is causing the problem? I understand it’s not a consistent problem which means this approach might take some time.