Having issues with piston OFF behavior

#1

1) Give a description of the problem
I’m having some issues with my things not turning off all of a sudden. Probably the last 10 days or so, I’ll have one or more lights that just fail to turn off. This is new behavior and I haven’t performed any work on my ST setup or these pistons in particular.

2) What is the expected behaviour?
When pistons turn on and have a time to turn off, I expect they will turn off.

3) What is happening/not happening?
My pistons are turning on, but failing to turn off.

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png1178×577 54.7 KB

5) Attach logs after turning logging level to Full
One successful event (4/7) and one UNsuccessful event (4/8):

4/8/2020, 7:00:30 AM +332ms
+0ms ╔Received event [Home].execute = recovery with a delay of 183ms
+103ms ║RunTime Analysis CS > 21ms > PS > 37ms > PE > 46ms > CE
+106ms ║Runtime (36814 bytes) successfully initialized in 37ms (v0.3.110.20191009) (104ms)
+107ms ║╔Execution stage started
+139ms ║║Comparison (time) 25230443 happens_daily_at (time) 1586353320000 = false (0ms)
+141ms ║║Condition #2 evaluated false (30ms)
+142ms ║║Cancelling statement #2's schedules...
+146ms ║║Requesting time schedule wake up at Thu, Apr 9 2020 @ 6:42:00 AM PDT
+148ms ║║Condition group #1 evaluated false (state did not change) (38ms)
+151ms ║╚Execution stage complete. (45ms)
+152ms ║Setting up scheduled job for Thu, Apr 9 2020 @ 6:42:00 AM PDT (in 85289.517s)
+171ms ╚Event processed successfully (171ms)
4/7/2020, 6:56:57 AM +316ms
+1ms ╔Received event [Home].execute = recovery with a delay of 48ms
+99ms ║RunTime Analysis CS > 18ms > PS > 36ms > PE > 44ms > CE
+101ms ║Runtime (36807 bytes) successfully initialized in 36ms (v0.3.110.20191009) (100ms)
+102ms ║╔Execution stage started
+133ms ║║Comparison (time) 25017422 happens_daily_at (time) 1586266980000 = false (1ms)
+134ms ║║Cancelling condition #2's schedules...
+135ms ║║Condition #2 evaluated false (29ms)
+136ms ║║Cancelling statement #2's schedules...
+140ms ║║Requesting time schedule wake up at Wed, Apr 8 2020 @ 6:43:00 AM PDT
+143ms ║║Cancelling condition #1's schedules...
+143ms ║║Condition group #1 evaluated false (state changed) (37ms)
+146ms ║╚Execution stage complete. (44ms)
+147ms ║Setting up scheduled job for Wed, Apr 8 2020 @ 6:43:00 AM PDT (in 85562.538s)
+156ms ╚Event processed successfully (156ms)

The very same behavior (though it looks different in the logs) is happening to 2 other pistons. Not sure if there was a change to ST FW or Webcore that requires that I change my pistons.

#2

I think I would recommend using two IF blocks… one to turn the device on at sunrise and the other to turn off the device at 11 pm. I would skip using the wait command.

Also, consider using the timer block… every day at sunrise and every day at 11pm :slight_smile:

#3

agree with @jkp. One problem with the wait is when it comes back, the if is no longer true so it doesn’t want to execute the statements inside. Also, even your successful run is a recovery, not the original run so something is clogging up your system. Avoiding the long wait should make this run more consistently.

#4

Thanks for the reply.

I have a ‘two if’ piston failing the same way:

download
download.png1178×656 89.8 KB

Note: I’ll change the original one to the more appropriate two-IF design later, but that doesn’t seem to be the cause.

#5

Here’s the same piston with the proper second IF block:

download%20(1)
download (1).png1178×673 96.3 KB

I’m assuming it won’t be fixed by this, since the other one is having the same problem. I’m tempted to reboot the ST gateway, since it seems to be affecting a broad swath of my pistons and not pistons that all look the same.

#6

That isn’t what I see in the logs. I see a recovery event for each day. The scheduled event for sunrise (shortly before 6:45am) appears to have failed on both occasions and a recovery event has been sent to ensure the schedule for the next morning gets set.

#7

That may be true, but the turn off event at midnight didn’t happen. Not real sure how to square that.

#8

The logs (and I am referring to the first post here) show no sign of the piston having run to turn the light on and set up the ‘wait’.

#9

Midnight can be a finicky thing as well. Once it is a new day, midnight means something new. Try using 11:59 PM.

If you have a lot of pistons all firing at sunrise, that could be one source of problems leading to the recoveries. If you want a lot of things to happen at sunrise, best to create one piston that triggers at sunrise and do everything than a lot of little ones all trying to run at the same time.

#10

Agree with @orangebucket, it looks as if both were from a recovery. I have also been having strange behavior with ST/WC recently so maybe that is the cause. However, I try not to use times around midnight as things sometimes get confusing. I generally code several minutes before or after midnight to avoid spanning midnight problems.

#11

Or what I do… I use a few mini-pistons, but set the times slightly differently…

IE: One piston runs at sunrise +5 minutes, and another runs at sunrise +8 minutes. This is also a great way to get a lot of things done at nearly the same time, without multiple pistons running simultaneously…

#12

So I would create a trigger piston, and then if the trigger piston is true, it triggers the other pistons that rely on it?

#13

Yes, you can take the trigger out of the other pistons and just run from the one ‘sunrise’ piston. You do need to be careful to disable event subscriptions to keep conditions in those pistons from turning into triggers. Simpler option may be to do as @WCmore suggested above and just offset each one slightly to avoid the collisions. Depends on the complexity of your pistons.