How to add a new device "capability"?

Devices & Integrations
1

According to the documentation found here: https://support.smartthings.com/hc/en-us/articles/200901360-Device-Types-Capabilities-Attributes

How?

2

I have given you bad advice before, so let me do that again…

I don’t think you can add a new capability. I know the documentation says:

You can add a custom capability to the platform yourself, and we will then look for common threads across new custom capabilities in order to determine which ones should be made part of the standard taxonomy.

You can specify custom actions and custom attributes. Since it says in the documentation

Capabilities themselves may decompose into both ‘Actions’ or ‘Commands’ (these are synonymous), and Attributes

If you add custom actions and attributes, it is like adding a custom capability.


metadata {
    definition (name: "Some device") {
        capability "Switch"

        attribute "customAttr", "number"

        command "someCommand"
    }
    ...
}

Hope that helps.

1 Like
3

There’s one huge gap with not being able to actually create a capability: The ability for a smartapp to retrieve a list of devices supporting a given capability.

BTW, do you know how to create a boolean attribute? ‘attribute “something”, “boolean”’ doesn’t work. (Also tried/failed with just “bool”)

4

That would be a problem of not being able to author a capability.

Oh you want boolean values, yeah, that is a pain. They seem to be broken as a type.

I found out that if you specify a preference type as a boolean, the value is “true” and “false” but they are really strings! You can call toBoolean() on the string to get the boolean value back out of them though.

That is 45 minutes of my life I want back right there figuring that out.

1 Like
5

okay, I just modified the custom device type I have for my door lock to have a couple of custom attributes. I can actually subscribe to those from a custom smartapp… that solves one of the small issues I’ve been fighting with.

Of course, that also opens a MASSIVE can of worms. If I put out a device type with a custom attribute of “alarmType” that reports the type of alarm CONFIGURED for the type, and then someone else writes a device type with an attribute by the same name, but reports the type of alarm actually sounding…

I guess those custom attributes should be very clearly named. Perhaps using a username or something. So… “garyd9_alarmType” instead of just “alarmType”.

6

That could be a problem.

For the Z-Wave devices, the attributes are loosely defined as properties of the command class (see the Z-Wave Utility Reference). I guess the capabilities are a way of trying to find commonality between Z-Wave and ZigBee.

Again, this is me reading the tea leaves of SmartThings developers though the code they have chosen to show us. I could be wrong.

1 Like
7

Hi guys… Great topic!

This is something I’ve brought up in discussion with @Ben ages ago, and with @Jim very recently.

I actually thought that arbitrary new capabilities could be created on the fly just by naming them in the "metadata{}' section, but …

So – it looks like at least a little involvement is required from the SmartThings side to update the master list in this situation.

But importantly…

(Theoretical / platform discussion moved to New Topic. Sorry for the initial intrusion.)
…CP / Terry.

9

The real answer? The real answer to what? That’s not an answer to any question that was asked. It’s an opinion that doesn’t take into account the reality of the situation. It’s theoretical. The reality is that I need to write a device type that has attributes and commands beyond what is provided for in the existing capabilities, and there doesn’t seem to be any form of inheritance available.

In fact, any class creation is forbidden by ST (http://docs.smartthings.com/en/latest/introduction/groovy-the-smartthings-programming-language.html#groovy-sandboxing)

Please, please, please stop hijacking all my dev related threads with theoretical “would be nice if” discussions.

So, while I KNOW you want to have a discussion on changing the architecture to support (fill in the blank), can we keep it to what can be done today with the existing architecture, restrictions, etc?

Gary

10

Only one capability I am interested in:

capability.worksAllTheTime

Can this be achieved?

3 Likes
11

I apologize … I will edit my contribution and spin-off to a new Thread (“Linked Topic”).

Best,
…CP / Terry.

12

Short answer: No, you can’t create capabilities at the infrastructure level. You can only create custom attributes and custom commands

When you’re posting on the community forum, you should expect opinions, since you’re asking the community for an answer. You’re probably better off directing the question towards SmartThings staff directly like @Jim or @Ben if you’re looking for an answer from SmartThings staff. You should bring up this topic during the bi-weekly developer’s meeting. Next one is on 1/28/2015.

1 Like
13

While I tend to agree, I’ve posted 3-4 topics asking development related questions on how to do things in the existing code. In each case, the same person has responded with theoretical discussion that, to be honest, is not an answer to the query, is only loosely related to the topic, and does nothing but divert the thread elsewhere.

It’s to the point where I feel as if this person is stalking my threads with the intent of only talking about theoretical stuff that simply isn’t possible in the existing system provides. The only way I know of to deal with that is to politely ask them to stop.

And now I’m defending myself for trying to keep a topic… on topic. pfft.

14

It’s not you Gary D; It is just coincidental that you’re encountering real-world examples that overlap with my theoretical imaginary wishful world. Definitely nothing personal – I hope that you can accept my apology for not being helpful.

BTW: I’m stalking everyone’s threads, of course! :smiling_imp:

Sincerely,
…CP / Terry.

3 Likes