Upstream
/
esphome-docs
mirror of https://github.com/esphome/esphome-docs.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update next docs

This commit is contained in:
Otto Winter 2019-02-16 23:25:23 +01:00
parent 644b1f033e
commit 59e03981a4
No known key found for this signature in database
GPG Key ID: DB66C0BE6013F97E
145 changed files with 1067 additions and 1119 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.github/PULL_REQUEST_TEMPLATE.md vendored
View File

@ -3,9 +3,9 @@
**Related issue (if applicable):** fixes <link to issue>
**Pull request in [esphomeyaml](https://github.com/OttoWinter/esphomeyaml) with YAML changes (if applicable):** OttoWinter/esphomeyaml#<esphomeyaml PR number goes here>
**Pull request in [esphomelib](https://github.com/OttoWinter/esphomelib) with C++ framework changes (if applicable):** OttoWinter/esphomelib#<esphomelib PR number goes here>
**Pull request in [esphome](https://github.com/esphome/esphome) with YAML changes (if applicable):** esphome/esphome#<esphome PR number goes here>
**Pull request in [esphome-core](https://github.com/esphome/esphome-core) with C++ framework changes (if applicable):** esphome/esphome-core#<esphome-core PR number goes here>
## Checklist:
- [ ] The documentation change has been tested and compiles correctly.
- [ ] Branch: `next` is for changes and new documentation that will go public with the next esphomelib release. Fixes, changes and adjustments for the current release should be created against `current`.
- [ ] Branch: `next` is for changes and new documentation that will go public with the next ESPHome release. Fixes, changes and adjustments for the current release should be created against `current`.

46
.gitlab-ci.yml
View File

@ -1,46 +0,0 @@
---
.deploy: &deploy
tags:
- esphomedocs
before_script:
- mkdir -p /root/.ssh
- echo "$PRIVATE_KEY" | tr -d '\r' >/root/.ssh/id_rsa
- chmod 600 /root/.ssh/id_rsa
- ssh-keyscan -t rsa github.com >>/root/.ssh/known_hosts
- git config --global user.email "$GITHUB_EMAIL"
- git config --global user.name "$GITHUB_NAME"
- git worktree prune
- rm -rf ../esphomelib _build/html/
script:
- mkdir -p _build/html
- git fetch --force git@github.com:${TARGET_REPO}.git gh-pages:gh-pages
- git worktree add _build/html gh-pages
- make ../esphomelib
- make html
- make convertimages
- git -C _build/html add --all
- git -C _build/html commit -m "Deploy to gh-pages"
- git -C _build/html push -f git@github.com:${TARGET_REPO}.git gh-pages
cache:
paths:
- _build/doctrees
deploy-release:
<<: *deploy
variables:
TARGET_REPO: OttoWinter/esphomedocs
PRIVATE_KEY: ${GITHUB_PRIVATE_KEY}
CNAME: esphomelib.com
BASE_URL: https://esphomelib.com
only:
- current
deploy-beta:
<<: *deploy
variables:
TARGET_REPO: OttoWinter/esphomedocs-beta
PRIVATE_KEY: ${GITHUB_BETA_PRIVATE_KEY}
CNAME: beta.esphomelib.com
BASE_URL: https://beta.esphomelib.com
only:
- rc

4
changelog/v1.7.0.rst
View File

@ -54,7 +54,7 @@ New Components
- The new :doc:`remote receiver </components/remote_transmitter>` and
:doc:`remote transmitter </components/remote_receiver>` components now allows you to use any 433MHz
receivers and senders with esphomelib. Currently, you will need to use the ``raw`` data as described in
receivers and senders with ESPHome. Currently, you will need to use the ``raw`` data as described in
:ref:`this guide <finding_remote_codes>`, but in the future more protocols will be supported out of the box.
New Features
@ -134,7 +134,7 @@ Other Contributions
- Fix deprecation of board_flash_mode parameter (`esphomeyaml/#41`_) by `@aequitas`_
- Support specifying hostname/ip as --upload-port (`esphomeyaml/#36`_) by `@aequitas`_
- DHT11 sensor doesn't work with esphomelib (`esphomelib/#88`_) by `@ayavilevich`_
- DHT11 sensor doesn't work with ESPHome (`esphomelib/#88`_) by `@ayavilevich`_
- tsl2561: wrong i2c function for channel 1 (`esphomelib/#81`_) by `@schumar`_
- No need to wait after Wire.requestFrom(). (`esphomelib/#80`_) by `@Koepel`_
- I2CComponent::write_byte_16 writes 0 words (`esphomelib/#78`_) by `@schumar`_

4
components/api.rst
View File

@ -28,10 +28,10 @@ Configuration variables:
Migrating from MQTT to Native API Setup in Home Assistant
---------------------------------------------------------
The native API is the best way to use esphomelib together with Home Assistant - it's fast,
The native API is the best way to use ESPHome together with Home Assistant - it's fast,
highly efficient and requires almost zero setup (whereas MQTT requires you to set up an MQTT broker first).
If you've previously used esphomelib with Home Assistant via MQTT and have enabled MQTT discovery,
If you've previously used ESPHome with Home Assistant via MQTT and have enabled MQTT discovery,
the upgrade process is unfortunately not just swapping out the ``mqtt`` for ``api`` in your configuration:
Home Assistant's `entity registry <https://developers.home-assistant.io/docs/en/entity_registry_index.html>`__ complicates
things a bit. If you don't follow these steps, all your new native API entities will have a trailing

8
components/binary_sensor/custom.rst
View File

@ -1,7 +1,7 @@
Custom Binary Sensor
====================
This integration can be used to create custom binary sensors in esphomelib
This integration can be used to create custom binary sensors in ESPHome
using the C++ (Arduino) API.
Please first read :doc:`/components/sensor/custom` guide,
@ -13,8 +13,8 @@ same as the gpio binary sensor.
.. code-block:: cpp
#include "esphomelib.h"
using namespace esphomelib;
#include "esphome.h"
using namespace esphome;
class MyCustomBinarySensor : public PollingComponent, public binary_sensor::BinarySensor {
public:
@ -41,7 +41,7 @@ And in YAML:
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
includes:
- my_binary_sensor.h

4
components/binary_sensor/esp32_ble_tracker.rst
View File

@ -49,10 +49,6 @@ the logs to see discovered Bluetooth Low Energy devices.
# Example configuration entry for finding MAC addresses
esp32_ble_tracker:
After adding that to your configuration, you will need to re-flash the ESP32 over USB, as esphomeyaml
needs to repartition the flash memory of the ESP in order to allow for the increased firmware size that
the BLE stack requires.
Using the configuration above, first you should see a ``Starting scan...`` debug message at
boot-up. Then, when a BLE device is discovered, you should see messages like
``Found device AC:37:43:77:5F:4C`` together with some information about their

26
components/binary_sensor/gpio.rst
View File

@ -2,7 +2,7 @@ GPIO Binary Sensor
==================
.. seo::
:description: Instructions for setting up GPIO binary sensors with esphomelib.
:description: Instructions for setting up GPIO binary sensors with ESPHome.
:image: pin.png
The GPIO Binary Sensor platform allows you to use any input pin on your
@ -30,19 +30,23 @@ Configuration variables:
- All other options from :ref:`Binary Sensor <config-binary_sensor>`
and :ref:`MQTT Component <config-mqtt-component>`.
.. note::
Activating internal pullups
---------------------------
For some applications such as reed switches you need to set the pin mode to ``INPUT_PULLUP``
like this:
If you're hooking up a button without an external pullup or see lots of ON/OFF events
in the log output all the time, this often means the GPIO pin is floating.
.. code-block:: yaml
For these cases you need to manually enable the pull-up (or pull-down) resistors on the ESP,
you can do so with the :ref:`Pin Schema <config-pin_schema>`.
binary_sensor:
- platform: gpio
pin:
number: D2
mode: INPUT_PULLUP
name: ...
.. code-block:: yaml
binary_sensor:
- platform: gpio
pin:
number: D2
mode: INPUT_PULLUP
name: ...
Inverting Values
----------------

12
components/binary_sensor/index.rst
View File

@ -5,7 +5,7 @@ Binary Sensor Component
:description: Information about the base representation of all binary sensors.
:image: folder-open.png
With esphomelib you can use different types of binary sensors. They will
With ESPHome you can use different types of binary sensors. They will
automatically appear in the Home Assistant front-end and have several
configuration options.
@ -57,7 +57,7 @@ Automations:
Binary Sensor Filters
---------------------
With binary sensor filters you can customize how esphomelib handles your binary sensor values even more.
With binary sensor filters you can customize how ESPHome handles your binary sensor values even more.
They are similar to :ref:`Sensor Filters <sensor-filters>`.
.. code-block:: yaml
@ -75,7 +75,6 @@ They are similar to :ref:`Sensor Filters <sensor-filters>`.
} else {
return {};
}
- heartbeat: 5s
Supported filters:
@ -91,15 +90,12 @@ Supported filters:
- **lambda**: Specify any :ref:`lambda <config-lambda>` for more complex filters. The input value from
the binary sensor is ``x`` and you can return ``true`` for ON, ``false`` for OFF, and ``{}`` to stop
the filter chain.
- **heartbeat**: Periodically send out the last received value from the binary sensor with the given
interval. All state changes are still immediately published.
Binary Sensor Automation
------------------------
The triggers for binary sensors in esphomeyaml use the lingo from computer mouses. This naming might not
perfectly fit every use case, but at least makes the naming consistent. For example, a ``press`` is triggered
in the first moment when the button on your mouse is pushed down.
The triggers for binary sensors in ESPHome use the lingo from computer mouses.
For example, a ``press`` is triggered in the first moment when the button on your mouse is pushed down.
You can access the current state of the binary sensor in :ref:`lambdas <config-lambda>` using
``id(binary_sensor_id).state``.

2
components/binary_sensor/remote_receiver.rst
View File

@ -55,7 +55,7 @@ Configuration variables:
pin: 5
carrier_duty_percent: 100%
Supporting the RF Bridge chip directly is currently only a long-term goal for esphomelib.
Supporting the RF Bridge chip directly is currently only a long-term goal for ESPHome.
See Also

53
components/binary_sensor/template.rst
View File

@ -18,12 +18,7 @@ a binary sensor.
- platform: template
name: "Garage Door Open"
lambda: |-
if (isnan(id(ultrasonic_sensor1).state)) {
// isnan checks if the ultrasonic sensor echo
// has timed out, resulting in a NaN (not a number) state
// in that case, return {} to indicate that we don't know.
return {};
} else if (id(ultrasonic_sensor1).state > 30) {
if (id(ultrasonic_sensor1).state > 30) {
// Garage Door is open.
return true;
} else {
@ -35,21 +30,61 @@ Possible return values of the lambda:
- ``return true;`` if the binary sensor should be ON.
- ``return false;`` if the binary sensor should be OFF.
- ``return {};`` if the last state should be repeated.
- ``return {};`` if the state is not known (use last known state)
Configuration variables:
------------------------
- **name** (**Required**, string): The name of the binary sensor.
- **lambda** (**Required**, :ref:`lambda <config-lambda>`):
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda to be evaluated repeatedly to get the current state of the binary sensor.
Only state *changes* will be published to MQTT.
- **id** (*Optional*,
:ref:`config-id`): Manually specify
the ID used for code generation.
- All other options from :ref:`Binary Sensor <config-binary_sensor>`
and :ref:`MQTT Component <config-mqtt-component>`.
.. _binary_sensor-template-publish_action:
``binary_sensor.template.publish`` Action
-----------------------------------------
You can also publish a state to a template binary sensor from elsewhere in your YAML file
with the ``binary_sensor.template.publish`` action.
.. code-block:: yaml
# Example configuration entry
binary_sensor:
- platform: template
name: "Garage Door Open"
id: template_bin
# in some trigger
on_...:
- binary_sensor.template.publish:
id: template_bin
state: ON
# Templated
- binary_sensor.template.publish:
id: template_bin
state: !lambda 'return id(some_sensor).state > 30;'
Configuration options:
- **id** (**Required**, :ref:`config-id`): The ID of the template binary sensor.
- **state** (**Required**, boolean, :ref:`templatable <config-templatable>`):
The state to publish.
.. note::
This action can also be written in lambdas:
.. code-block:: cpp
id(template_bin).publish_state(true);
See Also
--------

4
components/cover/index.rst
View File

@ -2,10 +2,10 @@ Cover Component
===============
.. seo::
:description: Instructions for setting up base covers in esphomelib.
:description: Instructions for setting up base covers in ESPHome.
:image: folder-opn.png
The ``cover`` component is a generic representation of covers in esphomelib/yaml.
The ``cover`` component is a generic representation of covers in ESPHome.
A cover can (currently) either be *closed* or *open* and supports three types of
commands: *open*, *close* and *stop*.

77
components/cover/template.rst
View File

@ -2,7 +2,7 @@ Template Cover
==============
.. seo::
:description: Instructions for setting up template covers in esphomelib.
:description: Instructions for setting up template covers in ESPHome.
:image: description.png
The ``template`` cover platform allows you to create simple covers out of just a few
@ -43,23 +43,64 @@ Possible return values for the optional lambda:
Configuration variables:
------------------------
- **name** (**Required**, string): The name of the cover.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda to be evaluated repeatedly to get the current state of the cover.
Only state *changes* will be published to MQTT.
- **optimistic** (*Optional*, boolean): Whether to operate in optimistic mode - when in this mode,
any command sent to the template cover will immediately update the reported state and no lambda
needs to be used. Defaults to ``false``.
- **open_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote (like Home Assistant's frontend) requests the cover to be opened.
- **close_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote requests the cover to be closed.
- **stop_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote requests the cover to stopped.
- **id** (*Optional*,
:ref:`config-id`): Manually specify
the ID used for code generation.
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
- **name** (**Required**, string): The name of the cover.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda to be evaluated repeatedly to get the current state of the cover.
- **open_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote (like Home Assistant's frontend) requests the cover to be opened.
- **close_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote requests the cover to be closed.
- **stop_action** (*Optional*, :ref:`Action <config-action>`):
- **optimistic** (*Optional*, boolean): Whether to operate in optimistic mode - when in this mode,
any command sent to the template cover will immediately update the reported state and no lambda
needs to be used. Defaults to ``false``.
- **assumed_state** (*Optional*, boolean): Whether the true state of the cover is not known.
This will make the Home Assistant frontend show buttons for both OPEN and CLOSE actions, instead
of hiding one of them. Defaults to ``false``.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
.. _cover-template-publish_action:
``cover.template.publish`` Action
---------------------------------
You can also publish a state to a template cover from elsewhere in your YAML file
with the ``cover.template.publish`` action.
.. code-block:: yaml
# Example configuration entry
cover:
- platform: template
name: "Template Cover"
id: template_cov
# in some trigger
on_...:
- cover.template.publish:
id: template_cov
state: OPEN
# Templated
- cover.template.publish:
id: template_cov
state: !lambda 'return cover::COVER_OPEN;'
Configuration options:
- **id** (**Required**, :ref:`config-id`): The ID of the template cover.
- **state** (**Required**, :ref:`templatable <config-templatable>`):
The state to publish. One of ``OPEN``, ``CLOSED``.
.. note::
This action can also be written in lambdas:
.. code-block:: cpp
id(template_cov).publish_state(cover::COVER_OPEN);
See Also
--------

6
components/debug.rst
View File

@ -2,11 +2,11 @@ Debug Component
===============
.. seo::
:description: Instructions for setting up the debug component in esphomelib
:description: Instructions for setting up the debug component in ESPHome
:image: bug-report.png
The ``debug`` component can be used to debug problems with esphomelib. At startup, it prints
a bunch of useful information like reset reason, free heap size, esphomelib version and so on.
The ``debug`` component can be used to debug problems with ESPHome. At startup, it prints
a bunch of useful information like reset reason, free heap size, ESPHome version and so on.
.. figure:: images/debug.png
:align: center

6
components/deep_sleep.rst
View File

@ -10,7 +10,7 @@ ESP8266/ESP32 after a certain amount of time. This is especially useful with nod
on batteries and therefore need to conserve as much energy as possible.
To use ``deep_sleep`` first specify how long the node should be active, i.e. how long it should
check sensor values and report them, using the ``run_duration`` and ``run_cycles`` options. If you
check sensor values and report them, using the ``run_duration`` options. If you
use both in your configuration, any time either one of them is finished, the node will go into deep
sleep mode.
@ -34,8 +34,6 @@ Configuration variables:
------------------------
- **run_duration** (*Optional*, :ref:`config-time`): The time duration the node should be active, i.e. run code.
- **run_cycles** (*Optional*, int): The number of ``loop()`` cycles to go through before
entering deep sleep mode. Note: for advanced use-cases with custom code only.
- **sleep_duration** (*Optional*, :ref:`config-time`): The time duration to stay in deep sleep mode.
- **wakeup_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`):
Only on ESP32. A pin to wake up to once in deep sleep mode. Use the inverted property to wake up
@ -73,7 +71,7 @@ ESP32 Wakeup Pin Mode
---------------------
On the ESP32, you have the option of waking up on any RTC pin. However, there's one scenario that you need
to tell esphomelib how to handle: What if the wakeup pin is already in the state with which it would wake up
to tell ESPHome how to handle: What if the wakeup pin is already in the state with which it would wake up
when the deep sleep should start? There are three ways of handling this using the ``wakeup_pin_mode`` option:
- ``IGNORE`` (Default): Ignore the fact that we will immediately exit the deep sleep mode because the wakeup

40
components/display/index.rst
View File

@ -5,7 +5,7 @@ Display Component
:description: Instructions for setting up the display integration.
:image: folder-open.png
The ``display`` component houses esphomelib's powerful rendering and display
The ``display`` component houses ESPHome's powerful rendering and display
engine. Fundamentally, there are these types of displays:
- Text based displays like :doc:`7-Segment displays <max7219>` or
@ -14,10 +14,10 @@ engine. Fundamentally, there are these types of displays:
- Binary displays which can toggle ON/OFF any pixel, like :doc:`E-Paper displays <waveshare_epaper>` or
:doc:`OLED displays <ssd1306_spi>`.
For the last type, esphomelib and esphomeyaml have a powerful rendering engine that can do
For the last type, ESPHome has a powerful rendering engine that can do
many things like draw some basic shapes, print text with any font you want, or even show images.
To achieve all this flexibility displays tie in directly into esphomeyaml's :ref:`lambda system <config-lambda>`.
To achieve all this flexibility displays tie in directly into ESPHome's :ref:`lambda system <config-lambda>`.
So when you want to write some text or sensor values to the screen you will be writing in C++ code
using an API that is designed to
@ -29,13 +29,13 @@ using an API that is designed to
Display Rendering Engine
------------------------
In this section we will be discussing how to use esphomelib's display rendering engine from esphomeyaml
In this section we will be discussing how to use ESPHome's display rendering engine from ESPHome
and some basic commands. Please note that this only applies to displays that can control each pixel
individually.
So, first a few basics: When setting up a display platform in esphomeyaml there will be a configuration
option called ``lambda:`` which will be called every time esphomelib wants to re-render the display.
In there, you can write code like in any :ref:`lambda <config-lambda>` in esphomeyaml. Display
So, first a few basics: When setting up a display platform in ESPHome there will be a configuration
option called ``lambda:`` which will be called every time ESPHome wants to re-render the display.
In there, you can write code like in any :ref:`lambda <config-lambda>` in ESPHome. Display
lambdas are additionally passed a variable called ``it`` which represents the rendering engine object.
.. code-block:: yaml
@ -67,7 +67,7 @@ the rendering engine is always first specify the ``x`` coordinate and then the `
Basic Shapes
************
Now that you know a bit more about esphomelib's coordinate system, let's draw some basic shapes like lines, rectangles
Now that you know a bit more about ESPHome's coordinate system, let's draw some basic shapes like lines, rectangles
and circles:
.. code-block:: yaml
@ -90,7 +90,7 @@ and circles:
All the above methods can optionally also be called with an argument at the end which specifies in which
color to draw. Currently, only ``COLOR_ON`` (the default if color is not given) and ``COLOR_OFF`` are supported because
esphomelib only has implemented binary displays.
ESPHome only has implemented binary displays.
.. code-block:: yaml
@ -128,12 +128,12 @@ You can view the full API documentation for the rendering engine in the "API Ref
Drawing Static Text
*******************
The rendering engine also has a powerful font drawer which integrates seamlessly into esphomeyaml.
The rendering engine also has a powerful font drawer which integrates seamlessly into ESPHome.
Whereas in most arduino display projects you have to use one of a few pre-defined fonts in very
specific sizes, with esphomeyaml you have the option to use **any** truetype (``.ttf``) font file
specific sizes, with ESPHome you have the option to use **any** truetype (``.ttf``) font file
at **any** size! Granted the reason for it is actually not having to worry about the licensing of font files :)
To use fonts you first have to define a font object in your esphomeyaml configuration file. Just grab
To use fonts you first have to define a font object in your ESPHome configuration file. Just grab
a ``.ttf`` file from somewhere on the Internet and create a ``font:`` section in your configuration:
.. code-block:: yaml
@ -164,9 +164,9 @@ Configuration variables:
.. note::
To use fonts you will need to have the python ``pillow`` package installed, as esphomeyaml uses that package
To use fonts you will need to have the python ``pillow`` package installed, as ESPHome uses that package
to translate the truetype files into an internal format. If you're running this as a Hass.io add-on or with
the official esphomeyaml docker image, it should already be installed. Otherwise you need to install it using
the official ESPHome docker image, it should already be installed. Otherwise you need to install it using
``pip2 install pillow``.
@ -181,10 +181,10 @@ Then, in your display code just reference the font like so:
// Print the string "Hello World!" at [0,10]
it.print(0, 10, id(my_font), "Hello World!");
By default, esphomelib will *align* the text at the top left. That means if you enter the coordinates
By default, ESPHome will *align* the text at the top left. That means if you enter the coordinates
``[0,10]`` for your text, the top left of the text will be at ``[0,10]``. If you want to draw some
text at the right side of the display, it is however sometimes useful to choose a different **text alignment**.
When you enter ``[0,10]`` you're really telling esphomelib that it should position the **anchor point** of the text
When you enter ``[0,10]`` you're really telling ESPHome that it should position the **anchor point** of the text
at ``[0,10]``. When using a different alignment, like ``TOP_RIGHT``, the text will be positioned left of the anchor
pointed, so that, as the name implies, the anchor point is a the *top right* corner of the text.
@ -218,7 +218,7 @@ Formatted Text
**************
Static text by itself is not too impressive. What we really want is to display *dynamic* content like sensor values
on the display!. That's where ``printf`` comes in. ``printf`` is a formatting engine from the C era and esphomelib
on the display!. That's where ``printf`` comes in. ``printf`` is a formatting engine from the C era and ESPHome
chose to use because ... well, I'm too lazy to create a fully-fledged format engine where the existing stuff
is way better documented :)
@ -244,7 +244,7 @@ stuff after it is encountered, it is magically replaced by the argument after th
Every time you type a percent sign ``%`` in a printf format string, it will treat the following letters as a format tag
until a so-called "specifier" is encountered (in this case ``f``). You can read more about it `here <https://www.tutorialspoint.com/c_standard_library/c_function_printf.htm>`__,
but for esphomelib there are really just a few things you need to know.
but for ESPHome there are really just a few things you need to know.
Let's break ``%.1f`` down:
@ -311,7 +311,7 @@ use any string you pass it, like ``"ON"`` or ``"OFF"``.
Displaying Time
***************
With esphomelib you can also display the current time using the NTP protocol. Please see the example :ref:`here <strftime>`.
With ESPHome you can also display the current time using the NTP protocol. Please see the example :ref:`here <strftime>`.
Images
^^^^^^
@ -334,7 +334,7 @@ Configuration variables:
.. note::
To use images you will need to have the python ``pillow`` package installed.
If you're running this as a Hass.io add-on or with the official esphomeyaml docker image, it should already be
If you're running this as a Hass.io add-on or with the official ESPHome docker image, it should already be
installed. Otherwise you need to install it using ``pip2 install pillow``.
And then later in code:

2
components/display/lcd_gpio.rst
View File

@ -6,7 +6,7 @@ GPIO Character-Based LCD Display
:image: lcd.jpg
The ``lcd_gpio`` display platform allows you to use standard character-based LCD displays like `this one <https://www.adafruit.com/product/181>`__
with esphomelib. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
with ESPHome. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
and 2-4 rows), and not for LCD displays that can control each pixel individually. Also, this is the GPIO version of the LCD
integration where each of the data pins of the LCD needs a dedicated GPIO pin on the ESP. These LCD displays are also
commonly sold with a PCF8574 chip which only need two lines to the ESP, for that see :doc:`lcd_pcf8574`.

2
components/display/lcd_pcf8574.rst
View File

@ -6,7 +6,7 @@ PCF8574 Character-Based LCD Display
:image: lcd.jpg
The ``lcd_pcf8574`` display platform allows you to use standard character-based LCD displays like `this one <https://docs.labs.mediatek.com/resource/linkit7697-arduino/en/tutorial/driving-1602-lcd-with-pcf8574-pcf8574a>`__
with esphomelib. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
with ESPHome. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
and 2-4 rows), and not for LCD displays that can control each pixel individually.
This version of the LCD integration is for LCD displays with an PCF8574 connected to all the data pins. This has

6
components/display/max7219.rst
View File

@ -7,7 +7,7 @@ MAX7219 7-Segment Display
The ``max7219`` display platform allows you to use MAX7219 7-segment display drivers (`datasheet <https://datasheets.maximintegrated.com/en/ds/MAX7219-MAX7221.pdf>`__,
`hobbycomponents <https://hobbycomponents.com/displays/597-max7219-8-digit-seven-segment-display-module>`__)
with esphomelib. Please note that this integration is *only* for 7-segment display, not matrix configurations.
with ESPHome. Please note that this integration is *only* for 7-segment display, not matrix configurations.
.. figure:: images/max7219-full.jpg
:align: center
@ -63,7 +63,7 @@ The MAX7219 has a similar API to the fully fledged :ref:`display-engine`, but it
as with all other displays. In this case however, ``it`` is an MAX7219 instance (see API Reference).
The most basic operation with the MAX7219 is wiring a simple number to the screen as in the configuration example
at the top of this page. But even though you're passing in a string (here ``"01234567"``), esphomelib converts it
at the top of this page. But even though you're passing in a string (here ``"01234567"``), ESPHome converts it
into a representation that the MAX7219 can understand: The exact pixels that should be turned on. And of course,
not all characters can be represented. You can see a full list of characters :ref:`below <display-max7219_characters>`.
@ -72,7 +72,7 @@ beginning which can be used to print the text at a specific position. This argum
means the first character of the first MAX7219. For example to start the first character of your text at
the end of the first MAX7219, you would write ``it.print(7, "0");``.
Also note that the ``.`` (dot) character is special because when esphomelib encounters it in the string the dot
Also note that the ``.`` (dot) character is special because when ESPHome encounters it in the string the dot
segment of the previous position will be enabled.
.. code-block:: yaml

4
components/display/nextion.rst
View File

@ -12,7 +12,7 @@ Nextion TFT LCD Display
The ``nextion`` display platform allows you to use Nextion LCD displays (`datasheet <https://nextion.itead.cc/resources/datasheets/>`__,
`iTead <https://www.itead.cc/display/nextion.html>`__)
with esphomelib.
with ESPHome.
.. figure:: images/nextion-full.jpg
:align: center
@ -55,7 +55,7 @@ Configuration variables:
Rendering Lambda
----------------
With Nextion displays, a dedicated chip on the display itself does the whole rendering. esphomelib can only
With Nextion displays, a dedicated chip on the display itself does the whole rendering. ESPHome can only
send *instructions* to the display to tell it *how* to render something and *what* to render.
First, you need to use the `Nextion Editor <https://nextion.itead.cc/resources/download/nextion-editor/>`__ to

2
components/display/ssd1306_i2c.rst
View File

@ -8,7 +8,7 @@ SSD1306 OLED Display over I²C
The ``ssd1306_i2c`` display platform allows you to use
SSD1306 (`datasheet <https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf>`__, `Adafruit <https://www.adafruit.com/product/326>`__)
and SH1106 (`datasheet <https://www.elecrow.com/download/SH1106%20datasheet.pdf>`__, `electrodragon <https://www.electrodragon.com/product/1-3-12864-blue-oled-display-iicspi/>`__)
displays with esphomelib. Note that this component is for displays that are connected via the :ref:`I²C Bus <i2c>`.
displays with ESPHome. Note that this component is for displays that are connected via the :ref:`I²C Bus <i2c>`.
If your SSD1306 or SH1106 is connected via the 4-Wire :ref:`SPI bus <spi>`, see :doc:`ssd1306_spi`.
.. figure:: images/ssd1306-full.jpg

2
components/display/ssd1306_spi.rst
View File

@ -8,7 +8,7 @@ SSD1306 OLED Display over SPI
The ``ssd1306_spi`` display platform allows you to use
SSD1306 (`datasheet <https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf>`__, `Adafruit <https://www.adafruit.com/product/326>`__)
and SH1106 (`datasheet <https://www.elecrow.com/download/SH1106%20datasheet.pdf>`__, `electrodragon <https://www.electrodragon.com/product/1-3-12864-blue-oled-display-iicspi/>`__)
displays with esphomelib. Note that this component is for displays that are connected via the 4-Wire :ref:`SPI bus <spi>`.
displays with ESPHome. Note that this component is for displays that are connected via the 4-Wire :ref:`SPI bus <spi>`.
If your SSD1306 or SH1106 is connected via the :ref:`I²C Bus <i2c>`, see :doc:`ssd1306_i2c`.
.. figure:: images/ssd1306-full.jpg

8
components/display/waveshare_epaper.rst
View File

@ -2,12 +2,12 @@ Waveshare E-Paper Display
=========================
.. seo::
:description: Instructions for setting up Waveshare E-Paper displays in esphomelib.
:description: Instructions for setting up Waveshare E-Paper displays in ESPHome.
:image: waveshare_epaper.jpg
The ``waveshare_epaper`` display platform allows you to use
some E-Paper displays sold by `Waveshare <https://www.waveshare.com/product/modules/oleds-lcds/e-paper.htm>`__
with esphomelib. Similar modules sold by other vendors might also work but not have been tested yet. Currently only
with ESPHome. Similar modules sold by other vendors might also work but not have been tested yet. Currently only
single-color E-Ink displays are implemented and of those only a few modules.
.. figure:: images/waveshare_epaper-full.jpg
@ -16,12 +16,12 @@ single-color E-Ink displays are implemented and of those only a few modules.
Waveshare E-Paper 2.9 Inch E-Paper Display.
The communication esphomelib has chosen to use for this integration is 4-wire :ref:`SPI <spi>`, as it's the most stable
The communication ESPHome has chosen to use for this integration is 4-wire :ref:`SPI <spi>`, as it's the most stable
and high-speed. So you need to make sure your board is set to the 4-wire SPI mode and have an ``spi:`` section in your
configuration.
==================== ===================== =====================
**E-Paper Pin** **ESP Pin** **esphomelib Option**
**E-Paper Pin** **ESP Pin** **ESPHome Option**
-------------------- --------------------- ---------------------
``VCC`` ``3.3V`` N/A
-------------------- --------------------- ---------------------

8
components/esp32_ble_beacon.rst
View File

@ -36,8 +36,8 @@ Advanced options:
Setting Up
----------
First, you'll need to set up the configuration for esphomeyaml. Just copy above configuration and
change the UUID to something unique. For example, you can copy below randomly generated UUID:
First, you'll need to set up the configuration for ESPHome. Just copy the configuration above and
change the UUID to something unique. For example, you can copy this randomly generated UUID:
.. raw:: html
@ -55,9 +55,7 @@ change the UUID to something unique. For example, you can copy below randomly ge
document.getElementById("ble-uuid").value = guid();
</script>
Then, just compile and flash the ESP32. Note that esphomeyaml needs to increase the size of the code
partitions of the ESP32 because BLE can take up a lot of space. It does this automatically, but you need
to flash the ESP32 via USB when enabling or disabling this component.
Then, just compile and flash the ESP32.
When everything is set up correctly, you should see a show up using your iBeacon scanner of choice. On iPhones,
this should already work from the bluetooth screen (not tested), on Android, you will need to use an app like

4
components/esp32_ble_tracker.rst
View File

@ -2,14 +2,14 @@ ESP32 Bluetooth Low Energy Tracker Hub
======================================
.. seo::
:description: Instructions for setting up ESP32 bluetooth low energy device trackers using esphomelib.
:description: Instructions for setting up ESP32 bluetooth low energy device trackers using ESPHome.
:image: bluetooth.png
The ``esp32_ble_tracker`` component creates a global hub so that you can track bluetooth low
energy devices using your ESP32 node.
See :ref:`Setting up devices <esp32_ble_tracker-setting_up_devices>`
for information on how you can find out the MAC address of a device and track it using esphomelib.
for information on how you can find out the MAC address of a device and track it using ESPHome.
.. code-block:: yaml

120
components/esphomeyaml.rst → components/esphome.rst
View File

@ -1,11 +1,11 @@
esphomeyaml Core Configuration
==============================
ESPHome Core Configuration
==========================
.. seo::
:description: Instructions for setting up the core esphomeyaml configuration.
:description: Instructions for setting up the core ESPHome configuration.
:image: cloud-circle.png
Here you specify some core information that esphomeyaml needs to create
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.
@ -13,7 +13,7 @@ where you specify the **name** of the node, the **platform** and
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
name: livingroom
platform: ESP32
board: nodemcu-32s
@ -26,8 +26,8 @@ Configuration variables:
can use the same name. It can also only contain upper/lowercase
characters, digits and underscores.
- **platform** (**Required**, string): The platform your board is on,
either ``ESP32`` or ``ESP8266``. See :ref:`esphomeyaml-arduino_version`.
- **board** (**Required**, string): The board esphomeyaml should
either ``ESP32`` or ``ESP8266``. See :ref:`esphome-arduino_version`.
- **board** (**Required**, string): The board ESPHome should
specify for platformio. For the ESP32, choose the appropriate one
from `this list <http://docs.platformio.org/en/latest/platforms/espressif32.html#boards>`__
and use `this list <http://docs.platformio.org/en/latest/platforms/espressif8266.html#boards>`__
@ -35,17 +35,15 @@ Configuration variables:
Advanced options:
- **esphomelib_version** (*Optional*): The version of the C++ `esphomelib framework <https://github.com/OttoWinter/esphomelib>`__
to use. See :ref:`esphomeyaml-esphomelib_version`.
- **esphome_core_version** (*Optional*): The version of the C++ `ESPHome-Core framework <https://github.com/esphome/esphome-core>`__
to use. See :ref:`esphome-esphome_core_version`.
- **arduino_version** (*Optional*): The version of the arduino framework to link the project against.
See :ref:`esphomeyaml-arduino_version`.
- **build_path** (*Optional*, string): Customize where esphomeyaml will store the build files
for your node. By default, esphomeyaml puts all platformio project files under a folder ``<NODE_NAME>/``,
See :ref:`esphome-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 :ref:`esphomeyaml-platformio_options`.
- **libraries** (*Optional*, list): Additional `platformio libraries <https://platformio.org/lib>`__ to
include in the build. Mostly for custom code.
platformio.ini file. See :ref:`esphome-platformio_options`.
- **use_custom_code** (*Optional*, boolean): Whether to configure the project for writing custom components.
This sets up some flags so that custom code should compile correctly
- **includes** (*Optional*, list of files): A list of files to include in the main (auto-generated) sketch file
@ -53,91 +51,93 @@ Advanced options:
is in.
- **libraries** (*Optional*, list of libraries): A list of `platformio libraries <https://platformio.org/lib>`__
to include in the project. See `platformio lib install <https://docs.platformio.org/en/latest/userguide/lib/cmd_install.html>`__.
- **board_flash_mode** (*Optional*, string): The `SPI flash mode <https://github.com/espressif/esptool/wiki/SPI-Flash-Modes>`__
to use for the board. One of ``qio``, ``qout``, ``dio`` and ``dout``. Defaults to ``dout``.
Automations:
- **on_boot** (*Optional*, :ref:`Automation <automation>`): An automation to perform
when the node starts. See :ref:`esphomeyaml-on_boot`.
when the node starts. See :ref:`esphome-on_boot`.
- **on_shutdown** (*Optional*, :ref:`Automation <automation>`): An automation to perform
right before the node shuts down. See :ref:`esphomeyaml-on_shutdown`.
right before the node shuts down. See :ref:`esphome-on_shutdown`.
- **on_loop** (*Optional*, :ref:`Automation <automation>`): An automation to perform
on each ``loop()`` iteration. See :ref:`esphomeyaml-on_loop`.
on each ``loop()`` iteration. See :ref:`esphome-on_loop`.
.. _esphomeyaml-esphomelib_version:
.. _esphome-esphome_core_version:
``esphomelib_version``
``esphome_core_version``
----------------------
With the ``esphomelib_version`` parameter you can tell esphomeyaml which version of the C++ framework
With the ``esphome_core_version`` parameter you can tell ESPHome which version of the C++ framework
to use when compiling code. For example, you can configure using the most recent (potentially unstable)
version of esphomelib straight from github. Or you can configure the use of a local copy of esphomelib
version of ESPHome straight from github. Or you can configure the use of a local copy of esphome-core
using this configuration option.
First, you can configure the use of either the latest esphomelib stable release (``latest``),
First, you can configure the use of either the latest esphome-core stable release (``latest``),
the latest development code from GitHub (``dev``), or a specific version number (``1.8.0``).
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
# ...
# Use the latest esphomelib stable release
esphomelib_version: latest
# Use the latest ESPHome stable release
esphome_core_version: latest
# Or use the latest code from github
esphomelib_version: dev
esphome_core_version: dev
# Use a specific version number
esphomelib_version: 1.8.0
esphome_core_version: 1.8.0
Alternatively, if you want to develop for esphomelib, you can download the
`latest code from GitHub <https://github.com/OttoWinter/esphomelib/archive/dev.zip>`__, extract the contents,
and point esphomeyaml to your local copy. Then you can modify the esphomelib to your needs or to fix bugs.
Alternatively, if you want to develop for ESPHome, you can download the
`latest code from GitHub <https://github.com/esphome/esphome-core/archive/dev.zip>`__, extract the contents,
and point ESPHome to your local copy. Then you can modify the ESPHome to your needs or to fix bugs.
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
# ...
# Use a local copy of esphomelib
esphomelib_version:
local: path/to/esphomelib
# Use a local copy of ESPHome
esphome_core_version:
local: path/to/esphome-core
And last, you can make esphomeyaml use a specific branch/commit/tag from a remote git repository:
And last, you can make ESPHome use a specific branch/commit/tag from a remote git repository:
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
# ...
# Use a specific commit/branch/tag from a remote repository
esphomelib_version:
# Repository defaults to https://github.com/OttoWinter/esphomelib.git
repository: https://github.com/OttoWinter/esphomelib.git
esphome_core_version:
# Repository defaults to https://github.com/esphome/esphome-core.git
repository: https://github.com/esphome/esphome-core.git
branch: master
esphomelib_version:
repository: https://github.com/somebody/esphomelib.git
esphome_core_version:
repository: https://github.com/somebody/esphome-core.git
commit: d27bac9263e8a0a5a00672245b38db3078f8992c
esphomelib_version:
repository: https://github.com/OttoWinter/esphomelib.git
esphome_core_version:
repository: https://github.com/esphome/esphome-core.git
tag: v1.8.0
.. _esphomeyaml-arduino_version:
.. _esphome-arduino_version:
``arduino_version``
-------------------
esphomelib uses the arduino framework internally to handle all low-level interactions like
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 esphomeyaml which arduino framework to use for compiling.
option you can tell ESPHome which arduino framework to use for compiling.
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
# ...
# Default: use the recommended version, usually this equals
# the latest version.
@ -158,17 +158,11 @@ list of arduino frameworks `here <https://github.com/esp8266/Arduino/releases>`_
* `2.4.2 <https://github.com/esp8266/Arduino/releases/tag/2.4.2>`__ (the latest version)
* `2.4.1 <https://github.com/esp8266/Arduino/releases/tag/2.4.1>`__
* `2.4.0 <https://github.com/esp8266/Arduino/releases/tag/2.4.0>`__
* `2.3.0 <https://github.com/esp8266/Arduino/releases/tag/2.3.0>`__ (tasmota uses this)
.. warning::
Over-the-Air update passwords do not work with the arduino framework
version 2.3.0
For the ESP32, there's currently only one arduino framework version:
`1.0.0 <https://github.com/espressif/arduino-esp32/releases/tag/1.0.0>`__.
.. _esphomeyaml-on_boot:
.. _esphome-on_boot:
``on_boot``
-----------
@ -178,7 +172,7 @@ is already set up. You can however change this using the ``priority`` parameter.
.. code-block:: yaml
esphomeyaml:
esphome:
# ...
on_boot:
priority: -10
@ -202,7 +196,7 @@ Configuration variables:
- See :ref:`Automation <automation>`.
.. _esphomeyaml-on_shutdown:
.. _esphome-on_shutdown:
``on_shutdown``
---------------
@ -217,7 +211,7 @@ too many WiFi/MQTT connection attempts, Over-The-Air updates being applied or th
.. code-block:: yaml
esphomeyaml:
esphome:
# ...
on_shutdown:
then:
@ -225,7 +219,7 @@ too many WiFi/MQTT connection attempts, Over-The-Air updates being applied or th
Configuration variables: See :ref:`Automation <automation>`.
.. _esphomeyaml-on_loop:
.. _esphome-on_loop:
``on_loop``
-----------
@ -234,19 +228,19 @@ This automation will be triggered on every ``loop()`` iteration (usually around
.. code-block:: yaml
esphomeyaml:
esphome:
# ...
on_loop:
then:
# do something
.. _esphomeyaml-platformio_options:
.. _esphome-platformio_options:
``platformio_options``
----------------------
Platformio supports a number of options in its ``platformio.ini`` file. With the ``platformio_options``
parameter you can tell esphomeyaml what options to pass into the ``env`` section of the platformio file
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: https://docs.platformio.org/en/latest/projectconf/section_env.html
@ -254,7 +248,7 @@ You can view a full list of platformio options here: https://docs.platformio.org
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
# ...
platformio_options:
upload_speed: 115200

7
components/ethernet.rst
View File

@ -2,7 +2,7 @@ Ethernet Component
==================
.. seo::
:description: Instructions for setting up the Ethernet configuration for your ESP32 node in esphomelib.
:description: Instructions for setting up the Ethernet configuration for your ESP32 node in ESPHome.
:image: ethernet.png
:keywords: Ethernet, ESP32
@ -11,7 +11,7 @@ Ethernet Component
This integration is experimental as I don't have the hardware to test it (yet).
If you can verify it works (or if it doesn't), notify me on `discord <https://discord.gg/KhAMKrd>`__.
This core esphomelib component sets up ethernet connections for ESP32s.
This core ESPHome component sets up ethernet connections for ESP32s.
Ethernet for ESP8266 is not supported.
.. code-block:: yaml
@ -59,9 +59,6 @@ Configuration variables:
- **dns1** (*Optional*, IPv4 address): The main DNS server to use.
- **dns2** (*Optional*, IPv4 address): The backup DNS server to use.
- **hostname** (*Optional*, string): Manually set the hostname of the
node. Can only be 63 long at max and must only contain alphanumeric
characters plus dashes and underscores.
- **domain** (*Optional*, string): Set the domain of the node hostname used for uploading.
For example, if it's set to ``.local``, all uploads will be sent to ``<HOSTNAME>.local``.
Defaults to ``.local``.

6
components/i2c.rst
View File

@ -4,7 +4,7 @@ I²C Bus
=======
.. seo::
:description: Instructions for setting up the i2c bus to communicate with 2-wire devices in esphomelib
:description: Instructions for setting up the i2c bus to communicate with 2-wire devices in ESPHome
:image: i2c.png
:keywords: i2c, iic, bus
@ -29,7 +29,7 @@ Configuration variables:
- **scl** (*Optional*, :ref:`config-pin`): The pin for the clock line of the i²c bus.
Defaults to the default of your board (usually GPIO22 for ESP32 and
GPIO5 for ESP8266).
- **scan** (*Optional*, boolean): If esphomelib should do a search of the i2c address space on startup.
- **scan** (*Optional*, boolean): If ESPHome should do a search of the i2c address space on startup.
Note that this can slow down startup and is only recommended for when setting up new sensors. Defaults to
``False``.
- **frequency** (*Optional*, float): Set the frequency the i²c bus should operate on.
@ -37,7 +37,7 @@ Configuration variables:
.. note::
If you're using the ESP32 and i2c frequently is showing errors in the logs, try with the latest
version of the Arduino framework. See :ref:`esphomeyaml-arduino_version` for information on how to do this.
version of the Arduino framework. See :ref:`esphome-arduino_version` for information on how to do this.
See Also
--------

2
components/light/binary.rst
View File

@ -2,7 +2,7 @@ Binary Light
============
.. seo::
:description: Instructions for setting up binary ON/OFF lights in esphomelib.
:description: Instructions for setting up binary ON/OFF lights in ESPHome.
:image: lightbulb.png
The ``binary`` light platform creates a simple ON/OFF-only light from a

2
components/light/fastled_clockless.rst
View File

@ -6,7 +6,7 @@ FastLED Clockless Light
:image: color_lens.png
The ``fastled_clockless`` light platform allows you to create RGB lights
in esphomelib for a :ref:`number of supported chipsets <fastled_clockless-chipsets>`.
in ESPHome for a :ref:`number of supported chipsets <fastled_clockless-chipsets>`.
Clockless FastLED lights differ from the
:doc:`fastled_spi` in that they only have a single data wire to connect, and not separate data and clock wires.

2
components/light/fastled_spi.rst
View File

@ -6,7 +6,7 @@ FastLED SPI Light
:image: color_lens.png
The ``fastled_spi`` light platform allows you to create RGB lights
in esphomelib for a :ref:`number of supported chipsets <fastled_spi-chipsets>`.
in ESPHome for a :ref:`number of supported chipsets <fastled_spi-chipsets>`.
SPI FastLED lights differ from the
:doc:`fastled_clockless` in that they require two pins to be connected, one for a data and one for a clock signal

10
components/light/index.rst
View File

@ -2,10 +2,10 @@ Light Component
===============
.. seo::
:description: Instructions for setting up lights and light effects in esphomelib.
:description: Instructions for setting up lights and light effects in ESPHome.
:image: folder-open.png
The ``light`` domain in esphomeyaml lets you create lights that will
The ``light`` domain in ESPHome lets you create lights that will
automatically be shown in Home Assistant’s frontend and have many
features such as RGB colors, transitions, flashing and effects.
@ -144,11 +144,11 @@ Configuration options:
Light Effects
-------------
esphomelib also offers a bunch of light effects you can use for your lights. The defaults for the
effect parameters are made to work well on their own but of course esphomelib gives you the option to manually change
ESPHome also offers a bunch of light effects you can use for your lights. The defaults for the
effect parameters are made to work well on their own but of course ESPHome gives you the option to manually change
these parameters.
With esphomelib's light effects system you're basically creating a bunch of entries for the effects dropdown in
With ESPHome's light effects system you're basically creating a bunch of entries for the effects dropdown in
Home Assistant. If you wish to have several variants of the same effect you can of course also create multiple
entries with each having a unique name like so:

14
components/light/monochromatic.rst
View File

@ -26,6 +26,12 @@ The ``monochromatic`` light platform creates a simple brightness-only light from
name: "Kitchen Lights"
output: output_component1
# Example output entry
output:
- platform: esp8266_pwm
id: output_component1
pin: D1
Configuration variables:
------------------------
@ -40,14 +46,6 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
.. note::
The ``monochromatic`` light platform only works with ``float``
:ref:`outputs <output>` that can output any light intensity percentage like the
:doc:`ESP32 LEDC </components/output/ledc>` or
:doc:`ESP8266 PWM </components/output/esp8266_pwm>` components and does **not** work with output
platforms like the :doc:`/components/output/gpio`.
See Also
--------

2
components/light/neopixelbus.rst
View File

@ -6,7 +6,7 @@ Neopixelbus Light
:image: color_lens.png
The ``neopixelbus`` light platform allows you to create RGB lights
in esphomelib for a individually addressable lights like NeoPixel or WS2812.
in ESPHome for a individually addressable lights like NeoPixel or WS2812.
It is very similar to the :doc:`fastled_clockless` and :doc:`fastled_spi` platforms;
in fact most addressable lights are supported through both light platforms. The

16
components/light/rgb.rst
View File

@ -2,7 +2,7 @@ RGB Light
=========
.. seo::
:description: Instructions for setting up RGB lights in esphomelib.
:description: Instructions for setting up RGB lights in ESPHome.
:image: rgb.png
The ``rgb`` light platform creates an RGB light from 3 :ref:`float output components <output>`
@ -28,6 +28,13 @@ The ``rgb`` light platform creates an RGB light from 3 :ref:`float output compon
green: output_component2
blue: output_component3
# Example output entry
output:
- platform: esp8266_pwm
id: output_component1
pin: D1
# Repeat for green and blue output
Configuration variables:
------------------------
@ -43,13 +50,6 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
.. note::
The RGB light platform only works with ``float`` :ref:`outputs <output>` that
can output any light intensity percentage like the :doc:`ESP32 LEDC </components/output/ledc>` or
:doc:`ESP8266 PWM </components/output/esp8266_pwm>` components and does **not** work with output
platforms like the :doc:`/components/output/gpio`.
See Also
--------

4
components/logger.rst
View File

@ -2,7 +2,7 @@ Logger Component
================
.. seo::
:description: Instructions for setting up the central logging component in esphomelib.
:description: Instructions for setting up the central logging component in ESPHome.
:image: file-document-box.png
The logger component automatically logs all log messages through the
@ -50,7 +50,7 @@ Possible log levels are (sorted by severity):
- ``WARN``
- With this log level, warnings and errors are logged. Warnings are issues like invalid readings from
sensors that esphomelib can recover from. Color: yellow
sensors that ESPHome can recover from. Color: yellow
- ``INFO``

35
components/mqtt.rst
View File

@ -2,12 +2,12 @@ MQTT Client Component
=====================
.. seo::
:description: Instructions for setting up the MQTT client to communicate with the local network in esphomelib.
:description: Instructions for setting up the MQTT client to communicate with the local network in ESPHome.
:image: mqtt.png
:keywords: MQTT
The MQTT Client Component sets up the MQTT connection to your broker and
is currently required for esphomelib to work. In most cases, you will
is currently required for ESPHome to work. In most cases, you will
just be able to copy over the `MQTT
section <https://www.home-assistant.io/components/mqtt/>`__ of your Home
Assistant configuration.
@ -69,7 +69,7 @@ Configuration variables:
MQTTMessage
-----------
With the MQTT Message schema you can tell esphomeyaml how a specific MQTT message should be sent.
With the MQTT Message schema you can tell ESPHome how a specific MQTT message should be sent.
It is used in several places like last will and birth messages or MQTT log options.
.. code-block:: yaml
@ -110,9 +110,9 @@ The ``log_topic`` has an additional configuration option:
Using with Home Assistant
-------------------------
Using esphomelib with Home Assistant is easy, simply setup an MQTT
Using ESPHome with Home Assistant is easy, simply setup an MQTT
broker (like `mosquitto <https://mosquitto.org/>`__) and point both your
Home Assistant installation and esphomelib to that broker. Next, enable
Home Assistant installation and ESPHome to that broker. Next, enable
discovery in your Home Assistant configuration with the following:
.. code-block:: yaml
@ -122,23 +122,22 @@ discovery in your Home Assistant configuration with the following:
broker: ...
discovery: True
And that should already be it 🎉 All devices defined through
esphomelib/esphomeyaml should show up automatically in the entities
section of Home Assistant.
And that should already be it 🎉 All devices defined through ESPHome should show up automatically
in the entities section of Home Assistant.
When adding new entities, you might run into trouble with old entities
still appearing in Home Assistant’s front-end. This is because in order
to have Home Assistant “discover” your devices on restart, all discovery
MQTT messages need to be retained. Therefore the old entities will also
re-appear on every Home Assistant restart even though they’re in
esphomeyaml anymore.
ESPHome anymore.
To fix this, esphomeyaml has a simple helper script that purges stale
To fix this, ESPHome has a simple helper script that purges stale
retained messages for you:
.. code-block:: bash
esphomeyaml configuration.yaml clean-mqtt
esphome configuration.yaml clean-mqtt
This will remove all retained messages with the topic
``<DISCOVERY_PREFIX>/+/NODE_NAME/#``. If you want to purge on another
@ -149,7 +148,7 @@ topic, simply add ``--topic <your_topic>`` to the command.
Defaults
--------
By default, esphomelib will prefix all messages with your node name or
By default, ESPHome will prefix all messages with your node name or
``topic_prefix`` if you have specified it manually. The client id will
automatically be generated by using your node name and adding the MAC
address of your device to it. Next, discovery is enabled by default with
@ -158,7 +157,7 @@ Home Assistant’s default prefix ``homeassistant``.
If you want to prefix all MQTT messages with a different prefix, like
``home/living_room``, you can specify a custom ``topic_prefix`` in the
configuration. That way, you can use your existing wildcards like
``home/+/#`` together with esphomelib. All other features of esphomelib
``home/+/#`` together with ESPHome. All other features of ESPHome
(like availability) should still work correctly.
.. _mqtt-last_will_birth:
@ -166,7 +165,7 @@ configuration. That way, you can use your existing wildcards like
Last Will And Birth Messages
----------------------------
esphomelib (and esphomeyaml) uses the `last will
ESPHome uses the `last will
testament <https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament>`__
and birth message feature of MQTT to achieve availability reporting for
Home Assistant. If the node is not connected to MQTT, Home Assistant
@ -176,7 +175,7 @@ will show all its entities as unavailable (a feature 😉).
:align: center
:width: 50.0%
By default, esphomelib will send a retained MQTT message to
By default, ESPHome will send a retained MQTT message to
``<TOPIC_PREFIX>/status`` with payload ``online``, and will tell the
broker to send a message ``<TOPIC_PREFIX>/status`` with payload
``offline`` if the connection drops.
@ -215,11 +214,11 @@ update the fingerprints variable. Additionally, SHA1 is known to be partially in
and with some computing power the fingerprint can be faked.
To get this fingerprint, first put the broker and port options in the configuration and
then run the ``mqtt-fingerprint`` script of esphomeyaml to get the certificate:
then run the ``mqtt-fingerprint`` script of ESPHome to get the certificate:
.. code-block:: bash
esphomeyaml livingroom.yaml mqtt-fingerprint
esphome livingroom.yaml mqtt-fingerprint
> SHA1 Fingerprint: a502ff13999f8b398ef1834f1123650b3236fc07
> Copy above string into mqtt.ssl_fingerprints section of livingroom.yaml
@ -235,7 +234,7 @@ then run the ``mqtt-fingerprint`` script of esphomeyaml to get the certificate:
MQTT Component Base Configuration
---------------------------------
All components in esphomelib that do some sort of communication through
All components in ESPHome that do some sort of communication through
MQTT can have some overrides for specific options.
.. code-block:: yaml

9
components/my9231.rst
View File

@ -2,14 +2,14 @@ MY9231/MY9291 LED driver Component
==================================
.. seo::
:description: Instructions for setting up MY9231 and MY9291 LED drives in esphomelib.
:description: Instructions for setting up MY9231 and MY9291 LED drives in ESPHome.
:image: my9231.png
:keywords: MY9231, MY9291, Sonoff B1, Ai-thinker AiLight WiFi light bulb, Arilux E27 Smart Bulb
The MY9231/MY9291 component represents a MY9231/MY9291 LED diver chain
(`MY9231 description <http://www.my-semi.com.tw/file/MY9231_BF_0.91.pdf>`__,
`MY9291 description <http://www.my-semi.com.tw/file/MY9291_BF_0.91.pdf>`__) in
esphomelib. Communication is done with two GPIO pins (DI and DCKI) and multiple
ESPHome. Communication is done with two GPIO pins (DI and DCKI) and multiple
driver chips can be chained. There are two models with different number of
output channels (MY9291 with 4 channels and MY9231 with 3 channels). They are
popular driver chips used in smart light blubs:
@ -26,7 +26,7 @@ global ``my9231`` hub and give it an id, and then define the
One of the features of the MY9231/MY9291 driver is that the chips
remember their state after a power cycling. Unfortunately, the
state of the driver can not be read. Therefore, if esphomelib can
state of the driver can not be read. Therefore, if ESPHome can
not restore the previous state, it will result in a mismatch of
the driver output and the internal state (= MQTT state). So you
can configure the behaviour on boot time:
@ -85,11 +85,10 @@ complete configuration for a Sonoff B1 looks like:
.. code-block:: yaml
esphomeyaml:
esphome:
name: <NAME_OF_NODE>
platform: ESP8266
board: esp01_1m
board_flash_mode: dout
wifi:
ssid: <YOUR_SSID>

47
components/ota.rst
View File

@ -8,26 +8,11 @@ OTA Update Component
With the OTA (Over The Air) update component you can upload your
firmware binaries to your node without having to use an USB cable for
uploads. esphomeyaml natively supports this through its ``run`` and
uploads. ESPHome natively supports this through its ``run`` and
``upload`` helper scripts.
.. note::
Please be aware that ESP8266 modules must be reset after a serial
upload before OTA can work.
When you are trying to conduct an OTA update and receive an error message
``Bad Answer: ERR: ERROR[11]: Invalid bootstrapping`` the reason is
very likely that power-cycling the ESP module is required once after
the serial upload.
Optionally, you can also define a password to use for OTA updates so
that an intruder isn’t able to upload any firmware to the ESP without
having hardware access to it. This password is also hashed
automatically, so an intruder can’t extract the password from the
binary.
esphomelib also supports an “OTA safe mode”. If for some reason your
node gets into a boot loop, esphomelib will automatically try to detect
ESPHome also has an "OTA safe mode". If for some reason your
node gets into a boot loop, ESPHome will automatically try to detect
this and will go over into a safe mode after 10 unsuccessful boot
attempts. In that mode, all components are disabled and only Serial
Logging+WiFi+OTA are initialized, so that you can upload a new binary.
@ -49,14 +34,25 @@ Configuration variables:
to ``3232`` for the ESP32 and ``8266`` for the ESP8266.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
.. note::
Please be aware that ESP8266 modules must be reset after a serial
upload before OTA can work.
When you are trying to conduct an OTA update and receive an error message
``Bad Answer: ERR: ERROR[11]: Invalid bootstrapping`` the reason is
very likely that power-cycling the ESP module is required once after
the serial upload.
Updating the password:
----------------------
Since the password is used both for compiling and uploading the regular ``esphomeyaml <file> run`` won't work of course. This issue can be worked around by executing the operations separately through a ``on_boot`` trigger:
Since the password is used both for compiling and uploading the regular ``esphome <file> run``
won't work of course. This issue can be worked around by executing the operations separately
through a ``on_boot`` trigger:
.. code-block:: yaml
esphomeyaml:
esphome:
on_boot:
- lambda: |-
id(ota).set_auth_password("New password");
@ -64,17 +60,6 @@ Since the password is used both for compiling and uploading the regular ``esphom
password: "Old password"
id: ota
.. note::
If you get errors like
.. code::
ERROR [esphomeyaml.espota] Failed
ERROR [esphomeyaml.espota] Host livingroom.local Not Found
when attempting to upload via OTA, please try setting a :ref:`manual IP for WiFi <wifi-manual_ip>`.
See Also
--------

8
components/output/custom.rst
View File

@ -2,7 +2,7 @@ Custom Output
=============
This integration can be used to create custom binary and float :doc:`outputs </components/output/index>`
in esphomelib using the C++ (Arduino) API.
in ESPHome using the C++ (Arduino) API.
Please first read :doc:`/components/sensor/custom` guide, the same principles apply here.
@ -11,8 +11,8 @@ same as the :doc:`ESP8266 software PWM output </components/output/esp8266_pwm>`.
.. code-block:: cpp
#include "esphomelib.h"
using namespace esphomelib;
#include "esphome.h"
using namespace esphome;
class MyCustomFloatOutput : public Component, public output::FloatOutput {
public:
@ -49,7 +49,7 @@ And in YAML:
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
includes:
- my_output.h

16
components/output/esp8266_pwm.rst
View File

@ -6,13 +6,9 @@ ESP8266 Software PWM Output
:image: pwm.png
The ESP8266 Software PWM platform allows you to use a software PWM on
the pins GPIO0-GPIO16 on your ESP8266. As this is only a software PWM
and not a hardware PWM (like the :doc:`ESP32 LEDC PWM <ledc>`) and has a key
disadvantage: There can be a noticeable amount of flickering with increased WiFi
activity.
If you need a stable PWM signal, it’s definitely recommended to use the
successor of the ESP8266, the ESP32, and its :doc:`ESP32 LEDC PWM <ledc>` instead.
the pins GPIO0-GPIO16 on your ESP8266. Note that this is a software PWM,
so there can be some flickering during periods of high wifi activity. Hardware PWMs
like the one on the ESP32 (see :doc:`ledc`) are preferred.
.. code-block:: yaml
@ -23,6 +19,12 @@ successor of the ESP8266, the ESP32, and its :doc:`ESP32 LEDC PWM <ledc>` instea
frequency: 1000 Hz
id: pwm_output
# Example usage in a light
light:
- platform: monochromatic
output: pwm_output
name: "Kitchen Light"
Configuration variables:
------------------------

2
components/output/gpio.rst
View File

@ -7,7 +7,7 @@ GPIO Output
The GPIO output component is quite simple: It exposes a single GPIO pin
as an output component. Note that output components are **not** switches and
will not show up in Home Assistant. See :doc:`/esphomeyaml/components/switch/gpio`.
will not show up in Home Assistant. See :doc:`/components/switch/gpio`.
.. code-block:: yaml

4
components/output/index.rst
View File

@ -4,11 +4,11 @@ Output Component
================
.. seo::
:description: Instructions for setting up generic outputs in esphomelib
:description: Instructions for setting up generic outputs in ESPHome
:image: folder-open.png
Each platform of the ``output`` domain exposes some output to
esphomelib. These are grouped into two categories: ``binary`` outputs
ESPHome. These are grouped into two categories: ``binary`` outputs
(that can only be ON/OFF) and ``float`` outputs (like PWM, can output
any rational value between 0 and 1).

13
components/output/ledc.rst
View File

@ -14,9 +14,15 @@ of the ESP32 as an output component.
# Example configuration entry
output:
- platform: ledc
pin: 19
pin: GPIO19
id: gpio_19
# Example usage in a light
light:
- platform: monochromatic
output: gpio_19
name: "Kitchen Light"
Configuration variables:
------------------------
@ -26,10 +32,13 @@ Configuration variables:
channel’s timer. Two LEDC channels always share the same timer and
therefore also the same frequency. Defaults to 1000Hz.
- **bit_depth** (*Optional*, int): The bit depth to use for the LEDC channel. Defaults to 12.
- All other options from :ref:`Output <config-output>`.
Advanced options:
- **channel** (*Optional*, int): Manually set the `LEDC
channel <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/ledc.html#configure-channel>`__
to use. Two adjacent channels share the same timer. Defaults to an automatic selection.
- All other options from :ref:`Output <config-output>`.
See Also
--------

2
components/pca9685.rst
View File

@ -8,7 +8,7 @@ PCA9685 PWM Component
The PCA9685 component represents a PCA9685 12-bit PWM driver
(`datasheet <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/ledc.html#configure-channel>`__,
`adafruit <https://www.adafruit.com/product/815>`__) in esphomelib. It
`adafruit <https://www.adafruit.com/product/815>`__) in ESPHome. It
uses :ref:`I²C Bus <i2c>` for communication.
To use the channels of this components, you first need to setup the

8
components/pcf8574.rst
View File

@ -2,17 +2,17 @@ PCF8574 I/O Expander
====================
.. seo::
:description: Instructions for setting up PCA8574 digital port expanders in esphomelib.
:description: Instructions for setting up PCA8574 digital port expanders in ESPHome.
:image: pcf8574.jpg
:keywords: Xiaomi, Mi Flora, BLE, Bluetooth
The PCF8574 component allows you to use PCF8574 or PCF8575 I/O expanders
(`datasheet <http://www.ti.com/lit/ds/symlink/pcf8574.pdf>`__,
`Sparkfun`_) in esphomeyaml. It uses :ref:`I²C Bus <i2c>` for communication.
`Sparkfun`_) in ESPHome. It uses :ref:`I²C Bus <i2c>` for communication.
Once configured, you can use any of the 8 pins (PCF8574) or 16 pins (PCF8575) as
pins for your projects. Within esphomelib they emulate a real internal GPIO pin
and can therefore be used with many of esphomelib's components such as the GPIO
pins for your projects. Within ESPHome they emulate a real internal GPIO pin
and can therefore be used with many of ESPHome's components such as the GPIO
binary sensor or GPIO switch.
Any option accepting a :ref:`Pin Schema <config-pin_schema>` can theoretically be used, but some more

4
components/pn532.rst
View File

@ -2,13 +2,13 @@ PN532 NFC/RFID Controller Hub
=============================
.. seo::
:description: Instructions for setting up PN532 NFC tag readers in esphomelib
:description: Instructions for setting up PN532 NFC tag readers in ESPHome
:image: pn532.jpg
:keywords: PN532, NFC, RFID
The ``pn532`` component allows you to use PN532 NFC/RFID controllers
(`datasheet <https://cdn-shop.adafruit.com/datasheets/pn532ds.pdf>`__, `adafruit <https://www.adafruit.com/product/364>`__)
with esphomelib. This component is a global hub that establishes the connection to the PN532 via :ref:`SPI <spi>` and
with ESPHome. This component is a global hub that establishes the connection to the PN532 via :ref:`SPI <spi>` and
outputs its data. Using the :doc:`PN532 binary sensors </components/binary_sensor/pn532>` you can then
create individual binary sensors that track if an NFC/RFID tag is currently detected by the PN532.

4
components/rdm6300.rst
View File

@ -2,13 +2,13 @@ RDM6300 NFC/RFID Hub
====================
.. seo::
:description: Instructions for setting up RDM6300 NFC/RFID tag readers in esphomelib.
:description: Instructions for setting up RDM6300 NFC/RFID tag readers in ESPHome.
:image: rdm6300.jpg
:keywords: RDM6300, NFC, RFID
The ``rdm6300`` component allows you to use RDM6300 NFC/RFID controllers
(`datasheet <https://elty.pl/upload/download/RFID/RDM630-Spec.pdf>`__, `iTead <https://www.itead.cc/rdm6300.html>`__)
with esphomelib. This component is a global hub that establishes the connection to the RDM6300 via :ref:`UART <uart>` and
with ESPHome. This component is a global hub that establishes the connection to the RDM6300 via :ref:`UART <uart>` and
translates the received data. Using the :doc:`RDM6300 binary sensors </components/binary_sensor/rdm6300>` you can then
create individual binary sensors that track if an NFC/RFID tag is currently detected by the RDM6300.

3
components/remote_receiver.rst
View File

@ -2,7 +2,7 @@ Remote Receiver Component
=========================
.. seo::
:description: Instructions for setting up remote receivers in esphomelib.
:description: Instructions for setting up remote receivers in ESPHome.
:image: remote.png
:keywords: RF, infrared
@ -35,6 +35,7 @@ Configuration variables:
- **samsung**: Decode and dump Samsung infrared codes.
- **sony**: Decode and dump Sony infrared codes.
- **rc_switch**: Decode and dump RCSwitch RF codes.
- **rc5**: Decode and dump RC5 IR codes.
- **raw**: Print all remote codes in their raw form. Useful for using arbitrary protocols.
- **tolerance** (*Optional*, int): The percentage that the remote signal lengths can deviate in the

2
components/remote_transmitter.rst
View File

@ -2,7 +2,7 @@ Remote Transmitter Component
============================
.. seo::
:description: Instructions for setting up remote transmitters in esphomelib
:description: Instructions for setting up remote transmitters in ESPHome
:image: remote.png
:keywords: RF, infrared

2
components/sensor/ads1115.rst
View File

@ -7,7 +7,7 @@ ADS1115 Sensor
:keywords: ADS1115
The ``ads1115`` sensor allows you to use your ADS1115 sigma-delta ADC
sensors (`datasheet <http://www.ti.com/lit/ds/symlink/ads1115.pdf>`__, `Adafruit`_) with esphomelib.
sensors (`datasheet <http://www.ti.com/lit/ds/symlink/ads1115.pdf>`__, `Adafruit`_) with ESPHome.
First, setup a :doc:`ADS1115 Hub </components/ads1115>` for your ADS1115 sensor and then use this
sensor platform to create individual sensors that will report the
voltage to Home Assistant.

2
components/sensor/apds9960.rst
View File

@ -7,7 +7,7 @@ APDS9960 Sensor
The ``apds9960`` sensor platform allows you to use your APDS9960 RGB and gesture sensors
(`datasheet <https://cdn-shop.adafruit.com/datasheets/BST-BME280_DS001-10.pdf>`__,
`Sparkfun`_) with esphomelib.
`Sparkfun`_) with ESPHome.
The :ref:`I²C <i2c>` is
required to be set up in your configuration for this sensor to work.

4
components/sensor/bh1750.rst
View File

@ -2,13 +2,13 @@ BH1750 Ambient Light Sensor
===========================
.. seo::
:description: Instructions for setting up BH1750 ambient light sensors in esphomelib.
:description: Instructions for setting up BH1750 ambient light sensors in ESPHome.
:image: bh1750.jpg
:keywords: BH1750
The ``bh1750`` sensor platform allows you to use your BH1750
(`datasheet <http://www.mouser.com/ds/2/348/bh1750fvi-e-186247.pdf>`__, `Aliexpress`_, `mklec`_)
ambient light sensor with esphomelib. The :ref:`I²C bus <i2c>` is required to be set up in
ambient light sensor with ESPHome. The :ref:`I²C bus <i2c>` is required to be set up in
your configuration for this sensor to work.
.. figure:: images/bh1750-full.jpg

2
components/sensor/bme280.rst
View File

@ -8,7 +8,7 @@ BME280 Temperature+Pressure+Humidity Sensor
The ``bme280`` sensor platform allows you to use your BME280
(`datasheet <https://cdn-shop.adafruit.com/datasheets/BST-BME280_DS001-10.pdf>`__,
`Adafruit`_) temperature, pressure and humidity sensors with esphomelib. The :ref:`I²C <i2c>` is
`Adafruit`_) temperature, pressure and humidity sensors with ESPHome. The :ref:`I²C <i2c>` is
required to be set up in your configuration for this sensor to work.
.. figure:: images/bme280-full.jpg

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.6 KiB

After

Width:  |  Height:  |  Size: 3.6 KiB

2
components/sensor/bme680.rst
View File

@ -8,7 +8,7 @@ BME680 Temperature+Pressure+Humidity+Gas Sensor
The ``bme680`` sensor platform allows you to use your BME680
(`datasheet <https://cdn-shop.adafruit.com/product-files/3660/BME680.pdf>`__,
`Adafruit`_) temperature, pressure and humidity sensors with esphomelib. The :ref:`I²C <i2c>` is required to be set up in
`Adafruit`_) temperature, pressure and humidity sensors with ESPHome. The :ref:`I²C <i2c>` is required to be set up in
your configuration for this sensor to work.
.. figure:: images/bme680-full.jpg

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 4.4 KiB

After

Width:  |  Height:  |  Size: 4.3 KiB

2
components/sensor/bmp085.rst
View File

@ -11,7 +11,7 @@ The BMP085 sensor platform allows you to use your BMP085
`adafruit <https://www.adafruit.com/product/391>`__) and BMP180
(`datasheet <https://cdn-shop.adafruit.com/datasheets/BST-BMP180-DS000-09.pdf>`__,
`adafruit <https://www.adafruit.com/product/1603>`__) temperature and
pressure sensors with esphomelib. The :ref:`I²C <i2c>` is required to be set up in
pressure sensors with ESPHome. The :ref:`I²C <i2c>` is required to be set up in
your configuration for this sensor to work.
.. figure:: images/bmp180-full.jpg

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.3 KiB

