ESPHome - refactoring secrets file

Feature Requests
1

Hi,

My secrets file has grown really big (250+ lines) and part of the reason is that for each ESPHome device it takes 7 lines with following details:

  1. Write a comment about the device (so that I can identify it)
  2. OTA password
  3. Fallback SSID
  4. Fallback SSID password
  5. API password
  6. API encruption key
  7. A blank line so that I can distinguish one device from another

The secrets file has gotten too big and it is clunky to scroll around it looking for a particular device or a block of devices grouped logically.

Please consider refactoring secrets.yaml for ESPHome if possible.
Thanks.

PS: I have about 40 ESPHome devices and planning to add more in coming months so this problem will likely get worse for me.

2

What do you suggest?

I also have these infos in the secrets, the difference is that I share them with all devices including a common.yaml file.

3
  1. you can use templating to use the device name as the fallback ssid, or as part of it.
  2. share the same data for 2. 4. 5. 6.
  3. if you do that… you are left with a file that is, a total of 4 lines no matter how many devices you add
4

How about !including one secret file per device?

5

I’m guessing they don’t like reusing passwords.

6

What’s the point of using the secrets file over a separate included file?

The only reasons I can think of die using the secrets file are for sharing devices, and reducing the amount of code that you repeat.

practically anyone who has access to your yaml file, has access to your secrets file.

apologies if I sound overly critical, I am genuinely curious

7

So that sensitive information is not leaked when sharing configs or backing up to github.

8

Hmmmm… what’s the point of having an SSID and password for each and every device written separately ? Do you have 40+ routers/wifi points?

9

By SSID I mean the fall back hotspot that a device creates if it cannot get on the home WiFi.

10

Ok, but that’s only one line per module. You can have same SSID for all modules, same wifi password and same hotspot password for all modules. I have currently around 15 modules and my secrets file contains one SSID name, one SSID password, one OTA username and one OTA password. That’s it. i have AP device name written on yaml of each module, since that’s not much of a secret.

1 Like
11

Would you mind to explain how do you make a “common.yaml” file include?

12
  • Example of what I include on each device
substitutions:
  devicename: device-name

<<: !include .common.yaml
  • Example of .common.yaml content
# Enable Home Assistant API
api:

# Enable logging
logger:

ota:
  password: !secret ota_password

packages:
  wifi: !include .common_wifi.yaml
  • Example of .common_wifi.yaml content
wifi:
  networks:
    - ssid: !secret wifi_ssid
      password: !secret wifi_password
  ap:
    ssid: "$devicename Hotspot"
    password: !secret wifi_ap_password

Both files should be at /config/esphome folder.

3 Likes
13

Similar to mine but I do not bother with the secrets file.

I do wish common files could be edited from within the addon though.

14

Many thanks! That’s exactly what i was looking for.
What’s even better: it’s possible to use this system for common sensors, too: i have reboot and rescan wifi in all my modules, so i added those two button definition in common.yaml file and it works like a charm!

1 Like
15

You can edit common.yaml using the Visual Studio Code add-on.

16

Here is my common code that is used and replicated across multiple devices.

########################################################
#Sonoff Basic code that is used with other config files
########################################################
substitutions:
  update: 60s

esphome:
  name: $name_of_board
  platform: ESP8266
  board: esp8285

wifi:
  ssid: !secret ssid
  password: !secret ssid_password
  fast_connect: True
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${name_of_board} Fallback Hotspot
    password: $ap_point_password
# Enable Home Assistant API
api:
  password: $api_password
  encryption:
    key: $api_encryption_key

logger:

ota:
  password: $ota_password

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO0
      mode:
        input: true
        pullup: true
      inverted: true
    name: ${name_of_board} Button
    on_press:
      - switch.toggle: relay
  - platform: status
    name: ${name_of_board} Status
switch:
  - platform: gpio
    name: ${name_of_board} Relay
    pin: GPIO12
    id: relay
  - platform: restart
    name: ${name_of_board} Restart
sensor:
  - platform: wifi_signal
    name: ${name_of_board} Wifi
    update_interval: 60s
  - platform: uptime
    name: g_uptime
    id: g_uptime
    update_interval: $update
    on_raw_value:
      then:
        - text_sensor.template.publish:
            id: uptime_human
            state: !lambda |-
              int seconds = round(id(g_uptime).raw_state);
              int days = seconds / (24 * 3600);
              seconds = seconds % (24 * 3600);
              int hours = seconds / 3600;
              seconds = seconds % 3600;
              int minutes = seconds /  60;
              seconds = seconds % 60;
              return (
                (days ? to_string(days) + "d " : "") +
                (hours ? to_string(hours) + "h " : "") +
                (minutes ? to_string(minutes) + "m " : "") +
                (to_string(seconds) + "s")
              ).c_str();
status_led:
  pin:
    number: GPIO13
    inverted: yes
text_sensor:
  - platform: template
    name: ${name_of_board} Board Uptime 
    id: uptime_human
    icon: mdi:clock-start

So a Sonoff basic would like following:

#The substitution block has all the configurable details
substitutions:
  name_of_board: basic01
  ota_password: !secret ota_basic_01
  ap_point_password: !secret ssid_basic_01_password
  api_password: !secret basic_01_api_password
  api_encryption_key: !secret basic_01_api_encryption
  
  ############################################
  #YOU SHOULD NOT NEED TO EDIT BELOW THIS LINE
  ############################################
  
packages:
  device_settings: !include common/basic.yaml
2 Likes
17

I just use HA’s secrets… and they could be split up further
my secrets in esphome:

<<: !include ../secrets.yaml
2 Likes
18

Repeating passwords for the sake of simplicity sounds more like a compromise and not a solution to my original question.

19

So you can essentially include as many files with this syntax using relative file path?

This seems like a solution to my question, thanks and I will give it a try!

20

Pankaj: i’ve put similar stuff into my common.yaml, included it in main code and i have buttons shown ok, but sensors are not - i have a sensor for wifi signal and friendly uptime, like you, but none of them are shown in HA.

Is there some catch? I mean - how the main yaml looks? I must miss something…

EDIT: it seems that sensors/buttons dissapear if i put same sensor/button/switch… type in main file also. like: i have buttons in common.yaml. If “button” doesn’t exists in main yaml it’s ok, but if i put it there also then it dissapears…