Why is my piston being called while it's still running?

saltyzoo · 2019-04-16 16:03:06 UTC

1) Give a description of the problem

I’m following the same pattern for this piston as I’ve used for many others with no problem - the only difference is this one is using a Ring doorbell as the motion sensor.

However, the piston is running again when the sensor changes to inactive and the code after the wait never runs.

2) What is the expected behavior?

When the sensor changes to active, the piston should turn on the light, wait, then turn off the light.

The piston should not be cancelled and allowed to run when the motion sensor turns inactive

3) What is happening/not happening?

The piston is being cancelled and running from the start when the sensor turns to inactive

5) Attach any logs (From ST IDE and by turning logging level to Full)

|+1ms|╔Received event [Home].time = 1555429461220 with a delay of -989ms|

| — | — |

|+97ms|║RunTime Analysis CS &gt; 20ms &gt; PS &gt; 51ms &gt; PE &gt; 26ms &gt; CE|

|+101ms|║Runtime (46498 bytes) successfully initialized in 51ms (v0.3.10a.20190223) (98ms)|

|+102ms|║╔Execution stage started|

|+103ms|║╚Execution stage complete. (2ms)|

|+105ms|╚Event processed successfully (104ms)|

|4/16/2019, 11:44:00 AM +140ms|

|+1ms|╔Received event [Motion Sensor 3].motion = inactive with a delay of 59ms|

|+72ms|║RunTime Analysis CS &gt; 13ms &gt; PS &gt; 34ms &gt; PE &gt; 25ms &gt; CE|

|+75ms|║Runtime (46491 bytes) successfully initialized in 34ms (v0.3.10a.20190223) (73ms)|

|+77ms|║╔Execution stage started|

|+83ms|║║Cancelling statement #20’s schedules…|

|+104ms|║║Calculating (string) gregPlace = + (string) home &gt;&gt; (string) gregPlace = home|

|+108ms|║║Calculating (string) gregPlace = home + (string)|

|+108ms|║║timeNow = &gt;&gt; (string) gregPlace = home|

|+108ms|║║timeNow =|

|+114ms|║║Calculating (string) gregPlace = home|

|+114ms|║║timeNow = + (string) 11:44:00 AM EDT &gt;&gt; (string) gregPlace = home|

|+114ms|║║timeNow = 11:44:00 AM EDT|

|+119ms|║║gregPlace = home|

|+119ms|║║timeNow = 11:44:00 AM EDT|

|+120ms|║║Executed virtual command log (2ms)|

|+129ms|║║Comparison (enum) inactive changes_to (string) active = false (1ms)|

|+131ms|║║Cancelling condition #42’s schedules…|

|+132ms|║║Condition #42 evaluated false (7ms)|

|+133ms|║║Cancelling condition #41’s schedules…|

|+134ms|║║Condition group #41 evaluated false (state changed) (11ms)|

|+138ms|║║Condition group #48 evaluated true (state did not change) (1ms)|

|+141ms|║╚Execution stage complete. (65ms)|

|+143ms|╚Event processed successfully (143ms)|

|4/16/2019, 11:43:20 AM +294ms|

|+2ms|╔Received event [Motion Sensor 3].motion = active with a delay of 96ms|

|+109ms|║RunTime Analysis CS &gt; 22ms &gt; PS &gt; 53ms &gt; PE &gt; 35ms &gt; CE|

|+112ms|║Runtime (46450 bytes) successfully initialized in 53ms (v0.3.10a.20190223) (109ms)|

|+113ms|║╔Execution stage started|

|+120ms|║║Cancelling statement #20’s schedules…|

|+834ms|║║Calculating (string) gregPlace = + (string) home &gt;&gt; (string) gregPlace = home|

|+838ms|║║Calculating (string) gregPlace = home + (string)|

|+838ms|║║timeNow = &gt;&gt; (string) gregPlace = home|

|+839ms|║║timeNow =|

|+844ms|║║Calculating (string) gregPlace = home|

|+844ms|║║timeNow = + (string) 11:43:21 AM EDT &gt;&gt; (string) gregPlace = home|

|+844ms|║║timeNow = 11:43:21 AM EDT|

|+849ms|║║gregPlace = home|

|+849ms|║║timeNow = 11:43:21 AM EDT|

|+850ms|║║Executed virtual command log (2ms)|

|+859ms|║║Comparison (enum) active changes_to (string) active = true (0ms)|

|+861ms|║║Cancelling condition #42’s schedules…|

|+862ms|║║Condition #42 evaluated true (8ms)|

|+863ms|║║Cancelling condition #41’s schedules…|

|+865ms|║║Condition group #41 evaluated true (state changed) (11ms)|

|+881ms|║║Comparison (enum) off is (string) off = true (2ms)|

|+883ms|║║Condition #23 evaluated true (13ms)|

|+885ms|║║Condition group #22 evaluated true (state did not change) (15ms)|

|+890ms|║║Cancelling statement #24’s schedules…|

|+907ms|║║Executed physical command [Outlet 6].on() (14ms)|

|+908ms|║║Executed [Outlet 6].on (16ms)|

|+912ms|║║Cancelling statement #49’s schedules…|

|+918ms|║║Executed virtual command setVariable (2ms)|

