Device Profile created from the CLI is incomplete

Hello,

I wrote a JavaScript SmartApp using the new guidelines and it works very well when creating the “Project” and “Device Profile” manually from the Developer Workspace. I am now trying to find an easier way to let people install the SmartApp for themselves without having to manually reproduce every single step in the web interface.

I then experimented with the SmartThings CLI and found out that some inputs seem ignored.

The input file I use is the following:

name: Temperature and Humidity for OpenWeather sensor
metadata:
  deviceType: Thermostat
components:
  - id: main
    capabilities:
      - id: temperatureMeasurement
      - id: relativeHumidityMeasurement
      - id: momentary
view:
  dashboard:
    states:
      - capability: temperatureMeasurement
    actions:
      - capability: momentary

Then, I create the Device Profile with:

smartthings deviceprofiles:view:create --input inputfile

As a result, the Device Profile appears in the Developer Workspace, has all the expected values on the two first tabs (Basic Info, Components & Capabilities), but keeps default values on the third one (UI Display) instead of my customized ones.

I can manually fix these ones, but even when exporting the result, deleting the Device Profile, creating a new with the exported file, these 3rd tab values and still ignored.

smartthings deviceprofiles:view ae761338-1dd7-460d-a6ae-92246f6b2a79 --output exportfile
smartthings deviceprofiles:delete ae761338-1dd7-460d-a6ae-92246f6b2a79
smartthings deviceprofiles:view:create --input exportfile

Am I missing something here?

I haven’t done a lot on the Developer Workspace end, but my understanding from the CLI side of things is that a view isn’t a ‘thing’ in itself, in the sense of an API object, rather it is a file format that combines a device profile and its associated device config.

So when you do smartthings deviceprofiles:view:create you aren’t creating a view, you are creating a device profile and a device config FROM a view, and when you do smartthings deviceprofiles:view you are retrieving a device profile and the device config it uses and combining them INTO a view.

I haven’t yet encountered the view concept anywhere but in the CLI.

I wouldn’t expect the Developer Workspace to do anything with the view section because it doesn’t exist in the device profile. That said, it doesn’t need to because the profile references the config/presentation in its metadata. So I would say the essence of your question remains.

It may be the Developer Workspace is still playing catch up with the latest thinking in this area.

Thank you for your reply. Your explanation helped me changing my perspective and try other things that seem to confirm a bug.

In the Device Profiles management page of the Developer Workspace, the third tab (“UI Display”) of every device profile allows downloading a JSON file. I believe this file represents the view since it contains at its root, subsections that are under the view section of a file retrieved with deviceprofiles:view --output.

  • If I create a device profile with deviceprofiles:create and the YAML of my first post without the view section, the JSON is understandably mostly empty

  • If I create a device profile with deviceprofiles:view:create and the YAML of my first post with the view section, the JSON does take into account the view section of my YAML, even though the web UI ignores it. I also tried to directly use this device profile with a project and I confirm the UI on the SmartThings mobile app does display the temperature and a momentary button as I wanted

  • If I manually fix the “State” and “Action” parameters of this “UI Display” tab and reload the JSON, I get the same JSON as above

I am now almost sure there is a bug in the Developer Workspace that doesn’t correctly displays the view parameters under the “UI Display” tab, although they are correctly stored and used by the SmartThings mobile app. I also notice that every time I edit a device profile in the developer workspace, I have to click again on “Use generated UI display” to enable the “Save” button. So that would be a second bug.

That’s a device configuration file. If you look in the metadata of the device profile created by view:create you should see a line saying vid: {{vid}} (or it may say presentationId if it has moved with the times). If you do

smartthings presentation:device-config {{vid}}

… that should show you your existing one.

The idea of uploading files seems a bit old hat given the files are in the API already.

It is at this point I always defer to @nayelyz.

Oh, I see.
Should I then ignore the concept of “view”, and instead create a device-config (that contains the same information as my view) and somehow bind it to a “view-less” device profile section?

Hi, @Konnichy!

I wouldn’t mix working with the API and the Developer Workspace in this regard (creating/updating device profiles).
For now, I need to confirm the following with the team:

  • Is it safe to work on both sides API and Dev WS with device profiles.
  • What’s the purpose of the view command

For you to continue with your integration, use smartthings device-profiles:create and create its device-config (smartthings presentation:device-config:create).
This command helps you generate a basic file which you can edit and use to create the device presentation:

smartthings presentation:device-config:generate profileID -j -o=deviceConfig.json

