@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.
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
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.