I’ve got a switch in my wall in the basement - it’s a WT00Z-1. Just connected to power - I use it to trigger a Webcore Piston to turn on my outside driveway floodlights.
This morning at 5:00am, the switch turned on, and turned off at 5:16am.
As my spouse and I, and the dogs, were all asleep, and the switch is too high for the cats to reach… Why? Why/how could a switch turn on, then back off, all on its own?
I am not pointing blame, but never underestimate the capabilities of a feline to create mischief.
Any chance that you have logging turned on within webCoRE? Not sure if there would be anything to glean from that, but the IDE logging will be useless.
LOL as a matter of fact… (bottom to top, obv)!
12/22/2020, 5:16:55 AM +19ms
+2ms ╔Received event [Driveway Lights].switch = off with a delay of 121ms
+3128ms ║RunTime Analysis CS > 25ms > PS > 3065ms > PE > 38ms > CE
+3130ms ║Runtime (36374 bytes) successfully initialized in 3065ms (v0.3.110.20191009) (3127ms)
+3131ms ║╔Execution stage started
+3138ms ║║Comparison (enum) off changes_to (string) on = false (0ms)
+3140ms ║║Condition #2 evaluated false (5ms)
+3141ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+3143ms ║╚Execution stage complete. (11ms)
+3144ms ╚Event processed successfully (3143ms)
12/22/2020, 5:16:55 AM +20ms
+1ms ╔Received event [Driveway Lights].switch = off with a delay of 121ms
+70ms ║RunTime Analysis CS > 27ms > PS > 10ms > PE > 33ms > CE
+72ms ║Runtime (36364 bytes) successfully initialized in 10ms (v0.3.110.20191009) (70ms)
+73ms ║╔Execution stage started
+80ms ║║Comparison (enum) off changes_to (string) on = false (0ms)
+82ms ║║Condition #2 evaluated false (5ms)
+83ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+85ms ║╚Execution stage complete. (12ms)
+86ms ╚Event processed successfully (86ms)
12/22/2020, 5:00:08 AM +160ms
+2ms ╔Received event [Driveway Lights].switch = on with a delay of 114ms
+10123ms ║RunTime Analysis CS > 20ms > PS > 10065ms > PE > 38ms > CE
+10124ms ║Piston waited at a semaphore for 10058ms
+10126ms ║Runtime (36442 bytes) successfully initialized in 10065ms (v0.3.110.20191009) (10123ms)
+10127ms ║╔Execution stage started
+10134ms ║║Comparison (enum) on changes_to (string) on = false (0ms)
+10135ms ║║Cancelling condition #2's schedules...
+10136ms ║║Condition #2 evaluated false (5ms)
|+10137ms|║║Cancelling condition #1's schedules...|
| --- | --- |
|+10138ms|║║Condition group #1 evaluated false (state changed) (6ms)|
|+10139ms|║╚Execution stage complete. (12ms)|
|+10140ms|╚Event processed successfully (10140ms)|
|12/22/2020, 5:00:08 AM +149ms|
|+1ms|╔Received event [Driveway Lights].switch = on with a delay of 102ms|
|+64ms|║RunTime Analysis CS > 25ms > PS > 9ms > PE > 31ms > CE|
|+66ms|║Runtime (36365 bytes) successfully initialized in 9ms (v0.3.110.20191009) (64ms)|
|+67ms|║╔Execution stage started|
|+75ms|║║Comparison (enum) on changes_to (string) on = true (0ms)|
|+76ms|║║Cancelling condition #2's schedules...|
|+77ms|║║Condition #2 evaluated true (5ms)|
|+78ms|║║Cancelling condition #1's schedules...|
|+79ms|║║Condition group #1 evaluated true (state changed) (8ms)|
|+81ms|║║Cancelling statement #3's schedules...|
|+96ms|║║Executed physical command [Front Floodlight].on() (11ms)|
|+97ms|║║Executed [Front Floodlight].on (13ms)|
|+108ms|║║Executed physical command [Garage Floodlight].on() (8ms)|
|+109ms|║║Executed [Garage Floodlight].on (10ms)|
|+111ms|║╚Execution stage complete. (44ms)|
|+112ms|╚Event processed successfully (112ms)|Hmm … I admit that I am not great at deciphering logs, other than to agree that it turned on/off 
Might be worth taking a swing at posting the piston and same log in the webCoRE forum. Still not ruling out the cat theory, though.
I’ve had some strange happenings with webcore lately. I believe the issue is related to an event failing, and then the “recovery” event not running right. Unfortunately logs stop at 5am so we really can’t see before.
Hopefully it straightens out soon, but if it continues I might have to move off webcore. Im not sure that’s your same issue, but The way recovery works is explained better on this post https://community.webcore.co/t/timed-events-not-always-running-correctly/18940/3
Try searching the forum for “poltergeist.“ 
It happens to some people sometimes. Sometimes it’s something local, but it can also be a cloud artifact and you’ll have no way of ever knowing why it happened. 
October 2017: Are the Poltergeists back? (Devices randomly turning on)
I guess I’m so weirded-out about it because it’s not something that’s been an issue in the past. Not the end of the world at all, it just had a couple lights on for a few hours until I noticed. Just weird.
I interrogated the cats - they assured me it wasn’t them and they blamed it on the dogs.
/Narrator: The dogs were asleep the whole time
All the logs show is that webCoRE received TWO ‘on’ events just after five in the morning, and TWO ‘off’ events just shy of seventeen minutes later.
G.
The ‘recovery’ events are sent when a piston has scheduled a timed execution and the timer event hasn’t been received, or is late.
A good way of seeing how pistons cope with recovery events is to surprise them with the Test button and see how they get on.
I had a piston “stuck” in recovery. The piston normaly sends me an sms if we all leave and the lights are still on, asking if I want to turn it them off. It kept repeatedly texting me over and over until I disabled the piston. The log just kept showing recovery events over and over. Very odd, that piston triggers frequently and that never happened before. I just figured its a glitch with whatever scheduler smartthings is using. I’m not sure if its related to the OP’s original issue or not though .
No, I don’t think it is, but it IS interesting. And something else to keep an eye on.
