Smartthings Rules, Triggers, Conditions

I am looking for how ST handles triggers, conditions that fire a scenes. I am coming from a Tuxedo environment. I loved it integration on the security vs HA. It only supports z wave, and with all the z wave devices that it not too bad, but it has really basic support for devices. Basicly it supports alarm faults, garage door, thermostat, water, and simple binary switches. For example it does not support multichannel binary switches.

I am moving into a new house and will have a clean slate for both security and HA.
After studying the STNP (Smartthing Node Proxy), looks like I can still use a monitored Honeywell security and glue it to the ST. Also, I like the idea of adding a plugin to the STNP for foreign devices. The way STNP adds a somewhat “offline” capability.

I going to ask some real generic questions to help me learn ST terminology and to build context for more specific questions…
I would like to better understand what triggers there are besides manual (app or voice). For example timed triggers? Sensors, for example security faults coming from the STNP/Alarm system.

1 Like

You will want to spend some time reading about CoRE. It is a community developed app.

You can trigger off of…

sunset / sunrise
wet / dry
…the list goes on…

Yep, that is what I am talking about. So CoRE would run on the same machine as STNP in it’s own process? So, it’s “rules” will be evaluated even if internet is down? Cool! I did a quick scan of the thread and read the wiki. The first post said beta, I assume it is still beta? I love the fact that it is community supported.

If the internet is down, CoRE will not work. It doesn’t run locally. SmartLighting has some of these features and it runs locally but not at robust as CoRE.

1 Like

This should help as a starting place. ( this is a clickable link.)

And as others have said, right now core gives you the most options, particularly stacked conditionals:

So as long as we are talking about Z wave, zigbee home automation, Devices with IFTTT services/channels, or cloud services with open APIs, there is very little that SmartThings can’t do in terms of accessing the features of those devices.

However, most of the SmartThings architecture is cloud-based, and it doesn’t run particularly reliably.

The company is very aware of the reliability issue and has made improving that a top priority, they just aren’t there yet.

But for flexibility and versatility, it is certainly a leader among low-cost systems. And that includes the available triggers and rule sets.

1 Like

Thanks @whoismoses and @JDRoberts. I am getting a better picture of ST. I was thinking of it as a controler kind of like Tuxedo, but other than SmartLighting, it is more of a bridge. I equated more to a bridge than a hub since there is some translation to the device. If I am understanding it right, Smartapps run in the cloud and I am thinking of it as a scripting language. Since CoRE is a “Smartapp” hence the cloud. This is more of a question for STNP Link to my STNP thread question., I wonder if a STNP plugin could be written in such a way as to publish a “virtual switch”, let it do some If/Then logic, turn on/off the “virtual switch” then let SmartLighting control the devices. Not saying it is worth the effort, just if there was some sort of mission critical operations. Just thinking out loud. :slight_smile:

From a network engineering standpoint, for technical reasons the SmartThings hub is definitely a hub and not just a bridge. (You will find discussions elsewhere in the forum about the difference between a hub and a bridge in this context.)

However, from a customer point of view it is a black box hub because customers are not allowed to load any code onto the hub. At all.

( this is where many people who have a technical background get confused, because they think they are buying a customer – accessible CPU with server capabilities. Sort of like a preloaded raspberry pi with a home automation stack. But they’re not. They’re buying a black box hub which is part of a cloud-based architecture.)

Smartthings itself is not the hub. It is a cloud-based platform. Customers are allowed to load code into their cloud account. This can be code that they wrote themselves or that they copied from other community members or that is available to load from the “published” library that you can see in the marketplace section of the SmartThings mobile app.

Once the code is loaded into the customers cloud account, it runs in the cloud, and some of the output of what runs may be sent to the hub device at the customer’s home. But it’s entirely possible to run a smartapp which never send output to the hub at all.

Meanwhile, the hub and the cloud talk to each other regularly and exchange information, independent of anything that any smart app is doing. Colloquially, we would call this housekeeping. It’s what keeps the status of devices in sync, let’s the cloud know if the hub is off-line, and some other stuff. But none of that is accessible to customers, it just happens as long as the hub is signed into the cloud account.

The SmartLighting Exeception: Local Execution

SmartLighting is an official feature which is unusual in that it specifically has been loaded into the firmware of every hub device and consequently can “run locally.” However, the hub is still a black box device. The customer cannot access it locally or make changes to smartlighting locally.

Instead, the customer makes changes to smartlighting in the usual way, in the cloud, and then that gets sent by the cloud to the hub for local storage. If the cloud is not available, for example, there is no way to change an existing smart lighting automation. It will just keep running with the old parameters.

So “run locally” in this case literally means “execute locally,” there’s still a required cloud component to set up a rule in the first place or make changes to it.

There some discussion of the SmartThings architecture in the developer docs and it’s worth taking a look at. But the Main thing to remember is that code that you write is going to run in the cloud. It’s the outputs that may get sent to the hub to act on if local device control is needed.

I’m not following the other thread (I rely on text to speech these days, so I can’t read code), so I’m not quite sure what your question about virtual switches means, or if it’s something specific to a particular integration.

For others who might Find this thread in the future since it has a general topic title, I’ll just mention that one of the most powerful features of smart things in terms of integration is that it does have the ability to very easily create virtual devices, including several different kinds of switches. Community members often use these for integration with IFTTT or Echo or Google Home. Virtual switches can also be used to create virtual timers.

I have a feeling that what you’re asking is something much more technical, but just as a general comment, it’s easy to create virtual switches through the cloud platform which are then treated like any other device on your account. Here’s the FAQ for that.

And here’s a common example, where a virtual switch is used to allow echo to change the mode or run a routine.

And since I brought it up, here’s the how to article in the community – created wiki on creating a virtual timer:

However, all of these examples are creating virtual switches in the cloud which will be accessed through the cloud.

As I said, I have a feeling that you were asking about something which could be created without the cloud, and that’s a whole different concept.