Ah OK, I think you may have skipped quite a few hours of learning here.
When you define your custom capability you define it with attributes and/or commands which then work exactly the same way as those for stock capabilities do.
When you are working with a stock capability like ‘Switch’ you define it in your code using capability "Switch". It has the attribute switch which takes the values on and off and also defines the commands on and off. When you click on an on/off button in the app, or use an automation, you are using the commands, which are implemented as the methods on() and off(). The actual value of the attribute is typically set in response to messages received in the parse() method using e.g. sendEvent(name: "switch", value: "on") (sometimes createEvent), or for devices that don’t communicate their current state you send the events in the on() and off() methods.
So suppose you have defined a custom capability ‘My Capability’. You will define that in your DTH using the namespace that gets allocated to you when you create the capability in the CLI, and the ID of the capability. So something like capability "ankletreehorse12345.myCapability". Supposing that has the attribute ‘currentState’ that takes the values ‘active’ and ‘inactive’ and the commands ‘setActive’ and ‘setInactive’. You will define the command methods setActive() and setInactive() and set the attribute using sendEvent(name: "currentState", value: "active") and sendEvent(name: "currentState", value: "inactive"). So basically the same approach as stock capabilities.
Now let’s look at the interesting bit of your capability presentation. I’ve given it a tweak to match the description above. It is telling the app to display your capability as a ‘toggleSwitch’ which is a type of on/off switch. As luck would have it, you’ve picked the same display type that I’ve been waiting on for the last how ever many months it is and it doesn’t actually work properly yet. However if it did …
"toggleSwitch": {
"command": {
"on": "setActive",
"off": "setInactive"
},
"state": {
"value": "currentState.value",
"on": "active",
"off": "inactive",
"label": "{{currentState.value}}",
}
}
The "state" section tells the app how to interpret the current state of your capability. From the top it says that the current value is the value of the currentState attribute, the value you want to correspond with the ‘on’ state of the switch is active, the value you want to correspond with the ‘off’ state is inactive, and you want the text description in the tile to be filled out with the value of currentState i.e. active or inactive. In theory you could have a label like "The current value is {{currentState.value}}" but last time I checked the extra text was being ignored. The double braces are signifying variable interpolation in a string, which is why you sometimes see {{currentState.value}} and elsewhere just currentState.value.
The "command" section says what is meant to happen when the button/switch is toggled. This doesn’t work at the moment. However what you do is define the command to be called when the button is being put into its ‘on’ state e.g. setActive, and for the ‘off’ state e.g. setInactive. So that would call the setActive() and setInactive() commands in your DTH.
Your original capability presentation has the extra entry “name” in the “command” section. That is used when your capability is defined with a ‘setter command’ instead of individual ones and the other entries define the arguments. So if you added "name": "setCurrentState" to the above your DTH would be called as setCurrentState("setActive") or setCurrentState("setInactive").
I think that is as much as I want to say on the subject at the moment.