Piston Recovery keeps executing. (Piston worked fine before today)

#1

1) Give a description of the problem
(Hello,
I have a piston that evaluates my motion sensors at the top and bottom of the stairs and turns my lights on. It accounts for motion being active at the top or bottom and the other being inactive so I do not get a double execution of the lights turning on. After 15 seconds of no motion on both sensors, it shuts off the lights. The piston has worked perfectly until today. Now the lights will turn on fine, but when motion goes inactive and it sets up the job to turn the lights off, instead of turning them off the log reports back the piston executed a recovery. It sets up another job. This now seems to be looping. Any ideas what could of happened?)

2) What is the expected behaviour?
(Lights should turn off as they have been doing.)

3) What is happening/not happening?
(The lights turn on but do not turn off. )

**4) Post a Green Snapshot

Piston%20Stairs
Piston Stairs.png1178×1093 140 KB

#2

Are you familiar with the idea of recovery events? Each time a piston runs it schedules its own next run, if required. If a timer event fails to arrive, that might mean the next run is never scheduled, which might mean the piston could ‘stop’ if it doesn’t fire for some other reason before the next runis due. That is where recovery events come in. Every running piston, as well as a regular recovery process, will check whether any other piston is very late receiving a timer event, and if so will send a recovery event to fire it.

If a timer event doesn’t arrive, ST may well be playing up. I imagine it might be possible to generate so many events in a short space of time that you get rate limited, but in a piston like yours I favour a one-off blip or more serious issues originating with ST.

#3

Hi There! Thank you always for your informative replies. I have started to become versed in recovery events as I have played with Pistons. When you refer to timed events, would this be any event I tell to execute in a certain amount of time? For example, setting a switch to “on” is not a timed event, but dimming a light to 50% in 20 seconds is? Would a recovery apply if webCore did not report back a successful execution of an event even if it was not a timed event?

As you have suggested with many events, sometimes I have gotten a little too ahead of myself in telling webcoRE how many things to do at once. Some events, especially long lighting fades would execute, but some would not, prompting a recovery to go back and execute the missed tasks. I solved this by putting some waits between events to help break up what I was sending. This recovery now seems to be occurring across all my Pistons now. So as you suggest, ST could be having a problem right now.

#4

Same for me. All my pistons, that have worked for years, are all executing their recovery callbacks today, and are not able to be scheduled. I don’t think the issue is with your code, but something that changed in webCoRe.

#5

It would be anything that involves scheduling a timed execution, exiting and waking up. So a ‘wait’ (usually over 5 seconds), a ‘stays’ condition, and, yes, a ‘fade’ are the obvious candidates (I’ve not got any dimmers or coloured lights so have zero practical experience).

The recovery events are sent by webCoRE because it knows it has requested a timer and not received it. It doesn’t know about other events until they arrive.

#6

Same for me. I have 2 very simple timer pistons that failed to execute just recently and showed up as a recovery event. The pistons were just simple timers that should have turned on a light at a certain time. Not sure why they did not execute.

#7

All pistons have stopped working.

#8

The ones that say “time happens daily at xxx” (to turn off the lights) suddenly stopped working a day ago, haven’t touch the code. The logs show up as a recovery event.

#9

My issues have been resolved automagically.