After

Width:  |  Height:  |  Size: 2.3 KiB

4
components/sensor/bmp280.rst
View File

@ -2,13 +2,13 @@ BMP280 Temperature+Pressure Sensor
==================================
.. seo::
:description: Instructions for setting up BMP280 temperature and pressure sensors with esphomelib
:description: Instructions for setting up BMP280 temperature and pressure sensors with ESPHome
:image: bmp280.jpg
:keywords: BMP280
The ``bmp280`` sensor platform allows you to use your BMP280
(`datasheet <https://cdn-shop.adafruit.com/datasheets/BST-BMP280-DS001-11.pdf>`__,
`Adafruit`_) temperature and pressure sensors with esphomelib. The :ref:`I²C <i2c>` is
`Adafruit`_) temperature and pressure sensors with ESPHome. The :ref:`I²C <i2c>` is
required to be set up in your configuration for this sensor to work.
.. figure:: images/bmp280-full.jpg

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.1 KiB

After

Width:  |  Height:  |  Size: 3.1 KiB

2
components/sensor/cse7766.rst
View File

@ -8,7 +8,7 @@ CSE7766 Power Sensor
The ``cse7766`` sensor platform allows you to use your CSE7766 voltage/current and power sensors
(`datasheet <http://dl.itead.cc/S31/CSE7766.pdf>`__) sensors with
esphomelib. This sensor is commonly found in Sonoff POW R2.
ESPHome. This sensor is commonly found in Sonoff POW R2.
As the communication with the CSE7766 done using UART, you need
to have an :ref:`UART bus <uart>` in your configuration with the ``rx_pin`` connected to the CSE7766.

