mirror of
https://github.com/esphome/esphome-docs.git
synced 2025-01-13 20:11:53 +01:00
Jesse Hills
GitHub
commit
9945c49e4f
2
Doxygen
2
Doxygen
@ -38,7 +38,7 @@ PROJECT_NAME = "ESPHome"
|
||||
# could be handy for archiving the generated documentation or if some version
|
||||
# control system is used.
|
||||
|
||||
PROJECT_NUMBER = 2021.11.4
|
||||
PROJECT_NUMBER = 2021.12.0
|
||||
|
||||
# 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
|
||||
|
||||
2
Makefile
2
Makefile
@ -1,5 +1,5 @@
|
||||
ESPHOME_PATH = ../esphome
|
||||
ESPHOME_REF = 2021.11.4
|
||||
ESPHOME_REF = 2021.12.0
|
||||
|
||||
.PHONY: html html-strict cleanhtml deploy help webserver Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png minify
|
||||
|
||||
|
||||
BIN
_static/changelog-2021.12.0.png
Normal file
BIN
_static/changelog-2021.12.0.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
@ -1 +1 @@
|
||||
2021.11.4
|
||||
2021.12.0
|
||||
265
changelog/2021.12.0.rst
Normal file
265
changelog/2021.12.0.rst
Normal file
@ -0,0 +1,265 @@
|
||||
ESPHome 2021.12.0 - 11th December 2021
|
||||
======================================
|
||||
|
||||
.. seo::
|
||||
:description: Changelog for ESPHome 2021.12.0.
|
||||
:image: /_static/changelog-2021.12.0.png
|
||||
:author: ESPHome
|
||||
:author_twitter: @esphome_
|
||||
|
||||
.. imgtable::
|
||||
:columns: 3
|
||||
|
||||
Button Core, components/button/index, folder-open.svg
|
||||
Template Button, components/button/template, description.svg
|
||||
Restart Button, components/button/restart, restart.svg
|
||||
BLE Binary Output, components/output/ble_client, bluetooth.svg
|
||||
Tuya Text Sensor, components/text_sensor/tuya, tuya.png
|
||||
SDP800 Series, components/sensor/sdp3x, sdp31.jpg, Pressure
|
||||
|
||||
|
||||
State of the Open Smart Home
|
||||
----------------------------
|
||||
|
||||
Today is the `State of the Open Smart Home <https://www.home-assistant.io/state-of-the-open-home/>`__ hosted by Nabu Casa, Home Assistant & ESPHome
|
||||
and we’ll be joined by our friends from WLED, Z-Wave JS, Stanford’s OVAL lab and Northeastern University to talk about our work on making this vision a reality.
|
||||
|
||||
Where: YouTube
|
||||
|
||||
When: Today, Saturday, December 11, at 11am PST / 8pm CET
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/6ZMXE5PXPqU"
|
||||
title="YouTube video player" frameborder="0"
|
||||
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
|
||||
allowfullscreen>
|
||||
</iframe>
|
||||
|
||||
Buttons
|
||||
-------
|
||||
|
||||
This release brings :doc:`buttons </components/button/index>` from Home Assistant. Many times there have been questions on how to simply trigger automations
|
||||
from the Home Assistant frontend with a button so here you go. Here is a very simple example:
|
||||
|
||||
.. code:: yaml
|
||||
|
||||
button:
|
||||
- platform: template
|
||||
name: Test Button
|
||||
on_press:
|
||||
then:
|
||||
- logger.log: "The button was pressed!!!"
|
||||
|
||||
Multiple WiFi networks with static IP
|
||||
-------------------------------------
|
||||
|
||||
This release has a fix that allows using multiple networks each with their own static IP address configuration.
|
||||
When using these options, you **must** also set ``wifi`` -> ``use_address`` when installing new firmware as ESPHome
|
||||
cannot know which IP address to use automatically.
|
||||
|
||||
The Dashboard and secrets
|
||||
-------------------------
|
||||
|
||||
The ESPHome Dashboard will now save the wifi credentials as secrets (``wifi_ssid`` / ``wifi_password``) for future use. If you are already using these secrets,
|
||||
then the dashboard will not ask for credentials and will configure using them for you.
|
||||
|
||||
The dashboard also now can view the logs straight from a serial connected device via the web browser. It will show up as an option when choosing the method to
|
||||
view them.
|
||||
|
||||
NEC remote protocol
|
||||
-------------------
|
||||
|
||||
In this version, the order of transferring bits was corrected from MSB to LSB in accordance with the NEC standard.
|
||||
Therefore, if the the configuration file has come from an earlier version of ESPhome, it is necessary to reverse
|
||||
the order of the address and command bits when moving to 2021.12 or above.
|
||||
For example, address: ``0x84ED``, command: ``0x13EC`` becomes ``0xB721`` and ``0x37C8`` respectively.
|
||||
|
||||
Tuya Covers
|
||||
-----------
|
||||
|
||||
:esphomepr:`2637` adds new functionality to the Tuya cover component, but at the same time removes the "soft"
|
||||
inversion of the direction. Instead, it seems that most if not all tuya covers have a "hidden" datapoint that
|
||||
sets the direction on the secondary MCU. See the :doc:`documentation </components/cover/tuya>` for the new
|
||||
configuration options.
|
||||
|
||||
|
||||
Full list of changes
|
||||
--------------------
|
||||
|
||||
New Features
|
||||
^^^^^^^^^^^^
|
||||
|
||||
- pmsx003: add support for new PMS5003S device :esphomepr:`2710` by :ghuser:`NeoAcheron` (new-feature)
|
||||
- Add climate on_state trigger :esphomepr:`2707` by :ghuser:`dudanov` (new-feature)
|
||||
- Add greeyac protocol to IR Climate / HeatpumpIR :esphomepr:`2694` by :ghuser:`cmroche` (new-feature)
|
||||
- Provide an option to select unique_id generator :esphomepr:`2701` by :ghuser:`kbialek` (new-feature)
|
||||
- Ignore secrets yaml on command line :esphomepr:`2715` by :ghuser:`cvwillegen` (new-feature)
|
||||
- Add max_telegram_length option to dsmr :esphomepr:`2674` by :ghuser:`mmakaay` (new-feature)
|
||||
- Relax the icon validator to allow non-mdi icons :esphomepr:`2764` by :ghuser:`paulmonigatti` (new-feature)
|
||||
- Add support for P1 Data Request pin control :esphomepr:`2676` by :ghuser:`mmakaay` (new-feature)
|
||||
- Add support for sdp8xx :esphomepr:`2779` by :ghuser:`martgras` (new-feature)
|
||||
- Add map filter for text sensors :esphomepr:`2761` by :ghuser:`oxan` (new-feature)
|
||||
- Optionally show internal components on the web server :esphomepr:`2627` by :ghuser:`mechanarchy` (new-feature)
|
||||
- cse7766: add energy sensor :esphomepr:`2822` by :ghuser:`ianchi` (new-feature)
|
||||
- Allow Git credentials to be loaded from secrets :esphomepr:`2825` by :ghuser:`mechanarchy` (new-feature)
|
||||
- Expand uart invert feature to ESP8266 :esphomepr:`1727` by :ghuser:`Lewn` (new-feature)
|
||||
|
||||
New Components
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
- Add ble_client binary_output :esphomepr:`2200` by :ghuser:`tekmaven` (new-integration)
|
||||
- Add support for button entities :esphomepr:`2824` by :ghuser:`jesserockz` (new-integration)
|
||||
|
||||
Breaking Changes
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
- Fix NEC protocol implementation :esphomepr:`2534` by :ghuser:`dudanov` (breaking-change)
|
||||
- Tuya Cover improvements :esphomepr:`2637` by :ghuser:`pauln` (breaking-change)
|
||||
|
||||
Beta Changes
|
||||
^^^^^^^^^^^^
|
||||
|
||||
- Feed watchdog during OTA :esphomepr:`2852` by :ghuser:`oxan`
|
||||
- Bump esphome-dashboard to 20211206.0 :esphomepr:`2870` by :ghuser:`jesserockz`
|
||||
- tlc59208f : fix compilation error :esphomepr:`2867` by :ghuser:`martgras`
|
||||
- ADC: Turn verbose the debugging "got voltage" :esphomepr:`2863` by :ghuser:`CarlosGS`
|
||||
- SPS30 : fix i2c read size :esphomepr:`2866` by :ghuser:`martgras`
|
||||
- Fix MCP23x17 not disabling pullup after config change :esphomepr:`2855` by :ghuser:`oxan`
|
||||
- Ignore already stopped dhcp for ethernet :esphomepr:`2862` by :ghuser:`madron`
|
||||
- Add endpoint to fetch secrets keys :esphomepr:`2873` by :ghuser:`jesserockz`
|
||||
- Adopt using wifi secrets that should exist at this point :esphomepr:`2874` by :ghuser:`jesserockz`
|
||||
- Allow wizard to specify secrets :esphomepr:`2875` by :ghuser:`jesserockz`
|
||||
- Feed watchdog when no component loops :esphomepr:`2857` by :ghuser:`oxan`
|
||||
- Bump esphome-dashboard to 20211207.0 :esphomepr:`2877` by :ghuser:`jesserockz`
|
||||
- Feed watchdog while setting up OTA :esphomepr:`2876` by :ghuser:`CarlosGS`
|
||||
- Use new platform component config blocks for wizard :esphomepr:`2885` by :ghuser:`jesserockz`
|
||||
- Bump esphome-dashboard to 20211208.0 :esphomepr:`2887` by :ghuser:`jesserockz`
|
||||
- Fix published state for modbus number :esphomepr:`2894` by :ghuser:`jesserockz`
|
||||
- Modbus number/output use write single :esphomepr:`2896` by :ghuser:`glmnet`
|
||||
- Fix for two points setting when fan_only_cooling is disabled :esphomepr:`2903` by :ghuser:`kbx81`
|
||||
- Bump esphome-dashboard to 20211211.0 :esphomepr:`2904` by :ghuser:`jesserockz`
|
||||
|
||||
All changes
|
||||
^^^^^^^^^^^
|
||||
|
||||
- Defines tidy :esphomepr:`2696` by :ghuser:`jesserockz`
|
||||
- pmsx003: add support for new PMS5003S device :esphomepr:`2710` by :ghuser:`NeoAcheron` (new-feature)
|
||||
- Add climate on_state trigger :esphomepr:`2707` by :ghuser:`dudanov` (new-feature)
|
||||
- Add greeyac protocol to IR Climate / HeatpumpIR :esphomepr:`2694` by :ghuser:`cmroche` (new-feature)
|
||||
- Fix rom/rtc.h deprecation compile warning for debug component :esphomepr:`2520` by :ghuser:`mmakaay`
|
||||
- Drop unused constants from const.py :esphomepr:`2718` by :ghuser:`oxan`
|
||||
- Install test requirements in lint Docker image :esphomepr:`2719` by :ghuser:`oxan`
|
||||
- Clean-up MAC address helpers :esphomepr:`2713` by :ghuser:`oxan`
|
||||
- Provide an option to select unique_id generator :esphomepr:`2701` by :ghuser:`kbialek` (new-feature)
|
||||
- Ignore secrets yaml on command line :esphomepr:`2715` by :ghuser:`cvwillegen` (new-feature)
|
||||
- Allow for subsecond sampling of hmc5883l :esphomepr:`2735` by :ghuser:`jaharkes`
|
||||
- Change log level from DEBUG to INFO for sniffing services of `rf_bridge` :esphomepr:`2736` by :ghuser:`nagyrobi`
|
||||
- Add ble_client binary_output :esphomepr:`2200` by :ghuser:`tekmaven` (new-integration)
|
||||
- Remove duplicated const data in esp8266 boards :esphomepr:`2740` by :ghuser:`jesserockz`
|
||||
- Move to use improv lib from platformio :esphomepr:`2741` by :ghuser:`jesserockz`
|
||||
- Add max_telegram_length option to dsmr :esphomepr:`2674` by :ghuser:`mmakaay` (new-feature)
|
||||
- Changed LUT for DKE epaper on ttgo t5 2.13inch to improve partial rfresh :esphomepr:`2475` by :ghuser:`spattinson`
|
||||
- Fix NEC protocol implementation :esphomepr:`2534` by :ghuser:`dudanov` (breaking-change)
|
||||
- Remove arduino dependency from hm3301 :esphomepr:`2745` by :ghuser:`martgras`
|
||||
- Add retry handler :esphomepr:`2721` by :ghuser:`martgras`
|
||||
- Introduce str_snprintf helper function :esphomepr:`2780` by :ghuser:`oxan`
|
||||
- Prettier date time display after time sync :esphomepr:`2778` by :ghuser:`cvwillegen`
|
||||
- Fix distorted gif frames when resizing :esphomepr:`2774` by :ghuser:`davet2001`
|
||||
- fixed wrong setup-usage tc9548a :esphomepr:`2766` by :ghuser:`andreashergert1984`
|
||||
- Relax the icon validator to allow non-mdi icons :esphomepr:`2764` by :ghuser:`paulmonigatti` (new-feature)
|
||||
- Bump black from 21.10b0 to 21.11b1 :esphomepr:`2760` by :ghuser:`dependabot[bot]`
|
||||
- Update aht10.cpp to address issue #1635 :esphomepr:`2675` by :ghuser:`krunkel`
|
||||
- Add support for P1 Data Request pin control :esphomepr:`2676` by :ghuser:`mmakaay` (new-feature)
|
||||
- Allow specifying the dashboard bind address :esphomepr:`2787` by :ghuser:`jesserockz`
|
||||
- remove LEDC_HIGH_SPEED_MODE for C3, S2, S3 :esphomepr:`2791` by :ghuser:`martgras`
|
||||
- Fix LEDC resolution calculation on ESP32-C3/S2/S3 :esphomepr:`2794` by :ghuser:`rsumner`
|
||||
- Add support for sdp8xx :esphomepr:`2779` by :ghuser:`martgras` (new-feature)
|
||||
- Allow empty UART debug: option, logging in hex format by default :esphomepr:`2771` by :ghuser:`mmakaay`
|
||||
- Bump pylint from 2.11.1 to 2.12.1 :esphomepr:`2798` by :ghuser:`dependabot[bot]`
|
||||
- Fix CI cache key for test3.yaml compile :esphomepr:`2757` by :ghuser:`oxan`
|
||||
- Drop obsolete comment from CI workflow file :esphomepr:`2758` by :ghuser:`oxan`
|
||||
- Cache virtualenv instead of pip cache between CI runs :esphomepr:`2759` by :ghuser:`oxan`
|
||||
- Add map filter for text sensors :esphomepr:`2761` by :ghuser:`oxan` (new-feature)
|
||||
- Only match GCC warnings from ESPHome source files in CI :esphomepr:`2756` by :ghuser:`oxan`
|
||||
- Correct constant for dynamic I2S bus in NeoPixelBus :esphomepr:`2797` by :ghuser:`oxan`
|
||||
- Consistently format errors in CI scripts :esphomepr:`2762` by :ghuser:`oxan`
|
||||
- Cancel previous workflows for PRs and branches :esphomepr:`2800` by :ghuser:`jesserockz`
|
||||
- total_daily_energy: allow to disable restore mode :esphomepr:`2795` by :ghuser:`ianchi`
|
||||
- Modbus_controller: Add custom command. :esphomepr:`2680` by :ghuser:`martgras`
|
||||
- Fix usage of deprecated climate method in anova :esphomepr:`2801` by :ghuser:`oxan`
|
||||
- Make clang-tidy suggest stdint.h int types :esphomepr:`2820` by :ghuser:`oxan`
|
||||
- Fixed data type inside fast_random_8() routine :esphomepr:`2818` by :ghuser:`anatoly-savchenkov`
|
||||
- Improve DSMR read timeout handling :esphomepr:`2699` by :ghuser:`mmakaay`
|
||||
- Optionally show internal components on the web server :esphomepr:`2627` by :ghuser:`mechanarchy` (new-feature)
|
||||
- Fix custom mode_state_topic :esphomepr:`2827` by :ghuser:`definitio`
|
||||
- Add support for button entities :esphomepr:`2824` by :ghuser:`jesserockz` (new-integration)
|
||||
- Tuya text_sensor and raw data usage :esphomepr:`1812` by :ghuser:`dentra`
|
||||
- Fix 8266 SPI Clock Polarity Setting :esphomepr:`2836` by :ghuser:`kbx81`
|
||||
- Fix too-broad matcher for custom CI script :esphomepr:`2829` by :ghuser:`oxan`
|
||||
- cse7766: add energy sensor :esphomepr:`2822` by :ghuser:`ianchi` (new-feature)
|
||||
- Burst read for BME280, to reduce spurious spikes :esphomepr:`2809` by :ghuser:`CarlosGS`
|
||||
- Bump aioesphomeapi from 10.2.0 to 10.6.0 :esphomepr:`2840` by :ghuser:`dependabot[bot]`
|
||||
- Button device class :esphomepr:`2835` by :ghuser:`jesserockz`
|
||||
- Implement unit_of_measurement for number component :esphomepr:`2804` by :ghuser:`puuu`
|
||||
- Number mode :esphomepr:`2838` by :ghuser:`jesserockz`
|
||||
- Bump esphome-dashboard to 20211201.0 :esphomepr:`2842` by :ghuser:`jesserockz`
|
||||
- Allow Git credentials to be loaded from secrets :esphomepr:`2825` by :ghuser:`mechanarchy` (new-feature)
|
||||
- Fix compile warning in Tuya automations :esphomepr:`2837` by :ghuser:`oxan`
|
||||
- Add problem matcher for Python formatting errors :esphomepr:`2833` by :ghuser:`oxan`
|
||||
- Fix CI check for Windows line endings :esphomepr:`2831` by :ghuser:`oxan`
|
||||
- Don't enable namespace comment clang-tidy check twice :esphomepr:`2830` by :ghuser:`oxan`
|
||||
- ESP32 Deep Sleep: correct level value :esphomepr:`2812` by :ghuser:`jhamhader`
|
||||
- Fix OTA updates on esp8266 by declaring arch_get_cpu_cycle_count IRAM_ATTR and HOT :esphomepr:`2843` by :ghuser:`Doridian`
|
||||
- Fix compilation using subprocesses :esphomepr:`2834` by :ghuser:`oxan`
|
||||
- Expand uart invert feature to ESP8266 :esphomepr:`1727` by :ghuser:`Lewn` (new-feature)
|
||||
- Support setting manual_ip under networks option :esphomepr:`2839` by :ghuser:`oxan`
|
||||
- Enable a bunch of clang-tidy checks :esphomepr:`2149` by :ghuser:`oxan`
|
||||
- Set ESP32 watchdog to loop task :esphomepr:`2846` by :ghuser:`oxan`
|
||||
- Tuya Cover improvements :esphomepr:`2637` by :ghuser:`pauln` (breaking-change)
|
||||
- Fix wifi not working with manual_ip using esp-idf :esphomepr:`2849` by :ghuser:`Maelstrom96`
|
||||
- modbus_controller: bugfix: enable overriding calculated register size :esphomepr:`2845` by :ghuser:`martgras`
|
||||
- Feed watchdog during OTA :esphomepr:`2852` by :ghuser:`oxan`
|
||||
- Bump esphome-dashboard to 20211206.0 :esphomepr:`2870` by :ghuser:`jesserockz`
|
||||
- tlc59208f : fix compilation error :esphomepr:`2867` by :ghuser:`martgras`
|
||||
- ADC: Turn verbose the debugging "got voltage" :esphomepr:`2863` by :ghuser:`CarlosGS`
|
||||
- SPS30 : fix i2c read size :esphomepr:`2866` by :ghuser:`martgras`
|
||||
- Fix MCP23x17 not disabling pullup after config change :esphomepr:`2855` by :ghuser:`oxan`
|
||||
- Ignore already stopped dhcp for ethernet :esphomepr:`2862` by :ghuser:`madron`
|
||||
- Add endpoint to fetch secrets keys :esphomepr:`2873` by :ghuser:`jesserockz`
|
||||
- Adopt using wifi secrets that should exist at this point :esphomepr:`2874` by :ghuser:`jesserockz`
|
||||
- Allow wizard to specify secrets :esphomepr:`2875` by :ghuser:`jesserockz`
|
||||
- Feed watchdog when no component loops :esphomepr:`2857` by :ghuser:`oxan`
|
||||
- Bump esphome-dashboard to 20211207.0 :esphomepr:`2877` by :ghuser:`jesserockz`
|
||||
- Feed watchdog while setting up OTA :esphomepr:`2876` by :ghuser:`CarlosGS`
|
||||
- Use new platform component config blocks for wizard :esphomepr:`2885` by :ghuser:`jesserockz`
|
||||
- Bump esphome-dashboard to 20211208.0 :esphomepr:`2887` by :ghuser:`jesserockz`
|
||||
- Fix published state for modbus number :esphomepr:`2894` by :ghuser:`jesserockz`
|
||||
- Modbus number/output use write single :esphomepr:`2896` by :ghuser:`glmnet`
|
||||
- Fix for two points setting when fan_only_cooling is disabled :esphomepr:`2903` by :ghuser:`kbx81`
|
||||
- Bump esphome-dashboard to 20211211.0 :esphomepr:`2904` by :ghuser:`jesserockz`
|
||||
|
||||
Past Changelogs
|
||||
---------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
2021.11.0
|
||||
2021.10.0
|
||||
2021.9.0
|
||||
2021.8.0
|
||||
v1.20.0
|
||||
v1.19.0
|
||||
v1.18.0
|
||||
v1.17.0
|
||||
v1.16.0
|
||||
v1.15.0
|
||||
v1.14.0
|
||||
v1.13.0
|
||||
v1.12.0
|
||||
v1.11.0
|
||||
v1.10.0
|
||||
v1.9.0
|
||||
v1.8.0
|
||||
v1.7.0
|
||||
@ -2,7 +2,7 @@ Changelog
|
||||
=========
|
||||
|
||||
.. redirect::
|
||||
:url: /changelog/2021.11.0.html
|
||||
:url: /changelog/2021.12.0.html
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
|
||||
@ -3,7 +3,7 @@ Native API Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the native ESPHome API for communication with Home Assistant.
|
||||
:image: server-network.png
|
||||
:image: server-network.svg
|
||||
:keywords: Native API, ESPHome, Home Assistant
|
||||
|
||||
The ESPHome native API is used to communicate with clients directly, with a highly-optimized
|
||||
|
||||
@ -3,7 +3,7 @@ ESP32 Bluetooth Low Energy Device
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up BLE binary sensors for the ESP32.
|
||||
:image: bluetooth.png
|
||||
:image: bluetooth.svg
|
||||
|
||||
The ``ble_presence`` binary sensor platform lets you track the presence of a
|
||||
Bluetooth Low Energy device.
|
||||
|
||||
@ -3,7 +3,7 @@ ESP32 Touch Pad
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the touch pad on the ESP32.
|
||||
:image: touch.png
|
||||
:image: touch.svg
|
||||
|
||||
.. _esp32-touch-component:
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ GPIO Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up GPIO binary sensors with ESPHome.
|
||||
:image: pin.png
|
||||
:image: pin.svg
|
||||
|
||||
The GPIO Binary Sensor platform allows you to use any input pin on your
|
||||
device as a binary sensor.
|
||||
|
||||
@ -3,7 +3,7 @@ Home Assistant Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Home Assistant binary sensors with ESPHome that import states from your Home Assistant instance.
|
||||
:image: home-assistant.png
|
||||
:image: home-assistant.svg
|
||||
|
||||
The ``homeassistant`` binary sensor platform allows you to create binary sensors that **import**
|
||||
states from your Home Assistant instance using the :doc:`native API </components/api>`.
|
||||
|
||||
@ -3,7 +3,7 @@ Binary Sensor Component
|
||||
|
||||
.. seo::
|
||||
:description: Information about the base representation of all binary sensors.
|
||||
:image: folder-open.png
|
||||
:image: folder-open.svg
|
||||
|
||||
With ESPHome you can use different types of binary sensors. They will
|
||||
automatically appear in the Home Assistant front-end and have several
|
||||
|
||||
@ -23,7 +23,16 @@ Configuration variables:
|
||||
- **address**: (**Required**, int): start address of the first register in a range
|
||||
- **bitmask** : some values are packed in a response. The bitmask is used to determined if the result is true or false
|
||||
- **skip_updates**: (*Optional*, int): By default all sensors of of a modbus_controller are updated together. For data points that don't change very frequently updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle
|
||||
- **force_new_range**: (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting `foce_new_range: true` enforces the start of a new range at that address.
|
||||
- **register_count**: (*Optional*, int): only required for uncommon response encodings or to :ref:`optimize modbus communications<modbus_register_count>`
|
||||
The number of registers this data point spans. Overrides the defaults determined by ``value_type``.
|
||||
If no value for ``register_count`` is provided, it is calculated based on the register type.
|
||||
|
||||
The default size for 1 register is 16 bits (1 Word). Some devices are not adhering to this convention and have registers larger than 16 bits. In this case ``register_count`` and ``response_size`` must be set. For example, if your modbus device uses 1 registers for a FP32 value instead the default of two set ``register_count: 1`` and ``response_size: 4``.
|
||||
- **response_size**: (*Optional*, int): Size of the response for the register in bytes. Defaults to register_count*2.
|
||||
- **force_new_range**: (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting ``force_new_range: true`` enforces the start of a new range at that address.
|
||||
- **custom_data** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_data`` is used ``address`` and ``register_type`` can't be used.
|
||||
custom data must contain all required bytes including the modbus device address. The crc is automatically calculated and appended to the command.
|
||||
See :ref:`modbus_custom_data` how to use ``custom_command``
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
|
||||
Lambda to be evaluated every update interval to get the new value of the sensor
|
||||
- **offset**: (*Optional*, int): not required for most cases
|
||||
|
||||
@ -3,7 +3,7 @@ Status Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MQTT status binary sensors.
|
||||
:image: server-network.png
|
||||
:image: server-network.svg
|
||||
|
||||
The Status Binary Sensor exposes the node state (if it’s connected to via MQTT/native API)
|
||||
for Home Assistant.
|
||||
|
||||
@ -3,7 +3,7 @@ Template Binary Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up template binary sensors.
|
||||
:image: description.png
|
||||
:image: description.svg
|
||||
|
||||
The ``template`` binary sensor platform allows you to define any :ref:`lambda template <config-lambda>`
|
||||
and construct a binary sensor out if it.
|
||||
|
||||
121
components/button/index.rst
Normal file
121
components/button/index.rst
Normal file
@ -0,0 +1,121 @@
|
||||
Button Component
|
||||
================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up button components in ESPHome.
|
||||
:image: folder-open.svg
|
||||
|
||||
ESPHome has support for components to create a button entity. A button entity is
|
||||
basically a momentary switch with no state and can be triggered by either YAML or
|
||||
the user/frontend.
|
||||
|
||||
.. note::
|
||||
|
||||
Home Assistant Core 2021.12 or higher is required for ESPHome button entities to work.
|
||||
|
||||
.. _config-button:
|
||||
|
||||
Base Button Configuration
|
||||
-------------------------
|
||||
|
||||
All buttons in ESPHome have a name and an optional icon.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example button configuration
|
||||
button:
|
||||
- platform: ...
|
||||
name: Livingroom Lazy Mood
|
||||
id: my_button
|
||||
|
||||
# Optional variables:
|
||||
icon: "mdi:emoticon-outline"
|
||||
on_press:
|
||||
- logger.log: "Button pressed"
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **name** (**Required**, string): The name for the button.
|
||||
- **icon** (*Optional*, icon): Manually set the icon to use for the button in the frontend.
|
||||
- **internal** (*Optional*, boolean): Mark this component as internal. Internal components will
|
||||
not be exposed to the frontend (like Home Assistant). Only specifying an ``id`` without
|
||||
a ``name`` will implicitly set this to true.
|
||||
- **disabled_by_default** (*Optional*, boolean): If true, then this entity should not be added to any client's frontend,
|
||||
(usually Home Assistant) without the user manually enabling it (via the Home Assistant UI).
|
||||
- **entity_category** (*Optional*, string): The category of the entity.
|
||||
See https://developers.home-assistant.io/docs/core/entity/#generic-properties
|
||||
for a list of available options. Set to ``""`` to remove the default entity category.
|
||||
- **device_class** (*Optional*, string): The device class for the button.
|
||||
See https://developers.home-assistant.io/docs/core/entity/button/#available-device-classes
|
||||
for a list of available options.
|
||||
|
||||
Automations:
|
||||
|
||||
- **on_press** (*Optional*, :ref:`Automation <automation>`): An automation to perform
|
||||
when the button is pressed. See :ref:`button-on_press`.
|
||||
|
||||
MQTT options:
|
||||
|
||||
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
|
||||
Button Automation
|
||||
-----------------
|
||||
|
||||
.. _button-on_press:
|
||||
|
||||
``on_press``
|
||||
************
|
||||
|
||||
This automation will be triggered when the button is pressed.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
button:
|
||||
- platform: template
|
||||
# ...
|
||||
on_press:
|
||||
then:
|
||||
- logger.log: Button Pressed
|
||||
|
||||
Configuration variables: see :ref:`Automation <automation>`.
|
||||
|
||||
.. _button-press_action:
|
||||
|
||||
``button.press`` Action
|
||||
***********************
|
||||
|
||||
This is an :ref:`Action <config-action>` for pressing a button in an Automation.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- button.press: my_button
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The ID of the button to set.
|
||||
|
||||
.. _button-lambda_calls:
|
||||
|
||||
lambda calls
|
||||
************
|
||||
|
||||
From :ref:`lambdas <config-lambda>`, you can press a button.
|
||||
|
||||
- ``press()``: Press the button.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
// Within lambda, press the button.
|
||||
id(my_button).press();
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :apiref:`button/button.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
*
|
||||
31
components/button/restart.rst
Normal file
31
components/button/restart.rst
Normal file
@ -0,0 +1,31 @@
|
||||
Restart Button
|
||||
==============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up buttons that can remotely reboot the ESP in ESPHome.
|
||||
:image: restart.svg
|
||||
|
||||
The ``restart`` button platform allows you to restart your node remotely
|
||||
through Home Assistant.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
button:
|
||||
- platform: restart
|
||||
name: "Living Room Restart"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **name** (**Required**, string): The name for the button.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Button <config-button>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/switch/restart`
|
||||
- :doc:`template`
|
||||
- :apiref:`restart/button/restart_button.h`
|
||||
- :ghedit:`Edit`
|
||||
32
components/button/template.rst
Normal file
32
components/button/template.rst
Normal file
@ -0,0 +1,32 @@
|
||||
Template Button
|
||||
===============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up template buttons that can execute arbitrary actions when pressed.
|
||||
:image: description.svg
|
||||
|
||||
The ``template`` button platform allows you to create simple buttons out of just actions. Once defined,
|
||||
it will automatically appear in Home Assistant as a button and can be controlled through the frontend.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
button:
|
||||
- platform: template
|
||||
name: "Template Button"
|
||||
on_press:
|
||||
- logger.log: Button Pressed
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **name** (**Required**, string): The name of the switch.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Button <config-button>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/guides/automations`
|
||||
- :doc:`/components/button/index`
|
||||
- :ghedit:`Edit`
|
||||
@ -5,7 +5,7 @@ CAN bus
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up an CAN bus in ESPHome
|
||||
:image: canbus.png
|
||||
:image: canbus.svg
|
||||
:keywords: CAN
|
||||
|
||||
Controller Area Network (CAN bus) is a serial bus protocol to connect individual systems and sensors
|
||||
|
||||
@ -3,7 +3,7 @@ Captive Portal
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the Captive Portal fallback mechanism in ESPHome.
|
||||
:image: wifi-strength-alert-outline.png
|
||||
:image: wifi-strength-alert-outline.svg
|
||||
|
||||
The captive portal component in ESPHome is a fallback mechanism for when connecting to the
|
||||
configured :doc:`WiFi <wifi>` fails.
|
||||
|
||||
@ -3,7 +3,7 @@ Bang Bang Climate Controller
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Bang Bang climate controllers with ESPHome.
|
||||
:image: air-conditioner.png
|
||||
:image: air-conditioner.svg
|
||||
|
||||
The ``bang_bang`` climate platform allows you to regulate a value with a
|
||||
`bang-bang controller <https://en.wikipedia.org/wiki/Bang%E2%80%93bang_control>`__ (also called hysteresis controller).
|
||||
|
||||
@ -3,7 +3,7 @@ Climate Component
|
||||
|
||||
.. seo::
|
||||
:description: Information about the base representation of all climate devices.
|
||||
:image: folder-open.png
|
||||
:image: folder-open.svg
|
||||
|
||||
ESPHome has support for climate devices. Climate devices can represent different types of
|
||||
hardware, but the defining factor is that climate devices have a settable target temperature
|
||||
@ -184,6 +184,21 @@ advanced stuff.
|
||||
// etc. see API reference
|
||||
call.perform();
|
||||
|
||||
.. _climate-on_state_trigger:
|
||||
|
||||
``climate.on_state`` Trigger
|
||||
******************************************************
|
||||
|
||||
This trigger is activated each time the state of the climate device is updated
|
||||
(for example, if the current temperature measurement or the mode set by the users changes).
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
climate:
|
||||
- platform: midea # or any other platform
|
||||
# ...
|
||||
on_state:
|
||||
- logger.log: "State updated!"
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
@ -3,7 +3,7 @@ IR Remote Climate
|
||||
|
||||
.. seo::
|
||||
:description: Controls a variety of compatible Climate devices via IR
|
||||
:image: air-conditioner-ir.png
|
||||
:image: air-conditioner-ir.svg
|
||||
|
||||
This climate component allows you to control compatible AC units by sending an infrared (IR)
|
||||
control signal, just as the unit's handheld remote controller would.
|
||||
@ -96,11 +96,23 @@ This platform utilises the library's generic one-size-fits-all API, which might
|
||||
|
||||
Additional configuration must be specified for this platform:
|
||||
|
||||
- **protocol** (**Required**, string): Choose one of Arduino-HeatpumpIR's supported protcols: ``aux``, ``ballu``, ``carrier_mca``, ``carrier_nqv``, ``daikin_arc417``, ``daikin_arc480``, ``daikin``, ``fuego``, ``fujitsu_awyz``, ``gree``, ``greeya``, ``greeyan``, ``hisense_aud``, ``hitachi``, ``hyundai``, ``ivt``, ``midea``, ``mitsubishi_fa``, ``mitsubishi_fd``, ``mitsubishi_fe``, ``mitsubishi_heavy_fdtc``, ``mitsubishi_heavy_zj``, ``mitsubishi_heavy_zm``, ``mitsubishi_heavy_zmp``, ``mitsubishi_heavy_kj``, ``mitsubishi_msc``, ``mitsubishi_msy``, ``mitsubishi_sez``, ``panasonic_ckp``, ``panasonic_dke``, ``panasonic_jke``, ``panasonic_lke``, ``panasonic_nke``, ``samsung_aqv``, ``samsung_fjm``, ``sharp``, ``toshiba_daiseikai``, ``toshiba``
|
||||
- **protocol** (**Required**, string): Choose one of Arduino-HeatpumpIR's supported protcols: ``aux``, ``ballu``, ``carrier_mca``, ``carrier_nqv``, ``daikin_arc417``, ``daikin_arc480``, ``daikin``, ``fuego``, ``fujitsu_awyz``, ``gree``, ``greeya``, ``greeyac``, ``greeyan``, ``hisense_aud``, ``hitachi``, ``hyundai``, ``ivt``, ``midea``, ``mitsubishi_fa``, ``mitsubishi_fd``, ``mitsubishi_fe``, ``mitsubishi_heavy_fdtc``, ``mitsubishi_heavy_zj``, ``mitsubishi_heavy_zm``, ``mitsubishi_heavy_zmp``, ``mitsubishi_heavy_kj``, ``mitsubishi_msc``, ``mitsubishi_msy``, ``mitsubishi_sez``, ``panasonic_ckp``, ``panasonic_dke``, ``panasonic_jke``, ``panasonic_lke``, ``panasonic_nke``, ``samsung_aqv``, ``samsung_fjm``, ``sharp``, ``toshiba_daiseikai``, ``toshiba``
|
||||
- **horizontal_default** (**Required**, string): What to default to when the AC unit's horizontal direction is *not* set to swing. Options are: ``left``, ``mleft``, ``middle``, ``mright``, ``right``, ``auto``
|
||||
- **vertical_default** (**Required**, string): What to default to when the AC unit's vertical direction is *not* set to swing. Options are: ``down``, ``mdown``, ``middle``, ``mup``, ``up``, ``auto``
|
||||
- **max_temperature** (**Required**, float): The maximum temperature that the AC unit supports being set to.
|
||||
- **min_temperature** (**Required**, float): The minimum temperature that the AC unit supports being set to.
|
||||
- **sensor** (*Optional*, :ref:`config-id`): The sensor that is used to measure the ambient temperature.
|
||||
|
||||
.. note::
|
||||
|
||||
- The ``greeyac`` protocol supports a feature Gree calls "I-Feel". The handheld remote control
|
||||
has a built-in temperature sensor and it will periodically transmit the temperature from this sensor to the
|
||||
AC unit. If a ``sensor`` is provided in the configuration with this model, the sensor's temperature will be
|
||||
transmitted to the ``greeyac`` device in the same manner as the original remote controller. How often the
|
||||
temperature is transmitted is determined by the ``update_interval`` assigned to the ``sensor``. Note that
|
||||
``update_interval`` must be less than 10 minutes or the ``greeyac`` device will revert to using its own
|
||||
internal temperature sensor; a value of 2 minutes seems to work well. See :doc:`/components/sensor/index`
|
||||
for more information.
|
||||
|
||||
.. _ir-receiver_id:
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Midea Air Conditioner
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a Midea climate device
|
||||
:image: air-conditioner.png
|
||||
:image: air-conditioner.svg
|
||||
|
||||
The ``midea`` component creates a Midea air conditioner climate device.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ PID Climate
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up PID climate controllers with ESPHome.
|
||||
:image: function.png
|
||||
:image: function.svg
|
||||
|
||||
The ``pid`` climate platform allows you to regulate a value with a
|
||||
`PID controller <https://en.wikipedia.org/wiki/PID_controller>`__.
|
||||
|
||||
@ -3,7 +3,7 @@ Thermostat Climate Controller
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Thermostat climate controllers with ESPHome.
|
||||
:image: air-conditioner.png
|
||||
:image: air-conditioner.svg
|
||||
|
||||
The ``thermostat`` climate platform allows you to control a climate control system in much the same manner as a
|
||||
physical thermostat. Its operation is similar to the :doc:`bang-bang <bang_bang>` controller; a sensor measures a value
|
||||
|
||||
@ -3,7 +3,7 @@ Tuya Climate
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a Tuya climate device.
|
||||
:image: air-conditioner.png
|
||||
:image: air-conditioner.svg
|
||||
|
||||
The ``tuya`` climate platform creates a climate device from a tuya component.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ AM43 Cover
|
||||
|
||||
.. seo::
|
||||
:description: Setting up AM43/BLE covers in ESPHome.
|
||||
:image: am43.png
|
||||
:image: am43.jpg
|
||||
|
||||
The ``am43`` cover platform allows you to control an AM43 based
|
||||
BLE cover motor. These devices are sold under various brands, such
|
||||
|
||||
@ -3,14 +3,14 @@ Current Based Cover
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up current-based covers in ESPHome.
|
||||
:image: window-open.jpg
|
||||
:image: window-open.svg
|
||||
|
||||
The ``current_based`` cover platform allows you to create covers with position control by using current
|
||||
sensors to detect the fully-open and fully-closed states. This is pretty useful when using motors with
|
||||
integrated mechanical endstops. During cover operation, the component monitors the current consumption
|
||||
to detect when the motor has stopped.
|
||||
sensors to detect the fully-open and fully-closed states. This is pretty useful when using motors with
|
||||
integrated mechanical endstops. During cover operation, the component monitors the current consumption
|
||||
to detect when the motor has stopped.
|
||||
|
||||
When fully open or close is requested, the corresponding relay will stay on until the current the motor is
|
||||
When fully open or close is requested, the corresponding relay will stay on until the current the motor is
|
||||
consuming goes below a certain amount. The amount of current needs to be specified in the configuration.
|
||||
|
||||
Open and close durations can be specified to allow ESPHome to approximate the current position of the cover.
|
||||
@ -19,14 +19,14 @@ Open and close durations can be specified to allow ESPHome to approximate the cu
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
This type of cover also provides safety features like current-based obstacle detection with automatic configurable
|
||||
rollback as well as relay malfunction detection: operation cancels if there's a current flowing in the opposite
|
||||
operation circuit (typically caused by welded relays).
|
||||
This type of cover also provides safety features like current-based obstacle detection with automatic configurable
|
||||
rollback as well as relay malfunction detection: operation cancels if there's a current flowing in the opposite
|
||||
operation circuit (typically caused by welded relays).
|
||||
|
||||
.. warning::
|
||||
|
||||
Depending on the cover and motor type, obstacles can physically damage the cover before being detectable.
|
||||
Verify your setup to ensure the current consumption will increase enough to be detectable before causing
|
||||
Depending on the cover and motor type, obstacles can physically damage the cover before being detectable.
|
||||
Verify your setup to ensure the current consumption will increase enough to be detectable before causing
|
||||
any physical damage. Use it at your own risk.
|
||||
|
||||
.. code-block:: yaml
|
||||
@ -56,7 +56,7 @@ operation circuit (typically caused by welded relays).
|
||||
|
||||
obstacle_rollback: 30%
|
||||
start_sensing_delay: 0.8s
|
||||
|
||||
|
||||
|
||||
|
||||
Configuration variables:
|
||||
@ -68,32 +68,32 @@ Configuration variables:
|
||||
be performed when the remote requests the cover to be opened.
|
||||
- **open_duration** (**Required**, :ref:`config-time`): The amount of time it takes the cover
|
||||
to open up from the fully-closed state.
|
||||
- **open_moving_current_threshold** (**Required**, float): The amount of current in Amps the motor
|
||||
should drain to consider the cover is opening.
|
||||
- **open_obstacle_current_threshold** (**Required**, float): The amount of current in Amps the motor
|
||||
- **open_moving_current_threshold** (**Required**, float): The amount of current in Amps the motor
|
||||
should drain to consider the cover is opening.
|
||||
- **open_obstacle_current_threshold** (**Required**, float): The amount of current in Amps the motor
|
||||
should drain to consider the cover is blocked during opening.
|
||||
- **close_sensor** (**Required**, :ref:`config-id`): The close current sensor.
|
||||
- **close_action** (*Optional*, :ref:`Action <config-action>`): The action that should
|
||||
be performed when the remote requests the cover to be closed.
|
||||
- **close_duration** (**Required**, :ref:`config-time`): The amount of time it takes the cover
|
||||
to close from the fully-open state.
|
||||
- **close_moving_current_threshold** (**Required**, float): The amount of current in Amps the motor
|
||||
- **close_moving_current_threshold** (**Required**, float): The amount of current in Amps the motor
|
||||
should drain to consider the cover is closing.
|
||||
- **close_obstacle_current_threshold** (**Required**, float): The amount of current in Amps the motor
|
||||
- **close_obstacle_current_threshold** (**Required**, float): The amount of current in Amps the motor
|
||||
should drain to consider the cover is blocked during closing.
|
||||
- **stop_action** (**Required**, :ref:`Action <config-action>`): The action that should
|
||||
be performed to stop the cover.
|
||||
- **max_duration** (*Optional*, :ref:`config-time`): The maximum duration the cover should be opening
|
||||
or closing. Useful for protecting from dysfunctional motor integrated endstops.
|
||||
- **start_sensing_delay** (*Optional*, :ref:`config-time`): The amount of time the current sensing will be
|
||||
disabled when the movement starts. Motors can take some time before reaching their average consumption.
|
||||
Low values can cause an immediate stop because of the first current reading happening in the current-rising period.
|
||||
- **start_sensing_delay** (*Optional*, :ref:`config-time`): The amount of time the current sensing will be
|
||||
disabled when the movement starts. Motors can take some time before reaching their average consumption.
|
||||
Low values can cause an immediate stop because of the first current reading happening in the current-rising period.
|
||||
Defaults to ``500ms``.
|
||||
- **obstacle_rollback** (*Optional*, percentage): The percentage of rollback the cover will perform in case of
|
||||
- **obstacle_rollback** (*Optional*, percentage): The percentage of rollback the cover will perform in case of
|
||||
obstacle detection. Defaults to ``10%``.
|
||||
- **malfunction_detection** (*Optional*, boolean): Enable to detect malfunction detection (Tipically welded realys). Defaults to ``True``.
|
||||
- **malfunction_action** (*Optional*, :ref:`Action <config-action>`): The action that should
|
||||
be performed when relay malfunction is detected. Malfunction may require device servicing. You can use this action
|
||||
be performed when relay malfunction is detected. Malfunction may require device servicing. You can use this action
|
||||
to notify other systems about this situation
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Cover <config-cover>`.
|
||||
@ -101,25 +101,21 @@ Configuration variables:
|
||||
Use with Shelly 2.5
|
||||
-------------------
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up current-based covers in ESPHome using a Shelly 2.5.
|
||||
:image: shelly2.5.png
|
||||
|
||||
The Shelly 2.5 is the perfect hardware for this platform. It features two outputs with current monitoring
|
||||
(thanks to an embedded :doc:`ADE7953 </components/sensor/ade7953>`) in a very small form factor (39mm x 36mm x 17 mm).
|
||||
(thanks to an embedded :doc:`ADE7953 </components/sensor/ade7953>`) in a very small form factor (39mm x 36mm x 17 mm).
|
||||
It also features an :doc:`NTC temperature sensor </components/sensor/ntc>`.
|
||||
|
||||
.. figure:: images/shelly2.5.png
|
||||
:align: center
|
||||
:width: 30.0%
|
||||
|
||||
These devices typically run hot (~55Cº at 20ºC room temperature). Long-term heavy loads (near to its rated limit) can overheat the device.
|
||||
It is strongly recommended to monitor the device temperature using the NTC temperature sensor, shutting down the device if it exceeds 90ºC.
|
||||
These devices typically run hot (~55Cº at 20ºC room temperature). Long-term heavy loads (near to its rated limit) can overheat the device.
|
||||
It is strongly recommended to monitor the device temperature using the NTC temperature sensor, shutting down the device if it exceeds 90ºC.
|
||||
This safety feature is also present in the original firmware.
|
||||
|
||||
.. warning::
|
||||
|
||||
The ADE7953 IRQ line is connected to the GPIO16. The ``irq_pin`` parameter for the :doc:`ADE7953 </components/sensor/ade7953>` MUST be
|
||||
The ADE7953 IRQ line is connected to the GPIO16. The ``irq_pin`` parameter for the :doc:`ADE7953 </components/sensor/ade7953>` MUST be
|
||||
set to GPIO16 to prevent device overheat (>70ºC idling).
|
||||
|
||||
Configuration example:
|
||||
@ -135,7 +131,7 @@ Configuration example:
|
||||
i2c:
|
||||
sda: GPIO12
|
||||
scl: GPIO14
|
||||
|
||||
|
||||
sensor:
|
||||
- platform: ade7953
|
||||
irq_pin: GPIO16
|
||||
@ -153,7 +149,7 @@ Configuration example:
|
||||
id: close_current
|
||||
internal: true
|
||||
update_interval: 0.5s
|
||||
|
||||
|
||||
# NTC Temperature
|
||||
- platform: ntc
|
||||
sensor: temp_resistance_reading
|
||||
@ -164,7 +160,7 @@ Configuration example:
|
||||
b_constant: 3350
|
||||
reference_resistance: 10kOhm
|
||||
reference_temperature: 298.15K
|
||||
on_value_range:
|
||||
on_value_range:
|
||||
above: 90
|
||||
then: # Security shutdown by overheating
|
||||
- switch.turn_on: _shutdown
|
||||
@ -182,7 +178,7 @@ Configuration example:
|
||||
internal: true
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
- platform: gpio
|
||||
pin:
|
||||
number: GPIO13
|
||||
name: Shelly 2.5 Open Button
|
||||
@ -243,8 +239,8 @@ Configuration example:
|
||||
malfunction_detection: true
|
||||
malfunction_action:
|
||||
then:
|
||||
- logger.log: "Malfunction detected. Relay welded."
|
||||
|
||||
- logger.log: "Malfunction detected. Relay welded."
|
||||
|
||||
|
||||
|
||||
status_led:
|
||||
|
||||
@ -3,7 +3,7 @@ Endstop Cover
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up time-based covers in ESPHome.
|
||||
:image: electric-switch.png
|
||||
:image: electric-switch.svg
|
||||
|
||||
The ``endstop`` cover platform allows you to create covers with position control that have
|
||||
endstops at both ends of the cover to detect the fully-open and fully-closed states.
|
||||
|
||||
@ -3,7 +3,7 @@ Cover Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up base covers in ESPHome.
|
||||
:image: folder-opn.png
|
||||
:image: folder-open.svg
|
||||
|
||||
The ``cover`` component is a generic representation of covers in ESPHome.
|
||||
A cover can (currently) either be *closed* or *open* and supports three types of
|
||||
|
||||
@ -3,7 +3,7 @@ Template Cover
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up template covers in ESPHome.
|
||||
:image: description.png
|
||||
:image: description.svg
|
||||
|
||||
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
|
||||
|
||||
@ -3,7 +3,7 @@ Time-Based Cover
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up time-based covers in ESPHome.
|
||||
:image: timer.png
|
||||
:image: timer.svg
|
||||
|
||||
The ``time_based`` cover platform allows you to create covers with position control that do not
|
||||
have any position feedback. The state of the cover is thus always an assumed one, the current
|
||||
|
||||
@ -29,7 +29,7 @@ the config and it will list the possible devices for you in the config log.
|
||||
# Make sure you can upload new firmware OTA
|
||||
ota:
|
||||
|
||||
# My dimmer used the hardware serial port on the alternate pins
|
||||
# My cover used the hardware serial port on the alternate pins
|
||||
uart:
|
||||
rx_pin: GPIO13
|
||||
tx_pin: GPIO15
|
||||
@ -38,7 +38,7 @@ the config and it will list the possible devices for you in the config log.
|
||||
# Register the Tuya MCU connection
|
||||
tuya:
|
||||
|
||||
Here is an example output for a Tuya dimmer:
|
||||
Here is an example output for a Tuya M515EGWT (motor for chain roller blinds):
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
@ -51,7 +51,7 @@ Now you can create the cover.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Create a cover using the dimmer
|
||||
# Create a cover using the datapoint from above
|
||||
cover:
|
||||
- platform: "tuya"
|
||||
name: "motor1"
|
||||
@ -62,13 +62,46 @@ Configuration variables:
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **name** (**Required**, string): The name of the cover.
|
||||
- **control_datapoint** (*Optional*, int): The datapoint id number for sending control commands.
|
||||
- **position_datapoint** (**Required**, int): The datapoint id number of the cover position value.
|
||||
- **position_report_datapoint** (*Optional*, int): The datapoint id number of the cover position report value, if separate from position_datapoint.
|
||||
- **direction_datapoint** (*Optional*, int): The datapoint id number for setting the direction of travel.
|
||||
- **min_value** (*Optional*, int): The lowest position value, meaning cover closed. Defaults to 0.
|
||||
- **max_value** (*Optional*, int): the highest position value, meaning cover opened. Defaults to 255.
|
||||
- **invert_position** (*Optional*, boolean): invert the meaning of ``min_value`` and ``max_value``.
|
||||
When set to ``true``, ``min_value`` will mean opened and ``max_value`` is closed.
|
||||
- **invert_position** (*Optional*, boolean): Sets the direction of travel to be inverted, if direction_datapoint is configured.
|
||||
- All other options from :ref:`Cover <config-cover>`.
|
||||
|
||||
Supported devices
|
||||
-----------------
|
||||
|
||||
Tuya cover devices known to be supported by this integration:
|
||||
|
||||
- Tuya ``M515EGWT`` (motor for bead chain roller blinds)
|
||||
|
||||
- Only the ``position`` datapoint (2) is used for this device.
|
||||
- Datapoint 5's function is not currently known.
|
||||
|
||||
- Zemismart ``ZM79E-DT`` (curtain motor)
|
||||
|
||||
- Supported datapoints: ``control`` (1), ``position`` (2), ``position_report`` (3) and ``direction`` (5).
|
||||
- The direction of travel is persisted to the Tuya MCU, so doesn't need to be set if you've already configured it via the remote control.
|
||||
|
||||
If you have a Tuya cover device that isn't listed above, it may still work - but you'll need to determine which datapoints it uses
|
||||
(and what their IDs are) for yourself.
|
||||
|
||||
Restore modes
|
||||
-------------
|
||||
|
||||
The default restore mode (``RESTORE``) attempts to restore the state on startup, but doesn't instruct the cover to move to that state.
|
||||
|
||||
``RESTORE_AND_CALL`` additionally instructs the cover to move to the restored state - which might not work, depending on your device (see note below).
|
||||
|
||||
The Tuya MCU usually reports its position on startup, so ``NO_RESTORE`` will likely also appear to restore its state - but may take slightly longer.
|
||||
|
||||
Note that if your Tuya cover device uses relative position sensing (such as the ZM79E-DT), it can't tell if the cover was moved while not powered up.
|
||||
This means that moving the cover while the device is powered off will result in its position not matching the reported/requested state.
|
||||
In this condition, it will go into an error / uncalibrated state when it next tries to go in one direction (as it can't move as far as it wants to), requiring an open/close cycle to recalibrate.
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
@ -77,4 +110,3 @@ See Also
|
||||
- :doc:`/components/cover/index`
|
||||
- :apiref:`tuya/cover/tuya_cover.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Debug Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the debug component in ESPHome
|
||||
:image: bug-report.png
|
||||
:image: bug-report.svg
|
||||
|
||||
The ``debug`` component can be used to debug problems with ESPHome. At startup, it prints
|
||||
a bunch of useful information like reset reason, free heap size, ESPHome version and so on.
|
||||
|
||||
@ -5,7 +5,7 @@ Deep Sleep Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the deep sleep support for minimizing power consumption on ESPs.
|
||||
:image: hotel.png
|
||||
:image: hotel.svg
|
||||
|
||||
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
|
||||
|
||||
@ -3,7 +3,7 @@ Demo Integration
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the demo integration in ESPHome
|
||||
:image: description.png
|
||||
:image: description.svg
|
||||
|
||||
The ``demo`` integration can be used for testing to generate sample instances of many
|
||||
different integrations (sensors, lights, ...)
|
||||
|
||||
@ -3,7 +3,7 @@ DF-Player mini
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up DF Player Mini integration in ESPHome.
|
||||
:image: crosshair-gps.png
|
||||
:image: dfplayer.svg
|
||||
|
||||
The ``dfplayer`` (`datasheet <https://wiki.dfrobot.com/DFPlayer_Mini_SKU_DFR0299>`__), component
|
||||
allows you to play sound and music stored in an SD card or USB flash drive.
|
||||
|
||||
@ -3,7 +3,7 @@ ILI9341 TFT LCD
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up ILI9341 TFT LCD display drivers.
|
||||
:image: ili9341-full.jpg
|
||||
:image: ili9341.jpg
|
||||
|
||||
.. _ili9341:
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Display Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the display integration.
|
||||
:image: folder-open.png
|
||||
:image: folder-open.svg
|
||||
|
||||
The ``display`` component houses ESPHome's powerful rendering and display
|
||||
engine. Fundamentally, there are these types of displays:
|
||||
|
||||
@ -4,7 +4,7 @@ ST7735 Display
|
||||
.. seo::
|
||||
:description: Instructions for setting up a ST7735 display drivers.
|
||||
:keywords: ST7735
|
||||
:image: ST7735.png
|
||||
:image: st7735.jpg
|
||||
|
||||
ST7735 Display Driver.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ ST7789V TFT LCD
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up ST7789V TFT LCD display drivers.
|
||||
:image: st7789v-full.jpg
|
||||
:image: st7789v.jpg
|
||||
|
||||
.. _st7789v:
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ ESP32 Platform
|
||||
|
||||
.. seo::
|
||||
:description: Configuration for the ESP32 platform for ESPHome.
|
||||
:image: esp32.png
|
||||
:image: esp32.svg
|
||||
|
||||
This component contains platform-specific options for the ESP32 platform.
|
||||
|
||||
@ -18,7 +18,7 @@ Configuration variables:
|
||||
|
||||
- **board** (**Required**, string): The PlatformIO board ID that should
|
||||
be used. Choose the appropriate board from
|
||||
`this list <https://platformio.org/boards?count=1000&filter%5Bplatform%5D=espressif32>`__.
|
||||
`this list <https://platformio.org/boards?count=1000&filter%5Bplatform%5D=espressif32>`__.
|
||||
*This only affects pin aliases, flash size and some internal settings*, if unsure choose a generic board.
|
||||
- **framework** (*Optional*): Options for the underlying framework used by ESPHome.
|
||||
See :ref:`esp32-arduino_framework` and :ref:`esp32-espidf_framework`.
|
||||
@ -42,7 +42,7 @@ This is the default framework for ESP32 chips at the moment.
|
||||
type: arduino
|
||||
version: 2.0.0
|
||||
|
||||
- **version** (*Optional*, string): The base framework version number to use, from
|
||||
- **version** (*Optional*, string): The base framework version number to use, from
|
||||
`ESP32 arduino releases <https://github.com/espressif/arduino-esp32/releases>`__. Defaults to ``recommended``. Additional values are:
|
||||
|
||||
- ``dev``: Use the latest commit from https://github.com/espressif/arduino-esp32, note this may break at any time
|
||||
@ -75,7 +75,7 @@ of the ESP32 like ESP32S2, ESP32S3, ESP32C3 and single-core ESP32 chips.
|
||||
advanced:
|
||||
ignore_efuse_mac_crc: false
|
||||
|
||||
- **version** (*Optional*, string): The base framework version number to use, from
|
||||
- **version** (*Optional*, string): The base framework version number to use, from
|
||||
`ESP32 ESP-IDF releases <https://github.com/espressif/esp-idf/releases>`__. Defaults to ``recommended``. Additional values are:
|
||||
|
||||
- ``dev``: Use the latest commit from https://github.com/espressif/esp-idf, note this may break at any time
|
||||
|
||||
@ -3,7 +3,7 @@ ESP32 Bluetooth Low Energy Beacon
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Bluetooth Low Energy iBeacons using the BLE feature on ESP32s.
|
||||
:image: bluetooth.png
|
||||
:image: bluetooth.svg
|
||||
|
||||
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
|
||||
|
||||
@ -3,7 +3,7 @@ ESP32 Bluetooth Low Energy Tracker Hub
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up ESP32 bluetooth low energy device trackers using ESPHome.
|
||||
:image: bluetooth.png
|
||||
:image: bluetooth.svg
|
||||
|
||||
The ``esp32_ble_tracker`` component creates a global hub so that you can track bluetooth low
|
||||
energy devices using your ESP32 node.
|
||||
|
||||
@ -3,7 +3,7 @@ ESP32 Camera Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the ESP32 Cameras in ESPHome
|
||||
:image: camera.png
|
||||
:image: camera.svg
|
||||
|
||||
The ``esp32_camera`` component allows you to use ESP32-based camera boards in ESPHome that
|
||||
directly integrate into Home Assistant through the native API.
|
||||
|
||||
@ -3,7 +3,7 @@ ESP32 Camera Web Server Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the ESP32 Camera Web Server in ESPHome
|
||||
:image: camera.png
|
||||
:image: camera.svg
|
||||
|
||||
The ``esp32_camera_web_server`` component allows you to use expose web server of
|
||||
ESP32-based camera boards in ESPHome that directly can be integrated into external
|
||||
|
||||
@ -3,7 +3,7 @@ ESP8266 Platform
|
||||
|
||||
.. seo::
|
||||
:description: Configuration for the ESP8266 platform for ESPHome.
|
||||
:image: esp8266.png
|
||||
:image: esp8266.svg
|
||||
|
||||
This component contains platform-specific options for the ESP8266 platform.
|
||||
|
||||
@ -20,11 +20,11 @@ Configuration variables:
|
||||
|
||||
- **board** (**Required**, string): The PlatformIO board ID that should
|
||||
be used. Choose the appropriate board from
|
||||
`this list <https://platformio.org/boards?count=1000&filter%5Bplatform%5D=espressif8266>`__.
|
||||
`this list <https://platformio.org/boards?count=1000&filter%5Bplatform%5D=espressif8266>`__.
|
||||
*This only affects pin aliases, flash size and some internal settings*, if unsure choose a generic board.
|
||||
- **framework** (*Optional*): Options for the underlying framework used by ESPHome.
|
||||
|
||||
- **version** (*Optional*, string): The base framework version number to use, from
|
||||
- **version** (*Optional*, string): The base framework version number to use, from
|
||||
`esp8266 arduino releases <https://github.com/esp8266/Arduino/releases>`__. Defaults to ``recommended``. Additional values
|
||||
|
||||
- ``dev``: Use the latest commit from https://github.com/esp8266/Arduino, note this may break at any time
|
||||
|
||||
@ -3,7 +3,7 @@ ESPHome Core Configuration
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the core ESPHome configuration.
|
||||
:image: cloud-circle.png
|
||||
:image: cloud-circle.svg
|
||||
|
||||
Here you specify some core information that ESPHome needs to create
|
||||
firmwares. Most importantly, this is the section of the configuration
|
||||
|
||||
@ -3,7 +3,7 @@ Ethernet Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the Ethernet configuration for your ESP32 node in ESPHome.
|
||||
:image: ethernet.png
|
||||
:image: ethernet.svg
|
||||
:keywords: Ethernet, ESP32
|
||||
|
||||
This core ESPHome component sets up ethernet connections for ESP32s.
|
||||
|
||||
@ -42,6 +42,8 @@ Configuration variables:
|
||||
|
||||
- **url** (**Required**, url): HTTP git repository url. See :ref:`external-components_git`.
|
||||
- **ref** (*Optional*, string): Git ref (branch or tag). If not specified the default branch is used.
|
||||
- **username** (*Optional*, string): Username for the Git server, if one is required
|
||||
- **password** (*Optional*, string): Password for the Git server, if one is required
|
||||
|
||||
local options:
|
||||
|
||||
@ -182,6 +184,12 @@ folder and components will then be loaded from this local copy. The local path o
|
||||
varies per repository name and ref name, so repositories with different refs are considered different
|
||||
repositories and updated independently.
|
||||
|
||||
If required, you can supply a username and password to use when authenticating with the remote git
|
||||
server using the ``username`` and ``password`` fields. This is most useful when combined with the
|
||||
``!secret`` feature, to load the values in from a ``secrets.yaml`` file. This is not a comprehensive
|
||||
security measure; your username and password will necessarily be stored in clear text within the
|
||||
``.esphome`` directory.
|
||||
|
||||
.. _external-components_refresh:
|
||||
|
||||
Refresh
|
||||
|
||||
@ -3,7 +3,7 @@ Binary Fan
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up binary fans.
|
||||
:image: fan.png
|
||||
:image: fan.svg
|
||||
|
||||
The ``binary`` fan platform lets you represent any binary :ref:`output` as a fan.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ H-bridge Fan
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up hbridge controlled fans (or motors).
|
||||
:image: fan.png
|
||||
:image: fan.svg
|
||||
|
||||
The `'hbridge`' fan platform allows you to use a compatible `h-bridge` (L298N, DRV8871, MX1508, BTS7960, L9110S, DRV8833, TB6612, etc.) to control a fan (or motor/solenoid).
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Fan Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the base fan component.
|
||||
:image: folder-open.png
|
||||
:image: folder-open.svg
|
||||
|
||||
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
|
||||
|
||||
@ -3,7 +3,7 @@ Speed Fan
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up speed-controllable fans.
|
||||
:image: fan.png
|
||||
:image: fan.svg
|
||||
|
||||
The ``speed`` fan platform lets you represent any float :ref:`output` as a fan that
|
||||
supports speed settings.
|
||||
|
||||
@ -3,7 +3,7 @@ Grow Fingerprint Reader
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Grow Fingerprint Reader integration in ESPHome.
|
||||
:image: fingerprint.png
|
||||
:image: fingerprint.svg
|
||||
|
||||
The ``fingerprint_grow`` component allows you to use your R307, R503, ZFM-20, ... fingerprint sensors with ESPHome.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ GPS Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up GPS integration in ESPHome.
|
||||
:image: crosshair-gps.png
|
||||
:image: crosshairs-gps.svg
|
||||
|
||||
The ``gps`` component allows you to connect GPS modules to your ESPHome project.
|
||||
Any GPS module that uses the standardized NMEA communication protocol will work.
|
||||
|
||||
@ -3,7 +3,7 @@ HTTP Request
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up HTTP Requests in ESPHome
|
||||
:image: connection.png
|
||||
:image: connection.svg
|
||||
:keywords: http, request
|
||||
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ I²C Bus
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the I²C bus to communicate with 2-wire devices in ESPHome
|
||||
:image: i2c.png
|
||||
:image: i2c.svg
|
||||
:keywords: i2c, iic, bus
|
||||
|
||||
This component sets up the I²C bus for your ESP32 or ESP8266. In order for these components
|
||||
|
||||
@ -14,6 +14,7 @@ Components
|
||||
select/index
|
||||
sensor/index
|
||||
switch/index
|
||||
button/index
|
||||
display/index
|
||||
text_sensor/index
|
||||
stepper/index
|
||||
|
||||
@ -3,7 +3,7 @@ Binary Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up binary ON/OFF lights in ESPHome.
|
||||
:image: lightbulb.png
|
||||
:image: lightbulb.svg
|
||||
|
||||
The ``binary`` light platform creates a simple ON/OFF-only light from a
|
||||
:ref:`binary output component <output>`.
|
||||
|
||||
@ -3,7 +3,7 @@ Color Temperature Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Color Temperature lights.
|
||||
:image: brightness-medium.png
|
||||
:image: brightness-medium.svg
|
||||
|
||||
The ``color_temperature`` light platform creates a Color Temperature
|
||||
light from 2 :ref:`float output components <output>`. One channel controls the LED temperature,
|
||||
|
||||
@ -3,7 +3,7 @@ Cold White + Warm White Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Cold White + Warm White lights.
|
||||
:image: brightness-medium.png
|
||||
:image: brightness-medium.svg
|
||||
|
||||
The ``cwww`` light platform creates a cold white + warm white light from 2
|
||||
:ref:`float output components <output>` (one for each channel). The two channels
|
||||
|
||||
@ -3,7 +3,7 @@ FastLED Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up FastLED addressable lights like NEOPIXEL.
|
||||
:image: color_lens.png
|
||||
:image: color_lens.svg
|
||||
|
||||
.. _fastled-clockless:
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ H-bridge Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a hbridge light.
|
||||
:image: brightness-medium.png
|
||||
:image: brightness-medium.svg
|
||||
|
||||
The ``hbridge`` light platform creates a dual color brightness controlled light from two
|
||||
:ref:`float output component <output>`.
|
||||
|
||||
@ -3,7 +3,7 @@ Light Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up lights and light effects in ESPHome.
|
||||
:image: folder-open.png
|
||||
:image: folder-open.svg
|
||||
|
||||
The ``light`` domain in ESPHome lets you create lights that will
|
||||
automatically be shown in Home Assistant’s frontend and have many
|
||||
|
||||
@ -3,7 +3,7 @@ Monochromatic Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up monochromatic (brightness-only) lights.
|
||||
:image: brightness-medium.png
|
||||
:image: brightness-medium.svg
|
||||
|
||||
The ``monochromatic`` light platform creates a simple brightness-only light from an
|
||||
:ref:`float output component <output>`.
|
||||
|
||||
@ -3,7 +3,7 @@ NeoPixelBus Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Neopixel addressable lights.
|
||||
:image: color_lens.png
|
||||
:image: color_lens.svg
|
||||
|
||||
The ``neopixelbus`` light platform allows you to create RGB lights
|
||||
in ESPHome for an individually addressable lights like NeoPixel or WS2812.
|
||||
|
||||
@ -3,7 +3,7 @@ Light Partition
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up light partitions.
|
||||
:image: color_lens.png
|
||||
:image: color_lens.svg
|
||||
|
||||
The ``partition`` light platform allows you to combine multiple addressable light segments
|
||||
(like :doc:`fastled` or :doc:`neopixelbus`) and/or individual lights (like :doc:`rgb`) into a single addressable light.
|
||||
|
||||
@ -3,14 +3,14 @@ Status LED Light
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a Status LED shared also as binary ON/OFF light in ESPHome.
|
||||
:image: led-on.png
|
||||
:image: led-on.svg
|
||||
|
||||
The ``status_led`` light platform allows to share a single LED for indicating the status of
|
||||
the device (when on error/warning state) or as binary light (when on OK state).
|
||||
the device (when on error/warning state) or as binary light (when on OK state).
|
||||
This is useful for devices with only one LED available.
|
||||
|
||||
It provides the combined functionality of :doc:`status_led component </components/status_led>` and a
|
||||
:doc:`binary light component </components/light/binary>` over a single shared GPIO led.
|
||||
It provides the combined functionality of :doc:`status_led component </components/status_led>` and a
|
||||
:doc:`binary light component </components/light/binary>` over a single shared GPIO led.
|
||||
|
||||
When the device is on error/warning state, the function of ``status_led`` will take precedence and control the blinking of the LED.
|
||||
When the device is in OK state, the LED will be restored to the state of the ``binary light`` function and can be controlled as such.
|
||||
@ -26,7 +26,7 @@ When the device is in OK state, the LED will be restored to the state of the ``b
|
||||
.. note::
|
||||
|
||||
When using this platform the high level ``status_led`` component should not be included (at least over the same pin),
|
||||
as its functionality is directly provided by this platform.
|
||||
as its functionality is directly provided by this platform.
|
||||
|
||||
The only difference is that the platform won't be loaded in OTA safe mode, while the component would be.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Tuya Dimmer
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a Tuya dimmer switch.
|
||||
:image: brightness-medium.png
|
||||
:image: brightness-medium.svg
|
||||
|
||||
The ``tuya`` light platform creates a simple brightness-only light from a
|
||||
tuya serial component.
|
||||
|
||||
@ -3,7 +3,7 @@ Logger Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the central logging component in ESPHome.
|
||||
:image: file-document-box.png
|
||||
:image: file-document-box.svg
|
||||
|
||||
The logger component automatically logs all log messages through the
|
||||
serial port and through MQTT topics. By default, all logs with a
|
||||
|
||||
@ -3,7 +3,7 @@ MCP230xx I/O Expander
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MCP23008, MCP23016 or MCP23017 digital port expander in ESPHome.
|
||||
:image: mcp230xx.png
|
||||
:image: mcp230xx.svg
|
||||
|
||||
The Microchip MCP230xx series of general purpose, parallel I/O expansion for I²C bus applications.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ MCP23Sxx I/O Expander
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MCP23S08, MCP23S16 or MCP23S17 digital port expander in ESPHome. This is exactly the same API as the MCP23SXX I/O Expander except talks on the SPI bus
|
||||
:image: mcp23Sxx.png
|
||||
:image: mcp230xx.svg
|
||||
|
||||
The Microchip MCP23Sxx series of general purpose, parallel I/O expansion for SPI bus applications.
|
||||
This is exactly the same API as the MCP23SXX I/O Expander except talks on the SPI bus
|
||||
|
||||
@ -3,7 +3,7 @@ mDNS Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the mDNS configuration for your ESP node in ESPHome.
|
||||
:image: mdns.svg
|
||||
:image: radio-tower.svg
|
||||
:keywords: WiFi, WLAN, ESP8266, ESP32, mDNS
|
||||
|
||||
The ``mdns`` component makes the node announce itself on the local network using the multicast DNS (mDNS) protocol.
|
||||
|
||||
@ -7,10 +7,6 @@ Modbus Controller
|
||||
|
||||
The ``modbus_controller`` component creates a RS485 connection to control a modbus device
|
||||
|
||||
.. warning::
|
||||
|
||||
If you are using the :doc:`logger` uart logging might interfere especially on esp8266. You can disable the uart logging with the ``baud_rate: 0`` option.
|
||||
|
||||
.. figure:: /images/modbus.png
|
||||
:align: center
|
||||
:width: 25%
|
||||
@ -29,6 +25,25 @@ See [How is this RS485 Module Working?](https://electronics.stackexchange.com/qu
|
||||
|
||||
The controller connects to the UART of the MCU. For ESP32 GPIO PIN 16 to TXD PIN 17 to RXD are the default ports but any other pins can be used as well . 3.3V to VCC and GND to GND.
|
||||
|
||||
.. note::
|
||||
|
||||
If you are using an ESP8266, serial logging may cause problems reading from UART. For best results, hardware serial is recommended. Software serial may not be able to read all received data if other components spend a lot of time in the ``loop()``.
|
||||
|
||||
For hardware serial only a limited set of pins can be used. Either ``tx_pin: GPIO1`` and ``rx_pin: GPIO3`` or ``tx_pin: GPIO15`` and ``rx_pin: GPIO13``.
|
||||
|
||||
The disadvantage of using the hardware uart is that you can't use serial logging because the serial logs would be sent to the modbus device and cause errors.
|
||||
|
||||
Serial logging can be disabled by setting ``baud_rate: 0``.
|
||||
|
||||
See :doc:`logger` for more details
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
logger:
|
||||
level: <level>
|
||||
baud_rate: 0
|
||||
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
@ -42,8 +57,8 @@ Configuration variables:
|
||||
Because some modbus devices limit the rate of requests the interval between sending requests to the device can be modified.
|
||||
|
||||
|
||||
Getting started with Home Assistant
|
||||
-----------------------------------
|
||||
Example
|
||||
-------
|
||||
The following code create a modbus_controller hub talking to a modbus device at address 1 with 115200 bps
|
||||
|
||||
|
||||
|
||||
@ -43,6 +43,10 @@ Configuration variables:
|
||||
- **discovery_prefix** (*Optional*, string): The prefix to use for Home
|
||||
Assistant’s MQTT discovery. Should not contain trailing slash.
|
||||
Defaults to ``homeassistant``.
|
||||
- **discovery_unique_id_generator** (*Optional*, string): The unique_id generator
|
||||
to use. Can be one of ``legacy`` or ``mac``. Defaults to ``legacy``, which
|
||||
generates unique_id in format ``ESP<component_type><default_object_id>``.
|
||||
``mac`` generator uses format ``<mac_address>-<component_type>-<fnv1_hash(friendly_name)>``.
|
||||
- **use_abbreviations** (*Optional*, boolean): Whether to use
|
||||
`Abbreviations <https://www.home-assistant.io/docs/mqtt/discovery/>`__
|
||||
in discovery messages. Defaults to ``true``.
|
||||
|
||||
@ -3,7 +3,7 @@ Number Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up number components in ESPHome.
|
||||
:image: folder-open.png
|
||||
:image: folder-open.svg
|
||||
|
||||
ESPHome has support for components to create a number entity. A number entity is
|
||||
like a sensor that can read a value from a device, but is useful when that value
|
||||
@ -42,6 +42,12 @@ Configuration variables:
|
||||
See https://developers.home-assistant.io/docs/core/entity/#generic-properties
|
||||
for a list of available options. Requires Home Assistant 2021.11 or newer.
|
||||
Set to ``""`` to remove the default entity category.
|
||||
- **unit_of_measurement** (*Optional*, string): Manually set the unit
|
||||
of measurement for the number. Requires Home Assistant Core 2021.12 or newer.
|
||||
- **mode** (*Optional*, string): Defines how the number should be displayed in the frontend.
|
||||
See https://developers.home-assistant.io/docs/core/entity/number/#properties
|
||||
for a list of available options. Requires Home Assistant Core 2021.12 or newer.
|
||||
Defaults to ``"auto"``.
|
||||
|
||||
Automations:
|
||||
|
||||
|
||||
@ -3,7 +3,6 @@ Modbus Controller Number
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a modbus_controller device sensor.
|
||||
:image: modbus_controller.png
|
||||
|
||||
The ``modbus_controller`` platform creates a Number from a modbus_controller.
|
||||
When the Number is updated a modbus write command is created sent to the device.
|
||||
@ -19,32 +18,42 @@ Configuration variables:
|
||||
- read: Read Input Registers - registers are 16-bit registers used for input, and may only be read
|
||||
- **address**: (**Required**, int): start address of the first register in a range
|
||||
- **value_type**: (**Required**): datatype of the mod_bus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first)
|
||||
- U_WORD (unsigned float from 1 register =16bit
|
||||
- S_WORD (signed float from one register)
|
||||
- U_DWORD (unsigned float from 2 registers = 32bit)
|
||||
- S_DWORD (unsigned float from 2 registers = 32bit)
|
||||
- U_DWORD_R (unsigend float from 2 registers low word first )
|
||||
- S_DWORD_R (sigend float from 2 registers low word first )
|
||||
- U_QWORD (unsigned float from 4 registers = 64bit
|
||||
- S_QWORD (signed float from 4 registers = 64bit
|
||||
- U_QWORD_R (unsigend float from 4 registers low word first )
|
||||
- S_QWORD_R (sigend float from 4 registers low word first )
|
||||
- U_WORD (unsigned 16 bit integer from 1 register = 16bit)
|
||||
- S_WORD (signed 16 bit integer from 1 register = 16bit)
|
||||
- U_DWORD (unsigned 32 bit integer from 2 registers = 32bit)
|
||||
- S_DWORD (signed 32 bit integer from 2 registers = 32bit)
|
||||
- U_DWORD_R (unsigned 32 bit integer from 2 registers low word first)
|
||||
- S_DWORD_R (signed 32 bit integer from 2 registers low word first)
|
||||
- U_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
|
||||
- S_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
|
||||
- U_QWORD_R (unsigned 64 bit integer from 4 registers low word first)
|
||||
- U_QWORD_R signed 64 bit integer from 4 registers low word first)
|
||||
- FP32 (32 bit IEEE 754 floating point from 2 registers)
|
||||
- FP32_R (32 bit IEEE 754 floating point - same as FP32 but low word first)
|
||||
|
||||
- **skip_updates**: (*Optional*, int): By default all sensors of of a modbus_controller are updated together. For data points that don't change very frequently updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle
|
||||
Note: The modbus_controller groups component by address ranges to reduce number of transactions. All compoents with the same address will be updated in one request. skip_updates applies for all components in the same range.
|
||||
- **register_count**: (*Optional*): only required for uncommon response encodings
|
||||
The number of registers this data point spans. Default is 1
|
||||
- **force_new_range**: (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting `foce_new_range: true` enforces the start of a new range at that address.
|
||||
- **register_count**: (*Optional*): only required for uncommon response encodings or to :ref:`optimize modbus communications<modbus_register_count>`
|
||||
The number of registers this data point spans. Overrides the defaults determined by ``value_type``.
|
||||
If no value for ``register_count`` is provided, it is calculated based on the register type.
|
||||
|
||||
The default size for 1 register is 16 bits (1 Word). Some devices are not adhering to this convention and have registers larger than 16 bits. In this case ``register_count`` and ``response_size`` must be set. For example, if your modbus device uses 1 registers for a FP32 value instead the default of two set ``register_count: 1`` and ``response_size: 4``.
|
||||
- **response_size**: (*Optional*): Size of the response for the register in bytes. Defaults to register_count*2.
|
||||
- **force_new_range**: (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting ``force_new_range: true`` enforces the start of a new range at that address.
|
||||
- **offset**: (*Optional*, int): only required for uncommon response encodings
|
||||
offset from start address in bytes. If more than one register is read a modbus read registers command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type
|
||||
- **min_value** (*Optional*, float): The minimum value this number can be.
|
||||
- **max_value** (*Optional*, float): The maximum value this number can be.
|
||||
- **step** (*Optional*, float): The granularity with which the number can be set. Defaults to 1
|
||||
- **custom_data** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_data`` is used ``address`` and ``register_type`` can't be used.
|
||||
custom data must contain all required bytes including the modbus device address. The crc is automatically calculated and appended to the command.
|
||||
See :ref:`modbus_custom_data` how to use ``custom_command``
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
|
||||
Lambda to be evaluated every update interval to get the new value of the sensor.
|
||||
- **write_lambda** (*Optional*, :ref:`lambda <config-lambda>`): Lambda called before send.
|
||||
Lambda is evaluated before the modbus write command is created.
|
||||
- **multiply** (*Optional*, float): multiply the new value with this factor before sending the requests. Ignored if lambda is defined.
|
||||
- **use_write_multiple**: (*Optional*, boolean): By default the modbus command ``Preset Single Registers`` (function code 6) is used for setting the holding register if only 1 register is set. If your device only supports ``Preset Multiple Registers`` (function code 16) set this option to true.
|
||||
|
||||
|
||||
All other options from :ref:`Number <config-number>`.
|
||||
@ -54,7 +63,7 @@ Parameters passed into the lambda
|
||||
- **x** (float): The parsed float value of the modbus data
|
||||
|
||||
- **data** (std::vector<uint8_t): vector containing the complete raw modbus response bytes for this sensor
|
||||
note: because the response contains data for all registers in the same range you have to use `data[item->offset]` to get the first response byte for your sensor.
|
||||
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
|
||||
- **item** (const pointer to a SensorItem derived object): The sensor object itself.
|
||||
|
||||
Possible return values for the lambda:
|
||||
@ -69,7 +78,7 @@ Possible return values for the lambda:
|
||||
- **x** (float): The float value to be sent to the modbus device
|
||||
|
||||
- **payload** (`std::vector<uint16_t>&payload`): empty vector for the payload. The lamdba can add 16 bit raw modbus register words.
|
||||
note: because the response contains data for all registers in the same range you have to use `data[item->offset]` to get the first response byte for your sensor.
|
||||
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
|
||||
- **item** (const pointer to a SensorItem derived object): The sensor object itself.
|
||||
|
||||
Possible return values for the lambda:
|
||||
|
||||
@ -3,7 +3,7 @@ Template Number
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up template numbers with ESPHome.
|
||||
:image: description.png
|
||||
:image: description.svg
|
||||
|
||||
The ``template`` number platform allows you to create a number with templated values
|
||||
using :ref:`lambdas <config-lambda>`.
|
||||
|
||||
@ -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.png
|
||||
:image: system-update.svg
|
||||
|
||||
.. _config-ota:
|
||||
|
||||
|
||||
43
components/output/ble_client.rst
Normal file
43
components/output/ble_client.rst
Normal file
@ -0,0 +1,43 @@
|
||||
BLE Client Binary Output
|
||||
========================
|
||||
|
||||
.. seo::
|
||||
:description: Writes a binary value to a BLE device.
|
||||
:image: bluetooth.svg
|
||||
|
||||
The ``ble_client`` component is a output that can
|
||||
write a binary value to service characteristics of
|
||||
BLE devices.
|
||||
|
||||
For more information on BLE services and characteristics, see
|
||||
:doc:`/components/ble_client`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
esp32_ble_tracker:
|
||||
|
||||
ble_client:
|
||||
- mac_address: FF:FF:20:00:0F:15
|
||||
id: itag_black
|
||||
|
||||
output:
|
||||
- platform: ble_client
|
||||
ble_client_id: itag_black
|
||||
service_uuid: "10110000-5354-4F52-5A26-4249434B454C"
|
||||
characteristic_uuid: "10110013-5354-4f52-5a26-4249434b454c"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **ble_client_id** (**Required**, :ref:`config-id`): ID of the associated BLE client.
|
||||
- **service_uuid** (**Required**, UUID): UUID of the service on the device.
|
||||
- **characteristic_uuid** (**Required**, UUID): UUID of the service's characteristic to write to.
|
||||
- **id** (*Optional*, :ref:`config-id`): The ID to use for code generation, and for reference by dependent components.
|
||||
- All other options from :ref:`Output <config-output>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/output/index`
|
||||
- :doc:`/components/ble_client`
|
||||
- :ghedit:`Edit`
|
||||
@ -3,7 +3,7 @@ GPIO Output
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up binary outputs for GPIO pins.
|
||||
:image: pin.png
|
||||
:image: pin.svg
|
||||
|
||||
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
|
||||
|
||||
@ -5,7 +5,7 @@ Output Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up generic outputs in ESPHome
|
||||
:image: folder-open.png
|
||||
:image: folder-open.svg
|
||||
|
||||
Each platform of the ``output`` domain exposes some output to
|
||||
ESPHome. These are grouped into two categories: ``binary`` outputs
|
||||
|
||||
@ -3,7 +3,7 @@ MCP4725 Output
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MCP4725 outputs on the ESP.
|
||||
:image: mcp4725.png
|
||||
:image: mcp4725.jpg
|
||||
|
||||
The MCP4725 output component allows to use `12bit external DAC
|
||||
<https://learn.sparkfun.com/tutorials/mcp4725-digital-to-analog-converter-hookup-guide/all>`__
|
||||
|
||||
@ -3,7 +3,6 @@ Modbus Controller Output
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a modbus_controller device sensor.
|
||||
:image: modbus_controller.png
|
||||
|
||||
The ``modbus_controller`` platform creates a output from a modbus_controller.
|
||||
|
||||
@ -14,24 +13,27 @@ Configuration variables:
|
||||
- **name** (**Required**, string): The name of the sensor.
|
||||
- **address**: (**Required**, int): start address of the first register in a range
|
||||
- **value_type**: (**Required**): datatype of the mod_bus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first)
|
||||
- U_WORD (unsigned float from 1 register =16bit
|
||||
- S_WORD (signed float from one register)
|
||||
- U_DWORD (unsigned float from 2 registers = 32bit)
|
||||
- S_DWORD (unsigned float from 2 registers = 32bit)
|
||||
- U_DWORD_R (unsigend float from 2 registers low word first )
|
||||
- S_DWORD_R (sigend float from 2 registers low word first )
|
||||
- U_QWORD (unsigned float from 4 registers = 64bit
|
||||
- S_QWORD (signed float from 4 registers = 64bit
|
||||
- U_QWORD_R (unsigend float from 4 registers low word first )
|
||||
- S_QWORD_R (sigend float from 4 registers low word first )
|
||||
- U_WORD (unsigned 16 bit integer from 1 register = 16bit)
|
||||
- S_WORD (signed 16 bit integer from 1 register = 16bit)
|
||||
- U_DWORD (unsigned 32 bit integer from 2 registers = 32bit)
|
||||
- S_DWORD (signed 32 bit integer from 2 registers = 32bit)
|
||||
- U_DWORD_R (unsigned 32 bit integer from 2 registers low word first)
|
||||
- S_DWORD_R (signed 32 bit integer from 2 registers low word first)
|
||||
- U_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
|
||||
- S_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
|
||||
- U_QWORD_R (unsigned 64 bit integer from 4 registers low word first)
|
||||
- U_QWORD_R signed 64 bit integer from 4 registers low word first)
|
||||
- FP32 (32 bit IEEE 754 floating point from 2 registers)
|
||||
- FP32_R (32 bit IEEE 754 floating point - same as FP32 but low word first)
|
||||
- **register_count**: (*Optional*): only required for uncommon response encodings
|
||||
The number of registers this data point spans. Default is 1
|
||||
- **write_lambda** (*Optional*, :ref:`lambda <config-lambda>`):
|
||||
Lambda is evaluated before the modbus write command is created. The value is passed in as `float x` and an empty vector is passed in as `std::vector<uint16_t>&payload`
|
||||
Lambda is evaluated before the modbus write command is created. The value is passed in as ``float x`` and an empty vector is passed in as ``std::vector<uint16_t>&payload``
|
||||
You can directly define the payload by adding data to payload then the return value is ignored and the content of payload is used.
|
||||
- **multiply** (*Optional*, float): multiply the new value with this factor before sending the requests. Ignored if lambda is defined.
|
||||
- **offset**: (*Optional*, int): only required for uncommon response encodings
|
||||
offset from start address in bytes. If more than one register is read a modbus read registers command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type
|
||||
- **use_write_multiple**: (*Optional*, boolean): By default the modbus command ``Preset Single Registers`` (function code 6) is used for setting the holding register if only 1 register is set. If your device only supports ``Preset Multiple Registers`` (function code 16) set this option to true.
|
||||
|
||||
All other options from :ref:`Output <config-output>`.
|
||||
|
||||
@ -41,7 +43,7 @@ All other options from :ref:`Output <config-output>`.
|
||||
- **x** (float): The float value to be sent to the modbus device
|
||||
|
||||
- **payload** (`std::vector<uint16_t>&payload`): empty vector for the payload. The lamdba can add 16 bit raw modbus register words.
|
||||
note: because the response contains data for all registers in the same range you have to use `data[item->offset]` to get the first response byte for your sensor.
|
||||
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
|
||||
- **item** (const pointer to a SensorItem derived object): The sensor object itself.
|
||||
|
||||
Possible return values for the lambda:
|
||||
|
||||
@ -3,7 +3,7 @@ MY9231/MY9291 LED driver
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MY9231 and MY9291 LED drives in ESPHome.
|
||||
:image: my9231.png
|
||||
:image: my9231.svg
|
||||
:keywords: MY9231, MY9291, Sonoff B1, Ai-thinker AiLight WiFi light bulb, Arilux E27 Smart Bulb
|
||||
|
||||
.. _my9231-component:
|
||||
|
||||
@ -3,7 +3,7 @@ SM16716 LED driver
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up SM16716 LED drivers in ESPHome.
|
||||
:image: sm16716.png
|
||||
:image: sm16716.svg
|
||||
:keywords: SM16716, Feit Electric A19 Smart WiFi Bulb, Merkury Innovations A21 Smart Wi-Fi Bulb
|
||||
|
||||
.. _sm16716-component:
|
||||
|
||||
@ -3,7 +3,7 @@ Template Output
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up template outputs with ESPHome.
|
||||
:image: description.png
|
||||
:image: description.svg
|
||||
|
||||
The ``template`` output component can be used to create templated binary and float outputs in ESPHome.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ TLC5947 LED driver
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up TLC5947 LED drivers in ESPHome.
|
||||
:image: images/tlc5947.jpg
|
||||
:image: tlc5947.jpg
|
||||
:keywords: tlc5947,
|
||||
|
||||
.. _tlc5947-component:
|
||||
|
||||
@ -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.png
|
||||
:image: power.svg
|
||||
:keywords: power, ATX
|
||||
|
||||
The ``power_supply`` component allows you to have a high power mode for
|
||||
|
||||
@ -3,7 +3,7 @@ Prometheus Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a prometheus exporter with ESPHome.
|
||||
:image: prometheus.png
|
||||
:image: prometheus.svg
|
||||
|
||||
The ``prometheus`` component enables an HTTP endpoint for the
|
||||
:doc:`web_server` in order to integrate a `Prometheus <https://prometheus.io/>`__ installation.
|
||||
|
||||
@ -3,7 +3,7 @@ Remote Receiver
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up remote receiver binary sensors for infrared and RF codes.
|
||||
:image: remote.png
|
||||
:image: remote.svg
|
||||
:keywords: RF, infrared
|
||||
|
||||
The ``remote_receiver`` component lets you receive and decode any remote signal, these can
|
||||
@ -71,6 +71,13 @@ Automations:
|
||||
- **on_nec** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
|
||||
NEC remote code has been decoded. A variable ``x`` of type :apistruct:`remote_base::NECData`
|
||||
is passed to the automation for use in lambdas.
|
||||
|
||||
.. note::
|
||||
|
||||
In version 2021.12, the order of transferring bits was corrected from MSB to LSB in accordance with the NEC standard.
|
||||
Therefore, if the the configuration file has come from an earlier version of ESPhome, it is necessary to reverse the order of the address and command bits when moving to 2021.12 or above.
|
||||
For example, address: 0x84ED, command: 0x13EC becomes 0xB721 and 0x37C8 respectively.
|
||||
|
||||
- **on_sony** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
|
||||
Sony remote code has been decoded. A variable ``x`` of type :apistruct:`remote_base::SonyData`
|
||||
is passed to the automation for use in lambdas.
|
||||
@ -152,6 +159,12 @@ Remote code selection (exactly one of these has to be included):
|
||||
|
||||
- **nec**: Trigger on a decoded NEC remote code with the given data.
|
||||
|
||||
.. note::
|
||||
|
||||
In version 2021.12, the order of transferring bits was corrected from MSB to LSB in accordance with the NEC standard.
|
||||
Therefore, if the the configuration file has come from an earlier version of ESPhome, it is necessary to reverse the order of the address and command bits when moving to 2021.12 or above.
|
||||
For example, address: 0x84ED, command: 0x13EC becomes 0xB721 and 0x37C8 respectively.
|
||||
|
||||
- **address** (**Required**, int): The address to trigger on, see dumper output for more info.
|
||||
- **command** (**Required**, int): The NEC command to listen for.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Remote Transmitter
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up switches that send out pre-defined sequences of IR or RF signals
|
||||
:image: remote.png
|
||||
:image: remote.svg
|
||||
:keywords: Infrared, IR, RF, Remote, TX
|
||||
|
||||
The ``remote_transmitter`` component lets you send digital packets to control
|
||||
@ -183,6 +183,12 @@ Configuration variables:
|
||||
|
||||
This :ref:`action <config-action>` sends an NEC infrared remote code to a remote transmitter.
|
||||
|
||||
.. note::
|
||||
|
||||
In version 2021.12, the order of transferring bits was corrected from MSB to LSB in accordance with the NEC standard.
|
||||
Therefore, if the the configuration file has come from an earlier version of ESPhome, it is necessary to reverse the order of the address and command bits when moving to 2021.12 or above.
|
||||
For example, address: 0x84ED, command: 0x13EC becomes 0xB721 and 0x37C8 respectively.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
|
||||
@ -3,7 +3,7 @@ Rtttl Buzzer
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a buzzer to play tones and rtttl songs with ESPHome.
|
||||
:image: crosshair-gps.png
|
||||
:image: buzzer.jpg
|
||||
|
||||
The ``rtttl``, component allows you to easily connect a passive piezo buzzer to your microcontroller
|
||||
and play monophonic songs. It accepts the Ring Tone Text Transfer Language, rtttl format (`Wikipedia
|
||||
|
||||
@ -3,7 +3,7 @@ Select Component
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up select components in ESPHome.
|
||||
:image: folder-open.png
|
||||
:image: folder-open.svg
|
||||
|
||||
ESPHome has support for components to create a select entity. A select entity is
|
||||
basically an option list that can be set by either yaml, hardware or the user/frontend.
|
||||
|
||||
@ -3,7 +3,7 @@ Template Select
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Template Select(s) with ESPHome.
|
||||
:image: description.png
|
||||
:image: description.svg
|
||||
|
||||
The ``template`` Select platform allows you to create a Select with templated values
|
||||
using :ref:`lambdas <config-lambda>`.
|
||||
|
||||
@ -3,7 +3,7 @@ Analog To Digital Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up built-in analog voltage sensors.
|
||||
:image: flash.png
|
||||
:image: flash.svg
|
||||
|
||||
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
|
||||
|
||||
@ -3,7 +3,7 @@ ADE7953 Power Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up ADE7953 power sensors
|
||||
:image: ade7953.png
|
||||
:image: ade7953.svg
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ AM43 Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Sensors on AM43/BLE covers in ESPHome.
|
||||
:image: am43.png
|
||||
:image: am43.jpg
|
||||
|
||||
The ``am43`` sensor platform allows you to read the light and
|
||||
battery sensors on an AM43 BLE cover motor. The platform connects
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user