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.
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
Uptime sensor
You can create an uptime sensor which periodically sends the uptime of the ESPHome device.
Contrary to relying on connectivity to the device, parsing the uptime is a more resilient way to detect unexpected reboots in case you require this for an automation.
Or you can use it as a trigger after a certain uptime.
Having a way to track reboot also gives you visibility in potential stability issues with your code.
Example code block
... sensor: - platform: uptime name: "Device Uptime" update_interval: 60s ...
More information and configuration options:
https://esphome.io/components/sensor/uptime.html
Time based events
Sometimes you would like have time-based events,. Either events based on the actual time, or events with a specific spacing between them.
Obviously you can implement this with HomeAssistant itself, or any other external means, but that would mean the ESPHome device will not function if that solution is unavailable or there is an issue with WIFI connectivity.
Wouldn’t it be nice if there was a way to use time based event on your ESPHome device directly?
Luckely there is… Simply use the “time” component of ESPHome.
This will allow you to directly include times in conditions, lambda code, etc… in your ESPHome configurations.
The current time is made available automatically and once synchronised, it will work independantly.
Example code block
... time: - platform: homeassistant ...
More information and configuration options:
https://esphome.io/components/time.html
Substitutions
Want to make templates?
Cool, let’s use substitutions to make life easier.
Example code block
...
substitutions:
devicename: "EXAMPLE_DEVICE"
...
sensor:
- platform: wifi_signal
name: "${devicename}: WiFi Signal"
update_interval: 60s
...
More information and configuration options:
https://esphome.io/guides/configuration-types.html#substitutions