Then, edit the device profile’s metadata to set the VID created.
You need to do this once, users can post the device profile with all the data (VID included).
Also, it is possible that you publish the device profile and they won’t have to create it anywhere.
Remember that once a device profile cannot be modified once it’s published.

Note: they will only have to create the SmartApp and deploy it to test in the Dev WS (this is a must, it cannot be deployed from the API).

Thanks for the tag, @orangebucket!

Thanks @nayelyz , that’s very informative.

Unfortunately, there is no metadata nor vid field present in the file generated by presentation:device-config:generate. Strangely enough, there’s also no mention of the device profile ID used on the command-line.

I manually prepended the metadata and vid keywords in the file, but no matter which value I use as the vid (tried the id of the device profile, as well as the vid, both returned after deviceprofiles:create), presentation:device-config:create succeeds but does not seem to do anything. Anything visible in the Developer Workspace at least, even when downloading the “UI Display” JSON.

The Developer Workspace has a lot of history in this area. It used to be THE place for device profiles and the UI Display worked with these monstrosities called UI Manifests. Imagine combining all the capability and device presentations and translations into a single file about 100-200 kb big and you’ll be roughly there. I suspect it still hasn’t quite let go of doing stuff for itself and to be fair it probably doesn’t really need to in order to do its job.

One could query why there isn’t an obvious option to use a published device profile instead of having to roll your own all the time. That would seem to be useful.

Hi, @Konnichy

We are looking into this. We will let you know as soon as we have an answer.

This is normal, the VID doesn’t appear there because it hasn’t been created yet, the generate command provides a template and doesn’t save any config.
The metadata property is part of the device profile, I didn’t specify this correctly earlier.
Also, the profile ID won’t appear there because a VID can be used in several profiles but a profile can use only one VID, so, that’s why this property must be included in the device profile.

I haven’t received the confirmation from the team but I don’t think the correct info of the profile will appear in that page.
To confirm the configuration you need to use the CLI as well:

smartthings deviceprofiles profileID -j or -y

Just to confirm we’re on the same page, here’s the process to create a device profile and its config:

  1. Create your device profile, you can only specify the capabilities used:
smartthings deviceprofiles:create
//You can also create it from a file adding -i profile.json or yaml
  1. Generate the device-config file which takes the list of capabilities in the device profile and puts them in each view.
smartthings presentation:device-config:generate profileID -j -o=deviceConfig.json
  1. Edit the file to add your custom configuration (change enums available, numbers range, etc.). You can also leave it as it is, then, create the device presentation to get its VID:
smartthings presentation:device-config:create -i deviceConfig.json

In the result of that command, you’ll see the VID and mnmn that you’ll use later.
4. Edit the device profile and add the metadata property with the correct VID and mnmn. This is an example using the YAML format:

name: multi-switch
components:
- id: main
  capabilities:
  - id: switch
    version: 1
  label: Main
  categories:
  - name: Switch
metadata:
  vid: xxx-xxx-xxx
  mnmn: SmartThingsCommunity

//command:
smartthings deviceprofiles:update profileId -i deviceProfile.yaml
  1. After this, you can use the profile normally but other users won’t have access to it unless it’s published. If you rather ask users to create it, they just need to do it using the final config (metadata included). The device presentation (VID) isn’t linked to an account so others can use it on their side.

Thank you @nayelyz for the complement of information. I could do all the steps and successfully create the device profile and device config following your instructions.

However, and although verification with deviceprofiles --yaml and presentation:device-config --yaml confirm that all parameters are taken into account, the momentary button does not appear on the mobile app’s dashboard widget.

Before going any further, I must admit my original problem is solved as you explained that I can publish a device profile to let other users use it without creating it on their side. I will then create my final device profile in the Developer Workspace (which is the only way that works 100% for me) and publish it.

Still, in an attempt to build an overview of my recent experience in the hope it’s of any help to you and the SmartThings teams, I tried to summarize all my results in the table below, comparing the 3 methods discussed in this topic:

  • Manually via the web-based Developer Workspace
  • Using the SmartThings CLI with the method detailed just above this reply, which I understand is the recommended way
  • Using the SmartThings CLI with the method I experimented in the first message (deviceprofiles:view:create)

This table shows that in my experience, information obtained via the Developer Workspace is relatively consistent with the final result, in opposition with presentation:device-config --yaml.

All YAML files I used are available here: smartthings-openweather-sensor/smartthings at main · Konnichy/smartthings-openweather-sensor · GitHub

