"Export" auto discover to configuration.yaml (and others)

Feature Requests
1
  • Doing things manually is great
  • Having discovery is great
  • Having auto-configuration in Lovelace is great

Mixing them could be better.

I would love a “commit UI to config” button
even if it just pushed everything in to a monolithic configuration.yaml file (but making use of sensors.yaml and other config files would be ideal)

This way, I could set up a new device, have it auto-discovered, commit the device to config files, then tweak (if needed) and have all the benefits of manual config

2

It is a nice suggestion, but it has many issues realising, one of them being that many integrations have ended support for configuration.yaml in favour of config entry support. If a component supports both configuration.yaml and config entry it would still end up back in as a config entry since configuration.yaml entries are imported to config entry system.

3

Not only do I make config files a .git repo to backup and track changes, but when things move out of .yaml files, they move out of our hands and over the years I’ve found that having systems be out of our hands means that when the inevitable problem happens the solution is also out of our hands.

I would be willing to self-manage collisions for said integrations if it meant keeping the ability to keep configuration in .yaml files.

3 Likes
4

This is up to each developer to decide what works best with each integration. It’s not a one size fits all solution

5

Doesn’t it bother you that the config is splintering?

I’m just a user, and I’m sure there are a lot of things going on behind the scenes that I don’t see, but I also know the benefit (and at scale: the requirement) for patterns like single source of truth.

It’s all well and good to back up the whole config folder as a precaution, but things like “find and replace” when you change your mind, UI tweaks, “starting over from scratch except for ____”, cleaning up entities, cleaning up configurations, and so-on (aka the stuff that ‘advanced’ users tend to do as they work through a system)

All these get a lot more complicated when there’s no single source of truth.

3 Likes
6

Bothers most of us. Unfortunately us being bothered doesn’t mean anything to those in charge.

7

It’s splintering but the end goal is to remove yaml :wink:

8

How exactly?

If they are added to the config entry, it’s just a JSON file. You still have control over the JSON file if you so desire.

9

Three reasons:

  1. Everything in the .storage directory is designed to be over-written by homeassistant. During UI config changes, during shutdown, etc. This takes it directly out of the user’s control (though as you say, we can take some of that back)
  2. As it stands, homeassistant must be shut down in order to modify these entries and have them re-read on startup (I may be wrong on this, but it’s been my experience)
  3. There’s no reason to believe that config entires will stay in text files. They could just as easily choose to move them to the DB in future.
10

If the end goal is to have a different single source of truth that’s

  • Editable by (advanced) users
  • Based on flat files as opposed to being in the DB
  • “File-first” (user changes not overwritten by any automated homeassistant process)

Then I’ll suffer through the growing pains of the current splintering with the knowledge that it will all work out in the end

11

No it doesn’t bother me since I’ve been a part of the drive away from only configuration.yaml. In my cases there have been no reason to not go the config entry path. Together with devices and config entry options.

Maybe not all integrations work as well yet with config entries. But it enables multiple improvements from a developer point of view

12

Would you mind going in to some detail about why config entries have been the clear winner for you?

13

Well the main thing the config entry brings is ease of use. No issues formatting configuration, when set up it stores a unique identifier that can be reused, which helps when a service or host changes address. Then the entry can be updated with new information automatically upon discovery of a new address. Configuration options are exposed from the front end, stuff like that

2 Likes
14

I was reminded of this thread when I recently went to reply to another in the community, and after some digging I’m still not sure what you implemented or what you mean from a user perspective.

I do know a couple of things:

  • Config entries are typically implemented by integration developers
  • Home Assistant loads the configuration files in to config entries at boot, making config entries the single source of truth (this seems absolutely true, but any dev can enlighten me about cases where it’s not)
  • The ideal is to eliminate the yaml files, but they are not going anywhere anytime soon. (Side question: is it possible to start from scratch and have a yaml-free Home Assistant today?)

But what are the next steps?

when set up it stores a unique identifier that can be reused, which helps when a service or host changes address.

This especially is very compelling because I have so many struggles with network-based presence detection in Hass.io.

But what can I do in current versions as an ‘advanced user’?

Can I add any of the following as config entries?

  1. Template sensors?
  2. panel_iframe entries?
  3. Groups?
  4. Notifications?
  5. The ability to enable things that I currently have as name: in configuration.yaml such as frontend:, history:, ios:, logbook:, history:, etc ?

And if so, how can I do that?
Do I need to create my own integration or modify the relevant code and submit a PR?

15

This transition is going to take years, there’s almost 2000 integrations. Sit tight or help out by moving things from yaml to the UI. Also keep in mind that some integrations won’t be transferable because the config flow helpers do not exist. Also keep in mind that some integrations may never move to the UI if config flow doesn’t have the ability to create a good working flow.