Alert when door sensor is tripped, then wait 2 minutes before alerting again


#42

Does it? That’s rather annoying as I rather hoped that the WAIT would be keep getting overwritten by a new one when the door opened because of the Task Scheduling Policy. One more thing for me to learn more about.


#43

Wasn’t used to be different???


#44

I’ll try that, it really makes it cleaner and makes more sense.

I was over thinking it with the “the door is open” for the first section and “the door was left open” for the second part. Open is Open. If it keeps alerting after 2 minutes chances are someone left it open!

Thanks,


#45

Not that I am aware of. WebCoRE has always been event driven. If a piston subscribes to a device, then all changes from that device will trigger the piston from the top.


I believe the recent discovery you are thinking of, was a few occasions where TCP can stay at default with a WAIT. Such as:

IF DeviceA changes to X
Then 
    Wait 5 minutes
    Do Something
END IF

In the past, I would use TCP = Never on this… but… the new discovery was that
IF the device does not change during the WAIT,
then TCP can be default, and the final commands will still work.

In other words, not very practical on chatty devices like motion sensors, and most doors.
(but it works great on rarely flipped devices, including SimSwitches)


#46

ok ok makes more sense now.


#47

Can you provide me with an example script I can import?


#48

I haven’t tested it and am working on a mobile device so unable to post a snapshot but try ‘sk5s’.


#49

Strange, yours was exactly what I came up with. In my case it didn’t run at all. Your copy ran once. I opened the contact, left it open for a few cycles, it notified every 2 minutes as expected. I closed the contact and re-opened it and it wouldn’t work again.

Dave


#50

I might be able to help real quick. Just to make sure we are on the same page can you post a green snapshot of sk5s you are using? When I imported it the thing that stood out to me was the first trigger was actually a condition.

Otherwise this is along the lines of what I have at home.


#51

Here’s what I have…


#52

In your akxj3 example the line 22 trigger is actually a condition. Change that to a trigger such as “changes to open” and retest.


#53

Not working at all now…

Here’s the updated Piston followed by the Full logs…

2/5/2020, 1:20:16 PM +941ms
+2ms ╔Received event [Porch Door].contact = closed with a delay of 126ms
+91ms ║RunTime Analysis CS > 20ms > PS > 56ms > PE > 15ms > CE
+93ms ║Runtime (38537 bytes) successfully initialized in 56ms (v0.3.110.20191009) (91ms)
+94ms ║╔Execution stage started
+100ms ║║Comparison (enum) closed changes_to (string) open = false (0ms)
+101ms ║║Cancelling condition #2’s schedules…
+102ms ║║Condition #2 evaluated false (4ms)
+103ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+105ms ║╚Execution stage complete. (11ms)
+106ms ╚Event processed successfully (106ms)
2/5/2020, 1:19:58 PM +241ms
+2ms ╔Received event [Porch Door].contact = open with a delay of 152ms
+90ms ║RunTime Analysis CS > 27ms > PS > 48ms > PE > 15ms > CE
+92ms ║Runtime (38538 bytes) successfully initialized in 48ms (v0.3.110.20191009) (89ms)
+93ms ║╔Execution stage started
+99ms ║║Comparison (enum) open changes_to (string) open = true (0ms)
+101ms ║║Cancelling condition #2’s schedules…
+102ms ║║Condition #2 evaluated true (4ms)
+105ms ║║Comparison (boolean) true is (boolean) false = false (1ms)
+107ms ║║Condition #7 evaluated false (4ms)
+107ms ║║Condition group #1 evaluated false (state did not change) (11ms)
+109ms ║╚Execution stage complete. (16ms)
+110ms ╚Event processed successfully (110ms)
2/5/2020, 1:19:34 PM +57ms
+1ms ╔Received event [Porch Door].contact = closed with a delay of 114ms
+61ms ║RunTime Analysis CS > 17ms > PS > 29ms > PE > 14ms > CE
+63ms ║Runtime (38537 bytes) successfully initialized in 29ms (v0.3.110.20191009) (61ms)
+65ms ║╔Execution stage started
+73ms ║║Comparison (enum) closed changes_to (string) open = false (0ms)
+75ms ║║Cancelling condition #2’s schedules…
+76ms ║║Condition #2 evaluated false (6ms)
+78ms ║║Condition group #1 evaluated false (state did not change) (8ms)
+80ms ║╚Execution stage complete. (16ms)
+81ms ╚Event processed successfully (81ms)
2/5/2020, 1:16:46 PM +612ms
+1ms ╔Received event [Porch Door].contact = open with a delay of 143ms
+68ms ║RunTime Analysis CS > 17ms > PS > 40ms > PE > 12ms > CE
+70ms ║Runtime (38538 bytes) successfully initialized in 40ms (v0.3.110.20191009) (68ms)
+71ms ║╔Execution stage started
+78ms ║║Comparison (enum) open changes_to (string) open = true (0ms)
+79ms ║║Cancelling condition #2’s schedules…
+80ms ║║Condition #2 evaluated true (5ms)
+83ms ║║Comparison (boolean) true is (boolean) false = false (1ms)
+85ms ║║Condition #7 evaluated false (4ms)
+85ms ║║Condition group #1 evaluated false (state did not change) (10ms)
+87ms ║╚Execution stage complete. (16ms)
+88ms ╚Event processed successfully (88ms)
2/5/2020, 1:16:34 PM +612ms
+1ms ╔Received event [Porch Door].contact = closed with a delay of 244ms
+80ms ║RunTime Analysis CS > 20ms > PS > 48ms > PE > 13ms > CE
+82ms ║Runtime (38537 bytes) successfully initialized in 48ms (v0.3.110.20191009) (80ms)
+83ms ║╔Execution stage started
+89ms ║║Comparison (enum) closed changes_to (string) open = false (0ms)
+91ms ║║Cancelling condition #2’s schedules…
+91ms ║║Condition #2 evaluated false (4ms)
+92ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+94ms ║╚Execution stage complete. (11ms)
+95ms ╚Event processed successfully (95ms)


