Custom capabilities for a driver

Sorry for the delay, can you share the definition of your device profile, please? (The one with the metadata section.)
I want to check if the issue can be replicated with the exact same configuration

mnmn: SmartThingsCommunity
vid: c3358628-dd3d-3071-90e3-01a791ebffd8
version: 0.0.1
type: profile
iconUrl: null
dashboard:
  states:
    - component: main
      capability: switch
      version: 1
      idx: 0
      group: main
      values: []
      composite: false
  actions:
    - component: main
      capability: switch
      version: 1
      idx: 0
      group: main
detailView:
  - component: main
    capability: switch
    version: 1
    values: []
    patch: []
  - component: main
    capability: switchLevel
    version: 1
    values: []
    patch: []
  - component: main
    capability: colorTemperature
    version: 1
    values:
      - key: colorTemperature.value
        enabledValues: []
        range:
          - 2900
          - 7000
    patch: []
  - component: main
    capability: titleradio02180.identification
    version: 1
    values: []
    patch: []
  - component: main
    capability: refresh
    version: 1
    values: []
    patch: []
automation:
  conditions:
    - component: main
      capability: switch
      version: 1
      values: []
      patch: []
      exclusion: []
    - component: main
      capability: switchLevel
      version: 1
      values: []
      patch: []
      exclusion: []
    - component: main
      capability: colorTemperature
      version: 1
      values:
        - key: colorTemperature.value
          enabledValues: []
          range:
            - 2900
            - 7000
      patch: []
      exclusion: []
  actions:
    - component: main
      capability: switch
      version: 1
      values: []
      patch: []
      exclusion: []
    - component: main
      capability: switchLevel
      version: 1
      values: []
      patch: []
      exclusion: []
    - component: main
      capability: colorTemperature
      version: 1
      values:
        - key: colorTemperature.value
          enabledValues: []
          range:
            - 2900
            - 7000
      patch: []
      exclusion: []
    - component: main
      capability: titleradio02180.identification
      version: 1
      values: []
      patch: []
      exclusion: []
    - component: main
      capability: refresh
      version: 1
      values: []
      patch: []
      exclusion: []
presentationId: c3358628-dd3d-3071-90e3-01a791ebffd8
manufacturerName: SmartThingsCommunity

Is that the complete configuration?
The property of mnmn is missing, when we create one using the CLI, it assigns automatically the value of SmartThingsCommunity.
This property is important because it helps identify the origin of the presentation. So, maybe that’s causing the issue in this case.

@nayelyz Updated the full device config presentation in my previous post. Extracted via

smartthings presentation:device-config c3358628-dd3d-3071-90e3-01a791ebffd8 SmartThingsCommunity -y

Sorry for the confusion, what I need to verify is if you added correctly the reference of the presentation you want to use in your device profile. For example, in the case of the presentation c3358628-dd3d-3071-90e3-01a791ebffd8, you need to have this configuration in your profile:

name: com.elgato.lighting.key-light.v1
components:
  - id: main 
    capabilities: 
      - id: switch 
        version: 1 
      - id: switchLevel 
        version : 1 
      - id: colorTemperature 
        version: 1 
      - id: titleradio02180.identification 
        version: 1
      - id: refresh
        version: 1
    categories:
      - name: Light
metadata: 
  deviceType: Light 
  ocfDeviceType: oic.d.light
  deviceTypeId: Light 
  vid: c3358628-dd3d-3071-90e3-01a791ebffd8
  mnmn: SmartThingsCommunity <------This is the one I mentioned was missing
1 Like

@nayelyz, in a private post you told me to delete it… so that is why I removed it from the files :wink: now it’s working.

Thank you!

Sorry I wasn’t clear enough. What I meant was that device configurations (device presentations) shouldn’t be created using a custom VID because a default value is assigned (SmartThingsCommunity).
Once it is created, we need to make reference to it using both properties, vid and mnmn, in the device profile.

1 Like

Has anybody managed to get the mobile app to display in the device detail view 2+ attributes from a given custom capability/device component?

If you have had success, please could you explain how you did it?

I am unable to get a custom capability with two or more (>1) attributes to display in the mobile app.

I have successfully managed to create and display several custom capabilities, each having a single (1) attribute.

I have tested the standard “colorControl” and “dustSensor” capabilities that have >1 attributes and they appear to use some “hidden magic” to display in the mobile app.

I have checked the corresponding profiles and presentations against standard ones and they all seem to mirror the same structures.

Is there an undocumented limitation to 1 attribute with the display of custom capabilities?

Hi, @sam11.
Custom capabilities only support displaying one attribute at a time in the detail view. This is because a capability is used to provide information about only one property of the device and a group of capabilities collects all those properties which are displayed according to the device presentation.

Note: The issue of displaying multi-attribute custom capabilities in the mobile app is under review of the engineering team

So, you should split them into different capabilities or, I’ve seen that other developers decide to show one attribute in the dashboard view and the other in the detail view (when they have two), but it’s up to you.
Let me know if you need help :smiley:

