IIRC, we had a discussion on this in one of an early CoRE thread. I think it’s Adrian’s intention to make it selectable this time around 
1 Like
4 Likes
You would have to rewrite all your pistons, the backbone is completely different for the SE version. Streamlined Edition 
In a SmartApp, all configuration is stored in a collection called Settings. CoRE (main app) will use that just like any app does. But the pistons, they won’t use it at all. That’s what allows me to be flexible. SmartApps cannot write into Settings, they can only read from it. The ST UI can write into settings which is what forced CoRE to use the UI.
I have something better in mind. It’s called… copy & paste so you can copy a whole section of a piston and paste it into another. How’s that for flexible? Oh and duplicate piston, not a problem.
10 Likes
oooooo …,. I LIKE THIS … LOL
OMG. You are the man.
Now… how do we get you installed into the top seat at SmartThings?
2 Likes
Who’s good at writing stuff? I need a short explanation in layman’s terms for each of the possible statements I have so far:
action (the task executioner LOL)
if (basic conditional block, allows unlimited else if concatenation and one else block)
switch (allows selection of statement blocks based on value matching)
for loop (executes the statements block a given number of times)
while loop (executes the statements block only if the condition is initially true and repeats until condition is false)
repeat loop (executes the statements block at least once and repeats until condition is false)
break (exits the current statement block)
return (terminates the current execution)
These are displayed in the statement edit dialog as seen above in a few pictures.
Thank you
Being a good programmer does not make one a good leader
2 Likes
Based on what I’ve seen so far, it would be impossible for you to be WORSE.
2 Likes
2 Likes
So I’ve been debating myself for the last two weeks now on what’s the best way to do things.
Triggers and conditions are cool and they allow flexibility, but are quite cumbersome to grasp for most.
An alternative I’ve come to like is by extending restrictions on all objects (conditions, statements, and tasks) to be a full fledged “conditions” collection. And call it “when” - because “while” is taken.
Imagine this:
if
Front Door opens (note the "changes to open" is gone)
when
Adrian is not present
then
with
Location
do
Send a message to Adrian to let him know someone's opened the door
end with;
else
with
Location
do
Send a message to Adrian and tell him the door closed
end with;
end if;
in the above example, Adrian arriving or departing would have no effect on the piston. However, the door opening or closing will cause messages to be sent out. In effect, the door is a trigger, Adrian’s presence is a “condition” - called a restriction in CoRE SE. In old CoRE, this would have to be:
IF
Front door changes to open
AND
Adrian is not present
THEN
Using Location...
> Send notification of someone opening the door
ELSE
Using Location...
> Send notification of someone closing the door
They’re both doing the same thing, but the second one uses “triggers vs conditions” to only subscribe to the door. Just a matter of how it’s explained, really… which one is easier for the non-programmer user?
And then there’s the THIRD way… give the option to the user to choose which conditions subscribe for events and which do not. On a one-by-one basis. This I feel is very complicated for the non-programmers as they usually don’t know what they want to begin with…
- Using triggers and conditions is circle/dot fun
- Using conditions and restrictions is the way to go, seems more fun
- Let me choose which of my conditions can subscribe for events and which not, I know it all, as usual
- Obviously, the best choice is using conditions and restrictions while letting me choose which conditions can subscribe and which not, because I love weird complicated stuff that no one will ever understand fully
0 voters
To me, the second (current) version is more intuitive for non-programmers; it’s the current ST-limited interface that causes the confusion.
1 Like
I foresee Piston creations as a service starting up. @bamarayne will charge $5 for piston creation, create it and then share it with you to use.
4 Likes
I’m not a huge fan of the current condition vs trigger way, it took me a long time to realize that conditions are triggers if there are no triggers, but when you add a trigger then a condition is no longer a trigger. I’m not a programmer but I’m familiar enough to be dangerous and I still find myself scratching my head on how to differentiate the two sometimes…
I suppose, because I am now used to how CoRE pistons work, I like the second method.
Having said that, if I was used to the first method and not the second method… you know what I’m going to say…
Also looking at the way you have written it above, the second one does seem clearer to me.
Having said that I’m not a coder/programmer so perhaps that is why.
What I will say is I’m a reasonably quick learner so whatever way you go I will adapt as I’m sure with all the others users will.
Lets face it, without this superb tool, ST automation would still be in the dark ages.
I kind of like this:
I’d recommend that you don’t let old CoRE dictate it 
what seems more fluid/easy to understand, think blank, no CoRE recollection
If I’m not mistaken, SmartRules uses something very similar, though they call it while? I can’t call it while because while is a statement keyword. Does the while loop
I believe there is a downside to the whole if-when thing, where triggers and conditions allows for a much more complex mixed mode whereas the if-when has a single AND between the triggers and the conditions. If anyone else feels the same, then I guess it’s going to be triggers and conditions… I’ll still leave the when in as restrictions (btw restrictions are now going to be full conditions - no triggers, you can restrict on anything you can put an IF on :D)
3 Likes
Makes sense, didn’t think about that part…
3 Likes
I believe we need triggers, conditions, and restrictions. LOL
The conditions for the while dictate when the while ends, but the when part dictates when the actions execute, not interrupting the while though. Makes sense? Or no one would ever use this?
The empty sections will disappear from the “view” mode of the piston.
The view mode would simply read:
while
Front door is closed
do
with
Location
do
adjustLevel
end with;
end while;
1 Like
The conditions would be the same as before, triggers and/or conditions.
The when section is really just restrictions. Non-subscribing conditions.
1 Like
I guess while cannot use triggers 
To me…that ^ is not intuitive, no matter how it’s written. I guess I have an inherent problem with wrapping my head around if-when. Is there an implied “and” between the if and when? Or is the when implied to be indented from the if, so that it acts as a condition once the piston is triggered?
(thinking as someone new to logic and looking at it written that way)
1 Like