Task Cancellation Help

#1

Looking for assistance with TCP please.

Background:

  1. My wife does not care about HA, and will never look at an app or tile screen for info; nor would she really understand what she is looking at if she did. As a result, I try to build with that in mind. And 2) ST misses actions or sensors fail to update 100% of the time

We have a piston that will turn off the thermostats if any doors/windows have been open for more than a minute - this works great, especially in spring and fall. However on rare occasion a ST sensor fails to read a close event, thus a contact sensor continues to report open (front door for example). It’s the middle of winter here, a falsely reporting open front door turns off the heat in the house. Rather than trying to automate any corrective actions, I am trying to push sms.

So I wrote the following piston to check to see if the ‘door/window open tracking’ switch is on (on=open) and it is cold out. If that switch is on for more than 10 minutes then send the SMS.

Here is the problem, I would have thought that the switch returning to off (within 10 minutes) would cancelled the pending SMS. It is not, I am getting the SMS most of the time.

At first, I wrote it with simply the default TCP, which as I understand it is simple and logical - cancel on condition state change. I have updated it to Piston or Condition. I think it is currently default in this piston. You can see I also tried A) ‘simply on, and wait’ or B) ‘switch stays on’ and (not shown) A+B. In all cases, I am getting the text message. What am I missing?

image
image.png1178×584 37.1 KB

#2

I must admit, I would have thought that the SMS would not be sent. Have you got the logs to post here.
I theory this should not be needed but how about putting an ELSE in the piston.

IF
x
and
y
THEN
Wait
SMS.

ELSE
WITH
Location
DO
Cancel all pending tasks.
In case it is setting up a schedule that is not being cancelled.
Don’t know if it will work but might be worth a try.
Logs would be good though to see what is happening, or not as the case may be.

#3

I have added logging and will try this approach first. Might be tomorrow before both the door is opened AND I have time to get the logs! If the logs do not produce results, I will try your ELSE approach. Cheers!

#4

Because you have a trigger on line 27, auto subscription is not subscribing to the conditions on lines 19, 21 and 29.

Therefore closing your window is not registered by the piston and isn’t cancelling your wait.

Either tweak the second part of your piston to only use conditions (like the first part) or open each condition in turn and change subscription to ‘always’

You can tell which lines have subscribed to events by looking looking for the orange lightning bolt in the left margin.

By default, in the absence of any triggers, all conditions act as triggers and subscribe. If there is a trigger in the mix, only the trigger subscribes and the conditions don’t.

Also, as temperature will nearly always fluctuate over 10 minutes, you should change your Task Execution Policy (on the two ‘with locations’) to ‘on condition change only’. This will prevent temp fluctuations re-firing the piston and resetting the waits back to 10 minutes.

#5

image
image.png1178×601 35 KB

#6

Or this method will send an SMS every 10 minutes while the conditions are met, and includes a running timer in the message stating how long the door/window has been open.

image
image.png1178×636 37.7 KB

#7

Hi Robin, thanks for the help.

I updated my piston as you show in post #5 (or so I believe).

image
image.png1178×585 37.2 KB

I still got a text message

