Confused about sensor updates

#11

Sorry, I sound like I am trying to tear your piston apart. Really, I am not :smile:.

I’m just not sure why your piston lags behind the sensor. Maybe the TRACE will help.

#12

If may have something to do with your STAYS LESS THAN / STAYS GREATER THAN statements. Those will cause your piston to schedule a wake-up time X minutes in the future.

#13

I have a few observations, if I may…

The piston state is only written at the time of execution.
(It does not keep a “live” account of changes)

That being said, if SmartThings sees 51%, then so does webCoRE.
(even if the Dashboard displays the old 49%)

Picture how a newspaper displays the stock prices. It is accurate at the time of printing, but things may have changed by the time you read it the next day.

I agree with @Pantheon. I would recommend starting with 5% difference (instead of 2%), and go from there. If the humidifier still toggles on/off too often, increase the space between the two numbers a bit more.

Pro Tip:

For a piston with multiple delays, it may also help to understand the value of Logs and Trace.

#14

One more observation…

Lines 31-35 are not inside a IF block… You may want this for some reason, just be aware that this means every single change to your humidity will also turn on the light.
(meaning “RGB Bulb 1” will be on at least 23½ hours a day)

#15

@kbhousen, I would heed everything that @WCmore says. He is my mentor and a master/professional webcore programmer.

#16

For what it’s worth, your problem solving skills were very good here @Pantheon.
I just elaborated a bit, and covered alternative angles.

#17

First, thanks for the suggestions!

Yes, exactly. What I’m trying to do is to get the newspaper delivered faster.

The problem isn’t that its cycling too fast. The humidifier runs for quite a long time, then shuts off for quite a long time (20-30 min). I initially had the min/max further apart, which didn’t help.

The problem appears to be the lag between the sensors current RH reading and the value that the piston “sees”. For example, the piston should shut the humidifier off when the RH exceeds 49%, but it continues to run for several minutes even though the RH continues to climb well beyond that, again over a period of several minutes.

I originally thought I should use some kind of time-based loop to check the RH, so that I could control how often the sensor is read. But most of the examples I’ve seen don’t employ loops. I’m still trying to figure out how webCoRE works…I’ll take a look at Logs and Trace.

Thanks again-

#18

20-30 min sounds perfect. In this case, I guess 2% is right for you.
(it must be a large room, a weak humidifier, or a stable environment)

I would love to see this in a Full log.

If this was my piston, I would probably code it like this:

IF Contact Sensor 1's humidity CHANGES  <-- Trigger
Then
    IF Humidity is below X              <-- Condition
        Then do stuff
    END IF
    IF Humidity is above Y              <-- Condition
        Then do something else
    END IF
    IF Humidity is between X & Y        <-- Condition
        Then do other tasks
    END IF
END IF

This is a single trigger piston, with everything else indented as conditions.

I would probably move your last two IF blocks into a separate piston…
(keeping the timers separate from the quick actions)

#19

Yes, 2% seems to be working more or less OK. And it’s probably good enough. The reason for my post was to understand how this works, how to optimize it, and to be sure I’m doing something that makes sense from a webCoRE perspective. The room itself isn’t that big, but I don’t keep the door to it shut (its my den). And there’s a heater/AC vent in there. So the humidifier is competing with the rest of the house, and fighting the gas furnace when its running.

OK, that makes sense. So the idea is to simplify the piston to act on one trigger, and then use multiple pistons as needed.

I’ll try recoding as suggested. If its still lagging I’ll dump a full log. As I’m typing this, the humidifier just shut off at RH=51% after running for 5 min with the RH above 49%. I’ll bet the use of “If sensor changes” will do the trick.

thanks

#20

Just to clarify… Not every device reports every single digit change during transition.

  • Humidity can easily “jump” from 49% to 51%…
    (you may see these details when you examine the full log)
  • Just like the temperature can quickly jump from 84° to 86°.
  • You would not believe at just how much lux or illumination can jump

Essentially, it is the device and device handler’s responsibility to report a change to the ST hub… At which point, webCoRE can take over, and do it’s magic.

#21

I am unfamiliar with “Wireless Tags”, but I have seen many device handlers that limit the frequency of updates. (IE: the device may only update it’s status to the hub no more than once every X seconds)

When this bottleneck is used, it’s usually added to reduce spam from the device.
(on quickly changing dataPoints)

