[OBSOLETE] [BETA MILESTONE 1] CoRE (Community's own Rules Engine)

Now there is a silver lining.

Really, we need an ady @ ST.

Imagine if we could fix the root of the problem, and could directly observe the issues.

1 Like

So the piston subscription to fast recovery was messing up with global variables. Moved it back towards the end of the piston (which I really don’t like, because if the actions time out, no re-subscription happens). When I moved it, I forgot to replace app.id with appId - thus rendering the fast recovery completely useless. Then the stage 1 and stage 2 were also keying on the subscriptions, rather than all pistons (really trying to use less resources) - meaning CoRE was not really recovering anything, unless CoRE > Settings > Recover all pistons was used. Sorry, beginner’s mistake. Lost some customers? (just being goofy now)

For the time being:

  • The play button in the SmartApps page kicks all piston’s butt
  • Stage 1 and 2 recovery also kick all piston’s butt
  • Fast recovery is now working - each piston tells CoRE when it’s supposed to run next, also giving CoRE a chance to check on all others. Once CoRE determines a piston was scheduled to run more than one minute ago, it gives it a nudge via a CoRE Recovery [app id goes here] event.
1 Like

i am on v0.1.114…

Since this is beta, I assume one would have to manually enable / load that code?

If you’re using github, all you need to do is just go to SmartApps in IDE and click Update from Repo, select the CoRE Repo, select the CoRE app, make sure you tick the Publish checkbox and press Update. Done.


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 :wink:

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.

1 Like

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 :bellhop: I thought it was our ST Ticker causing more problems :wink:

1 Like

I just released a new version of that DTH, please let me know if it fixes your pistons.

1 Like

I have this piston that missed it 3:01 deadline. It appears that it isn’t being rebuilt either. What action should I take?

1 Like

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 :wink:

Yes, please email that to me…



1 Like

I will and will take 2 Alabama Slammers in return, sounds like a great drink :tropical_drink:

1 Like

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?