Feature request: Confirm dialogue about garminhomeassistant HOT 4 CLOSED

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

from garminhomeassistant.

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.

from garminhomeassistant.

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.

from garminhomeassistant.

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.

from garminhomeassistant.