CoRE and Piston Rules Engine, first design steps

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) ???

1 Like

This makes more sense in my head, thanks. I woudn’t change the name though, it’ll only confuse people further.

Agree 100%. It can just be left blank if not needed.

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?

Nope. It’s essentially the same as IF (condition) THEN (actions) ELSE (do nothing). Don’t need to reinvent the wheel.

1 Like

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.

Agree don’t make the change

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.

Is there a type of refresh in CoRE. I would like to refresh my weather stuff since it has a hard time keeping up to date.

Try Pollster

already do that but I would like to be able to keep it to one program. I think RM had a command refresh. Dont remember though.

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} :slight_smile:

There is a Refresh command in CoRE too. Also Poll. All standard commands are supported. All custom commands are supported too.

1 Like

Too late, I already added the Basic Piston… It’s so basic that I may actually use it :slight_smile: NOT.

IF (conditions) THEN (actions)

4 Likes

OIC

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

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.

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?

  1. If any one of three presence sensors are present, set cooling temp to XX.
  2. If no one is present, set cooling temp to YY.
  3. If any of the four contact sensors (doors) are OPEN for more than x minutes, set thermostat to off (regardless of any presence state).
  4. 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!