60
components/sensor/custom.rst
View File

@ -2,25 +2,25 @@ Custom Sensor Component
=======================
.. seo::
:description: Instructions for setting up Custom C++ sensors with esphomelib.
:description: Instructions for setting up Custom C++ sensors with ESPHome.
:image: language-cpp.png
:keywords: C++, Custom
.. warning::
While I do try to keep the esphomeyaml configuration options as stable as possible
and back-port them, the esphomelib API is less stable. If something in the APIs needs
While I do try to keep the ESPHome configuration options as stable as possible
and back-port them, the ESPHome API is less stable. If something in the APIs needs
to be changed in order for something else to work, I will do so.
So, you just set up esphomelib for your ESP32/ESP8266, but sadly esphomelib is missing a sensor integration
So, you just set up ESPHome for your ESP32/ESP8266, but sadly ESPHome is missing a sensor integration
you'd really like to have 😕. It's pretty much impossible to support every single sensor, as there are simply too many.
That's why esphomelib has a really simple API for you to create your own **custom sensors** 🎉
That's why ESPHome has a really simple API for you to create your own **custom sensors** 🎉
In this guide, we will go through creating a custom sensor component for the
`BMP180 <https://www.adafruit.com/product/1603>`__ pressure sensor (we will only do the pressure part,
temperature is more or less the same). During this guide, you will learn how to 1. define a custom sensor
esphomelib can use 2. go over how to register the sensor so that it will be shown inside Home Assistant and
3. leverage an existing arduino library for the BMP180 with esphomelib.
ESPHome can use 2. go over how to register the sensor so that it will be shown inside Home Assistant and
3. leverage an existing arduino library for the BMP180 with ESPHome.
.. note::
@ -39,12 +39,12 @@ before, don't worry, at the end of this guide you can just copy the example sour
- learning the intricacies of C++ classes won't be required.
Before you can create your own custom sensors, let's first take a look at the basics: How sensors (and components)
are structured in the esphomelib ecosystem.
are structured in the ESPHome ecosystem.
In esphomelib, a **sensor** is some hardware device (like a BMP180) that periodically
In ESPHome, a **sensor** is some hardware device (like a BMP180) that periodically
sends out numbers, for example a temperature sensor that periodically publishes its temperature **state**.
Another important abstraction in esphomelib is the concept of a **component**. In esphomelib,
Another important abstraction in ESPHome is the concept of a **component**. In ESPHome,
a **component** is an object with a *lifecycle* managed by the :cpp:class:`Application` class.
What does this mean? Well if you've coded in Arduino before you might know the two special methods
``setup()`` and ``loop()``. ``setup()`` is called one time when the node boots up and ``loop()`` is called
@ -57,9 +57,9 @@ So, let's now take a look at some code: This is an example of a custom component
.. code-block:: cpp
#include "esphomelib.h"
#include "esphome.h"
using namespace esphomelib;
using namespace esphome;
class MyCustomSensor : public Component, public sensor::Sensor {
public:
@ -71,8 +71,8 @@ So, let's now take a look at some code: This is an example of a custom component
}
};
In the first two lines, we're importing esphomelib so you can use the APIs and telling the compiler that
we want to use the esphomelib "namespace" (you don't need to know what this is now, it's basically just
In the first two lines, we're importing ESPHome so you can use the APIs and telling the compiler that
we want to use the esphome "namespace" (you don't need to know what this is now, it's basically just
there to have a clean, well-structured codebase).
Let's now also take a closer look at this line, which you might not be too used to when writing Arduino code:
@ -120,7 +120,7 @@ just :cpp:class:`Component`. Additionally, we now have a new line: the construct
know much about constructors here, so to simplify let's just say this is where we "initialize" the custom sensor.
In this constructor we're telling the compiler that we want :cpp:class:`PollingComponent` to be instantiated with an
*update interval* of 15s, or 15000 milliseconds (esphomelib uses milliseconds internally).
*update interval* of 15s, or 15000 milliseconds (ESPHome uses milliseconds internally).
Let's also now make our sensor actually publish values in the ``update()`` method:
@ -134,7 +134,7 @@ Let's also now make our sensor actually publish values in the ``update()`` metho
};
Every time ``update`` is called we will now **publish** a new value to the frontend.
The rest of esphomelib will then take care of processing this value and ultimately publishing it
The rest of ESPHome will then take care of processing this value and ultimately publishing it
to the outside world (for example using MQTT).
Step 2: Registering the custom sensor
@ -145,11 +145,11 @@ Actually ... it does nothing because it's never included nor instantiated.
First, create a new file called ``my_custom_sensor.h`` in your configuration directory and copy the source code
from above into that file.
Then in the YAML config, *include* that file in the top-level ``esphomeyaml`` section like this:
Then in the YAML config, *include* that file in the top-level ``esphome`` section like this:
.. code-block:: yaml
esphomeyaml:
esphome:
# ... [Other options]
includes:
- my_custom_sensor.h
@ -172,14 +172,14 @@ Next, create a new ``custom`` sensor platform entry like this:
Let's break this down:
- First, we specify a :ref:`lambda <config-lambda>` that will be used to **instantiate** our sensor class. This will
be called on boot to register our sensor in esphomelib.
be called on boot to register our sensor in ESPHome.
- In this lambda, we're first creating a new instance of our custom class (``new MyCustomSensor()``) and then
assigning it to a variable called ``my_sensor``. Note: This uses a feature in the C++ standard, ``auto``, to make our
lives easier. We could also have written ``MyCustomSensor *my_sensor = new MyCustomSensor()``
- Next, as our custom class inherits from Component, we need to **register** it - otherwise esphomelib will not know
- Next, as our custom class inherits from Component, we need to **register** it - otherwise ESPHome will not know
about it and won't call our ``setup()`` and ``update`` methods!
- Finally, we ``return`` the custom sensor - don't worry about the curly braces ``{}``, we'll cover that later.
- After that, we just let *esphomeyaml* know about our newly created sensor too using the ``sensors:`` block. Additionally,
- After that, we just let ESPHome know about our newly created sensor too using the ``sensors:`` block. Additionally,
here we're also assigning the sensor a name.
Now all that's left to do is upload the code and let it run :)
@ -196,7 +196,7 @@ Step 3: BMP180 support
Let's finally make this custom sensor useful by adding the BMP180 aspect into it! Sure, printing ``42`` is a nice number
but it won't help with home automation :D
A great feature of esphomelib is that you don't need to code everything yourself. You can use any existing arduino
A great feature of ESPHome is that you don't need to code everything yourself. You can use any existing arduino
library to do the work for you! Now for this example we'll
use the `Adafruit BMP085 Library <https://platformio.org/lib/show/525/Adafruit%20BMP085%20Library>`__
library to implement support for the BMP085 sensor. But you can find other libraries too on the
@ -207,7 +207,7 @@ in your global ``libraries``:
.. code-block:: yaml
esphomeyaml:
esphome:
includes:
- my_custom_sensor.h
libraries:
@ -217,10 +217,10 @@ Next, include the library at the top of your custom sensor file you created prev
.. code-block:: cpp
#include "esphomelib.h"
#include "esphome.h"
#include "Adafruit_BMP085.h"
using namespace esphomelib;
using namespace esphome;
// ...
@ -255,7 +255,7 @@ we will communicate with the sensor.
In our custom ``setup()`` function we're *initializing* the library (using ``.begin()``) and in
``update()`` we're reading the pressure and publishing it using ``publish_state``.
For esphomeyaml we can use the previous YAML. So now if you upload the firmware, you'll see the sensor
For ESPHome we can use the previous YAML. So now if you upload the firmware, you'll see the sensor
reporting actual pressure values! Hooray 🎉!
Step 4: Additional Overrides
@ -263,10 +263,10 @@ Step 4: Additional Overrides
There's a slight problem with our code: It does print the values fine, **but** if you look in Home Assistant
you'll see a) the value has no **unit** attached to it and b) the value will be rounded to the next integer.
This is because esphomelib doesn't know these infos, it's only passed a floating point value after all.
This is because ESPHome doesn't know these infos, it's only passed a floating point value after all.
We *could* fix that in our custom sensor class (by overriding the ``unit_of_measurement`` and ``accuracy_decimals``
methods), but here we have the full power of esphomeyaml, so let's use that:
methods), but here we have the full power of ESPHome, so let's use that:
.. code-block:: yaml
@ -290,7 +290,7 @@ Bonus: Sensors With Multiple Output Values
The ``Sensor`` class doesn't fit every use-case. Sometimes, (as with the BMP180),
a sensor can expose multiple values (temperature *and* pressure, for example).
Doing so in esphomelib is a bit more difficult. Basically, we will have to change our sensor
Doing so in ESPHome is a bit more difficult. Basically, we will have to change our sensor
model to have a **component** that reads out the values and then multiple **sensors** that represent
the individual sensor measurements.
@ -350,7 +350,7 @@ Our YAML configuration needs an update too:
unit_of_measurement: hPa
accuracy_decimals: 2
In ``lambda`` the return statement has changed: Because we have *two* sensors now we must tell esphomeyaml
In ``lambda`` the return statement has changed: Because we have *two* sensors now we must tell ESPHome
about both of them. We do this by returning them as an array of values in the curly braces.
``sensors:`` has also changed a bit: Now that we have multiple sensors, each of them needs an entry here.

