YAML configuration to leverage the same infrastructure than UI entities

[nitobuendia]

Context

Issue #399 discusses about the possibility of allowing YAML configuration. On this issue, we discuss one of the possible ways of implementing YAML Support with minimal cost.

As I understand, YAML Configuration is still required for some integrations. As such, YAML entry points like async_setup_platform will still be supported by core. Hence, the main cost of supporting YAML is the specific cost of each component to add a config flow.

This issue proposes a solution which significantly minimizes and centralizes the cost.

Proposal

The overall proposal is that YAML configuration leverages all the same infrastructure that UI flows leverages. In more detail:

1. YAML and .storage entities will use the same data structure for all static configuration data.
2. Dynamic data (e.g. refresh tokens) can be stored in .storage. Config flows may require merging dictionaries.
3. YAML will add version as a parameter, which will allow to translate set up between versions with the same async_migrate_entry.
4. UI Config Flow can/will be used to do a first set up of integrations if not all data is known. For advanced users, the final data can be shown by config flow. See example for Hue.
5. async_setup_platform and async_setup_entry will read the configuration and use the same flow to start the device. (Similar to how cast works today or this PS4 example).

Consequences

First of all, this solves all the problems introduced by the deprecation of YAML on device integrations which is being discussed on this issue.

Second, this improves the issues and cost for contributors to maintain YAML configuration by:

1. Maintain a single data structure for both .storage and YAML entities.
2. Leverage and maintain one single device entry flow.
3. Allow YAML to work across versions even when underlying schema changes.
4. Reducing or eliminating documentation on how to obtain data for YAML, as UI provides that.

[balloob]

Thanks for your interest in this topic but this is not something that we would consider right now.

[nitobuendia]

Hi @balloob, in order to respect the time that has been invested in bringing this proposal, could you kindly elaborate what's wrong with this proposal or why is this "not something that we would consider right now"?

If this is related to ADR-0010, there's an open discussion on #399 on this topic and this is a very needed complement to it, as the HOW matters for the IF.

Additionally, even if it's not something that you would consider right now, where's a good place for discussions? Community does not seem the right place and this is the official channel for architecture decisions.

Thanks for caring about the Open Source community.