@nayelyz I think that someone found a way to display two capabilities in dashboard view, and in detail view.

Tagging @Mariano_Colmenarejo

Hello @milandjurovic71

They are custom capabilities with a single attribute.

What can be displayed is several attributes of different caàbilities in the dasboard

Are differents things

1 Like

I thought the reason was because they hadn’t got around to implementing multiple attributes yet. That would be annoying but at least there would be an obvious forward path. If there really is a suggestion that custom capabilities will only have one displayed attribute then there is a problem.

There are quite a few standard capabilities that have multiple attributes. There are things like dust sensors which report on levels of two grades of dust, and colour controls which have three colour parameters. Then there are capabilities for things like appliances where you get modes and timers bundled together. So I can’t see why custom capabilities should be expected to be any different.

There are over 40 standard capabilities with 2+ attributes that I know of. So it is important that this functionality becomes available for custom capabilities too.

If the reason for not being able to display 2+ attributes in the details view is due to it not yet having been implemented, this is unfortunate, because I have not seen any documented warning regarding this. Documentation is therefore urgently needed.

Tell me about it. Usually with the documentation we are playing catch up with what is actually working. However on day one with the capability presentations we were already working with an unusually comprehensive API reference. The API basically worked very well. Unfortunately next to none of the presentation functionality had actually been implemented in the mobile apps. I just wanted to have a custom capability that could set its state with the equivalent of on() and off() commands - about as basic as you can get and all documented. A year and a half later that functionality still wasn’t implemented. I eventually gave up and to this day have no idea what works and what doesn’t.

Thanks for the insight. It was only after I cross-checked the generated profile and presentation json that I began to suspect that everything was in order except for the display functionality being available in the mobile apps.

Friday afternoon inspiration and all that…

I was about to suggest that some developer wizz could take all the generated json and knock up a webservice to at least check visually what you are doing…

But there already is one! And it works! I just logged in and my multi-attribute custom capability is displaying exactly as I intended!

And the link is… https://my.smartthings.com

My custom capability with multiple attributes displays correctly on the web interface available at “https://my.smartthings.com

I therefore think you need to prompt the mobile app development team to implement this functionality…

Also, it might be worth suggesting to anybody having problems with the display of custom capabilities to check out how it displays in the web interface.

The issue of multi-attributes not appearing on the mobile app is already being reviewed by the engineering team. However, there’s not an ETA on its solution, we already added your comments in the corresponding report so the team can see the feedback (@sam11 and @orangebucket)
I’ll ask for more details about that tool and how much we can trust it would look the same.

Could you share a screen capture of how the capability appears on that page, please?

Hi folks,

I too am attempting to create a custom capability for my edge driver. I’m trying to start simple/slow, so first I created my capability:

{
    "id": "radioamber53161.wind",
    "version": 1,
    "status": "proposed",
    "name": "wind",
    "ephemeral": false,
    "attributes": {
        "windSpeed": {
            "schema": {
                "type": "object",
                "properties": {
                    "value": {
                        "type": "number",
                        "minimum": 0
                    },
                    "unit": {
                        "type": "string",
                        "enum": [
                            "KTS"
                        ],
                        "default": "KTS"
                    }
                },
                "additionalProperties": false,
                "required": [
                    "value"
                ]
            },
            "enumCommands": []
        }
    },
    "commands": {}
}

Then, I created my presentation:

{
    "dashboard": {
        "states": [
            {
                "label": "Wind: {{windSpeed.value}}"
            }
        ],
        "actions": [],
        "basicPlus": []
    },
    "detailView": [
        {
            "label": "Wind Speed",
            "displayType": "state",
            "state": {
                "label": "windSpeed.value",
                "unit": "windSpeed.unit"
            }
        }
    ],
    "automation": {
        "conditions": [
            {
                "label": "Wind Speed",
                "displayType": "numberField",
                "numberField": {
                    "value": "windSpeed.value",
                    "unit": "windSpeed.unit"
                }
            }
        ],
        "actions": []
    },
    "id": "radioamber53161.wind",
    "version": 1
}

The problem comes when I try and create the device config using

smartthings presentation:device-config:create -i mypresentationfile.yaml

I get an 500 error as follows:

    Error: Request failed with status code 500:
    {"requestId":"41F01228-FE02-40E4-90C1-09CF4661F476","error":{"code":"UnexpectedError","message":"A non-recoverable
     error condition occurred.","details":[]}}

Any thoughts? I’m fairly stuck and feel like I’m missing something silly…

Cheers

You should be using "smartthings capabilities:presentation:create -i mypresentationfile.yaml. The device-config file has a different format, and i think (may be wrong) you don’t have to provide one for Edge drivers (there are defaults for that instead).

For the capability you should be running "smartthings capabilities:create -i mycapabilities.yaml.

Once you’ve done :create you can update the id’s in the files and use :update for the capability and capability:presentation commands.