2
components/sensor/dht.rst
View File

@ -15,7 +15,7 @@ The DHT Temperature+Humidity sensor allows you to use your DHT11
`adafruit <https://www.adafruit.com/product/393>`__) and RHT03
(`datasheet <https://cdn.sparkfun.com/datasheets/Sensors/Weather/RHT03.pdf>`__,
`sparkfun <https://cdn.sparkfun.com/datasheets/Sensors/Weather/RHT03.pdf>`__)
sensors with esphomelib.
sensors with ESPHome.
.. figure:: images/dht-full.jpg
:align: center

2
components/sensor/dht12.rst
View File

@ -8,7 +8,7 @@ DHT12 Temperature+Humidity Sensor
The ``dht12`` Temperature+Humidity sensor allows you to use your DHT12
(`datasheet <http://www.robototehnika.ru/file/DHT12.pdf>`__,
`electrodragon`_) i2c-based sensor with esphomelib. This sensor is also called AM2320 by some sellers.
`electrodragon`_) i2c-based sensor with ESPHome. This sensor is also called AM2320 by some sellers.
.. figure:: images/dht12-full.jpg
:align: center

2
components/sensor/duty_cycle.rst
View File

@ -2,7 +2,7 @@ Duty Cycle Sensor
=================
.. seo::
:description: Instructions for setting up duty cycle sensors in esphomelib
:description: Instructions for setting up duty cycle sensors in ESPHome
:image: percent.png
The duty cycle sensor allows you to measure for what percentage of time a signal

