Feature request: Confirm dialogue

[Karstensson]

One feature I'd like to request is a confirmation on entity activation. For example if I have a toggle/tap service that unlocks the door/opens garage door or similar it could be used. The confirm action should require a physical button press. The reason is to not to be able to accidentally trigger such entities by "ghost touches" by for example rain.

[philipabbey]

We think we have a way forward for this using built in classes.

[JosephAbbey]

So, regarding the config schema, we should try to match the schema of lovelace as much as possible but we don't want to affect those currently using the app too much:

Option 1 (less schema churn):

{
  "type": "tap",
  "entity": "script.test",
  "service": "script.turn_on",
  "name": "Test!",
  "confirm": true // optional (Boolean or Null)
}

Option 2 (closer to homeassistant):

{
  "type": "tap",
  "entity": "script.test",
  "name": "Test!",
  "tap_action": {
    "service": "script.turn_on",
    "confirm": true // optional (Boolean or Null)
  }
}

"confirm" defaults to false (obviously).

Regarding implementation, we should be able to use the builtin WatchUI.Confirmation dialog which will already be optimised for all devices.

[philipabbey]

As you say, I'm worried that Option 2 means schema churn. Its a pity that we did not think ahead a bit more when adding the service field and put it inside tap_action ahead of time. As a consequence I favour Option 1.

Does that preference then land us in trouble going forwards? Will we wish we had bitten the bullet sooner and mirrored the HA schema more carefully? If so, we go for Option 2 without breaking the existing use of service field outside of tap_action, and upsetting users. That just means continuing to support the earlier schema too, even if it is no longer advertised.

[JosephAbbey]

After a discussion, we have decided to move forward with option 2, while still supporting the previous service property as a fallback. This way we keep closer to Home-Assistant.

The confirmation property will be available as tap_action.confirmation.

We plan to maintain backward compatibility far into the future so that we do not break user's configurations.