Custom Capability and CLI Developer Preview

I flagged it internally. I think the URL may have changed: https://smartthings.developer.samsung.com/docs/Capabilities/custom-capabilities.html#Creating-a-Capability-Presentation

1 Like

Thanks for that

I have been at this for four months now. I largely remain at the position I was after about one or two weeks. Since then all I have gained is a better understanding of how things piece together and increased confidence that I got it right in the first place. Not a single thing I have done with custom capabilities and the UI has ever worked fully as documented. I’m not saying there aren’t such things as I haven’t been seeking them out, but nothing I have ever tried has actually worked at the time I tried it.

The only thing I have ever had run a command is an example list from @erickv and that only seemed to bear a loose relationship with the intended behaviour as documented.

2 Likes

You may want to consider using the standard “Fan Speed” capability instead, and map the “fan speed” to what you need. Standard capability would allow voice control (Alexa/Google); the custom capability does not.

I think it’s a list view in my custom capability dth. You should be able to get json presentation.

Do you have a screenshot of what your detail view looks like?

Yes. Find the screenshot “AC” here.

It has been 3 months since that was reported. At this point, I am very concerned as to the competence of engineering on something that seems pretty baseline important. I have tried to give the benefit of the doubt, but a TON of time has passed now with almost no visible change and yet apparently the Classic shutdown is still happening today. This does not look good.

6 Likes

See this sample:

Aren’t the key and value in the command the wrong way around in that example, or at least aren’t they supposed to be the other way around? I never quite grasped exactly what @erickv was saying there. I know something was supposedly happening back to front but I was never clear what.

The key should be the actual attribute value, which will be used for the command argument, and the value should be the touchy feely version of it for display purposes. As illustrated by the fanSpeed capability where you can see the ids for i18n.

    "detailView": [
        {
            "label": "___PO_CODE_SMARTTHINGS_DREAM_SAC_TMBODY_FAN_SPEED",
            "displayType": "list",
            "list": {
                "command": {
                    "name": "setFanSpeed",
                    "alternatives": [
                        {
                            "key": "0",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_OFF_T_SAMSUNG_CONNECT",
                            "type": "inactive"
                        },
                        {
                            "key": "1",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_LOW_M_FAN_SPEED",
                            "type": "active"
                        },
                        {
                            "key": "2",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_OPT_MEDIUM_M_FAN_SPEED",
                            "type": "active"
                        },
                        {
                            "key": "3",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_HIGH_M_FAN_SPEED",
                            "type": "active"
                        },
                        {
                            "key": "4",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_MAX_M_SPEED",
                            "type": "active"
                        }
                    ]
                },
                "state": {
                    "value": "fanSpeed.value",
                    "alternatives": [
                        {
                            "key": "0",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_OFF_T_SAMSUNG_CONNECT",
                            "type": "inactive"
                        },
                        {
                            "key": "1",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_LOW_M_FAN_SPEED",
                            "type": "active"
                        },
                        {
                            "key": "2",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_OPT_MEDIUM_M_FAN_SPEED",
                            "type": "active"
                        },
                        {
                            "key": "3",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_HIGH_M_FAN_SPEED",
                            "type": "active"
                        },
                        {
                            "key": "4",
                            "value": "___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_MAX_M_SPEED",
                            "type": "active"
                        }
                    ]
                }
            }
        }
    ],

Yes they are and that’s a pending bug (one of many many reported so far). I’m told that there are fixes in QA so just waiting here to see when it’ll be released and keeping my fingers crossed that it doesn’t break anything else when it moves to production (I’m not in a mood to rewrite 60 device handlers again, just getting through this first batch).
Honestly I liked the older ST team development model, they were QUICK to respond and fix bugs. Any critical bug would be fixed same day, any important bugs (like these) would be fixed in production in a week, max two.
With the new team model it looks like they work on a quarterly cycle. Report this quarter (I must say the build support team @nayelyz @erickv are quick to replicate and raise tickets but that’s where the responsiveness ends - there’s never any transparency on the ticket status or an ETA from the dev team to actually fix tickets) and maybe fix next quarter. I can only wonder what will happen if somethings breaks because QA didn’t catch it. Wait another 3-6 months for a fix? Wouldn’t hurt to look at Agile development and weekly sprints.

