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

Seems to be a trend here , I had a Time of Use Piston for my A/C fail yesterday, that cost me some money! It showed overdue in the Dashboard, went into the Piston and pressed Done and it executed.

So, no one? @ady624

This was Adrian’s explanation of it:

And I believe the second stage kicks the first stage in case it died. It’s been working for me.

Adrian is in vacation this week. He’ll respond as soon as he gets back if his previous explanation posted by @eibyer is not sufficient.

Yay vacation!

I did see that response about how it kicks, I guess what I was looking for was more of what it actually does. Is it the same as pressing ‘done’ to an open piston? I can wait.

Thanks!

Well, it would seem that mine is doing the same thing… But I haven’t had any problems. Maybe it works better when it’s off?

1 Like

I am having an issue getting back to the CoRE main page after creating a piston. Hitting “done” takes me back to the “My Apps” page, where I can view the CoRE app again, however when I click on it I am directed back into the last piston I had accessed. Same thing happens if I use the back arrow. I’m sure I am missing something quite simple here, but I cannot figure out what, so I am limited to creating a single piston at this point.

Get to CoRE using the.hamburger menu (3 horizontal lines) from top left, errr right of the ST app.

I’ve done some changes to the recovery because too many pistons would cause it to timeout. Namely, rather than executing child apps, I am sending them events. I noticed that recovery no longer works consistently now (it relies on pistons telling CoRE when they need to run next) I will fix this when I get home. Also, the Play button on the Smart Apps page only recovers those pistons that have been successful at tellig CoRE when to run. I will make it kick all. You can still kick all pistons right now by going to CoRE’s Settings and recovering all pistons.

2 Likes

Guys, that recoveryHandle is a piston routine that is initiated if and when an execution times out. It is also used by CoRE’s internal recovery to kick them started. But you’ll se a recoveryHandle every time a timeout happens.

HaHa, that’s what the Play button is for, since I never saw it do anything, wan’t sure if it was just eye candy :slight_smile:

Rick

I will make it kickstart all pistons. Via an event that all pistons subscribe to behind the scene.

My dashboard has quit working again.
Is any one else having this problem?

I have tried opening each piston and clicking done twice now. No problems were found, and it is still not working.

Edit: about an hour after just leaving it alone the dashboard is back up…

Fixed some bugs with recovery.

v0.1.130.20160805 - Beta M1 - Fixed a bug with CoRE recovery, the play button now kicks all pistons to run.

Hope this helps most folks here get past the looooong delays and failed time schedules.
I noticed one of the main culprit that I have is the Underground Weather - I have it update along with some lights changing colors. I think it should have it’s own littl’ ol’ piston. It’s an underlying HTTP request that depends on an external service that may or may not work all the time…

I gotta be honest, this is the best time to code/test. With so many failed time events, I can easily (and empirically) find ways around errors :wink: Love it :slight_smile: (not being sarcastic this time)

8 Likes

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.

2 Likes