Custom Capability and CLI Developer Preview

More examples coming. This is just the basic how-to video. Need to cover the basics before launching into the more complex areas. We also need to gather feedback about issues with the basics first.

1 Like

@erickv there appears to be a bug with rendering a custom toggleSwitch as the dashboard on the iOS ST app, it not only doesn’t render it also prevents the detailView from opening. I’ve provided a sample to Jody.

Can you please clarify the correct usage for list in a detailView, the documentation appears to be conflicting as I had pointed out earlier.

Here is an example which renders on the detailView page but

  1. It does not display the specified values (from “value” as I understand the docs) in the list, so it should show “Mode 1” and “Mode 2”, instead it shows “mode1” and “mode2” on the screen list.
  2. It doesn’t call the specified custom method (setMode) with the arguments (as defined in the JSON key and as per the current documentation), instead the app throws an error when you select an option from the list.
  3. It doesn’t use the values from the attribute mentioned in supportedValues (in this case the DTH initializes the supportedCustomModes attribute value to contain ["mode1"], but the UI still shows both values (mode1 and mode2) in the drop down list.
"detailView": [
        {
            "label": "Custom Mode",
            "displayType": "list",
            "list": {
                "command": {
                    "name": "setMode",
                    "alternatives": [
                        {
                            "key": "mode1",
                            "value": "Mode 1"
                        },
                        {
                            "key": "mode2",
                            "value": "Mode 2"
                        }
                    ],
                    "supportedValues": "supportedCustomModes.value"
                },
                "state": {
                    "value": "customMode.value",
                    "alternatives": [
                        {
                            "key": "mode1",
                            "value": "Mode 1",
                            "type": "inactive"
                        },
                        {
                            "key": "mode2",
                            "value": "Mode 2",
                            "type": "active"
                        }
                    ]
                }
            }
        }
    ]

I think not

Thanks @jody.albritton for the guide and video. I have created a some custom capabilities with the capability presentation. I’m trying to get it to display units, but cant get it to work. The log in the app shows the units, but not on the detailView. Can anyone point me in the right direction?

Here is the presentation:

"dashboard": {

        "states": [

            {

                "label": "{{rain.value}}"

            }

        ],

        "actions": [],

        "basicPlus": []

    },

    "detailView": [

        {

            "label": "Now",

            "displayType": "state",

            "state": {

                "label": "{{rain.value}} {{rain.unit}}",

                "unit": "rain.unit"

            }

        }

    ],

    "automation": {

        "conditions": [

            {

                "label": "Now",

                "displayType": "numberField",

                "numberField": {

                    "value": "rain.value",

                    "unit": "rain.unit"

                }

            }

        ],

        "actions": []

    },

    "id": "islandtravel33177.rain",

    "version": 8

}

1 Like

It does apply. We will be making more guides soon.

2 Likes

Hello @cscheiene,

Thank you for your feedback. We’ve been able to replicate this issue and we have escalated it to our development team. I’ll keep updating you about the progress.

2 Likes

Is there a better way to have these changes apply immediately in the mobile app? It’s making it rather tedious while testing to have to go into the IDE and either toggle a device’s name or device type to actually see how the change I made to the device config looks.

1 Like

After playing more tonight, I’m definitely seeing some progress, which is very cool.
Two other things I’d like to see:

  1. Ability to specify sort order of items in the detail view
  2. An example with a custom capability with multiple attributes. I’ve tried a couple different ways but can only seem to get 1 of the attributes showing at a time. This is compounded by the issue of not being able to immediately and reliably get changes to show on the mobile app. If I publish a new version of a custom capability’s presentation, is that supposed to immediately take effect on the device config? I tried then pushing the device config after, but the vid didn’t change because presumably no update was detected.
3 Likes

Yes I really would like to see this too.

On the detailView I’m not able to disable more than one attribute. On the Dashboard it displays multiple attributes. None of the views displays units, but that’s confirmed by ST above.

When I make changes to the presentation I change the version number at the bottom and post it. Then I go to the device config, enter the new version number and post it. Then I always get a new VID from the cli. But after entering the new vid to the DTH I have not found a good way to update the mobile app, except for deleting the device, changing name, changing DH etc

How do we expose the custom capabilities to Alexa or Google Home?

For example, I have custom AC capabilities - AirConditionerTemperature, AirConditionerMode; Alexa/Google is unable to discover them, won’t even show up as a device…

1 Like

It would appear that the ocfDeviceType still influences the icon used by the mobile app when creating device presentations using the procedure under discussion in this thread. I’ve come across one or two lists of device types around but I thought I’d see what the Developer Workspace admits to. So:

3 Likes

Built-in capabilities should be preferred where possible as it makes easier for SmartApps and other integrations to follow the standards and ‘consume’ your device types. In other words, custom capabilities shouldn’t be used when there are existing capabilities that already cover those use cases.

2 Likes

Just a friendly reminder. I have re-written the tutorial in the first post on this topic. If you haven’t checked it out in a while, give it another look and let me know if you have any feedback.

3 Likes

Jody, I noticed there was an update to the iOS app. However this presentation still doesn’t work:

The detail view still throws an error when selecting an option the list and it doesn’t show the correct names)

@RBoy Only IOS? Or does this impact android too?

Both, iOS and Android

Amazon/Google need to recognize them as supported capabilities on their platform.

One bit of housekeeping. I will start moving specific bugs and issues to the new developer support category. If you have questions about the CLI Examples/Tutorials, keep posting them here. If you have a bug or feature request, please start a new thread here

https://community.smartthings.com/c/developer-programs/support

2 Likes

Until the thermostat setpoint is not supporting 0.5 Celsius steps how would you do that? I was just thinking to rewrite my TRV DH to do support the 0.5 step. But this specific question stopped me.

And of course the idea, that the setpoint’s stepper is defined by 1 and not 0.5 as default for Celsius. It makes me think, that even at ST, the 1 for Fahrenheit and 0.5 for Celsius stepper, is a difficult issue as the structure doesn’t seems to support it…

@jody.albritton, please correct me if I am wrong.

Jody, in the detailView, apart from the list commands and alternatives not working as described here, if I use the state instead, it doesn’t seem to honor the alternatives values either

"detailView": [
        {
            "label": "Custom Mode",
            "displayType": "state",
            "state": {
				"label": "{{customMode.value}}",
				"alternatives": [
					{
						"key": "mode1",
						"value": "Mode 1",
						"type": "inactive"
					},
					{
						"key": "mode 2",
						"value": "Mode 2",
						"type": "active"
					}
				]
            }
        }
    ]

It displays mode1 and mode2 instead of Mode 1 and Mode 2 in the detailView. This happens with iOS and Android.

Also on the Android dashboard for states it doesn’t show any value (it’s stuck showing “Checking status…”), however on the iOS dashboard it does seem to correctly show states and the alternatives.