Custom Capability and CLI Developer Preview

Hey there Mike. Did you get any takers?

If not, can you explain a little more what you need to do?

Hey! I have not yet. Thanks for reaching out. I can send you a PM explaining in detail.


1 Like

Feel like i missed something. This link and all of the other’s take me to a “We’ve Moved!” message.

Yes! There’s a new documentation portal, you can find it here:

Devices list > API | SmartThings Developers

Got it. Thx.

1 Like

A post was split to a new topic: Edit Sensibo integration

Is there any way to get a list display type to show the items in the order you put them in the alternatives section of the presentation json or is this a known issue? (iOS / Edge driver)

I used a custom capability in an Edge Driver and the order is correct in iOS and Android. Can you share your capability ID and presentation ID, please?

capability id: partyvoice23922.partitioncommand
vid: 57e26369-e7e4-320c-b5ab-54942fb5381d

ok, I was able to replicate the issue with your capability and a new one I created. I’ll report this, it doesn’t happen only for Edge Drivers and iOS. Thank you for bringing this to our attention.

1 Like

OK. Thanks for looking into it!

Hello - I need some guidance on the design/creation of custom capabilities for device details screen:

There are a number of stock capabilities that have some desirable UI elements that I don’t know if I can replicate with a custom capability. For example, the thermostatFanMode displays as a nice cluster of buttons, but if I look at the presentation json, it says it’s using a list display type. Well of course if I use a list display type in a custom capability I get a very different rendering (a single pushbutton that displays a text list to select from).

Other examples that I’d like to replicate are those that use an up/down arrow (temperature change) or right/left arrow. So for example to replicate a remote control that has up/down/left/right, with select in the center. Is there any way to have something like that rendered by a custom capability?

Is defining components part of the secret sauce?

1 Like

Some of the stock capabilities have a custom UI. Up to now, there are no options to change this UI for custom and stock capabilities (design, colors, font size, etc.).

I suspected that might be the answer! Can you elaborate on the purpose of putting capabilities into components other than ‘main’? What impact, if any, does this have on the way those capabilities (both stock and custom) are rendered on the device details screen?

Using components, allow you to have the same capability more than once. There are some devices (eg. Zigbee) that have different components (endpoints) which use the same capability such as a 3-gang switch. You can identify which element was actioned based on the endpoints and reflect the status in the corresponding component or vice-versa.

About the order, each component follows the specifications shared in the post below but it’ll depend on which capabilities you use:

1 Like

What is the recommended way to clear out (set to blank) a text string field? I’m unable to set an attribute to nil or ‘’ from an Edge driver; I can only set it to a blank character (’ '). I have fields I want to clear out each time a button is pressed, but that results in a bunch of undesirable changes being shown in history, and may also cause unwanted effects on automations watching the attribute. I’ve seen the use of {state_change = true} in some capabilities like momentary button, but don’t know if a {state_change = false} could be used or if it would help me eliminate the extraneous history changes or triggers of an automation when blanking a field.

Are you displaying this attribute in a specific display type?

Which undesirable changes do you mean?

How are you configuring your automation that is also triggered by this value? Have you tried to set something like - or none

Example capability:

    "id": "partyvoice23922.httpcode",
    "version": 1,
    "status": "proposed",
    "name": "httpcode",
    "attributes": {
        "httpcode": {
            "schema": {
                "type": "object",
                "properties": {
                    "value": {
                        "type": "string"
                "additionalProperties": false,
                "required": [
            "enumCommands": []
    "commands": {}


    "dashboard": {
        "states": [],
        "actions": [],
        "basicPlus": []
    "detailView": [
            "label": "HTTP Response Code",
            "displayType": "state",
            "state": {
                "label": "{{httpcode.value}}"
    "automation": {
        "conditions": [
                "label": "HTTP Response Code",
                "displayType": "textField",
                "textField": {
                    "value": "httpcode.value",
                    "valueType": "string"
        "actions": []
    "id": "partyvoice23922.httpcode",
    "version": 1

Every time you set an attribute to a blank, that gets listed in history.

I could set it to anything, but I’d rather be able to nil-out an attribute without it triggering anything.


Consider the button capability and attribute. The only actual events generated have the values pushed, held etc but in the mobile app we get to see ‘Standby’ displayed.

Similarly for momentary which doesn’t have an attribute at all and yet can display ‘Pushed’ when activated and then return to ‘Standby’.

So in both cases the app display can be changed without an event being generated.

For stateless attributes, such as the HTTP code example @TAustin presented, it makes no sense to permanently display the value of the last event. At the very least it should be possible to display an intermediate message as was possible in the Classic app.

It seems our only option to change the status reported in the app is to set the attribute and if we do that an event is generated in the device history and propagated to apps. Both are undesirable, with the event being a particular problem.

So are we overlooking something?

Another issue, which is related but off topic for this particular thread, relates to state change.

With the Classic platform, the ‘system’ would only propagate events where there was a state change. For stateless events, like pushing a button, developers could override this behaviour and force the event to be considered as a state change.

It appears the same is possible in Edge drivers, although undocumented, which seems odd as it would be critical. Does the ‘new’ platform behave the same as the old one in this respect? My assumption had been that as subscriptions can be limited to state changes, all events must be propagated. But then I saw a state change added to direct connected devices and I’ve seen it used in Edge drivers. So unless it is purely for back compatibility with the legacy platform I am confused.


Ok, I understand what you mean. Please, allow me some time to check this with the internal team. I’ll come back as soon as I get some news.

The engineering team mentioned that currently, there’s not an option to control the displayed events in the device history, so, they have opened a feature request to provide a better option for this kind of use case.

The state_change option is available to set manually, there are some examples in the button drivers.
However, consider the following:

  • This property helps mostly when we want to trigger a state change despite the “new” value is the same as the previous one (Eg. a button press). For that we should use state_change:true.
  • If the new value is different, the property will be set automatically to true even if we set it to false because a change is detected.
1 Like