Pistons no longer execute other Pistons


#1

1) Give a description of the problem
I rewired my dehumidifier over a year ago with a contact sensor so that I could get notifications when the tank was full. This worked for over a year without any problems at all. I haven’t made any changes to webcore in months, but in the recent weeks, I noticed I was no longer getting notifications. The setup works like this:

Piston A subscribes to the contact change and if the contact changes, waits 5 mins. If the contact has remain changed after 5 mins, it would “Execute Piston B”.

Piston B was responsible for Pausing Piston A and then checking on the contact sensor every hour and sending SMS notifications to my kids to tell them to dump the dehumidifier. When the contact changed, it would execute Piston A again (which would Pause B)

This worked awesome for a year - my house was dry :slight_smile: ! Now, it’s wet :frowning:

2) What is the expected behaviour?
I can no longer execute one piston from another

3) What is happening/not happening?
The second Piston stays in the Paused State

**4) Post a Green Snapshot of the piston


5) Attach logs after turning logging level to Full
(PASTE YOUR LOGS HERE THEN HIGHLIGHT ALL OF THE LOGS AND CLICK ON THE </> ICON TO FORMAT THEM CORRECTLY)
8/4/2020, 7:02:20 PM +46ms
+1ms ╔Received event [Hidden Stream].time = 1596582141719 with a delay of -1673ms
+76ms ║RunTime Analysis CS > 18ms > PS > 44ms > PE > 14ms > CE
+79ms ║Runtime (38784 bytes) successfully initialized in 44ms (v0.3.110.20191009) (77ms)
+80ms ║╔Execution stage started
+98ms ║║open
+99ms ║║Executed virtual command log (2ms)
+111ms ║║Comparison (enum) open is (string) open = true (1ms)
+112ms ║║Cancelling condition #8’s schedules…
+113ms ║║Condition #8 evaluated true (11ms)
+115ms ║║Cancelling condition #7’s schedules…
+115ms ║║Condition group #7 evaluated true (state changed) (14ms)
+118ms ║║Cancelling statement #9’s schedules…
+125ms ║║Piston should have fired
+126ms ║║Executed virtual command log (1ms)
+140ms ║║Executed virtual command executePiston (10ms)
+143ms ║╚Execution stage complete. (63ms)
+145ms ╚Event processed successfully (145ms)
8/4/2020, 6:57:21 PM +641ms
+1ms ╔Received event [Dehumidifier].contact = open with a delay of 37ms
+56ms ║RunTime Analysis CS > 14ms > PS > 32ms > PE > 10ms > CE
+58ms ║Runtime (38778 bytes) successfully initialized in 32ms (v0.3.110.20191009) (56ms)
+59ms ║╔Execution stage started
+66ms ║║Comparison (enum) open changes_to (string) open = true (0ms)
+68ms ║║Cancelling condition #2’s schedules…
+69ms ║║Condition #2 evaluated true (6ms)
+70ms ║║Cancelling condition #1’s schedules…
+71ms ║║Condition group #1 evaluated true (state changed) (8ms)
+73ms ║║Cancelling statement #5’s schedules…
+76ms ║║Executed virtual command wait (1ms)
+77ms ║║Requesting a wake up for Tue, Aug 4 2020 @ 7:02:21 PM EDT (in 300.0s)
+81ms ║╚Execution stage complete. (22ms)
+82ms ║Setting up scheduled job for Tue, Aug 4 2020 @ 7:02:21 PM EDT (in 299.996s)
+90ms ╚Event processed successfully (90ms)
8/4/2020, 6:57:19 PM +190ms
+1ms ╔Received event [Hidden Stream].test = 1596581839190 with a delay of 0ms
+65ms ║RunTime Analysis CS > 14ms > PS > 32ms > PE > 18ms > CE
+67ms ║Runtime (38784 bytes) successfully initialized in 32ms (v0.3.110.20191009) (65ms)
+68ms ║╔Execution stage started
+81ms ║║Condition #2 evaluated false (8ms)
+83ms ║║Condition group #1 evaluated false (state did not change) (9ms)
+86ms ║╚Execution stage complete. (18ms)
+88ms ╚Event processed successfully (88ms)


#2

There is no code shown above that pauses or resumes “Dehumidifier B”.
(it might have gotten paused accidentally during testing)

Regardless as to why it happened, you can manually press Resume on piston “B” once, and it should remain on indefinitely afterwards. (unless there is a 3rd piston at play)


#3

If you are going to be using the new app, adjust your pistons to the following:

send push notifications {your msg} and store in messages


#4

@WCmore - I now see what happened. I used to do a Resume Piston B from Piston A…A while back (seriously, how did I not notice for months), I changed A to “Execute B”, meaning (as you said), Pison B needs to be running (but not subscribing to events). I am not sure how Piston B got paused, but I now see the flaw in my logic and I can’t thank you enough. I have been staring at this for days and didn’t catch that - you are amazing!

@jkp - thank you for the tip - I saw you mention that in some other threads and will keep that in mind!


#5

Thanks! Glad we got it working!