Custom capability with list of supported commands


I’d like to create a custom capability that can be used by different devices.
Some devices support only a subset of commands. I think I need something similar to windowShade’s supported commands, where the device during initialization will provide the list of supported values/commands.
Is such functionality supported for custom capabilities?

My use case is for wall switch backlight support.
There are 2 values (on,off) that are supported by all devices. However, some switches allow the third mode, where the color of backlight changes, depending on the switch state.
I’d like to allow setting the third mode only for devices that actually support it.


IMHO the backlight color belongs to the settings page as users will not change this setting often.

Also please think about 3rd party integrations.
I am afraid that the custom capability is not discoverable for Alexa/Google, so even basic on/off feature will be unavailable for users.

@veonua ,
Thank you for your replay.
I personally don’t see any problem displaying rarely used capability in detail view.

On the other hand, putting it into settings would mean the following:

  1. The current state of the device can not be
    queried/updated. This means the setting shown in settings page might not reflect the actual device state/configuration
  2. It is not possible to control backlight from automation.

Further, I think backlight logically fits better into capabilities model. It is actually a capability of the device, not its configuration.

1 Like

it can’t be true. settings are just a permanent storage under the hood so you can query update fields as you like.

It is not possible to control backlight from automation.

It’s an interesting case, never thought it would be popular to use the backlight in automation.
Just curious what kind of device it is.

In theory, yes. However even some of the most basic functionality of capability presentations that I’ve been waiting on since day one doesn’t seem to have be implemented yet (like using basic commands instead of setter commands) so I have no idea what actually works. @nayelyz and @erickv know stuff like that, and some other developers might have touched upon it.

Anyway the bottom line seems to be that for the list display types you can use the supportedValues key. That should be set to an attribute value of your choice that holds an array of the commands (so I guess the equivalent of supportedButtons or supportedWindowShadeCommands).

So in a Detail View the structure would be:

"detailView": [
    "list": {
      "command": {
        "name": "setDoor",
        "supportedValues": "supportedValues.value"

In the Automations it would be:

"automation": {
    "conditions": [
            "list": {
                "supportedValues": "supportedValues.value",
    "actions": [
            "list": {
                "supportedValues": "supportedValues.value",

I think that’s right anyway. Certainly supportedValues is the magic word that should help you find information.

1 Like

The difference would be in which enums for the command you can select? Eg. In windowShade you can select that in the list only appear the options “open” and “close”.

The option mentioned by @orangebucket is correct,supportedValues should be an attribute in the capability (it won’t be displayed) and it allows you to change the available alternatives for each device without having to create a specific device-config.

You can check other similar capabilities like thermostatMode as a reference.

@nayelyz ,
Thank you.
That is correct, some devices will show a subset (on,off), while others will show all three options (on, off, state).
I already looked at windowShade and thermostatMode capabilities, I just wanted to make sure that supportedValues attribute can be used also for custom capabilities.

No problem! Let me know how it goes :smiley:

1 Like