We’re talking about Else. Define “piston should not run”. Are you suggesting the Simple piston should not have an Else? I think that Else adds a lot of value… and can be easily ignored if not needed.
Should I add a Basic piston? IF (conditions) THEN (actions) ???
Given that a “normal” piston will evaluate on a change to one of its conditions, but a Follow-Up piston won’t, this could cause a lot of confusion. How will a user distinguish between these two kinds of pistons?
Do you mean in the list? The dashboard shows the type in front of the name. The UI does not give me any room to play with extra info… it builds the list itself… They could put it in the name of the piston, I guess?
Yeah, in the list. If I’m staring at a piston I created 3 weeks ago, I may not immediately recall the context in which it’s supposed to be used, and if it’s not firing when it “should”, that would be a head scratcher.
This is what you would recommend for controlling a group of physical bulbs using an appropriate virtual bulb, yes? If so, I’ve got a bunch of use cases that I can play with this weekend.
No. That won’t work. If you use the local/global store, each device has its own state. So you’re only reverting the device to a previous state. If you want to “group” devices together, that’s where the “Save attribute/state to variable” comes into place. If it’s only one attribute you want to “group”, use the Save attribute to variable on the source device and the Load the attribute from same variable on destination devices.
IF you want to allow multiple devices to control the whole group, you can also use the $currentEventValue to load the attribute into the group - if done properly (only run on a trigger of any of those lights changing), the $currentEventValue should contain the new attribute value of the light that just changed. All you need to do is just Load attribute from variable {$currentEventValue}
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
2575
This is a known bug on the Android version of SmartThings, but since they don’t publish a bug/issues list, you’d never know…
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
2576
Yes, this would make the app a lot more user friendly. Not everyone needs out wants the complexity. Sometimes they just want to turn a light on when the door opens, and that’s it.
I think adding that and keeping it just an if-then (keep all of the tools in it) would be a bonus to the app.
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
2577
I agree with this as well. You’ve given do so many powerful optionfeaturesyed and choices… NoNote we just need a simplistic and painfully obvious choice to not choose.
I have a few basic pistons up and running but I get a bit lost in the weeds when things get more complex. Can someone help me with what I want to do here?
If any one of three presence sensors are present, set cooling temp to XX.
If no one is present, set cooling temp to YY.
If any of the four contact sensors (doors) are OPEN for more than x minutes, set thermostat to off (regardless of any presence state).
Thermostat comes back on and goes back to whatever temp setting it should be once the doors are closed for 30 seconds.
Any help would be appreciated!