Question about "Only when" piston restrictions

#1

1) Give a description of the problem
My piston has a restriction to only fire when location mode=DAY. The piston triggers when a motion sensor is now and stays inactive for 30 minutes. If location mode changes away from DAY during that 30 minutes of inactivity the piston still fires. It doesn’t seem to re-evaluate the restriction at the time of execution.

2) What is the expected behaviour?
I would expect the restriction to be enforced and the piston should not fire.

3) What is happening/not happening?
The piston fires even though the restricted condition should block it.

4) Post a Green Snapshot of the pistonimage

image
image.png1178×712 34.7 KB

5) Attach logs after turning logging level to Full
Sorry, no logs in this instance.

#2

Try putting it in the Execute statement.

#3

@eibyer, I could add the condition to my IF in the execute section of this sample piston. My real piston is more complex so I was hoping not to need the additional condition on each section. Thanks for your prompt reply.

#4

I think you may be getting caught out by the way timed triggers (stays) work.

The piston will fire everytime there is a motion sensor event but should only execute the code when the restriction is valid.

When the motion sensor changes to inactive the piston code will execute if the location mode is Day, and if the switch is on the stays condition is evaluated.

The condition will look to see if the motion is inactive and it is because that is why the piston is executing. It will set a timer for 30 minutes time (i.e. it schedules a piston execution) and it will then return false (stays always returns false when evaluated).

In order for that timer to be ‘cancelled’ the piston must be executed again and the stays evaluated when motion is active. If the piston doesn’t reach the stays because of the restriction or because the switch is off, that timer is going to stay running.

(Strictly speaking timers don’t get cancelled as such. They run as scheduled but the piston just exits. It is convenient to think of them as being cancelled though.)

If the running timer fires the piston will execute, fast forward to the stays statement, and then return true and the rest of the piston will execute.

#5

@orangebucket, thanks for the thorough explanation. It sounds like they function similar to the wait statements I used when I started w/WC on ST a couple years back. I hadn’t noticed those stays triggers and only discovered them when I added WC to my Hubitat platform recently. I find them to be more elegant and it feels like they cut 5-10% of the logic I used to add myself.

Thanks again for the response. I’ll add the condition elsewhere to suit my situation.

#6

Yes, the mechanism is really like having a wait at the start of the then block with the default Task Cancellation Policy in place.

I think what can surprise users is that it also returns false and continues on with the piston rather than waiting to see if the condition is fulfilled.

#7

To help me further understand, can these timers be cancelled?

So in my example could I add a trigger and cancel pending tasks if location mode changes away from Day?

Side question: How do you add the markup and highlighting in your posts? It greatly improves readability.

Thanks as always.

#8

What I was really trying to do was to warn you that you read the logs you will often see pistons starting up on a timer event and then not doing anything. The task the timer was meant to trigger has been cancelled, but the actual timer event may still happen.

Something you have to bear in mind with the ‘triggers’ in webCoRE is that by using them you are explicitly telling webCoRE you want to run when certain things happen and if those things happen those triggers really need to be evaluated. For example ‘switch changes to on’ needs to be evaluated every time the switch changes or it may not recognise the change. WebCoRE works with the events as received and seen by the piston.

This makes only when a bit of a nuisance and in my opinion webCoRE would be better off without it. I also think if you have to even consider explicitly cancelling timers you are fighting webCoRE.

The highlighting mostly comes from an icon menu at the top of the edit box. If it isn’t there I can’t recall how you get it. it just adds formatting characters and I know most of them anyway.