Questions on Capability, DTH and DTH Publish

@jody.albritton @nayelyz

Hi everyone! It’s my first time of FAQ.

I’ve been struggling to learn Smartthings hard to connect devices like boilers recently.

I accidentally came across this treasure trove, and through this community I was able to better understand the Smartthings Documentation as well.

At first it was very difficult to make a capabilitiy for this, but fortunately this article saved me.

Creating custom capabilties for schema devices

Thank you so much Jody.

However, even if I followed it while watching the video, it seemed that there were still many problems to make the Device Handler Type.

There are three problems I have been curious about in the process so far.
I would appreciate your answer.

First question.

Should there be only one detailView of Custom Capability? If you look at the pre-defined’Temperature and Humidity’, there are two small settings on the top right as well as Humidity and Temperature.
Below is one of my dozens of attempts.

{
“dashboard”: {

},
"detailView": [
    {
        "label": "currentTemp",
        "displayType": "state",
        "state":{
                "label": "{{currentTemperature.value}}",
                "unit": "currentTemperature.unit"
                }
    },
    {
        "label": "setTemp",
        "displayType": "slider",
        "slider": {
            "range": [
                0,
                80
            ],
            "unit": "heatingSetpoint.unit",
            "command": "setHeatingSetpoint",
            "argumentType": "number",
            "value": "heatingSetpoint.value",
            "valueType": "number"
        }
    },
    {
        "label": "Modes",
        "displayType": "list",
        "list": {
            "command": {
                "name": "setBoilerMode",
                "alternatives": [
                    {
                        "key": "outside",
                        "value": "outside",
                        "type": "active"
                    },
                    {
                        "key": "space",
                        "value": "space",
                        "type": "active"
                    },
                    {
                        "key": "floor",
                        "value": "floor",
                        "type": "active"
                    }
                ],
                "supportedValues": "supportedThermostatModes.value"
            },
            "state": {
                "value": "thermostatMode.value",
                "alternatives": [
                    {
                        "key": "outside",
                        "value": "outside",
                        "type": "active"
                    },
                    {
                        "key": "space",
                        "value": "space",
                        "type": "active"
                    },
                    {
                        "key": "floor",
                        "value": "floor",
                        "type": "active"
                    }
                ]
            }
        }
    }
],
"automation": {


},
"id": "blah_blah",
"version": 1

}

The following is the result of querying the presentation of this capability in CLI.
It shows what I want very well.

Basic Information
┌─────────┬────────────────────────────┐
│ Id │ secret │
│ Version │ 1 │
└─────────┴────────────────────────────┘

No dashboard states

No dashboard actions

No dashboard basic plus items

Detail View Items
┌───────┬──────────────┐
│ Label │ Display Type │
├───────┼──────────────┤
│ secret1 │ state │
│ secret2 │ slider │
│ secret3 │ list │
└───────┴──────────────┘

No automation conditions

No automation actions

Nevertheless, what I could check was the capability with only the first detailView.
Is there any other way to create multiple detailViews? I looked for a tile from DTH… (Is it okay to use this)? It seemed to be using.

Second question.
I tried the process of creating and applying DTH’s DeviceConfig and DevicePresentation by referring to Jody’s video. When I followed along, I confirmed that the Capabilities that I put in the IDE’s DTH in DeviceConfig.json are well defined.
But when I set the component of each capability (you can think of it as main, A, and B), the capability did not appear at all. I was completely frustrated.
It is definitely not a grammatical mistake. This is because I already made Device Profile similar to that in Developer Workspace and checked the result (.json) of dividing components according to UI. It was a perfect match.

Third question.
The Device Handler Type following the video is made in IDE.
If so, how do I actually distribute it?
Don’t worry, I already checked the IDE’s My Publication Request.
I am concerned that this new DTH I created will be used by many other companies or people when I distribute it through this. When this is released, it will be available to everyone, right?
Since this device is being developed as a device of our company, the goal is to prevent other companies from using this DTH. I want to know if publishing is possible like that. (I mean DTH available only for us)

Dear SmartThings Partners, I was very impressed with the smart and brilliant answering. This is my first question I raised after seeing it. Please… There are too many questions, but I ask you to answer my questions.

Thank you.

I think this is definitely one that needs ST staff to help you with. You can always contact Developer Support directly via the Developer Workspace. However while you are waiting …

First question
The ‘Temperature Measurement’ and ‘Relative Humidity Measurement’ capabilities have individual presentations defined. However, as with many stock capabilties, the app doesn’t respect the capability presentations or the device presentation, and displays a customised solution combining the two. This sort of thing isn’t generally available yet.

Custom capabilities are still evolving and at one stage only supported one detail view per capability, and so you needed a custom capability for each attribute. We may well still be at that stage.

Second question
I’m afraid I don’t really understand the question here. It seems like your are talking about components like they are a feature of the UI rather than fundamental to the device integration so I am probably misunderstanding you.

Third question
The answer to your question is almost certainly that you can do what you require, though I’ve always assumed ‘My Publication Requests’ was a relic of the past that has lingered on in the IDE and not the way to go about things these days. I could be wrong.

@orangebucket
Thank you so much for answering.
As expected, the answer to the First question… is still impossible. Well I understood.

It’s cumbersome, but you said you didn’t understand well, so I’ll tell you the second question in more detail.

After processing Create New DTH in IDE, when we enter the following cli using the ID of the DTH, we get deviceConfig.json, right?

