"mode" capability and "proposed" state

Developer Programs Support
1

We are looking at creating our own device profile with “mode” capability.

  1. Does “purposed” mean we cannot use it in production or it something waiting for approval or removal?

image
image923×366 11.9 KB

  1. if we use “mode” capability, how can we send the supported “modes” ? since discovery will contain only the profile id in “deviceHandlerType”
2

Hey, @aruna_t

  1. The proposed status means that the capability is under development. In this case, I tried to replicate your implementation and on the first try the Mode capability didn’t show up at the detail view when the state is populating the dashboard, so I’ll be looking for more information about this with the team.

Also, if you want to dig into the capability, I recommend you to setup the SmartThings CLI and run the following commands to get its metadata:

    # definition
    st capabilities mode --json
    # presentation
    st capabilities:presentation mode --json
  1. To send the supported modes over ST Schema, you’ll need to send an array of the modes at your deviceState.states, e.g.:
...
.stateRefreshHandler((accessToken, response) => {
    response.addDevice('external-device-1', [
      {
        component: 'main',
        capability: 'st.mode',
        attribute: 'supportedModes',
        value: ['mode_x', 'mode_y','mode_z']
      },

…by the way, welcome back = )

1 Like
3

Thank you for your reply. Your answer was very helpful. Didn’t know about SmartThings CLI

4

Hi @erickv

Please let me know if you found out why modes are not displaying in the app. I found the same issue as well.

Discovery

{"headers":{"schema":"st-schema","version":"1.0","interactionType":"discoveryResponse","requestId":"4BBB34B8-AC1E-4F4F-B72F-859F81DD3B72"},"devices":[{"externalDeviceId":"60a9443bfc79483f1ce53efe","deviceUniqueId":"60a9443bfc79483f1ce53efe","deviceCookie":{},"friendlyName":"Lightshow2","manufacturerInfo":{"manufacturerName":"SinricPro","modelName":"Custom Device","hwVersion":"1.0","swVersion":"1.0"},"deviceContext":{"roomName":"Bedroom","categories":["light"]},"deviceHandlerType":"d964e766-3124-4da5-98e9-869d02d277da"}]}

{"headers":{"schema":"st-schema","version":"1.0","interactionType":"stateRefreshResponse","requestId":"4BBB34B8-AC1E-4F4F-B72F-859F81DD3B72"},"deviceState":[{"externalDeviceId":"60a9443bfc79483f1ce53efe","states":[{"component":"main","capability":"st.switch","attribute":"switch","value":"off"},{"component":"main","capability":"st.mode","attribute":"supportedModes","value":["White","Blue","Aqua","Lightshow"]},{"component":"main","capability":"st.healthCheck","attribute":"healthStatus","value":"online"}]}]}

App:

image
image750×1334 51 KB

5

Hey, @aruna_t

I share this finding with our team and this issue is because the capability still under development, however, there’s a chance to update the metadata from a new Device Configuration based on your device profile. So, let me dig in and as soon as I get an update, I’ll share it with you.

For a better reference on how to generate the metadata from your device profile, check this CLI resource.

6

Hey @erickv

Just wanted to see whether you have any update on this?

7

Hi, @aruna_t

I retested the implementation and customization of this capability, and it is now possible to define your own modes.

To support your ["White","Blue","Aqua","Lightshow"] modes (at least at API-level), you’ll need to patch the Device Configuration that has been prepared for your device profile. So, do the following through the ST CLI:

  1. Extract the current device config:

     st presentation:device-config:generate \
 <DEVICE_PROFILE_ID> --json --output config,json

  2. Open the output file and from the detailView array, replace the reference of the capability Mode with the following:

        {
            "component": "main",
            "capability": "mode",
            "version": 1,
            "values": [
                {
                    "key": "mode.value",
                    "enabledValues": ["default", "x"]
                }
            ],
            "patch": [
                {
                    "op": "add",
                    "path": "/0/alternatives",
                    "value": {
                        "key": "default",
                        "value": "Default Mode"
                    }
                },
                {
                    "op": "add",
                    "path": "/0/alternatives",
                    "value": {
                        "key": "x",
                        "value": "X Mode"
                    }
                }
            ]
        }

What it does is just to include those two alternatives as part of the configuration of the capability itself (and its presentation). Of course, you can add any key-value you need.

  1. Then push the patch into the server:

     st presentation:device-config:create --input config.json

Now, its time to update the device profile:

  1. Get your device profile config:

     st deviceprofiles <DEVICE_PROFILE_ID> --json --output profile.json

  2. From the device-config:create command, copy the vid and mnmn values and update the metadata section of your device profile, e.g.:

    "metadata": {
        "deviceType": "Light",
        "vid": "< VID_FROM_OUTPUT >",
        "mnmn": "< MNMN_FROM_OUTPUT >",
        "ocfDeviceType": "oic.d.light",
        "deviceTypeId": "Light",
        "ocfSpecVer": "core 1.1.0"
    }

  1. Push the update:

     st deviceprofile:update <DEVICE_PROFILE_ID> --input profile.json

Now, the next time you create a new device with that metadata reference, check its status via:

 st devices:status <DEVICE_ID> --json

and you’ll find the references.

As soon as I have more news regarding the rendering of this implementation, I’ll share them at this post.

1 Like