Location of the configuration.yaml file

Guys If i see another tutorial that starts with Pi this and pi that im going to cry. I followed all instruction how to install home assistant on windows 10 but can not find a why to find or config the yaml file. WINscp can not log into the 192.168.8.103:8123 default address since its not a remote linux pc its that same machine.

Please point me to the page where setup has to do with windows and windows only. Im trying to setup a mqtt client on the windows server that will communicate with a lora linux based gateway.

On the About page on your HA Gui you should see where the config file lives.

3 Likes

Thank you !

I try to look for the “About” section, but where is that? I have tried to look everywhere.

You are reading a post of 2017. Things have changed a lot since then. This information is now under developer tools -> info

I’m constantly reading docs and posts that seem like nonsense because “Things have changed”. Is there a doc that can tell me what docs are still true?

Oh, yeah, in 2021 there doesn’t seem to be a Developer Tools -> Info @francisp . States, Services, Templates, and Events is all I have.

Yes. The official documentation.

‘info’ is now under configuration.

You’re replying to a 3 year old thread, that was ancient history the last time it was exhumed 9 month ago, in homeassistant terms that’s prehistoric. Follow the official documentation and keep your homeassistant up-to-date, the docs always refer to the latest version.

I’m starting to think 10 minutes is ancient history in HA land. I mean, this “configuration.yaml” file in the subject of this thread, a file referred to in a billion spots in that “ancient” documentation – does that file even matter any more? I see it in /config and it doesn’t seem to hold anything of interest. I have a /addons directory that’s empty. My guess is that all the flat YAML configuration was migrated to the database, but that’s just a guess.

C

Home Assistant is definitely under rapid development and it gets better and better with each release. Yes, sometimes the official docs lag behind a little bit but for the most part they are accurate.

The configuration.yaml file is quite necessary, even if you personally find it uninteresting.

No, I didn’t “personally” find it uninteresting. I found it personally fascinating, but I thought it might be technically uninteresting because it seems to just point to a bunch of empty files. This led me to conclude that the real configuration data (all that stuff I typed into the GUI) was elsewhere (where?) The “documentation” doesn’t say. My guess is database. But that’s just a guess.

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

A lot of the stuff you’re typing into the GUI ends up as JSON files in hidden storage folders.in the config directory. But at the end of the day everything (except lovelace) ends up being put together as one big configuration.yaml file. It is THE system file. Without it HA really has no idea where to find anything.

For simplicities sake, most people split up their configuration.yaml file into lots of other files to keep the system organized. That is what the !include directive is all about. You are including that code in your configuration.yaml file. The bigger and more customized your system gets, the more you will include in that file.

Thank you for confirming that the configuration.yaml is still a “thing”. I can see there must be at least two or three other places that configuration hides – like where does all that detailed device library data for things like OpenZwave hide, I wonder. Some HA zwave docs suggest it’s in the /addons directory, but that directory is empty for me, so it seems to be “ancient history”. But that’s just a guess.

I’ve been watching some YouTube tutorials and several of them start with “A lot has changed. My old tutorial is no longer valid so I decided to make a new tutorial”. Now that I’m getting a sense of the rapid flux of change, I’ll know better how to approach things.

I will say that it’s amazing how big and active the HA community is. I’ve been involved in a lot of open source projects and this one has to be one of the most dynamic I’ve seen. Maybe that’s ultimately a good thing? But a core of stability is also a good thing.

C

The general ‘thing’ of homeassistant hasn’t changed much, but things move around (like the info screen) and a lot of configuration is now done via the ui so the details of it end up in a hidden directory.

But at the end of it it’s still a platform for taking a trigger and completing an action.

If you’ve watched a video and thought ‘that looks easy’, the chances are it’s actually even easier now, but the video is pointing you to the wrong place, which makes it confusing (and therefore feels harder).

Try to treat videos as a ‘general feel for what homeassistant can do’ rather than an instruction manual :slightly_smiling_face:

A big part of the “general feel” for me is knowing where everything generally is. I don’t worry about the details of what exact config data is needed till I know basically where everything goes.

chances are it’s actually even easier now

A couple of months ago I decided to swap my SD card because it was coming up on it’s second birthday (Yes, I’m still on an RPi with an SD card… but my “Blue” is supposed to ship in March!) Anyway, I decided to rebuild my system from scratch (except my automations and scripts of course) just to try out the new onboarding process.

I was extremely impressed with how much easier it is now than it was a couple of years ago. Everything went without a hitch. I had my system completely rebuilt in a couple hours including my zwave network with 50ish devices. HA has definitely come a long way. Everyone has done a fantastic job.

1 Like

It’s still pretty overwhelming for a beginner, I can testify. I wonder what I’ll be saying to people three years from now. I also wonder if HA will still exist. I’m old enough to remember X-10, so I have experience with Smart Home technology that never lives up to its initial promise.

In contrast, I have some always-on linux and BSD systems that “just work” and haven’t been rebooted in years. So it IS possible to make things that are stable and reliable.