2
components/sensor/esp32_hall.rst
View File

@ -42,7 +42,7 @@ Configuration variables:
Therefore the values could very well be off by orders of magnitude. Besides, this sensor should
only be used to detect sudden high changes in the magnetic field.
If you have a real magnetic field calibration setup and want to contribute your values to esphomelib,
If you have a real magnetic field calibration setup and want to contribute your values to ESPHome,
please feel free to do so 😺.
See Also

2
components/sensor/hdc1080.rst
View File

@ -9,7 +9,7 @@ HDC1080 Temperature+Humidity Sensor
The HDC1080 Temperature+Humidity sensor allows you to use your HDC1080
(`datasheet <http://www.ti.com/lit/ds/symlink/hdc1080.pdf>`__,
`adafruit <https://www.adafruit.com/product/2635>`__) sensors with
esphomelib. The :ref:`I²C Bus <i2c>` is
ESPHome. The :ref:`I²C Bus <i2c>` is
required to be set up in your configuration for this sensor to work.
.. figure:: images/hdc1080-full.jpg

4
components/sensor/hlw8012.rst
View File

@ -8,13 +8,13 @@ HLW8012 Power Sensor
The ``hlw8012`` sensor platform allows you to use your HLW8012 voltage/current and power sensors
(`datasheet <https://github.com/xoseperez/hlw8012/blob/master/docs/HLW8012.pdf>`__) sensors with
esphomelib. This sensor is commonly found in Sonoff POWs.
ESPHome. This sensor is commonly found in Sonoff POWs.
This sensor has two data outputs which both encode values using the frequency of a modulated signal: CF and CF1.
CF's frequency is proportional to the (active) power measured and CF1 is proportional to the current/voltage. Using
the SEL pin, one can choose between which mode to use.
esphomelib will continuously cycle the state of the SEL pin to measure current *and* voltage, though both cannot
ESPHome will continuously cycle the state of the SEL pin to measure current *and* voltage, though both cannot
be measured at the same exact points in time.
.. code-block:: yaml

