.. seo:: :description: Frequently asked questions in ESPHome. :image: question_answer.png
ESPHome supports (most of) Home Assistant's YAML configuration directives like
!include
and!secret
. So you can store all your secret WiFi passwords and so on in a file calledsecrets.yaml
within the directory where the configuration file is.For even more configuration templating, take a look at :ref:`config-substitutions`.
If you want to see how ESPHome interprets your configuration, run
esphome livingroom.yaml config
To view the logs from your node without uploading, run
esphome livingroom.yaml logs
You can always find the source ESPHome generates under
<NODE_NAME>/src/
.You can view the full list of command line interface options here: :doc:`/guides/cli`
Use :ref:`substitutions <config-substitutions>` to reduce repetition in your configuration files.
ESPHome depends on the operating system the tool is running on to recognize
the ESP. This can sometimes fail. Common causes are that you did not install
the drivers (see note below) or you are trying to upload from a Docker container
and did not mount the ESP device into your container using --device=/dev/ttyUSB0
.
Starting with ESPHome 1.9.0, the ESPHome suite provides esphome-flasher, a tool to flash ESPs over USB.
First, you need to get the firmware file to flash. For the Home Assistant add-on based
installs you can use the COMPILE
button (click the overflow icon with the three dots)
and then press Download Binary
. For command line based installs you can access the
file under <CONFIG_DIR>/<NODE_NAME>/.pioenvs/<NODE_NAME>/firmware.bin
.
Then, install esphome-flasher by going to the releases page and downloading one of the pre-compiled binaries. Open up the application and select the serial port you want to flash to (on windows you can use the "device manager" to check if it's the right one).
Select the firmware binary and finally press "Flash ESP".
Note
If the serial port is not showing up, you might not have the required drivers installed. ESPs usually ship with one of these two UART chips:
Note
If you're just seeing Connecting....____....
on the screen and the flashing fails, that might
be a sign that the ESP is defect or cannot be programmed. Please double check the UART wires
are connected correctly if flashing using a USB to UART bridge. For some devices you need to
keep pressing the BOOT button until flashing has begun (ie. Geekcreit DOIT ESP32 DEVKIT V1).
That's no good. Here are some steps that resolve some problems:
- If you're having WiFi problems: See :ref:`wifi-problems`.
- Enable verbose logs in the logger: section.
- Still an error? Please file a bug report over in the ESPHome issue tracker. We will take a look at it as soon as we can. Thanks!
First of all, thank you very much to everybody submitting issue reports! While we try to test ESPHome/YAML as much as we can using our available hardware, we don't own every single device type and rely on testing done by the community and the contributors. When doing some changes in the core, it can quickly happen that something somewhere breaks. Issue reports are a great way for us to track and (hopefully) fix issues, so thank you!
For us to fix the issue quickly, there are some things that would be really helpful:
- Just writing "X doesn't work" or "X gives bug" is not helpful!!! Seriously, how do you expect help given just that information?
- A snippet of the code/configuration file used is always great to reproduce this issue. Please read How to create a Minimal, Complete, and Verifiable example.
- If it's an I²C or hardware communication issue please also try setting the
:ref:`log level <logger-log_levels>` to
VERY_VERBOSE
as it provides helpful information about what is going on. - Please also include what you've already tried and didn't work as that can help us track down the issue.
You can find the issue tracker here https://github.com/esphome/issues
It's simple. Run:
pip3 install -U esphome
# From docker:
docker pull esphome/esphome:latest
And in Home Assistant, there's a simple UPDATE button when there's an update available as with all add-ons.
ESPHome has a beta release cycle so that new releases can easily be tested before the changes are deployed to the stable channel. You can help test ESPHome (and use new features) by installing the tested beta:
# For pip-based installs
pip3 install --pre -U esphome
# For docker-based installs
docker run [...] -it esphome/esphome:beta livingroom.yaml run
For Home Assistant supervised installs add the community addons beta repository by adding https://github.com/hassio-addons/repository-beta in Add-on store -> Repositories.
The beta docs are available at beta.esphome.io
First, a fair warning that the latest bleeding edge version is not always stable and might have issues. If you find some, please do however report them.
To install the dev version of ESPHome:
In Home Assistant: Add the ESPHome repository https://github.com/esphome/hassio <https://github.com/esphome/hassio> in Add-on store -> Repositories. Then install the add-on
ESPHome Dev
From
pip
: Runpip3 install https://github.com/esphome/esphome/archive/dev.zip
From docker, use the esphome/esphome:dev image
docker run [...] -it esphome:dev livingroom.yaml compile
The latest dev docs are here: next.esphome.io
If you want to keep all your secrets in one place, make a secrets.yaml
file in the
esphome directory with these contents (so it pulls in the contents of your main Home Assistant
secrets.yaml
file from one directory higher):
<<: !include ../secrets.yaml
If it's not in :doc:`the docs </index>`, it's probably not supported. However, we are always trying to add support for new features, so feel free to create a feature request in the ESPHome feature request tracker. Thanks!
Sure! We are happy to help :) You can contact us here:
- Discord
- Home Assistant Community Forums
- ESPHome issue and feature request issue trackers. Preferably only for issues and feature requests.
- Alternatively, also under contact (at) esphome.io (NO SUPPORT!)
Jep, that's a known issue. However, it seems to be very low-level and we don't really know how to solve it. We are working on possible workarounds for the issue, but currently we do not have a real solution.
Some steps that can help with the issue:
- If you're using a hidden WiFi network, make sure to enable
fast_connect
mode in the WiFi configuration (also sometimes helps with non-hidden networks) - Give your ESP a :ref:`static IP <wifi-manual_ip>`.
- Set the
power_save_mode
tolight
in thewifi:
config (only helps in some cases, in other it can make things worse). See :ref:`wifi-power_save_mode`. - The issue seems to happen with cheap boards more frequently. Especially the "cheap" NodeMCU boards from eBay which sometimes have quite bad antennas.
- ESPHome reboots on purpose when something is not going right, e.g.
:doc:`wifi connection cannot be made </components/wifi>` or
:doc:`api connection is lost </components/api>` or
:doc:`mqtt connection is lost </components/mqtt>`. So if you are facing this problem you'll need
to explicitly set the
reboot_timeout
option to0s
on the components being used. - If you see
Error: Disconnecting <NODE_NAME>
in your logs, ESPHome is actively closing the native API client connection. Connect a serial console to inspect the reason, which is only logged via serial. If you seeack timeout 4
right before a disconnect, this might be because of a bug in the AsyncTCP library, for which a fix was included in ESPHome version 1.18.0. If you are running an ESPHome version, prior to 1.18.0, then upgrade ESPHome and build fresh firmware for your devices. - We have seen an increase in disconnects while the log level was set to
VERY_VERBOSE
, especially on single-core devices, where the logging code might be interfering with the operation of the networking code. For this reason, we advise using a lower log level for production purposes. - Related to this, seems to be the number of clients that are simultaneously connected to the native API server on the device. These might for example be Home Assistant (via the ESPHome integration) and the log viewer on the web dashboard. In production, you will likely only have a single connection from Home Assistant, making this less of an issue. But beware that attaching a log viewer might have impact.
Install versions:
# Stable Release
docker pull esphome/esphome
# Beta
docker pull esphome/esphome:beta
# Dev version
docker pull esphome/esphome:dev
Command reference:
# Start a new file wizard for file livingroom.yaml
docker run --rm -v "${PWD}":/config -it esphome/esphome livingroom.yaml wizard
# Compile and upload livingroom.yaml
docker run --rm -v "${PWD}":/config -it esphome/esphome livingroom.yaml run
# View logs
docker run --rm -v "${PWD}":/config -it esphome/esphome livingroom.yaml logs
# Map /dev/ttyUSB0 into container
docker run --rm -v "${PWD}":/config --device=/dev/ttyUSB0 -it esphome/esphome ...
# Start dashboard on port 6052 (general command)
# Warning: this command is currently not working with Docker on MacOS. (see note below)
docker run --rm -v "${PWD}":/config --net=host -it esphome/esphome
# Start dashboard on port 6052 (MacOS specific command)
docker run --rm -p 6052:6052 -e ESPHOME_DASHBOARD_USE_PING=true -v "${PWD}":/config -it esphome/esphome
# Setup a bash alias:
alias esphome='docker run --rm -v "${PWD}":/config --net=host -it esphome/esphome'
And a docker compose file looks like this:
version: '3'
services:
esphome:
image: esphome/esphome
volumes:
- ./:/config:rw
# Use local time for logging timestamps
- /etc/localtime:/etc/localtime:ro
network_mode: host
restart: always
Note
By default ESPHome uses mDNS to show online/offline state in the dashboard view. So for that feature to work you need to enable host networking mode
On MacOS the networking mode ("-net=host" option) doesn't work as expected. You have to use another way to launch the dashboard with a port mapping option and use alternative to mDNS to have the online/offline stat (see below)
mDNS might not work if your Home Assistant server and your ESPHome nodes are on different subnets. If your router supports Avahi, you are able to get mDNS working over different subnets.
Just follow the next steps:
- Enable Avahi on both subnets.
- Enable UDP traffic from ESPHome node's subnet to 224.0.0.251/32 on port 5353.
Alternatively, you can make esphome use ICMP pings to check the status of the device
with the Home Assistant add-on "status_use_ping": true,
option or with
Docker -e ESPHOME_DASHBOARD_USE_PING=true
.
See also esphome/issues#641 (comment).
Some of ESPHome's functionalities rely on mDNS, so naturally :ref:`disabling <wifi-configuration_variables>` it will cause these features to stop working. Generally speaking, disabling mDNS without setting a :ref:`static IP address <wifi-manual_ip>` (or a static DHCP lease) is bound to cause problems. This is due to the fact that mDNS is used to find the IP address of each ESPHome nodes.
- You will not be able to use the node's hostname to ping, find it's IP address or connect to it.
- Automatic discovery in Home Assistant when using :doc:`native API </components/api>` relies on mDNS broadcast messages to detect presence of new ESPHome nodes. If you need to use the native API with mDNS disabled, then you will have to use a static IP address and manually add the ESPHome integration with the fixed IP address.
- Online status detection in ESPHome's dashboard by default uses mDNS, so disabling mDNS will cause the ESPHome dashboard to show the status of the nodes created without mDNS support to be always offline. Currently, this does not affect any functionality, however if you want to see the online/offline status you could configure ESPHome to ping each node instead. See the :ref:`notes in the Docker Reference section <docker-reference-notes>` for more information.
If you lost your ESPHome YAML configuration files, there's no way to recover them. The configuration is not stored on the device directly - only the generated firmware is on the device itself (technically, the configuration can be reverse-engineered from that, but only with a lot of work).
Always back up all your files!