This is CoRE’s fast recovery in effect:
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]
I am using @krlaframboise 's
This is my fault, I requested the change so that it matches the documentation. I’ll have an update for the DTH shortly.
First timed event failure while running on the new release. Looks like it recovered this one. Keeping fingers crossed.
Thanks Kevin, I miss my hourly clock chimes I thought it was our ST Ticker causing more problems
I just released a new version of that DTH, please let me know if it fixes your pistons.
I have this piston that missed it 3:01 deadline. It appears that it isn’t being rebuilt either. What action should I take?
Are you talking about something like a cuckoo clock paying through your speaker every hour? That’s awesome!
Please post your piston.
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
Yes, please email that to me…
I will and will take 2 Alabama Slammers in return, sounds like a great drink
Same here Jason. Lots of my lights stays open even if there is no motion after X mins.
@ady624 just curious if something is going on with my CoRE install re: the odd spacing in the word co re in the light grey text under each recovery.
@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.
It wasn’t until the CoRE’s main stage recover fired that if finally brought back my testing app.
This means that CoRE is making sure nothing is left behind. I just wonder how my piston failed with no indicator there was a problem.
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.
What is that branch of the piston doing to timeout?
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.
Main CoRE runs some recovery routines. What version are you on? The latest switched from executing the child app to sending an event to the child app…
Also, you mentioned your latching piston(s) not firing. Any logs there?
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.
Master Bathroom piston
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:
I executed the Good morning routine to set the mode back to Home at 9:05am:
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%.