Capability externalAlarm / tri-state switch

Lets start this off by saying I’m not sold on the capability name of externalAlarm, but figured it could start the conversation.

The use-case is integrating with external alarm systems (such as SimpliSafe) that have 3 states: [off, on-home, on-away]
The significance of the two on states is different per configuration of the alarm system, in my case ‘on-home’ is for no motion sensors active and different siren delays.

I have a first pass at an integration example that I’m using today for SimpliSafe - - where I’m overloading the current Alarm capability (meant for siren/strobes).

I haven’t yet built the function calls integration to set the 3 states because there isn’t a clear winner for what the right capability would be to do that.

Isn’t this a perfect use case for using the ST’s built in modes?
I do not have an alarm integration, but using modes is exactly how I keep the cat from triggering motion lighting when we’re away.

I’m new to ST, so please correct me if my understanding is incorrect …

The modes seem like they dictate a high level state for all of the sensors and define how they should behave. Each sensor still needs to expose capabilities that that you can then map to react in different ways based on that state.

The Capability Type request here is to define something for this external alarm device type, that we can then wire to react to changes in Mode, or other things.

Love to know your thoughts, or if I’m missing the boat.

smartApps are the functional glue that allow devices to interact with each other.
Modes function as optional on off switches or conditional branches within smartApps.
You can have one or more smartApps that interact with the same devices, but provide a different functions depending on the active mode.

Makes sense, so continuing with what you outlined, doesn’t the device need to then expose one of the accepted capabilities for the SmartApp to take action?

SmartThings will look at one device at a time to get information based on the capabilities of that one device.

Another controller, like the security system, is a whole separate issue.

But in terms of each end device, if smartthings is able to talk to it, it likely does NOT reflect the three states you mention. Rather, a contact sensor is on or off. A motion sensor is active or inactive. A lux sensor reports a range of values. And so on.

If these end devices are certified zwave or zigbee devices, then their capabilities are defined in terms of those standards, and are self reported regardless of which controller queries them.

Some devices, like locks, may have more capabilities such as a tamper code, but each is still reporting based on the standard to which it is certified.

So as far as your 3 states: off, on-home, and on-away, that sounds more like a system state held by the controller of that system, not something that can be exposed at the individual device level. The motion sensor itself doesn’t know the difference, rather the controller handles the reports differently based on the system state. So that parallels modes.

Or did I misunderstand the kinds of devices that would expose the capability? For example, if SmartThings in fact does not talk directly with the end devices, but rather goes to the controller every time more like a web service, AND if that security system has zones, so that some sensors might be on-home while others are off, then it would make sense to give the types for the end devices the virtual capability of armed, but it would have to be reported by the security controller as the individual device likely doesn’t know its own state in that sense. All of the devices owned by the security system would be child devices to the security panel parent.

For the most part yes, however if you are making a custom device, and a smart app to go along with it, You can create custom capabilities and attributes, which you can use in your smart app. The custom stuff won’t be available unless you write a custom smart app to go along with it.

1 Like

Since “Capability” is special SmartThings terminology, I recommend being careful with this word.

SmartThings currently does not allow the creation of custom “Capabilities”; however, you can create custom Attributes and custom Commands.

A “Capability” is pretty much defined by its list of Attributes & Commands, so you are almost creating a custom Capability, except that you can’t name it or refer to it by name in methods like “preference{ input() }” and others.

Old ST documentation said we could declare new Capabilities on the fly, but it was wrong or deprecated.

1 Like

@JDRoberts You are correct that this is a completely separate controller in the security system, with its own configuration and state handling. It is accessed over webservices (you can see the Github link I shared for what I have so far), but that controller can just as easily be exposed as any other ST compatible device that exposes its own attributes and commands.

Some alarm systems expose the individual sensors themselves and their state (which we can map to existing capabilities), but the ask here is whether it would be worth creating a new Capability that maps to what seems most alarms define as their primary 3 states (at the controller level).

1 Like

I see, that makes sense. Yes, in that case I agree that the three state capability would make sense. I think it will be clearer to other people in the smartthings context if you talk about the control panel having those state rather than the end devices, though, just so they don’t get confused the way I did.

(I am quadriparetic, and depend on a text to voice reader. So I can’t review code or code blocks easily, particularly groovy code.)

1 Like

My instinct is “yes”, but the problem is that SmartThings hasn’t created any new official Capabilities based on Community recommendations yet. So we don’t know what level of granularity, etc., will become customary or best practices.

If you would like to think about the Capability topic in theory, please feel welcome to read my long post…