ESPHome Core Configuration

Here you specify some core information that ESPHome needs to create firmwares. Most importantly, this is the section of the configuration where you specify the name of the node, the platform and board you’re using.

# Example configuration entry
    name: livingroom
    comment: Living room ESP32 controller
    platform: ESP32
    board: nodemcu-32s

Configuration variables:

  • name (Required, string): This is the name of the node. It should always be unique in your ESPHome network. May only contain lowercase characters, digits and hyphens. See Changing ESPHome Node Name.

  • platform (Required, string): The platform your board is using, either ESP32 or ESP8266.

  • board (Required, string): The PlatformIO board ID that should be used. Choose the appropriate board from this list for the ESP8266, and this list for the ESP32 (the icon next to the name can be used to copy the board ID). This only affects pin aliases and some internal settings, if unsure choose a generic board from Espressif.

Advanced options:

  • arduino_version (Optional): The version of the Arduino framework to link the project against. See arduino_version.

  • build_path (Optional, string): Customize where ESPHome will store the build files for your node. By default, ESPHome puts all PlatformIO project files under a folder <NODE_NAME>/, but you can customize this behavior using this option.

  • platformio_options (Optional, mapping): Additional options to pass over to PlatformIO in the platformio.ini file. See platformio_options.

  • includes (Optional, list of files): A list of C/C++ files to include in the main (auto-generated) sketch file for custom components. The paths in this list are relative to the directory where the YAML configuration file is in. See includes for more info.

  • libraries (Optional, list of libraries): A list of platformio libraries to include in the project. See platformio lib install. The <name>=<source> syntax can be used to override the source used for a library that is included by a component.

  • comment (Optional, string): Additional text information about this node. Only for display in UI.

  • name_add_mac_suffix (Optional, boolean): Appends the last 6 bytes of the mac address of the device to the name in the form <name>-aabbcc. Defaults to false. See Adding the MAC address as a suffix to the device name.

  • project (Optional): ESPHome Creator’s Project information. See Project information.

    • name (Required, string): Name of the project

    • version (Required, string): Version of the project

ESP8266 Options:

  • esp8266_restore_from_flash (Optional, boolean): Whether to save & restore data from flash on ESP8266s. Defaults to no. See esp8266_restore_from_flash for more info


  • on_boot (Optional, Automation): An automation to perform when the node starts. See on_boot.

  • on_shutdown (Optional, Automation): An automation to perform right before the node shuts down. See on_shutdown.

  • on_loop (Optional, Automation): An automation to perform on each loop() iteration. See on_loop.


ESPHome uses the Arduino framework internally to handle all low-level interactions like initializing the WiFi driver and so on. Unfortunately, every Arduino framework version often has its own quirks and bugs, especially concerning WiFi performance. With the arduino_version option you can tell ESPHome which Arduino framework to use for compiling.

# Example configuration entry
  # ...
  # Default: use the recommended version, usually this equals
  # the latest version.
  arduino_version: recommended

  # Use the latest stable version
  arduino_version: latest

  # Use the latest staged version from GitHub, try this if you have WiFi problems
  arduino_version: dev

  # Use a specific version
  arduino_version: 2.3.0

For the ESP8266, you currently can manually pin the Arduino version to these values (see the full list of Arduino frameworks here):

For the ESP32, there are these Arduino framework versions:


With this option you can control where the state of certain components is kept on the ESP. Components like light, switch, fan and globals can restore their state upon boot.

However, by default this data is stored in the “RTC memory” section of the ESP8266s. This memory is cleared when the ESP8266 is disconnected from power. So by default the state cannot be recovered after power loss.

To still have these components restore their state upon power loss the state can additionally be saved in flash memory by setting this option to true.

Beware: The flash has a limited number of write cycles (usually around 100 000), after that the flash section will fail. So do not use this option when you have components that update rapidly. These include GPIO switches that are used internally (disable restoring with the restore_mode option), certain light effects like random and the on_value_range trigger.


This automation will be triggered when the ESP boots up. By default, it is executed after everything else is already set up. You can however change this using the priority parameter.

  # ...
    priority: 600
    # ...
      - switch.turn_off: switch_1

Configuration variables:

  • priority (Optional, float): The priority to execute your custom initialization code. A higher value means a high priority and thus also your code being executed earlier. Please note this is an ESPHome-internal value and any change will not be marked as a breaking change. Defaults to 600. Priorities (you can use any value between them too):

    • 800.0: This is where all hardware initialization of vital components is executed. For example setting switches to their initial state.

    • 600.0: This is where most sensors are set up.

    • 250.0: At this priority, WiFi is initialized.

    • 200.0: Network connections like MQTT/native API are set up at this priority.

    • -100.0: At this priority, pretty much everything should already be initialized.

  • See Automation.


This automation will be triggered when the ESP is about to shut down. Shutting down is usually caused by too many WiFi/MQTT connection attempts, Over-The-Air updates being applied or through the Deep Sleep Component.


It’s not guaranteed that all components are in a connected state when this automation is triggered. For example, the MQTT client may have already disconnected.

  # ...
      - switch.turn_off: switch_1

Configuration variables: See Automation.


This automation will be triggered on every loop() iteration (usually around every 16 milliseconds).

  # ...
      # do something


PlatformIO supports a number of options in its platformio.ini file. With the platformio_options parameter you can tell ESPHome what options to pass into the env section of the PlatformIO file (Note you can also do this by editing the platformio.ini file manually).

You can view a full list of PlatformIO options here:

# Example configuration entry
  # ...
    upload_speed: 115200
    board_build.f_flash: 80000000L


With includes you can include source files in the generated PlatformIO project. All files declared with this option are copied to the project each time it is compiled.

You can always look at the generated PlatformIO project (<CONFIG_DIR>/<NODENAME>) to see what is happening - and if you want you can even copy the include files directly into the src/ folder. The includes option is only a helper option that does that for you.

# Example configuration entry
  # ...
    - my_switch.h

This option behaves differently depending on what the included file is pointing at:

  • If the include string is pointing at a directory, the entire directory tree is copied into the src/ folder.

  • If the include string points to a header file (.h, .hpp, .tcc), it is copied in the src/ folder AND included in the main.cpp file. This way the lambda code can access it.

  • If the include string points to a regular source file (.c, .cpp), it is copied in the src/ folder AND compiled into the binary. This way implementation of classes and functions in header files can be provided.

Changing ESPHome Node Name

Trying to change the name of a node or its address in the network? You can do so with the use_address option of the WiFi configuration.

Change the device name or address in your YAML to the new value and additionally set use_address to point to the old address like so:

# Step 1. Changing name from test8266 to kitchen
  name: kitchen
  # ...

  # ...
  use_address: test8266.local

Now upload the updated config to the device. As a second step, you now need to remove the use_address option from your configuration again so that subsequent uploads will work again (otherwise it will try to upload to the old address).

# Step 2
  name: kitchen
  # ...

  # ...
  # Remove or comment out use_address
  # use_address: test8266.local

The same procedure can be done for changing the static IP of a device.

Adding the MAC address as a suffix to the device name

Using name_add_mac_suffix allows the user to compile a single binary file to flash many of the same device and they will all have unique names/hostnames. Note that you will still need to create an individual YAML config file if you want to OTA update the devices in the future.

Project information

This allows creators to add the project name and version to the compiled code. It is currently only exposed via the logger, mDNS and the device_info response via the native API. The format of the name should be author_name.project_name.

# Example configuration
    name: "jesse.leds_party"
    version: "1.0.0"

See Also