Merge branch 'updates' into next
# Conflicts: # components/binary_sensor/homeassistant.rst # components/sensor/dht.rst # components/uart.rst # cookbook/h801.rst
8
.github/PULL_REQUEST_TEMPLATE.md
vendored
@ -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`.
|
||||
|
@ -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
|
@ -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`_
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
----------------
|
||||
|
@ -2,7 +2,7 @@ Homeassistant Binary Sensor
|
||||
===========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up homeassistant binary sensors with esphomelib that import states from your homeassistant instance.
|
||||
:description: Instructions for setting up homeassistant binary sensors with ESPHome that import states from your homeassistant instance.
|
||||
:image: home-assistant.png
|
||||
|
||||
The ``homeassistant`` binary sensor platform allows you to create binary sensors that **import**
|
||||
|
@ -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``.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
--------
|
||||
|
||||
|
@ -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*.
|
||||
|
||||
|
@ -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
|
||||
--------
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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:
|
||||
|
@ -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`.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
-------------------- --------------------- ---------------------
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
@ -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``.
|
||||
|
@ -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,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
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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:
|
||||
|
||||
|
@ -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
|
||||
--------
|
||||
|
||||
|
@ -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
|
||||
|
65
components/light/partition.rst
Normal file
@ -0,0 +1,65 @@
|
||||
Light Partition
|
||||
===============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up light partitions.
|
||||
:image: color_lens.png
|
||||
|
||||
The ``partition`` light platform allows you to combine multiple addressable light segments
|
||||
(like :doc:`fastled_clockless` or :doc:`neopixelbus`) into a single addressable light.
|
||||
This platform also allows splitting up an addressable lights into multiple segments, so that
|
||||
segments can be individually controlled.
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
- platform: partition
|
||||
name: "Partition Light"
|
||||
segments:
|
||||
# Use first LED from the light with ID light1
|
||||
- id: light1
|
||||
from: 0
|
||||
to: 0
|
||||
# Use 10 leds from light with ID light2 starting 2nd LED
|
||||
- id: light2
|
||||
from: 1
|
||||
to: 10
|
||||
|
||||
# Example for light segment source
|
||||
- platform: fastled_clockless
|
||||
id: light2
|
||||
# Other settings
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **name** (**Required**, string): The name of the light.
|
||||
- **segments** (**Required**, list): The segments this light partition controls
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The ID of the light this segment belongs to.
|
||||
- **from** (**Required**, int): The first LED to address in the segment. Counting starts with 0,
|
||||
so first LED is 0.
|
||||
- **to** (**Required**, int): The index of the last LED to address in this segment.
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **effects** (*Optional*, list): A list of :ref:`light effects <light-effects>` to use for this light.
|
||||
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
|
||||
.. note::
|
||||
|
||||
Do *not* use this platform to control each LED on your addressable light - the light
|
||||
objects have a moderate overhead and if you try to create many lights you will run out
|
||||
of memory quickly.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/light/index`
|
||||
- :doc:`/components/light/fastled_clockless`
|
||||
- :doc:`/components/light/neopixelbus`
|
||||
- :apiref:`light/addressable_light.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
@ -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
|
||||
--------
|
||||
|
||||
|
@ -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
|
||||
@ -71,7 +71,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``
|
||||
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
--------
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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:
|
||||
------------------------
|
||||
|
||||
|
@ -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).
|
||||
|
||||
|
@ -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
|
||||
--------
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
||||
@ -36,6 +36,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,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
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
Before Width: | Height: | Size: 3.6 KiB After Width: | Height: | Size: 3.6 KiB |
@ -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
|
||||
|
Before Width: | Height: | Size: 4.4 KiB After Width: | Height: | Size: 4.3 KiB |
@ -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
|
||||
|
Before Width: | Height: | Size: 2.3 KiB After Width: | Height: | Size: 2.3 KiB |
@ -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
|
||||
|
Before Width: | Height: | Size: 3.1 KiB After Width: | Height: | Size: 3.1 KiB |
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -17,7 +17,7 @@ The DHT Temperature+Humidity sensor allows you to use your DHT11
|
||||
`sparkfun <https://cdn.sparkfun.com/datasheets/Sensors/Weather/RHT03.pdf>`__) and SI7021 (one wire Sonoff version)
|
||||
(`datasheet <https://cdn.sparkfun.com/assets/b/1/b/8/5/Si7021-A20.pdf>`__,
|
||||
`sparkfun <https://cdn.sparkfun.com/assets/b/1/b/8/5/Si7021-A20.pdf>`__)
|
||||
sensors with esphomelib.
|
||||
sensors with ESPHome.
|
||||
|
||||
.. figure:: images/dht-full.jpg
|
||||
:align: center
|
||||
|
@ -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,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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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,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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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>`.
|
||||
|
@ -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.
|
||||
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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).
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -1,6 +1,6 @@
|
||||
#include "esphomelib.h"
|
||||
#include "esphome.h"
|
||||
|
||||
using namespace esphomelib;
|
||||
using namespace esphome;
|
||||
|
||||
class MyCustomSensor : public PollingComponent, public sensor::Sensor {
|
||||
public:
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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,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.
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
--------
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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,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).
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
||||
|
@ -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,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,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.
|
||||
|
@ -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:
|
||||
|
||||
@ -113,6 +113,9 @@ Supported remote codes:
|
||||
group: 'a'
|
||||
device: 2
|
||||
state: True
|
||||
rc5:
|
||||
address: 0x00
|
||||
command: 0x0B
|
||||
raw:
|
||||
carrier_frequency: 35kHz
|
||||
data:
|
||||
@ -186,6 +189,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
|
||||
@ -211,7 +219,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
|
||||
@ -221,7 +229,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
|
||||
@ -257,7 +265,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::
|
||||
@ -277,7 +285,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
|
||||
|
||||
@ -317,6 +325,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:
|
||||
@ -328,7 +337,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,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
|
||||
|
@ -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,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
|
||||
|
@ -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
|
||||
|
||||
|