CoRE and Piston Rules Engine, first design steps

Yeah. More stuff.

v0.0.08a.20160612 - Alpha test version - Improved loop logic, providing the $index variable for simple loops and ensuring variable value during execution stage. Improved variable triggers during preauthorization.


XYZ output for drones… I have a couple of drones which I want to start flying in random XYZ positions around my home when ST is set to AWAY mode and when SHM armed. Now all I need is a small replica machine gun to be attached to the drones… :grinning:

With the rate CoRE is progressing, I am confident we will reach 22nd century very soon.


Life support drones only. Seems legit.

Love the adding of features but please keep a focus on intuitiveness too. Some of the best programmers I’ve seen can go overboard.

I love CoRE, keep rockin it Adrian.

1 Like

Why use a replica?

With a fully armed drone… It is life support…

Any chance you can move the main “Remove” button to another page.

I had about 10 test pistons to delete and after about the 8th one I hit the wrong Remove button and lost everything. :sob:

Sorry about that. Already moved it, but not published yet. Working on the … drum roll… three axis.


I only had a few good ones so it’s not that big of a deal, but thanks for moving it and fixing the looping index.

v0.0.08b.20160612 - Alpha test version - Added three-axis initial support.

Use the “facet” attribute :slight_smile:


Hint: to remove a piston, swipe left on the piston in the piston list. A remove button appears… A lot less scrolling…



Wondering if this is intentional…

There is no way to select ‘All’ as the evaluation mode when the comparison is using ‘stays’ with two motion sensors.

And this seems to be always true and doesn’t turn false.

Intentional. A trigger marks an event. You cannot have two devices generating an event at the exact same time, hence the forced OR. If you would be able to select All (AND), it would never be true.

1 Like

Awesome, thank you for the threeaxis support! I am however having some trouble with this.

On initial setup of the 6 faces of my color cube, all but 1 orientation (right side up) was detected correctly, but when the cube was actually right side up CoRE was reading it as down side up, and CoRE was also reading down side up as true on the same evaluation.

This got me thinking that the “faces” values were probably hard-coded X Y Z ranges, and that perhaps my orientation sensor was slightly out of bounds of the ranges you pre-defined. Is that how you’ve set it up?

Not to be deterred, I opened the live logger and started looking at the X Y Z values my cube was putting out. I was actually able to isolate some unique X Y and Z ranges that I could plug into CoRE that have so far resulted in 100% operational success and color consistency. So that’s a win! But obviously more involved than just choosing a “face” value.

I did run into one small bug - the X Y Z values of my sensor can exceed ± 1024, but CoRE can’t exceed those values (gives me an out of range error). Is this intentional, and could CoRE be updated to accept larger (and smaller) values than ±1024?

Also, I noticed with my Hue DTH (Hue Lights and Groups and Scenes Oh My), the set color command in CoRE sets the correct color, but only sets the level to 67%. Is this intentional behavior on CoRE’s end, or an issue with the DTH? I would (personally) prefer that set color always use 100% as the brightness. In most of my other automations this behavior isn’t a problem (I can simply ask CoRE to set color then set level 100), but when rotating the lighting cube the sensor inside will often send 3-4 slightly different X Y Z axis changes to SmartThings before it settles down, which causes CoRE to run set color and set level 3-4 times, which makes the light levels bounce between 67% to 100% however many times the in-range X Y Z values are reported by the threeaxis sensor.

To solve this I considered using set color with RGB or Hue, Saturation, and Lightness, but I realized I don’t know how to get values for these settings that CoRE understands, since my DTH for my Hue Lights doesn’t appear to output those values during Live Logging. Is there a color list you’re using to get values that are compatible with CoRE that I could use?

Anyway, in full faith of your coding abilities I straight up deleted the Mood Cube app I was using. And there’s nothing stopping me (I think) from capturing my color lighting states to global variables and then calling those states to get the color and level I want. I think it’s utterly amazing that I have 3 or 4 different and viable ways to solve my problems, and it’s a testament to your skill that CoRE has come so far, so quickly. Thank you again for your incredible support of this community!

Face is determined by the prevailing axis. I look at absolute value of each of the three axis and pick the highest. That determines the face pair (front/rear, left/right, or up/down). Then the sign of the value of that axis picks the facet from the pair. Negative is left, positive is right. There is a flaw to this, if the cube is laying perfectly flat, one of the axis should be at its negative or positive max. But if the cube is not perfectly flat, you won’t achieve the max value, and then if you rotate the cube around its base, one other axis may reach a value higher than the one I am expecting, causing a wrong side to be detected. I’ll look into a more “precise” algorithm tonight, that’s all my brain could come up with at 10pm on a Sunday :slight_smile: Guess I need to get inspired by external sources :wink: Rotate the cube around its base and see if the face is detected right.

As for the color, level is part of it. To get a variation of bright red vs dark red, lightness plays a role. Try entering the hue, saturation and level manually, instead of picking a color. Hue is 0-360, Saturation is 0-100, Level is 0-100. H/S/L 0/100/100 should be red (hue starts at red/0 and goes around the whole spectrum arriving at 360 which is red again).

Also, use triggers, facet changes [to …]… this will ensure you’re filtering out all those intermediary positions.

NOTE: facet will change to orientation

Before I do this manually :wink: to a bunch of RM rules I want to check that it didn’t get integrated somewhere in the 3400 posts!
RM could dim by mode in one command, can CoRE do this or just resort to IF THEN ELSEIF stuff?

Any examples to help start with IFTTT + CoRE? I have enabled the integration… already an IFTTT user : )

Hi, I can’t seem to get the “OR IF” to work on this Piston. It skips right to the Else portion (ignore the actions on Else for now).

I use it with IFTTT to make things happen when I arrive at work based on a ST virtual switch and IFTTT location. It’s handy because I don’t have to worry about sick days or other weekdays when I don’t go to work.

Sorry, I forgot to check the IDE live log last night when the piston turned off the fan. I looked this morning and again there’s no schedule set. I attached a screen cap of the Scheduled Jobs and Job History.

Dashboard appears to be broken in the latest update for me. I can view the main page that lists all Pistons, but get no information when selecting each piston individually.