Logs:
1/25/2018, 10:33:42 AM +253ms
+5ms ╔Received event [Home].time = 1516894422866 with a delay of -614ms
+127ms ║RunTime Analysis CS > 36ms > PS > 44ms > PE > 43ms > CE
+134ms ║Runtime (40610 bytes) successfully initialized in 44ms (v0.2.102.20180116) (126ms)
+138ms ║╔Execution stage started
+187ms ║║Executed virtual command sendSMSNotification (27ms)
+201ms ║║Comparison (enum) off is (string) on = false (2ms)
+203ms ║║Condition #10 evaluated false (12ms)
+204ms ║║Condition group #7 evaluated false (state did not change) (14ms)
+207ms ║╚Execution stage complete. (72ms)
+211ms ╚Event processed successfully (211ms)
1/25/2018, 10:30:14 AM +181ms
+2ms ╔Received event [SmartWeather Station Tile 2.0].temperature = 23 with a delay of 81ms
+121ms ║RunTime Analysis CS > 17ms > PS > 60ms > PE > 44ms > CE
+124ms ║Runtime (40626 bytes) successfully initialized in 60ms (v0.2.102.20180116) (121ms)
+126ms ║╔Execution stage started
+140ms ║║Comparison (enum) off is (string) on = false (1ms)
+142ms ║║Condition #5 evaluated false (10ms)
+143ms ║║Condition group #1 evaluated false (state did not change) (11ms)
+153ms ║║Comparison (enum) off is (string) on = false (2ms)
+154ms ║║Condition #10 evaluated false (8ms)
+155ms ║║Condition group #7 evaluated false (state did not change) (10ms)
+158ms ║╚Execution stage complete. (34ms)
+160ms ║Setting up scheduled job for Thu, Jan 25 2018 @ 10:33:42 AM EST (in 208.526s)
+175ms ╚Event processed successfully (175ms)
1/25/2018, 10:23:42 AM +950ms
+1ms ╔Received event [Thermo: Windows/Doors Open].switch = off with a delay of 70ms
+122ms ║RunTime Analysis CS > 35ms > PS > 39ms > PE > 48ms > CE
+124ms ║Runtime (40616 bytes) successfully initialized in 39ms (v0.2.102.20180116) (123ms)
+125ms ║╔Execution stage started
+137ms ║║Comparison (enum) off is (string) on = false (2ms)
+138ms ║║Cancelling condition #5’s schedules…
+139ms ║║Condition #5 evaluated false (8ms)
+140ms ║║Cancelling condition #1’s schedules…
+141ms ║║Condition group #1 evaluated false (state changed) (10ms)
+149ms ║║Comparison (enum) off is (string) on = false (2ms)
+151ms ║║Condition #10 evaluated false (6ms)
+152ms ║║Condition group #7 evaluated false (state did not change) (8ms)
+155ms ║╚Execution stage complete. (30ms)
+156ms ╚Event processed successfully (156ms)
1/25/2018, 10:23:42 AM +557ms
+1ms ╔Received event [Thermo: Windows/Doors Open].switch = on with a delay of 87ms
+272ms ║RunTime Analysis CS > 25ms > PS > 208ms > PE > 39ms > CE
+274ms ║Runtime (40623 bytes) successfully initialized in 208ms (v0.2.102.20180116) (272ms)
+275ms ║╔Execution stage started
+286ms ║║Comparison (enum) on is (string) on = true (2ms)
+287ms ║║Cancelling condition #5’s schedules…
+288ms ║║Condition #5 evaluated true (7ms)
+298ms ║║Comparison (decimal) 22.0 is_less_than_or_equal_to (integer) 50 = true (1ms)
+299ms ║║Condition #6 evaluated true (10ms)
+300ms ║║Cancelling condition #1’s schedules…
+301ms ║║Condition group #1 evaluated true (state changed) (20ms)
+303ms ║║Cancelling statement #2’s schedules…
+307ms ║║Executed virtual command wait (1ms)
+308ms ║║Requesting a wake up for Thu, Jan 25 2018 @ 10:33:42 AM EST (in 600.0s)
+314ms ║╚Execution stage complete. (38ms)
+315ms ║Setting up scheduled job for Thu, Jan 25 2018 @ 10:33:42 AM EST (in 599.994s)
+323ms ╚Event processed successfully (322ms)
1/25/2018, 10:21:48 AM +459ms
+2ms ╔Received event [Home].test = 1516893708453 with a delay of 2ms
+130ms ║RunTime Analysis CS > 26ms > PS > 61ms > PE > 45ms > CE
+137ms ║Runtime (40607 bytes) successfully initialized in 61ms (v0.2.102.20180116) (133ms)
+139ms ║╔Execution stage started
+182ms ║║Comparison (enum) off is (string) on = false (4ms)
+185ms ║║Condition #5 evaluated false (27ms)
+186ms ║║Condition group #1 evaluated false (state did not change) (30ms)
+197ms ║║Comparison (enum) off is (string) on = false (1ms)
+198ms ║║Condition #10 evaluated false (7ms)
+198ms ║║Condition group #7 evaluated false (state did not change) (8ms)
+205ms ║╚Execution stage complete. (66ms)
+209ms ╚Event processed successfully (210ms)