2
components/sensor/hmc5883l.rst
View File

@ -9,7 +9,7 @@ HMC5883L Magnetometer
The ``hmc5883l`` allows you to use your HMC5883L triple-axis magnetometers
(`datasheet <https://cdn-shop.adafruit.com/datasheets/HMC5883L_3-Axis_Digital_Compass_IC.pdf>`__,
`Adafruit`_) with
esphomelib. The :ref:`I²C Bus <i2c>` is
ESPHome. The :ref:`I²C Bus <i2c>` is
required to be set up in your configuration for this sensor to work.
.. _Adafruit: https://www.adafruit.com/product/1746

2
components/sensor/homeassistant.rst
View File

@ -2,7 +2,7 @@ Homeassistant Sensor
====================
.. seo::
:description: Instructions for setting up homeassistant sensors with esphomelib that import states from your homeassistant instance.
:description: Instructions for setting up homeassistant sensors with ESPHome that import states from your homeassistant instance.
:image: home-assistant.png
The ``homeassistant`` sensor platform allows you to create a sensors that import

2
components/sensor/htu21d.rst
View File

@ -9,7 +9,7 @@ HTU21D Temperature+Humidity Sensor
The HTU21D Temperature+Humidity sensor allows you to use your HTU21D
(`datasheet <https://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Data+Sheet%7FHPC199_6%7FA6%7Fpdf%7FEnglish%7FENG_DS_HPC199_6_A6.pdf%7FCAT-HSC0004>`__,
`adafruit <https://www.adafruit.com/product/1899>`__) sensors with
esphomelib. The :ref:`I²C Bus <i2c>` is
ESPHome. The :ref:`I²C Bus <i2c>` is
required to be set up in your configuration for this sensor to work.
.. figure:: images/htu21d-full.jpg

4
components/sensor/hx711.rst
View File

@ -2,13 +2,13 @@ HX711 Load Cell Amplifier
=========================
.. seo::
:description: Instructions for setting up HX711 load cell amplifiers with esphomelib
:description: Instructions for setting up HX711 load cell amplifiers with ESPHome
:image: hx711.png
:keywords: HX711
The ``hx711`` sensor platform allows you to use your HX711
load cell amplifier
(`datasheet <https://www.mouser.com/ds/2/813/hx711_english-1022875.pdf>`__, `Sparkfun`_) with esphomelib
(`datasheet <https://www.mouser.com/ds/2/813/hx711_english-1022875.pdf>`__, `Sparkfun`_) with ESPHome
.. figure:: images/hx711-full.jpg
:align: center

6
components/sensor/ina219.rst
View File

@ -9,7 +9,7 @@ INA219 DC Current Sensor
The ``ina219`` sensor platform allows you to use your INA219 High Side DC Current Sensor
(`datasheet <https://cdn-learn.adafruit.com/downloads/pdf/adafruit-ina219-current-sensor-breakout.pdf>`__,
`Adafruit`_) sensors with
esphomelib. The :ref:`I²C Bus <i2c>` is
ESPHome. The :ref:`I²C Bus <i2c>` is
required to be set up in your configuration for this sensor to work.
@ -50,9 +50,9 @@ Configuration variables:
- **address** (*Optional*, int): Manually specify the i^2c address of the sensor. Defaults to ``0x40``.
- **shunt_resistance** (*Optional*, float): The value of the shunt resistor on the board for current calculation.
Defaults to ``0.1 ohm``.
- **max_voltage** (*Optional*, float): The maximum bus voltage you are expecting. esphomelib will use this to
- **max_voltage** (*Optional*, float): The maximum bus voltage you are expecting. ESPHome will use this to
configure the sensor optimally. Defaults to ``32V`` (the max).
- **max_current** (*Optional*, float): The maximum current you are expecting. esphomelib will use this to
- **max_current** (*Optional*, float): The maximum current you are expecting. ESPHome will use this to
configure the sensor optimally. Defaults to ``3.2A``.
- **current** (*Optional*): Use the current value of the sensor in amperes. All options from
:ref:`Sensor <config-sensor>` and :ref:`MQTT Component <config-mqtt-component>`.

2
components/sensor/ina3221.rst
View File

@ -9,7 +9,7 @@ INA3221 3-Channel DC Current Sensor
The ``ina3221`` sensor platform allows you to use your INA3221 3-Channel DC Current Sensor
(`datasheet <http://www.ti.com/lit/ds/symlink/ina3221.pdf>`__,
`switchdoc`_) sensors with
esphomelib. The :ref:`I²C Bus <i2c>` is
ESPHome. The :ref:`I²C Bus <i2c>` is
required to be set up in your configuration for this sensor to work.

