Handy configuration blocks for ESPHome

Although every ESPHome configuration is different, I’d like to have some similar features enabled in each of them in order to have a more consistent configuration architecture and identical capabilities on all nodes.

Described are some default configurations I’m using in all of my ESPHome projects and why.

Captive Portal / Fallback Access Point

I always enable a fallback accesspoint in my ESPHome configurations.

This allows me to access the device and update the firmware when the configured network connection fails or it otherwise unavailable.
When you don’t have this enables, most of the time the only alternative is to flash the firmware again direcly on the device itself, requiring physical access and opening the device. When the device is already installed somewhere, this is not always very convenient.

Having this enabled is not only handy when changing WiFi configurations, but I already needed it for some device that didn’t come online when configured to use DHCP to dynamically get an IP address. (I had to manually confgure a static IP address in the config to resolve this issue, and thus upload new firmware with this configuration.)

To trigger the captive portal when there is nothing wrong with the connectivity, simply disallow the specific ESPHome device access to the wireless network. This can often be done through the confiratrion of your access point. Wait one minute for the ESPHome captive portal to kick in.

Be sure to store the configured access credentials somewhere safe so you are able to access them when needed!

Example code block

#...
wifi:
  #...
  ap:
    ssid: "Some SSID"
    password: "Some Password"
#...
captive_portal:
#...

More information and configuration options: https://esphome.io/components/captive_portal.html

Restart Switch

ESPHome has an option that enables you to execute a remote restart of the uploaded firmware.

It is not often needed, but if you would like to trigger automatic restarts occasionaly or in certain conditions, this allows you to do it.

Some integrations in beta phase might stop working after a while for some random reason and triggering a restart remotely fixes it.
When this configuration is not in place, often the only alternative is to disconnect/connect the power supply.

(FYI: I’m not advocading restarting stuff as a fix for broken software. I’m just saying it is possible to remotely restart an ESPHome device, which can help you troubleshooting the actual issue.)

Example code block

#...
switch:
  - platform: restart
    name: "DeviceName restart"
#...

More information and configuration options: https://esphome.io/components/switch/restart.html

Wifi signal strength

For all my devices, I enable the WiFi signal strength sensor.
This relays the strength of the signal received from your WiFi access point.

It enables me to imediately see if a device will have a stable connection or not as often the signal strength in the installed location will be complete different than during test.

It also allows me to track the signal strength over time, allowing me to intervene before the devices drops of the network completely.

Example of WiFi strength over time of an ESPHome node.

When the signal goes dark, it can also be used to trigger some actions or to come to certain conclusions. (Power/battery failure, device stolen, …)

Example code block

...
sensor:
  - platform: wifi_signal
    name: "WiFi Signal DeviceName"
    update_interval: 60s
...

More information and configuration options:: https://esphome.io/components/sensor/wifi_signal.html