Splitting Up customize.yaml

Configuration
1

I’m attempting to split my customize.yaml into two files. I have some entities which I’ve customized that I don’t want readable. For example:

public.entity_id:
  friendly_name: Public Entity ID
private.secret_id:
  friendly_name: Don't Look At Me

Ideally, this would be split into two files, such as:

customize/public.yaml

public.entity_id:
  friendly_name: Public Entity ID

customize/private.yaml

private.secret_id:
  friendly_name: Don't Look At Me

Unfortunately, I cannot figure out how to do this reliably. With the following solution, only one of the files seems to get loaded:

customize: !include_dir_merge_named customize/

Help appreciated, thanks.

2

I’m not sure how/why, but this is now properly working for me. Ah well, sorry folks.

3

It is not clear that you are aware of secrets.yaml

2 Likes
4

Well, my problem is that my entity IDs themselves contain information I’d rather not commit to a Git repo. Specifically the haveibeenpwned component.

5

You can access any entry from the secrets.yaml file, it doesn’t have to be a password.

1 Like
6

I don’t think you understand my problem. The entity ID being generated by haveibeenpwned has an approximation of an email address in it, and I would rather not commit that entity ID to git because it’s not an email address which I control. However, I would also like to put that entity into my customize.yaml to attach a friendly_name:

sensor
  - platform: haveibeenpwned
    email: !secret haveibeenpwned_email_addresses

This generates entity IDs in the following format:

sensor.breaches_someonegmailcom

Are you saying that the following setup would work?

secrets.yaml

breach_entity_1: sensor.breaches_someonegmailcom

customize.yaml

!secret breach_entity_1:
  friendly_name: "Someone's Email Address"
7

This is correct, I was merely making sure you were aware of all the possibilities and not spending time re-inventing a wheel.

I’m not sure if that will work in secrets file - it is certainly an edge case, but it would be interesting to see if it does.

8

This is correct, I was merely making sure you were aware of all the possibilities and not spending time re-inventing a wheel.

Gotcha, and thanks.

FWIW, splitting my customize.yaml into separate files and using !include_dir_merge_named seems to have fixed the problem. I just used a .gitignore line to block out the private file. Along the way I learned that it won’t load a file using !include_dir_merge_named if the file is named secrets.yaml.

1 Like