16
components/sensor/index.rst
View File

@ -2,10 +2,10 @@ Sensor Component
================
.. seo::
:description: Instructions for setting up sensor components in esphomelib.
:description: Instructions for setting up sensor components in ESPHome.
:image: folder-open.png
esphomelib has support for many different sensors. Each of them is a
ESPHome has support for many different sensors. Each of them is a
platform of the ``sensor`` domain and each sensor has several base
configuration options.
@ -14,7 +14,7 @@ configuration options.
Base Sensor Configuration
-------------------------
All sensors in esphomeyaml/esphomelib have a name and some other
All sensors in ESPHome have a name and some other
optional configuration options. By default, the sensor platform will
chose appropriate values for all of these by default, but you can always
override them if you want to.
@ -81,13 +81,9 @@ Automations:
Sensor Filters
--------------
esphomeyaml/esphomelib allow you to do some basic pre-processing of
ESPHome allows you to do some basic pre-processing of
sensor values before they’re sent to Home Assistant. This is for example
useful if you want to apply some average over the last few values to
relief Home Assistant’s state machine and keep the history graphs in the
front-end a bit more clean. More sophisticated filters should be done
with Home Assistant's `filter
sensor <https://www.home-assistant.io/components/sensor.filter/>`__.
useful if you want to apply some average over the last few values.
.. code-block:: yaml
@ -178,7 +174,7 @@ Example: Converting Celsius to Fahrenheit
While I personally don’t like the Fahrenheit temperature scale, I do
understand that having temperature values appear in the fahrenheit unit
is quite useful to some users. esphomelib uses the celsius temperature
is quite useful to some users. ESPHome uses the celsius temperature
unit internally, and I’m not planning on making converting between the
two simple (😉), but you can use this filter to convert celsius values to
fahrenheit.

2
components/sensor/max31855.rst
View File

@ -6,7 +6,7 @@ MAX31855 K-Type Thermocouple Temperature Sensor
:image: max31855.jpg
The ``max31855`` temperature sensor allows you to use your max31855 thermocouple
temperature sensor (`datasheet <https://datasheets.maximintegrated.com/en/ds/MAX31855.pdf>`__) with esphomelib
temperature sensor (`datasheet <https://datasheets.maximintegrated.com/en/ds/MAX31855.pdf>`__) with ESPHome
As the communication with the MAX66775 is done using SPI, you need
to have an :ref:`spi bus <spi>` in your configuration with the **miso_pin** set (mosi is not required).

2
components/sensor/max6675.rst
View File

@ -6,7 +6,7 @@ MAX6675 K-Type Thermocouple Temperature Sensor
:image: max6675.jpg
The ``max6675`` temperature sensor allows you to use your max6675 thermocouple
temperature sensor (`datasheet <https://datasheets.maximintegrated.com/en/ds/MAX6675.pdf>`__, `sainsmart`_) with esphomelib
temperature sensor (`datasheet <https://datasheets.maximintegrated.com/en/ds/MAX6675.pdf>`__, `sainsmart`_) with ESPHome
.. figure:: images/max6675-full.jpg
:align: center

2
components/sensor/mhz19.rst
View File

@ -7,7 +7,7 @@ MH-Z19 CO_2 and Temperature Sensor
:keywords: mh-z19
The ``mhz19`` sensor platform allows you to use MH-Z19 CO_2 and temperature sensors
(`refspace`_) with esphomelib.
(`refspace`_) with ESPHome.
.. figure:: images/mhz19-full.jpg
:align: center

4
components/sensor/misc/custom-empty.h
View File

@ -1,6 +1,6 @@
#include "esphomelib.h"
#include "esphome.h"
using namespace esphomelib;
using namespace esphome;
class MyCustomSensor : public PollingComponent, public sensor::Sensor {
public:

2
components/sensor/mpu6050.rst
View File

@ -8,7 +8,7 @@ MPU6050 Accelerometer/Gyroscope Sensor
The ``mpu6050`` sensor platform allows you to use your MPU6050 Accelerometer/Gyroscope
(`datasheet <https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-Datasheet1.pdf>`__,
`Sparkfun`_) sensors with
esphomelib. The :ref:`I²C Bus <i2c>` is
ESPHome. The :ref:`I²C Bus <i2c>` is
required to be set up in your configuration for this sensor to work.
This component only does some basic filtering and no calibration. Due to the complexity of

4
components/sensor/mqtt_subscribe.rst
View File

@ -6,13 +6,13 @@ MQTT Subscribe Sensor
:image: mqtt.png
:keywords: MQTT
The ``mqtt_subscribe`` sensor platform allows you to get external data into esphomelib.
The ``mqtt_subscribe`` sensor platform allows you to get external data into ESPHome.
The sensor will subscribe to messages on the given MQTT topic and parse each message into
a floating point number.
Please note this integration only works with MQTT topics that have numeric data! Each time
a message that is not a number is published a warning will be shown. Please use the MQTT subscribe
text sensor for importing arbitrary text into the esphomelib ecosystem.
text sensor for importing arbitrary text into the ESPHome ecosystem.
.. code-block:: yaml

2
components/sensor/ms5611.rst
View File

@ -8,7 +8,7 @@ MS5611 Atmospheric Pressure Sensor
The ``ms5611`` sensor platform allows you to use your MS5611 atmospheric pressure sensors
(`datasheet <https://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Data+Sheet%7FMS5611-01BA03%7FB3%7Fpdf%7FEnglish%7FENG_DS_MS5611-01BA03_B3.pdf%7FCAT-BLPS0036>`__,
`hobbytronics`_) temperature and pressure sensors with esphomelib. The :ref:`I²C <i2c>` is
`hobbytronics`_) temperature and pressure sensors with ESPHome. The :ref:`I²C <i2c>` is
required to be set up in your configuration for this sensor to work.
.. figure:: images/ms5611-full.jpg

2
components/sensor/pmsx003.rst
View File

@ -12,7 +12,7 @@ PMSX003 Particulate Matter Sensor
The ``pmsx003`` sensor platform allows you to use your PMS5003, PMS7003, ... particulate matter
(`datasheet <http://www.aqmd.gov/docs/default-source/aq-spec/resources-page/plantower-pms5003-manual_v2-3.pdf>`__)
sensors with esphomelib.
sensors with ESPHome.
As the communication with the PMSX003 is done using UART, you need
to have an :ref:`UART bus <uart>` in your configuration with the ``rx_pin`` connected to the SEND/TX pin

6
components/sensor/rotary_encoder.rst
View File

@ -6,7 +6,7 @@ Rotary Encoder Sensor
:image: rotary_encoder.jpg
The ``rotary_encoder`` sensor platform allows you to use any continuous-rotation
rotary encoders with esphomeyaml. These devices usually have two pins with which
rotary encoders with ESPHome. These devices usually have two pins with which
they encode the rotation. Every time the knob of the rotary encoder is turned, the
signals of the two pins go HIGH and LOW in turn. See
`this Arduino article <https://playground.arduino.cc/Main/RotaryEncoders>`__ to gain
@ -23,7 +23,7 @@ a better understanding of these sensors.
:align: center
:width: 75.0%
To use rotary encoders in esphomeyaml, first identify the two pins encoding th step value.
To use rotary encoders in ESPHome, first identify the two pins encoding th step value.
These are often called ``CLK`` and ``DT`` as in above image. Note if the values this sensor
outputs go in the wrong direction, you can just swap these two pins.
@ -54,7 +54,7 @@ Debouncing Output
-----------------
This sensor can output a lot of values in a short period of time when turning the knob.
In order to not put too much stress on your network connection, you can leverage esphomelib's
In order to not put too much stress on your network connection, you can leverage ESPHome's
sensor filters. The following will only send out values if the last input value is at least
0.1s seconds old *or* if the new rotary encoder value has changed by 10 from the previous value.

2
components/sensor/sht3xd.rst
View File

@ -8,7 +8,7 @@ SHT3X-D Temperature+Humidity Sensor
The ``sht3xd`` sensor platform Temperature+Humidity sensor allows you to use your Sensiron SHT31-D
(`datasheet <https://cdn-shop.adafruit.com/product-files/2857/Sensirion_Humidity_SHT3x_Datasheet_digital-767294.pdf>`__,
`Adafruit`_ ) sensors with
esphomelib. The :ref:`I²C Bus <i2c>` is
ESPHome. The :ref:`I²C Bus <i2c>` is
required to be set up in your configuration for this sensor to work.
.. _Adafruit: https://www.adafruit.com/product/2857

2
components/sensor/tcs34725.rst
View File

@ -8,7 +8,7 @@ TCS34725 RGB Color Sensor
The ``tcs34725`` sensor platform allows you to use your TCS34725 RGB color sensors
(`datasheet <https://cdn-shop.adafruit.com/datasheets/TCS34725.pdf>`__,
`Adafruit`_) temperature and pressure sensors with esphomelib. The :ref:`I²C <i2c>` is
`Adafruit`_) temperature and pressure sensors with ESPHome. The :ref:`I²C <i2c>` is
required to be set up in your configuration for this sensor to work.
.. figure:: images/tcs34725-full.jpg

40
components/sensor/template.rst
View File

@ -2,7 +2,7 @@ Template Sensor
===============
.. seo::
:description: Instructions for setting up template sensors with esphomelib.
:description: Instructions for setting up template sensors with ESPHome.
:image: description.png
The ``template`` sensor platform allows you to create a sensor with templated values
@ -40,14 +40,46 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- All other options from :ref:`Sensor <config-sensor>` and :ref:`MQTT Component <config-mqtt-component>`.
.. _sensor-template-publish_action:
``sensor.template.publish`` Action
----------------------------------
You can also publish a state to a template sensor from elsewhere in your YAML file
with the ``sensor.template.publish`` action.
.. code-block:: yaml
# Example configuration entry
sensor:
- platform: template
name: "Template Sensor"
id: template_sens
# in some trigger
on_...:
- sensor.template.publish:
id: template_sens
state: 42.0
# Templated
- sensor.template.publish:
id: template_sens
state: !lambda 'return 42.0;'
Configuration options:
- **id** (**Required**, :ref:`config-id`): The ID of the template sensor.
- **state** (**Required**, float, :ref:`templatable <config-templatable>`):
The state to publish.
.. note::
You can use the ``publish_state()`` method to set the value of a template
sensor from other automations:
This action can also be written in lambdas:
.. code-block:: cpp
id(my_sensor).publish_state(42.0);
id(template_sens).publish_state(42.0);
See Also
--------

4
components/sensor/tsl2561.rst
View File

@ -2,14 +2,14 @@ TSL2561 Ambient Light Sensor
============================
.. seo::
:description: Instructions for setting up TSL2561 ambient light sensors in esphomelib.
:description: Instructions for setting up TSL2561 ambient light sensors in ESPHome.
:image: tsl2561.jpg
:keywords: TSL2561
The ``tsl2561`` sensor platform allows you to use your TSL2561
(`datasheet <https://cdn-shop.adafruit.com/datasheets/TSL2561.pdf>`__,
`Adafruit`_)
ambient light sensor with esphomelib. The :ref:`I²C <i2c>` is required to be set up in
ambient light sensor with ESPHome. The :ref:`I²C <i2c>` is required to be set up in
your configuration for this sensor to work.
.. figure:: images/tsl2561-full.jpg

4
components/sensor/ultrasonic.rst
View File

@ -2,14 +2,14 @@ Ultrasonic Distance Sensor
==========================
.. seo::
:description: Instructions for setting up ultrasonic distance measurement sensors in esphomelib.
:description: Instructions for setting up ultrasonic distance measurement sensors in ESPHome.
:image: ultrasonic.jpg
:keywords: ultrasonic, hc-sr04
The ultrasonic distance sensor allows you to use simple ultrasonic
sensors like the HC-SR04
(`datasheet <https://www.electroschematics.com/wp-content/uploads/2013/07/HC-SR04-datasheet-version-2.pdf>`__,
`sparkfun <https://www.sparkfun.com/products/13959>`__) with esphomelib
`sparkfun <https://www.sparkfun.com/products/13959>`__) with ESPHome
to measure distances. These sensors usually can’t measure anything more
than about two meters and may sometimes make some annoying clicking
sounds.

6
components/sensor/xiaomi_miflora.rst
View File

@ -2,14 +2,14 @@ Xiaomi MiFlora BLE Sensor
=========================
.. seo::
:description: Instructions for setting up Xiaomi Mi Flora bluetooth-based plant monitors in esphomelib.
:description: Instructions for setting up Xiaomi Mi Flora bluetooth-based plant monitors in ESPHome.
:image: xiaomi_miflora.jpg
:keywords: Xiaomi, Mi Flora, BLE, Bluetooth
The ``xiaomi_miflora`` sensor platform lets you track the output of Xiaomi MiFlora Bluetooth Low Energy
devices using the :doc:`/components/esp32_ble_tracker`. This component will track the
temperature, humidity and optionally the battery level of the MiFlora device every time the sensor
sends out a BLE broadcast. Note that contrary to other implementations, esphomelib can track as many
sends out a BLE broadcast. Note that contrary to other implementations, ESPHome can track as many
MiFlora devices at once as you want.
.. code-block:: yaml
@ -71,7 +71,7 @@ Setting Up Devices
Before you can even scan for the MiFlora sensor, you need to activate it using the Flower Care app. Set it up there and you'll be able to discover it.
To set up Xiaomi MiFlora devices you first need to find their MAC Address so that esphomelib can
To set up Xiaomi MiFlora devices you first need to find their MAC Address so that ESPHome can
identify them. So first, create a simple configuration without any ``xiaomi_miflora`` entries like so:
.. code-block:: yaml

6
components/sensor/xiaomi_mijia.rst
View File

@ -2,14 +2,14 @@ Xiaomi MiJia BLE Sensor
=======================
.. seo::
:description: Instructions for setting up Xiaomi Mi Jia bluetooth-based temperature and humidity sensors in esphomelib.
:description: Instructions for setting up Xiaomi Mi Jia bluetooth-based temperature and humidity sensors in ESPHome.
:image: xiaomi_miflora.jpg
:keywords: Xiaomi, Mi Jia, BLE, Bluetooth
The ``xiaomi_mijia`` sensor platform lets you track the output of Xiaomi MiJia Bluetooth Low Energy
devices using the :doc:`/components/esp32_ble_tracker`. This component will track the
temperature, humidity and optionally the battery level of the MiJia device every time the sensor
sends out a BLE broadcast. Note that contrary to other implementations, esphomelib can track as many
sends out a BLE broadcast. Note that contrary to other implementations, ESPHome can track as many
MiJia devices at once as you want.
.. figure:: images/xiaomi_mijia-full.jpg
@ -63,7 +63,7 @@ Configuration variables:
Setting Up Devices
------------------
To set up Xiaomi MiJia devices you first need to find their MAC Address so that esphomelib can
To set up Xiaomi MiJia devices you first need to find their MAC Address so that ESPHome can
identify them. So first, create a simple configuration without any ``xiaomi_mijia`` entries like so:
.. code-block:: yaml

4
components/spi.rst
View File

