esphome-docs/guides/configuration-types.rst

461 lines
13 KiB
ReStructuredText
Raw Normal View History

2018-05-13 11:37:02 +02:00
Configuration Types
===================
2018-11-14 22:12:27 +01:00
.. seo::
2019-02-16 23:25:23 +01:00
:description: Documentation of different configuration types in ESPHome
:image: settings.svg
2018-11-14 22:12:27 +01:00
2019-02-16 23:25:23 +01:00
ESPHomes configuration files have several configuration types. This
2018-05-13 11:37:02 +02:00
page describes them.
2018-06-01 18:10:00 +02:00
.. _config-id:
2018-05-13 11:37:02 +02:00
ID
2018-10-12 16:33:22 +02:00
--
2018-05-13 11:37:02 +02:00
Quite an important aspect of ESPHome are “IDs”. They are used to
2018-05-13 11:37:02 +02:00
connect components from different domains. For example, you define an
output component together with an ID and then later specify that same ID
2018-05-13 11:37:02 +02:00
in the light component. IDs should always be unique within a
2019-02-16 23:25:23 +01:00
configuration and ESPHome will warn you if you try to use the same
2018-05-13 11:37:02 +02:00
ID twice.
2019-02-16 23:25:23 +01:00
Because ESPHome converts your configuration into C++ code and the
IDs are in reality just C++ variable names, they must also adhere to
2018-05-13 11:37:02 +02:00
C++s naming conventions. `C++ Variable
names <https://venus.cs.qc.cuny.edu/~krishna/cs111/lectures/D3_C++_Variables.pdf>`__
2018-05-13 11:37:02 +02:00
- … must start with a letter and can end with numbers.
- … must not have a space in the name.
- … can not have special characters except the underscore (“_“).
- … must not be a keyword.
.. note::
These IDs are used only within ESPHome and are not translated to Home Assistant's Entity ID.
2018-06-01 18:10:00 +02:00
.. _config-pin:
2018-05-13 11:37:02 +02:00
Pin
2018-10-12 16:33:22 +02:00
---
2018-05-13 11:37:02 +02:00
2019-02-16 23:25:23 +01:00
ESPHome always uses the **chip-internal GPIO numbers**. These
2018-05-13 11:37:02 +02:00
internal numbers are always integers like ``16`` and can be prefixed by
``GPIO``. For example to use the pin with the **internal** GPIO number 16,
you could type ``GPIO16`` or just ``16``.
Most boards however have aliases for certain pins. For example the NodeMCU
ESP8266 uses pin names ``D0`` through ``D8`` as aliases for the internal GPIO
2019-02-16 23:25:23 +01:00
pin numbers. Each board (defined in :doc:`ESPHome section </components/esphome>`)
2018-05-13 11:37:02 +02:00
has their own aliases and so not all of them are supported yet. For example,
for the ``D0`` (as printed on the PCB silkscreen) pin on the NodeMCU ESP8266
has the internal GPIO name ``GPIO16``, but also has an alias ``D0``. So using
either one of these names in your configuration will lead to the same result.
.. code-block:: yaml
2018-05-13 11:37:02 +02:00
some_config_option:
pin: GPIO16
some_config_option:
# alias on the NodeMCU ESP8266:
pin: D0
2018-06-01 18:10:00 +02:00
.. _config-pin_schema:
2018-05-13 11:37:02 +02:00
Pin Schema
2018-10-12 16:33:22 +02:00
----------
2018-05-13 11:37:02 +02:00
2019-02-16 23:25:23 +01:00
In some places, ESPHome also supports a more advanced “pin schema”.
2018-05-13 11:37:02 +02:00
.. code-block:: yaml
2018-05-13 11:37:02 +02:00
some_config_option:
# Basic:
pin: D0
# Advanced:
pin:
number: D0
inverted: true
2021-10-19 21:53:24 +02:00
mode:
input: true
pullup: true
2018-05-13 11:37:02 +02:00
Configuration variables:
- **number** (**Required**, pin): The pin number.
- **inverted** (*Optional*, boolean): If all read and written values
should be treated as inverted. Defaults to ``false``.
2021-10-19 21:53:24 +02:00
- **mode** (*Optional*, string or mapping): Configures the pin to behave in different
modes like input or output. The default value depends on the context.
2022-02-10 23:10:43 +01:00
Accepts either a shorthand string or a mapping where each feature can be individually
2021-10-19 21:53:24 +02:00
enabled/disabled:
- **input** (*Optional*, boolean): If true, configure the pin as an input.
- **output** (*Optional*, boolean): If true, configure the pin as an output.
- **pullup** (*Optional*, boolean): Activate internal pullup resistors on the pin.
- **pulldown** (*Optional*, boolean): Activate internal pulldown resistors on the pin.
- **open_drain** (*Optional*, boolean): Set the pin to open-drain (as opposed to push-pull).
The active pin state will then result in a high-impedance state.
For compatibility some shorthand modes can also be used.
- ``INPUT``
- ``OUTPUT``
- ``OUTPUT_OPEN_DRAIN``
- ``ANALOG``
- ``INPUT_PULLUP``
- ``INPUT_PULLDOWN``
Advanced options:
- **drive_strength** (*Optional*, string): On ESP32s with esp-idf framework the pad drive strength,
i.e. the maximum amount of current can additionally be set. Defaults to ``20mA``.
Options are ``5mA``, ``10mA``, ``20mA``, ``40mA``.
2018-06-01 18:10:00 +02:00
.. _config-time:
2018-05-13 11:37:02 +02:00
Time
2018-10-12 16:33:22 +02:00
----
2018-05-13 11:37:02 +02:00
2019-02-16 23:25:23 +01:00
In lots of places in ESPHome you need to define time periods.
2018-05-14 21:15:49 +02:00
There are several ways of doing this. See below examples to see how you can specify time periods:
2018-05-13 11:37:02 +02:00
.. code-block:: yaml
2018-05-13 11:37:02 +02:00
some_config_option:
2018-05-14 21:15:49 +02:00
some_time_option: 1000us # 1000 microseconds = 1ms
2018-05-13 11:37:02 +02:00
some_time_option: 1000ms # 1000 milliseconds
some_time_option: 1.5s # 1.5 seconds
some_time_option: 0.5min # half a minute
some_time_option: 2h # 2 hours
2018-06-07 23:12:51 +02:00
# Make sure you wrap these in quotes
some_time_option: '2:01' # 2 hours 1 minute
some_time_option: '2:01:30' # 2 hours 1 minute 30 seconds
2018-05-14 21:15:49 +02:00
# 10ms + 30s + 25min + 3h
some_time_option:
2018-05-13 11:37:02 +02:00
milliseconds: 10
seconds: 30
minutes: 25
hours: 3
days: 0
2018-06-01 18:10:00 +02:00
2018-08-24 22:44:01 +02:00
# for all 'update_interval' options, also
update_interval: never # never update
update_interval: 0ms # update in every loop() iteration
2018-12-01 09:46:37 +01:00
.. _config-substitutions:
Substitutions
-------------
2019-02-16 23:25:23 +01:00
Starting with version 1.10.0, ESPHome has a powerful new way to reduce repetition in configuration files:
2019-01-06 18:56:14 +01:00
Substitutions. With substitutions, you can have a single generic source file for all nodes of one kind and
substitute expressions in.
2018-12-01 09:46:37 +01:00
.. code-block:: yaml
substitutions:
devicename: livingroom
2019-01-06 18:56:14 +01:00
upper_devicename: Livingroom
2018-12-01 09:46:37 +01:00
2019-02-16 23:25:23 +01:00
esphome:
name: $devicename
2018-12-01 09:46:37 +01:00
# ...
2019-01-06 18:56:14 +01:00
sensor:
- platform: dht
# ...
temperature:
name: ${upper_devicename} Temperature
humidity:
name: ${upper_devicename} Humidity
In the top-level ``substitutions`` section, you can put as many key-value pairs as you want. Before
2019-02-16 23:25:23 +01:00
validating your configuration, ESPHome will automatically replace all occurrences of substitutions
2019-01-06 18:56:14 +01:00
by their value. The syntax for a substitution is based on bash and is case-sensitive: ``$substitution_key`` or
2019-02-16 23:25:23 +01:00
``${substitution_key}`` (same).
Two substitution passes are performed allowing compound replacements.
.. code-block:: yaml
2022-11-25 19:11:45 +01:00
substitutions:
foo: yellow
bar_yellow_value: !secret yellow_secret
bar_green_value: !secret green_secret
something:
test: ${bar_${foo}_value}
.. _YAML-insertion-operator:
YAML insertion operator
***********************
Additionally, you can use the YAML insertion operator ``<<`` syntax to create a single YAML file from which a number
2019-02-16 23:25:23 +01:00
of nodes inherit:
.. code-block:: yaml
# In common.yaml
esphome:
name: $devicename
# ...
sensor:
- platform: dht
# ...
temperature:
name: ${upper_devicename} Temperature
humidity:
name: ${upper_devicename} Humidity
.. code-block:: yaml
# In nodemcu1.yaml
substitutions:
devicename: nodemcu1
upper_devicename: NodeMCU 1
<<: !include common.yaml
2018-12-01 09:46:37 +01:00
2019-03-17 20:45:03 +01:00
.. tip::
To hide these base files from the dashboard, you can
- Place them in a subdirectory (dashboard only shows files in top-level directory)
2019-03-17 20:45:03 +01:00
- Prepend a dot to the filename, like ``.base.yaml``
.. _substitute-include-variables:
Substitute !include variables
*****************************
ESPHome's ``!include`` accepts a list of variables that can be substituted within the included file.
.. code-block:: yaml
2022-11-25 19:11:45 +01:00
2022-11-25 19:18:02 +01:00
binary_sensor:
- platform: gpio
id: button1
pin: GPIO16
on_multi_click: !include { file: on-multi-click.yaml, vars: { id: 1 } } # inline syntax
- platform: gpio
id: button2
pin: GPIO4
on_multi_click: !include
# multi-line syntax
file: on-multi-click.yaml
vars:
id: 2
``on-multi-click.yaml``:
.. code-block:: yaml
2022-11-25 19:11:45 +01:00
- timing: !include click-single.yaml
then:
- mqtt.publish:
topic: ${device_name}/button${id}/status
payload: single
- timing: !include click-double.yaml
then:
- mqtt.publish:
topic: ${device_name}/button${id}/status
payload: double
.. _command-line-substitutions:
Command line substitutions
**************************
You can define or override substitutions from the command line by adding e.g. ``-s KEY VALUE``
which overrides substitution KEY and gives it value VALUE. This can be issued multiple times,
so e.g. with the following ``example.yaml`` file:
.. code-block:: yaml
substitutions:
name: default
platform: ESP8266
esphome:
name: $name
platform: $platform
board: $board
and the following command:
.. code-block:: bash
esphome -s name device01 -s board esp01_1m example.yaml config
You will get something like the following output (please note the unchanged ``platform``,
added ``board``, and overridden ``name`` substitutions):
.. code-block:: yaml
substitutions:
name: device01
platform: ESP8266
board: esp01_1m
esphome:
name: device01
platform: ESP8266
board: esp01_1m
includes: []
libraries: []
esp8266_restore_from_flash: false
build_path: device01
platformio_options: {}
arduino_version: espressif8266@2.2.3
We can observe here that command line substitutions take precedence over the ones in
your configuration file. This can be used to create generic 'template' configuration
files (like the ``example.yaml`` above) which can be used for multiple devices,
using substitutions which are provided on the command line.
.. _config-packages:
Packages
--------
Another way to modularize and reuse your configuration is to use packages. This feature allows
you to put common pieces of configuration in separate files and keep only unique pieces of your
config in the main yaml file. All definitions from packages will be merged with your main
config in non-destructive way so you could always override some bits and pieces of package
configuration.
Dictionaries are merged key-by-key. Lists of components are merged by component
ID if specified. Other lists are merged by concatenation. All other config
values are replaced with the later value.
2021-09-05 22:23:12 +02:00
Local packages
**************
Consider the following example where the author put common pieces of configuration like WiFi and
I²C into base files and extends it with some device specific configurations in the main config.
Note how the piece of configuration describing ``api`` component in ``device_base.yaml`` gets
merged with the services definitions from main config file.
.. code-block:: yaml
# In config.yaml
substitutions:
node_name: mydevice
device_verbose_name: "My Device"
packages:
wifi: !include common/wifi.yaml
device_base: !include common/device_base.yaml
api:
services:
- service: start_laundry
then:
- switch.turn_on: relay
- delay: 3h
- switch.turn_off: relay
sensor:
- platform: mhz19
co2:
name: "CO2"
temperature:
name: "Temperature"
update_interval: 60s
automatic_baseline_calibration: false
.. code-block:: yaml
# In wifi.yaml
wifi:
2022-02-10 23:10:43 +01:00
ssid: !secret wifi_ssid
password: !secret wifi_password
domain: .yourdomain.lan
fast_connect: true
.. code-block:: yaml
# In device_base.yaml
esphome:
name: ${node_name}
platform: ESP32
board: wemos_d1_mini32
build_path: ./build/${node_name}
# I²C Bus
i2c:
sda: GPIO21
scl: GPIO22
scan: true
frequency: 100kHz
# Enable logging
logger:
level: ${log_level}
api:
2022-02-10 23:10:43 +01:00
encryption:
key: !secret api_encryption_key
reboot_timeout: 1h
sensor:
- <<: !include common/sensor/uptime.config.yaml
- <<: !include common/sensor/wifi_signal.config.yaml
binary_sensor:
- <<: !include common/binary_sensor/connection_status.config.yaml
switch:
- <<: !include common/switch/restart_switch.config.yaml
2021-09-10 11:50:17 +02:00
.. _config-git_packages:
2021-09-05 22:23:12 +02:00
Remote/git Packages
*******************
Packages can also be loaded from a git repository by utilizing the correct config syntax.
2021-09-10 11:50:17 +02:00
:ref:`config-substitutions` can be used inside the remote packages which allows users to override
them locally with their own subsitution value.
2021-09-05 22:23:12 +02:00
.. note::
Remote packages cannot have ``secret`` lookups in them. They should instead make use of substitutions with an
optional default in the packaged YAML, which the local device YAML can set using values from the local secrets.
2021-09-05 22:23:12 +02:00
.. code-block:: yaml
packages:
# Git repo examples
remote_package:
url: https://github.com/esphome/non-existant-repo
ref: main # optional
files: [file1.yml, file2.yml]
refresh: 1d # optional
# A single file can be expressed using `file` or `files` as a string
remote_package_two:
url: https://github.com/esphome/non-existant-repo
file: file1.yml # cannot be combined with `files`
# files: file1.yml
# shorthand form github://username/repository/[folder/]file-path.yml[@branch-or-tag]
remote_package_three: github://esphome/non-existant-repo/file1.yml@main
2018-06-01 18:10:00 +02:00
See Also
2018-10-12 16:33:22 +02:00
--------
2018-06-01 18:10:00 +02:00
- :doc:`ESPHome index </index>`
2018-06-01 18:10:00 +02:00
- :doc:`getting_started_command_line`
- :doc:`faq`
- :ghedit:`Edit`