Turns on and stays on for 20 mins

#1

What’s the Webcore equivalent of Hubitat’s basic rule “When switch turns on and stays on for (time)”

image
image.png983×679 51.9 KB

None of these seem to fit. “Changes to” doesn’t have timer options and the ones that have timer options don’t make sense.

image

#2

I think this would be several commands in WC
Turn switch on
wait 20 mins
Turn switch off

the “is now and stays” is similar, but would need the switch turning on first
Turn switch on
if switch is now and stays on for 20 mins
turn off

I’ve not used rules machine, but think WC offers more flexibility for complex automations, however for some cases it may be more complex.
I’d recommend reading up on task cancellation policy. e.g any wait command in a piston (by default) will be cancelled if the piston is triggered again. This can be useful for keeping a light on while a room is occupied, but in other cases may not be the behaviour you need.

#3

I have always used “is now and stays” for this without any issue, but I agree the phrasing is awkward at best. .

#4

The problem with “is now and stays” is that when something else triggers the piston (even the “Test” button in the user interface) it causes that to trigger.

For example “(light switch) is now and stays off for 20 mins”…. If something else wakes up the piston while the switch is off (another condition, timer, URL call, the test button or ANYTHING) then WebCoRE sees that the switch is off and immediately schedules a 20 min timer to double check the switch is still off then executes the rule.

“Is now and stays” does not require the switch to change. Only for it to be off when the piston executes.

#5

That’s true of all triggers in webCoRE and such possibilities must be accounted for in piston design in general. The more triggers or timers you allow, the more likely it is that your piston will behave in undesirable ways. You should post a green snapshot of your piston so that people here can give more meaningful assistance.

And just be clear, conditions don’t cause a piston to re-evaluate, unless the way the piston is structured results in the condition being treated as a trigger by webCoRE. The Test button, by the way, simulates a trigger, so what you’re seeing when you press that is exactly what is expected.