CLI:
$ smartthings presentation:device-config:generate “SECRET_ID” --dth -j -o=deviceConfig.json

deviceConfig.json

{
"type": "dth",
"dashboard": {
    "states": [
        {
            "component": "main",
            "capability": "switch",
            "version": 1,
            "values": [],
            "patch": []
        },
        {
            "component": "main",
            "capability": " TOP_SECRET_CAPABILITY1",
            "version": 1,
            "values": [],
            "patch": []
        },
        {
            "component": "main",
            "capability": " TOP_SECRET_CAPABILITY2",
            "version": 1,
            "values": [],
            "patch": []
        }
    ],
    "actions": [
        {
            "component": "main",
            "capability": "switch",
            "version": 1,
            "values": [],
            "patch": []
        },
        {
            "component": "main",
            "capability": " TOP_SECRET_CAPABILITY1",
            "version": 1,
            "values": [],
            "patch": []
        },
        {
            "component": "main",
            "capability": " TOP_SECRET_CAPABILITY2",
            "version": 1,
            "values": [],
            "patch": []
        }
    ]
},
"detailView": [
    {
        "component": "main",
        "capability": "switch",
        "version": 1,
        "values": [],
        "patch": []
    },
    {
        "component": "main",
        "capability": " TOP_SECRET_CAPABILITY1",
        "version": 1,
        "values": [],
        "patch": []
    },
    {
        "component": "main",
        "capability": " TOP_SECRET_CAPABILITY2",
        "version": 1,
        "values": [],
        "patch": []
    },
    {
        "component": "main",
        "capability": " TOP_SECRET_CAPABILITY3",
        "version": 1,
        "values": [],
        "patch": []
    },
    {
        "component": "main",
        "capability": " TOP_SECRET_CAPABILITY4",
        "version": 1,
        "values": [],
        "patch": []
    },
    {
        "component": "main",
        "capability": " TOP_SECRET_CAPABILITY5",
        "version": 1,
        "values": [],
        "patch": []
    },
    {
        "component": "main",
        "capability": "TOP_SECRET_CAPABILITY6",
        "version": 1,
        "values": [],
        "patch": []
    }
],
"automation": {
    "conditions": [
        {
            .....
        }
    ]
}

}

You don’t need to read all deviceConfig.json! Below is an estimate of the results.

If you use the following command using this deviceConfig.json file, a vvid appears, and then applying this vvid to DTH creates the UI we want to create, right?

$ smartthings presentation:device-config:create -j -i=deviceConfig.json

But what I want to do is make it like this. (Bringing capabilities into components)

image

For this, you just need to set component for each capability of deviceConfig.json, right?
When I did that, the question was no. Is there any way to do this? What am I missing?

Waiting for your answer, I will work hard to develop it… Thank you

OK, that is what I thought you meant, and the answer is no. It isn’t something you do to make the UI look nicer, it is something you do because your device is a composite device that has multiple components to start with.

As a Groovy DTH you’d actually have to have at least three device handlers - a parent device handler and two child device handlers - to have a UI like that. I’d imagine new style integrations will lend themselves to it more elegantly.

Newer integrations would also allow you to define your own plugin to implement the UI rather than using the standard one, but that is another story (one I haven’t read and I don’t know how well it works).

Thank you, @orangebucket I was just waiting for your reply.
(As you helped, I’ve already asked a lot of questions from Workspace’s developer support)

When configuring the Device Profile in the Developer Workspace, I was able to decorate the component by putting my pre-implemented Custom Capabilities. As a result, I was able to make it like this.

Thanks.

But I have another question!

I am working on a project based on SmartThingsSchemaConnector which is connected by C2C.
If so, I learned to work based on ‘InteractionTypes’. That means when I press the button of the device that I uploaded, a command request occurs, and I just need to process the response for that command request in SchemaConnector, right?

But why can I write the contents by overriding the capabilities command in DTH?
So I mean… This is an area where the Connector receives and processes command requests, right? By the way, why does DTH handle the command by overriding the function?
If I just process all commands in Connector and return appropriate values, I don’t have to make DTH?

I’m so sorry to ask you so much, thank you! Thanks!

And, can’t other capabilities behave like active/inactive when a certain capability command is executed?
What the hell is this??

If you look at the yaml file of the contents here, there is

visibleCondition:

But it seems completely useless. No examples, no usage.

Ah OK.

A Groovy DTH used to be the only way of implementing devices. It was very much structured for hub connected devices using Zigbee or Z-Wave but could be used for C2C as well. It is still the way of implementing the hub connected devices as the replacement is still in development. If you are using the Schema then you don’t want to go near a DTH at all.

It just so happens that much of the discussion in this forum about custom capabilities and presentations has been focused on DTHs because many desperately need patching up with retrofitted new technology to make the UI work.

The custom capabilities are also new to schemas but thus far they are still a marginal subject in this forum simply because it is dominated by end users and hobbyists who are still trapped in the legacy environment.

It seemed like that when I started to deploy .

I have to think that there was a big change as well as changing to…
this -> this
(The first one will disappear?)

However, compared to the changes, what can be implemented seems to have decreased a lot.
Is that because I don’t know yet? Or is it really like that?
It’s frustrating!

I’m not sure whether that has been fully implemented yet, or indeed at all. The timelines of much of this stuff aren’t really what you might reasonably assume.

I believe the idea is to make certain capabilities only appear in the UI, or perhaps be conditionally greyed out, based on the value of other device attributes.

1 Like