Examining your logs will either confirm (or deny) whether your device handler does this.

  • If the humidity changes are spaced out somewhat evenly, then assume “yes”.
  • If the humidity changes appear to be somewhat random, then assume “no”.
#22

FYP, might have been just a typo but I believe WCmore was suggesting only one piston.

#23

To clarify…

I would likely keep all immediate commands (triggered by Contact Sensor 1’s humidity) in a single piston. I would probably move the two timed events (stays) into another piston.
(as seen here)

#24

Great point. I went into the iOS app for the Wireless Tag sensor and mucked around in the settings. I found a switch that is by default set to not send data until several points have been collected. The intent was to save battery life and keep traffic down. I turned that switch off. The sensor was set to update every minute. So I re-ran the same code as given above using this setting, turned on trace and full log and let it go for 2 or 3 hours.

Then I captured the RH data from the sensor and plotted it. I went though the piston log and noted the time, RH value, and action taken at every execution of the piston. A plot of the results is:

image
image.jpg1482×882 163 KB

It’s interesting. First, the blue curve is the data (floats) as reported directly by the sensor. The colored points are the RH values sent to the piston. They are integers, so don’t always lie on the blue curve because of rounding. The black dashed lines are the range of RH that the piston tries to maintain. The blue points are when the RH was above the max acceptable, so it turns off the humidifier. The green points are when the RH is in range, so the only action is to turn the LED bulb green. The yellow points are when the RH is too low, and the humidifier is turned on. There was one call where the RH was too high, but no action was needed because the humidifier was already off (the X data symbol). Then there were 3 “empty events” recorded in the log. The piston was executed but there was no RH value reported. Not sure what those are - but I plotted then at RH=43 just to show the time they occurred.

The interesting part is that the calls are always exactly a multiple of 5 minutes apart. And it looks like when the RH is changing fastest, the time between calls is 5 min. When changing slowly, the interval between calls is longer, but again always a multiple of 5 min. This makes me wonder if the ST integration device handler is doing this. The sensor reports values every minute. Makes me think this is about as good as I’m going to be able to do (which isn’t bad).

Next, I’ll try coding the piston up as suggested looking at “when humidity changes” as the trigger. Might shed some more light.

#25

In case anyone stumbles on this issue in the future, it turns out the ST SmartApp that handles the Wireless Tag sensors has a user-settable minimum time interval for updates. By default its set to 5 min, probably to keep the chatter down. Something to keep in mind if your piston that uses Wireless Tags doesn’t seem to be updating like you expected.

Thanks again to everyone for your help on this, especially WCmore and Pantheon.

#26

If you keep in mind the decimals rounding to integers, that graph above shows very accurate and timely toggles…

Personally, I don’t think I would try to push it any farther… Every five minutes sounds perfectly acceptable for something like humidity…

Most devices with that bottleneck in place, have implemented it for a reason.

YMMV

#27

Yup, I agree and think it will be fine. The RH swings a total of 5% now, which is probably good enough for my purposes (keeping musical instruments healthy). I was mainly interested in finding out how it all works. Turns out that switch had no effect on the frequency of piston executions.

#28

Well, for what it’s worth, I have encountered some real “chatty” devices in the past, that simply “talked” way too much! LOL

In a way, you are fortunate that your SmartHome is not getting “spammed” as frequently.
(from your graph, I assume it’s reporting in decimals, so it could be trying to update every few seconds… Ouch!)

It is a tradeoff, really, between precision and network chatter.

A key element to also keep in mind that a single ¢R@z√ trigger can make other (unrelated) automations fail. (which is why pistons that trigger based on power or illumination changes can be tricky to work with… They change nearly every second!)

Humidity and Temperature changes may be next on that spectrum… Perhaps followed by Motion Sensors… (still chatty, but not as frequent as power fluctuations.)

#29

The Wireless Tags are actually pretty smart about that. They let you sample at, say, once/minute (which I do). But those data points get stored locally on the sensor until it collects a “bundle” of them, then transmits to the server. So you can get nice time resolution w/o cluttering up the network. I’ve been impressed with them so far.

#30

While I do not like my data being “censored”, I do not mind a “summary” for data that changes frequently… We would not want a piston to be executed every 3 seconds… All day… Every day…

Real Life Example:

Can you imagine the frustration if you told your broker to call you whenever there was any change (at all) to your favorite stock price?!? Creating “thresholds” is a great way to reduce the alerts.