Confused about sensor updates

#1

1) Give a description of the problem
I’m writing a piston to regulate the humidity in a room. I’m using Wireless Tags as the relative humidity sensors and a Samsung smart outlet to switch on the room humidifier. When the sensor reports a RH outside a specified range it turns the humidifier on or off as needed. The piston also sets the color of a smart bulb to give a visual indication of the RH (too dry=yellowish, good=green and too wet=blue). If the RH stays too low or too high for more than 30 min, it sends me a text and has my echo dot speak the message. It more or less works but the problem I’m having is the piston seems to lag quite a ways behind the sensor. For example, the piston state says it thinks the RH is 49% when the sensor is currently showing 51% (viewed through my smartphone app for the sensor). I’d appreciate any help on how to code this to make it more responsive. Would something like an If RH has changed statement help?

2) What is the expected behaviour?
I’d like the piston will stay up to date better

3) What is happening/not happening?
I don’t understand enough about what causes a trigger to be sure if I have my piston written correctly to do what I want.

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png1178×1690 202 KB

#2

Do you have a trigger in this piston? I do not see an orange lightning bolt in the left margin.

multi-trigger

#3

Yeah, there are lightning bolts at the line immediately following each of the 5 main IF blocks on my screen. When I take the snapshot, none of that shows up in the capture.

BTW, when I exit the editor, under the Quick Facts heading it says I have subscriptions to 1 event. Not sure what that means.

#4

I don’t understand that at all. Those are not trigger points in the piston you posted.

#5

Yeah, sorry I just noticed that the line numbers differ between the snapshot and when I’m looking in the editor. I just edited my reply to say the bolts are on the line immediately under each main IF block. So, there’s a bolt in the 5 lines that say If Contact Sensor…

#6

Why are you forcing subscriptions at your IF statements? (the purple plus sign at the end). Do those IF statements subscribe on their own?

#7

Wasn’t sure if it was necessary. But I read a post earlier about someone having a similar problem and that was suggested. Does it hurt to force the subscription? Keep in mind, I’m not even sure what a subscription is in this case :slightly_smiling_face:

#8

A few things:

  1. We have a tornado watch in my area and my lights are flickering. So I may lose power.
  2. If you have not, I would suggest reading Conditions and Triggers. A subscribed event is a Trigger or Condition that will cause your piston to run top to bottom. If you have five lightning bolts, then those five events can EACH trigger your piston to run top to bottom EACH TIME they trigger. Generally, I like to have a single trigger to initiate the piston and then use conditions (ex. IF-Then statements) to control other aspects of my anticipated actions.
  3. Not sure about yours, but my relative humidity sensors can change 1-2 percent fairly quickly. If yours are the same, then you piston has the potential to cycle your Outlet 1 often. Just food for thought.
#9

I am a fan of task-specific pistons. Generally I like to have one trigger that accomplishes a single task. Others may disagree, but you might try separating your piston into two pistons. Such as:

Piston #1:
IF Humidity drops below X% (Trigger)
Then
Do Stuff

Piston #2;
IF Humidity rises above X% (Trigger)
Then
Do Stuff

I find it MUCH easier to debug task-specific pistons. Then once I have things working like I want, it is much easier to pull everything into a single piston. That’s just how I like to do things. :slight_smile: Your mileage may vary.

Also, if you could include a TRACE of your piston along with the logs, it makes debugging easier.

#10

Oh yikes. Hope you’re safe! Appreciate you chiming in given the situation.

I’ll re-read the Conditions and Terms FAQ. But from what you describe, it sounds like the piston should be running fairly frequently. When I look under the Quick Facts section, it often says the last execution was 20-30 min ago, which is why I thought the piston was lagging so far behind the sensors. The RH hasn’t been changing real fast in my room. The outlet doesn’t cycle wildly - the humidifier runs for say 15 min then shuts off for 15 or 20. Rinse and repeat.

#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.