CoRE and Piston Rules Engine, first design steps

I may be mistaken, but I think you already have the basic grouping for lights, as it’s really one of the simplest rules.

Turn on

A list of lights

When a switch is turned on

Specify that switch

The only other thing we need that you might not have is a clause like the one in smart lighting:

Turn off as well. (this has to be optional because sometimes you won’t want them to turn off when the master turns off.)

That groups the lights. You can either pick one of the group as the master, or you can assign them to follow a virtual switch. The rule works the same.

But notice that this is super simple: the only thing it matches is on and off. Not set level or color or any other Device capability.

I think it’s likely that people will have existing groups that were created in other smart apps and are tied to a virtual switch.

But unless I misunderstood something, you’ve already given them the ability to create a simple group of the “follows master” type. :sunglasses:


Of course he is. Leave it to @JDRoberts to pour wisdom into a topic…

But like he said, my case is not everyone’s case :slight_smile: I still believe one can easily do away with VS and that actually VS add unnecessary points of possible failure more so than a physical device…

1 Like

I guess my understanding of grouping is a bit different. I am talking about a multi-way sync, where if any of the devices turns something, all the others follow. Say, you have zwave dimmers in the wall, you turn the light on in the living room, all others turn on, but if you turn the hallway lights off, the others should follow. In this case, you don’t even need a virtual device, an app can “link” them together. Bind them, if you may. This can be done in a rule, especially with the local variables:

If any of [blah blah blah]'s switch changes, save the event value into variable @whatever, action Set [same list]'s switch to @whatever. A rate limit should be placed on this rule (when developed) to avoid unnecessary events while turning those lights on/off.

This is where an optimized app that only does that would make sure to not trigger further actions as a result of its own changing of lights. That’s why I said, a specialized app can make things easier for both the UI and the ST.

You may have already meant all this, but just for clarity, it’s important to note that If they all follow each other all the time, it’s really hard to put a device into two different groups.

Say I have a hallway light. It’s at the base of some stairs. I want to put it into two different groups.

First, it’s in the downstairs group which includes the entry area and two of four lights in the living room. This is the " entry" group.

Then I have a pathway of lights that I call “bedtime.” It includes the hallway light at the bottom of the stairs, the hallway light at the top of the stairs, and a Bedroom light.

And then I have yet a third group called “living room” that has all four of the living room lights in it but does not have the hallway light.

Three groups. Each can be independently scheduled, and independently triggered. I could have a Contact sensor on the front door turn on the Entry group.

I can have a motion sensor in the living room turn on the living room group.

I could have voice activation turn on the bedtime group.

What I don’t want is to have turning on the hallway light automatically turn on the two living room lights and the upstairs bedroom light.

Based on tons of work done by Apple, and practical if less comprehensive work done by most other home automation companies, humans tend to think of device groups in terms of what Apple now calls “service groups”–Devices which are grouped together for a specific purpose, but which may be in a different group for a different purpose.

This is why most home automation systems now distinguish between “rooms” (based on the physical location of a device) and other types of groups, which could be based on device class (“all lights”) or on A specific use case (“Good night.”)

Of course if you’re changing the settings of a specific device through physical manipulation at the switch, then you’re probably stuck with one group for that purpose, which is probably what you meant in your description.

But once you allow for Settings which are changed in other ways, even just by voice, then a device can be in multiple groups, so it’s better to have a virtual master concept even if that’s just presented in the UI as changing the characteristics of the group (in that case The group name is standing in for a virtual master).

So again, that’s probably exactly what you meant, which is you were referring to groups where The settings are physically changed at the switch. But of course there are many use cases where that’s not necessarily true. :sunglasses:

Yeah, switch binding would not allow for multiple groups. It all depends on the needs. If I had 4 mood lights in four corners of a room, it may be practical to “bind” them together, switch, level, color and all, so you don’t have to keep changing all of them in all the rules. I am not going to impose any artificial limits on anything, so virtual devices or not, they should work just fine.


Yep, there is already a SA for Grouping Devices created by @Kriskit

Trend Setter - A SmartApp for grouping devices
[RELEASE] Trend Setter

1 Like

Since SmartThings supports both Zwave and Zigbee, speaking just for myself I prefer not to see the terms “association” (a specific zwave term) or “binding” (a specific Zigbee term) used outside of those contexts, as it can get totally confusing for those of us with a network engineering background. Or anyone reviewing a feature list while trying to select devices for their home. (The obvious “does not support association” springs to mind.)

It is not possible to bind a zigbee switch to a Z wave switch from a zigbee point of view. And saying you can bind one zigbee switch to another zigbee switch has a very specific meaning for the manufacturers of those devices. So it can just lead to a lot of confusion. :sunglasses:

“Synch” is a good general-purpose term for multiprotocol systems, as are “link,” “group,” and “follow.”

Ok, this is a great discussion. But isn’t the most basic use of CoRE really nothing more than an association (grouping) app?

If this (something does something)
Then that (something else does something else)

Also known as, Trigger and Action.

It really doesn’t matter how many triggers you have, whether they are real or virtual, or how many actions you have, also without concern to real or virtual.

The app is just a super fancy cause and effect machine.

No, because the Trigger isn’t limited to event activity on another device.

Still cause and effect.

Cause-and-effect, yes. “Just” Grouping, no. :sunglasses:

As an example, One of the most popular basic rules is “turn light A on at sunset.”

One trigger, one action, absolutely. But I’m not “grouping” light A with sunset. I might be putting it into a “sunset group” but that’s a different data model. Sunset itself is a trigger which is a schedule. Not a device event.

It’s easy to see the difference when you think about what the network controller knows. What would be the “device ID” for sunset? It doesn’t have one because it’s not a controllable device. But in a device group, each device in the group does have a device ID. :first_quarter_moon_with_face:

There are certainly basic rules which are essentially just groupings. But they’re also basic rules which are just schedules.


Just as a side note to all this VS conversation. I use them quite a bit for groups of lights mainly because I have tablets on the walls running SmartTiles. I need one tile (VS) to control groups of lights in various areas. I don’t think I could reduce the number to 0 for this use case.

1 Like

That’s true. But I still say I’m right and you’re wrong!

1 Like

More stats for the nerdier ones:


I want to see the nerdiest one! (I am sure you’ll come up with a more detailed one, cannot you :slight_smile: )

Under Rule Engine, maybe adding a total count of Pistons?

1 Like

I know there are likely UI limitations that may prevent this… but some way to organize, group, etc the rules or pistons… if at all possible. I only mention this because I see some really creative solutions coming out here. Certainly not nearly as important as the functions.


Very good ideea, will see about it. Got tired of working on time filters and events, so I digressed towards performance counters. lol


Like so?

NOTE: the average event delay is off because no data was collected for much of the 98 evaluations.


You do realize I now want to aggregate the event delays across all pistons for the last hour or so and put that in a variable that can more or less give an idea of when ST has problems, right?