Piston not continuously checking state

#1

1) Give a description of the problem
I have a piston defined to tell when the front or back door is open for at least 5 minutes then turn off the air conditioning. It looks like the piston subscribed to the initial door sensor open event but then does not continuously check to see if it is open 5 minutes from that point.

2) What is the expected behaviour?
I would expect the piston to run every minute or so to see if the door sensor is still open and run the piston.

3) What is happening/not happening?
The piston never runs again and never gets triggered.

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

image
image.png1178×864 41.8 KB

5) Attach logs after turning logging level to Full
8/30/2020, 12:11:16 PM +316ms
+4ms ╔Received event [Front door sensor].contact = open with a delay of 58ms, canQueue: true, calledMyself: false
+106ms ║RunTime initialize > 104 LockT > 2ms > rtDT > 80ms > pistonT > 78ms (first state access 22 6 98)
+112ms ║Runtime (7951 bytes) successfully initialized in 80ms (v0.3.110.20200716_HE)
+114ms ║╔Execution stage started
+168ms ║║Comparison (enum) open was (string) open = false (44ms)
+170ms ║║Condition #2 evaluated false (51ms)
+218ms ║║Comparison (enum) closed was (string) open = false (43ms)
+220ms ║║Condition #9 evaluated false (48ms)
+222ms ║║Condition group #1 evaluated false (state did not change) (103ms)
+228ms ║║Comparison (enum) open changes_to (string) closed = false (0ms)
+230ms ║║Condition #6 evaluated false (5ms)
+234ms ║║Condition #10 evaluated false (4ms)
+236ms ║║Condition group #5 evaluated false (state did not change) (12ms)
+240ms ║╚Execution stage complete. (126ms)
+244ms ╚Event processed successfully (242ms)
8/30/2020, 12:10:19 PM +865ms
+29ms ╔Subscribing to devices…
+151ms ║Device missing from piston. Loading all from parent (120ms)
+160ms ║Using Attribute subscription
+162ms ║Using Attribute subscription
+167ms ║Subscribing to Front door sensor.contact…
+173ms ║Subscribing to Rear door sensor.contact…
+178ms ║Piston controls EcobeeTherm: My ecobee…
+179ms ║Piston controls My ecobee…
+194ms ╚Finished subscribing (168ms)
+255ms ║Comparison (enum) closed was (string) open = false (43ms)
+303ms ║Comparison (enum) closed was (string) open = false (41ms)
+364ms ║Comparison (boolean) false is (boolean) true = false (1ms)
+374ms ╔Starting piston… (v0.3.110.20200716_HE)
+375ms ╚Piston successfully started (350ms)

#2

Your door open events are not triggers (lightning bolt). Only your close events are triggers. So, when you open the door, the piston will run to check all the conditions but then won’t run again until the door closes again (or the other door opens). I think you want ‘remains open’ to make the open a trigger. Then it will set a timer and look if the door is still open in 5 minutes.

#3

Thank you. That does appear to work.

#4

That isn’t how pistons work, I’m afraid. Indeed that isn’t how SmartThings works. It is all about events.

Your piston has two explicit triggers that tells the piston to subscribe to change events for the contact sensor attributes. It will run whenever one is received, regardless of what the ‘new’ value of the attribute actually is.

The issue with your piston is the way the ‘was’ condition works. It is a retrospective thing. Consider if Front Door sensor contact was open for at least 5 minutes. What that actually does is either:

  • If the piston is running because the Rear Door sensor changed, it looks to see if the Front Door is open at the moment and has been for more than five minutes.
  • If the piston is running because the Front Door sensor changed, it looks to see if the Front Door was open prior to the latest change and had been for more than five minutes.

So it is ‘was’ as in looking backwards from the current time to what the situation was before the piston was just fired.

You need to be waiting for the door to be open and then seeing if it stays open for five minutes from then.