Creating a piston for SHM delay

#1

1) Give a description of the problem
I created a piston that connects real contact sensors to virtual contacts sensors. The virtual sensors are connected to SHM. This piston delays the opening of the virtual sensors so you can enter through the real door without the alarm going off for a few moments.

2) What is the expected behavior?
Real contact sensor opens, wait x seconds, open virtual sensor, wait x seconds, close virtual sensor.

3) What is happening/not happening?
Sometimes the sensors get stuck open, the closing part of the piston does not run.

**4) Post a Green Snapshot of the piston!

piston
piston.png1178×1148 113 KB

#2

It appears that after 30 seconds, the real contact is no longer open and has returned to closed, nulling the remainder of the piston sequence. There is a setting to null out cancellations. Or you can set a trigger for the real contacts returning to close and then manually close the virtual contacts.

Definitely interested as I am getting ready to port over my alarm system and I have the same dilemma. I use presence to disarm the house, but sometimes we get through the front door before that actually happens. A 10 second delay is all I need, but 30-60 seconds is pretty standard with other alarms.

#3

There is a smartapp that does this but I thought this would be an easy piston. I’ll try to find the setting to null out cancellation but should that really matter? The trigger is just the contact changing to open and not the state of the contact. I used to have the piston just open the virtual sensor and then close it when the physical sensor closed. That didn’t work because too often the door would closer before the piston completed.

#4

The only way to know for sure is to post your full log as per problem request statement 5. But yes, if the contact changes state within the wait period, it does matter and the piston will be aborted. I get what your stating about it now working with no wait, perhaps try a shorter wait period and dial it in. But I think the cancellation policy will solve this issue

#5

I agree. The pending tasks will get cancelled if the event which triggered them is no longer true after the Wait commands (meaning you opened the door and then subsequently closed it while the piston was waiting).

There’s no need to adjust the Wait’s you just need to never cancel the pending tasks.

So, click the “with” in each action and the hit the little cog icon and then change TCP (Task Cancellation Policy) to Never.

#6

I would have never thought that was the case! O changed the cancellation policy and will test it out tonight. Thank you both!