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

This is something that I’ll look into in the near future. Not there yet.


I would have a time trigger at 10pm to set a variable to a value, either 0 or 1, or whatever you fancy, I’ll pick 1 for “enabled”.

  Time trigger happens at 10 pm >>> when true >>> set controlLight = 1
  OR (
    Motion changes to active
    Variable controlLight = 1
  ) >>> when true Using light, turn on
  Ask Alexa Macro "whatever macro turns the light off" was executed >>> when true >>> Set variable controlLight = 0

This should do what you need.

Piston restrictions prevent a piston from evaluating. An action restriction prevents the action from being scheduled.

The piston has three stages: Evaluation (when comparisons are made). Scheduling (when actions are decided and put into a queue). Execution (when actions queued during Scheduling are actually executed). Piston restrictions prevent all three stages. Action restrictions apply to the Scheduling stage.

1 Like

Thanks for the quick response on both my questions. That helped clarify things. Now I’m going to go play around and try not to tick off the wife .Lol


Sweet! As much as I like all of this making bulletproof rules is seeming a bit tough, so I’m sure some solid ones are being generated by people with time to look into it more so it’d be nice to share anything decent I create too. Thanks so much @ady624. Good luck!


Hey, share what you make over here!

1 Like

We need a ‘show and tell’ thread. Keep the peer thread for building advice.

Fine! Be that way!


I wonder what is the best, most efficient, way to manage a switch. Simple use case: Assume a motion detector controlling a Z-Wave wall switch with several minutes of motion. Motion Active turns the switch ON, then Mutton Inactive turns the same switch OFF.

Is it better for the platform and for the switch, as something of a mechanical device, to repeatedly send an ON signal to it during the time of continuous motion? Or is it better for the piston to query the switch status and only turn it ON if it is OFF? Alternatively, how about setting a local piston variable to reflect the switch state and then check the variable state before turning the switch ON?

I too am torn as to which is the most efficient way to turn on a constantly toggling sensor and turn off after delay. As I am not the programmer I can’t say how much evaluation is going on for no result. I think that what you suggest in you second paragraph is already in place as the LATCH variant of the IF THEN.
i assume once this is latched in there is very little processing until a false redirects to the BUT IF.to reset the flip flop.

45 days into development, CoRE has reached BETA. Milestone 1 is all about optimizations, consolidation of existing features, optimizations and did I mention… optimizations?


Yahoo! Great job!

Where are the Release Notes for Beta Milestone 1? You should be used to this community by now… :joy:

Will write them in the morning. Movie time.


Congratulations! You worked unbelievably hard on this. Great work…

Now let me pick on you…-:slight_smile: Can you delete the extra u on the IFTTT page


Shhhhh! Didn’t you hear? It’s movie time! :wink:

1 Like

Did you mention documentation?

1 Like

How are you guys/gals setting variables?

@ady624 Can’t get Runtime Statistics to open, just get spinning wheel and then it times out and nothing happens. Been happening since approx 082, i think. I don’t often go into it so am unsure when it started. Am now on 1.090. Is it a CoRE issue?

Okay, I’m starting to feel like CoRE is beyond me, LOL. I just went to update to the latest version and I only show a version under the Obsolete section, nothing under the Conflicted or New. What the heck am I doing wrong?