Custom Capability and CLI Developer Preview

Hi, @RBoy

The results that I’ve shared were reproduced at Android. I’ll proceed to test these results at iOS.

About the example implementation, I’ve set both label and value for a better reference of the result that I wanted to have. Also, since this is a basic implementation, without enum values or restrictions for supported values, I’ll proceed to create an implementation following these resource limitations and report them accordingly.

Another bug @erickv @nayelyz with changes to presentations not being reflected.

  1. Create a capability, presentation (with a custom “state” component in the detailView) and then device-config:create
  2. The platform will generate a VID (which I understand is a unique hash of the components in the configuration)
  3. Delete the custom capability
  4. Change the presentation custom component in detailView from “state” to “list”
  5. Regenerate the capability, presentation and configuration (don’t make any changes to the capability or configuration, the only change is to the custom control from “state” to “list” in the presentation above)
  6. The UI still renders the custom components as a “state” instead of a “list”

The bug is replicable consistently and the UI refuses to either generate a new VID or update the presentation for that VID.

Here’s is a custom VID I created that originally had a “state” as the custom control in the detailView. Then I deleted the capability and created it all again ONLY changing the presentation control from “state” to “list”, however the presentation:device-config:create command still returns the same VID and it still renders the component as “state” and not a “list”: 7c7c3ec0-db88-3fc2-b498-d4135a2a22dd

In this VID the custom control detailView in the presentation is defined as:

“detailView”: [
{
“label”: “Arm Mode”,
“displayType”: “list”,
“list”: {

Where as when I query the VID it returns:

{
“capability”: “xxx”,
“version”: 1,
“label”: “Arm Mode”,
“displayType”: “state”,

Notice it’s not taking the updated presentation for the control (I’ve deleted the capability and started over so it should pick up the latest presentation JSON).

If I change the configuration JSON (even a minor change not related to the custom component, e.g. change the dashboard control to something else) then presentation:device-config:create will generate a new VID and it renders the custom component correctly (as a “list” now since it was changed from “state” to “list” in the presentation JSON). It looks like once the VID is generated it doesn’t seem to want to update the presentation layout (displayType) for that VID.

Is there a way to force the platform to update the VID when the presentation changes? Let me know if you need more details.

EDIT: I tried it again by changing the presentation for the custom control from “state” to “stepper” and it still generates the same VID and renders it as a “state” (unless I make some other un-related change the configuration JSON which forces it to generate a new VID and then display the control correctly as a stepper)

2 Likes

Thanks for these details, @RBoy

As @nayelyz has shared at this post, the UI metadata is being cached and queried twice a day, and to avoid vid duplications, where the only changes were at the capability’s presentation, the system is not creating new vids.

However, it will create a new vid when the device-config changes (or when the DTH - Device profile is updated).

Also, this seems to be a workaround to improve testing new presentations. I will test it out and share the results with the team.

Hi, @RBoy

I’ve tested different formats of a capability supporting list display type, and below are my results:

  • When the attribute supports for enum values (this is part of the issue reported that commands are sending the key as argument). If the device handler uses directly the argument from the command, the response will trigger an error.

  • When the capability has a “supportedValues” attribute. Just like you’ve mentioned, all the values/arguments will be displayed ignoring the values declared at the attribute’s array (issue documented and reported).

Regarding this post, I’ve been able to make it work, so I’ll keep creating some implementations to collect the necessary information to document it.

All these results have been tested at:

  • Android app v1.7.50-21

  • iOS app v1.6.49-413

Erick, I don’t quite understand what you meant by this. You’re saying that the key should be passed as the argument. Can tell me what is the expected argument in your example that the command should receive?

Can you explain what you mean by:

How should the device handler use the argument?

From your example above, I would expect the DTH to define the command as:

def setTodo(argument)

And from your example above, what would be the argument passed by the control? (do cut or cut)

Hi, @RBoy

The issue that I’ve noticed is that the key assigned at the command’s alternative is being passed as the argument of the setter command instead of the value, e.g. I would expect that when I hit the command from the list (the visual key), receive as argument the value defined (cut, copy or paste).

Also, here’s an example on how this issue is impacting from the API’s perspective as well:

{
    "component": "main",
    "capability": "namespace.toDoList",
    "command": "setTodo",
    "arguments": ["Do Cut"] <--- This is the actual argument that is being passed
}

This would be considerably increasing the flow-control coding to parse their respective values (e.g. Button alike custom capabilities).

1 Like

Okay so you’re saying that it’s calling the command with an incorrect argument value (being substituted from the alternative list).

However, are you able to see the command being invoked (albeit with an incorrect argument value)?

I’m not seeing the command being invoked in the IDE Live Logs (just an error message on the screen) on iOS.

1 Like

Hi, @RBoy

I’ve been able to deploy the previous example (toDoList capability) with a basic DTH and just like you’ve mentioned, events are not being registered at the IDE.

Addionally, based on the activity from the mobile logs extracted, I’ve noticed that commands are being triggered following the patter mentioned Here but, they’re not getting correctly to the device’s handler.

This issue has been documented and reported properly.

1 Like

Appreciate the update Erick. Any idea on the ETA to get these fixed so I can continue with the migration efforts?

hi,

Is there a way to refresh a device in the new app following a DTH update (new publish) or a capability update through the CLI? so far I couldn’t do it without deleting the device and recreating a new one. In the Classic app there is no such problem.

Is there a list of all the displayType with visual examples? There are some that I can’t find. for ex - what is the displayType used for the colorControl capability?

Is there a way to create a displayType or is it a closed list?

Hello @SZaf,

For the DTH update, you could try the workaround of changing its name instead of creating a new device. We mentioned above that the device configuration presentation is cached, so you can also try the workaround mentioned there.

As for the available displayTypes, currently, the list is fixed, if you want to see the presentation of a predefined capability, you can use the command below to visualize the configuration in JSON format.

smartthings capabilities:presentation capabilityName -j

1 Like

Thank you @nayelyz

One more question: I couldn’t find any documentation regarding icons.
Below is a section from the switch capability’s JSON under dashboard. Is the ___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_ON_T_SAMSUNG_CONNECT an icon?

If so, is there a list of all the icons for the new app, similar to http://scripts.3dgo.net/smartthings/icons/ (that is used in tiles)?

“alternatives”: [
“key”: “on”,
“value”: “___PO_CODE_SMARTTHINGS_DREAM_SAC_SBODY_ON_T_SAMSUNG_CONNECT”,
“type”: “active”

Hi @SZaf,
No, that value in the switch capability is not an icon, is part of the conventions of the predefined capabilities.

Here’s a list that was shared previously in this thread. You can use these values in the device profile metadata, for example:

{
  "name": "deviceIconTest",
  "components": [
      {
          "label": "main",
          "id": "main",
          "capabilities": [
              {
                  "id": "capabilityID",
                  "version": 1
              }
          ],
          "categories": []
      }
  ],
  "metadata": {
      "deviceType": "Fan",
      "ocfDeviceType": "oic.d.fan",
      "vid": "xxx-xxx-xxx",
      "mnmn": "SmartThingsCommunity"
  }
}

Is there an ETA to fix these issues? It’s been 23 days since I reported bugs with the toggleSwitch, list and custom child components, while I appreciate the reproduction and submission of the bug reports, however without a fix I don’t see how to move forward.

2 Likes

Hello, @RBoy

Following-up on this issue about setter commands from custom capabilities supporting the list display type, here are some IDE logs where the key has been sent as argument instead of the value specified at the capability’s presentation.

As mentioned before, this would be impacting the flow-control of command handlers. For example, where I could be handling commands as following:

def setTodo(String arg) {
    	sendEvent(name: 'todo', value: arg)
}

I’m forced to do this:

def setTodo(String arg) {
    if (arg == 'Do copy'){
    	sendEvent(name: 'todo', value: 'copy')
	}
    if (arg == 'Do paste'){
    	sendEvent(name: 'todo', value: 'paste')
    }
    if (arg == 'Do cut'){
    	sendEvent(name: 'todo', value: 'cut')
    }
}

@erickv a couple of things:

  1. I’m not seeing this happen on iOS. The command is never called in the IDE when the command is invoked on the UI.
  2. As of this week, the UI isn’t updating at all on the mobile phones. The same control is showing different UI components on Android and iOS. My iOS is stuck showing a state in the detailView where as the Anrdoid is showing a stepper. The presentation file is set to a list
"detailView": [
        {
            "label": "Arm Mode",
            "displayType": "list",
			"list": {
                                     ...

The VID is 7c7c3ec0-db88-3fc2-b498-d4135a2a22dd

iOS (v1.6.49-413)

Android (v1.7.50-21)

I’ve logged out and logged back into the mobile app it’s still completely disconnected from reality. I’ve deleted the capability completely and started over and everything is still disconnected from each other.

In short, the whole thing is a mess and nothing is working as directed/documented or even in sync with each other. I don’t know the iOS, Android and VID are showing controls which are completely different from each other?

@nayelyz

thank you again. Regarding the icon, can you change the DTH presentation icon with the iconURL parameter rather changing the device profile? In the api I noticed “preload” suffix before the URL which I didn’t find any explanation for.

I tried “iconUrl”: “http://cdn.device-icons.smartthings.com/Appliances/appliances11-icn@2x.png” yet it didn’t change anything (I deleted the app’s cache as you suggested).

Am I doing something wrong?

On a different note, when I tried to update the device on the app by changing the device’s name there was an error. The device is a Child device and it seems like a bug in the app because it happened with other child devices that I tried. I had to delete the device and recreate it from the Classic App.

I’m seeing this to. I have done a minor text change to my custom capability presentation. It’s been 4-5 days now. The change has not been made yet, even though the cli reports the change if I check the presentation.

I’m also seeing mismatch between ios and Android, even between devices using the same DH on Android.

Makes it very hard to test changes, you don’t know if the changes didn’t work or just hasn’t been updated yet

3 Likes

Hi @SZaf,
You can also set those properties in the DTH definition, for example:

metadata {
    definition (name: "DTH Icon", deviceType:"fan",ocfDeviceType:"oic.d.fan", ...) {
        ...
    }
}

You would see the icon of the sample below:
fan_icon

The workaround I mentioned to update the device presentation refers to changing the DTH’s name so the device can detect the last published version. Apologies for the confusion.

1 Like

@rboy Now all my custom capabilities does not display anything in the detail view anymore. Even on Smartthings own SmartWeather Station tile the capabilities have disappeared, only standard capabilities are displayed. They still show up in the history in new app. Both ios and Android. Have you seen anything similar?

2 Likes