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.
4 Likes
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ā¦ 
With the rate CoRE is progressing, I am confident we will reach 22nd century very soon.
4 Likes
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. 
Sorry about that. Already moved it, but not published yet. Working on the ā¦ drum rollā¦ three axis.
3 Likes
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 
2 Likes
Hint: to remove a piston, swipe left on the piston in the piston list. A remove button appearsā¦ A lot less scrollingā¦
5 Likes
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 Guess I need to get inspired by external sources 
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 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.
3 Likes