#54

Looks like it ran into the boolean. Without diving into it too far I dont think I would have written the code this way and judging by the number of responses in this thread there are a lot stabs taken at it! :slight_smile:

For kicks and giggles, can you import and try my k5rf example? I tried it in my environment and it ran correctly as far as I could tell.


#55

That’s where we started, only alerting when opened, but not if it’s left open.


#56

Gotya, sorry. Misunderstood that. I was still working based off of this one;

So once it has alerted you the first time, and while its open you want to continue getting alerts. How often? And then once its closed is that when the 2x minute cool off period happens? If not where does that occur?


#57

Door opens, alert, wait 2 minutes before alerting again whether it’s from a re-open OR left open.

Wife comes in and out with groceries, opens, re-opens the door. Don’t want it to alert every single time, every 2 minutes is enough.

Last trip in she forgets to close it. Also alert me in 2 minutes, over and over until someone closes the door.


#58

edit #2; @DaveinTN try this one instead. Redid my approach without a variable


#59

Going back to the akxj3 example, I’d expect it to loop around giving a notification while the contact is open, but once the contact is closed, it wouldn’t run again. Is that what you found?

The problem is the variable. When you close the contact, the piston starts from the top and the condition evaluates differently, so the wait lower down gets cancelled (sort of - the effect is the same). When you open it again you are stuffed because the variable is false.

Have you tried the piston without the condition testing the variable? I can’t immediately see how it helps. Mind you that makes the whole ‘if’ redundant too. Your problem is being able to differentiate between the door being opened and reopened.

I need to think about this more, but it might be that what you need is a separate ‘if’ and ‘while’ rather than nesting them. The ‘if’ would be something like ‘if contact changes to open and contact was closed for x minutes then push notification’ (where x is however long you consider represents a new open rather than a reopen) and then the ‘while’ would be ‘while contact is open do wait 2 minutes; push notification’.


#60

I hope I am not out of line for jumping in…

All of these are solved in the following piston:

Some of the code above could be condensed a bit, but it helps most people to understand the logic when I break it down like this. (also, the log commands are optional code, and are only there so you can see the logic happening behind the scenes)

Here is a sample output from my testing:
(start reading from the bottom, going up)

pic


The only thing this piston does not do is:

I apologize, but I do not program loops for anyone unless I am “on the clock”.

… but as a courtesy, I would likely put the code for the “Repeat Notifier” in a separate piston.
(totally bypassing any looping, or at most, with a hard limit of 4-5 cycles)

IF Door's contact stays open for 121 seconds
    Then do stuff

Pro Tip:

If you hard code instead of looping, then each notification can be worded more aggressively, with the later one(s) also going to SMS and/or flashing a light in your house to get immediate attention.


#61

wqn2b didn’t work, it never pushed out the 1st notification.

q2uu seems to work for the open/close, however I’m at a lose on what your suggesting for a second Piston.

How does:

IF Door’s contact stays open for 121 seconds
Then do stuff

Repeat without a loop if the door is left open.

Sorry but my scripting skills are limited…