I’m new to Home Assistant and do not really understand a thing here. I have configured several things in the configuration.yaml. I have also a few things I have configured from the UI. Where are those configuration stored?
E.g. I have a couple of MQTT sensors in my configuration file. I have also added a few ZigBee sensors via the UI. It works but I don’t really understand where the config for those ends up.
Can someone please point me to some documentation that can help me understand?
To clarify what christoph said : -
Don’t mess in the .storage folder - you REALLY need to know what you are doing to go in there.
The ui writes to that location so do any changes through the ui.
If you prefer to take manual control you can set your dashboard to yaml mode and write your configuration to configuration.yaml (and associated files)
Thanks for the quick answer!
I have´no intention to edit anyting in thge .storage. I just wanted to understand where the conmfig ended up. I also realize what the customize now means. I read about it but missed the context.
My interpretation is that I can add e.g. sensors via the gui. Then I have two option for customizing them; either in the gui with its limitation or in a cutomize yaml file. Right?
Yes. So you enabled either Zigbee Home Integration (ZHA), deCONZ, Zigbee2MQTT, Philips Hue or MQTT (with dedicated Zigbee2MQTT installation) and they created devices with entities.
Sorry, who was that last post meant for ?
This is your topic so you get notifications on all postings.
Others only get notifications if you specifically reply to an individual.
There are many ways of doing the same thing in HA, I don’t use custoize.yaml as I have packages.
This is just another way to store the same information but all my music config is in my media.yaml file (input numbers, texts, datetime, boolean also sensors, binary sensors, customisations, scripts and automations) I have heating.yaml for my heating, I also break down the house into rooms so my lighting for bed 1 is in bed1.yaml etc.
A standard HA install has no sensors at all, they are added by integrations and some of those you configure from the gui and some from editing yaml (some both, but not many)
The most basic and useful sensors are the time and date sensors
Are you after something specific ?
I did also add a few MQTT sensor but only in the configuration file. Is it a better practice to integrate them via the gui and customize them only in the file (or in the gui)?
Now I did everythiong in the config file.
I would love to keep it this way, as it allows provisioning fresh installations, but unfortunately more and more integrations becoming “ui only” configurable.
I think I have I have seen many ways to setup different parts in HA and I have not yet figured out how I should do it in the best way.
I have started to divide the config into several files. That is helping me structure the configuration.
When I read the documentation I see several ways to solve a situation but it is hard for me to understand which I should chose for my case.
@Mutt: Could packages be a possible option to provision fresh HA installations? How would I enable / configure an integration, which uses UI config-flow (like: Philips Hue)?
No need to tag, you can just reply to me (the reply button in the lower right corner of any post)
Time was when everyone started with just the configuration.yaml
This got unwieldy for most people so the use of yaml anchors allows them to split things up. (it still reads as one file from the yaml point of view)
This has now been adopted as standard so all new installations come with an automation.yaml and a script.yaml for the gui to write those items to, same with costomisations etc.
You can add sensor.yaml and binary_sensor.yaml if you so desire (look it up in the docs)
There is no single best way and many people change their approach as their needs change.
Packages are quite advanced but due to the fact that all my indentation is the same wherever it is (eg an action indentation from an automation is the same (for me at least) the same as a sequence indentation in a script) I can cut and paste with impunity across many different areas (then just change the names of the usual suspects).
Many new users prefer to use the gui so don’t get their hands dirty with yaml.
But the editors are not perfect and like the time date sensor mentioned previously will require a little yaml work.
Read the docs on “splitting up your configuration” take it in small steps, backup before you do anything major and go at your own pace.
Christoph, probably - there’s not much you can’t do with packages. I got into it when I needed the same suite of automations (and support ‘stuff’) in multiple rooms. Write once, copy the file, change its name, edit the file to replace all instances of bed1 with bed2 (you get the idea) and then restart (some things do still require a restart) and off you go.
(this sort of activity requires careful thought about naming conventions) @Burningstone knows far more about the hue integration than I do
You can’t do this in YAML, that was one of the main points people were so offended by the change from YAML to UI for adding integrations. When you deploy a new system you need to click through the UI, you can’t import a YAML file and it will fill out the config flow, you need to set it up again through the UI. You don’t have a good version control (you can store .storage in your version control system, but unfortunately .storage doesn’t distinguish between static and dynamic info, meaning there are also states in there which the system uses to restore after a restart).
I know probably as much as you do, I haven’t used the Hue integration for over 3 years, because I ditched the Hue Hub in favor of a generic ZigBee stick.
I stand corrected and I’ve learnt something. Thanks
(knowledge trumps ignorance every time )
@m0wlheld there are many users here who understand the need to Simplyfy HA to bring in new users, but are being ‘inconvenienced’ by the move away from yaml (their equivalents are stored in JSON format in the .storage folder and JSON to yaml (and visa versa) converters are simple but easy human readable formats sometimes get mangled (no excuse, just the decision they made).
It’s akin to the point above about bed1 to bed2 - you want an alarm clock, I have an alarm clock, I send you the package file, instruct you about any sensors you need external to the package (time date sun etc). I can even give you a lovelace snippet for a card to go into your frontend. 10 mins and you are done - Shiney New Alarm Clock !
Now how do you do the same just using the frontend ?
I know this is really old - but I really wish that HA would poke around the config files from the interface this is much simpler …
It would be nice for example to create a single input number in the interface and then be able to copy and past it (with a few changes) in the config file…
I have solar panels and want to create 3x sensors for each one… I have > 20 panels.
So this would mean creating 20 helpers that can either:
NOT be managed through the interface (if I set them up in the config)
OR creating everything through the interface that will take hours
)