2:21:34 PM: trace ╔═══ Task processing took 3667ms
2:21:34 PM: trace ║░░░ Removing any existing ST safety nets
2:21:34 PM: info ║░░░ Executing command: [Living Room Ambient Light].setColor([hue:44, saturation:100, level:75]) (141ms)
2:21:33 PM: info ║░░░ Executing command: [Kitchen Ambient Light].setColor([hue:91, saturation:100, level:54]) (211ms)
2:21:33 PM: info ║░░░ Executing command: [Weather].refresh() (999ms)
2:21:32 PM: info ║░░░ Scheduling ST job to run in 38.0s, at Sat, Aug 6 2016 @ 2:22 PM EDT
2:21:32 PM: trace ║░░░ Rescheduling time triggers
2:21:32 PM: trace ║╔══ Event processing took 387ms
2:21:31 PM: trace ║╚══ Processing event time with id time, generated on Sat Aug 06 18:20:10 UTC 2016, about 81501ms ago (v0.1.131.20160805)
2:21:31 PM: trace ║░░░ Broadcasting time event for primary IF block, condition #3, task = [time:1470507610332, idx:5, created:1470507599631, ownerId:3, type:evt, deviceId:time]
2:21:31 PM: trace ║░░░ Installing ST safety net
2:21:30 PM: trace ╚═══ Processing tasks (v0.1.131.20160805)
2:21:30 PM: info ║░░░ Received a RECOVER request...
2:19:59 PM: trace ║╔══ Task processing took 888ms
2:19:59 PM: trace ║║░░ Removing any existing ST safety nets
2:19:59 PM: info ║║░░ Scheduling ST job to run in 11.0s, at Sat, Aug 6 2016 @ 2:20 PM EDT
2:19:59 PM: trace ║║░░ Rescheduling time triggers
2:19:59 PM: trace ║╚══ Processing tasks (v0.1.131.20160805)
Note: read upside down…
The recovery happened as I moved in the patio - another piston subscribed to that motion sensor, handling patio lights - so CoRE is technically using other piston events to kick start belly-up’d pistons…
Welcome back! It appears you are back at the home helm now
CoRE v0.1.131.20160805 has stopped the playback of my Aeon Doorbell (DTH Siren and Music Player)
I have revisited the Pistons and R&R device and actions, even built new Simple Piston to Play Track at contact close and get this in the live log:
12:48:19 PM: error groovy.lang.MissingMethodException: No signature of method: script1470512507154634151819.playTrack() is applicable for argument types: (java.lang.String, java.lang.Integer) values: [2, 10]
Very simple Piston, set hourly minute to ‘59’, too much delay at ‘00’.
It is actually the #2 sound in the Aeotec Doorbell. Sounds like Big Ben, I used Audacity to add some lead-in and out silence to avoid cut out.
Also have another Pendulum Clock chime file I made, you can hear the clock workings before and after, I’d be happy to send or post somewhere. Let me know
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
1379
@ady624 Since updating to v0.1.131 recovery has been working much better, Example; my weather tile poll update. In this image can see it recovering quite nicely.
However right around the same time my test piston failed. Notice the logs indicated no excess time delay and yet it didn’t reschedule, probably because looking at the logs, nothing failed.
Looks like some of the recent platform issues finally got me. None of my latching pistons are changing state to False when they should (when a routine is executed), unless I manually kick them with the little arrow on the CoRE button under SmartApps. This also means that the True actions don’t run when they are set to execute only on piston state change. Argh. I’m getting tons of timeout exceptions in the logs, even when CoRE isn’t commanding anything.
This is under the main CoRE logs, not a log for a specific piston. At the time I took that screenshot nothing was running or was supposed to be running.
I updated to the latest version this morning when I noticed the issues, which was before I captured the logs below.
I have three similar pistons (one for the closet light, one for the master bathroom, and one for the master toilet room) that are all supposed to set dimmer levels when Goodnight routine is run, then the first time each of the lights are turned on the next morning, they should reset to 100%. Here’s the logs of one of them, assuming that all three are experiencing the same issues so not going to post all three unless you want to see the others as well.
Log from the master bathroom piston when I executed the Goodnight routine (9:01am) shows a piston state change to false, but in the dashboard it never changes to false:
Here’s when I turned the Master Bath lights on, which should have met the conditions to change piston state back to True. Nothing happened other than the light turned on to it’s previous level of 1%.
I thought it was our ST Ticker causing more problems 
