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

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

[mime24]

Hi, I stumbled across this thread because I am looking for a solution for nested schema.
Here is an excerpt of my application:

schema:
  inverters:
    - serial: str
      monitor_sn: int?
      node_id: str
      suggested_area: str
      modbus_polling: bool
      client_mode_host: str?
      client_mode_port: int?
      strings: 
        - string: str
          type: str
          manufacturer: str

Do I understand correctly, the new “configuration:” would bring support for nested options. But as it is in "open" stage it is not yet implemented and usable?

[lmagyar]

Another issue with the current add-on config UI is that it doesn't show unused optional configuration options grayed out, but shows them as false or empty, leading to lot of user complaints and wasted hours figuring out what is going on.

Example:

• 2 bool? optional config options, and the default is true for both if they are not specified
• user wants to disable option1
• user unhide the optional config options, and see they are already off (not gray), user enables option2, save, restart
• but in reality only option2 goes into the yaml, with true value, what is already the default, so basically nothing happens
• user spends hours on forums, finally edit the yaml or creates a github issue, that option1 is broken