@ -4,7 +4,7 @@ SPI Bus
=======
.. seo::
:description: Instructions for setting up an SPI bus in esphomelib
:description: Instructions for setting up an SPI bus in ESPHome
:image: spi.png
:keywords: SPI
@ -21,7 +21,7 @@ SPI is a very common high-speed protocol for a lot of devices. The SPI bus usual
In some cases one of **MOSI** or **MISO** do not exist as the receiving device only accepts data or sends data.
To set up SPI devices in esphomelib, you first need to place a top-level SPI hub like below which defines what pins to
To set up SPI devices in ESPHome, you first need to place a top-level SPI hub like below which defines what pins to
use for the functions described above. The **CS** pins are then individually managed by the components. The ``spi:``
component also accepts a list of buses if you want to have multiple SPI buses with your ESP (though this should
rarely be necessary, as the SPI bus can be shared by the devices).

6
components/status_led.rst
View File

@ -2,16 +2,16 @@ Status LED
==========
.. seo::
:description: Instructions for setting up status LEDs in esphomelib to monitor the status of an ESP.
:description: Instructions for setting up status LEDs in ESPHome to monitor the status of an ESP.
:image: led-on.png
The ``status_led`` hooks into all esphomelib components and can indicate the status of
The ``status_led`` hooks into all ESPHome components and can indicate the status of
the device. Specifically, it will:
- Blink slowly (about every second) when a **warning** is active. Warnings are active when for
example reading a sensor value fails temporarily or the WiFi/MQTT connections are disrupted.
- Blink quickly (multiple times per second) when an **error** is active. Errors indicate that
esphomelib has found an error while setting up. In most cases, esphomelib will still try to
ESPHome has found an error while setting up. In most cases, ESPHome will still try to
recover from the error and continue with all other operations.
- Stay off otherwise.

4
components/stepper/index.rst
View File

@ -2,11 +2,11 @@ Stepper Component
=================
.. seo::
:description: Instructions for setting up stepper motor drivers in esphomelib
:description: Instructions for setting up stepper motor drivers in ESPHome
:image: folder-open.png
:keywords: stepper motor, stepper driver, a4988
The ``stepper`` component allows you to use stepper motors with esphomelib.
The ``stepper`` component allows you to use stepper motors with ESPHome.
Currently only the A4988 stepper driver
(`datasheet <https://www.pololu.com/file/0J450/a4988_DMOS_microstepping_driver_with_translator.pdf>`__)
and ULN2003 (`datasheet <http://www.ti.com/lit/ds/symlink/uln2003a.pdf>`__) are supported.

8
components/switch/custom.rst
View File

@ -1,7 +1,7 @@
Custom Switch
=============
This integration can be used to create custom switches in esphomelib
This integration can be used to create custom switches in ESPHome
using the C++ (Arduino) API.
Please first read :doc:`/components/sensor/custom` guide,
@ -12,8 +12,8 @@ same as the gpio switch implementation.
.. code-block:: cpp
#include "esphomelib.h"
using namespace esphomelib;
#include "esphome.h"
using namespace esphome;
// namespace is called 'switch_' because 'switch' is a reserved keyword
class MyCustomSwitch : public Component, public switch_::Switch {
@ -39,7 +39,7 @@ And in YAML:
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
includes:
- my_switch.h

71
components/switch/gpio.rst
View File

@ -2,7 +2,7 @@ GPIO Switch
===========
.. seo::
:description: Instructions for setting up GPIO pin switches in esphomelib that control GPIO outputs.
:description: Instructions for setting up GPIO pin switches in ESPHome that control GPIO outputs.
:image: pin.png
The ``gpio`` switch platform allows you to use any pin on your node as a
@ -35,8 +35,14 @@ Configuration variables:
- ``ALWAYS_OFF`` - Always initialize the pin as OFF on bootup.
- ``ALWAYS_ON`` - Always initialize the pin as ON on bootup.
- **interlock** (*Optional*, list): A list of other GPIO switches in an interlock group. See
:ref:`switch-gpio-interlocking`.
- All other options from :ref:`Switch <config-switch>` and :ref:`MQTT Component <config-mqtt-component>`.
Active Low Switch
-----------------
To create an active-low switch (one that is turned off by default), use the :ref:`Pin Schema <config-pin_schema>`:
.. code-block:: yaml
@ -48,9 +54,15 @@ To create an active-low switch (one that is turned off by default), use the :ref
number: 25
inverted: yes
To create momentary switches, for example switches that toggle a pin for a moment, you can use :doc:`template switches <template>`.
Momentary Switch
----------------
An example that uses a single relay to activate a remote control button. The button can only start or stop the motor of the gate. In itself, the button or remote can not know if it opens or closes the gate. The relay simulates the button press for 500ms.
To create momentary switches, for example switches that toggle a pin for a moment, you can use
:doc:`template switches <template>`.
An example that uses a single relay to activate a remote control button. The button can only
start or stop the motor of the gate. In itself, the button or remote can not know if it opens
or closes the gate. The relay simulates the button press for 500ms.
.. code-block:: yaml
@ -62,7 +74,6 @@ An example that uses a single relay to activate a remote control button. The but
- platform: template
name: "Gate Remote"
icon: "mdi:gate"
optimistic: no
turn_on_action:
- switch.turn_on: relay
- delay: 500ms
@ -71,6 +82,58 @@ An example that uses a single relay to activate a remote control button. The but
.. figure:: images/gate-remote-ui.png
:align: center
.. _switch-gpio-interlocking:
Interlocking
------------
In some cases it is necessary to ensure that two outputs are never active at the same time.
ESPHome has a feature to prevent two GPIO Switches from being active at the same time called
interlocking. Just give *each switch* in the "interlocking group" an ``interlock`` option
with a list of all the switches in the group.
.. code-block:: yaml
# Example configuration entry
# Prevent relay #1 and relay #2 from being activated at the same time.
switch:
- platform: gpio
pin: GPIO25
name: "Relay #1"
id: relay1
interlock: [relay2]
- platform: gpio
pin: GPIO26
name: "Relay #2"
id: relay2
interlock: [relay1]
Or with some YAML anchors you can further simplify the config:
.. code-block:: yaml
# Example configuration entry
switch:
- platform: gpio
# etc
id: relay1
interlock: &interlock_group [relay1, relay2]
- platform: gpio
# etc
id: relay2
interlock: *interlock_group
.. warning::
These are software interlocks. As such, a software bug (which can *always* happen) can still
activate both switches at the same time. Similarly, at reset time (before any of ESPHome's code runs)
the relay GPIO pins may have pull-ups active, so the relay may be active before ESPHome can manually
deactivate them.
So it is **highly** recommended to use hardware interlocks (like SPDT-type relays) that ensure
that two GPIOs are never active at the same time.
See Also
--------

2
components/switch/index.rst
View File

@ -2,7 +2,7 @@ Switch Component
================
.. seo::
:description: Instructions for setting up generic switches in esphomelib.
:description: Instructions for setting up generic switches in ESPHome.
:image: folder-open.png
The ``switch`` domain includes all platforms that should show up like a

2
components/switch/output.rst
View File

@ -2,7 +2,7 @@ Generic Output Switch
=====================
.. seo::
:description: Instructions for setting up generic output switches in esphomelib that control an output component.
:description: Instructions for setting up generic output switches in ESPHome that control an output component.
:image: upload.png
The ``output`` switch platform allows you to use any output component as a switch.

21
components/switch/remote_transmitter.rst
View File

@ -63,7 +63,7 @@ Configuration variables:
pin: 5
carrier_duty_percent: 100%
Supporting the RF Bridge chip directly is currently only a long-term goal for esphomelib.
Supporting the RF Bridge chip directly is currently only a long-term goal for ESPHome.
.. _remote_transmitter-codes:
@ -111,6 +111,9 @@ Supported remote codes:
group: 'a'
device: 2
state: True
rc5:
address: 0x00
command: 0x0B
raw:
carrier_frequency: 35kHz
data:
@ -180,6 +183,11 @@ Configuration variables:
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch is triggered. See :ref:`remote_transmitter-on_off_template`.
- **protocol** (*Optional*, :ref:`RCSwitch protocol <rc_switch-protocol>`): The RCSwitch protocol to use. Defaults to ``1``.
- **rc5**: Send a RC5 IR code.
- **address**: The address of the device.
- **command**: The command to send.
- **raw**: Send an arbitrary signal.
- **carrier_frequency**: The frequency to use for the carrier. A lot
@ -205,7 +213,7 @@ using the :doc:`remote receiver component </components/remote_receiver>` like th
# dump all signals we find
dump: all
And then activate the remote control you want to have in esphomelib. you will see a log output like this:
And then activate the remote control you want to have in ESPHome. you will see a log output like this:
.. figure:: images/rf_receiver-log_raw.png
:align: center
@ -215,7 +223,7 @@ And then activate the remote control you want to have in esphomelib. you will se
Raw Remote Codes
****************
If esphomelib has a decoder set up for the code, it will spit out the decoded code in the logs. In this case,
If ESPHome has a decoder set up for the code, it will spit out the decoded code in the logs. In this case,
it's a proprietary protocol which would be difficult to reverse engineer. Fortunately, we can just
do a "replay attack" by repeating the signal we just saw for our own purposes. The output you see in above image
is encoded in microseconds: A negative value represents the output being LOW for x microseconds and a positive
@ -251,7 +259,7 @@ a transmission.
RCSwitch Remote Codes
*********************
Starting with version 1.8.0 esphomelib can also recognize a bunch of 433MHz RF codes directly using `RCSwitch's <https://github.com/sui77/rc-switch>`__
Starting with version 1.8.0 ESPHome can also recognize a bunch of 433MHz RF codes directly using `RCSwitch's <https://github.com/sui77/rc-switch>`__
remote protocol. If you have RF code dumping enabled for the receiver, you will then see log outputs like this one:
.. code::
@ -271,7 +279,7 @@ Like before with raw codes, you can then use this code to create switches:
Alternatively, you can use the information on `this page <https://github.com/sui77/rc-switch/wiki/HowTo_OperateLowCostOutlets>`__
to manually find the RCSwitch codes without having to first find them using the remote receiver. For example, this would
be the esphomelib equivalent of the first Type-A switch on that site:
be the ESPHome equivalent of the first Type-A switch on that site:
.. code-block:: yaml
@ -311,6 +319,7 @@ when switched off. To do this, use the :doc:`/components/switch/template` like t
- platform: template
name: Living Room Lights
optimistic: True
assumed_state: True
turn_on_action:
- switch.turn_on: living_room_lights_on
turn_off_action:
@ -322,7 +331,7 @@ when switched off. To do this, use the :doc:`/components/switch/template` like t
RCSwitch Protocol
-----------------
RCSwitch transmitters/receivers all have a ``protocol:`` option that can be used to tell esphomelib what timings to use
RCSwitch transmitters/receivers all have a ``protocol:`` option that can be used to tell ESPHome what timings to use
for the transmission. This is necessary as many remotes use different timings to encode a logic zero or one.
RCSwitch has 7 built-in protocols that cover most use cases. You can however also choose to use custom parameters

2
components/switch/restart.rst
View File

@ -2,7 +2,7 @@ Restart Switch
==============
.. seo::
:description: Instructions for setting up switches that can remotely reboot the ESP in esphomelib.
:description: Instructions for setting up switches that can remotely reboot the ESP in ESPHome.
:image: restart.png
The ``restart`` switch platform allows you to restart your node remotely

56
components/switch/template.rst
View File

@ -25,7 +25,6 @@ as a switch and can be controlled through the frontend.
- switch.turn_on: switch2
turn_off_action:
- switch.turn_on: switch1
optimistic: true
Possible return values for the optional lambda:
@ -40,19 +39,62 @@ Configuration variables:
- **name** (**Required**, string): The name of the switch.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda to be evaluated repeatedly to get the current state of the switch.
Only state *changes* will be published to MQTT.
- **optimistic** (*Optional*, boolean): Whether to operate in optimistic mode - when in this mode,
any command sent to the template cover will immediately update the reported state and no lambda
needs to be used. Defaults to ``false``.
- **turn_on_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote (like Home Assistant's frontend) requests the switch to be turned on.
- **turn_off_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote (like Home Assistant's frontend) requests the switch to be turned off.
- **restore_state** (*Optional*, boolean): Sets whether esphomelib should attempt to restore the
state on boot-up and call the turn on/off actions with the recovered values. Defaults to ``yes``.
- **restore_state** (*Optional*, boolean): Sets whether ESPHome should attempt to restore the
state on boot-up and call the turn on/off actions with the recovered values. Defaults to ``no``.
- **optimistic** (*Optional*, boolean): Whether to operate in optimistic mode - when in this mode,
any command sent to the template cover will immediately update the reported state.
Defaults to ``false``.
- **assumed_state** (*Optional*, boolean): Whether the true state of the switch is not known.
This will make the Home Assistant frontend show buttons for both ON and OFF actions, instead
of hiding one of them when the switch is ON/OFF. Defaults to ``false``.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- All other options from :ref:`Switch <config-switch>` and :ref:`MQTT Component <config-mqtt-component>`.
.. _switch-template-publish_action:
``switch.template.publish`` Action
----------------------------------
You can also publish a state to a template switch from elsewhere in your YAML file
with the ``switch.template.publish`` action.
.. code-block:: yaml
# Example configuration entry
switch:
- platform: template
name: "Template Switch"
id: template_swi
# in some trigger
on_...:
- switch.template.publish:
id: template_swi
state: ON
# Templated
- switch.template.publish:
id: template_swi
state: !lambda 'return true;'
Configuration options:
- **id** (**Required**, :ref:`config-id`): The ID of the template switch.
- **state** (**Required**, boolean, :ref:`templatable <config-templatable>`):
The state to publish.
.. note::
This action can also be written in lambdas:
.. code-block:: cpp
id(template_swi).publish_state(42.0);
See Also
--------

2
components/switch/uart.rst
View File

@ -2,7 +2,7 @@ UART Switch
===========
.. seo::
:description: Instructions for setting up UART switches in esphomelib that can output arbitrary UART sequences when activated.
:description: Instructions for setting up UART switches in ESPHome that can output arbitrary UART sequences when activated.
:image: uart.png
The ``uart`` switch platform allows you to send a pre-defined sequence of bytes on a

8
components/text_sensor/custom.rst
View File

@ -1,7 +1,7 @@
Custom Text Sensor
==================
This integration can be used to create custom text sensors in esphomelib
This integration can be used to create custom text sensors in ESPHome
using the C++ (Arduino) API.
Please first read :doc:`/components/sensor/custom` guide,
@ -13,8 +13,8 @@ the message "Hello World!".
.. code-block:: cpp
#include "esphomelib.h"
using namespace esphomelib;
#include "esphome.h"
using namespace esphome;
class MyCustomTextSensor : public PollingComponent, public text_sensor::TextSensor {
public:
@ -38,7 +38,7 @@ And in YAML:
.. code-block:: yaml
# Example configuration entry
esphomeyaml:
esphome:
includes:
- my_text_sensor.h

2
components/text_sensor/homeassistant.rst
View File

@ -2,7 +2,7 @@ Homeassistant Text Sensor
=========================
.. seo::
:description: Instructions for setting up homeassistant text sensors with esphomelib that import states from your homeassistant instance.
:description: Instructions for setting up homeassistant text sensors with ESPHome that import states from your homeassistant instance.
:image: home-assistant.png
The ``homeassistant`` text sensor platform allows you to create a sensors that import

Some files were not shown because too many files have changed in this diff Show More