Manually via the Developer Workspace Separate device profile and device config via CLI Combined device profile and view via CLI
Developer Workspace’s “UI Display” tab State: “Temperature Measurement”
Action: “Momentary”
State: “Connection State (Default)”
Action: “Do not display any”
State: “Connection State (Default)”
Action: “Do not display any”
Developer Workspace’s JSON
Section dashboard:states
[{
"component": "main",
"capability": "temperatureMeasurement",
"version": 1,
"idx": 0,
"group": "main",
"composite": false
}]
[{
"component": "main",
"capability": "temperatureMeasurement",
"version": 1,
"idx": 0,
"group": "main",
"values": [],
"composite": false
}]
[{
"component": "main",
"capability": "temperatureMeasurement",
"version": 1,
"idx": 0,
"group": "main",
"values": [],
"composite": false
}]
Developer Workspace’s JSON
Section dashboard:actions
[{
"component": "main",
"capability": "momentary",
"version": 1,
"idx": 0,
"group": "main"
}]
[] []
deviceprofiles --yaml id OK
name OK
vid OK
mnmn: fYgO
mnid: fYgO
mnId: fYgO
id OK
name OK
vid OK
mnmn: SmartThingsCommunity
ocfDeviceType: oic.d.thermostat
id OK
name OK
vid OK
mnmn: SmartThingsCommunity
ocfDeviceType: oic.d.thermostat
presentation:device-config --yaml N/A dashboard:states OK
dashboard:actions OK
detailView OK
automation:conditions OK
automation:actions OK
dashboard:states OK
dashboard:actions OK
detailView: []
NO automation
Mobile app widget with_momentary
Temperature OK
Momentary OK
without_momentary
Temperature OK
NO momentary
without_momentary
Temperature OK
NO momentary
Mobile app detailed view Temperature OK
Humidity OK
Momentary OK
Temperature OK
Humidity OK
Momentary OK
Temperature OK
Humidity OK
Momentary OK

Well, I guess I was too fast. It seems I can’t publish reliably with the CLI a device profile created with the developer workspace. Although its status becomes PUBLISHED in the CLI, nothing changes in the developer workspace (a padlock appears when publishing a CLI-created device profile). I can even still edit it.

I know I shouldn’t mix developer workspace and CLI, but as detailed above I cannot get the momentary button on the dashboard action with CLI only. And since I cannot publish a device profile created in the developer workspace, or even one created with the CLI but then edited in the workspace to get the dashboard action button enabled, I am stuck again.

It doesn’t let you save the changes:

What do you mean? You can publish device profiles created in the Developer Workspace, it doesn’t cause an issue like editing its configuration and presentation alternatively on both sides. It just changes its state.

In this section, it must have the capability momentary included in the device-config before you create the device presentation so the capability presentation of this capability is retrieved there. If it was empty or had a capability that doesn’t have this view defined, it will show nothing in the dashboard.
In the Developer Workspace, this section is configured when you select an item here:

If the presentation is incorrect, the button won’t appear in the app. For example, consider the following device-config content:

{
    "type": "profile",
    "dashboard": {
        "states": [
            {
                "component": "main",
                "capability": "momentary",
                "version": 1,
                "idx": 0,
                "group": "main",
                "values": [],
                "composite": false
            }
        ],
        "actions": [ /*This is the section that configures the button showed in the dashboard view*/
            {
                "component": "main",
                "capability": "momentary",
                "version": 1,
                "idx": 0,
                "group": "main",
                "values": [],
                "composite": false
            }
        ]
    },
    "detailView": [
        {
            "component": "main",
            "capability": "momentary",
            "version": 1,
            "values": []
        }
    ],
    "automation": {
        "conditions": [
            {
                "component": "main",
                "capability": "momentary",
                "version": 1,
                "values": []
            }
        ],
        "actions": [
            {
                "component": "main",
                "capability": "momentary",
                "version": 1,
                "values": []
            }
        ]
    }
}

This is the output we should see in the CLI, the dashboard.actions isn’t empty:

And, we can verify the configuration was correct by querying the presentation content:

smartthings presentation vid -j or -y

Pro tip: When working with custom device presentations, check the capability’s presentation as not all have the three views configured (dashboard, detail, automation). So, even if you include them in the device config, they won’t appear.

Hi, @Konnichy

I talked to the team about this issue of the Developer Workspace and they replied that we are aware that something is broken in the view iplementation. We haven’t fixed it because there are plans to replace the view stuff with a new embedded device config.