|+923ms|║║Executed virtual command wait (1ms)|

|+925ms|║║Requesting a wake up for Tue, Apr 16 2019 @ 11:44:21 AM EDT (in 60.0s)|

|+933ms|║╚Execution stage complete. (820ms)|

|+935ms|║Setting up scheduled job for Tue, Apr 16 2019 @ 11:44:21 AM EDT (in 59.992s)|

|+1120ms|╚Event processed successfully (1119ms)|

saltyzoo · 2019-04-16 16:34:13 UTC

Ok, so I found a tip in another thread that recommended putting ‘never cancel’ on all the with statements, which worked, but I still don’t understand why I have to do this. I don’t have to do this with ST sensors.

Pantheon · 2019-04-16 17:14:19 UTC

Just a very quick look at your piston…but is your Motion Sensor 3 changing to Inactive during your 1 minute wait? That will initiate a state change in your piston and the piston will restart from the beginning.

WCmore · 2019-04-16 18:37:52 UTC

To add a bit to what @Pantheon said, any device that you have subscribed to (in this case Motion Sensor’s motion) will run thru the code from top to bottom anytime that attribute changes either way. (active or inactive)

The “Never Cancel” option basically forces it to continue on with the original progression.

Paul1964 · 2019-04-16 18:39:16 UTC

I’ve written my pistons the same as you and they work fine. I only use the ST motion sensors.

I’ve been curious seeing other posts suggesting the whole piston runs again when the sensor goes back to no motion. This doesn’t seem to be the behaviour I see. I think the way it works with ST sensors seems correct & more intuitive.

Could this be down to the way the DH is written & interacts with webcore?

WCmore · 2019-04-16 18:43:44 UTC

It is the core functionality. Any lightning bolts in the left margin (triggers) means that webCoRE is told to monitor that device’s attribute, and to run thru the piston when it changes. (and executing any lines that are not blocked by conditions)

This is true for lights, motion sensors, thermometers, locks, etc.

Paul1964 · 2019-04-16 18:53:51 UTC

I think my memory of initial webcore programming may be failing me! I now use quite a complex piston that handles all my smart lighting. New sensors,devices, dim levels and times are just added to variables in arrays.

However, this is my original piston to control one light/sensor, which does use separate conditions for motion/no motion.

Pantheon · 2019-04-16 19:10:37 UTC

Slightly different approach…

WCmore · 2019-04-16 19:16:50 UTC

…and for those following along, @Pantheon’s piston above technically has ten triggers.

Driveway Motion active
Driveway Motion inactive
Main open
Main close
Second open
Second close
Shop open
Shop close
Man Door open
Man Door close

but with his choice of wording, there is only 5 of them that will actually do anything.
(if the first IF had an ELSE, then all 10 triggers would do stuff)

Pantheon · 2019-04-16 19:20:54 UTC

Hmmmm…you’re right. I hadn’t really thought about it that way. Yep, still learning webcore

Pantheon · 2019-04-16 19:29:25 UTC

@WCmore, are you suggesting I change some things? I ask, because I have struggled with this piston since I wrote it months ago.

WCmore · 2019-04-16 19:33:19 UTC

Well, if it is working for you now, then no need to mess with it.

If you are finding it unreliable (inconsistent), I often try to limit each piston to only a single trigger (which is really two) but it takes a bit of extra coding (and note taking) to achieve that on a piston like this.

Pantheon · 2019-04-16 19:41:00 UTC

AFAIK, it is working. Yeah, I have never really been good about “note taking” when writing code. Back in the day, when processing power and job runs were limited, I did put more forethought into writing code. Thanks for the critique.

saltyzoo · 2019-04-16 19:47:03 UTC

This is definitely NOT happening with my ST motion sensors. When they go back to inactive my pistons are NOT re-triggered. Only when I wrote one with a ring doorbell did I run into this behavior.

Pantheon · 2019-04-16 19:54:40 UTC

@saltyzoo, could it be related to the refresh time of the Ring? I have the Ring as well but I don’t know what the refresh time is. The refresh time on my motion sensors is 4 minutes. So my pistons (and my waits in those pistons) can definitely be influenced by a refresh (ie change of state) of the sensor.

saltyzoo · 2019-04-16 19:56:12 UTC

I have waits of up to 10 minutes that are working just fine with ST sensors. And the sensors are definitely going back to inactive before that 10 minutes is up. Loooong before.

WCmore · 2019-04-16 20:40:41 UTC

I have never seen a device where this did not happen. If you turn your logs to FULL you will see what I mean for all of your devices. Granted, if coded properly, the inverted trigger may not actually do anything, but it does trigger in both directions.

WCmore · 2019-04-16 20:54:12 UTC

@saltyzoo, notice there’s only one trigger here, but the entire piston runs top to bottom even when changing to inactive:

temp

saltyzoo · 2019-04-16 20:59:35 UTC

I am an idiot. I did not in fact follow the same pattern in this piston. Sorry.

In my other pistons I am in fact triggering off the inactive event with a “stays inactive” condition rather than doing a wait.

Oops.

This piston is actually a different use case than my others. Normally I want to wait for an inactivity period, but in this case I actually don’t care about activity, just time.

Pantheon · 2019-04-16 21:01:54 UTC

@saltyzoo, been there…many, many times