Merge branch 'current' into custom-sensor
# Conflicts: # esphomeyaml/components/sensor/custom.rst # esphomeyaml/guides/getting_started_hassio.rst
@ -1,14 +1,4 @@
|
||||
---
|
||||
build:
|
||||
tags:
|
||||
- esphomedocs
|
||||
script:
|
||||
- make ../esphomelib
|
||||
- make html
|
||||
except:
|
||||
- current
|
||||
- rc
|
||||
|
||||
.deploy: &deploy
|
||||
tags:
|
||||
- esphomedocs
|
||||
@ -26,12 +16,14 @@ build:
|
||||
- git fetch --force git@github.com:${TARGET_REPO}.git gh-pages:gh-pages
|
||||
- git worktree add _build/html gh-pages
|
||||
- make ../esphomelib
|
||||
- touch _build/html/.nojekyll
|
||||
- echo ${CNAME} >_build/html/CNAME
|
||||
- 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
|
||||
|
@ -10,6 +10,12 @@ RUN apt-get update && apt-get install -y --no-install-recommends \
|
||||
make \
|
||||
doxygen \
|
||||
openssh-client \
|
||||
software-properties-common \
|
||||
&& apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/*
|
||||
|
||||
RUN apt-add-repository ppa:inkscape.dev/stable && \
|
||||
apt-get update && apt-get install -y --no-install-recommends \
|
||||
inkscape \
|
||||
&& apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/*
|
||||
|
||||
RUN pip3 install --no-cache-dir --no-binary :all: \
|
||||
|
2
Doxygen
@ -38,7 +38,7 @@ PROJECT_NAME = "esphomelib"
|
||||
# could be handy for archiving the generated documentation or if some version
|
||||
# control system is used.
|
||||
|
||||
PROJECT_NUMBER = 1.9.0b3
|
||||
PROJECT_NUMBER = 1.9.3
|
||||
|
||||
# Using the PROJECT_BRIEF tag one can provide an optional one line description
|
||||
# for a project that appears at the top of each page and should give viewer a
|
||||
|
9
Makefile
@ -8,7 +8,7 @@ SPHINXPROJ = esphomelib
|
||||
SOURCEDIR = .
|
||||
BUILDDIR = _build
|
||||
ESPHOMELIB_PATH = ../esphomelib
|
||||
ESPHOMELIB_TAG = v1.9.0b3
|
||||
ESPHOMELIB_TAG = v1.9.3
|
||||
CNAME = esphomelib.com
|
||||
|
||||
.PHONY: html cleanhtml doxyg cleandoxyg deploy help webserver Makefile $(ESPHOMELIB_PATH)
|
||||
@ -32,11 +32,8 @@ $(ESPHOMELIB_PATH):
|
||||
git clone --branch $(ESPHOMELIB_TAG) https://github.com/OttoWinter/esphomelib.git $(ESPHOMELIB_PATH); \
|
||||
fi
|
||||
|
||||
deploy: cleanhtml doxyg html $(ESPHOMELIB_PATH)
|
||||
touch "$(BUILDDIR)/html/.nojekyll"
|
||||
echo "$(CNAME)" >"$(BUILDDIR)/html/CNAME"
|
||||
git -C "$(BUILDDIR)/html" add --all && git -C "$(BUILDDIR)/html" commit -m "Deploy to gh-pages"
|
||||
@printf "Run \033[0;36mcd $(BUILDDIR)/html && git push origin gh-pages\033[0m to deploy\n"
|
||||
convertimages:
|
||||
python3 svg2png.py
|
||||
|
||||
help:
|
||||
$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
|
1
_static/version
Normal file
@ -0,0 +1 @@
|
||||
1.9.3
|
10
conf.py
@ -45,6 +45,8 @@ extensions = [
|
||||
'disqus',
|
||||
'github',
|
||||
'seo',
|
||||
'githubpages',
|
||||
'sitemap',
|
||||
]
|
||||
|
||||
breathe_projects = {"esphomelib": "./_doxyxml/"}
|
||||
@ -66,6 +68,7 @@ master_doc = 'index'
|
||||
# General information about the project.
|
||||
project = 'esphomelib'
|
||||
copyright = '2018, Otto Winter'
|
||||
html_show_copyright = False
|
||||
author = 'Otto Winter'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
@ -75,7 +78,7 @@ author = 'Otto Winter'
|
||||
# The short X.Y version.
|
||||
version = '1.9'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = '1.9.0b3'
|
||||
release = '1.9.3'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
@ -93,9 +96,9 @@ exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
|
||||
# default_role = 'cpp:any'
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
pygments_style = 'xcode'
|
||||
|
||||
# highlight_language = 'yaml'
|
||||
highlight_language = 'yaml'
|
||||
|
||||
primary_domain = None
|
||||
|
||||
@ -209,3 +212,4 @@ texinfo_documents = [
|
||||
'Miscellaneous'),
|
||||
]
|
||||
html_baseurl = os.getenv('BASE_URL', 'https://esphomelib.com')
|
||||
linkcheck_ignore = [r'https://github.com/.*', r'https://discord.gg/.*']
|
||||
|
@ -3,7 +3,7 @@ Changelog - Version 1.9.0
|
||||
|
||||
.. seo::
|
||||
:description: Changelog for esphomelib version 1.9.0.
|
||||
:image: /_static/_changelog-1.9.0.png
|
||||
:image: /_static/changelog-1.9.0.png
|
||||
:author: Otto Winter
|
||||
:author_twitter: @OttoWinter_
|
||||
|
||||
@ -91,10 +91,10 @@ New Features
|
||||
or higher you will see a list of all components for each esphomelib node in the integrations screen
|
||||
(:libpr:`233`).
|
||||
|
||||
- The current esphomelib version and compilation time are no printed on each boot
|
||||
- The current esphomelib version and compilation time are now printed on each boot
|
||||
(:libpr:`189`, :yamlpr:`159`):
|
||||
|
||||
.. code:: bash
|
||||
.. code-block:: text
|
||||
|
||||
[13:57:33][I][application:092]: You're running esphomelib v1.9.0 compiled on Nov 3 2018, 13:55:11
|
||||
|
||||
@ -158,6 +158,35 @@ Breaking Changes
|
||||
the :docspr:`62` changeset for more information
|
||||
(:libpr:`231`, :docspr:`62`, :yamlpr:`197`)
|
||||
|
||||
Release 1.9.1 - November 19
|
||||
---------------------------
|
||||
|
||||
- lib: Fix RDM6300 not reporting cards :libpr:`278`
|
||||
- lib: Fix SNTP with less than 3 servers :libpr:`279`
|
||||
- lib: Fix update interval log missing time unit :libpr:`280`
|
||||
- lib: Fix CSE7766 spamming logs :libpr:`281`
|
||||
- lib: Fix outdated links :libpr:`282`
|
||||
- yaml: Fix SNTP servers option :yamlpr:`237`
|
||||
|
||||
Release 1.9.2 - November 25
|
||||
---------------------------
|
||||
|
||||
- lib: Fix crashing when logger not being used :libpr:`285`
|
||||
- lib: Fix template cover spamming logs :libpr:`287`
|
||||
- lib: Improve ESP32 BLE tracker stability :libpr:`289`
|
||||
- lib: Fix sensor filters using C++ undefined behavior :libpr:`293`
|
||||
|
||||
Release 1.9.3 - December 1
|
||||
--------------------------
|
||||
|
||||
- docs: Fix Sonoff Basic pinouts :docspr:`88` by :ghuser:`sherbang`
|
||||
- docs: Update cwww.rst :docspr:`85` by :ghuser:`Melkor82`
|
||||
- lib: Fix PMSX003 :libpr:`300`
|
||||
- lib: Fix issue with filters introduced in 1.9.2 :libpr:`296`
|
||||
- lib: Fix BMP085 pressure value :libpr:`292`
|
||||
- yaml: CSE7766 update interval :yamlpr:`250`
|
||||
- docs: CSE7766 Update Interval :docspr:`91`
|
||||
|
||||
All changes
|
||||
-----------
|
||||
|
||||
@ -261,7 +290,9 @@ All changes
|
||||
- yaml: Add Stepper Motor Support :yamlpr:`206` (new-feature)
|
||||
- yaml: Add send_first_at option to sliding window sensor filter :yamlpr:`207` (new-feature)
|
||||
- docs: Switch example to Dehumidifier, minor grammar/puncuation :docspr:`67` by :ghuser:`rorpage`
|
||||
- docs: Tiny typo fix. :docspr:`73` by :ghuser:`corbanmailloux`
|
||||
- yaml: Auto-Decode stacktraces :yamlpr:`214` (new-feature)
|
||||
- docs: Fix a broken link to setting up a BLE tracker. :docspr:`72` by :ghuser:`corbanmailloux`
|
||||
- yaml: Add generate home assistant config command :yamlpr:`208` (new-feature)
|
||||
- yaml: Update Gitlab Build Script :yamlpr:`215`
|
||||
- lib: Fix status binary sensor always reporting false internally :libpr:`257`
|
||||
@ -286,7 +317,15 @@ All changes
|
||||
- lib: Add Total Daily Energy Sensor :libpr:`256` (new-feature)
|
||||
- yaml: Add total daily energy sensor :yamlpr:`220` (new-feature)
|
||||
- docs: Add total daily energy sensor :docspr:`79`
|
||||
|
||||
- lib: Introduce new setup phase: "dump config" to allow fully-offline operation :libpr:`267`
|
||||
- yaml: Let esphomeyaml know about class inheritance :yamlpr:`229`
|
||||
- docs: ESP32 deep sleep wake up multiple pins :docspr:`81`
|
||||
- yaml: Deep Sleep Wake Up From Multiple Pins :yamlpr:`230`
|
||||
- lib: Deep Sleep Multi Wakeup :libpr:`268`
|
||||
- lib: MY9231/MY9291 LED driver support :libpr:`266` by :ghuser:`puuu` (new-feature)
|
||||
- yaml: Add MY9231 support :yamlpr:`227` by :ghuser:`puuu` (new-feature)
|
||||
- docs: MY9231/MY9291 LED driver documentation :docspr:`80` by :ghuser:`puuu` (new-feature)
|
||||
- docs: SEO Optimization :docspr:`82`
|
||||
|
||||
|
||||
Past Changelogs
|
||||
|
@ -94,7 +94,7 @@ Breaking Changes
|
||||
parameter. The accuracy now defaults to ``HIGH``.
|
||||
- The ``inverted`` option of binary sensors has been moved into the ``filters:`` section. So instead of
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: ...
|
||||
@ -103,7 +103,7 @@ Breaking Changes
|
||||
|
||||
you would now write:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: ...
|
||||
|
@ -121,7 +121,7 @@ Other notable changes
|
||||
|
||||
- In actions, instead of
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -130,7 +130,7 @@ Other notable changes
|
||||
|
||||
You can now write:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -138,7 +138,7 @@ Other notable changes
|
||||
|
||||
Or even shorter:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
- switch.turn_on: my_switch
|
||||
|
@ -19,7 +19,7 @@ To use this hub, first setup the :ref:`I²C Bus <i2c>` and connect the sensor to
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/1085
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
ads1115:
|
||||
- address: 0x48
|
||||
|
@ -3,7 +3,7 @@ ESP32 Bluetooth Low Energy Device
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up BLE binary sensors for the ESP32.
|
||||
:image: bluetooth.svg
|
||||
:image: bluetooth.png
|
||||
|
||||
The ``esp32_ble_tracker`` binary sensor platform lets you track the presence of a
|
||||
bluetooth low energy device.
|
||||
@ -12,7 +12,7 @@ bluetooth low energy device.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_ble_tracker:
|
||||
@ -44,12 +44,16 @@ to track. Most devices show this screen in some setting menu. If you don't know
|
||||
however, you can use the ``esp32_ble_tracker`` hub without any binary sensors attached and read through
|
||||
the logs to see discovered Bluetooth Low Energy devices.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry for finding MAC addresses
|
||||
esp32_ble_tracker:
|
||||
|
||||
Using above configuration, first you should see a ``Starting scan...`` debug message at
|
||||
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
|
||||
address type and advertised name. If you don't see these messages, your device is unfortunately
|
||||
|
@ -3,7 +3,7 @@ ESP32 Touch Pad Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the touch pad on the ESP32.
|
||||
:image: touch.svg
|
||||
:image: touch.png
|
||||
|
||||
The ``esp32_touch`` binary sensor platform lets you use the touch peripheral of the
|
||||
ESP32 to detect if a certain pin is being "touched".
|
||||
@ -17,7 +17,7 @@ an ``OFF`` state.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_touch:
|
||||
@ -72,7 +72,7 @@ to output measured values using the ``setup_mode:`` configuration option. Next,
|
||||
for the touch pads you want to observe. Also put some threshold in the configuration as seen below
|
||||
to make the validator happy, we are going to find good thresholds in a moment anyway.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry for finding threshold values
|
||||
esp32_touch:
|
||||
|
@ -3,7 +3,7 @@ GPIO Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up GPIO binary sensors with esphomelib.
|
||||
:image: pin.svg
|
||||
:image: pin.png
|
||||
|
||||
The GPIO Binary Sensor platform allows you to use any input pin on your
|
||||
device as a binary sensor.
|
||||
@ -12,7 +12,7 @@ device as a binary sensor.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
binary_sensor:
|
||||
@ -35,7 +35,7 @@ Configuration variables:
|
||||
For some applications such as reed switches you need to set the pin mode to ``INPUT_PULLUP``
|
||||
like this:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
@ -50,7 +50,7 @@ Inverting Values
|
||||
Use the ``inverted`` property of the :ref:`Pin Schema <config-pin_schema>` to invert the binary
|
||||
sensor:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
binary_sensor:
|
||||
@ -66,7 +66,7 @@ Debouncing Values
|
||||
Some binary sensors are a bit unstable and quickly transition between the ON and OFF state while
|
||||
they're pressed. To fix this and debounce the signal, use the :ref:`binary sensor filters <binary_sensor-filters>`:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
binary_sensor:
|
||||
@ -80,7 +80,7 @@ Above example will only make the signal go high if the button has stayed high fo
|
||||
Alternatively, below configuration will make the binary sensor publish an ON value immediately, but
|
||||
will wait 10ms before publishing an OFF value:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
binary_sensor:
|
||||
|
@ -3,7 +3,7 @@ Binary Sensor Component
|
||||
|
||||
.. seo::
|
||||
:description: Information about the base representation of all binary sensors.
|
||||
:image: folder-open.svg
|
||||
:image: folder-open.png
|
||||
|
||||
With esphomelib you can use different types of binary sensors. They will
|
||||
automatically appear in the Home Assistant front-end and have several
|
||||
@ -19,7 +19,7 @@ All binary sensors have a platform and an optional device class. By
|
||||
default, the binary will chose the appropriate device class itself, but
|
||||
you can always override it.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: ...
|
||||
@ -58,7 +58,7 @@ Binary Sensor Filters
|
||||
With binary sensor filters you can customize how esphomelib handles your binary sensor values even more.
|
||||
They are similar to :ref:`Sensor Filters <sensor-filters>`.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: ...
|
||||
@ -110,7 +110,7 @@ You can access the current state of the binary sensor in :ref:`lambdas <config-l
|
||||
This automation will be triggered when the button is first pressed down, or in other words on the leading
|
||||
edge of the signal.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
@ -129,7 +129,7 @@ Configuration variables: See :ref:`Automation <automation>`.
|
||||
This automation will be triggered when a button press ends, or in other words on the falling
|
||||
edge of the signal.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
@ -149,7 +149,7 @@ This automation will be triggered when a button is pressed down for a time perio
|
||||
``min_length`` to ``max_length``. Any click longer or shorter than this will not trigger the automation.
|
||||
The automation is therefore also triggered on the falling edge of the signal.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
@ -175,7 +175,7 @@ This automation will be triggered when a button is pressed down twice, with the
|
||||
``min_length`` and ``max_length``. When a second leading edge then happens within ``min_length`` and
|
||||
``max_length``, the automation is triggered.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
@ -200,7 +200,7 @@ Configuration variables:
|
||||
This automation will be triggered when a button is pressed in a user-specified sequence.
|
||||
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
@ -238,7 +238,7 @@ You can use an ``OFF`` timing at the end of the timing sequence to differentiate
|
||||
kinds of presses. For example the configuration below will differentiate between double, long and short
|
||||
presses.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_multi_click:
|
||||
- timing:
|
||||
@ -269,7 +269,7 @@ advanced stuff (see the full :doc:`API Reference </api/binary_sensor/index>` for
|
||||
- ``publish_state()``: Manually cause the binary sensor to publish and store a state from anywhere
|
||||
in the program.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
// Within lambda, publish an OFF state.
|
||||
id(my_binary_sensor).publish_state(false);
|
||||
@ -279,7 +279,7 @@ advanced stuff (see the full :doc:`API Reference </api/binary_sensor/index>` for
|
||||
|
||||
- ``.state``: Retrieve the current state of the binary sensor.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
// Within lambda, get the binary sensor state and conditionally do something
|
||||
if (id(my_binary_sensor).state) {
|
||||
|
@ -11,7 +11,7 @@ pressed on, and will turn off as soon as the finger is released.
|
||||
|
||||
See :doc:`/esphomeyaml/components/display/nextion` for setting up the display
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
display:
|
||||
|
@ -14,7 +14,7 @@ unique id (``uid``) is currently being detected by the PN532 or not.
|
||||
|
||||
See :doc:`/esphomeyaml/components/pn532` for instructions for setting up the connection to the PN532.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
|
@ -14,7 +14,7 @@ unique id (``uid``) is currently being detected by the RDM6300 or not.
|
||||
|
||||
See :doc:`/esphomeyaml/components/rdm6300` for instructions for setting up the connection to the RDM6300.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
|
@ -3,14 +3,14 @@ Remote Receiver Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up remote receiver binary sensors for infrared and RF codes.
|
||||
:image: remote.svg
|
||||
:image: remote.png
|
||||
|
||||
The ``remote_receiver`` binary sensor lets you track when a button on a remote control is pressed.
|
||||
|
||||
Each time the pre-defined signal is received, the binary sensor will briefly go ON and
|
||||
then immediately OFF.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
remote_receiver:
|
||||
@ -45,7 +45,7 @@ Configuration variables:
|
||||
For the Sonoff RF Bridge you can use `this hack <https://github.com/xoseperez/espurna/wiki/Hardware-Itead-Sonoff-RF-Bridge---Direct-Hack>`__
|
||||
created by the Github user wildwiz. Then use this configuration for the remote receiver/transmitter hubs:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
remote_receiver:
|
||||
pin: 4
|
||||
|
@ -3,7 +3,7 @@ Status Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MQTT status binary sensors.
|
||||
:image: server-network.svg
|
||||
:image: server-network.png
|
||||
|
||||
The Status Binary Sensor exposes the node state (if it’s connected to
|
||||
MQTT or not) for Home Assistant. It uses the :ref:`MQTT birth and last will messages <mqtt-last_will_birth>`
|
||||
@ -13,7 +13,7 @@ to do this.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
binary_sensor:
|
||||
|
@ -3,7 +3,7 @@ Template Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up template binary sensors.
|
||||
:image: description.svg
|
||||
:image: description.png
|
||||
|
||||
The ``template`` binary sensor platform allows you to define any :ref:`lambda template <config-lambda>`
|
||||
and construct a binary sensor out if it.
|
||||
@ -11,7 +11,7 @@ and construct a binary sensor out if it.
|
||||
For example, below configuration would turn the state of an ultrasonic sensor into
|
||||
a binary sensor.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
binary_sensor:
|
||||
|
@ -3,7 +3,7 @@ Cover Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up base covers in esphomelib.
|
||||
:image: folder-opn.svg
|
||||
:image: folder-opn.png
|
||||
|
||||
The ``cover`` component is a generic representation of covers in esphomelib/yaml.
|
||||
A cover can (currently) either be *closed* or *open* and supports three types of
|
||||
@ -16,7 +16,7 @@ commands: *open*, *close* and *stop*.
|
||||
|
||||
This action opens the cover with the given ID when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -26,7 +26,7 @@ This action opens the cover with the given ID when executed.
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
id(cover_1).open();
|
||||
|
||||
@ -37,7 +37,7 @@ This action opens the cover with the given ID when executed.
|
||||
|
||||
This action closes the cover with the given ID when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -47,7 +47,7 @@ This action closes the cover with the given ID when executed.
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
id(cover_1).close();
|
||||
|
||||
@ -58,7 +58,7 @@ This action closes the cover with the given ID when executed.
|
||||
|
||||
This action stops the cover with the given ID when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -68,7 +68,7 @@ This action stops the cover with the given ID when executed.
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
id(cover_1).stop();
|
||||
|
||||
@ -82,7 +82,7 @@ advanced stuff (see the full :doc:`API Reference </api/cover/index>` for more in
|
||||
- ``publish_state()``: Manually cause the cover to publish a new state and store it internally.
|
||||
If it's different from the last internal state, it's additionally published to the frontend.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
// Within lambda, make the cover report a specific state
|
||||
id(my_cover).publish_state(cover::COVER_OPEN);
|
||||
@ -90,7 +90,7 @@ advanced stuff (see the full :doc:`API Reference </api/cover/index>` for more in
|
||||
|
||||
- ``state``: Retrieve the current state of the cover.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
if (id(my_cover).state == cover::COVER_OPEN) {
|
||||
// Cover is open
|
||||
|
@ -3,7 +3,7 @@ Template Cover
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up template covers in esphomelib.
|
||||
:image: description.svg
|
||||
:image: description.png
|
||||
|
||||
The ``template`` cover platform allows you to create simple covers out of just a few
|
||||
actions and a value lambda. Once defined, it will automatically appear in Home Assistant
|
||||
@ -13,7 +13,7 @@ as a cover and can be controlled through the frontend.
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
cover:
|
||||
|
@ -17,7 +17,7 @@ sensors are connected to should have an external pullup resistor of
|
||||
about 4.7KΩ. For this, connect a resistor of *about* 4.7KΩ (values around that like 1Ω will, if you don't have
|
||||
massively long wires, work fine in most cases) between ``3.3V`` and the data pin.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
dallas:
|
||||
|
@ -3,7 +3,7 @@ Debug Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the debug component in esphomelib
|
||||
:image: bug-report.svg
|
||||
: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.
|
||||
@ -13,7 +13,7 @@ a bunch of useful information like reset reason, free heap size, esphomelib vers
|
||||
|
||||
Example debug component output.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
debug:
|
||||
|
@ -3,7 +3,7 @@ Deep Sleep Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the deep sleep support for minimizing power consumption on ESPs.
|
||||
:image: hotel.svg
|
||||
:image: hotel.png
|
||||
|
||||
The ``deep_sleep`` component can be used to automatically enter a deep sleep mode on the
|
||||
ESP8266/ESP32 after a certain amount of time. This is especially useful with nodes that operate
|
||||
@ -23,7 +23,7 @@ to wake up on any RTC pin (``GPIO0``, ``GPIO2``, ``GPIO4``, ``GPIO12``, ``GPIO13
|
||||
While in deep sleep mode, the node will not do any work and not respond to any network traffic,
|
||||
even Over The Air updates.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
deep_sleep:
|
||||
@ -60,7 +60,7 @@ Advanced features:
|
||||
from the node to be displayed as "unavailable" while the node is in deep sleep mode. To disable availability
|
||||
reporting and not have any "unavailable" values, set ``birth_message`` and ``will_message`` to empty values:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
# ...
|
||||
@ -92,7 +92,7 @@ when the deep sleep should start? There are three ways of handling this using th
|
||||
|
||||
This action makes the given deep sleep component enter deep sleep immediately.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -107,7 +107,7 @@ This action makes the given deep sleep component enter deep sleep immediately.
|
||||
This action prevents the given deep sleep component from entering deep sleep.
|
||||
Useful for
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -126,7 +126,7 @@ Useful for
|
||||
Remember to turn "OTA mode" off again after the OTA update by sending a MQTT message with the payload
|
||||
``OFF``.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
deep_sleep:
|
||||
# ...
|
||||
|
@ -3,7 +3,7 @@ Display Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the display integration.
|
||||
:image: folder-open.svg
|
||||
:image: folder-open.png
|
||||
|
||||
The ``display`` component houses esphomelib's powerful rendering and display
|
||||
engine. Fundamentally, there are these types of displays:
|
||||
@ -38,7 +38,7 @@ option called ``lambda:`` which will be called every time esphomelib wants to re
|
||||
In there, you can write code like in any :ref:`lambda <config-lambda>` in esphomeyaml. Display
|
||||
lambdas are additionally passed a variable called ``it`` which represents the rendering engine object.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
@ -70,7 +70,7 @@ Basic Shapes
|
||||
Now that you know a bit more about esphomelib's coordinate system, let's draw some basic shapes like lines, rectangles
|
||||
and circles:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
@ -92,7 +92,7 @@ All the above methods can optionally also be called with an argument at the end
|
||||
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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
@ -111,7 +111,7 @@ esphomelib only has implemented binary displays.
|
||||
|
||||
Additionally, you have access to two helper methods which will fetch the width and height of the display:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
@ -136,7 +136,7 @@ at **any** size! Granted the reason for it is actually not having to worry about
|
||||
To use fonts you first have to define a font object in your esphomeyaml configuration file. Just grab
|
||||
a ``.ttf`` file from somewhere on the Internet and create a ``font:`` section in your configuration:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
font:
|
||||
- file: "Comic Sans MS.ttf"
|
||||
@ -172,7 +172,7 @@ Configuration variables:
|
||||
|
||||
Then, in your display code just reference the font like so:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
@ -188,7 +188,7 @@ When you enter ``[0,10]`` you're really telling esphomelib that it should positi
|
||||
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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
@ -198,11 +198,11 @@ pointed, so that, as the name implies, the anchor point is a the *top right* cor
|
||||
it.print(0, 0, id(my_font), "Left aligned");
|
||||
|
||||
// Aligned on right edge
|
||||
it.print(0, it.get_width(), id(my_font), TextAlign::TOP_RIGHT, "Right aligned");
|
||||
it.print(it.get_width(), 0, id(my_font), TextAlign::TOP_RIGHT, "Right aligned");
|
||||
|
||||
As with basic shapes, you can also specify a color for the text:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
@ -225,7 +225,7 @@ is way better documented :)
|
||||
``printf`` can do way more stuff than you will probably ever need, but it's also quite simple for the basic stuff.
|
||||
For example, a printf call can look like this:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: ...
|
||||
@ -267,7 +267,7 @@ Another interesting format string is ``%7.2f``, which would become the right-jus
|
||||
You can even have as many format strings as you want in a single printf call. Just make sure the put the
|
||||
arguments after the format string in the right order.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
@ -282,7 +282,7 @@ The last printf tip for use in displays I will discuss here is how to display bi
|
||||
you want to be efficient you can use an *inline if* too. With the ``%s`` print specifier you can tell it to
|
||||
use any string you pass it, like ``"ON"`` or ``"OFF"``.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: ...
|
||||
@ -316,7 +316,7 @@ With esphomelib you can also display the current time using the NTP protocol. Pl
|
||||
Images
|
||||
^^^^^^
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
image:
|
||||
- file: "image.png"
|
||||
@ -339,7 +339,7 @@ Configuration variables:
|
||||
|
||||
And then later in code:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ...
|
||||
|
@ -21,7 +21,7 @@ commonly sold with a PCF8574 chip which only need two lines to the ESP, for that
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
display:
|
||||
@ -71,7 +71,7 @@ Each of the three methods (``print``, ``printf`` and ``strftime``) all optionall
|
||||
beginning which can be used to print the text at a specific position. These arguments are set to ``0`` (column) and ``0`` (row)
|
||||
by default which means the character at the top left.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: lcd_gpio # or lcd_pcf8574
|
||||
@ -92,9 +92,14 @@ by default which means the character at the top left.
|
||||
// Result: "Sensor value: 42"
|
||||
|
||||
// Print the current time
|
||||
it.strftime("It is %H:%M on %d.%m.%Y");
|
||||
it.strftime("It is %H:%M on %d.%m.%Y", id(my_time).now());
|
||||
// Result for 10:06 on august 21st 2018 -> "It is 10:06 on 21.08.2018"
|
||||
|
||||
# (Optional) For displaying time:
|
||||
time:
|
||||
- platform: sntp
|
||||
id: my_time
|
||||
|
||||
.. note::
|
||||
|
||||
If you're not seeing anything on the display, make sure you try turning the contrast potentiometer around.
|
||||
|
@ -23,7 +23,7 @@ As the communication with the :ref:`I²C Bus <i2c>`, you need to have an ``i2c:`
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
i2c:
|
||||
|
@ -24,7 +24,7 @@ You can even daisy-chain multiple MAX7219s by connecting the DOUT of the previou
|
||||
next DIN. With more than ~3 chips the 3.3V will probably not be enough, so then you will have to potentially
|
||||
use a logic level converted.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
@ -75,7 +75,7 @@ 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
|
||||
segment of the previous position will be enabled.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: max7219
|
||||
|
@ -24,7 +24,7 @@ As the communication with the MH-Z19 is done using UART, you need to have an :re
|
||||
in your configuration with ``rx_pin`` both the ``tx_pin`` set to the respective pins on the display.
|
||||
Additionally, you need to set the baud rate to 9600.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
@ -62,7 +62,7 @@ First, you need to use the `Nextion Editor <https://nextion.itead.cc/resources/d
|
||||
create a display file and insert it using the SD card slot. Then, in the rendering ``lambda``, you have 3 main methods
|
||||
you can call to populate data on the display:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: nextion
|
||||
@ -90,7 +90,7 @@ See Also
|
||||
- :doc:`index`
|
||||
- :doc:`API Reference </api/display/nextion>`
|
||||
- `Simple Nextion Library <https://github.com/bborncr/nextion>`__ by `Bentley Born <https://github.com/bborncr>`__
|
||||
- `Official Nextion Library <https://github.com/itead/ITEADLIB_Arduino_Nextion>`__ by `iTead <http://itead.cc/>`__
|
||||
- `Official Nextion Library <https://github.com/itead/ITEADLIB_Arduino_Nextion>`__ by `iTead <https://www.itead.cc/>`__
|
||||
- `Edit this page on GitHub <https://github.com/OttoWinter/esphomedocs/blob/current/esphomeyaml/components/display/nextion.rst>`__
|
||||
|
||||
.. disqus::
|
||||
|
@ -21,7 +21,7 @@ Connect D0 to the SCL pin you chose for the :ref:`I²C Bus <i2c>`, and connect D
|
||||
VCC to 3.3V and GND to GND. Optionally you can also connect the ``RESET`` pin to a pin on the ESP which may
|
||||
improve reliability.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
i2c:
|
||||
@ -66,7 +66,7 @@ See Also
|
||||
|
||||
- :doc:`index`
|
||||
- :doc:`API Reference </api/display/ssd1306>`
|
||||
- `SSD1306 Library <https://github.com/adafruit/Adafruit_SSD1306>`__ by `Adafruit <http://adafruit.com/>`__
|
||||
- `SSD1306 Library <https://github.com/adafruit/Adafruit_SSD1306>`__ by `Adafruit <https://www.adafruit.com/>`__
|
||||
- `Edit this page on GitHub <https://github.com/OttoWinter/esphomedocs/blob/current/esphomeyaml/components/display/ssd1306_i2c.rst>`__
|
||||
|
||||
.. disqus::
|
||||
|
@ -22,7 +22,7 @@ to some GPIO pins on the ESP. For power, connect
|
||||
VCC to 3.3V and GND to GND. Optionally you can also connect the ``RESET`` pin to a pin on the ESP which may
|
||||
improve reliability.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
@ -71,7 +71,7 @@ See Also
|
||||
|
||||
- :doc:`index`
|
||||
- :doc:`API Reference </api/display/ssd1306>`
|
||||
- `SSD1306 Library <https://github.com/adafruit/Adafruit_SSD1306>`__ by `Adafruit <http://adafruit.com/>`__
|
||||
- `SSD1306 Library <https://github.com/adafruit/Adafruit_SSD1306>`__ by `Adafruit <https://www.adafruit.com/>`__
|
||||
- `Edit this page on GitHub <https://github.com/OttoWinter/esphomedocs/blob/current/esphomeyaml/components/display/ssd1306_spi.rst>`__
|
||||
|
||||
.. disqus::
|
||||
|
@ -47,7 +47,7 @@ configuration.
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
|
@ -3,14 +3,14 @@ ESP32 Bluetooth Low Energy Beacon
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Bluetooth Low Energy iBeacons using the BLE feature on ESP32s.
|
||||
:image: bluetooth.svg
|
||||
:image: bluetooth.png
|
||||
|
||||
The ``esp32_ble_beacon`` component creates a Bluetooth Low Energy Beacon with your ESP32 device.
|
||||
Beacons are BLE devices that repeatedly just send out a pre-defined packet of data. This packet
|
||||
can then be received by devices like smartphones and can then be used to track a phone's location.
|
||||
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_ble_beacon:
|
||||
|
@ -3,7 +3,7 @@ ESP32 Bluetooth Low Energy Tracker Hub
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up ESP32 bluetooth low energy device trackers using esphomelib.
|
||||
:image: bluetooth.svg
|
||||
: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.
|
||||
@ -11,7 +11,7 @@ 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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_ble_tracker:
|
||||
|
@ -3,12 +3,12 @@ ESP32 Touch Pad Hub
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the touch pad feature on the ESP32.
|
||||
:image: touch.svg
|
||||
:image: touch.png
|
||||
|
||||
The ``esp32_touch`` component creates a global hub for detecting touches on
|
||||
the eight touch pads of the ESP32 as :doc:`binary senors </esphomeyaml/components/binary_sensor/esp32_touch>`.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_touch:
|
||||
@ -42,13 +42,13 @@ Advanced options (the defaults are usually quite good, but if you're having accu
|
||||
time for all touch pads. A longer conversion time means that more charge/discharge cycles of the touch pad
|
||||
can be performed, therefore increasing accuracy. Default is about 8ms, the maximum amount.
|
||||
- **low_voltage_reference** (*Optional*): The low voltage reference to use for the charge cycles. See
|
||||
the `esp-idf docs <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``0.5V``, ``0.6V``, ``0.7V``, ``0.8V``. Default is ``0.5V``.
|
||||
- **high_voltage_reference** (*Optional*): The high voltage reference to use for the charge cycles. See
|
||||
the `esp-idf docs <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``2.4V``, ``2.5V``, ``2.6V``, ``2.7V``. Default is ``2.7V``.
|
||||
- **voltage_attenuation** (*Optional*): The voltage attenuation to use for the charge cycles. See
|
||||
the `esp-idf docs <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``1.5V``, ``1V``, ``0.5V``, ``0V``. Default is ``0V``.
|
||||
|
||||
See Also
|
||||
|
@ -3,14 +3,14 @@ esphomeyaml Core Configuration
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the core esphomeyaml configuration.
|
||||
:image: cloud-circle.svg
|
||||
:image: cloud-circle.png
|
||||
|
||||
Here you specify some core information that esphomeyaml 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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esphomeyaml:
|
||||
@ -72,7 +72,7 @@ using this configuration option.
|
||||
First, you can configure the use of either the latest esphomelib stable release (``latest``),
|
||||
the latest development code from GitHub (``dev``), or a specific version number (``1.8.0``).
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esphomeyaml:
|
||||
@ -87,10 +87,10 @@ the latest development code from GitHub (``dev``), or a specific version number
|
||||
esphomelib_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/master.zip>`, extract the contents,
|
||||
`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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esphomeyaml:
|
||||
@ -101,7 +101,7 @@ and point esphomeyaml to your local copy. Then you can modify the esphomelib to
|
||||
|
||||
And last, you can make esphomeyaml use a specific branch/commit/tag from a remote git repository:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esphomeyaml:
|
||||
@ -130,7 +130,7 @@ initializing the WiFi driver and so on. Unfortunately, every arduino framework v
|
||||
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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esphomeyaml:
|
||||
@ -172,7 +172,7 @@ For the ESP32, there's currently only one arduino framework version:
|
||||
This automation will be triggered when the ESP boots up. By default, it is executed after everything else
|
||||
is already set up. You can however change this using the ``priority`` parameter.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
esphomeyaml:
|
||||
# ...
|
||||
@ -211,7 +211,7 @@ too many WiFi/MQTT connection attempts, Over-The-Air updates being applied or th
|
||||
It's not guaranteed that all components are in a connected state when this automation is triggered. For
|
||||
example, the MQTT client may have already disconnected.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
esphomeyaml:
|
||||
# ...
|
||||
@ -228,7 +228,7 @@ Configuration variables: See :ref:`Automation <automation>`.
|
||||
|
||||
This automation will be triggered on every ``loop()`` iteration (usually around every 16 milliseconds).
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
esphomeyaml:
|
||||
# ...
|
||||
|
@ -3,7 +3,7 @@ Binary Fan
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up binary fans.
|
||||
:image: fan.svg
|
||||
:image: fan.png
|
||||
|
||||
The ``binary`` fan platform lets you represent any binary :ref:`output` as a fan.
|
||||
|
||||
@ -11,7 +11,7 @@ The ``binary`` fan platform lets you represent any binary :ref:`output` as a fan
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
fan:
|
||||
|
@ -3,7 +3,7 @@ Fan Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the base fan component.
|
||||
:image: folder-open.svg
|
||||
:image: folder-open.png
|
||||
|
||||
With the ``fan`` domain you can create components that appear as fans in
|
||||
the Home Assistant frontend. A fan can be switched ON or OFF, optionally
|
||||
@ -19,7 +19,7 @@ oscillate output.
|
||||
Base Fan Configuration
|
||||
----------------------
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
fan:
|
||||
- platform: ...
|
||||
@ -45,7 +45,7 @@ Configuration variables:
|
||||
|
||||
Toggles the ON/OFF state of the fan with the given ID when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -58,7 +58,7 @@ Toggles the ON/OFF state of the fan with the given ID when executed.
|
||||
|
||||
Turns the fan with the given ID off when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -71,7 +71,7 @@ Turns the fan with the given ID off when executed.
|
||||
|
||||
Turns the fan with the given ID off when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
|
@ -3,7 +3,7 @@ Speed Fan
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up speed-controllable fans.
|
||||
:image: fan.svg
|
||||
:image: fan.png
|
||||
|
||||
The ``speed`` fan platform lets you represent any float :ref:`output` as a fan that
|
||||
supports speed settings.
|
||||
@ -12,7 +12,7 @@ supports speed settings.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
fan:
|
||||
|
@ -5,13 +5,13 @@ I²C Bus
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the i2c bus to communicate with 2-wire devices in esphomelib
|
||||
:image: i2c.svg
|
||||
:image: i2c.png
|
||||
:keywords: i2c, iic, bus
|
||||
|
||||
This component sets up the i²c bus for your ESP32 or ESP8266. In order for those components
|
||||
to work correctly, you need to define the i²c bus in your configuration.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
i2c:
|
||||
|
@ -3,7 +3,7 @@ Binary Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up binary ON/OFF lights in esphomelib.
|
||||
:image: lightbulb.svg
|
||||
:image: lightbulb.png
|
||||
|
||||
The ``binary`` light platform creates a simple ON/OFF-only light from a
|
||||
:ref:`binary output component <output>`.
|
||||
@ -12,7 +12,7 @@ The ``binary`` light platform creates a simple ON/OFF-only light from a
|
||||
:align: center
|
||||
:width: 40.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
|
@ -3,17 +3,17 @@ Cold White + Warm White Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Cold White + Warm White lights.
|
||||
:image: brightness-medium.svg
|
||||
:image: brightness-medium.png
|
||||
|
||||
The ``cwww`` light platform creates an Cold-White+Warm-White
|
||||
light from 2 :ref:`float output components <output>` (one for each channel). The two
|
||||
channels will be mixed using the color temperature configuration options.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
- platform: rgbw
|
||||
- platform: cwww
|
||||
name: "Livingroom Lights"
|
||||
cold_white: output_component1
|
||||
warm_white: output_component2
|
||||
|
@ -3,7 +3,7 @@ FastLED Clockless Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up FastLED addressable lights like NEXTION.
|
||||
:image: color_lens.svg
|
||||
: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>`.
|
||||
@ -15,7 +15,7 @@ Clockless FastLED lights differ from the
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
|
@ -3,7 +3,7 @@ FastLED SPI Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up other FastLED addressable lights.
|
||||
:image: color_lens.svg
|
||||
: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>`.
|
||||
@ -16,7 +16,7 @@ whereas the clockless lights only need a single pin.
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
|
@ -3,7 +3,7 @@ Light Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up lights and light effects in esphomelib.
|
||||
:image: folder-open.svg
|
||||
:image: folder-open.png
|
||||
|
||||
The ``light`` domain in esphomeyaml lets you create lights that will
|
||||
automatically be shown in Home Assistant’s frontend and have many
|
||||
@ -16,7 +16,7 @@ features such as RGB colors, transitions, flashing and effects.
|
||||
|
||||
This action toggles a light with the given ID when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -35,7 +35,7 @@ Configuration options:
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
auto call = id(light_1).toggle();
|
||||
// perform action:
|
||||
@ -48,7 +48,7 @@ Configuration options:
|
||||
|
||||
This action turns a light with the given ID on when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -93,7 +93,7 @@ Configuration options:
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
auto call = id(light_1).turn_on();
|
||||
// set parameters (optional)
|
||||
@ -111,7 +111,7 @@ Configuration options:
|
||||
|
||||
This action turns a light with the given ID off when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -131,7 +131,7 @@ Configuration options:
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
auto call = id(light_1).turn_off();
|
||||
// set parameters (optional)
|
||||
@ -152,7 +152,7 @@ With esphomelib's light effects system you're basically creating a bunch of entr
|
||||
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:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: ...
|
||||
@ -172,7 +172,7 @@ Random Effect
|
||||
|
||||
This effect makes a transition (of length ``transition_length``) to a randomly-chosen color every ``update_interval``.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: ...
|
||||
@ -196,7 +196,7 @@ Strobe Effect
|
||||
|
||||
This effect cycles through a list of colors with specific durations.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: ...
|
||||
@ -239,7 +239,7 @@ Flicker Effect
|
||||
|
||||
This effect "hovers" around the active color of the light and flickers each color channel a bit.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: ...
|
||||
@ -264,7 +264,7 @@ Lambda Effect
|
||||
|
||||
This effect allows you to write completely custom light effects yourself using :ref:`lambdas <config-lambda>`.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: ...
|
||||
@ -302,7 +302,7 @@ FastLED Rainbow Effect
|
||||
A light effect for individually-addressable LEDs that creates a moving rainbow over the whole LED strip using
|
||||
the HSV color wheel.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: fastled_...
|
||||
@ -327,7 +327,7 @@ FastLED Color Wipe Effect
|
||||
A light effect for individually-addressable LEDs that continuously introduces new colors at the beginning of
|
||||
the strip and shifts them forward every ``add_led_interval``.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: fastled_...
|
||||
@ -371,7 +371,7 @@ FastLED Scan Effect
|
||||
Create a single, fast-moving dot moving back and forth an individually-addressable LED strip. The color is chosen by the
|
||||
currently active light color.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: fastled_...
|
||||
@ -395,7 +395,7 @@ A light effect for individually-addressable LED strips that randomly chooses som
|
||||
up for a moment, like a stars twinkling in the night's sky. The color of the pixels will be chosen by the
|
||||
currently active light color.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: fastled_...
|
||||
@ -420,7 +420,7 @@ FastLED Random Twinkle Effect
|
||||
|
||||
A light effect similar to ``fastled_twinkle``, but using random colors for each twinkle animation.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: fastled_...
|
||||
@ -447,7 +447,7 @@ FastLED Fireworks Effect
|
||||
A light effect for individually-addressable LED strips that randomly sparks some fireworks at random positions
|
||||
and lets the sparkles cascade over the LED strip.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: fastled_...
|
||||
@ -480,7 +480,7 @@ FastLED Flicker Effect
|
||||
An effect similar to the ``flicker`` effect, but for individually-addressable LED strips. This effect flickers
|
||||
each LED by its own random amount around the currently active light color.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: fastled_...
|
||||
|
@ -3,7 +3,7 @@ Monochromatic Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up monochromatic (brightness-only) lights.
|
||||
:image: brightness-medium.svg
|
||||
:image: brightness-medium.png
|
||||
|
||||
The ``monochromatic`` light platform creates a simple brightness-only light from an
|
||||
:ref:`float output component <output>`.
|
||||
@ -18,7 +18,7 @@ The ``monochromatic`` light platform creates a simple brightness-only light from
|
||||
:align: center
|
||||
:width: 40.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
|
@ -18,7 +18,7 @@ The ``rgb`` light platform creates an RGB light from 3 :ref:`float output compon
|
||||
:align: center
|
||||
:width: 40.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
|
@ -7,7 +7,7 @@ RGBW Light
|
||||
|
||||
The ``rgbw`` light platform creates an RGBW light from 4 :ref:`float output components <output>` (one for each channel).
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
|
@ -9,7 +9,7 @@ The ``rgbww`` light platform creates an RGBWW (cold white + warm white)
|
||||
light from 5 :ref:`float output components <output>` (one for each channel). The cold white
|
||||
and warm white channels will be mixed using the color temperature configuration options.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
|
@ -3,14 +3,14 @@ Logger Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the central logging component in esphomelib.
|
||||
:image: file-document-box.svg
|
||||
:image: file-document-box.png
|
||||
|
||||
The logger component automatically logs all log messages through the
|
||||
serial port and through MQTT topics. By default, all logs with a
|
||||
severity higher than ``DEBUG`` will be shown. Decreasing the log level
|
||||
can help with the performance of the application and memory size.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
logger:
|
||||
@ -39,13 +39,37 @@ Log Levels
|
||||
Possible log levels are (sorted by severity):
|
||||
|
||||
- ``NONE``
|
||||
|
||||
- No messages are logged.
|
||||
|
||||
- ``ERROR``
|
||||
|
||||
- With this log level, only errors are logged. Errors are issues that prevent the ESP from working
|
||||
correctly. Color: red
|
||||
|
||||
- ``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
|
||||
|
||||
- ``INFO``
|
||||
- ``DEBUG``
|
||||
|
||||
- With this log level, everything up to info messages are logged; so errors, warnings and info. Color: green
|
||||
|
||||
- ``DEBUG`` (**Default**)
|
||||
|
||||
- Everything up to this log level is logged. Debug messages include the current readings from a sensor
|
||||
and status messages. Color: cyan
|
||||
|
||||
- ``VERBOSE``
|
||||
|
||||
- Like debug, but a few more messages that are usually deemed to be spam are also included. Color: grey
|
||||
|
||||
- ``VERY_VERBOSE``
|
||||
|
||||
- All internal messages are logged. Including all the data flowing through data buses like
|
||||
i2c, spi or uart. Color: white
|
||||
|
||||
.. _logger-manual_tag_specific_levels:
|
||||
|
||||
Manual Tag-Specific Log Levels
|
||||
@ -64,7 +88,7 @@ the tag for MQTT components is ``mqtt.component``.
|
||||
|
||||
Next, we can manually set the log levels in the configuration like this:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
logger:
|
||||
level: VERBOSE
|
||||
@ -87,7 +111,7 @@ Print a formatted message to the logs.
|
||||
|
||||
In the ``format`` option, you can use ``printf``-style formatting (see :ref:`display-printf`).
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
|
@ -12,7 +12,7 @@ just be able to copy over the `MQTT
|
||||
section <https://www.home-assistant.io/components/mqtt/>`__ of your Home
|
||||
Assistant configuration.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
mqtt:
|
||||
@ -72,7 +72,7 @@ MQTTMessage
|
||||
With the MQTT Message schema you can tell esphomeyaml 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:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Simple:
|
||||
some_option: topic/to/send/to
|
||||
@ -115,7 +115,7 @@ broker (like `mosquitto <https://mosquitto.org/>`__) and point both your
|
||||
Home Assistant installation and esphomelib to that broker. Next, enable
|
||||
discovery in your Home Assistant configuration with the following:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example Home Assistant configuration.yaml entry
|
||||
mqtt:
|
||||
@ -136,7 +136,7 @@ esphomeyaml anymore.
|
||||
To fix this, esphomeyaml has a simple helper script that purges stale
|
||||
retained messages for you:
|
||||
|
||||
.. code:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
esphomeyaml configuration.yaml clean-mqtt
|
||||
|
||||
@ -184,7 +184,7 @@ broker to send a message ``<TOPIC_PREFIX>/status`` with payload
|
||||
You can change these messages by overriding the ``birth_message`` and
|
||||
``will_message`` with the following options.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
# ...
|
||||
@ -217,13 +217,13 @@ 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:
|
||||
|
||||
.. code:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
esphomeyaml livingroom.yaml mqtt-fingerprint
|
||||
> SHA1 Fingerprint: a502ff13999f8b398ef1834f1123650b3236fc07
|
||||
> Copy above string into mqtt.ssl_fingerprints section of livingroom.yaml
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
# ...
|
||||
@ -238,7 +238,7 @@ MQTT Component Base Configuration
|
||||
All components in esphomelib that do some sort of communication through
|
||||
MQTT can have some overrides for specific options.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
name: "Component Name"
|
||||
# Optional variables:
|
||||
@ -286,7 +286,7 @@ With this configuration option you can write complex automations whenever an MQT
|
||||
message on a specific topic is received. To use the message content, use a :ref:`lambda <config-lambda>`
|
||||
template, the message payload is available under the name ``x`` inside that lambda.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
# ...
|
||||
@ -304,11 +304,14 @@ Configuration variables:
|
||||
- **qos** (*Optional*, integer): The MQTT Quality of Service to subscribe to the topic with. Defaults
|
||||
to 0.
|
||||
|
||||
- **payload** (*Optional*, string): Optionally set a payload to match. Only if exactly the payload
|
||||
you specify with this option is received, the automation will be executed.
|
||||
|
||||
.. note::
|
||||
|
||||
You can even specify multiple ``on_message`` triggers by using a YAML list:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
on_message:
|
||||
@ -323,7 +326,7 @@ Configuration variables:
|
||||
|
||||
This action can also be used in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
App.get_mqtt_client()->subscribe("the/topic", [=](const std::string &payload) {
|
||||
// do something with payload
|
||||
@ -345,7 +348,7 @@ Basically, you can access elements by typing ``x["THE_KEY"]`` and save them into
|
||||
Please note that it's a good idea to check if the key exists in the Json Object by calling
|
||||
``containsKey`` first as the ESP will crash if an element that does not exist is accessed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
# ...
|
||||
@ -386,7 +389,7 @@ Configuration variables:
|
||||
|
||||
This action can also be used in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
App.get_mqtt_client()->subscribe_json("the/topic", [=](JsonObject &root) {
|
||||
// do something with JSON-decoded value root
|
||||
@ -399,7 +402,7 @@ Configuration variables:
|
||||
|
||||
Publish an MQTT message on a topic using this action in automations.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -431,13 +434,13 @@ Configuration options:
|
||||
|
||||
This action can also be written in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
# Give the mqtt component an ID
|
||||
id: mqtt_client
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
id(mqtt_client).publish("the/topic", "The Payload");
|
||||
|
||||
@ -453,7 +456,7 @@ In the ``payload`` option you have access to a ``root`` object which will repres
|
||||
of the JSON message. You can assign values to keys by using the ``root["KEY_NAME"] = VALUE;`` syntax
|
||||
as seen below.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -482,13 +485,13 @@ Configuration options:
|
||||
|
||||
This action can also be written in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
# Give the mqtt component an ID
|
||||
id: mqtt_client
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
id(mqtt_client).publish_json("the/topic", [=](JsonObject &root) {
|
||||
root["something"] = id(my_sensor).value;
|
||||
|
@ -3,7 +3,7 @@ MY9231/MY9291 LED driver Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MY9231 and MY9291 LED drives in esphomelib.
|
||||
:image: my9231.svg
|
||||
: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
|
||||
@ -40,7 +40,7 @@ global ``my9231`` hub and give it an id, and then define the
|
||||
internal data will not reflect this state. Thus, the first fade
|
||||
is wrong, as well as the MQTT state.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
my9231:
|
||||
@ -83,7 +83,7 @@ about flashing Sonoff devices, see:
|
||||
chain of two MY9321 chips that are connected to GPIO12 and GPIO14. A
|
||||
complete configuration for a Sonoff B1 looks like:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
esphomeyaml:
|
||||
name: <NAME_OF_NODE>
|
||||
@ -106,8 +106,8 @@ complete configuration for a Sonoff B1 looks like:
|
||||
password: <YOUR_OTA_PASSWORD>
|
||||
|
||||
my9231:
|
||||
data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
data_pin: GPIO12 # GPIO13 for AiLight
|
||||
clock_pin: GPIO14 # GPIO15 for AiLight
|
||||
num_channels: 6
|
||||
num_chips: 2
|
||||
|
||||
|
@ -3,7 +3,7 @@ OTA Update Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Over-The-Air (OTA) updates for ESPs to upload firmwares remotely.
|
||||
:image: system-update.svg
|
||||
:image: system-update.png
|
||||
:keywords: Xiaomi, Mi Flora, BLE, Bluetooth
|
||||
|
||||
With the OTA (Over The Air) update component you can upload your
|
||||
@ -32,7 +32,7 @@ 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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
ota:
|
||||
|
@ -16,7 +16,7 @@ limitations.
|
||||
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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
output:
|
||||
|
@ -3,13 +3,13 @@ GPIO Output
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up binary outputs for GPIO pins.
|
||||
:image: pin.svg
|
||||
:image: pin.png
|
||||
|
||||
The GPIO output component is quite simple: It exposes a single GPIO pin
|
||||
as an output component. Note that output components are **not** switches and
|
||||
will not show up in Home Assistant. See :doc:`GPIO Switch <gpio>`.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
output:
|
||||
|
@ -5,7 +5,7 @@ Output Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up generic outputs in esphomelib
|
||||
:image: folder-open.svg
|
||||
:image: folder-open.png
|
||||
|
||||
Each platform of the ``output`` domain exposes some output to
|
||||
esphomelib. These are grouped into two categories: ``binary`` outputs
|
||||
@ -19,7 +19,7 @@ Base Output Configuration
|
||||
|
||||
Each output platform extends this configuration schema.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
output:
|
||||
@ -50,7 +50,7 @@ Configuration variables:
|
||||
|
||||
This action turns the output with the given ID on when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -60,7 +60,7 @@ This action turns the output with the given ID on when executed.
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
id(relay_1).turn_on();
|
||||
|
||||
@ -71,7 +71,7 @@ This action turns the output with the given ID on when executed.
|
||||
|
||||
This action turns the output with the given ID off when executed.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -81,7 +81,7 @@ This action turns the output with the given ID off when executed.
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
id(relay_1).turn_off();
|
||||
|
||||
@ -93,7 +93,7 @@ This action turns the output with the given ID off when executed.
|
||||
This action sets the float output to the given level when executed. Note: This only
|
||||
works with floating point outputs like ESP8266 PWM or LEDC.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
@ -105,7 +105,7 @@ works with floating point outputs like ESP8266 PWM or LEDC.
|
||||
|
||||
This action can also be expressed in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
// range is 0.0 (off) to 1.0 (on)
|
||||
id(relay_1).set_level(0.5);
|
||||
|
@ -6,10 +6,10 @@ ESP32 LEDC Output
|
||||
:image: pwm.png
|
||||
|
||||
The LEDC output component exposes a `LEDC PWM
|
||||
channel <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/ledc.html>`__
|
||||
channel <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/ledc.html>`__
|
||||
of the ESP32 as an output component.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
output:
|
||||
@ -27,7 +27,7 @@ Configuration variables:
|
||||
therefore also the same frequency. Defaults to 1000Hz.
|
||||
- **bit_depth** (*Optional*, int): The bit depth to use for the LEDC channel. Defaults to 12.
|
||||
- **channel** (*Optional*, int): Manually set the `LEDC
|
||||
channel <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/ledc.html#configure-channel>`__
|
||||
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>`.
|
||||
|
||||
@ -40,7 +40,7 @@ See Also
|
||||
- :doc:`/esphomeyaml/components/fan/speed`
|
||||
- :doc:`/esphomeyaml/components/power_supply`
|
||||
- :doc:`API Reference </api/output/ledc>`
|
||||
- `esp-idf LEDC API docs <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/ledc.html>`__
|
||||
- `esp-idf LEDC API docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/ledc.html>`__
|
||||
- `Edit this page on GitHub <https://github.com/OttoWinter/esphomedocs/blob/current/esphomeyaml/components/output/ledc.rst>`__
|
||||
|
||||
.. disqus::
|
||||
|
@ -3,12 +3,12 @@ MY9231/MY9291 Output
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MY931 and MY9231 outputs.
|
||||
:image: my9231.svg
|
||||
:image: my9231.png
|
||||
|
||||
The MY931/MY9291 output component exposes a MY931/MY9291 channel of a global
|
||||
:doc:`/esphomeyaml/components/my9231` as a float output.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
my9231:
|
||||
|
@ -15,7 +15,7 @@ output.
|
||||
|
||||
PCA9685 16-Channel PWM Driver.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
pca9685:
|
||||
|
@ -7,7 +7,7 @@ PCA9685 PWM Component
|
||||
:keywords: PCA9685
|
||||
|
||||
The PCA9685 component represents a PCA9685 12-bit PWM driver
|
||||
(`datasheet <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/ledc.html#configure-channel>`__,
|
||||
(`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
|
||||
uses :ref:`I²C Bus <i2c>` for communication.
|
||||
|
||||
@ -15,7 +15,7 @@ To use the channels of this components, you first need to setup the
|
||||
global ``pca9685`` hub and give it an id, and then define the
|
||||
:doc:`individual output channels </esphomeyaml/components/output/pca9685>`.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
pca9685:
|
||||
|
@ -27,7 +27,7 @@ not work.
|
||||
|
||||
.. _Sparkfun: https://www.sparkfun.com/products/retired/8130
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
pcf8574:
|
||||
|
@ -22,7 +22,7 @@ As the communication with the PN532 is done using SPI for this integration, you
|
||||
the board to the SPI mode (usually by setting the first one to OFF and the second one to ON). Additionally, you need
|
||||
to have an :ref:`spi bus <spi>` in your configuration with both the **miso_pin** and **mosi_pin** set.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
@ -71,7 +71,7 @@ if the tag is re-read many times.
|
||||
The parameter ``x`` this trigger provides is of type ``std::string`` and is the tag UID in the format
|
||||
``74-10-37-94``. The configuration below will for example publish the tag ID on the MQTT topic ``pn532/tag``.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
pn532:
|
||||
# ...
|
||||
|
@ -3,7 +3,7 @@ Power Supply Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up power supplies which will automatically turn on together with outputs.
|
||||
:image: power.svg
|
||||
:image: power.png
|
||||
:keywords: power, ATX
|
||||
|
||||
The ``power_supply`` component allows you to have a high power mode for
|
||||
@ -16,7 +16,7 @@ will automatically switch on if any of the outputs are on. Furthermore,
|
||||
it also has a cooldown time that keeps the power supply on for a while
|
||||
after the last output has been disabled.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
power_supply:
|
||||
@ -53,7 +53,7 @@ pin up when high power mode is needed. Most ATX power supplies however
|
||||
operate with an active-low configuration. Therefore their output needs
|
||||
to be inverted.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
power_supply:
|
||||
- id: 'atx_power_supply'
|
||||
|
@ -22,7 +22,7 @@ As the communication with the RDM6300 is done using UART, you need
|
||||
to have an :ref:`UART bus <uart>` in your configuration with the ``rx_pin`` connected to the data pin of the RDM6300 and
|
||||
with the baud rate set to 9600
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
|
@ -3,7 +3,7 @@ Remote Receiver Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up remote receivers in esphomelib.
|
||||
:image: remote.svg
|
||||
:image: remote.png
|
||||
:keywords: RF, infrared
|
||||
|
||||
The ``remote_receiver`` component lets you receive and decode any remote signal, these can
|
||||
@ -14,7 +14,7 @@ receive, decode and dump all remote codes, and individual
|
||||
:doc:`remote receiver binary sensors <binary_sensor/remote_receiver>` which will trigger when they
|
||||
hear their own configured signal.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
remote_receiver:
|
||||
|
@ -3,7 +3,7 @@ Remote Transmitter Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up remote transmitters in esphomelib
|
||||
:image: remote.svg
|
||||
:image: remote.png
|
||||
:keywords: RF, infrared
|
||||
|
||||
The ``remote_transmitter`` component lets you send infrared messages to control
|
||||
@ -18,7 +18,7 @@ Use-cases are for example infrared remotes or 433MHz signals.
|
||||
This component is *much* more accurate on the ESP32, since that chipset has a dedicated
|
||||
peripheral for sending exact signal sequences.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
remote_transmitter:
|
||||
|
@ -3,7 +3,7 @@ Analog To Digital Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up built-in analog voltage sensors.
|
||||
:image: flash.svg
|
||||
:image: flash.png
|
||||
|
||||
The Analog To Digital (``adc``) Sensor allows you to use the built-in
|
||||
ADC in your device to measure a voltage on certain pins. On the ESP8266
|
||||
@ -14,7 +14,7 @@ GPIO39 can be used.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
@ -50,7 +50,7 @@ On the ESP32, the voltage measured with the ADC caps out at 1.1V by default as t
|
||||
or the attenuation of the ADC is set to ``0db`` by default.
|
||||
|
||||
To measure voltages higher than 1.1V, set ``attenuation`` to one of the `following values
|
||||
<http://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/adc.html#_CPPv225adc1_config_channel_atten14adc1_channel_t11adc_atten_t>`__:
|
||||
<https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/adc.html#_CPPv225adc1_config_channel_atten14adc1_channel_t11adc_atten_t>`__:
|
||||
|
||||
- ``0db`` for a full-scale voltage of 1.1V (default)
|
||||
- ``2.5db`` for a full-scale voltage of 1.5V
|
||||
@ -67,7 +67,7 @@ where you want to shut down the chip if the voltage is low when using a battery.
|
||||
|
||||
To measure the VCC voltage, set ``pin:`` to ``VCC`` and make sure nothing is connected to the ``A0`` pin.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: adc
|
||||
|
@ -24,7 +24,7 @@ voltage to Home Assistant.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
ads1115:
|
||||
- address: 0x48
|
||||
|
@ -24,7 +24,7 @@ your configuration for this sensor to work.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -3,14 +3,14 @@ ESP32 Bluetooth Low Energy RSSI Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up RSSI sensors for the ESP32 BLE.
|
||||
:image: bluetooth.svg
|
||||
:image: bluetooth.png
|
||||
:keywords: ESP32
|
||||
|
||||
The ``ble_rssi`` sensor platform lets you track the RSSI value or signal strength of a
|
||||
BLE device. See :ref:`the binary sensor setup <esp32_ble_tracker-setting_up_devices>` for
|
||||
instructions for setting up this platform.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_ble_tracker:
|
||||
|
@ -19,7 +19,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/2652
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
Before Width: | Height: | Size: 3.8 KiB After Width: | Height: | Size: 3.8 KiB |
@ -19,7 +19,7 @@ your configuration for this sensor to work.
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/3660
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
Before Width: | Height: | Size: 4.5 KiB After Width: | Height: | Size: 4.5 KiB |
@ -24,7 +24,7 @@ your configuration for this sensor to work.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
Before Width: | Height: | Size: 2.5 KiB After Width: | Height: | Size: 2.5 KiB |
@ -19,7 +19,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/2651
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
Before Width: | Height: | Size: 3.2 KiB After Width: | Height: | Size: 3.3 KiB |
@ -3,14 +3,9 @@ CSE7766 Power Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up CSE7766 power sensors for the Sonoff Pow R2
|
||||
:image: cse7766.svg
|
||||
:image: cse7766.png
|
||||
:keywords: cse7766, Sonoff Pow R2
|
||||
|
||||
.. warning::
|
||||
|
||||
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>`__.
|
||||
|
||||
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.
|
||||
@ -19,7 +14,7 @@ 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.
|
||||
Additionally, you need to set the baud rate to 4800.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
# Disable logging over USB
|
||||
@ -52,6 +47,8 @@ Configuration variables:
|
||||
:ref:`Sensor <config-sensor>` and :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- **voltage** (*Optional*): Use the voltage value of the sensor in V (RMS).
|
||||
All options from :ref:`Sensor <config-sensor>` and :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the
|
||||
sensor. Defaults to ``15s``. See :ref:`sensor-default_filter`.
|
||||
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
|
||||
to use multiple UART buses.
|
||||
|
||||
|
@ -26,7 +26,7 @@ To initialize a sensor, first supply either ``address`` **or** ``index`` to iden
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
dallas:
|
||||
@ -67,7 +67,7 @@ level <logger-log_levels>` must be set to at least
|
||||
``debug``!). Note that you don't need to define the individual sensors just yet, as
|
||||
the scanning will happen even with no sensors connected. For example with this configuration:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
dallas:
|
||||
@ -81,7 +81,7 @@ You will find something like this:
|
||||
|
||||
Now we can add the individual sensors to our configuration:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
dallas:
|
||||
|
@ -33,7 +33,7 @@ if you're having issues try the 4.7kΩ recommended by the manufacturer) between
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -22,7 +22,7 @@ The ``dht12`` Temperature+Humidity sensor allows you to use your DHT12
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -3,7 +3,7 @@ Duty Cycle Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up duty cycle sensors in esphomelib
|
||||
:image: percent.svg
|
||||
:image: percent.png
|
||||
|
||||
The duty cycle sensor allows you to measure for what percentage of time a signal
|
||||
on a GPIO pin is HIGH or LOW.
|
||||
@ -15,7 +15,7 @@ For example, you can measure if a status LED of a pool controller is permanently
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -3,7 +3,7 @@ ESP32 Hall Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the integrated hall-effect sensor of the ESP32.
|
||||
:image: magnet.svg
|
||||
:image: magnet.png
|
||||
:keywords: esp32, hall
|
||||
|
||||
The ``esp32_hall`` sensor platform allows you to use the integrated
|
||||
@ -19,7 +19,7 @@ by the hall sensor.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -25,7 +25,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -3,7 +3,7 @@ HLW8012 Power Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up HLW8012 power sensors for the Sonoff Pow R1
|
||||
:image: hlw8012.svg
|
||||
:image: hlw8012.png
|
||||
:keywords: HLW8012, Sonoff Pow R1
|
||||
|
||||
The ``hlw8012`` sensor platform allows you to use your HLW8012 voltage/current and power sensors
|
||||
@ -17,7 +17,7 @@ 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
|
||||
be measured at the same exact points in time.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -14,7 +14,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/1746
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -7,7 +7,7 @@ HTU21D Temperature+Humidity Sensor
|
||||
:keywords: HTU21D
|
||||
|
||||
The HTU21D Temperature+Humidity sensor allows you to use your HTU21D
|
||||
(`datasheet <http://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Data+Sheet%7FHPC199_6%7FA6%7Fpdf%7FEnglish%7FENG_DS_HPC199_6_A6.pdf%7FCAT-HSC0004>`__,
|
||||
(`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
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
@ -28,7 +28,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
|
||||
The **SI7021** sensor also works with this integration.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -3,7 +3,7 @@ HX711 Load Cell Amplifier
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up HX711 load cell amplifiers with esphomelib
|
||||
:image: hx711.svg
|
||||
:image: hx711.png
|
||||
:keywords: HX711
|
||||
|
||||
The ``hx711`` sensor platform allows you to use your HX711
|
||||
@ -22,7 +22,7 @@ load cell amplifier
|
||||
Connect ``GND`` to ``GND``, ``VCC`` to ``3.3V`` and the other three ``MISO`` (or ``SO`` for short),
|
||||
``CS`` and ``CLOCK`` (or ``SCK``) to free GPIO pins.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
@ -58,7 +58,7 @@ To calibrate the sensor:
|
||||
|
||||
Once you've done those steps, you can use the ``map`` function to map the incoming value to the calibrated one:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -25,7 +25,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -25,7 +25,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -3,7 +3,7 @@ Sensor Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up sensor components in esphomelib.
|
||||
:image: folder-open.svg
|
||||
:image: folder-open.png
|
||||
|
||||
esphomelib has support for many different sensors. Each of them is a
|
||||
platform of the ``sensor`` domain and each sensor has several base
|
||||
@ -19,7 +19,7 @@ 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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example sensor configuration
|
||||
name: Livingroom Temperature
|
||||
@ -64,7 +64,7 @@ Automations:
|
||||
If you're trying to setup filters for a sensor that has multiple outputs - for example a DHT22 which
|
||||
reports temperature *and* humidity - put the ``filters`` option into each sensor output like this:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: dht
|
||||
@ -86,10 +86,10 @@ 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 `filter
|
||||
with Home Assistant's `filter
|
||||
sensor <https://www.home-assistant.io/components/sensor.filter/>`__.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example filters:
|
||||
filters:
|
||||
@ -183,7 +183,7 @@ 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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
filters:
|
||||
- lambda: return x * (9.0/5.0) + 32.0;
|
||||
@ -200,7 +200,7 @@ Therefore if you have an ``update_interval`` of 15 seconds, you will only see th
|
||||
every 3 and a half minutes or so. To disable the default filter and publish all raw values
|
||||
directly, put an empty ``filters:`` block in your configuration:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
@ -223,7 +223,7 @@ This automation will be triggered when a new value that has passed through all f
|
||||
is published. In :ref:`Lambdas <config-lambda>` you can get the value from the trigger
|
||||
with ``x``.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: dallas
|
||||
@ -250,7 +250,7 @@ was outside the range. It will also trigger on startup if the first value receiv
|
||||
Define the range with ``above`` and ``below``. If only one of them is defined, the interval is half-open.
|
||||
So for example ``above: 5`` with no below would mean the range from 5 to positive infinity.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: dallas
|
||||
@ -276,7 +276,7 @@ This automation will be triggered when a new value that has passed through all f
|
||||
is published. In :ref:`Lambdas <config-lambda>` you can get the value from the trigger
|
||||
with ``x``.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: dallas
|
||||
@ -298,7 +298,7 @@ advanced stuff (see the full :doc:`API Reference </api/sensor/index>` for more i
|
||||
- ``publish_state()``: Manually cause the sensor to push out a value. It will then
|
||||
be processed by the sensor filters, and once done be published to MQTT.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: cpp
|
||||
|
||||
// Within lambda, push a value of 42.0
|
||||
id(my_sensor).publish_state(42.0);
|
||||
@ -306,7 +306,7 @@ advanced stuff (see the full :doc:`API Reference </api/sensor/index>` for more i
|
||||
- ``.state``: Retrieve the current value of the sensor that has passed through all sensor filters.
|
||||
Is ``NAN`` if no value has gotten through all filters yet.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: cpp
|
||||
|
||||
// For example, create a custom log message when a value is received:
|
||||
ESP_LOGI("main", "Value of my sensor: %f", id(my_sensor).state);
|
||||
@ -314,7 +314,7 @@ advanced stuff (see the full :doc:`API Reference </api/sensor/index>` for more i
|
||||
- ``raw_state``: Retrieve the current value of the sensor that has not passed through any filters
|
||||
Is ``NAN`` if no value if no value has been pushed by the sensor itself yet.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: cpp
|
||||
|
||||
// For example, create a custom log message when a value is received:
|
||||
ESP_LOGI("main", "Raw Value of my sensor: %f", id(my_sensor).raw_state);
|
||||
|
@ -26,7 +26,7 @@ Connect ``GND`` to ``GND``, ``VCC`` to ``3.3V`` and the other three ``MISO`` (or
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
|
@ -22,7 +22,7 @@ to have an :ref:`UART bus <uart>` in your configuration with the ``rx_pin`` conn
|
||||
MH-Z19 and the ``tx_pin`` connected to the RX Pin of the MH-Z19 (it's switched because the
|
||||
TX/RX labels are from the perspective of the MH-Z19). Additionally, you need to set the baud rate to 9600.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
|
@ -29,7 +29,7 @@ new feature. Supporting all possible use-cases would be quite hard.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -14,7 +14,7 @@ Please note this integration only works with MQTT topics that have numeric data!
|
||||
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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -7,7 +7,7 @@ MS5611 Atmospheric Pressure Sensor
|
||||
:keywords: MS5611
|
||||
|
||||
The ``ms5611`` sensor platform allows you to use your MS5611 atmospheric pressure sensors
|
||||
(`datasheet <http://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Data+Sheet%7FMS5611-01BA03%7FB3%7Fpdf%7FEnglish%7FENG_DS_MS5611-01BA03_B3.pdf%7FCAT-BLPS0036>`__,
|
||||
(`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
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
|
||||
@ -23,7 +23,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -3,7 +3,7 @@ PMSX003 Particulate Matter Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up PMSX003 Particulate matter sensors
|
||||
:image: pmsx003.svg
|
||||
:image: pmsx003.png
|
||||
|
||||
.. warning::
|
||||
|
||||
@ -25,15 +25,16 @@ value:
|
||||
- ``PMS5003T`` for PMS5003T. These support ``pm_2_5``, ``temperature`` and ``humidity``.
|
||||
- ``PMS5003ST`` for PMS5003ST. These support ``pm_2_5``, ``temperature``, ``humidity`` and ``formaldehyde``.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
rx_pin: GPIO23
|
||||
baud_rate: 9600
|
||||
|
||||
sensor:
|
||||
- platform: pmsx003
|
||||
type: PMX003
|
||||
type: PMSX003
|
||||
pm_1_0:
|
||||
name: "Particulate Matter <1.0µm Concentration"
|
||||
pm_2_5:
|
||||
|
@ -3,20 +3,20 @@ Pulse Counter Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up pulse counter sensors.
|
||||
:image: pulse.svg
|
||||
:image: pulse.png
|
||||
|
||||
The pulse counter sensor allows you to count the number of pulses and the frequency of a signal
|
||||
on any pin.
|
||||
|
||||
On the ESP32, this sensor is even highly accurate because it's using the hardware `pulse counter
|
||||
peripheral <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/pcnt.html>`__
|
||||
peripheral <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/pcnt.html>`__
|
||||
on the ESP32.
|
||||
|
||||
.. figure:: images/pulse-counter.png
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
@ -55,7 +55,7 @@ of “pulses/min”. You can change this by using :ref:`sensor-filters`.
|
||||
For example, if you’re using the pulse counter with a photodiode to
|
||||
count the light pulses on a power meter, you can do the following:
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
@ -71,7 +71,7 @@ See Also
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`rotary_encoder`
|
||||
- `esp-idf Pulse Counter API <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/pcnt.html>`__.
|
||||
- `esp-idf Pulse Counter API <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/pcnt.html>`__.
|
||||
- :doc:`API Reference </api/sensor/pulse_counter>`
|
||||
- `Edit this page on GitHub <https://github.com/OttoWinter/esphomedocs/blob/current/esphomeyaml/components/sensor/pulse_counter.rst>`__
|
||||
|
||||
|
@ -27,7 +27,7 @@ To use rotary encoders in esphomeyaml, first identify the two pins encoding th s
|
||||
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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
@ -58,7 +58,7 @@ In order to not put too much stress on your network connection, you can leverage
|
||||
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.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -17,7 +17,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -23,7 +23,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
|
@ -3,12 +3,12 @@ Template Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up template sensors with esphomelib.
|
||||
:image: description.svg
|
||||
:image: description.png
|
||||
|
||||
The ``template`` sensor platform allows you to create a sensor with templated values
|
||||
using :ref:`lambdas <config-lambda>`.
|
||||
|
||||
.. code:: yaml
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
@ -45,7 +45,7 @@ Configuration variables:
|
||||
You can use the ``publish_state()`` method to set the value of a template
|
||||
sensor from other automations:
|
||||
|
||||
.. code:: cpp
|
||||
.. code-block:: cpp
|
||||
|
||||
id(my_sensor).publish_state(42.0);
|
||||
|
||||
|