7 Likes

What I see is support working to close the tickets out ASAP if you cannot provide proof of the bug. I open a bug and support asks for more information, and if I do not provide it within 24-48 hours they respond back stating they closed the issue because I have not provided the extra information.

They asked for a screen recording, when I got to it the recording was too large to use … they seem to not want to believe the issues if just providing a screenshot. I’m sure after providing recording they will need another recording to prove physical device status.

Is device status ever accurate for anyone? No matter device type, 80% of time device status is not correct, making app largely useless … becomes more convenient to NOT use app due to frustration and time it takes.

1 Like

I’m trying to follow this tutorial, but I’ve been getting so many issues.

First, I can’t even seem to log in the normal way. When I click authorize in the popup window, it just gives me an “unexpected server error”. I’m able to bypass this by just adding --token <INSERT TOKEN HERE>, but it’s just super inconvenient.

Second, I got up to the portion where you create the presentation. I enter the command smartthings capabilities:presentation:create <namespace>:<name> 1 -j -i=<name>.json --token <TOKEN> and that gives me a status code 500 with the message "A non-recoverable error condition occurred.` I haven’t been able to find anything on it.

Third, I tried to do the same thing without the “1 -j -i=.json” part, and it starts off with a prompt. I get up to “Enter id or index”, I enter in either the id or the index of the corresponding capability, and it gives me the error Q & A not yet implemented. I have not found a single result for this error code.

Is there something wrong in this tutorial, or am I doing something wrong?

I’m assuming you’ve successfully created the capability first. The presentation can only be created after the capability is successfully created.

it is good to know that development is already informed of the problem.
but I really don’t understand why Samsung Smartthings is SHOUTING that it will discontinue the old ST app so quickly when the new app still lacks very basic required features.

So if the pushbutton’s commands are not working, is there any recommended workaround using other display types ?

One of the things that has been puzzling me about this whole process is that we can query the API and see a shedload of stock capabilities and their capability presentations that are all in exactly the same format as the custom capabilities. Literally the only difference is that the custom capabilities have an explicit namespace. So on the face of it going from device presentations to the UI should be a known quantity, and the problem should be seamlessly handling the namespaces.

That isn’t what I am seeing though. I see stock capabilities being implemented in ways that suggest that they are bespoke solutions with little or no connection to the capability presentations, and the UI for the custom capabilities trickling out as if the capability presentation concept is a completely new approach that hasn’t been used before.

Have I been labouring under a misapprehension here?

1 Like

Is “successful” defined as "the capability shows up when you type smartthings capabilities or is it when this status is no longer proposed. I didn’t see an approval requirement in the tutorial video.

My overall goal is to get a DTH with two sliders like in the Classic app. I saw that there can only be one attribute per capability, so I figured I’d have to create two capabilities, one for my primary device and one for my secondary device. Right now, moving everything over as-is, the second slider does not show up.

The capability statuses used by stock capabilities are ‘dead’, ‘deprecated’, ‘proposed’ and ‘live’. It isn’t an approval thing. The custom capabilities are just being piggy backed onto ‘proposed’.

So, the capability was created successfully then. Why the weird errors when attempting to make a presentation then?

@SmartThings / @jody.albritton i am having no luck with migrating my rooms occupancy capability and presentation of it in either the dashboard or detail view. there are no errors being thrown it simply does not work with no indication why.

migrating to the new app today will leave my SmartThings based home automation non-operational. i am sure SmartThings also does not want us to be left with a non-operational home automation because of a date driven migration that does not align with the current state of the proposed custom capabilities which, from what’s available externally, seems to be still in an alpha state.

difficult as it will be for me it’s going to make me loose major brownie points with my better half. as you can imagine none of us who have a better half want to be in that position.

what is our option here?

thank you.

3 Likes