Splitting yaml files , access to secrets in ESPHome subfolders

sorry for jumping in this conversation but I have to ask: does this mean that I willl end up with two secrets.yaml files? one for the main configuration.yaml and one inside the esphome folder? is this allowed and this is the way things are supposed to be setup? I am really new at this and I am trying to organize the configurations so I can manage future device integrations.





However if you include this line in the secrets.yaml file that is in the esphome folder:

<<: !include ../secrets.yaml

This will pull all the secrets from your existing secrets.yaml file in the /config folder.

So you can enter the esphome specific secrets in either file, but both must exist.

Also if your home assistant secrets file is not in the root of the /config folder you would have to adjust the include path in the esphome secret file.

Yes, you end up with two secret files. One for hass and one for esphome.

thank you! this is a very clear explanation!

thank you! I understand now!

Hi, I dont think the solution of referring the base secret file from the esphome secret file is straight forward. At least I was not able to make it work the way Otto Winter suggested and how @tom_l has suggested here.
Please see this thread where I raised this issue and ultimately fixed it by compiling a custom version of esphome by making a simple change in the dockerfile. I know everybody may not want to compile a custom version of esphome but then i couldnt make it work any other way.

1 Like

It is if you are running the esphome addon.

Well , maybe you’re right but I wasnt able to make it work when I was running it as an addon in hassio. I always got this error:

cannot merge mappings; the provided source object is unacceptable at line 15, column 58:
     ... assio/homeassistant/secrets.yaml

ESPHome does not look the the secret file there. There is an ESPHome folder in your config dir, after installing ESPHome. You have to add the secrets file there for the items you want to use in the ESP config.

Hi @Lifelogger , that’s exactly I don’t want. I don’t want to maintain two different copies of secrets. I have one secrets in the home assistant config folder and i want to refer to that in esphome. And that’s what I have achieved by what I wrote above.

Ah ok. Didn’t read it properly I guess. :slight_smile:

I’m having a similar issue.

I have yaml files in esphome root and the secret.yaml


and i included some packages in node1.yaml:

  wifi:                   !include common/wireless.yaml
  tempsensor:     !include components/sensors/dht/dht11.yaml

Now i’m unable to reach secrets.yaml located in esphome root from common/wireless.yaml

I tryed this in wireless yaml

<<: !include ../secrets.yaml
  ssid: !secret wifi_ssid
  password: !secret wifi_password

but the log reports that is still searching the secrets.yaml inside the /common folder instead of the secrets.yaml located in root.

Could you please help me?
thank you

Your only option is to compile your own version of esphome with the change i mentioned above.

1 Like

Thank you, I hoped something changed in the meanwhile.
The strange thing is that in this official guide:
Configuration Types — ESPHome
The above example about packages it suggest that may work.

Am I wrong or it is an error of the documentation?

hi, unfortunately I’m unable to reach the esphome secret file from any subfolder.
I’ve tried to do so packages but without success.

The way I’m doing this is to assign the secrets to substitutions in my main file and then just use the substitution variables everywhere else.

That works. Mostly. I think I found one case where it didn’t work and that was for the esphome.build_path.

could you please write an example?

thank you

Hi, I provided most of the files in another post.

1 Like

I see you put secrets.yaml in a subfolder with wifi.yaml. In this way works also for me. What I’m unable to do is reaching secrets.yaml from a subfolder (/common/wifi.yaml).

The secrets file has to be in the same folder as the yaml.

I’ve changed my config now so that all the secrets are in the root. The root yaml accesses them in substitutions. Other yaml files can use substitutions more easily.