#8

PS: A bit of a sidestory here, but interesting - line numbers are different between View Only and Edit modes. Slightly confusing. I wonder if that is the best approach - I can see why it was done that way, but still. Interesting…

#9

That’s seriously odd… shouldn’t be sending the message!!!

@ipaterson

#10

For now… guess you’ll need to add the

ELSE
cancel all pending tasks

as per @bobbles comment at the top of this thread… would have needed the subscriptions anyway but certainly shouldn’t be needing the added cancel command… would appear ‘cancel on condition state change’ is not cancelling SMS schedules.

#11

I may be a bit off here, but as I read it, there’s not check after 10 minutes to validate the switch state. It’s a synchronous uninterrupted command.

I would think you have to make the first If the same as the second (Swtich 6 stays on for 10 minutes).

If
Switch 6’s switch stays on for 10 minutes
and
Temperature Sensor 1’s …
then
send message

#12

That method would also work… but so should two conditions.

I simple piston like the following cancels just fine when the switch turns off:

IF switch is ON
THEN
wait 10 minutes
turn off

So why won’t the SMS cancel in the example @kraig109 is trying???

#13

So both of these cancel fine, so it’s not the SMS command that’s at fault.

image
57EBB1B0-CB1E-4545-BE81-9A932FD53CA4.png1178×413 55.5 KB

image
F8836F51-768C-45EA-A546-03B07D127FDE.png1178×481 57.3 KB

Must be to do with ‘condition state change’ not changing until BOTH conditions change back to false…

Perhaps:

IF
Switch IS on
THEN
IF
temp is below
THEN
wait 10 minutes
Send SMS
END IF
END IF

might work better?

#14

Your last post makes sense. So far I have tried the ‘Else Do Cancel’, and tested that twice. It behaved correctly both time, one of them texting because indeed a sensor missed a close event and was stuck reporting open (exactly the point of this piston).

FYI, here is my updated (worked once) piston. For testing I shortened the time and merged the two temp conditions into 1 Logical OR statement.

image
image.png1178×651 37.1 KB

Feels like I am going to leave it here. It will get tested a bunch each day as it includes the front door. If it fails, I’ll post.

Well maybe we discovered for the wiki on TCP! Thanks for the help

#15

That’s a really good question. I get where it might with the “while” statement, which would then make sense that both conditions need to chance back since there is an “and.”

I’m surprised it does cancel with a simple “if” statement. In my mind it doesn’t make sense for the reevaluation of a switch state after a time in a synchronous execution. It “should” just blow right through to the next command with a “If” statement.

Show’s you how much I’m getting this.

#16

Got it. Clearly I was thinking of something completely different. Yes I agree now that it should work. A variable could be put in so that only one text is sent.

#17

The ‘Else Do Cancel’ also failed today. *I also since fixed my variable in the SMS message incase anyone catches that error! :slight_smile:

Logs:
1/26/2018, 7:20:08 AM +413ms
+7ms ╔Received event [Home].time = 1516969209097 with a delay of -685ms
+501ms ║RunTime Analysis CS > 254ms > PS > 129ms > PE > 113ms > CE
+511ms ║Runtime (40367 bytes) successfully initialized in 129ms (v0.2.102.20180116) (501ms)
+519ms ║╔Execution stage started
+713ms ║║Calculating (string) Doors and/or Windows have been open for more than + (string) Empty device list >> (string) Doors and/or Windows have been open for more than Empty device list
+717ms ║║Calculating (string) Doors and/or Windows have been open for more than Empty device list + (string) minutes and it is >> (string) Doors and/or Windows have been open for more than Empty device list minutes and it is
+724ms ║║Calculating (string) Doors and/or Windows have been open for more than Empty device list minutes and it is + (string) 17 >> (string) Doors and/or Windows have been open for more than Empty device list minutes and it is 17
+728ms ║║Calculating (string) Doors and/or Windows have been open for more than Empty device list minutes and it is 17 + (string) °F outside. >> (string) Doors and/or Windows have been open for more than Empty device list minutes and it is 17°F outside.
+754ms ║║Executed virtual command sendSMSNotification (19ms)
+759ms ║╚Execution stage complete. (247ms)
+769ms ╚Event processed successfully (770ms)
1/26/2018, 7:18:08 AM +965ms
+0ms ╔Received event [Thermo: Windows/Doors Open].switch = off with a delay of 61ms
+10277ms ║RunTime Analysis CS > 20ms > PS > 10173ms > PE > 85ms > CE
+10278ms ║Piston waited at a semaphore for 10133ms
+10280ms ║Runtime (40452 bytes) successfully initialized in 10173ms (v0.2.102.20180116) (10279ms)
+10281ms ║╔Execution stage started
+10291ms ║║Comparison (enum) off is (string) on = false (2ms)
+10293ms ║║Cancelling condition #5’s schedules…
+10294ms ║║Condition #5 evaluated false (6ms)
+10295ms ║║Cancelling condition #1’s schedules…
+10295ms ║║Condition group #1 evaluated false (state changed) (9ms)
+10298ms ║║Cancelling statement #13’s schedules…
+10306ms ║║Executed virtual command cancelTasks (7ms)
+10323ms ║╚Execution stage complete. (42ms)
+10325ms ╚Event processed successfully (10325ms)
1/26/2018, 7:18:08 AM +879ms
+6ms ╔Received event [Thermo: Windows/Doors Open].switch = on with a delay of 301ms
+166ms ║RunTime Analysis CS > 32ms > PS > 59ms > PE > 72ms > CE
+172ms ║Runtime (40378 bytes) successfully initialized in 59ms (v0.2.102.20180116) (164ms)
+176ms ║╔Execution stage started
+187ms ║║Comparison (enum) on is (string) on = true (1ms)
+188ms ║║Cancelling condition #5’s schedules…
+189ms ║║Condition #5 evaluated true (7ms)
+201ms ║║Comparison (decimal) 17.0 is_less_than_or_equal_to (integer) 50 = true (2ms)
+203ms ║║Condition #6 evaluated true (11ms)
+204ms ║║Condition group #15 evaluated true (state did not change) (13ms)
+205ms ║║Cancelling condition #1’s schedules…
+206ms ║║Condition group #1 evaluated true (state changed) (24ms)
+208ms ║║Cancelling statement #2’s schedules…
+214ms ║║Executed virtual command wait (1ms)
+218ms ║║Requesting a wake up for Fri, Jan 26 2018 @ 7:20:09 AM EST (in 120.0s)
+223ms ║╚Execution stage complete. (51ms)
+227ms ║Setting up scheduled job for Fri, Jan 26 2018 @ 7:20:09 AM EST (in 119.994s)
+235ms ╚Event processed successfully (235ms)
1/26/2018, 4:45:14 AM +335ms

Later today I will look at some of the other suggestions in this thread, have to go back and read/understand them. Maybe the IF/IF/Then might work. Something does seem off however, TCP should be working here and canceling the SMS.

#18

In theory, the If/If/Then “should” work as only one condition would need to prove false to cancel things. I’m really interested in how you sort this out. I’m still confused about how some of these statements (e.g. while, if/then) are managed throughout the piston firing.

#19

I probably won’t be much help here, but

The off and on events arrived within the same second which makes me very suspicious of a race condition where perhaps toggling the switch on had not yet scheduled the wake up by the time toggling the switch off cancelled the schedule. I’m sure you’ve tested this with more than a second between toggling the switch but just wanted to verify.

#20

Yes, tested with several seconds delay. The most common switch at work here is front door. Most times it takes more than a second to pass through (including the open, walk through, and close) actions.

That said, is there a way to write it that reevalutates the state after the wait time - should allow to buffer out the race condition? Something like ‘and is still open’?