[Custom capabilites] Issue with enum commands

@nayelyz / @andresg I believe I have a bug here when defining custom capabilities with enum commands. It appears to be looking for a command based on the value rather than the command. For most enums, this would be the same and would go unnoticed, but I saw this on a virtual sensor I am building. Here are the yml files I am using. I am expecting the close command to be called when I choose closed in the automation actions. Instead it is calling the closed command which I shouldn’t need to define.

Capability:

id: myId.virtualcontactsensor3
version: 1
status: proposed
name: virtualcontactsensor3
ephemeral: false
attributes:
  contact:
    schema:
      type: object
      properties:
        value:
          type: string
          enum:
            - closed
            - open
            - unknown
      additionalProperties: false
      required:
        - value
    enumCommands:
      - command: close ## <--- This should map the 'closed' value to the 'close' command
        value: closed
      - command: open
        value: open
      - command: unknown
        value: unknown
commands:
  close:
    name: close
    arguments: []
  closed: ## <-- Should not be needed
    name: closed
    arguments: []
  open:
    name: open
    arguments: []
  unknown:
    name: unknown
    arguments: []

Presentation:

dashboard:
  states:
    - label: '{{contact.value}}'
      alternatives:
        - key: closed
          value: Closed
          type: inactive
        - key: open
          value: Open
          type: active
        - key: unknown
          value: Unknown
          type: active
  actions: []
detailView:
  - label: Contact Sensor
    displayType: state
    state:
      label: '{{contact.value}}'
      alternatives:
        - key: closed
          value: Closed
          type: inactive
        - key: open
          value: Open
          type: active
        - key: unknown
          value: Unknown
          type: active
automation:
  conditions: []
  actions:
    - label: Contact Sensor
      displayType: list
      list:
        alternatives:
          - key: closed ## <-- Should call the enum command with value 'closed'
            value: Closed
            type: inactive
          - key: open
            value: Open
            type: active
          - key: unknown
            value: Unknown
            type: active
id: myId.virtualcontactsensor3

I would expect it to call the closed command because I expect the key to be the command not the target attribute value. I would expect to used close as a key to run close as a command.

I know there are enumCommands defined but I wouldn’t expect them to come into play here as not all capabilities have attributes, let alone ones with enumerated commands, so it would be very inconsistent.

Not saying it isn’t a bug, but if it is I find the buggy behaviour more obvious.

The key represents the enumerated value. The three possibilities are closed, open and unknown. You can look at the ST defined capability for a valve as an example. Mine is basically the same, just used in Edge

OK. This is the automation section of the valve presentation …

automation:
  conditions:
    - label: '{{i18n.label}}'
      displayType: list
      list:
        alternatives:
          - key: open
            value: '{{i18n.attributes.valve.i18n.value.open.label}}'
            type: active
          - key: closed
            value: '{{i18n.attributes.valve.i18n.value.closed.label}}'
            type: inactive
        value: valve.value
  actions:
    - label: '{{i18n.label}}'
      displayType: list
      list:
        alternatives:
          - key: open
            value: '{{i18n.commands.open.label}}'
            type: active
          - key: close
            value: '{{i18n.commands.close.label}}'
            type: inactive

As you can see, the alternatives for the conditions list are keyed on the possible attribute values (open and closed), and the alternatives for the actions are keyed on the commands (open and close).

The conditions list has a value defined that associates it with a specific attribute. The actions list isn’t associated with an attribute at all.

The enumCommands presumably comes into play somewhere, but it doesn’t seem to be here.

I agree with @orangebucket, the “key” is the one used, “value” is more like a label, it is not even included as an argument in the command (I made some tests using ST Schema).

I created the capability commonsmall09402.virtualcontactsensor3 and I only changed the section of “actions” in the presentation:

automation:
  conditions: []
  actions:
    - label: Contact Sensor
      displayType: list
      list:
        alternatives:
          - key: close
            value: Closed
            type: inactive
          - key: open
            value: Open
            type: active
          - key: unknown
            value: Unknown
            type: active

Now, the command called is close and in the case of Edge the corresponding handler will be called.
This is the command request I received using Schema.

{
    "externalDeviceId": "listwEnum",
    "deviceCookie": {},
    "commands": [
        {
            "component": "main",
            "capability": "commonsmall09402.virtualcontactsensor3",
            "command": "close",
            "arguments": []
        }
    ]
}

Also, I wouldn’t expect the list to work with enum values due to the sample shown in the documentation, I will verify with the team if the behavior I saw is correct so we can add this sample case to the documentation.

Note: for future reference, it’s highly unlikely that issues with capabilities occur only in Edge integrations, that’s why I separated the topic from the main Edge thread.

Thanks this makes a little more sense now. In the presentation, conditions use the enumerated attributes and actions use commands. How is enumCommands used in the capability? It doesn’t seem necessary if we need to reference the commands in the presentation anyway.

@orangebucket Where did you find the presentation? That was helpful

In CLI speak:

smartthings capabilities:presentation valve

I think that is right. I tend to pluralise the wrong thing.

It is tempting to think you are working with your own stuff in the CLI but you can see any publicly accessible capability and capability presentation, just as you can see any presentation and device-config.

2 Likes