RFC: Add-on configuration/option

[pvizeli]

Context

The current schema/options are going to limit how we can build the UI around.

Decision

We merge options and schema into a new configuration format:

"configuration": {
  "key": {
    "label": "key_trans",
    "advanced": true,
    "type": "string",
    "list": false,
    "optional": true,
    "default": ""
  }
}

Nested object:

"configuration": {
  "key": {
    "label": "key_trans",
    "advanced": true,
    "type": "object",
    "list": false,
    "optional": true,
    "object": {
       "key": {
          "label": "key_trans",
          "advanced": true,
          "type": "string",
          "list": false,
          "optional": true,
          "default": ""
       }
     }
  }
}

Translation and keys

translations/en.json

{
  "key_trans":
    {
      "name": "Awesome key",
      "description": "Awesome description"
    }
}

We can use the current UI generator to create a migration class for the old format for being backwards compatible.

[ludeeus]

~~We should have a "validate" key here as well to allow for complex validation~~ let the add-on itself handle that if needed.

[pvizeli]

We should only allow supported types `"type": "string" which is handled by backend. I think the format like the UI use to nest things should be good.

[pvizeli]

~We should have a "validate" key here as well to allow for complex validation~ let the add-on itself handle that if needed.

We don't process or store not validated content on the supervisor. How it works currently is perfect, just not good for making a nice UI

[adamoutler]

I like the idea. I'm a bit unclear on the goal or implementation. I have some questions:

• What becomes possible after the change?
• What is the change aside from combining the options and schema into a more complex object?
• Can you provide some proposed documentation to describe the new "object" object?
• What would this configuration look like in UI form?
• Why can't we parse, merge, or improve the existing json?

I'm a big fan of reducing the amount of work required. I'd personally prefer something like this:

"options": {
  "My First Key": {
      "type": [ "string" ],
      "default": "My First Value",
   "My Sub-Items Grouped Header": [
      "My Sub-item 1": {
          "type": [ "bool", "advanced", "optional" ],
          "default": true     
       }
      "My Sub-item 1": {
          "type": [ "int", "advanced", "optional" ],
          "default": 3    
       }
    }
  }
}

[aschamberger]

It would be great to have conditional options in the future and give the ? some conditions related to the selected value of a list and make it to a required. e.g.

"schema": {
  ...
  "interface_type": "list(ft12-cemi|tpuart|usb)",
  "serial_device": "device(subsystem=tty)?[interface_type=ft12-cemi|tpuart]",
  "usb_device": "str?[interface_type=usb]",
  ...
}

Or is there already a method to achieve the same result.

[ludeeus]

For the UI we now use the same selectors as blueprint/config_flow/services. When doing changes here now, we should start using selectors as schema options. Example:

schema:
  config_key:
    text:
      type: url
  packages:
    select:
      custom_value: true
      multiple: true

And we can then send that like {"schema":{"config_key":{"selector":{"text":{"type":"url"}}},"packages":{"selector":{"select":{"custom_value":true,"multiple":true}}}}} to the UI

[pvizeli]

This need today an improvement from our UI team with using selectors as well

[ludeeus]

Selectors are already supported in that UI.