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”.
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)
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:
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.
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.
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.
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.)
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.
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.
