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

Merge branch 'current' into webserver-sorting

This commit is contained in:
RFDarter 2024-04-05 11:33:45 +02:00 committed by GitHub
parent f6e55e691f 6fa3868347
commit 9dbe08bb29
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
287 changed files with 11387 additions and 3834 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.github/workflows/docker.yml vendored
View File

@ -21,6 +21,9 @@ jobs:
-
name: Checkout source code
uses: actions/checkout@v4.1.0
-
name: Set up QEMU
uses: docker/setup-qemu-action@v3
-
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
@ -43,6 +46,7 @@ jobs:
with:
context: .
push: true
platforms: linux/amd64,linux/arm64
tags: |
esphome/esphome-docs:latest
ghcr.io/esphome/esphome-docs:latest

2
.github/workflows/lint.yml vendored
View File

@ -21,7 +21,7 @@ jobs:
steps:
- uses: actions/checkout@v4.1.0
- name: Set up Python 3.8
uses: actions/setup-python@v4
uses: actions/setup-python@v5
with:
python-version: 3.8
- name: Install dependencies

2
Doxygen
View File

@ -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 = 2023.11.6
PROJECT_NUMBER = 2024.3.1
# 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
View File

@ -1,5 +1,5 @@
ESPHOME_PATH = ../esphome
ESPHOME_REF = 2023.11.6
ESPHOME_REF = 2024.3.1
.PHONY: html html-strict cleanhtml deploy help live-html Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png minify

BIN
_static/changelog-2023.12.0.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 81 KiB

BIN
_static/changelog-2024.2.0.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 73 KiB

BIN
_static/changelog-2024.3.0.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 169 KiB

8
_static/custom.css
View File

@ -256,7 +256,7 @@ div.body p, div.body dd, div.body li, div.body blockquote {
background: #212121;
color: #ececec;
}
}
body, div.body {
@ -281,7 +281,7 @@ div.body p, div.body dd, div.body li, div.body blockquote {
color: #ececec;
background-color: #212121;
}
a, a.reference, a:visited {
color: #00bfff;
border-bottom: 1px dotted #00bfff;
@ -326,7 +326,7 @@ div.body p, div.body dd, div.body li, div.body blockquote {
color: #e2e2e2;
}
div.note, div.tip {
div.note, div.tip, div.important {
background-color: #2d2c2c;
border: 1px solid #808080;
}
@ -339,4 +339,4 @@ div.body p, div.body dd, div.body li, div.body blockquote {
background-color: #8e8129;
}
}
}

2
_static/version
View File

@ -1 +1 @@
2023.11.6
2024.3.1

2
_templates/layout.html
View File

@ -40,7 +40,7 @@
{% block footer %}
<div id="upgrade-footer">
A new version has been release since you last visited this page: {{ release }} 🎉
A new version has been released since you last visited this page: {{ release }} 🎉
<div class="footer-button-container">
<div role="button" id="upgrade-footer-dismiss" class="footer-button">Dismiss</div>
<a id="upgrade-footer-changelog" class="footer-button" href="/changelog/{{ version }}.0.html">View Changelog</a>

361
changelog/2023.12.0.rst Normal file
View File

@ -0,0 +1,361 @@
ESPHome 2023.12.0 - 20th December 2023
======================================
.. seo::
:description: Changelog for ESPHome 2023.12.0.
:image: /_static/changelog-2023.12.0.png
:author: Jesse Hills
:author_twitter: @jesserockz
.. imgtable::
:columns: 3
ENS160, components/sensor/ens160, ens160.jpg, CO2 & Air Quality
GT911, components/touchscreen/gt911, esp32_s3_box_3.png
Pylontech Batteries, components/pylontech, pylontech.jpg
HE60R Cover, components/cover/he60r, he60r.jpg
Graphical Display Menu, components/display_menu/graphical_display_menu, graphical_display_menu.jpg
FT63X6, components/touchscreen/ft63x6, wt32-sc01.png
A02YYUW, components/sensor/a02yyuw, a02yyuw.jpg
PN7150, components/binary_sensor/pn7150, pn7150.jpg
PN716X, components/binary_sensor/pn7160, pn716x.jpg
Graphical Menu
--------------
Following on from the previous :doc:`/components/display_menu/lcd_menu` that was only for LCD displays,
there is now a new :doc:`/components/display_menu/graphical_display_menu` that can be used with any
graphical/pixel based display.
Pin Reuse validation
--------------------
There is a new validation performed on configurations to ensure that pins are not reused unintentionally.
This is a common source of issues and generally a pin does not need to be reused across multiple components
in a single configuration. Pins should only be reused in a very limited set of circumstances and seeing the
error will generally mean that you need to reorganise your configuration to not reuse the pins.
The error can be bypassed by specifically adding another config item to all of the
duplicate pin definitions. See the :ref:`config-pin_schema` for details.
Touchscreen internal changes
----------------------------
The touchscreen compoenent code has had a big overhaul which breaks any external components or open PRs for
new touchscreens. See :esphomepr:`4596` for details if this affects you.
MCP3008 breaking changes
------------------------
The MCP3008 has has a restructure of the code and at the same time the default update interval has been changed to 60 seconds,
the units, device class and state class default have also been set to sane defaults expected for a voltage sensor.
Release 2023.12.1 - December 21
-------------------------------
- Fix replaced - in allowed characters during object_id sanitizing :esphomepr:`5983` by :ghuser:`jesserockz`
Release 2023.12.2 - December 22
-------------------------------
- ESP32-S3 and ESP-IDF don't play well with USB_CDC and need USB_SERIAL_JTAG :esphomepr:`5929` by :ghuser:`clydebarrow`
- Update libtiff6 :esphomepr:`5985` by :ghuser:`cvandesande`
- Override GPIOs 12 and 13 on the airm2m (LuatOS) board :esphomepr:`5982` by :ghuser:`davidmonro`
- Add workaround for crash in Arduino 2.0.9 when CDC is configured :esphomepr:`5987` by :ghuser:`kbx81`
- web_server.py: return empty content when file doesn't exist :esphomepr:`5980` by :ghuser:`jessicah`
Release 2023.12.3 - December 22
-------------------------------
- Fix unexpected disconnects when outgoing buffer is full during keepalive :esphomepr:`5988` by :ghuser:`bdraco`
- Regenerate api_pb2 after manual changes were added incorrectly in #5732 :esphomepr:`5990` by :ghuser:`jesserockz`
- Improved sensor readings in htu21d component. :esphomepr:`5839` by :ghuser:`matzman666`
- Fix dashboard logs when api is disabled and using MQTT :esphomepr:`5992` by :ghuser:`bdraco`
- Fix broken configs with non-existent components :esphomepr:`5993` by :ghuser:`jesserockz`
Release 2023.12.4 - December 25
-------------------------------
- dashboard: Only ping when polling is active :esphomepr:`6001` by :ghuser:`bdraco`
- tt21100: restore init read :esphomepr:`6008` by :ghuser:`nielsnl68`
- dashboard: Fix file writes on Windows :esphomepr:`6013` by :ghuser:`bdraco`
- Display: fix class inherence in Python script :esphomepr:`6009` by :ghuser:`nielsnl68`
Release 2023.12.5 - December 25
-------------------------------
- Fix docker builds :esphomepr:`6012` by :ghuser:`bdraco`
Release 2023.12.6 - January 15
------------------------------
- Fix device not requesting Home Assistant time at the update interval :esphomepr:`6022` by :ghuser:`bdraco`
- fix compilation error for libretiny :esphomepr:`6064` by :ghuser:`tomaszduda23`
- pylontech: Fix parsing error with US2000 :esphomepr:`6061` by :ghuser:`functionpointer`
- Support full (>460 char) dumps of Pronto IR commands :esphomepr:`6040` by :ghuser:`rpaskowitz`
- ESP32-C3 USB_CDC fixes :esphomepr:`6069` by :ghuser:`kbx81`
- Improv Serial -- don't wait for incoming bytes :esphomepr:`6089` by :ghuser:`kbx81`
- add STATE_CLASS_TOTAL_INCREASING to bl0940 and bl0942 :esphomepr:`6090` by :ghuser:`tomaszduda23`
- Fallback to pure-python loader for better error when YAML loading fails :esphomepr:`6081` by :ghuser:`bdraco`
Release 2023.12.7 - January 17
------------------------------
- Fix RMT timing clock base :esphomepr:`6101` by :ghuser:`majkrzak`
- Create RingBuffer for VoiceAssistant :esphomepr:`6102` by :ghuser:`jesserockz`
- Inkplate6: Fix crash with initial set of greyscale :esphomepr:`6038` by :ghuser:`clydebarrow`
Release 2023.12.8 - January 19
------------------------------
- Let show_*_page actions depend on "Display" :esphomepr:`6092` by :ghuser:`guillempages`
- Fix some Voice Assistant bugs :esphomepr:`6121` by :ghuser:`jesserockz`
Release 2023.12.9 - January 22
------------------------------
- fix sen5x negative temperature :esphomepr:`6082` by :ghuser:`ssieb`
- negative values for all DHT22 variants :esphomepr:`6074` by :ghuser:`ssieb`
- fix negative temperature for pmsx003 :esphomepr:`6083` by :ghuser:`ssieb`
- fix: negative temperatures on PMS5003T sensors :esphomepr:`6100` by :ghuser:`aschmitz`
Full list of changes
--------------------
New Components
^^^^^^^^^^^^^^
- Add ENS160 Sensor :esphomepr:`4243` by :ghuser:`vincentscode` (new-integration)
- Create GT911 Touchscreen component :esphomepr:`4027` by :ghuser:`jesserockz` (new-integration)
- Pylontech integration (solar battery bank) :esphomepr:`4688` by :ghuser:`functionpointer` (new-integration)
- Add Chamberlain/HomEntry HE60R garage door opener :esphomepr:`5834` by :ghuser:`clydebarrow` (new-integration)
- Add graphical display menu :esphomepr:`4105` by :ghuser:`MrMDavidson` (new-integration)
- Updating the touchscreen interface structure :esphomepr:`4596` by :ghuser:`nielsnl68` (new-integration) (breaking-change)
- Added the A02YYUW distance sensor :esphomepr:`5729` by :ghuser:`TH-Braemer` (new-integration)
- Add support for PN7160 :esphomepr:`5486` by :ghuser:`kbx81` (new-integration)
- Add support for PN7150 :esphomepr:`5487` by :ghuser:`kbx81` (new-integration)
Breaking Changes
^^^^^^^^^^^^^^^^
- Add proper support for SH1107 to SSD1306 component :esphomepr:`5166` by :ghuser:`nikitakuklev` (breaking-change)
- sen5x fix temperature compensation and gas tuning :esphomepr:`4901` by :ghuser:`matt7aylor` (breaking-change)
- Ensure names containing characters other than `a-z` `A-Z` `0-9` or `_` are unique :esphomepr:`5810` by :ghuser:`bdraco` (breaking-change)
- mcp3008: Tidy up and fix auto load bug :esphomepr:`5842` by :ghuser:`jesserockz` (breaking-change)
- Nextion colors parameters :esphomepr:`5699` by :ghuser:`edwardtfn` (breaking-change)
- Checks for pins used in multiple places :esphomepr:`5666` by :ghuser:`clydebarrow` (breaking-change)
- Updating the touchscreen interface structure :esphomepr:`4596` by :ghuser:`nielsnl68` (new-integration) (breaking-change)
Beta Changes
^^^^^^^^^^^^
- Allow use of CDC/JTAG loggers on esp32 variants with Arduino :esphomepr:`4658` by :ghuser:`jesserockz`
- [Logger] ESP32 S3 serial logger :esphomepr:`4853` by :ghuser:`Fabian-Schmidt`
- Support toggle action for template cover :esphomepr:`5917` by :ghuser:`jochenvg`
- Fix SplitDefault with variants :esphomepr:`5928` by :ghuser:`jesserockz`
- Update ENS160 TVOC device_class and AQI units to match required by HA :esphomepr:`5939` by :ghuser:`mrtoy-me`
- Bump zeroconf from 0.128.4 to 0.130.0 :esphomepr:`5950` by :ghuser:`dependabot[bot]`
- UARTComponent inline doc :esphomepr:`5930` by :ghuser:`edwardtfn`
- Fix - Tuya Fan - Allow integer speed datapoint :esphomepr:`5948` by :ghuser:`cram42`
- i2s_audio: Set player_task's prio to 1 :esphomepr:`5945` by :ghuser:`gaaf`
- esp32_camera: Set framebuffer task prio to 1 :esphomepr:`5943` by :ghuser:`gaaf`
- web_server_idf: fix call with hardcoded http code :esphomepr:`5942` by :ghuser:`dentra`
- Revert pure virtual functions in UART component from #5920 :esphomepr:`5932` by :ghuser:`DrCoolzic`
- Use the correct UART/`Serial` when CDC is enabled :esphomepr:`5957` by :ghuser:`kbx81`
- rename ``set_raw_touch_position_`` to ``add_raw_touch_position_`` :esphomepr:`5962` by :ghuser:`nielsnl68`
- Fix build issue with UART component when building with Arduino and CDC :esphomepr:`5964` by :ghuser:`kbx81`
- Fix ``I2CBus::write()`` bug and add i2c documentation :esphomepr:`5947` by :ghuser:`DrCoolzic`
- Add deep sleep between updates for waveshare epaper 1.54in and 1.54inv2 :esphomepr:`5961` by :ghuser:`mathieu-mp`
- Speed up writing protobuf strings/bytes :esphomepr:`5828` by :ghuser:`bdraco`
- Bump aioesphomeapi to 21.0.1 :esphomepr:`5969` by :ghuser:`bdraco`
- image: allow the image to by auto-loaded by animation :esphomepr:`5139` by :ghuser:`ayufan`
- Fix pin reuse error with pin expanders :esphomepr:`5973` by :ghuser:`jesserockz`
All changes
^^^^^^^^^^^
- Nextion support to ``esp-idf`` :esphomepr:`5667` by :ghuser:`edwardtfn`
- fix pin range for xl9535 :esphomepr:`5722` by :ghuser:`ssieb`
- Bump black from 23.10.1 to 23.11.0 :esphomepr:`5702` by :ghuser:`dependabot[bot]`
- Speed up YAML by using YAML C loader when available :esphomepr:`5721` by :ghuser:`bdraco`
- Bump Arduino Pico Framework to 3.6.0 and Platform to 1.10.0 :esphomepr:`5731` by :ghuser:`HeMan`
- Correct url for Arduino platform :esphomepr:`5744` by :ghuser:`HeMan`
- remote_base: added helper class and schemas :esphomepr:`5169` by :ghuser:`dudanov`
- Bump zeroconf from 0.123.0 to 0.126.0 :esphomepr:`5748` by :ghuser:`dependabot[bot]`
- Make precommit checks happy :esphomepr:`5751` by :ghuser:`HeMan`
- dashboard: Use mdns cache when available if device connection is OTA :esphomepr:`5724` by :ghuser:`bdraco`
- Speed up OTAs :esphomepr:`5720` by :ghuser:`bdraco`
- dashboard: convert ping thread to use asyncio :esphomepr:`5749` by :ghuser:`bdraco`
- dashboard: Break apart dashboard into separate modules :esphomepr:`5764` by :ghuser:`bdraco`
- dashboard: split dashboard web server code into its own module :esphomepr:`5770` by :ghuser:`bdraco`
- Bump zeroconf from 0.126.0 to 0.127.0 :esphomepr:`5768` by :ghuser:`dependabot[bot]`
- dashboard: fix subprocesses blocking the event loop :esphomepr:`5772` by :ghuser:`bdraco`
- dashboard: use fastest available yaml loader in the dashboard :esphomepr:`5771` by :ghuser:`bdraco`
- dashboard: Centralize dashboard entries into DashboardEntries class :esphomepr:`5774` by :ghuser:`bdraco`
- Pass the name to the log runner when available :esphomepr:`5759` by :ghuser:`bdraco`
- Add proper support for SH1107 to SSD1306 component :esphomepr:`5166` by :ghuser:`nikitakuklev` (breaking-change)
- Split release workflow jobs per system arch :esphomepr:`5723` by :ghuser:`jesserockz`
- Bump aioesphomeapi to 18.5.3 :esphomepr:`5785` by :ghuser:`bdraco`
- Refactor log api client to let aioesphomeapi manage zeroconf :esphomepr:`5783` by :ghuser:`bdraco`
- dashboard: Add support for firing events :esphomepr:`5775` by :ghuser:`bdraco`
- dashboard: Ensure disk I/O happens in the executor :esphomepr:`5789` by :ghuser:`bdraco`
- dashboard: Add lookup by name to entries :esphomepr:`5790` by :ghuser:`bdraco`
- Refactor StorageJSON to keep loaded_integrations a set until its converted to JSON :esphomepr:`5793` by :ghuser:`bdraco`
- wifi: Don't build SoftAP/DHCPS support unless 'ap' is in config. :esphomepr:`5649` by :ghuser:`kpfleming`
- ssd1306: handle V_COM differently for SH1106 :esphomepr:`5796` by :ghuser:`papillon81`
- Bump aioesphomeapi from 18.5.3 to 18.5.5 :esphomepr:`5804` by :ghuser:`dependabot[bot]`
- dashboard: Fix online status when api is disabled :esphomepr:`5792` by :ghuser:`bdraco`
- Haier component updated to support new protocol variations :esphomepr:`5713` by :ghuser:`paveldn`
- sen5x fix temperature compensation and gas tuning :esphomepr:`4901` by :ghuser:`matt7aylor` (breaking-change)
- Add startup_delay to interval. :esphomepr:`5327` by :ghuser:`clydebarrow`
- Pillow: bump to 10.1.0 :esphomepr:`5815` by :ghuser:`hostcc`
- dashboard: set nodelay on the websocket to avoid a delay seeing log messages :esphomepr:`5802` by :ghuser:`bdraco`
- Bump aioesphomeapi from 18.5.5 to 18.5.7 :esphomepr:`5822` by :ghuser:`dependabot[bot]`
- Ensure names containing characters other than `a-z` `A-Z` `0-9` or `_` are unique :esphomepr:`5810` by :ghuser:`bdraco` (breaking-change)
- Add ENS160 Sensor :esphomepr:`4243` by :ghuser:`vincentscode` (new-integration)
- Bump actions/github-script from 6.4.1 to 7.0.1 :esphomepr:`5803` by :ghuser:`dependabot[bot]`
- Run all tests when local testing. :esphomepr:`5717` by :ghuser:`Fabian-Schmidt`
- Bump aioesphomeapi from 18.5.7 to 18.5.9 :esphomepr:`5830` by :ghuser:`dependabot[bot]`
- Allow split uart pin inversion for ESP-IDF :esphomepr:`5831` by :ghuser:`clydebarrow`
- Add ``is_detected()`` for Nextion displays :esphomepr:`5825` by :ghuser:`edwardtfn`
- Pull PollingComponent up from individual display drivers to Display. :esphomepr:`5444` by :ghuser:`clydebarrow`
- Implement variable length single word SPI writes. :esphomepr:`5678` by :ghuser:`clydebarrow`
- Add 'enable_on_boot' feature to power_supply :esphomepr:`5826` by :ghuser:`clydebarrow`
- mcp3008: Tidy up and fix auto load bug :esphomepr:`5842` by :ghuser:`jesserockz` (breaking-change)
- Create GT911 Touchscreen component :esphomepr:`4027` by :ghuser:`jesserockz` (new-integration)
- Bump aioesphomeapi from 18.5.9 to 19.1.2 :esphomepr:`5844` by :ghuser:`dependabot[bot]`
- Nextion - Standardizing log messages :esphomepr:`5837` by :ghuser:`edwardtfn`
- dashboard: Small cleanups to dashboard :esphomepr:`5841` by :ghuser:`bdraco`
- Pylontech integration (solar battery bank) :esphomepr:`4688` by :ghuser:`functionpointer` (new-integration)
- Implement deep sleep and clear screen on Waveshare 7.5in B V3 :esphomepr:`5239` by :ghuser:`lucasprim`
- Fix ESP-IDF uart initialisation sequence to match Espressif docs. :esphomepr:`5838` by :ghuser:`clydebarrow`
- Nextion - Align strings on ``dump_config`` :esphomepr:`5824` by :ghuser:`edwardtfn`
- Speed up (and fix) ili9xxx display component. :esphomepr:`5406` by :ghuser:`clydebarrow`
- Fix regex for 'byte' custom CI check :esphomepr:`5851` by :ghuser:`jesserockz`
- Pass through additional arguments to create number :esphomepr:`5849` by :ghuser:`clydebarrow`
- Nextion ``on_touch`` trigger :esphomepr:`5833` by :ghuser:`edwardtfn`
- Nextion colors parameters :esphomepr:`5699` by :ghuser:`edwardtfn` (breaking-change)
- dashboard: fix supervisor auth doing I/O in the event loop :esphomepr:`5807` by :ghuser:`bdraco`
- Improve reliability of Nextion TFT uploads (Arduino) :esphomepr:`5683` by :ghuser:`edwardtfn`
- Add Pro Check Universal sensor support. :esphomepr:`5798` by :ghuser:`spbrogan`
- Bump aioesphomeapi from 19.1.2 to 19.1.7 :esphomepr:`5859` by :ghuser:`dependabot[bot]`
- Pn532 non blocking scan :esphomepr:`5191` by :ghuser:`sharkydog`
- Add Chamberlain/HomEntry HE60R garage door opener :esphomepr:`5834` by :ghuser:`clydebarrow` (new-integration)
- Bump aioesphomeapi from 19.1.7 to 19.2.1 :esphomepr:`5863` by :ghuser:`dependabot[bot]`
- Bump tornado from 6.3.3 to 6.4 :esphomepr:`5862` by :ghuser:`dependabot[bot]`
- add missing ifdef to pvvx_mithermometer :esphomepr:`5880` by :ghuser:`ssieb`
- Fix un-initialized version string :esphomepr:`5865` by :ghuser:`descipher`
- fix a01nyub data reading :esphomepr:`5882` by :ghuser:`ssieb`
- Bump pytest-asyncio from 0.21.1 to 0.23.2 :esphomepr:`5888` by :ghuser:`dependabot[bot]`
- Bump zeroconf from 0.127.0 to 0.128.0 :esphomepr:`5889` by :ghuser:`dependabot[bot]`
- Bump pylint from 2.17.6 to 3.0.2 :esphomepr:`5592` by :ghuser:`dependabot[bot]`
- Bump voluptuous from 0.13.1 to 0.14.1 :esphomepr:`5784` by :ghuser:`dependabot[bot]`
- Security improvement: Support wifi ap_timeout=0s (disable) :esphomepr:`5887` by :ghuser:`fornellas`
- Suppress full config output of "esphome config" when -q option is used. :esphomepr:`5852` by :ghuser:`clydebarrow`
- Checks for pins used in multiple places :esphomepr:`5666` by :ghuser:`clydebarrow` (breaking-change)
- Nextion support to idf with `cinttypes` :esphomepr:`5876` by :ghuser:`edwardtfn`
- Fix test4.yaml after #5666 :esphomepr:`5890` by :ghuser:`kbx81`
- Fix template text component length check :esphomepr:`5881` by :ghuser:`fornellas`
- RC522 - Fix error counter error :esphomepr:`5873` by :ghuser:`kbx81`
- feat(packages): support removing components :esphomepr:`5821` by :ghuser:`TMaYaD`
- dashboard: Add some basic tests for the dashboard :esphomepr:`5870` by :ghuser:`bdraco`
- Nextion exit reparse mode on startup :esphomepr:`5868` by :ghuser:`edwardtfn`
- Bump aioesphomeapi from 19.2.1 to 19.3.0 :esphomepr:`5895` by :ghuser:`dependabot[bot]`
- Add framework info to Nextion log tags :esphomepr:`5864` by :ghuser:`edwardtfn`
- Handle case where using enetity level name: None with MQTT :esphomepr:`5897` by :ghuser:`mtl010957`
- Bump actions/setup-python from 4.7.1 to 5.0.0 :esphomepr:`5896` by :ghuser:`dependabot[bot]`
- Bump zeroconf from 0.128.0 to 0.128.4 :esphomepr:`5906` by :ghuser:`dependabot[bot]`
- Fix 18 bit displays. :esphomepr:`5908` by :ghuser:`clydebarrow`
- fix RGBW Mode on RP2040 :esphomepr:`5907` by :ghuser:`firegore`
- Add graphical display menu :esphomepr:`4105` by :ghuser:`MrMDavidson` (new-integration)
- Added on_image callback to ESP32 Cam :esphomepr:`4860` by :ghuser:`freekode`
- Bump actions/stale from 8.0.0 to 9.0.0 :esphomepr:`5899` by :ghuser:`dependabot[bot]`
- Bump pylint from 3.0.2 to 3.0.3 :esphomepr:`5905` by :ghuser:`dependabot[bot]`
- Bump frenck/action-yamllint from 1.4.1 to 1.4.2 :esphomepr:`5716` by :ghuser:`dependabot[bot]`
- Bump dessant/lock-threads from 4.0.1 to 5.0.1 :esphomepr:`5820` by :ghuser:`dependabot[bot]`
- Add support for fan preset modes :esphomepr:`5694` by :ghuser:`mill1000`
- Fix uninitialized climate target temperature :esphomepr:`5795` by :ghuser:`ckoca`
- Bump aioesphomeapi from 19.3.0 to 20.0.0 :esphomepr:`5911` by :ghuser:`dependabot[bot]`
- Bump black from 23.11.0 to 23.12.0 :esphomepr:`5912` by :ghuser:`dependabot[bot]`
- Updating the touchscreen interface structure :esphomepr:`4596` by :ghuser:`nielsnl68` (new-integration) (breaking-change)
- Added the A02YYUW distance sensor :esphomepr:`5729` by :ghuser:`TH-Braemer` (new-integration)
- Fix AHT10 / AHT20 communication :esphomepr:`5198` by :ghuser:`flaminggoat`
- Fix crash when handling pin_check error :esphomepr:`5915` by :ghuser:`clydebarrow`
- Bump aioesphomeapi to 20.1.0 :esphomepr:`5914` by :ghuser:`bdraco`
- Remove setpoint-change from error when calculating derivative in pid controller :esphomepr:`4737` by :ghuser:`Newspaperman57`
- ir_transmitter: add support for repeated commands in NEC protocol :esphomepr:`4995` by :ghuser:`ngilles`
- BP1658CJ - Fix timing for all platforms, now consistent with other drivers :esphomepr:`5799` by :ghuser:`Cossid`
- Add humidity support to climate :esphomepr:`5732` by :ghuser:`kroimon`
- Remove lingering note :esphomepr:`5916` by :ghuser:`jesserockz`
- Fix typo added in esp32 post_build filename :esphomepr:`5918` by :ghuser:`jesserockz`
- Copy esp32 custom partition files to build folder :esphomepr:`5919` by :ghuser:`jesserockz`
- UART change at runtime :esphomepr:`5909` by :ghuser:`edwardtfn`
- Bump aioesphomeapi from 20.1.0 to 21.0.0 :esphomepr:`5922` by :ghuser:`dependabot[bot]`
- Fix the initial run of lambda light effects :esphomepr:`5921` by :ghuser:`smithjacobj`
- Exposes ``load_settings`` to `UARTComponent` class :esphomepr:`5920` by :ghuser:`edwardtfn`
- Add support for PN7160 :esphomepr:`5486` by :ghuser:`kbx81` (new-integration)
- Add support for PN7150 :esphomepr:`5487` by :ghuser:`kbx81` (new-integration)
- Allow use of CDC/JTAG loggers on esp32 variants with Arduino :esphomepr:`4658` by :ghuser:`jesserockz`
- [Logger] ESP32 S3 serial logger :esphomepr:`4853` by :ghuser:`Fabian-Schmidt`
- Support toggle action for template cover :esphomepr:`5917` by :ghuser:`jochenvg`
- Fix SplitDefault with variants :esphomepr:`5928` by :ghuser:`jesserockz`
- Update ENS160 TVOC device_class and AQI units to match required by HA :esphomepr:`5939` by :ghuser:`mrtoy-me`
- Bump zeroconf from 0.128.4 to 0.130.0 :esphomepr:`5950` by :ghuser:`dependabot[bot]`
- UARTComponent inline doc :esphomepr:`5930` by :ghuser:`edwardtfn`
- Fix - Tuya Fan - Allow integer speed datapoint :esphomepr:`5948` by :ghuser:`cram42`
- i2s_audio: Set player_task's prio to 1 :esphomepr:`5945` by :ghuser:`gaaf`
- esp32_camera: Set framebuffer task prio to 1 :esphomepr:`5943` by :ghuser:`gaaf`
- web_server_idf: fix call with hardcoded http code :esphomepr:`5942` by :ghuser:`dentra`
- Revert pure virtual functions in UART component from #5920 :esphomepr:`5932` by :ghuser:`DrCoolzic`
- Use the correct UART/`Serial` when CDC is enabled :esphomepr:`5957` by :ghuser:`kbx81`
- rename ``set_raw_touch_position_`` to ``add_raw_touch_position_`` :esphomepr:`5962` by :ghuser:`nielsnl68`
- Fix build issue with UART component when building with Arduino and CDC :esphomepr:`5964` by :ghuser:`kbx81`
- Fix I2CBus::write() bug and add i2c documentation :esphomepr:`5947` by :ghuser:`DrCoolzic`
- Add deep sleep between updates for waveshare epaper 1.54in and 1.54inv2 :esphomepr:`5961` by :ghuser:`mathieu-mp`
- Speed up writing protobuf strings/bytes :esphomepr:`5828` by :ghuser:`bdraco`
- Bump aioesphomeapi to 21.0.1 :esphomepr:`5969` by :ghuser:`bdraco`
- image: allow the image to by auto-loaded by animation :esphomepr:`5139` by :ghuser:`ayufan`
- Fix pin reuse error with pin expanders :esphomepr:`5973` by :ghuser:`jesserockz`
Past Changelogs
---------------
- :doc:`2023.11.0`
- :doc:`2023.10.0`
- :doc:`2023.9.0`
- :doc:`2023.8.0`
- :doc:`2023.7.0`
- :doc:`2023.6.0`
- :doc:`2023.5.0`
- :doc:`2023.4.0`
- :doc:`2023.3.0`
- :doc:`2023.2.0`
- :doc:`2022.12.0`
- :doc:`2022.11.0`
- :doc:`2022.10.0`
- :doc:`2022.9.0`
- :doc:`2022.8.0`
- :doc:`2022.6.0`
- :doc:`2022.5.0`
- :doc:`2022.4.0`
- :doc:`2022.3.0`
- :doc:`2022.2.0`
- :doc:`2022.1.0`
- :doc:`2021.12.0`
- :doc:`2021.11.0`
- :doc:`2021.10.0`
- :doc:`2021.9.0`
- :doc:`2021.8.0`
- :doc:`v1.20.0`
- :doc:`v1.19.0`
- :doc:`v1.18.0`
- :doc:`v1.17.0`
- :doc:`v1.16.0`
- :doc:`v1.15.0`
- :doc:`v1.14.0`
- :doc:`v1.13.0`
- :doc:`v1.12.0`
- :doc:`v1.11.0`
- :doc:`v1.10.0`
- :doc:`v1.9.0`
- :doc:`v1.8.0`
- :doc:`v1.7.0`

281
changelog/2024.2.0.rst Normal file
View File

@ -0,0 +1,281 @@
ESPHome 2024.2.0 - 21st February 2024
=====================================
.. seo::
:description: Changelog for ESPHome 2024.2.0.
:image: /_static/changelog-2024.2.0.png
:author: Jesse Hills
:author_twitter: @jesserockz
.. imgtable::
:columns: 4
micro Wake Word, components/micro_wake_word, voice-assistant.svg, dark-invert
AS5600, components/sensor/as5600, as5600.jpg
ST7567, components/display/st7567, st7567.jpg
BME280 SPI, components/sensor/bme280, bme280.jpg
VEML3235, components/sensor/veml3235, veml3235.jpg
Honeywell HIH I2C, components/sensor/honeywell_hih_i2c, honeywellhih.jpg
Combination, components/sensor/combination, function.svg, dark-invert
micro Wake Word
---------------
ESPHome implements an on-device wake word detection framework from `microWakeWord <https://github.com/kahrendt/microWakeWord>`__.
See the :doc:`component documentation </components/micro_wake_word>` for details on how to use it.
Check out the live stream replay below for more details about how it works and came to be.
.. raw:: html
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/NQIv3nsu7dE"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen>
</iframe>
BME280 changes
--------------
:ghuser:`apbodrov` has added support for the BME280 sensor over SPI. This change is a breaking change for any existing configurations using
the BME280 over I2C as the platform name has been changed from ``bme280`` to ``bme280_i2c``. There are no other configuration changes required
to continue using the BME280 over I2C. See the :doc:`component documentation </components/sensor/bme280>` for the latest configuration variables.
CSE7766 changes
---------------
:ghuser:`ssieb` has changed the CSE7766 sensor from appearing to be a polling component.
It has a high update rate, so if you don't want to send a lot of data to HA, you can
add the :ref:`throttle_average <sensor-filters>` filter
with the time period you were using for the update interval (the default is 60s) to each
sensor. The example in the sensor doc page has been updated to show this.
Release 2024.2.1 - February 26
------------------------------
- Add missing timeout to "async_request" :esphomepr:`6267` by :ghuser:`jesserockz`
- Bump zeroconf timeout to 3000 :esphomepr:`6270` by :ghuser:`jesserockz`
- web_server: Add a position property for cover entities that have the supports position trait :esphomepr:`6269` by :ghuser:`DanielBaulig`
- allow multiple emc2101 :esphomepr:`6272` by :ghuser:`ssieb`
- Fix RP2040 SPI pin validation :esphomepr:`6277` by :ghuser:`kbx81`
- dashboard: move storage json update to a background task in edit save :esphomepr:`6280` by :ghuser:`bdraco`
- make output optional for speed fan :esphomepr:`6274` by :ghuser:`ssieb`
- fix throttle average nan handling :esphomepr:`6275` by :ghuser:`ssieb`
- Fix thermostat supplemental actions :esphomepr:`6282` by :ghuser:`kbx81`
Release 2024.2.2 - March 6
--------------------------
- CSE7766: Fix energy calculation :esphomepr:`6286` by :ghuser:`puuu`
- handling with the negative temperature in the sensor tmp102 :esphomepr:`6316` by :ghuser:`FlyingFeng2021`
- fix tmp102 negative calculation :esphomepr:`6320` by :ghuser:`ssieb`
- auto load output for now :esphomepr:`6309` by :ghuser:`ssieb`
- Add wake word phrase to voice assistant start command :esphomepr:`6290` by :ghuser:`jesserockz`
Full list of changes
--------------------
New Components
^^^^^^^^^^^^^^
- feat: add AS5600 component/sensor :esphomepr:`5174` by :ghuser:`ammmze` (new-integration)
- Support for ST7567 display 128x64 (I2C, SPI) :esphomepr:`5952` by :ghuser:`latonita` (new-integration)
- BME280 SPI :esphomepr:`5538` by :ghuser:`apbodrov` (new-integration) (breaking-change)
- Add support for VEML3235 lux sensor :esphomepr:`5959` by :ghuser:`kbx81` (new-integration)
- Add support of Honeywell HumidIcon (I2C HIH series) Temperature & Humidity sensor :esphomepr:`5730` by :ghuser:`Benichou34` (new-integration)
- Add combination sensor and remove absorbed kalman_combinator component :esphomepr:`5438` by :ghuser:`kahrendt` (new-integration) (breaking-change)
- Add micro_wake_word component :esphomepr:`6136` by :ghuser:`kahrendt` (new-integration)
Breaking Changes
^^^^^^^^^^^^^^^^
- PMSx003 add relevant device and state classes to default config :esphomepr:`5633` by :ghuser:`wheimbigner` (breaking-change)
- BME280 SPI :esphomepr:`5538` by :ghuser:`apbodrov` (new-integration) (breaking-change)
- convert cse7766 to non-polling :esphomepr:`6095` by :ghuser:`ssieb` (breaking-change)
- Add combination sensor and remove absorbed kalman_combinator component :esphomepr:`5438` by :ghuser:`kahrendt` (new-integration) (breaking-change)
Beta Changes
^^^^^^^^^^^^
- AUTO_LOAD ``sensor`` for ``shelly_dimmer`` :esphomepr:`6223` by :ghuser:`kbx81`
- Add more debugging logs to microWakeWord :esphomepr:`6238` by :ghuser:`kahrendt`
- Fix to RF receiver for Drayton Digistat heating controller :esphomepr:`6235` by :ghuser:`marshn`
- WRGB Use correct multiplier :esphomepr:`6237` by :ghuser:`mhetzi`
- Add optional minimum esphome version to microWakeWord manifest :esphomepr:`6240` by :ghuser:`jesserockz`
- Fix xl9535 pin reads :esphomepr:`6242` by :ghuser:`jesserockz`
- hold interrupt disable for dallas one-wire :esphomepr:`6244` by :ghuser:`ssieb`
- Fix tm1651 enum :esphomepr:`6248` by :ghuser:`kbx81`
- Clear UART read buffer before sending next command :esphomepr:`6200` by :ghuser:`fototakas`
- Voice Assistant: add on_idle trigger and fix nevermind :esphomepr:`6141` by :ghuser:`synesthesiam`
- Tuya Fan component fix to handle enum datapoint type :esphomepr:`6135` by :ghuser:`sibowler`
All changes
^^^^^^^^^^^
- Bump esptool from 4.6.2 to 4.7.0 :esphomepr:`5935` by :ghuser:`dependabot[bot]`
- Bump actions/download-artifact from 3.0.2 to 4.0.0 :esphomepr:`5936` by :ghuser:`dependabot[bot]`
- Bump build-image action versions :esphomepr:`5954` by :ghuser:`jesserockz`
- Revert "Bump build-image action versions" :esphomepr:`5955` by :ghuser:`jesserockz`
- Revert "Bump actions/download-artifact from 3.0.2 to 4.0.0" :esphomepr:`5956` by :ghuser:`jesserockz`
- Bump zeroconf from 0.130.0 to 0.131.0 :esphomepr:`5967` by :ghuser:`dependabot[bot]`
- Add ability to lock to set mode :esphomepr:`5924` by :ghuser:`ysmilda`
- feat: add AS5600 component/sensor :esphomepr:`5174` by :ghuser:`ammmze` (new-integration)
- Add default substitutions for package includes :esphomepr:`5752` by :ghuser:`mknjc`
- Add gradient option to addressable color wipe effect :esphomepr:`5689` by :ghuser:`lifeisafractal`
- Added alarm processing for Haier component (hOn protocol) :esphomepr:`5965` by :ghuser:`paveldn`
- Allow haier remote protocol to use lambdas :esphomepr:`5898` by :ghuser:`catlee`
- PMSx003 add relevant device and state classes to default config :esphomepr:`5633` by :ghuser:`wheimbigner` (breaking-change)
- Add waveshare 2.7in V2 model :esphomepr:`5903` by :ghuser:`gumulka`
- Add support for waveshare 2.9in B V3 version :esphomepr:`5902` by :ghuser:`gumulka`
- Fix pin reuse in test1 :esphomepr:`5978` by :ghuser:`jesserockz`
- Add Waveshare 1.47in 172x320 to ST7789v component :esphomepr:`5884` by :ghuser:`mrtoy-me`
- (fingerprint_grow) Added on_finger_scan_invalid automation. :esphomepr:`5885` by :ghuser:`RubenNL`
- Alarm panel: Add changes to support enhanced features :esphomepr:`5671` by :ghuser:`hwstar`
- support default pins for adafruit esp32 feather v2 :esphomepr:`5482` by :ghuser:`sbrudenell`
- Bug: Unwanted change resistance in x9c component :esphomepr:`5483` by :ghuser:`fizista`
- Improvements to RF receiver for Drayton Digistat heating controller :esphomepr:`5504` by :ghuser:`marshn`
- Reduce memory usage with StringRef in MQTT Components :esphomepr:`5719` by :ghuser:`kahrendt`
- Nextion allow underscore on names :esphomepr:`5979` by :ghuser:`edwardtfn`
- Add Keeloq RF protocol :esphomepr:`5511` by :ghuser:`marshn`
- Add a Binary Sensor Filter for state settling :esphomepr:`5900` by :ghuser:`cottsay`
- Lint the script folder files :esphomepr:`5991` by :ghuser:`jesserockz`
- web_server support for home assistant like styling :esphomepr:`5854` by :ghuser:`afarago`
- [Touchscreen] Add expire of touch record. :esphomepr:`5986` by :ghuser:`Fabian-Schmidt`
- Support for ST7567 display 128x64 (I2C, SPI) :esphomepr:`5952` by :ghuser:`latonita` (new-integration)
- Add constants used by multiple display drivers to global const.py :esphomepr:`6033` by :ghuser:`clydebarrow`
- Nextion queue size :esphomepr:`6029` by :ghuser:`edwardtfn`
- Ble client additions and fixes :esphomepr:`5277` by :ghuser:`clydebarrow`
- HaierProtocol library updated to 0.9.25 to fix the answer_timeout bug :esphomepr:`6015` by :ghuser:`paveldn`
- GT911 touchscreen: Fix bug causing touch button release to fail :esphomepr:`6042` by :ghuser:`clydebarrow`
- Display: Introduce `draw_pixels_at()` method for fast block display rendering :esphomepr:`6034` by :ghuser:`clydebarrow`
- clang-format and clang-tidy scripts: More robust algorithm to find correct executable :esphomepr:`6041` by :ghuser:`clydebarrow`
- Don't crash with invalid adc pin :esphomepr:`6059` by :ghuser:`ssieb`
- Add questionmark to default glyphs. :esphomepr:`6053` by :ghuser:`RubenNL`
- pylontech: fix voltage_low and voltage_high wrong unit :esphomepr:`6060` by :ghuser:`functionpointer`
- Bump flake8 from 6.1.0 to 7.0.0 :esphomepr:`6058` by :ghuser:`dependabot[bot]`
- Nextion enable upload from https when using esp-idf :esphomepr:`6051` by :ghuser:`edwardtfn`
- Extends UART change at runtime to ESP8266 :esphomepr:`6019` by :ghuser:`edwardtfn`
- Nextion draw QR code at runtime :esphomepr:`6027` by :ghuser:`edwardtfn`
- Extend i2s config options :esphomepr:`6056` by :ghuser:`Hadatko`
- Add getter for image data_start :esphomepr:`6036` by :ghuser:`clydebarrow`
- Bump hypothesis to 6.92.1 :esphomepr:`6011` by :ghuser:`bdraco`
- Bump recommended ESP32 IDF to 4.4.6 :esphomepr:`6048` by :ghuser:`bdraco`
- Bump pytest from 7.4.3 to 7.4.4 :esphomepr:`6046` by :ghuser:`dependabot[bot]`
- dashboard: refactor ping implementation to be more efficient :esphomepr:`6002` by :ghuser:`bdraco`
- Bump pytest-asyncio from 0.23.2 to 0.23.3 :esphomepr:`6047` by :ghuser:`dependabot[bot]`
- Bump black from 23.12.0 to 23.12.1 :esphomepr:`6018` by :ghuser:`dependabot[bot]`
- Run python tests on windows and macos :esphomepr:`6010` by :ghuser:`bdraco`
- BME280 SPI :esphomepr:`5538` by :ghuser:`apbodrov` (new-integration) (breaking-change)
- Actions to enable and disable WireGuard connection :esphomepr:`5690` by :ghuser:`droscy`
- hydreon_rgxx - fix missing cg.add(var.set_model(...)) :esphomepr:`6065` by :ghuser:`mrtoy-me`
- Bump pillow to 10.2.0. :esphomepr:`6091` by :ghuser:`pfrenssen`
- convert cse7766 to non-polling :esphomepr:`6095` by :ghuser:`ssieb` (breaking-change)
- Use touch state from ft63x6 driver. :esphomepr:`6055` by :ghuser:`nielsnl68`
- update script/setup so it works fine on windows :esphomepr:`6087` by :ghuser:`nielsnl68`
- add Pico-ResTouch-LCD-3.5 :esphomepr:`6078` by :ghuser:`nielsnl68`
- Revert "add Pico-ResTouch-LCD-3.5" :esphomepr:`6098` by :ghuser:`nielsnl68`
- Add triangle shapes to display component :esphomepr:`6096` by :ghuser:`mathieu-mp`
- Fingerprint_grow: Trigger on finger scan start and on finger scan misplaced :esphomepr:`6003` by :ghuser:`alexborro`
- Add continuous option to the graph :esphomepr:`6093` by :ghuser:`ssieb`
- Add NFC binary sensor platform :esphomepr:`6068` by :ghuser:`kbx81`
- Socket: Add recvfrom method to receive UDP with source address. :esphomepr:`6103` by :ghuser:`clydebarrow`
- Add support for VEML3235 lux sensor :esphomepr:`5959` by :ghuser:`kbx81` (new-integration)
- CV: tidy up Schema wrapper :esphomepr:`6105` by :ghuser:`jesserockz`
- Add support X.509 client certificates for MQTT. :esphomepr:`5778` by :ghuser:`h2zero`
- Fix color observation for triangle outline in display component :esphomepr:`6107` by :ghuser:`mathieu-mp`
- Add support of Honeywell HumidIcon (I2C HIH series) Temperature & Humidity sensor :esphomepr:`5730` by :ghuser:`Benichou34` (new-integration)
- Proposal: Test yaml for each component :esphomepr:`5398` by :ghuser:`Fabian-Schmidt`
- WiFi fast_connect: save/load BSSID and channel for faster connect from sleep :esphomepr:`5931` by :ghuser:`rguca`
- Fixes Waveshare 7.5in B V2 and V3 :esphomepr:`6079` by :ghuser:`Pofilo`
- Add combination sensor and remove absorbed kalman_combinator component :esphomepr:`5438` by :ghuser:`kahrendt` (new-integration) (breaking-change)
- Bump platformio from 6.1.11 to 6.1.13 :esphomepr:`6086` by :ghuser:`dependabot[bot]`
- Bump actions/cache from 3.3.2 to 4.0.0 :esphomepr:`6110` by :ghuser:`dependabot[bot]`
- Enable networking and some other components on host platform :esphomepr:`6114` by :ghuser:`clydebarrow`
- Fix time component for host platform :esphomepr:`6118` by :ghuser:`clydebarrow`
- Add quad spi features :esphomepr:`5925` by :ghuser:`clydebarrow`
- add AM2120 device type :esphomepr:`6115` by :ghuser:`alexbuit`
- Add support for Waveshare EPD 2.13" V3 :esphomepr:`5363` by :ghuser:`clydebarrow`
- OTA 2 which confirm each written chunk :esphomepr:`6066` by :ghuser:`tomaszduda23`
- Remove optional<> for pointer types :esphomepr:`6120` by :ghuser:`kroimon`
- Improve temperature precision in BME280 and BMP280 :esphomepr:`6124` by :ghuser:`jxl77`
- Nextion TFT upload IDF memory optimization :esphomepr:`6128` by :ghuser:`edwardtfn`
- Add support for Pico-ResTouch-LCD-3.5 to ili9xxx driver :esphomepr:`6129` by :ghuser:`clydebarrow`
- Ensure filename is shown when YAML raises an error :esphomepr:`6139` by :ghuser:`bdraco`
- ILI9XXX: Restore offset usage in set_addr_window :esphomepr:`6147` by :ghuser:`clydebarrow`
- Minimum 1 for full_update_every to prevent IntegerDivideByZero. :esphomepr:`6150` by :ghuser:`RubenNL`
- Support tri-color waveshare eink displays 2.7inch B and B V2 :esphomepr:`4238` by :ghuser:`rnauber`
- Synchronise Device Classes from Home Assistant :esphomepr:`6158` by :ghuser:`esphomebot`
- dfrobot_sen0395: Use setLatency instead of outputLatency :esphomepr:`5665` by :ghuser:`jfroy`
- Add some components to the new testing framework (A part 1) :esphomepr:`6142` by :ghuser:`kbx81`
- WRGB or RGBW? WS2814 :esphomepr:`6164` by :ghuser:`mhetzi`
- Add some components to the new testing framework (A part 2) :esphomepr:`6162` by :ghuser:`kbx81`
- Bump aioesphomeapi to 21.0.2 :esphomepr:`6188` by :ghuser:`bdraco`
- Add some components to the new testing framework (B) :esphomepr:`6173` by :ghuser:`kbx81`
- Add "transformer_active" flag for use in effects. :esphomepr:`6157` by :ghuser:`TikiBill`
- CSE7766: fix power and current measurements at low loads :esphomepr:`6180` by :ghuser:`twasilczyk`
- host platform: improvements and bugfixes :esphomepr:`6137` by :ghuser:`clydebarrow`
- WLED Sync fix and BK72XX support :esphomepr:`6190` by :ghuser:`ChuckMash`
- Add missing vector.h for lightwaverf :esphomepr:`6196` by :ghuser:`kbx81`
- Add some components to the new testing framework (C) :esphomepr:`6174` by :ghuser:`kbx81`
- update docstrings in cpp_generator.py :esphomepr:`6212` by :ghuser:`nielsnl68`
- Fixed group mask logic for WLED Sync fix :esphomepr:`6193` by :ghuser:`ChuckMash`
- Add micro_wake_word component :esphomepr:`6136` by :ghuser:`kahrendt` (new-integration)
- AUTO_LOAD ``sensor`` for ``shelly_dimmer`` :esphomepr:`6223` by :ghuser:`kbx81`
- Add more debugging logs to microWakeWord :esphomepr:`6238` by :ghuser:`kahrendt`
- Fix to RF receiver for Drayton Digistat heating controller :esphomepr:`6235` by :ghuser:`marshn`
- WRGB Use correct multiplier :esphomepr:`6237` by :ghuser:`mhetzi`
- Add optional minimum esphome version to microWakeWord manifest :esphomepr:`6240` by :ghuser:`jesserockz`
- Fix xl9535 pin reads :esphomepr:`6242` by :ghuser:`jesserockz`
- hold interrupt disable for dallas one-wire :esphomepr:`6244` by :ghuser:`ssieb`
- Fix tm1651 enum :esphomepr:`6248` by :ghuser:`kbx81`
- Clear UART read buffer before sending next command :esphomepr:`6200` by :ghuser:`fototakas`
- Voice Assistant: add on_idle trigger and fix nevermind :esphomepr:`6141` by :ghuser:`synesthesiam`
- Tuya Fan component fix to handle enum datapoint type :esphomepr:`6135` by :ghuser:`sibowler`
Past Changelogs
---------------
- :doc:`2023.12.0`
- :doc:`2023.11.0`
- :doc:`2023.10.0`
- :doc:`2023.9.0`
- :doc:`2023.8.0`
- :doc:`2023.7.0`
- :doc:`2023.6.0`
- :doc:`2023.5.0`
- :doc:`2023.4.0`
- :doc:`2023.3.0`
- :doc:`2023.2.0`
- :doc:`2022.12.0`
- :doc:`2022.11.0`
- :doc:`2022.10.0`
- :doc:`2022.9.0`
- :doc:`2022.8.0`
- :doc:`2022.6.0`
- :doc:`2022.5.0`
- :doc:`2022.4.0`
- :doc:`2022.3.0`
- :doc:`2022.2.0`
- :doc:`2022.1.0`
- :doc:`2021.12.0`
- :doc:`2021.11.0`
- :doc:`2021.10.0`
- :doc:`2021.9.0`
- :doc:`2021.8.0`
- :doc:`v1.20.0`
- :doc:`v1.19.0`
- :doc:`v1.18.0`
- :doc:`v1.17.0`
- :doc:`v1.16.0`
- :doc:`v1.15.0`
- :doc:`v1.14.0`
- :doc:`v1.13.0`
- :doc:`v1.12.0`
- :doc:`v1.11.0`
- :doc:`v1.10.0`
- :doc:`v1.9.0`
- :doc:`v1.8.0`
- :doc:`v1.7.0`

305
changelog/2024.3.0.rst Normal file
View File

@ -0,0 +1,305 @@
ESPHome 2024.3.0 - 20th March 2024
==================================
.. seo::
:description: Changelog for ESPHome 2024.3.0.
:image: /_static/changelog-2024.3.0.png
:author: Jesse Hills
:author_twitter: @jesserockz
.. imgtable::
:columns: 5
Datetime Core, components/datetime/index, clock-outline.svg, dark-invert
Template Datetime, components/datetime/template, description.svg, dark-invert
AM2315C, components/sensor/am2315c, am2315c.jpg
HTU31D, components/sensor/htu31d, htu31d.jpg,
MS8607, components/sensor/ms8607, ms8607.jpg
AGS10, components/sensor/ags10, ags10.jpg
VEML6030, components/sensor/veml7700, veml6030.jpg
VEML7700, components/sensor/veml7700, veml7700.jpg
MR24HPC1 mmWave, components/seeed_mr24hpc1, seeed-mr24hpc1.jpg
ADS1118, components/sensor/ads1118, ads1118.jpg
CST816, components/touchscreen/cst816, cst816.jpg
CST226, components/touchscreen/cst226, t4-s3.jpg
RPI_DPI_RGB, components/display/rpi_dpi_rgb, waveshare_touch-s3.jpg
Quad SPI AMOLED, components/display/qspi_amoled, t4-s3.jpg
ST7701S, components/display/st7701s, indicator.jpg
ADE7880, components/sensor/ade7880, ade7880.svg
Emmeti, components/climate/climate_ir, air-conditioner-ir.svg, dark-invert
Uponor Smatrix, components/uponor_smatrix, uponor.svg
Kamstrup KMP, components/sensor/kamstrup_kmp, kamstrup_kmp.jpg
Template Fan, components/fan/template, description.svg, dark-invert
Dates
-----
ESPHome now has support for ``date`` entities that can be set from the frontend (like Home Assistant) for you to check against and execute
automations in the future.
ESPHome Dates require Home Assistant 2024.4 or later.
IPv6
----
ESPHome is now prepared for the future! The future that is the old IPv6 that is.
Dualstack is added and it could now have up to 5 ip addresses of any type, and communication with Home assistant,
MQTT and NTP works with IPv6. ESPHome still depends on IPv4, but the crystal ball shows sign of IPv6-only networks.
If you are building an :doc:`/components/external_components` or you use
``network::get_ip_address()``, ``wifi::global_wifi_component->get_ip_address()`` or ``ethernet::global_eth_component->get_ip_address()``,
these functions have been renamed to ``::get_ip_addresses()`` respectively and now return a list of all IP addresses.
Release 2024.3.1 - March 27
---------------------------
- AHT10: Fix bug :esphomepr:`6409` by :ghuser:`clydebarrow`
- microWakeWord: Fix model path joining :esphomepr:`6426` by :ghuser:`ebw44`
- Don't compile strptime unless its required :esphomepr:`6424` by :ghuser:`gabest11`
- Fix editor live validation :esphomepr:`6431` by :ghuser:`bdraco`
Thank you for your support
--------------------------
We would like to thank all Home Assistant Cloud subscribers for their support. It allows `Nabu Casa <https://nabucasa.com/>`__ to
employ two developers to maintain and further develop the ESPHome project.
Full list of changes
--------------------
New Components
^^^^^^^^^^^^^^
- New component: ADE7880 voltage/current/power/energy sensor :esphomepr:`5242` by :ghuser:`kpfleming` (new-integration)
- Add Uponor Smatrix component :esphomepr:`5769` by :ghuser:`kroimon` (new-integration)
- Support for MS8607 PHT (Pressure Humidity Temperature) sensor :esphomepr:`3307` by :ghuser:`e28eta` (new-integration)
- Add datetime date entities :esphomepr:`6191` by :ghuser:`RFDarter` (new-integration)
- Add AGS10 Sensor :esphomepr:`6070` by :ghuser:`mak-42` (new-integration)
- ads1118 component :esphomepr:`5711` by :ghuser:`solomondg1` (new-integration)
- Add CST816 touchscreen driver :esphomepr:`5941` by :ghuser:`clydebarrow` (new-integration)
- AM2315C Temperature + Humidity Sensor :esphomepr:`6266` by :ghuser:`swoboda1337` (new-integration)
- Touchscreen: add support for CST226 controller chip :esphomepr:`6151` by :ghuser:`clydebarrow` (new-integration)
- Drivers for RGB 16 bit parallel displays :esphomepr:`5872` by :ghuser:`clydebarrow` (new-integration)
- VEML7700 and VEML6030 light sensors :esphomepr:`6067` by :ghuser:`latonita` (new-integration)
- Add Seeed Studio mmWave Kit MR24HPC1 :esphomepr:`5761` by :ghuser:`limengdu` (new-integration)
- Add driver for quad SPI AMOLED displays :esphomepr:`6354` by :ghuser:`clydebarrow` (new-integration)
- feat: Add HTU31D Support :esphomepr:`5805` by :ghuser:`betterengineering` (new-integration)
- Emmeti infrared climate support :esphomepr:`5197` by :ghuser:`E440QF` (new-integration)
- Added Kamstrup Multical 40x component :esphomepr:`4200` by :ghuser:`cfeenstra1024` (new-integration)
New Platforms
^^^^^^^^^^^^^
- Additional sensors and binary sensors support for Haier Climate :esphomepr:`6257` by :ghuser:`paveldn` (breaking-change) (new-platform)
- add template fan :esphomepr:`6310` by :ghuser:`ssieb` (breaking-change) (new-platform)
Breaking Changes
^^^^^^^^^^^^^^^^
- LTR390 - Multiple bugfixes :esphomepr:`6161` by :ghuser:`sjtrny` (breaking-change)
- Touchscreen component and driver fixes :esphomepr:`5997` by :ghuser:`nielsnl68` (breaking-change)
- Additional sensors and binary sensors support for Haier Climate :esphomepr:`6257` by :ghuser:`paveldn` (breaking-change) (new-platform)
- add template fan :esphomepr:`6310` by :ghuser:`ssieb` (breaking-change) (new-platform)
Beta Changes
^^^^^^^^^^^^
- SPI: Revert clk_pin to standard output pin schema :esphomepr:`6368` by :ghuser:`clydebarrow`
- Allow actions in web_server to be executed via GET method :esphomepr:`5938` by :ghuser:`afarago`
- fix servo restore :esphomepr:`6370` by :ghuser:`ssieb`
- Don't try to get IPv6 addresses when disabled :esphomepr:`6366` by :ghuser:`HeMan`
- Use AQI device class :esphomepr:`6376` by :ghuser:`fgsch`
- Fix list-components when PR is not targeting dev :esphomepr:`6375` by :ghuser:`jesserockz`
- allow negative ppm for sensair :esphomepr:`6385` by :ghuser:`ssieb`
- microWakeWord - add new ops and small improvements :esphomepr:`6360` by :ghuser:`kahrendt`
- Fix compilation for uponor_smatrix without time component :esphomepr:`6389` by :ghuser:`kroimon`
- Shows component operation time in ``ms`` :esphomepr:`6388` by :ghuser:`edwardtfn`
- IPv6 can't be enabled for libretiny :esphomepr:`6387` by :ghuser:`HeMan`
- Replace name and friendly name in full adopted configs :esphomepr:`4456` by :ghuser:`jesserockz`
- Fix bug in ``remote_base`` conditional :esphomepr:`6281` by :ghuser:`swoboda1337`
- Fix sending packets to uponor_smatrix devices :esphomepr:`6392` by :ghuser:`kroimon`
- Fix wrong initialization of vectors in ade7953_i2c :esphomepr:`6393` by :ghuser:`kroimon`
- ld2420: Firmware v1.5.4+ bug workaround :esphomepr:`6168` by :ghuser:`descipher`
- Require xsrf/csrf when using a password :esphomepr:`6396` by :ghuser:`jesserockz`
- AHT10: Use state machine to avoid blocking delay :esphomepr:`6401` by :ghuser:`clydebarrow`
- Show component warnings and errors in the log; :esphomepr:`6400` by :ghuser:`clydebarrow`
- web_server support for v3 :esphomepr:`6203` by :ghuser:`RFDarter`
All changes
^^^^^^^^^^^
- Bump openssh-client to 1:9.2p1-2+deb12u2 :esphomepr:`6216` by :ghuser:`jesserockz`
- Add support for 1.8V-powered devices :esphomepr:`6234` by :ghuser:`bisbastuner`
- Adjust HeatpumpIR dependency :esphomepr:`6222` by :ghuser:`ivankravets`
- INA226 - fixed improper work with signed values, added configurable ADC parameters :esphomepr:`6172` by :ghuser:`latonita`
- Prevent network config on rpipico board :esphomepr:`5832` by :ghuser:`carlosV2`
- Bump pytest-asyncio from 0.23.3 to 0.23.5 :esphomepr:`6201` by :ghuser:`dependabot[bot]`
- New component: ADE7880 voltage/current/power/energy sensor :esphomepr:`5242` by :ghuser:`kpfleming` (new-integration)
- Add some components to the new testing framework (D) :esphomepr:`6175` by :ghuser:`kbx81`
- Provide example devcontainer config for mdns and USB passthrough :esphomepr:`6094` by :ghuser:`linkedupbits`
- Bump black from 23.12.1 to 24.2.0 :esphomepr:`6221` by :ghuser:`dependabot[bot]`
- Bump pytest from 7.4.4 to 8.0.1 :esphomepr:`6246` by :ghuser:`dependabot[bot]`
- Bump codecov/codecov-action from 3 to 4 :esphomepr:`6160` by :ghuser:`dependabot[bot]`
- Bump peter-evans/create-pull-request from 5.0.2 to 6.0.0 :esphomepr:`6159` by :ghuser:`dependabot[bot]`
- Bump frenck/action-yamllint from 1.4.2 to 1.5.0 :esphomepr:`6236` by :ghuser:`dependabot[bot]`
- Bump voluptuous from 0.14.1 to 0.14.2 :esphomepr:`6181` by :ghuser:`dependabot[bot]`
- Bump pyupgrade from 3.15.0 to 3.15.1 :esphomepr:`6247` by :ghuser:`dependabot[bot]`
- LTR390 - Multiple bugfixes :esphomepr:`6161` by :ghuser:`sjtrny` (breaking-change)
- Fix yamllint :esphomepr:`6253` by :ghuser:`jesserockz`
- Improve the error message on OTA version mismatch :esphomepr:`6259` by :ghuser:`sybrenstuvel`
- Bump aioesphomeapi from 21.0.2 to 22.0.0 :esphomepr:`6263` by :ghuser:`dependabot[bot]`
- Allow ESP8266 to use multiple i2c busses :esphomepr:`6145` by :ghuser:`LouDou`
- Add Uponor Smatrix component :esphomepr:`5769` by :ghuser:`kroimon` (new-integration)
- Fix test_build_components for macOS sed :esphomepr:`6278` by :ghuser:`kbx81`
- Allow to specify global build directory :esphomepr:`6276` by :ghuser:`werwolfby`
- Add device class support to text sensor :esphomepr:`6202` by :ghuser:`dougiteixeira`
- Bump pytest from 8.0.1 to 8.0.2 :esphomepr:`6288` by :ghuser:`dependabot[bot]`
- Improve dualstack and IPv6 support :esphomepr:`5449` by :ghuser:`HeMan`
- Waveshare e-ink 2IN9_V2 - fix full and partial update based on vendor… :esphomepr:`5481` by :ghuser:`darianndd`
- Add RTTTL volume control. :esphomepr:`5968` by :ghuser:`nielsnl68`
- Touchscreen component and driver fixes :esphomepr:`5997` by :ghuser:`nielsnl68` (breaking-change)
- Add `on_update` trigger for Project versions :esphomepr:`6298` by :ghuser:`jesserockz`
- Bump peter-evans/create-pull-request from 6.0.0 to 6.0.1 :esphomepr:`6302` by :ghuser:`dependabot[bot]`
- CSE7766 Apparent Power & Power Factor calculations :esphomepr:`6292` by :ghuser:`DAVe3283`
- Adding W5500 support to ethernet component :esphomepr:`4424` by :ghuser:`JeroenVanOort`
- Fix numbering of ip_address sensors :esphomepr:`6305` by :ghuser:`HeMan`
- Bump aioesphomeapi from 22.0.0 to 23.0.0 :esphomepr:`6293` by :ghuser:`dependabot[bot]`
- Add regular polygon shapes to display component :esphomepr:`6108` by :ghuser:`mathieu-mp`
- Fix return value in `core/automation.h` :esphomepr:`6314` by :ghuser:`FlyingFeng2021`
- aht10: Added new CMD and renamed existing CMD to match datasheet :esphomepr:`6303` by :ghuser:`cptskippy`
- handling with the negative temperature in the sensor tmp102 :esphomepr:`6316` by :ghuser:`FlyingFeng2021`
- x9c: fix off by 1 error :esphomepr:`6318` by :ghuser:`andynumber2`
- Support for MS8607 PHT (Pressure Humidity Temperature) sensor :esphomepr:`3307` by :ghuser:`e28eta` (new-integration)
- Separate logger implementations for each hardware platform into different files :esphomepr:`6167` by :ghuser:`tomaszduda23`
- Additional sensors and binary sensors support for Haier Climate :esphomepr:`6257` by :ghuser:`paveldn` (breaking-change) (new-platform)
- Add toggle command to cover web_server endpoint :esphomepr:`6319` by :ghuser:`heythisisnate`
- Improv: support connecting to hidden networks :esphomepr:`6322` by :ghuser:`jesserockz`
- Update mDNS for IDF >= 5.0 :esphomepr:`6328` by :ghuser:`HeMan`
- DFPlayer: refix Bug created with PR 4758 :esphomepr:`5861` by :ghuser:`sandronidi`
- Fix build failures on host platform caused by #6167 :esphomepr:`6338` by :ghuser:`clydebarrow`
- Update bang_bang to log two decimal places in config dump :esphomepr:`6304` by :ghuser:`rafalw1277`
- Add datetime date entities :esphomepr:`6191` by :ghuser:`RFDarter` (new-integration)
- Add AGS10 Sensor :esphomepr:`6070` by :ghuser:`mak-42` (new-integration)
- Bump aioesphomeapi from 23.0.0 to 23.1.0 :esphomepr:`6332` by :ghuser:`dependabot[bot]`
- Bump pytest-asyncio from 0.23.5 to 0.23.5.post1 :esphomepr:`6334` by :ghuser:`dependabot[bot]`
- Bump docker/setup-buildx-action from 3.0.0 to 3.1.0 :esphomepr:`6295` by :ghuser:`dependabot[bot]`
- Set dependabot to look at composite actions versions :esphomepr:`6343` by :ghuser:`jesserockz`
- ads1118 component :esphomepr:`5711` by :ghuser:`solomondg1` (new-integration)
- Bump actions/cache from 4.0.0 to 4.0.1 :esphomepr:`6306` by :ghuser:`dependabot[bot]`
- Bump docker/build-push-action from 5.0.0 to 5.2.0 in /.github/actions/build-image :esphomepr:`6347` by :ghuser:`dependabot[bot]`
- fix: modbus_textsensor response is too long in some cases :esphomepr:`6333` by :ghuser:`NewoPL`
- add template fan :esphomepr:`6310` by :ghuser:`ssieb` (breaking-change) (new-platform)
- dump config after logging CDC port is opened by host :esphomepr:`6169` by :ghuser:`tomaszduda23`
- Add IRK support to allow tracking of devices with random MAC addresses :esphomepr:`6335` by :ghuser:`chbmuc`
- [Fingerprint_grow] Implements Sleep Mode feature :esphomepr:`6116` by :ghuser:`alexborro`
- cleanup ili9xxx component by removing data rate define :esphomepr:`6350` by :ghuser:`nielsnl68`
- web_server_idf: support x-www-form-urlencoded POST requests :esphomepr:`6037` by :ghuser:`dentra`
- feat(MQTT): Add QoS option for each MQTT component :esphomepr:`6279` by :ghuser:`Rapsssito`
- Check permissions :esphomepr:`6255` by :ghuser:`OdileVidrine`
- Add CST816 touchscreen driver :esphomepr:`5941` by :ghuser:`clydebarrow` (new-integration)
- ILI9XXX: Lazily allocate buffer :esphomepr:`6352` by :ghuser:`clydebarrow`
- AM2315C Temperature + Humidity Sensor :esphomepr:`6266` by :ghuser:`swoboda1337` (new-integration)
- Add ble_presence binary sensor timeout config value. :esphomepr:`6024` by :ghuser:`clydebarrow`
- Add state listeners to `rotary_encoder` :esphomepr:`6035` by :ghuser:`clydebarrow`
- ili9xxx: Add support for GC9A01A display :esphomepr:`6351` by :ghuser:`clydebarrow`
- Touchscreen: add support for CST226 controller chip :esphomepr:`6151` by :ghuser:`clydebarrow` (new-integration)
- font: add anti-aliasing and other features :esphomepr:`6198` by :ghuser:`clydebarrow`
- Mhz19 warmup :esphomepr:`6214` by :ghuser:`fornellas`
- Refactor ATM90E32 to reduce blocking time and improve accuracy. :esphomepr:`5670` by :ghuser:`descipher`
- Bump aioesphomeapi from 23.1.0 to 23.1.1 :esphomepr:`6348` by :ghuser:`dependabot[bot]`
- Bump pytest from 8.0.2 to 8.1.1 :esphomepr:`6346` by :ghuser:`dependabot[bot]`
- Add support for Waveshare 2.13" V2 display :esphomepr:`6337` by :ghuser:`manuelkasper`
- Mitsubishi Climate updates :esphomepr:`3886` by :ghuser:`RubyBailey`
- Drivers for RGB 16 bit parallel displays :esphomepr:`5872` by :ghuser:`clydebarrow` (new-integration)
- hydreon_rgxx - add resolution option :esphomepr:`6077` by :ghuser:`mrtoy-me`
- SPI schema now uses typed_schema with `type` key :esphomepr:`6353` by :ghuser:`clydebarrow`
- VEML7700 and VEML6030 light sensors :esphomepr:`6067` by :ghuser:`latonita` (new-integration)
- Add Seeed Studio mmWave Kit MR24HPC1 :esphomepr:`5761` by :ghuser:`limengdu` (new-integration)
- Add getter for font glyph data :esphomepr:`6355` by :ghuser:`clydebarrow`
- Require reset_pin for certain waveshare_epaper models in YAML validation :esphomepr:`6357` by :ghuser:`manuelkasper`
- touchscreen driver fixes :esphomepr:`6356` by :ghuser:`clydebarrow`
- Make USE_HOST compilable on msys2 :esphomepr:`6359` by :ghuser:`maruel`
- download font from url on build :esphomepr:`5254` by :ghuser:`landonr`
- Add driver for quad SPI AMOLED displays :esphomepr:`6354` by :ghuser:`clydebarrow` (new-integration)
- ADE7953: Add the ability to use accumulating energy registers, more precise power reporting :esphomepr:`6311` by :ghuser:`isorin`
- feat: Add HTU31D Support :esphomepr:`5805` by :ghuser:`betterengineering` (new-integration)
- Emmeti infrared climate support :esphomepr:`5197` by :ghuser:`E440QF` (new-integration)
- Added Kamstrup Multical 40x component :esphomepr:`4200` by :ghuser:`cfeenstra1024` (new-integration)
- add possibility to provide different conversion times for Bus Voltage… :esphomepr:`6327` by :ghuser:`kev300`
- SPI: Revert clk_pin to standard output pin schema :esphomepr:`6368` by :ghuser:`clydebarrow`
- Allow actions in web_server to be executed via GET method :esphomepr:`5938` by :ghuser:`afarago`
- fix servo restore :esphomepr:`6370` by :ghuser:`ssieb`
- Don't try to get IPv6 addresses when disabled :esphomepr:`6366` by :ghuser:`HeMan`
- Use AQI device class :esphomepr:`6376` by :ghuser:`fgsch`
- Fix list-components when PR is not targeting dev :esphomepr:`6375` by :ghuser:`jesserockz`
- allow negative ppm for sensair :esphomepr:`6385` by :ghuser:`ssieb`
- microWakeWord - add new ops and small improvements :esphomepr:`6360` by :ghuser:`kahrendt`
- Fix compilation for uponor_smatrix without time component :esphomepr:`6389` by :ghuser:`kroimon`
- Shows component operation time in ``ms`` :esphomepr:`6388` by :ghuser:`edwardtfn`
- IPv6 can't be enabled for libretiny :esphomepr:`6387` by :ghuser:`HeMan`
- Replace name and friendly name in full adopted configs :esphomepr:`4456` by :ghuser:`jesserockz`
- Fix bug in ``remote_base`` conditional :esphomepr:`6281` by :ghuser:`swoboda1337`
- Fix sending packets to uponor_smatrix devices :esphomepr:`6392` by :ghuser:`kroimon`
- Fix wrong initialization of vectors in ade7953_i2c :esphomepr:`6393` by :ghuser:`kroimon`
- ld2420: Firmware v1.5.4+ bug workaround :esphomepr:`6168` by :ghuser:`descipher`
- Require xsrf/csrf when using a password :esphomepr:`6396` by :ghuser:`jesserockz`
- AHT10: Use state machine to avoid blocking delay :esphomepr:`6401` by :ghuser:`clydebarrow`
- Show component warnings and errors in the log; :esphomepr:`6400` by :ghuser:`clydebarrow`
- web_server support for v3 :esphomepr:`6203` by :ghuser:`RFDarter`
Past Changelogs
---------------
- :doc:`2024.2.0`
- :doc:`2023.12.0`
- :doc:`2023.11.0`
- :doc:`2023.10.0`
- :doc:`2023.9.0`
- :doc:`2023.8.0`
- :doc:`2023.7.0`
- :doc:`2023.6.0`
- :doc:`2023.5.0`
- :doc:`2023.4.0`
- :doc:`2023.3.0`
- :doc:`2023.2.0`
- :doc:`2022.12.0`
- :doc:`2022.11.0`
- :doc:`2022.10.0`
- :doc:`2022.9.0`
- :doc:`2022.8.0`
- :doc:`2022.6.0`
- :doc:`2022.5.0`
- :doc:`2022.4.0`
- :doc:`2022.3.0`
- :doc:`2022.2.0`
- :doc:`2022.1.0`
- :doc:`2021.12.0`
- :doc:`2021.11.0`
- :doc:`2021.10.0`
- :doc:`2021.9.0`
- :doc:`2021.8.0`
- :doc:`v1.20.0`
- :doc:`v1.19.0`
- :doc:`v1.18.0`
- :doc:`v1.17.0`
- :doc:`v1.16.0`
- :doc:`v1.15.0`
- :doc:`v1.14.0`
- :doc:`v1.13.0`
- :doc:`v1.12.0`
- :doc:`v1.11.0`
- :doc:`v1.10.0`
- :doc:`v1.9.0`
- :doc:`v1.8.0`
- :doc:`v1.7.0`

2
changelog/index.rst
View File

@ -2,7 +2,7 @@ Changelog
=========
.. redirect::
:url: /changelog/2023.11.0.html
:url: /changelog/2024.3.0.html
.. toctree::
:glob:

40
components/alarm_control_panel/index.rst
View File

@ -44,6 +44,11 @@ Configuration variables:
when the alarm state changes to ``disarmed``. See :ref:`alarm_control_panel_on_disarmed_trigger`.
- **on_cleared** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the alarm clears. See :ref:`alarm_control_panel_on_cleared_trigger`.
- **on_ready** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the logical 'and' of all the zone sensors change state. See :ref:`alarm_control_panel_on_ready_trigger`.
- **on_chime** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when a zone has been marked as chime in the configuration, and it changes from closed to open.
See :ref:`alarm_control_panel_on_chime_trigger`.
Automation:
@ -184,6 +189,39 @@ This trigger is activated when the alarm changes from to disarmed.
then:
- logger.log: "Alarm Disarmed!"
.. _alarm_control_panel_on_ready_trigger:
``on_ready`` Trigger
********************
This trigger is activated when the logical 'and' of all the alarm sensors change state. This is useful for implementing "alarm ready" LEDs.
Once this trigger is called, you can get the ready state by calling get_all_sensors_ready() in a lambda block.
.. code-block:: yaml
alarm_control_panel:
# ...
on_disarmed:
then:
- lambda: !lambda |-
ESP_LOGI("AlarmPanel", "Sensor ready change to: %s", ((id(acp1).get_all_sensors_ready()) ? (const char *) "True" : (const char *) "False"));
.. _alarm_control_panel_on_chime_trigger:
``on_chime`` Trigger
********************
This trigger is activated when a zone sensor marked with chime:true changes from closed to open. This is useful for implementing keypad chimes when a zone
opens.
.. code-block:: yaml
alarm_control_panel:
# ...
on_chime:
then:
- logger.log: "Alarm Chime!"
.. _alarm_control_panel_arm_away_action:
``arm_away`` Action
@ -296,6 +334,7 @@ From :ref:`lambdas <config-lambda>`, you can call the following methods:
- ``arm_home(code)``
- ``arm_night(code)``
- ``disarm(code)``
- ``get_all_sensors_ready()``
.. code-block:: cpp
@ -303,6 +342,7 @@ From :ref:`lambdas <config-lambda>`, you can call the following methods:
id(acp1).arm_home();
id(acp1).arm_night();
id(acp1).disarm(std::string("1234"));
bool all_sensors_ready = id(acp1).get_all_sensors_ready();
Platforms

86
components/alarm_control_panel/template.rst
View File

@ -36,6 +36,8 @@ Configuration variables:
- **input** (**Required**, string): The id of the binary sensor component
- **bypass_armed_home** (*Optional*, boolean): This binary sensor will not trigger the alarm when in ``armed_home`` state.
- **bypass_armed_night** (*Optional*, boolean): This binary sensor will not trigger the alarm when in ``armed_night`` state.
- **trigger_mode** (*Optional*, string): Sets the trigger mode for this sensor. One of ``delayed``, ``instant``, or ``delayed_follower``. (``delayed`` is the default if not specified)
- **chime** (*Optional*, boolean): When set ``true``, the chime callback will be called whenever the sensor goes from closed to open. (``false`` is the default if not specified)
- **restore_mode** (*Optional*, enum):
@ -46,9 +48,33 @@ Configuration variables:
.. note::
If ``binary_sensors`` is ommited then you're expected to trigger the alarm using
If ``binary_sensors`` is omitted then you're expected to trigger the alarm using
:ref:`alarm_control_panel_pending_action` or :ref:`alarm_control_panel_triggered_action`.
.. _template_alarm_control_panel-trigger_modes:
Trigger Modes
-------------
Each binary sensor "zone" supports 3 trigger modes. The 3 trigger modes are:
- delayed
- instant
- delayed_follower
The ``delayed`` trigger mode is typically specified for exterior doors where entry is required to access an alarm keypad or other arm/disarm method. If the alarm panel is armed, and a zone set to ``delayed`` is "faulted" (i.e. the zone state is ``true``) the alarm state will change from the ``armed`` state to the ``pending`` state. During the ``pending`` state, the user has a preset time to disarm the alarm before it changes to the ``triggered`` state. This is the default trigger mode if not specified.
The ``instant`` trigger mode is typically used for exterior zones (e.g. windows, and glass break detectors). If the alarm control panel is armed, a fault on this type of zone will cause the alarm to go from the ``armed`` state directly to the ``triggered`` state.
The ``delayed_follower`` trigger mode is typically specifed for interior passive infared (PIR) or microwave sensors. One of two things happen when a ``delayed_follower`` zone is faulted:
1. When the alarm panel is in the armed state, a fault on a zone with ``delayed_follower`` specified will cause the alarm control panel to go directly to the ``triggered`` state.
2. When the alarm panel is in the pending state, a fault on a zone with ``delayed_follower`` specified will remain in the ``pending`` state.
The ``delayed_follower`` trigger mode offers better protection if someone enters a premises via an unprotected window or door. If there is a PIR guarding the main hallway, it will cause an instant trigger of the alarm panel as someone
entered the premises in a unusual manner. Likewise, if someone enters the premises though a door set to the ``delayed`` trigger mode, and then triggers the PIR, the alarm will stay in the ``pending`` state until either they disarm the alarm, or
the pending timer expires.
.. _template_alarm_control_panel-state_flow:
@ -63,18 +89,29 @@ State Flow:
3. When the alarm is tripped by a sensor state changing to ``on`` or ``alarm_control_panel_pending_action`` invoked
a. ``pending_time`` greater than 0 the state is ``PENDING``
b. ``pending_time`` is 0 or after the ``pending_time`` delay the state is ``TRIGGERED``
1. If trigger_mode is set to ``delayed``:
1. ``pending_time`` greater than 0 the state is ``PENDING``
2. ``pending_time`` is 0 or after the ``pending_time`` delay the state is ``TRIGGERED``
2. If trigger_mode is set to ``instant``:
1. The state is set to ``TRIGGERED``
3. If the trigger_mode is set to ``interior_follower``:
1. If the current state is ``ARMED_...`` the state will be set to ``TRIGGERED``
2. If the current state is ``PENDING`` then nothing will happen and it will stay in the ``PENDING`` state.
4. If ``trigger_time`` greater than 0 and no sensors are ``on`` after ``trigger_time`` delay
the state returns to ``ARM_...``
.. note::
Although the interface supports all arming modes only ``away`` and ``home`` have been implemented for now.
Although the interface supports all arming modes only ``away``, ``home`` and ``night`` have been implemented for now.
``arm_...`` is for either ``arm_away`` or ``arm_home``
``arming_..._time`` is for either ``arming_away_time`` or ``arming_home_time``
``ARMED_...`` is for either ``ARMED_AWAY`` or ``ARMED_HOME``
``arming_..._time`` is for either ``arming_away_time``, ``arming_home_time``, or ``arming_night_time``
``ARMED_...`` is for either ``ARMED_AWAY``, ``ARMED_HOME``, or ``ARMED_NIGHT``
Example:
@ -95,8 +132,16 @@ Example:
trigger_time: 5min
binary_sensors:
- input: zone_1
chime: true
trigger_mode: delayed
- input: zone_2
chime: true
trigger_mode: delayed
- input: zone_3
bypass_armed_home: true
trigger_mode: delayed_follower
- input: zone_4
trigger_mode: instant
- input: ha_test
on_state:
then:
@ -108,6 +153,15 @@ Example:
on_cleared:
then:
- switch.turn_off: siren
on_ready:
then:
- lambda: !lambda |-
ESP_LOGD("TEST", "Sensor ready change to: %s",
(id(acp1).get_all_sensors_ready())) ? (const char *) "True" : (const char *) "False");
on_chime:
then:
- lambda: !lambda |-
ESP_LOGD("TEST", "Zone with chime mode set opened");
binary_sensor:
- platform: gpio
@ -121,14 +175,30 @@ Example:
- platform: gpio
id: zone_2
name: Zone 2
device_class: motion
device_class: door
pin:
number: D2
mode: INPUT_PULLUP
inverted: True
- platform: gpio
id: zone_3
name: Zone 3
device_class: motion
pin:
number: D3
mode: INPUT_PULLUP
inverted: True
- platform: gpio
id: zone_4
name: Zone 4
device_class: door
pin:
number: D4
mode: INPUT_PULLUP
inverted: True
- platform: homeassistant
id: ha_test
name: Zone 3
name: HA Test
entity_id: input_boolean.test_switch
switch:

29
components/binary_sensor/ble_presence.rst
View File

@ -30,10 +30,15 @@ The ``ble_presence`` binary sensor platform lets you track the presence of a Blu
mac_address: AC:37:43:77:5F:4C
name: "ESP32 BLE Tracker Google Home Mini"
min_rssi: -80dB
# Presence based on Identity Resolving Key (IRK)
- platform: ble_presence
irk: 1234567890abcdef1234567890abcdef
name: "ESP32 BLE Tracker iPhone"
# Presence based on BLE Service UUID
- platform: ble_presence
service_uuid: '11aa'
name: "ESP32 BLE Tracker Test Service 16 bit"
timeout: 45s
# Presence based on iBeacon UUID
- platform: ble_presence
ibeacon_uuid: '68586f1e-89c2-11eb-8dcd-0242ac130003'
@ -51,14 +56,17 @@ Configuration variables:
- **name** (**Required**, string): The name of the binary sensor.
- **mac_address** (*Optional*, MAC Address): The MAC address to track for this
binary sensor. Note that exactly one of ``mac_address``, ``service_uuid`` or ``ibeacon_uuid``
binary sensor. Note that exactly one of ``mac_address``, ``irk``, ``service_uuid`` or ``ibeacon_uuid``
must be present.
- **irk** (*Optional*, 16 byte hex string): The Identity Resolving Key (IRK) to track for this
binary sensor. Note that exactly one of ``mac_address``, ``irk``, ``service_uuid`` or ``ibeacon_uuid``
must be present.
- **service_uuid** (*Optional*, string): 16 bit, 32 bit, or 128 bit BLE Service UUID
which can be tracked if the device randomizes the MAC address. Note that exactly one of
``mac_address``, ``service_uuid`` or ``ibeacon_uuid`` must be present.
``mac_address``, ``irk``, ``service_uuid`` or ``ibeacon_uuid`` must be present.
- **ibeacon_uuid** (*Optional*, string): The `universally unique identifier <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__
to identify the beacon that needs to be tracked. Note that exactly one of ``mac_address``,
``service_uuid`` or ``ibeacon_uuid`` must be present.
``irk``, ``service_uuid`` or ``ibeacon_uuid`` must be present.
- **ibeacon_major** (*Optional*, int): The iBeacon major identifier of the beacon that needs
to be tracked. Usually used to group beacons, for example for grouping all beacons in the
same building.
@ -66,7 +74,9 @@ Configuration variables:
to be tracked. Usually used to identify beacons within an iBeacon group.
- **id** (*Optional*, :ref:`config-id`): Manually specify
the ID used for code generation.
- **min_rssi** (*Optional*, int): at which minimum RSSI level would the component report the device be precent
- **min_rssi** (*Optional*, int): at which minimum RSSI level would the component report the device be present.
- **timeout** (*Optional*, :ref:`config-time`): The delay after last detecting the device before publishing not present state.
The default is 5 minutes.
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
.. _esp32_ble_tracker-setting_up_devices:
@ -105,8 +115,15 @@ iBeacon major and minor identifiers, BLE manufacturer data, RSSI and other data
debugging purposes. Note that this is useful only during set-up and a less verbose log level
should be specified afterwards.
Please note that devices that show a ``RANDOM`` address type in the logs cannot be used for
MAC address based tracking, since their MAC-address periodically changes. Instead you can:
Please note that devices that show a ``RANDOM`` address type in the logs probably use a privacy
feature called Resolvable Private Addresses to avoid BLE tracking. Since their MAC-address periodically
changes, they can't be tracked by the MAC address. However, if you know the devices "Identity Resolving
Key" (IRK), you can check if the generated private MAC address belongs to the device with the IRK.
There is no support to obtain the key with ESPHome. For now you will have to use one of the options
described in the ESPresense project: https://espresense.com/beacons
Alternatively you can:
- Create a BLE beacon, set a unique 16 bit, 32 bit or 128 bit Service UUID and track your device
based on that. Make sure you don't pick a `GATT Service UUID

29
components/binary_sensor/esp32_touch.rst
View File

@ -149,6 +149,35 @@ Configuration variables:
wake-up from a touch event. Note that no filter(s) is/are active during deep sleep.
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
Raw Values
----------
If access to the raw values is required, a template sensor can be created that polls for them:
.. code-block:: yaml
# Example configuration entry for accessing raw values
esp32_touch:
id: esp32_touch_1
binary_sensor:
- platform: esp32_touch
id: esp32_touch_pad
pin: GPIO4
threshold: 0
sensor:
- platform: template
name: "Raw touch value"
lambda: |-
return id(esp32_touch_pad).get_value();
update_interval: 3s
One example of use is a wide area pressure sensor that integrates a number of smaller sensors in an area. Make two strips
of aluminium foil that sandwich paper, and connect one wire to a touch pin and the other to ground. Set up several sensors
under a flexible object like a plastic mat, add the raw values, and apply a threshold.
.. _esp32-touch-pad-pins:
Touch Pad Pins

68
components/binary_sensor/haier.rst Normal file
View File

@ -0,0 +1,68 @@
Haier Climate Binary Sensors
============================
.. seo::
:description: Instructions for setting up additional binary sensors for Haier climate devices.
:image: haier.svg
Additional sensors for Haier Climate device. **These sensors are supported only by the hOn protocol**.
.. figure:: images/haier-climate.jpg
:align: center
:width: 50.0%
.. code-block:: yaml
# Example configuration entry
uart:
baud_rate: 9600
tx_pin: 17
rx_pin: 16
id: ac_port
climate:
- platform: haier
id: haier_ac
protocol: hOn
name: Haier AC
uart_id: ac_port
binary_sensor:
- platform: haier
haier_id: haier_ac
compressor_status:
name: Haier Outdoor Compressor Status
defrost_status:
name: Haier Defrost Status
four_way_valve_status:
name: Haier Four Way Valve Status
indoor_electric_heating_status:
name: Haier Indoor Electric Heating Status
indoor_fan_status:
name: Haier Indoor Fan Status
outdoor_fan_status:
name: Haier Outdoor Fan Status
Configuration variables:
------------------------
- **haier_id** (**Required**, :ref:`config-id`): The id of haier climate component
- **compressor_status** (*Optional*): A binary sensor that indicates Haier climate compressor activity.
All options from :ref:`Binary Sensor <config-binary_sensor>`.
- **defrost_status** (*Optional*): A binary sensor that indicates defrost procedure activity.
All options from :ref:`Binary Sensor <config-binary_sensor>`.
- **four_way_valve_status** (*Optional*): A binary sensor that indicates four way valve status.
All options from :ref:`Binary Sensor <config-binary_sensor>`.
- **indoor_electric_heating_status** (*Optional*): A binary sensor that indicates electrical heating system activity.
All options from :ref:`Binary Sensor <config-binary_sensor>`.
- **indoor_fan_status** (*Optional*): A binary sensor that indicates indoor fan activity.
All options from :ref:`Binary Sensor <config-binary_sensor>`.
- **outdoor_fan_status** (*Optional*): A binary sensor that indicates outdoor fan activity.
All options from :ref:`Binary Sensor <config-binary_sensor>`.
See Also
--------
- :doc:`Haier Climate </components/climate/haier>`
- :ghedit:`Edit`

BIN
components/binary_sensor/images/haier-climate.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

12
components/binary_sensor/index.rst
View File

@ -35,7 +35,7 @@ Configuration variables:
you want the binary sensor to use that name, you can set ``name: None``.
- **device_class** (*Optional*, string): The device class for the
sensor. See https://developers.home-assistant.io/docs/core/entity/binary-sensor/#available-device-classes
sensor. See https://www.home-assistant.io/integrations/binary_sensor/#device-class
for a list of available options.
- **icon** (*Optional*, icon): Manually set the icon to use for the binary sensor in the frontend.
- **filters** (*Optional*, list): A list of filters to apply on the binary sensor values such as
@ -208,6 +208,16 @@ Specify any :ref:`lambda <config-lambda>` for more complex filters. The input va
the binary sensor is ``x`` and you can return ``true`` for ON, ``false`` for OFF, and ``{}`` to stop
the filter chain.
``settle``
**********
(**Required**, time, :ref:`templatable <config-templatable>`): When a signal is received, publish the state
but wait for the received state to remain the same for specified time period before publishing any
additional state changes. This filter complements the ``delayed_on_off`` filter but publishes value changes at
the beginning of the delay period.
When using a lambda call, you should return the delay value in milliseconds.
**Useful for debouncing binary switches**.
Binary Sensor Automation
------------------------

48
components/binary_sensor/modbus_controller.rst
View File

@ -16,26 +16,25 @@ Configuration variables:
- **name** (**Required**, string): The name of the sensor.
- **register_type** (**Required**): type of the modbus register.
- ``coil``: Function 01 (01hex) Read Coils - Reads the ON/OFF status of discrete coils in the device.
- ``discrete_input``: Function 02(02hex) - Reads the ON/OFF status of discrete inputs in the device.
- ``holding``: Function 03 (03hex) Read Holding Registers - Read the binary contents of holding registers in the device.
- ``read``: Function 04 (04hex) Read Input Registers - Read the binary contents of input registers in the device.
- ``coil``: Coils are 1-bit registers (ON/OFF values) that are used to control discrete outputs. Read and Write access. Modbus *Function Code 1 (Read Coil Status)* will be used.
- ``discrete_input``: discrete input register (read only coil) are similar to coils but can only be read. Modbus *Function Code 2 (Read Input Status)* will be used.
- ``holding``: Holding Registers - Holding registers are the most universal 16-bit register. Read and Write access. Modbus *Function Code 3 (Read Holding Registers)* will be used.
- ``read``: Read Input Registers - registers are 16-bit registers used for input, and may only be read. Modbus *Function Code 4 (Read Input Registers)* will be used.
- **address** (**Required**, int): start address of the first register in a range
- **bitmask** (*Optional*, int): 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 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
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **bitmask** (*Optional*, int): sometimes multiple values are packed in a single register's response. The bitmask is used to determined if the result is true or false. See :ref:`bitmasks`.
- **skip_updates** (*Optional*, int): By default all sensors 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 components by address ranges to reduce number of transactions. All components with the same starting address will be updated in one request. ``skip_updates`` applies for *all* components in the same range.
- **register_count** (*Optional*, int): The number of consecutive registers this read request should span or skip in a single command. Default is 1. See :ref:`modbus_register_count` for more details.
- **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_command** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_command`` 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_command` how to use ``custom_command``
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_command` 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
Parameters
Lambda to be evaluated every update interval to get the new value of the sensor. Parameters:
- **x** (bool): The parsed float value of the modbus data
- **data** (std::vector<uint8_t): vector containing the complete raw modbus response bytes for this sensor
- **data** (std::vector<uint8_t>): vector containing the complete raw modbus response bytes for this sensor
- **item** (const pointer to a ModbusBinarySensor object): The sensor object itself.
Possible return values for the lambda:
@ -43,21 +42,19 @@ Configuration variables:
- ``return true/false;`` the new value for the sensor.
- **offset** (*Optional*, int): not required for most cases
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
The value for offset depends on the register type. If a binary_sensor is created from an input register the offset is in bytes. For coil and discrete input resisters the LSB of the first data byte contains the coil addressed in the request. The other coils follow toward the high-order end of this byte and from low order to high order in subsequent bytes. For the registers offset is the position of the relevant bit.
To get the value of the coil register 2 can be retrieved using address: 2 / offset: 0 or address: 0 / offset 2
- **offset** (*Optional*, int): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a command, this value is used to find the start of this datapoint relative to the start address. The component calculates the size of the range based on offset and size of the value type. The value for offset depends on the register type. If a binary_sensor is created from an input register, the offset is in bytes. For coil and discrete input resisters, the LSB of the first data byte contains the coil addressed in the request. The other coils follow toward the high-order end of this byte and from low order to high order in subsequent bytes. For registers, the offset is the position of the relevant bit. To get the value of the coil register, 2 can be retrieved using ``address: 2`` / ``offset: 0`` or ``address: 0`` / ``offset 2``.
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
Example
Example:
--------
.. code-block:: yaml
binary_sensor:
- platform: modbus_controller
modbus_controller_id: epever
id: battery_internal_resistance_abnormal
name: "Battery internal resistance abnormal"
modbus_controller_id: modbus1
name: "Error status"
register_type: read
address: 0x3200
bitmask: 0x80 #(bit 8)
@ -65,11 +62,14 @@ Example
See Also
--------
- :apiclass:`:modbus_controller::ModbusBinarySensor`
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- https://www.modbustools.com/modbus.html
- :apiclass:`:modbus_controller::ModbusBinarySensor`
- :ghedit:`Edit`

90
components/binary_sensor/nfc.rst Normal file
View File

@ -0,0 +1,90 @@
NFC Binary Sensor
=================
.. seo::
:description: Instructions for setting up a NFC binary sensor in ESPHome
:image: nfc.png
:keywords: PN532, PN7150, PN7160, NFC
.. _nfc-platform:
The ``nfc`` binary sensor platform provides an easy way for you to determine if an NFC tag is presented to the reader.
The tag may be identified in one of three ways:
- By given unique ID (``uid``) -- for example ``74-10-37-94``
- By a given NDEF tag "name", or...
- By a given string contained in the tag's NDEF message/data
Note that this platform is currently supported by the :doc:`PN7150 <../pn7150>` and :doc:`PN716x <../pn7160>` only;
one of these components must be present in your device's configuration in order to use it.
.. code-block:: yaml
# Example configuration entries
binary_sensor:
- platform: nfc
ndef_contains: pulse
name: "NFC 1 Tag"
- platform: nfc
tag_id: pulsed
name: "NFC 2 Tag"
- platform: nfc
uid: 74-10-37-94
name: "MFC Tag"
Configuration variables:
------------------------
- **ndef_contains** (*Optional*, string): A (sub)string that must appear in the tag's NDEF message. May not be used
with ``tag_id`` and/or ``uid`` (below).
- **tag_id** (*Optional*, string): A string that identifies the tag; in effect, its name. Specifically, this looks
for the Home Assistant URI encoded into one of the tag's NDEF records and then looks for this specific string. May
not be used with ``ndef_contains`` and/or ``uid``.
- **uid** (*Optional*, string): The unique ID of the NFC tag. This is a hyphen-separated list of hexadecimal values.
For example: ``74-10-37-94``. May not be used with ``ndef_contains`` and/or ``tag_id`` (above).
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
.. _nfc-setting_up_tags:
Setting Up Tags
---------------
To set up a binary sensor for a given NFC tag, you must first know either its unique ID (``uid``), tag ID (if it was
prepared using the Home Assistant Companion app) or (part of) a string that is contained within its NDEF message.
To obtain a tag's UID:
- Set up a simple NFC component (such as the :doc:`PN532 <pn532>`, :doc:`PN7150 <../pn7150>` or :doc:`PN716x <../pn7160>`)
configuration without any binary sensors.
- Approach the NFC reader with an NFC tag. When the tag is sufficiently close to the reader, you'll see a message in the
ESPHome device's logs similar to this:
.. code::
Read tag type Mifare Classic with UID 1C-E5-E7-A6
- Either:
- Copy this ID and use it to create a ``binary_sensor`` entry as shown in the configuration example above, or...
- Use the tag ID (as determined when it was prepared with the Home Assistant Companion app) to define the ``tag_id``
parameter for the ``binary_sensor`` as shown above, or...
- Choose a substring contained within the tag's NDEF message and use this to define the ``ndef_contains`` parameter
as shown in the example above. If present, the tag's NDEF records will appear in the log on the lines just below
the message shown above.
Repeat this process for each tag.
Note that, since *you* are able to define the NDEF message, this approach is more flexible and even allows multiple
cards/tags to share the same message.
See Also
--------
- :doc:`index`
- :doc:`pn532`
- :doc:`../pn7150`
- :doc:`../pn7160`
- :apiref:`pn532/pn532.h`
- :apiref:`pn7150/pn7150.h`
- :apiref:`pn7160/pn7160.h`
- :ghedit:`Edit`

55
components/ble_client.rst
View File

@ -38,11 +38,13 @@ to discover available client devices.
ble_client:
- mac_address: FF:FF:20:00:0F:15
id: itag_black
auto_connect: true
Configuration variables:
------------------------
- **mac_address** (**Required**, MAC Address): The MAC address of the BLE device to connect to.
- **auto_connect** (*Optional*, boolean): If true the device will be automatically connected when found by the :doc:`/components/esp32_ble_tracker`. Defaults to true.
- **id** (**Required**, :ref:`config-id`): The ID to use for code generation, and for reference by dependent components.
Automations:
@ -153,6 +155,57 @@ This automation is triggered when a numeric comparison is requested by the BLE d
id: ble_itag
accept: True
.. _ble_client-connect_action:
``ble_client.connect`` Action
-----------------------------
This action is useful only for devices with ``auto_connect: false`` and allows a connection to be made from
within an automation. Once connected other actions like ``ble_write`` can be used. This is useful where
a BLE server needs only to be interacted with occasionally, and thus does not need a constant
connection held.
The following example updates the time of a Xiaomi MHO-C303 clock once per hour. Note that the BLE tracker must
be stopped during the connect attempt, and restarted afterwards. This would not be necessary if the tracker had
``continuous: false`` set. In this example scenario there is another BLE device that does require the scanner to be
on, hence the stop and start of the scan during connect.
.. code-block:: yaml
ble_client:
- id: ble_clock
mac_address: 17:75:BC:F2:94:4D
auto_connect: false
- id: other_device
mac_address: 0D:33:12:66:00:D4
interval:
- interval: 60min
then:
- esp32_ble_tracker.stop_scan:
- ble_client.connect: ble_clock
- ble_client.ble_write:
id: ble_clock
service_uuid: EBE0CCB0-7A0A-4B0C-8A1A-6FF2997DA3A6
characteristic_uuid: EBE0CCB7-7A0A-4B0C-8A1A-6FF2997DA3A6
value: !lambda |-
uint32_t t = id(sntp_time).now().timestamp + ESPTime::timezone_offset();
return {(uint8_t)t, (uint8_t)(t >> 8), (uint8_t)(t >> 16), (uint8_t)(t >> 24), 0};
- ble_client.disconnect: ble_clock
- esp32_ble_tracker.start_scan:
Any actions after the ``connect`` action will proceed only after the connect succeeds. If the connect
fails the subsequent actions in the automation block will *not* be executed. This should be considered
if scanning has been stopped - another mechanism may be required to restart it.
.. _ble_client-disconnect_action:
``ble_client.disconnect`` Action
--------------------------------
This action disconnects a device that was connected with the ``ble_client.connect`` action.
Execution of the automation block sequence resumes after the disconnect has completed.
.. _ble_client-ble_write_action:
``ble_client.ble_write`` Action
@ -161,6 +214,8 @@ This automation is triggered when a numeric comparison is requested by the BLE d
This action triggers a write to a specified BLE characteristic. The write is attempted in
a best-effort fashion and will only succeed if the ``ble_client``'s connection has been
established and the peripheral exposes the expected BLE service and characteristic.
Execution of the automation block sequence resumes after the write has completed. A write failure will *not*
stop execution of succeeding actions (this allows a disconnect to be executed, for example.)
Example usage:

2
components/bluetooth_proxy.rst
View File

@ -11,7 +11,7 @@ Integration in Home Assistant which automatically aggregates all ESPHome Bluetoo
Adapters you might have. This exceptional feature offers fault tolerant connection between the Bluetooth devices
and Home Assistant.
Note that while ths component is named ``bluetooth_proxy``, only BLE devices (and their Home Assistant integrations)
Note that while this component is named ``bluetooth_proxy``, only BLE devices (and their Home Assistant integrations)
are supported.
If you're looking to create an ESPHome node that is just a Bluetooth Proxy, see

2
components/button/index.rst
View File

@ -57,7 +57,7 @@ Configuration variables:
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
See https://www.home-assistant.io/integrations/button/#device-class
for a list of available options.
Automations:

2
components/climate/bang_bang.rst
View File

@ -70,6 +70,8 @@ Configuration variables:
------------------------
- **sensor** (**Required**, :ref:`config-id`): The sensor that is used to measure the current temperature.
- **humidity_sensor** (**Optional**, :ref:`config-id`): If specified, this sensor is used to measure the current humidity.
This is used for information only and does not influence temperature control.
- **default_target_temperature_low** (**Required**, float): The default low target temperature for
the control algorithm. This can be dynamically set in the frontend later.
- **default_target_temperature_high** (**Required**, float): The default high target temperature for

48
components/climate/climate_ir.rst
View File

@ -31,6 +31,8 @@ submit a feature request (see FAQ).
+---------------------------------------+---------------------+----------------------+
| :ref:`Delonghi<delonghi_ir>` | ``delonghi`` | yes |
+---------------------------------------+---------------------+----------------------+
| Emmeti | ``emmeti`` | yes |
+---------------------------------------+---------------------+----------------------+
| Fujitsu General | ``fujitsu_general`` | yes |
+---------------------------------------+---------------------+----------------------+
| :ref:`GREE<gree_ir>` | ``gree`` | |
@ -42,7 +44,7 @@ submit a feature request (see FAQ).
+---------------------------------------+---------------------+----------------------+
| Midea | ``midea_ir`` | yes |
+---------------------------------------+---------------------+----------------------+
| Mitsubishi | ``mitsubishi`` | |
| :ref:`Mitsubishi<mitsubishi>` | ``mitsubishi`` | yes |
+---------------------------------------+---------------------+----------------------+
| Noblex | ``noblex`` | yes |
+---------------------------------------+---------------------+----------------------+
@ -253,6 +255,48 @@ Known working with:
- Delonghi PAC WE 120HP
.. _mitsubishi:
``mitsubishi`` Climate
------------------------
Additonal configurations available for this platform.
Configuration variables:
- **set_fan_mode** (*Optional*, string): Select the fan modes desired or that are supported on your remote. Defaults to ``3levels``
- Options are: ``3levels`` , ``4levels``, ``quiet_4levels``.
- ``3levels``; Low [fan speed 1], Medium [2], High [3]
- ``4levels``; Low [1], Middle [2], Medium [3], High [4]
- ``quiet_4levels``; Low [1], Middle [2], Medium [3], High [4], Quiet [5]
- **supports_dry** (*Optional*, boolean): Enables setting dry mode for this unit. Defaults to ``false``.
- **supports_fan_only** (*Optional*, boolean): Enables setting fan only mode for this unit. Confirm that mode is supported on your remote. Defaults to ``false``.
- **horizontal_default** (*Optional*, string): What to default to when the AC unit's horizontal direction is *not* set to swing. Defaults to ``middle``.
- Options are: ``left``, ``middle-left``, ``middle``, ``middle-right``, ``right``, ``auto``
- **vertical_default** (*Optional*, string): What to default to when the AC unit's vertical direction is *not* set to swing. Defaults to ``middle``.
- Options are: ``down``, ``middle-down``, ``middle``, ``middle-up``, ``up``, ``auto``
.. note::
- This climate IR component is also known to work with some Stiebel Eltron Units. It has been tested with Stiebel Eltron IR-Remote ``KM07F`` and unit ``ACW 25 i``
.. code-block:: yaml
# Example configuration entry
climate:
- platform: mitsubishi
name: "Heatpump"
set_fan_mode: "quiet_4levels"
supports_dry: "true"
supports_fan_only: "true"
horizontal_default: "left"
vertical_default: "down"
.. _toshiba:
@ -284,7 +328,7 @@ Configuration variables:
``update_interval`` must be less than seven minutes or the ``RAC-PT1411HWRU`` will revert to using its own
internal temperature sensor; a value of 30 seconds seems to work well. See :doc:`/components/sensor/index`
for more information.
- This climate IR component is also known to work with Midea model MAP14HS1TBL and may work with other similar
models, as well. (Midea acquired Toshiba's product line and re-branded it.)

141
components/climate/haier.rst
View File

@ -2,14 +2,14 @@ Haier Climate
=============
.. seo::
:description: Instructions for setting up a Haier climate devices.
:description: Instructions for setting up Haier climate devices.
:image: air-conditioner.svg
This is an implementation of the ESPHome component to control HVAC on the base of the SmartAir2 and hOn Haier protocols (AC that is controlled by the hOn or SmartAir2 application).
There are two versions of the Haier protocol. The older one is using an application called SmartAir2 and the newer one - an application called hOn. Both protocols are compatible on the transport level but have different commands to control appliances.
There are two versions of the Haier protocol: the older version uses an application called SmartAir2 while the newer version uses an application called hOn. Both protocols are compatible on the transport level but utilize different commands to control appliances.
Older Haier models controlled by the SmartAir2 application are using the KZW-W002 module. This module can’t be reused, and you need to replace it with an ESP (RPI pico w) module. The USB connector on a board doesn’t support the USB protocol. It is a UART port that just uses a USB connector. To connect the ESP board to your AC you can cut a USB type A cable and connect wires to the climate connector.
Older Haier models controlled by the SmartAir2 application are using the KZW-W002 module. This module can’t be reused, and you need to replace it with an ESP or RPI Pico W module. The USB connector on the board doesn’t support the USB protocol. It is a UART port that just uses a USB connector. To connect the ESP board to your AC you can cut a USB type A cable and connect wires to the climate connector.
.. list-table:: Haier UART pinout
:header-rows: 1
@ -43,7 +43,7 @@ Older Haier models controlled by the SmartAir2 application are using the KZW-W00
Newer Haier models using a module called ESP32-for-Haier. It is an ESP32 single-core board with an ESP32-S0WD chip. In some cases, you can reuse this module and flash it with ESPHome, but some new modules don’t support this. They look the same but have encryption enabled.
**Warning!** The new generation of ESP32-Haier devices has encryption enabled, so they can only be flashed with firmware that is signed with a private key. There is no way to make them work with ESPHome, so if you try to do it, the board will get into a boot loop with error ``rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)`` The only way to recover this board is to flash it with the original image. So before starting your experiments make a backup image.
**Warning!** The new generation of ESP32-Haier devices has encryption enabled, so they can only be flashed with firmware that is signed with a private key. There is no way to make them work with ESPHome, so if you try to do it, the board will get into a boot loop with the error ``rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)`` The only way to recover this board is to flash it with the original image. So before starting your experiments make a backup image.
.. figure:: images/haier_pinout.jpg
:align: center
@ -51,7 +51,7 @@ Newer Haier models using a module called ESP32-for-Haier. It is an ESP32 single-
ESP32-for-Haier UART0 pinout
Also, you can use any other ESP32, ESP8266 or a RPI pico W board. In this case, you will need to cut the original wire or make a connector yourself (the board has a JST SM04B-GHS-TB connector)
Also, you can use any other ESP32, ESP8266, or an RPI pico W board. In this case, you will need to cut the original wire or make a connector yourself (the board has a JST SM04B-GHS-TB connector)
This component requires a :ref:`uart` to be setup.
@ -74,8 +74,6 @@ This component requires a :ref:`uart` to be setup.
wifi_signal: true
beeper: true
display: true
outdoor_temperature:
name: Haier AC outdoor temperature
visual:
min_temperature: 16 °C
max_temperature: 30 °C
@ -92,10 +90,23 @@ This component requires a :ref:`uart` to be setup.
- VERTICAL
- HORIZONTAL
- BOTH
supported_presets:
- ECO
- BOOST
- SLEEP
supported_presets:
- AWAY
- ECO
- BOOST
- SLEEP
on_alarm_start:
then:
- logger.log:
level: WARN
format: "Alarm activated. Code: %d. Message: \"%s\""
args: [ code, message]
on_alarm_end:
then:
- logger.log:
level: INFO
format: "Alarm deactivated. Code: %d. Message: \"%s\""
args: [ code, message]
Configuration variables:
@ -103,27 +114,63 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **uart_id** (*Optional*, :ref:`config-id`): ID of the UART port to communicate with AC.
- **protocol** (*Optional*, string): Defines protocol of communication with AC. Possible values: hon or smartair2. Default value is smartair2.
- **protocol** (*Optional*, string): Defines communication protocol with AC. Possible values: hon or smartair2. The default value is smartair2.
- **name** (**Required**, string): The name of the climate device.
- **wifi_signal** (*Optional*, boolean): If true - send wifi signal level to AC.
- **answer_timeout** (*Optional*, :ref:`config-time`): Responce timeout. Default value is 150ms.
- **display** (*Optional*, boolean): Can be used to set AC display off.
- **answer_timeout** (*Optional*, :ref:`config-time`): Responce timeout. The default value is 200ms.
- **alternative_swing_control** (*Optional*, boolean): (supported by smartAir2 only) If true - use alternative values to control swing mode. Use only if the original control method is not working for your AC.
- **control_packet_size** (*Optional*, int): (supported only by hOn) Define the size of the control packet. Can help with some newer models of ACs that use bigger packets. The default value: 10.
- **control_method** (*Optional*, list): (supported only by hOn) Defines control method (should be supported by AC). Supported values: MONITOR_ONLY - no control, just monitor status, SET_GROUP_PARAMETERS - set all AC parameters with one command (default method), SET_SINGLE_PARAMETER - set each parameter individually (this method is supported by some new ceiling ACs like AD71S2SM3FA)
- **display** (*Optional*, boolean): Can be used to set the AC display off.
- **beeper** (*Optional*, boolean): Can be used to disable beeping on commands from AC. Supported only by hOn protocol.
- **outdoor_temperature** (*Optional*): Temperature sensor for outdoor temperature. Supported only by hOn protocol.
- **name** (**Required**, string): The name of the sensor.
- **id** (*Optional*, :ref:`config-id`): ID of the sensor, can be used for code generation
- All other options from :ref:`Sensor <config-sensor>`.
- **supported_modes** (*Optional*, list): Can be used to disable some of AC modes. Possible values: 'OFF', HEAT_COOL, COOL, HEAT, DRY, FAN_ONLY
- **supported_swing_modes** (*Optional*, list): Can be used to disable some swing modes if your AC does not support it. Possible values: 'OFF', VERTICAL, HORIZONTAL, BOTH
- **supported_presets** (*Optional*, list): Can be used to disable some presets. Possible values for smartair2 are: BOOST, COMFORT. Possible values for hOn are: ECO, BOOST, SLEEP
- **supported_presets** (*Optional*, list): Can be used to disable some presets. Possible values for smartair2 are: AWAY, BOOST, COMFORT. Possible values for hOn are: AWAY, ECO, BOOST, SLEEP. AWAY preset can be enabled only in HEAT mode, it is disabled by default
- **on_alarm_start** (*Optional*, :ref:`Automation <automation>`): (supported only by hOn) Automation to perform when AC activates a new alarm. See :ref:`haier-on_alarm_start`
- **on_alarm_end** (*Optional*, :ref:`Automation <automation>`): (supported only by hOn) Automation to perform when AC deactivates a new alarm. See :ref:`haier-on_alarm_end`
- All other options from :ref:`Climate <config-climate>`.
Automations
-----------
climate.haier.power_on Action
*****************************
.. _haier-on_alarm_start:
``on_alarm_start`` Trigger
**************************
This automation will be triggered when a new alarm is activated by AC. The error code of the alarm will be given in the variable "code" (type uint8_t), error message in the variable "message" (type char*). Those variables can be used in :ref:`lambdas <config-lambda>`
.. code-block:: yaml
climate:
- protocol: hOn
on_alarm_start:
then:
- logger.log:
level: WARN
format: "Alarm activated. Code: %d. Message: \"%s\""
args: [ code, message]
.. _haier-on_alarm_end:
``on_alarm_end`` Trigger
************************
This automation will be triggered when a previously activated alarm is deactivated by AC. The error code of the alarm will be given in the variable "code" (type uint8_t), error message in the variable "message" (type char*). Those variables can be used in :ref:`lambdas <config-lambda>`
.. code-block:: yaml
climate:
- protocol: hOn
on_alarm_end:
then:
- logger.log:
level: INFO
format: "Alarm deactivated. Code: %d. Message: \"%s\""
args: [ code, message]
``climate.haier.power_on`` Action
*********************************
This action turns AC power on.
@ -133,8 +180,8 @@ This action turns AC power on.
then:
climate.haier.power_on: device_id
climate.haier.power_off Action
******************************
``climate.haier.power_off`` Action
**********************************
This action turns AC power off
@ -144,8 +191,8 @@ This action turns AC power off
then:
climate.haier.power_off: device_id
climate.haier.power_toggle Action
*********************************
``climate.haier.power_toggle`` Action
*************************************
This action toggles AC power
@ -155,8 +202,8 @@ This action toggles AC power
then:
climate.haier.power_toggle: device_id
climate.haier.display_on Action
*******************************
``climate.haier.display_on`` Action
***********************************
This action turns the AC display on
@ -166,8 +213,8 @@ This action turns the AC display on
then:
climate.haier.display_on: device_id
climate.haier.display_off Action
********************************
``climate.haier.display_off`` Action
************************************
This action turns the AC display off
@ -177,8 +224,8 @@ This action turns the AC display off
then:
climate.haier.display_off: device_id
climate.haier.health_on Action
******************************
``climate.haier.health_on`` Action
**********************************
Turn on health mode (`UV light sterilization <https://www.haierhvac.eu/en/node/1809>`__)
@ -188,8 +235,8 @@ Turn on health mode (`UV light sterilization <https://www.haierhvac.eu/en/node/1
then:
climate.haier.health_on: device_id
climate.haier.health_off Action
*******************************
``climate.haier.health_off`` Action
***********************************
Turn off health mode
@ -199,8 +246,8 @@ Turn off health mode
then:
climate.haier.health_off: device_id
climate.haier.beeper_on Action
******************************
``climate.haier.beeper_on`` Action
**********************************
(supported only by hOn) This action enables beep feedback on every command sent to AC
@ -210,8 +257,8 @@ climate.haier.beeper_on Action
then:
climate.haier.beeper_on: device_id
climate.haier.beeper_off Action
*******************************
``climate.haier.beeper_off`` Action
***********************************
(supported only by hOn) This action disables beep feedback on every command sent to AC (keep in mind that this will not work for IR remote commands)
@ -221,8 +268,8 @@ climate.haier.beeper_off Action
then:
climate.haier.beeper_off: device_id
climate.haier.set_vertical_airflow Action
*****************************************
``climate.haier.set_vertical_airflow`` Action
*********************************************
(supported only by hOn) Set direction for vertical airflow if the vertical swing is disabled. Possible values: Health_Up, Max_Up, Up, Center, Down, Health_Down.
@ -234,8 +281,8 @@ climate.haier.set_vertical_airflow Action
id: device_id
vertical_airflow: Up
climate.haier.set_horizontal_airflow Action
*******************************************
``climate.haier.set_horizontal_airflow`` Action
***********************************************
(supported only by hOn) Set direction for horizontal airflow if the horizontal swing is disabled. Possible values: Max_Left, Left, Center, Right, Max_Right.
@ -247,8 +294,8 @@ climate.haier.set_horizontal_airflow Action
id: device_id
vertical_airflow: Right
climate.haier.start_self_cleaning Action
****************************************
``climate.haier.start_self_cleaning`` Action
********************************************
(supported only by hOn) Start `self-cleaning <https://www.haier.com/in/blogs/beat-the-summer-heat-with-haier-self-cleaning-ac.shtml>`__
@ -258,8 +305,8 @@ climate.haier.start_self_cleaning Action
then:
- climate.haier.start_self_cleaning: device_id
climate.haier.start_steri_cleaning Action
*****************************************
``climate.haier.start_steri_cleaning`` Action
*********************************************
(supported only by hOn) Start 56°C steri-cleaning
@ -273,6 +320,8 @@ See Also
--------
- `haier-esphome <https://github.com/paveldn/haier-esphome>`__
- :doc:`Haier Climate Sensors </components/sensor/haier>`
- :doc:`Haier Climate Binary Sensors </components/binary_sensor/haier>`
- :doc:`/components/climate/index`
- :apiref:`haier/climate/haier.h`
- :ghedit:`Edit`

41
components/climate/index.rst
View File

@ -15,6 +15,10 @@ and can be put in different modes like ``HEAT``, ``COOL``, ``HEAT_COOL`` or ``OF
Climate Device UI in Home Assistant.
.. note::
Not all climate components support all possible features. Check the corresponding documentation page for details on what is supported.
.. _config-climate:
Base Climate Configuration
@ -30,6 +34,15 @@ All climate platforms in ESPHome inherit from the climate configuration schema.
min_temperature: 18
max_temperature: 25
temperature_step: 0.1
min_humidity: 30%
max_humidity: 99%
- platform: ...
visual:
min_temperature: 18
max_temperature: 25
temperature_step:
target_temperature: 0.5
current_temperature: 0.1
Configuration variables:
@ -55,6 +68,11 @@ Configuration variables:
- **target_temperature** (**Required**, float): The granularity for target temperature
- **current_temperature** (**Required**, float): The granularity for current temperature
- **min_humidity** (*Optional*, percentage): The minimum humidity the climate device can reach.
Used to set the range of the frontend gauge.
- **max_humidity** (*Optional*, percentage): The maximum humidity the climate device can reach.
Used to set the range of the frontend gauge.
Advanced options:
- **internal** (*Optional*, boolean): Mark this component as internal. Internal components will
@ -74,6 +92,8 @@ MQTT options:
climate device action changes to.
- **current_temperature_state_topic** (*Optional*, string): The topic to publish
current temperature changes to.
- **current_humidity_state_topic** (*Optional*, string): The topic to publish
current humidity changes to.
- **fan_mode_state_topic** (*Optional*, string): The topic to publish
fan mode changes to.
- **fan_mode_command_topic** (*Optional*, string): The topic to receive
@ -102,19 +122,12 @@ MQTT options:
lower target temperature changes to.
- **target_temperature_low_command_topic** (*Optional*, string): The topic to receive
lower target temperature commands on.
- **target_humidity_state_topic** (*Optional*, string): The topic to publish
target humidity changes to.
- **target_humidity_command_topic** (*Optional*, string): The topic to receive
target humidity commands on.
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
.. code-block:: yaml
climate:
- platform: ...
visual:
min_temperature: 18
max_temperature: 25
temperature_step:
target_temperature: 0.5
current_temperature: 0.1
Climate Automation
------------------
@ -152,6 +165,8 @@ Configuration variables:
lower target temperature of a climate device with a two-point target temperature.
- **target_temperature_high** (*Optional*, float, :ref:`templatable <config-templatable>`): Set the
higher target temperature of a climate device with a two-point target temperature.
- **target_humidity** (*Optional*, float, :ref:`templatable <config-templatable>`): Set the
target humidity of a climate device.
- **preset** (*Optional*, string, :ref:`templatable <config-templatable>`): Set the preset
of the climate device. One of ``ECO``, ``AWAY``, ``BOOST``, ``COMFORT``, ``HOME``, ``SLEEP``,
``ACTIVITY``.
@ -181,12 +196,16 @@ advanced stuff.
id(my_climate).mode
// Current temperature, type: float (degrees)
id(my_climate).current_temperature
// Current humidity, type: float (percentage)
id(my_climate).current_humidity
// Target temperature, type: float (degrees)
id(my_climate).target_temperature
// Lower Target temperature, type: float (degrees)
id(my_climate).target_temperature_low
// High Target temperature, type: float (degrees)
id(my_climate).target_temperature_high
// Target humidity, type: float (percentage)
id(my_climate).target_humidity
// Fan mode, type: FanMode (enum)
id(my_climate).fan_mode
// Custom Fan mode, type: string

2
components/climate/pid.rst
View File

@ -53,6 +53,8 @@ Configuration variables:
- **sensor** (**Required**, :ref:`config-id`): The sensor that is used to measure the current
temperature.
- **humidity_sensor** (**Optional**, :ref:`config-id`): If specified, this sensor is used to measure the current humidity.
This is used for information only and does not influence temperature control.
- **default_target_temperature** (**Required**, float): The default target temperature (setpoint)
for the control algorithm. This can be dynamically set in the frontend later.
- **heat_output** (*Optional*, :ref:`config-id`): The ID of a :ref:`float output <config-output>`

2
components/climate/thermostat.rst
View File

@ -168,6 +168,8 @@ Configuration Variables:
The thermostat controller uses the sensor to determine whether it should heat or cool.
- **sensor** (**Required**, :ref:`config-id`): The sensor that is used to measure the current temperature.
- **humidity_sensor** (**Optional**, :ref:`config-id`): If specified, this sensor is used to measure the current humidity.
This is used for information only and does not influence temperature control.
Heating and Cooling Actions
***************************

109
components/cover/he60r.rst Normal file
View File

@ -0,0 +1,109 @@
HE60R Garage Door Opener
========================
.. seo::
:description: Setting up a Chamberlain HomEntry HE60R and similar garage door openers
:image: he60r.jpg
.. figure:: images/he60r.jpg
:align: right
The ``he60r`` cover platform allows you to control a HomEntry HE60R
garage door opener. These units were made by Chamberlain and sold through Bunnings. It is *likely* that this
component will also work with other older Chamberlain garage door openers. It is not currently compatible with
newer Chamberlain units that use the Security+ 2.0 protocol.
This component makes use of the HE60R keypad communication interface. This is a single-wire half duplex serial
connection and requires a :ref:`uart` component to be configured. The uart **must** be set to 1200 baud, EVEN parity. See
below for a sample hardware interface.
.. code-block:: yaml
# Example configuration entry
uart:
- id: door_uart
baud_rate: 1200
parity: even
stop_bits: 1
tx_pin: REPLACEME
rx_pin: REPLACEME
cover:
platform: he60r
id: garage_door
name: Garage Door
Configuration variables:
------------------------
- **open_duration** (*Optional*, :ref:`config-time`): The time required for the door to fully open from the closed position. Default 15s.
- **close_duration** (*Optional*, :ref:`config-time`): The time required for the door to fully close from the open position. Default 15s.
- All other options from :ref:`Cover <config-cover>`.
The open and close duration serve to estimate the position to provide feedback during travel and for partial open/close
requests. These can be adjusted according to your door's actual operation. Enabling DEBUG logging will report the
actual open and close times which will help to refine these timings.
Hardware Connection
-------------------
A sample circuit is shown below which also draws power from the HE60R - note that the 3.3V regulator must
be a switching type, a linear regulator would draw too much current and run hot. You can of course simply power
the ESP32 via USB from 5V. This circuit also includes a manual control button connected to a GPIO.
Any microcontroller board supported by ESPHome should be suitable for this application.
.. figure:: images/he60r-sch.jpg
:target: /_images/he60r-sch.jpg
Note that this circuit inverts the TX line. A configuration for this would look something like:
.. code-block:: yaml
# Example configuration entry
uart:
- id: door_uart
baud_rate: 1200
parity: even
stop_bits: 1
tx_pin:
number: REPLACEME
inverted: true
rx_pin: REPLACEME
cover:
platform: he60r
id: garage_door
name: Garage Door
binary_sensor:
- platform: gpio
pin:
number: REPLACEME
inverted: true
mode:
input: true
pullup: true
name: "Garage Door Manual Button"
# debounce the switch
filters:
- delayed_on: 50ms
- delayed_off: 50ms
on_press:
then:
- cover.toggle: garage_door
See Also
--------
- :doc:`index`
- :ref:`automation`
- :ref:`gpio-binary-sensor`
- :ghedit:`Edit`

BIN
components/cover/images/he60r-sch.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 101 KiB

BIN
components/cover/images/he60r.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

2
components/cover/index.rst
View File

@ -36,7 +36,7 @@ Configuration variables:
you want the cover to use that name, you can set ``name: None``.
- **device_class** (*Optional*, string): The device class for the
sensor. See https://www.home-assistant.io/components/cover/ for a list of available options.
sensor. See https://www.home-assistant.io/integrations/cover/#device-class for a list of available options.
- **icon** (*Optional*, icon): Manually set the icon to use for the cover in the frontend.
Advanced options:

2
components/cover/template.rst
View File

@ -52,6 +52,8 @@ Configuration variables:
be performed when the remote requests the cover to be closed.
- **stop_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote requests the cover to be stopped.
- **toggle_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote requests to toggle the the cover.
- **optimistic** (*Optional*, boolean): Whether to operate in optimistic mode - when in this mode,
any command sent to the template cover will immediately update the reported state and no lambda
needs to be used. Defaults to ``false``.

166
components/datetime/index.rst Normal file
View File

@ -0,0 +1,166 @@
Datetime Component
==================
.. seo::
:description: Instructions for setting up datetime components in ESPHome.
:image: folder-open.svg
ESPHome has support for components to create a datetime entity. A datetime entity
currently represents a date that can be set by the user/frontend.
.. note::
Requires Home Assistant 2024.4 or newer.
.. _config-datetime:
Base Datetime Configuration
---------------------------
All datetime in ESPHome have a name and an optional icon.
.. code-block:: yaml
# Example datetime configuration
name: Date to check
# Optional variables:
icon: "mdi:calendar-alert"
Configuration variables:
- **name** (**Required**, string): The name for the datetime.
.. note::
If you have a :ref:`friendly_name <esphome-configuration_variables>` set for your device and
you want the datetime to use that name, you can set ``name: None``.
- **icon** (*Optional*, icon): Manually set the icon to use for the datetime 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).
Requires Home Assistant 2021.9 or newer. Defaults to ``false``.
- **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. Requires Home Assistant 2021.11 or newer.
Set to ``""`` to remove the default entity category.
MQTT Options:
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
Datetime Automation
-------------------
You can access the most recent state as a string of the datetime in :ref:`lambdas <config-lambda>` using
``id(datetime_id).state``.
You can also access it as a ``ESPTime`` object by ``id(datetime_id).state_as_time``
.. _datetime-on_value:
``on_value``
************
This automation will be triggered when a new value is published. In :ref:`Lambdas <config-lambda>`
you can get the value as a ESPTime object from the trigger with ``x``.
.. code-block:: yaml
datetime:
- platform: template
# ...
on_value:
then:
- lambda: |-
if(x.hour >= 12) {
ESP_LOGD("main", "Updated hour is later or equal to 12");
} else {
ESP_LOGD("main", "Updated hour is earlier than 12");
}
Configuration variables: See :ref:`Automation <automation>`.
.. _datetime-date_set_action:
``datetime.date.set`` Action
****************************
This is an :ref:`Action <config-action>` for setting a datetime date state.
The ``date`` provided can be in one of 3 formats:
.. code-block:: yaml
# String date
- datetime.date.set:
id: my_date
date: "2023-12-04"
# Individual date parts
- datetime.date.set:
id: my_date
date:
year: 2023
month: 12
day: 4
# Using a lambda
- datetime.date.set:
id: my_date
date: !lambda |-
// Return an ESPTime struct
return {.day_of_month: 4, .month: 12, .year: 2023};
Configuration variables:
- **id** (**Required**, :ref:`config-id`): The ID of the datetime to set.
- **date** (**Required**, string, date parts, :ref:`templatable <config-templatable>`):
The value to set the datetime to.
.. _datetime-lambda_calls:
lambda calls
************
From :ref:`lambdas <config-lambda>`, you can call several methods on all datetimes to do some
advanced stuff (see the full API Reference for more info).
- ``.make_call()``: Make a call for updating the datetime value.
.. code-block:: cpp
// Within lambda, set the date to 2024-02-25
auto call = id(my_date).make_call();
call.set_date("2024-02-25");
call.perform();
Check the API reference for information on the methods that are available for
the ``DateCall`` object.
- ``.year``: Retrieve the current year of the ``date``. It will be ``0`` if no value has been set.
- ``.month``: Retrieve the current month of the ``date``. It will be ``0`` if no value has been set.
- ``.day``: Retrieve the current day of the ``date``. It will be ``0`` if no value has been set.
- ``.state_as_esptime()``: Retrieve the current value of the datetime as a :apistruct:`ESPTime` object.
.. code-block:: cpp
// For example, create a custom log message when a value is received:
ESP_LOGI("main", "Value of my datetime: %04d-%02d-%02d", id(my_date).year, id(my_date).month, id(my_date).day);
See Also
--------
- :apiref:`DateTimeBase <datetime/datetime_base.h>`
- :apiref:`DateEntity <datetime/date_entity.h>`
- :apiref:`DateCall <datetime/date_entity.h>`
- :ghedit:`Edit`
.. toctree::
:maxdepth: 1
:glob:
*

59
components/datetime/template.rst Normal file
View File

@ -0,0 +1,59 @@
Template Datetime
=================
.. seo::
:description: Instructions for setting up template datetime with ESPHome.
:image: description.svg
The ``template`` datetime platform allows you to create a datetime with templated values
using :ref:`lambdas <config-lambda>`.
.. code-block:: yaml
# Example configuration entry
datetime:
- platform: template
id: my_date
type: date
name: Pick a Date
optimistic: yes
initial_value: "2024-01-30"
restore_value: true
Configuration variables:
------------------------
- **type** (*Required*, enum): The type of the datetime. Can only be ``date``.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda to be evaluated every update interval to get the current value of the datetime.
- **set_action** (*Optional*, :ref:`Action <config-action>`): The action that should
be performed when the remote (like Home Assistant's frontend) requests to set the
dateime value. The new value is available to lambdas in the ``x`` variable.
- **update_interval** (*Optional*, :ref:`config-time`): The interval on which to update the datetime
by executing the ``lambda``. Defaults to ``60s``.
- **optimistic** (*Optional*, boolean): Whether to operate in optimistic mode - when in this mode,
any command sent to the template datetime will immediately update the reported state.
Cannot be used with ``lambda``. Defaults to ``false``.
- **restore_value** (*Optional*, boolean): Saves and loads the state to RTC/Flash.
Cannot be used with ``lambda``. Defaults to ``false``.
- **initial_value** (*Optional*, string): The value to set the state to on setup if not
restored with ``restore_value``. Can be one of:
- A string in the format ``%Y-%m-%d``, eg: ``"2023-12-04"``.
- An object including ``year``, ``month``, ``day``.
.. code-block:: yaml
initial_value:
year: 2023
month: 12
day: 4
- All other options from :ref:`Datetime <config-datetime>`.
See Also
--------
- :ref:`automation`
- :apiref:`template/datetime/template_date.h`
- :ghedit:`Edit`

36
components/deep_sleep.rst
View File

@ -21,7 +21,9 @@ to wake up on any RTC pin (``GPIO0``, ``GPIO2``, ``GPIO4``, ``GPIO12``, ``GPIO13
``GPIO15``, ``GPIO25``, ``GPIO26``, ``GPIO27``, ``GPIO32``, ``GPIO39``).
While in deep sleep mode, the node will not do any work and not respond to any network traffic,
even Over The Air updates.
even Over The Air updates. If the device's entities are appearing as **Unavailable** while your device is actively
sleeping, this component was likely added after the device was added to Home Assistant. To prevent this behavior,
you can remove and re-add the device in Home Assistant.
.. code-block:: yaml
@ -32,8 +34,8 @@ even Over The Air updates.
.. note::
Some ESP8266s have an onboard USB chip (e.g. D1 mini) on the chips' control line that is connected to the RST pin. This enables the flasher to reboot the ESP when required. This may interfere with deep sleep on some devices and prevent the ESP from waking when it's powered through its USB connector. Powering the ESP from a separate 3.3V source connected to the 3.3V pin and GND will solve this issue. In these cases, using a USB to TTL adapter will allow you to log ESP activity.
Some ESP8266s have an onboard USB chip (e.g. D1 mini) on the chips' control line that is connected to the RST pin. This enables the flasher to reboot the ESP when required. This may interfere with deep sleep on some devices and prevent the ESP from waking when it's powered through its USB connector. Powering the ESP from a separate 3.3V source connected to the 3.3V pin and GND will solve this issue. In these cases, using a USB to TTL adapter will allow you to log ESP activity.
Configuration variables:
------------------------
@ -85,6 +87,34 @@ when the deep sleep should start? There are three ways of handling this using th
then re-configure deep sleep to wake up on a LOW signal and vice versa. Useful in situations when you want to
use observe the state changes of a pin using deep sleep and the ON/OFF values last longer.
ESP32 Wakeup Cause
------------------
On the ESP32, the ``esp_sleep_get_wakeup_cause()`` function can be used to check which wakeup source has triggered
wakeup from sleep mode.
.. code-block:: yaml
sensor:
- platform: template
name: "Wakeup Cause"
accuracy_decimals: 0
lambda: return esp_sleep_get_wakeup_cause();
The following integers are the wakeup causes:
- **0** - ``ESP_SLEEP_WAKEUP_UNDEFINED``: In case of deep sleep, reset was not caused by exit from deep sleep
- **1** - ``ESP_SLEEP_WAKEUP_ALL``: Not a wakeup cause, used to disable all wakeup sources with esp_sleep_disable_wakeup_source
- **2** - ``ESP_SLEEP_WAKEUP_EXT0``: Wakeup caused by external signal using RTC_IO
- **3** - ``ESP_SLEEP_WAKEUP_EXT1``: Wakeup caused by external signal using RTC_CNTL
- **4** - ``ESP_SLEEP_WAKEUP_TIMER``: Wakeup caused by timer
- **5** - ``ESP_SLEEP_WAKEUP_TOUCHPAD``: Wakeup caused by touchpad
- **6** - ``ESP_SLEEP_WAKEUP_ULP``: Wakeup caused by ULP program
- **7** - ``ESP_SLEEP_WAKEUP_GPIO``: Wakeup caused by GPIO (light sleep only on ESP32, S2 and S3)
- **8** - ``ESP_SLEEP_WAKEUP_UART``: Wakeup caused by UART (light sleep only)
- **9** - ``ESP_SLEEP_WAKEUP_WIFI``: Wakeup caused by WIFI (light sleep only)
- **10** - ``ESP_SLEEP_WAKEUP_COCPU``: Wakeup caused by COCPU int
- **11** - ``ESP_SLEEP_WAKEUP_COCPU_TRAP_TRIG``: Wakeup caused by COCPU crash
- **12** - ``ESP_SLEEP_WAKEUP_BT``: Wakeup caused by BT (light sleep only)
.. _deep_sleep-enter_action:

160
components/display/fonts.rst Normal file
View File

@ -0,0 +1,160 @@
.. _display-fonts:
Font Renderer Component
=======================
.. seo::
:description: Instructions for setting up fonts in ESPHome.
:image: format-font.svg
ESPHome's graphical rendering engine also has a powerful font drawer which integrates seamlessly into the system. You have the option to use **any** OpenType/TrueType (``.ttf``, ``.otf``, ``.woff``) font file at **any** size, as well as fixed-size `PCF <https://en.wikipedia.org/wiki/Portable_Compiled_Format>`_ and `BDF <https://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format>`_ bitmap fonts.
These fonts can be used in ESPHome's :ref:`own rendering engine <display-engine>`.
To use fonts you can either
- Just grab a ``.ttf``, ``.otf``, ``.woff``, ``.pcf``, or ``.bdf`` file from somewhere on the internet and place it, for example, inside a ``fonts`` folder next to your configuration file.
- Use the ``gfonts://`` short form to use Google Fonts directly.
- Load a font from a URL directly on build.
Next, create a ``font:`` section in your configuration:
.. code-block:: yaml
# Various ways to configure fonts
font:
- file: "fonts/Comic Sans MS.ttf"
id: my_font
size: 20
bpp: 2
- file: "fonts/tom-thumb.bdf"
id: tomthumb
# gfonts://family[@weight]
- file: "gfonts://Roboto"
id: roboto_20
size: 20
- file:
type: gfonts
family: Roboto
weight: 900
id: roboto_16
size: 16
- file: "gfonts://Material+Symbols+Outlined"
id: icons_50
size: 50
glyphs: ["\U0000e425"] # mdi-timer
- file: "fonts/RobotoCondensed-Regular.ttf"
id: roboto_special_28
size: 28
bpp: 4
glyphs: [
a,A,á,Á,e,E,é,É,
(,),+,-,_,.,°,•,µ,
"\u0020", #space
"\u0021", #!
"\u0022", #"
"\u0027", #'
]
- file: "fonts/RobotoCondensed-Regular.ttf"
id: my_font_with_icons
size: 20
bpp: 4
extras:
- file: "fonts/materialdesignicons-webfont.ttf"
glyphs: [
"\U000F02D1", # mdi-heart
"\U000F05D4", # mdi-airplane-landing
]
- file: "https://github.com/IdreesInc/Monocraft/releases/download/v3.0/Monocraft.ttf"
id: web_font
size: 20
- file:
url: "https://github.com/IdreesInc/Monocraft/releases/download/v3.0/Monocraft.ttf"
type: web
id: web_font2
size: 24
display:
# ...
Configuration variables:
------------------------
- **file** (**Required**, string): The path (relative to where the .yaml file is) of the font
file. You can also use the ``gfonts://`` short form to use Google Fonts, or use the below structure:
- **type** (**Required**, string): Can be ``local``, ``gfonts`` or ``web``.
**Local Fonts**:
- **path** (**Required**, string): The path (relative to where the .yaml file is) of the OpenType/TrueType or bitmap font file.
**Google Fonts**:
Each Google Font will be downloaded once and cached for future use. This can also be used to download Material
Symbols or Icons as in the example above.
- **family** (**Required**, string): The name of the Google Font family.
- **italic** (*Optional*, boolean): Whether the font should be italic.
- **weight** (*Optional*, enum): The weight of the font. Can be either the text name or the integer value:
- **thin**: 100
- **extra-light**: 200
- **light**: 300
- **regular**: 400 (**default**)
- **medium**: 500
- **semi-bold**: 600
- **bold**: 700
- **extra-bold**: 800
- **black**: 900
**Web Fonts**:
- **url** (**Required**, string): The URL of the TrueType or bitmap font file.
- **id** (**Required**, :ref:`config-id`): The ID with which you will be able to reference the font later
in your display code.
- **size** (*Optional*, int): The size of the font in pt (not pixel!).
If you want to use the same font in different sizes, create two font objects. Note: *size* is ignored
by bitmap fonts. Defaults to ``20``.
- **bpp** (*Optional*, int): The bit depth of the rendered font from OpenType/TrueType, for anti-aliasing. Can be ``1``, ``2``, ``4``, ``8``. Defaults to ``1``.
- **glyphs** (*Optional*, list): A list of characters you plan to use. Only the characters you specify
here will be compiled into the binary. Adjust this if you need some special characters or want to
reduce the size of the binary if you don't plan to use some glyphs. You can also specify glyphs by their codepoint (see below). Defaults to ``!"%()+=,-_.:°/?0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz``.
- **extras** (*Optional*, enum): A list of font glyph configurations you'd like to include within this font, from other OpenType/TrueType files (eg. icons from other font, but at the same size as the main font):
- **file** (**Required**, string): The path of the font file with the extra glyphs.
- **glyphs** (**Required**, list): A list of glyphs you want to include. Can't repeat the same glyph codepoint if it was declared in the level above.
.. note::
OpenType/TrueType font files offer icons at codepoints far from what's reachable on a standard keyboard, for these it's needed
to specify the unicode codepoint of the glyph as a hex address escaped with ``\u`` or ``\U``.
- Code points up to ``0xFFFF`` are encoded like ``\uE6E8``. Lowercase ``\u`` and exactly 4 hexadecimal digits.
- Code points above ``0xFFFF`` are encoded like ``\U0001F5E9``. Capital ``\U`` and exactly 8 hexadecimal digits.
The ``extras`` section only supports OpenType/TrueType files, ``size`` and ``bpp`` will be the same as the above level. This will allow printing icons alongside the characters in the same string, like ``I \uF004 You \uF001``.
Many font sizes with multiple glyphs at high bit depths will increase the binary size considerably. Make your choices carefully.
.. note::
To use fonts you will need to have the python ``pillow`` package installed, as ESPHome uses that package
to translate the OpenType/TrueType and bitmap font files into an internal format. If you're running this as a Home Assistant add-on or with the official ESPHome docker image, it should already be installed. Otherwise you need
to install it using ``pip install "pillow==10.2.0"``.
See Also
--------
- :apiref:`display/display_buffer.h`
- :ref:`display-engine`
- `MDI cheatsheet <https://pictogrammers.com/library/mdi/>`_
- `MDI font repository <https://github.com/Pictogrammers/pictogrammers.github.io/tree/main/%40mdi/font/>`_
- :ghedit:`Edit`

110
components/display/ili9xxx.rst
View File

@ -1,4 +1,3 @@
ILI9xxx TFT LCD Series
======================
@ -11,9 +10,11 @@ ILI9xxx TFT LCD Series
Models
------
With this display driver you can control the following displays:
- GC9A01A
- ILI9341
- ILI9342
- ILI9481
- ILI9481-18 (ILI9481 in 18 bit, i.e. 262K color, mode)
- ILI9486
- ILI9488
- ILI9488_A (alternative gamma configuration for ILI9488)
@ -21,22 +22,25 @@ With this display driver you can control the following displays:
- S3BOX
- S3BOX_LITE
- ST7796
- ST7789V
- TFT 2.4
- TFT 2.4R
- WAVESHARE_RES_3_5 (Waveshare Pico-ResTouch-LCD-3.5)
More display drivers will come in the future.
Usage
-----
This component is the successor of the ILI9341 component allowing to control more display drivers and use 16bit colors when enough free ram.
This component is the successor of the ILI9341 component supporting more display driver chips from the ILI and related
families.
The ``ILI9xxx`` display platform allows you to use
ILI9341 (`datasheet <https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf>`__,
`Aliexpress <https://www.aliexpress.com/af/Ili9341.html>`__) and other
displays from the same chip family with ESPHome. As this is a somewhat higher resolution display and may require pins
beyond the typical SPI connections, it is better suited for use with the ESP32.
displays from the same chip family with ESPHome. As this is a somewhat higher resolution display and requires additional pins
beyond the basic SPI connections, and a reasonable amount of RAM, it is not well suited for the ESP8266.
**Note:** To use 16bit instead of 8bit colors use a esp32 with enough PSRAM the display.
**Note:** use of 16 bit colors requires double the amount of RAM as 8 bit, and may need PSRAM to be available.
.. figure:: images/ili9341-full.jpg
:align: center
@ -62,15 +66,14 @@ Configuration variables:
- **model** (**Required**): The model of the display. Options are:
- ``M5STACK``, ``TFT 2.4``, ``TFT 2.4R``, ``S3BOX``, ``S3BOX_LITE``
- ``ILI9341``, ``ILI9342``, ``ILI9481``, ``ILI9486``, ``ILI9488``, ``ILI9488_A`` (alternative gamma configuration for ILI9488), ``ST7796``
.. note:: According to its documentation, the ESP32 S3 Box Lite has an ST7789V display driver. We've found, however, that it works with the ILIxxxx component here, instead. This could change in the future.
- ``M5STACK``, ``TFT 2.4``, ``TFT 2.4R``, ``S3BOX``, ``S3BOX_LITE``, ``WSPICOLCD``
- ``ILI9341``, ``ILI9342``, ``ILI9486``, ``ILI9488``, ``ILI9488_A`` (alternative gamma configuration for ILI9488)
- ``ILI9481``, ``ILI9481-18`` (18 bit mode)
- ``ST7789V``, ``ST7796``
- ``GC9A01A``
- **dc_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The DC pin.
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
- **rotation** (*Optional*): Set the rotation of the display. Everything drawn in the ``lambda:`` will be rotated
per this option. One of ``0°`` (default), ``90°``, ``180°``, or ``270°``.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
See :ref:`display-engine` for more information.
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``5s``.
@ -83,14 +86,54 @@ Configuration variables:
- ``NONE`` (default)
- ``GRAYSCALE``
- ``IMAGE_ADAPTIVE``
- **color_order** (*Optional*): Should be one of ``bgr`` (default) or ``rgb``.
- **color_palette_images** (*Optional*): A list of image files that will be used to generate the color pallet for the display. This should only be used in conjunction with ``-color_palette: IMAGE_ADAPTIVE`` above. The images will be analysed at compile time and a custom color pallet will be created based on the most commonly occuring colors. A typical setting would be a sample image that represented the fully populated display. This can significantly improve the quality of displayed images. Note that these images are not stored on the ESP device, just the 256byte color pallet created from them.
- **dimensions** (*Optional*): Dimensions of the screen with WIDTHxHEIGHT. Usually not needed since ``model:`` has good defaults.
- **data_rate** (*Optional*): Set the data rate of the SPI interface to the display. One of ``80MHz``, ``40MHz`` (default), ``20MHz``, ``10MHz``, ``5MHz``, ``2MHz``, ``1MHz``, ``200kHz``, ``75kHz`` or ``1kHz``. If you have multiple ILI9xxx displays they must all use the same **data_rate**.
- **invert_display** (*Optional*): With this boolean option you can invert the some of the display colors manual. **Note** some of the displays have this option set automatically to true and can't be changed.
- **dimensions** (*Optional*): Dimensions of the screen, specified either as *width* **x** *height* (e.g ``320x240``) or with separate config keys. If not provided the dimensions will be determined by the model selected.
- **height** (**Required**, int): Specifies height of display in pixels.
- **width** (**Required**, int): Specifies width of display.
- **offset_width** (*Optional*, int): Specify an offset for the x-direction of the display, typically used when an LCD is smaller than the maximum supported by the driver chip. Default is 0
- **offset_height** (*Optional*, int): Specify an offset for the y-direction of the display. Default is 0.
- **invert_colors** (*Optional*): With this boolean option you can invert the display colors. **Note** some of the displays have this option set automatically to true and can't be changed.
- **18bit_mode** (*Optional*): With this boolean option you can manual enable or disable the 18 bit color mode.
- **rotation** (*Optional*): Rotate the display presentation in software. Choose one of ``0°``, ``90°``, ``180°``, or ``270°``. This option cannot be used with ``transform``.
- **transform** (*Optional*): Transform the display presentation using hardware. All defaults are ``false``. This option cannot be used with ``rotation``.
- **swap_xy** (*Optional*, boolean): If true, exchange the x and y axes.
- **mirror_x** (*Optional*, boolean): If true, mirror the x axis.
- **mirror_y** (*Optional*, boolean): If true, mirror the y axis.
**Note:** The ``rotation`` variable will do a software based rotation. It is better to use the **transform** to rotate the display in hardware. Use one of the following combinations:
- 90 degrees - use ``swap_xy`` with ``mirror_x``
- 180 degrees - use ``mirror_x`` with ``mirror_y``
- 270 degrees - use ``swap_xy`` with ``mirror_y``
With 90 and 270 rotations you will also need to swap the **dimensions** ''height'' and ''width'' (see example below.
To modify the SPI setting see :ref:`SPI bus <spi>` . The default **data_rate** is set to ``40MHz`` and the **spi_mode** mode is ``MODE0`` but some displays require ``MODE3`` (*).
**Note:** The maximum achievable data rate will depend on the chip type (e.g. ESP32 vs ESP32-S3) the pins used (on ESP32 using the default SPI pins allows higher rates) and the connection type (on-board connections will support higher rates than long cables or DuPont wires.) If in doubt, start with a low speed and test higher rates to find what works. A MISO pin should preferably not be specified, as this will limit the maximum rate in some circumstances, and is not required if the SPI bus is used only for the display.
Configuration examples
**********************
To use hardware rotation, use both ``dimensions`` and ``transform``, e.g. this config will turn a landscape display with
height 320 and width 480 into portrait. Note that the dimensions are those of the final display.
.. code-block:: yaml
transform:
swap_xy: true
mirror_x: true
dimensions:
height: 480
width: 320
To utilize the color capabilities of this display module, you'll likely want to add a ``color:`` section to your
YAML configuration; please see :ref:`color <config-color>` for more detail on this configuration section.
@ -172,6 +215,45 @@ To configure an image adaptive color pallet to show greater than 8 bit color dep
lambda: |-
it.image(0, 0, id(myimage));
Using the ``transform`` options to hardware rotate the display on a Lilygo T-Embed. This has an st7789v but only uses 170 pixels of the 240 width.
This config rotates the display into landscape mode using the driver chip.
.. code-block:: yaml
display:
- platform: ili9xxx
model: st7789v
dimensions:
height: 170
width: 320
offset_height: 35
offset_width: 0
transform:
swap_xy: true
mirror_x: false
mirror_y: true
color_order: bgr
data_rate: 80MHz
cs_pin: 10
dc_pin: GPIO13
reset_pin: GPIO9
For Lilygo TTGO Boards if you move from the st7789v to this you need the following settings to make it work.
.. code-block:: yaml
display:
- platform: ili9xxx
model: st7789v
#TTGO TDisplay 135x240
dimensions:
height: 240
width: 135
offset_height: 40
offset_width: 52
# Required or the colors are all inverted, and Black screen is White
invert_colors: true
See Also
--------

BIN
components/display/images/indicator.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
components/display/images/st7567-full.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 77 KiB

BIN
components/display/images/t-display-amoled.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
components/display/images/t4-s3.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
components/display/images/waveshare_touch-s3.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 25 KiB

191
components/display/index.rst
View File

@ -9,10 +9,10 @@ The ``display`` component houses ESPHome's powerful rendering and display
engine. Fundamentally, there are these types of displays:
- Text based displays like :doc:`7-Segment displays <max7219>` or
:doc:`some LCD displays <lcd_display>`.
- Displays like the :doc:`nextion` that have their own processors for rendering.
- Binary displays which can toggle ON/OFF any pixel, like :doc:`E-Paper displays <waveshare_epaper>` or
:doc:`OLED displays <ssd1306>`.
:doc:`LCD displays <lcd_display>`.
- Graphical serial displays like :doc:`nextion` that have their own processors for rendering.
- Graphical binary displays which can toggle ON/OFF any pixel, like :doc:`E-Paper <waveshare_epaper>`,
:doc:`OLED <ssd1306>` or :doc:`TFT <ili9xxx>` displays.
For the last type, ESPHome has a powerful rendering engine that can do
many things like draw some basic shapes, print text with any font you want, or even show images.
@ -24,11 +24,6 @@ using an API that is designed to
- be simple and to be used without programming experience
- but also be flexible enough to work with more complex tasks like displaying an analog clock.
.. note::
Display hardware is complex and sometimes doesn't behave as expected. If you're having trouble with your display,
please see :ref:`troubleshooting` below.
.. _display-engine:
Display Rendering Engine
@ -38,6 +33,11 @@ In this section we will be discussing how to use ESPHome's display rendering eng
and some basic commands. Please note that this only applies to displays that can control each pixel
individually.
.. note::
Display hardware is complex and sometimes doesn't behave as expected. If you're having trouble with your display,
please see :ref:`troubleshooting` below.
So, first a few basics: When setting up a display platform in ESPHome there will be a configuration
option called ``lambda:`` which will be called every time ESPHome wants to re-render the display.
In each cycle, the display is automatically cleared before the lambda is executed. You can disable
@ -72,7 +72,7 @@ x always represents the horizontal axis (width) and y the vertical axis (height)
the rendering engine is always first specify the ``x`` coordinate and then the ``y`` coordinate.
Basic Shapes
************
------------
Now that you know a bit more about ESPHome's coordinate system, let's draw some basic shapes like lines, rectangles
and circles:
@ -95,6 +95,19 @@ and circles:
// ... and the same thing filled again
it.filled_circle(25, 25, 10);
// Triangles... Let's draw the outline of a triangle from the [x,y] coordinates of its three points
// [25,5], [5,25], [50,50]
it.triangle(25, 5, 5, 25, 50, 50);
// and a filled triangle !
it.filled_triangle(125, 5, 105, 25, 150, 50);
// Regular Polygons? Let's draw the outline of a pointy-topped hexagon inscribed in a circle
// centered on [x1=100,y1=100] with a radius of 50
it.regular_polygon(100, 100, 50, EDGES_HEXAGON);
// and a filled flat-topped octagon!
it.filled_regular_polygon(200, 200, 50, EDGES_OCTAGON, VARIATION_FLAT_TOP);
// Need to rotate the polygon, or retrieve the coordinates of its vertices? Check the API!
All the above methods can optionally also be called with an argument at the end which specifies in which
color to draw. For monochrome displays, only ``COLOR_ON`` (the default if color is not given) and ``COLOR_OFF`` are supported.
@ -146,110 +159,14 @@ Additionally, you have access to two helper methods which will fetch the width a
You can view the full API documentation for the rendering engine in the "API Reference" in the See Also section.
.. _display-fonts:
Fonts
*****
The rendering engine also has a powerful font drawer which integrates seamlessly into ESPHome.
Whereas in most Arduino display projects you have to use one of a few pre-defined fonts in very
specific sizes, with ESPHome you have the option to use **any** TrueType (``.ttf``) font file
at **any** size, as well as fixed-size `PCF <https://en.wikipedia.org/wiki/Portable_Compiled_Format>`_ and `BDF <https://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format>`_ bitmap fonts! Granted the reason for it is
actually not having to worry about the licensing of font files :)
To use fonts you first have to define a font object in your ESPHome configuration file. Just grab
a ``.ttf``, ``.pcf``, or ``.bdf`` file from somewhere on the internet and place it, for example,
inside a ``fonts`` folder next to your configuration file.
Next, create a ``font:`` section in your configuration:
.. code-block:: yaml
font:
- file: "fonts/Comic Sans MS.ttf"
id: my_font
size: 20
# gfonts://family[@weight]
- file: "gfonts://Roboto"
id: roboto
size: 20
- file:
type: gfonts
family: Roboto
weight: 900
id: font2
size: 16
- file: "fonts/tom-thumb.bdf"
id: tomthumb
- file: 'gfonts://Material+Symbols+Outlined'
id: icon_font_50
size: 50
glyphs: ["\U0000e425"] # mdi-timer
display:
# ...
Configuration variables:
- **file** (**Required**): The path (relative to where the .yaml file is) of the font
file. You can use the ``gfonts://`` short form to use Google Fonts, or use the below structure:
- **type** (**Required**, string): Can be ``gfonts`` or ``local``.
**Google Fonts**:
Each Google Font will be downloaded once and cached for future use. This can also be used to download Material
Symbols or Icons as in the example above.
- **family** (**Required**, string): The name of the Google Font family.
- **weight** (*Optional*, enum): The weight of the font. Can be either the text name or the integer value:
- **thin**: 100
- **extra-light**: 200
- **light**: 300
- **regular**: 400 (**default**)
- **medium**: 500
- **semi-bold**: 600
- **bold**: 700
- **extra-bold**: 800
- **black**: 900
- **italic** (*Optional*, boolean): Whether the font should be italic.
**Local Fonts**:
- **path** (**Required**, string): The path (relative to where the .yaml file is) of the TrueType or bitmap font file.
- **id** (**Required**, :ref:`config-id`): The ID with which you will be able to reference the font later
in your display code.
- **size** (*Optional*, int): The size of the font in pt (not pixel!).
If you want to use the same font in different sizes, create two font objects. Note: *size* is ignored
by bitmap fonts. Defaults to ``20``.
- **glyphs** (*Optional*, list): A list of characters you plan to use. Only the characters you specify
here will be compiled into the binary. Adjust this if you need some special characters or want to
reduce the size of the binary if you don't plan to use some glyphs. The items in the list can also
be more than one character long if you for example want to use font ligatures. Defaults to
``!"%()+=,-_.:°0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz``.
.. note::
To use fonts you will need to have the python ``pillow`` package installed, as ESPHome uses that package
to translate the TrueType and bitmap font files into an internal format. If you're running this as a Home Assistant
add-on or with the official ESPHome docker image, it should already be installed. Otherwise you need
to install it using
``pip install "pillow>4.0.0,<10.0.0"``.
.. _display-static_text:
Drawing Static Text
*******************
-------------------
In your display code, you can render static text by referencing the font and just entering your string:
To be able to display text, you need to prepare some fonts. ESPHome's :ref:`font renderer <display-fonts>` allows you to use OpenType/TrueType/Bitmap fonts for your texts. This is very flexiblle because you can prepare various sets of fonts at different sizes with a different number of glyphs which is extremely convenient when we're talking about flash space.
In your display code, you can render static text by referencing the font and just entering your string enclosed in double quotes:
.. code-block:: yaml
@ -290,11 +207,21 @@ As with basic shapes, you can also specify a color for the text:
// Syntax is always: it.print(<x>, <y>, <font>, [color=COLOR_ON], [align=TextAlign::TOP_LEFT], <text>);
it.print(0, 0, id(my_font), COLOR_ON, "Left aligned");
In case of fonts rendered at higher bit depths, the background color has to be specified after the text in order for antialiasing to work:
.. code-block:: yaml
display:
- platform: ...
# ...
lambda: |-
// Syntax is always: it.print(<x>, <y>, <font>, [color=COLOR_ON], [align], <text>, [color=COLOR_OFF]);
it.print(0, 0, id(my_font_with_icons), COLOR_ON, TextAlign::CENTER, "Just\U000f05d4here. Already\U000F02D1this.", COLOR_OFF);
.. _display-printf:
Formatted Text
**************
--------------
Static text by itself is not too impressive. What we really want is to display *dynamic* content like sensor values
on the display!. That's where ``printf`` comes in. ``printf`` is a formatting engine from the C era and ESPHome
@ -344,7 +271,7 @@ Another interesting format string is ``%7.2f``, which would become the right-jus
- ``.2`` - round the decimal number to ``2`` digits after the decimal point.
- ``f`` - specifier: f(loat).
You can even have as many format strings as you want in a single printf call. Just make sure the put the
You can even have as many formatted items as you want in a single printf call. Just make sure the put the
arguments after the format string in the right order.
.. code-block:: yaml
@ -366,6 +293,19 @@ To display a text string from a ``text_sensor``, append ``.c_str()`` to the end
lambda: |-
it.printf(0, 0, id(my_font), "Text to follow: %s", id(template_text).state.c_str());
When using anti-aliased fonts you will probably need to specify the color to draw the characters, and the background
color to mix in for anti-aliasing. This requires the full version of `printf`, e.g.:
.. code-block:: yaml
display:
- platform: ...
# ...
lambda: |-
it.printf(10, 100, id(roboto), Color(0x123456), COLOR_OFF, display::TextAlign::BASELINE, "%f", id(heap_free).state);
The last printf tip for use in displays I will discuss here is how to display binary sensor values. You
*could* of course just check the state with an ``if`` statement as the first few lines in the example below, but if
you want to be efficient you can use an *inline if* too. With the ``%s`` print specifier you can tell it to
@ -398,14 +338,14 @@ use any string you pass it, like ``"ON"`` or ``"OFF"``.
.. _display-strftime:
Displaying Time
***************
---------------
You can display current time using a time component. Please see the example :ref:`here <strftime>`.
.. _clipping:
Screen Clipping
***************
---------------
Screen clipping is a new set of methods since version 2023.2.0 of esphome. It could be useful when you just want to show
a part of an image or make sure that what you draw on the screen does not go outside a specific region on the screen.
@ -457,12 +397,10 @@ With ``get_clipping();`` you get a ``Rect`` object back with the latest set clip
With ``is_clipping();`` tells you if clipping is activated.
.. _config-color:
Color
*****
-----
When using RGB-capable displays in ESPHome you may wish to use custom colors.
A ``color`` component exists for just this purpose:
@ -512,7 +450,7 @@ RGB displays use red, green, and blue, while grayscale displays may use white.
.. _display-graphs:
Graph Component
***************
---------------
You can display a graph of a sensor value(s) using this component. The states used for the graph are stored in
memory at the time the sensor updates and will be lost when the device reboots.
@ -552,6 +490,7 @@ Graph component with options for grids, border and line-types.
color: my_red
- sensor: my_outside_temperature
line_type: SOLID
continuous: true
line_thickness: 3
color: my_blue
- sensor: my_beer_temperature
@ -580,6 +519,7 @@ Trace specific fields:
- **sensor** (*Optional*, :ref:`config-id`): The sensor value to plot
- **line_thickness** (*Optional*): Defaults to 3
- **line_type** (*Optional*): Specifies the plot line-type. Can be one of the following: ``SOLID``, ``DOTTED``, ``DASHED``. Defaults to ``SOLID``.
- **continuous** (*Optional*): connects the individual points to make a continuous line. Defaults to ``false``.
- **color** (*Optional*): Sets the color of the sensor trace.
And then later in code:
@ -623,8 +563,11 @@ And then later in code:
- Axis labels are currently not possible without manually placing them.
- The grid and border color is set with it.graph(), while the traces are defined separately.
.. _display-qrcode:
QR Code Component
*****************
-----------------
Use this component to generate a QR-code containing a string on the device, which can then be drawn on compatible displays.
@ -659,8 +602,11 @@ To draw the QR-code, call the ``it.qr_code`` function from your render lambda:
// Draw the QR-code at position [x=50,y=0] with white color and a 2x scale
it.qr_code(50, 0, id(homepage_qr), Color(255,255,255), 2);
.. _display-image:
Images
******
------
Use this component to store graphical images on the device, you can then draw the images on compatible displays.
@ -775,7 +721,7 @@ You can also use this to invert images in two colors display, use ``COLOR_OFF``
as the additional parameters.
Animation
*********
---------
Allows to use animated images on displays. Animation inherits all options from the image component.
It adds additional lambda methods: ``next_frame()``, ``prev_frame()`` and ``set_frame()`` to change the shown picture of a gif.
@ -976,7 +922,7 @@ Troubleshooting
---------------
Color Test Pattern
******************
------------------
If you're experiencing issues with your color display, the script below can help you to identify what might be wrong.
It will show 3 color bars in **RED**, **GREEN** and **BLUE**. To help the graphics display team determine
@ -1023,6 +969,7 @@ See Also
--------
- :apiref:`display/display_buffer.h`
- :ref:`Fonts <display-fonts>`
- :ghedit:`Edit`
.. toctree::

4
components/display/inkplate6.rst
View File

@ -10,7 +10,7 @@ All-in-one e-paper display ``Inkplate 6``, ``Inkplate 10`` and ``Inkplate 6 Plus
The Inkplate 6, 10 and 6 Plus are powerful, Wi-Fi enabled ESP32 based six-inch e-paper displays -
recycled from a Kindle e-reader. Its main feature is simplicity.
Learn more at `Inkplate's website <https://inkplate.io/>`__
Learn more at `Inkplate's documentation website <https://inkplate.readthedocs.io/en/stable/>`__
.. figure:: images/inkplate6.jpg
:align: center
@ -282,7 +282,7 @@ Inkplate 6 Plus Touchscreen
***************************
The Inkplate 6 Plus has a built in touchscreen supported by ESPHome. Note you need to enable pin 12 on the mcp23017 to enable the touchscreen
Below is a config example with touchscreen power swtich:
Below is a config example with touchscreen power switch:
.. code-block:: yaml

27
components/display/nextion.rst
View File

@ -67,10 +67,12 @@ Configuration variables:
- **start_up_page** (*Optional*, int): Sets the page to display when ESPHome connects to the Nextion. (Nextion shows page 0 on start-up by default).
- **wake_up_page** (*Optional*, int): Sets the page to display after waking up
- **auto_wake_on_touch** (*Optional*, boolean): Sets if Nextion should auto-wake from sleep when touch press occurs.
- **exit_reparse_on_start** (*Optional*, boolean): Request the Nextion exit Active Reparse Mode before setup of the display. Defaults to ``false``.
- **on_setup** (*Optional*, :ref:`Action <config-action>`): An action to be performed after ESPHome connects to the Nextion. See :ref:`Nextion Automation <nextion-on_setup>`.
- **on_sleep** (*Optional*, :ref:`Action <config-action>`): An action to be performed when the Nextion goes to sleep. See :ref:`Nextion Automation <nextion-on_sleep>`.
- **on_wake** (*Optional*, :ref:`Action <config-action>`): An action to be performed when the Nextion wakes up. See :ref:`Nextion Automation <nextion-on_sleep>`.
- **on_page** (*Optional*, :ref:`Action <config-action>`): An action to be performed after a page change. See :ref:`Nextion Automation <nextion-on_page>`.
- **on_touch** (*Optional*, :ref:`Action <config-action>`): An action to be performed after a touch event (press or release). See :ref:`Nextion Automation <nextion-on_touch>`.
.. _display-nextion_lambda:
@ -259,6 +261,31 @@ Once you know the page id, it's time to update the components. Two strategies wo
break;
}
.. _nextion-on_touch:
``on_touch``
************
This automation is triggered when a component is pressed or released on the Nextion display.
The following arguments will be available:
- ``page_id``: Contains the id (integer) of the page where the touch happened.
- ``component_id``: Contains the id (integer) of the component touched. It's required that the component have "Send Component ID" enabled either for "Touch Press Event" and/or "Touch Release Event".
- ``touch_event``: It will be ``true`` for a "press" event, or ``false`` for a "release" event.
.. code-block:: yaml
on_touch:
then:
lambda: |-
ESP_LOGD("nextion.on_touch", "Nextion touch event detected!");
ESP_LOGD("nextion.on_touch", "Page Id: %i", page_id);
ESP_LOGD("nextion.on_touch", "Component Id: %i", component_id);
ESP_LOGD("nextion.on_touch", "Event type: %s", touch_event ? "Press" : "Release");
.. _nextion_upload_tft_file:
Uploading A TFT File

186
components/display/qspi_amoled.rst Normal file
View File

@ -0,0 +1,186 @@
Quad SPI AMOLED Displays
========================
.. seo::
:description: Instructions for setting up quad SPI AMOLED displays.
:image: t4-s3.jpg
.. _qspi_amoled:
Models
------
This display driver supports AMOLED displays with quad SPI interfaces.
This driver has been tested with the following displays:
- Lilygo T4-S3
- Lilygo T-Display S3 AMOLED
Usage
-----
This component requires an ESP32 and the use of
ESP-IDF. PSRAM is a requirement due to the size of the display buffer. A :ref:`quad SPI bus <spi>` interface must be configured.
.. figure:: images/t4-s3.jpg
:align: center
:width: 75.0%
Lilygo T4-S3
.. figure:: images/t-display-amoled.jpg
:align: center
:width: 75.0%
Lilygo T-Display S3 AMOLED
.. code-block:: yaml
# Example minimal configuration entry
display:
- platform: qspi_amoled
model: RM690B0
data_rate: 80MHz
spi_mode: mode0
dimensions:
width: 450
height: 600
offset_width: 16
color_order: rgb
invert_colors: false
brightness: 255
cs_pin: 11
reset_pin: 13
enable_pin: 9
Configuration variables:
************************
- **model** (**Required**): One of ``RM67162`` or ``RM690B0``.
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The chip select pin.
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
- **enable_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The display enable pin.
- **brightness** (*Optional*, int): A brightness value in the range 0-255
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``5s``.
- **auto_clear_enabled** (*Optional*, boolean): Whether to automatically clear the display in each loop (''true'', default),
or to keep the existing display content (must overwrite explicitly, e.g., only on data change).
- **pages** (*Optional*, list): Show pages instead of a single lambda. See :ref:`display-pages`.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **color_order** (*Optional*): Should be one of ``rgb`` (default) or ``bgr``.
- **dimensions** (**Required**): Dimensions of the screen, specified either as *width* **x** *height* (e.g ``320x240``) or with separate config keys.
- **height** (**Required**, int): Specifies height of display in pixels.
- **width** (**Required**, int): Specifies width of display.
- **offset_width** (*Optional*, int): Specify an offset for the x-direction of the display, typically used when a display is smaller than the maximum supported by the driver chip. Default is 0
- **offset_height** (*Optional*, int): Specify an offset for the y-direction of the display. Default is 0.
- **rotation** (*Optional*): Rotate the display presentation in software. Choose one of ``0°``, ``90°``, ``180°``, or ``270°``.
- **transform** (*Optional*): Transform the display presentation using hardware. All defaults are ``false``. This option cannot be used with ``rotation``.
- **swap_xy** (*Optional*, boolean): If true, exchange the x and y axes.
- **mirror_x** (*Optional*, boolean): If true, mirror the x axis.
- **mirror_y** (*Optional*, boolean): If true, mirror the y axis.
- **data_rate** (*Optional*): Set the data rate of the SPI interface to the display. One of ``80MHz``, ``40MHz``, ``20MHz``, ``10MHz`` (default), ``5MHz``, ``2MHz`` or ``1MHz``.
- **spi_mode** (*Optional*): Set the mode for the SPI interface to the display. Default is ``MODE0``.
- **invert_colors** (*Optional*): With this boolean option you can invert the display colors.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
See :ref:`display-engine` for more information.
Example configurations
----------------------
Lilygo T4-S3
************
.. code-block:: yaml
spi:
id: quad_spi
type: quad
clk_pin: 15
data_pins: [14, 10, 16, 12]
i2c:
sda: 6
scl: 7
touchscreen:
- platform: cst226
id: my_touchscreen
interrupt_pin: 8
reset_pin: 17
display:
- platform: qspi_amoled
model: RM690B0
data_rate: 80MHz
spi_mode: mode0
dimensions:
width: 450
height: 600
offset_width: 16
color_order: rgb
invert_colors: false
brightness: 255
cs_pin: 11
reset_pin: 13
enable_pin: 9
update_interval: never
auto_clear_enabled: false
psram:
mode: octal
speed: 80MHz
Lilygo T-Display S3 AMOLED
**************************
.. code-block:: yaml
spi:
id: quad_spi
type: quad
clk_pin: 47
data_pins:
- 18
- 7
- 48
- 5
i2c:
sda: 3
scl: 2
touchscreen:
- platform: cst816
id: my_touchscreen
interrupt_pin:
number: 21
display:
- platform: qspi_amoled
model: RM67162
id: main_lcd
dimensions:
height: 240
width: 536
transform:
mirror_x: true
swap_xy: true
color_order: rgb
brightness: 255
cs_pin: 6
reset_pin: 17
enable_pin: 38
See Also
--------
- :doc:`index`
- :apiref:`qspi_amoled/qspi_amoled.h`
- :ghedit:`Edit`

213
components/display/rpi_dpi_rgb.rst Normal file
View File

@ -0,0 +1,213 @@
RPI_DPI_RGB Display Driver
===========================
.. seo::
:description: Instructions for setting up 16 bit "RPI_DPI_RGB" parallel displays
:image: waveshare_touch-s3.jpg
.. _rpi_dpi_rgb:
Models
------
This display driver supports displays with 16 bit parallel interfaces, often referred to as "RPI_DPI_RGB" type.
These have a parallel interface but no SPI interface and require no configuration of the driver chip.
This driver has been tested with the following displays:
- Waveshare ESP32-S3-Touch-LCD-4.3
- Makerfabs 4.3" display (Sunton)
Usage
-----
This component requires an ESP32 (usually an ESP32-S3 because of the number of GPIO pins required) and the use of
ESP-IDF. PSRAM is a requirement due to the size of the display buffer.
.. figure:: images/waveshare_touch-s3.jpg
:align: center
:width: 75.0%
Waveshare ESP32-S3 Touch 4.3
.. code-block:: yaml
# Example minimal configuration entry
display:
- platform: rpi_dpi_rgb
id: rpi_disp
dimensions:
width: 800
height: 480
de_pin: REPLACE_ME
hsync_pin: REPLACE_ME
vsync_pin: REPLACE_ME
pclk_pin: REPLACE_ME
data_pins:
red:
- XX #r1
- XX #r2
- XX #r3
- XX #r4
- XX #r5
green:
- XX #g0
- XX #g1
- XX #g2
- XX #g3
- XX #g4
- XX #g5
blue:
- XX #b1
- XX #b2
- XX #b3
- XX #b4
- XX #b5
Configuration variables:
************************
- **data_pins** (**Required**) A list of pins used for the databus. Specified in 3 groups:
- **red**: (**Required**, :ref:`Pin Schema <config-pin_schema>`) Exactly 5 pin numbers for the red databits, listed from least to most significant bit.
- **green**: (**Required**, :ref:`Pin Schema <config-pin_schema>`) Exactly 6 pin numbers for the green databits, listed from least to most significant bit.
- **blue**: (**Required**, :ref:`Pin Schema <config-pin_schema>`) Exactly 5 pin numbers for the blue databits, listed from least to most significant bit.
- **de_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The DE pin
- **pclk_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The PCLK pin.
- **hsync_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The Horizontal sync pin.
- **vsync_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The Vertical sync pin.
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
- **hsync_pulse_width** (*Optional*, int): The horizontal sync pulse width.
- **hsync_front_porch** (*Optional*, int): The horizontal front porch length.
- **hsync_back_porch** (*Optional*, int): The horizontal back porch length.
- **vsync_pulse_width** (*Optional*, int): The vertical sync pulse width.
- **vsync_front_porch** (*Optional*, int): The vertical front porch length.
- **vsync_back_porch** (*Optional*, int): The vertical back porch length.
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``5s``.
- **auto_clear_enabled** (*Optional*, boolean): Whether to automatically clear the display in each loop (''true'', default),
or to keep the existing display content (must overwrite explicitly, e.g., only on data change).
- **pages** (*Optional*, list): Show pages instead of a single lambda. See :ref:`display-pages`.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **color_order** (*Optional*): Should be one of ``bgr`` (default) or ``rgb``.
- **dimensions** (**Required**): Dimensions of the screen, specified either as *width* **x** *height* (e.g ``320x240``) or with separate config keys.
- **height** (**Required**, int): Specifies height of display in pixels.
- **width** (**Required**, int): Specifies width of display.
- **offset_width** (*Optional*, int): Specify an offset for the x-direction of the display, typically used when an LCD is smaller than the maximum supported by the driver chip. Default is 0
- **offset_height** (*Optional*, int): Specify an offset for the y-direction of the display. Default is 0.
- **pclk_frequency** (*Optional*): Set the pixel clock speed. Default is 16MHz.
- **pclk_inverted** (*Optional* bool): If the pclk is active negative (default is True)
- **invert_colors** (*Optional*): With this boolean option you can invert the display colors. **Note** some of the displays have this option set automatically to true and can't be changed.
- **rotation** (*Optional*): Rotate the display presentation in software. Choose one of ``0°``, ``90°``, ``180°``, or ``270°``.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
See :ref:`display-engine` for more information.
The horizontal and vertical ``pulse_width``, ``front_porch`` and ``back_porch`` values are optional, but may require
changing for a specific display. Refer to the manufacturer's sample code for suitable values. These specify timing
requirements for the display.
Example configurations
----------------------
Waveshare ESP32-S3 Touch 4.3
****************************
.. code-block:: yaml
display:
- platform: rpi_dpi_rgb
auto_clear_enabled: false
color_order: RGB
pclk_frequency: 16MHz
dimensions:
width: 800
height: 480
de_pin:
number: 5
hsync_pin:
number: 46
ignore_strapping_warning: true
vsync_pin:
number: 3
ignore_strapping_warning: true
pclk_pin: 7
hsync_back_porch: 30
hsync_front_porch: 210
hsync_pulse_width: 30
vsync_back_porch: 4
vsync_front_porch: 4
vsync_pulse_width: 4
data_pins:
red:
- 1 #r3
- 2 #r4
- 42 #r5
- 41 #r6
- 40 #r7
blue:
- 14 #b3
- 38 #b4
- 18 #b5
- 17 #b6
- 10 #b7
green:
- 39 #g2
- 0 #g3
- 45 #g4
- 48 #g5
- 47 #g6
- 21 #g7
Makerfabs 4.3" 800x480 display
******************************
.. code-block:: yaml
display:
- platform: rpi_dpi_rgb
update_interval: never
auto_clear_enabled: false
id: rpi_display
color_order: RGB
rotation: 90
dimensions:
width: 800
height: 480
de_pin:
number: 40
hsync_pin: 39
vsync_pin: 41
pclk_pin: 42
data_pins:
red:
- 45 #r1
- 48 #r2
- 47 #r3
- 21 #r4
- 14 #r5
green:
- 5 #g0
- 6 #g1
- 7 #g2
- 15 #g3
- 16 #g4
- 4 #g5
blue:
- 8 #b1
- 3 #b2
- 46 #b3
- 9 #b4
- 1 #b5
See Also
--------
- :doc:`index`
- :apiref:`rpi_dpi_rgb/rpi_dpi_rgb.h`
- :ghedit:`Edit`

15
components/display/ssd1306.rst
View File

@ -12,7 +12,9 @@ Over I²C
The ``ssd1306_i2c`` display platform allows you to use
SSD1306 (`datasheet <https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf>`__,
`Adafruit <https://www.adafruit.com/product/326>`__), SSD1305 (`datasheet <https://cdn-shop.adafruit.com/datasheets/SSD1305.pdf>`__)
`Adafruit <https://www.adafruit.com/product/326>`__), SSD1305 (`datasheet <https://cdn-shop.adafruit.com/datasheets/SSD1305.pdf>`__),
SH1107 (`datasheet <https://cdn-learn.adafruit.com/assets/assets/000/094/580/original/SH1107_datasheet.pdf>`__,
`Adafruit <https://www.adafruit.com/product/4650>`__)
and SH1106 (`datasheet <https://www.elecrow.com/download/SH1106%20datasheet.pdf>`__,
`electrodragon <https://www.electrodragon.com/product/1-3-12864-blue-oled-display-iicspi/>`__)
displays with ESPHome. Note that this component is for displays that are connected via the :ref:`I²C Bus <i2c>`.
@ -58,6 +60,7 @@ Configuration variables:
- ``SH1106 96x16``
- ``SH1106 64x48``
- ``SH1107 128x64``
- ``SH1107 128x128``
- ``SSD1305 128x32``
- ``SSD1305 128x64``
@ -71,8 +74,8 @@ Configuration variables:
Defaults to ``false``.
- **flip_x** (*Optional*, boolean): Flip the horizontal axis on the screen. Defaults to ``true``.
- **flip_y** (*Optional*, boolean): Flip the vertical axis on the screen. Defaults to ``true``.
- **offset_x** (*Optional*, int): Set this option if some horizontal pixel is missing. Numbers are only allowed between ``-32~32``. Defaults to ``0``.
- **offset_y** (*Optional*, int): Set this option if some vertical pixel is missing. Numbers are only allowed between ``-32~32``. Defaults to ``0``.
- **offset_x** (*Optional*, int): Set this option if some horizontal pixel is missing. Numbers are only allowed between ``0~128``. Defaults to ``0``.
- **offset_y** (*Optional*, int): Set this option if some vertical pixel is missing. Numbers are only allowed between ``0~128``. Defaults to ``0``.
- **invert** (*Optional*, boolean): Invert all pixel state on the display. Defaults to ``false``.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
See :ref:`display-engine` for more information.
@ -138,6 +141,7 @@ Configuration variables:
- ``SH1106 96x16``
- ``SH1106 64x48``
- ``SH1107 128x64``
- ``SH1107 128x128``
- ``SSD1305 128x32``
- ``SSD1305 128x64``
@ -152,8 +156,8 @@ Configuration variables:
Defaults to ``false``.
- **flip_x** (*Optional*, boolean): Flip the horizontal axis on the screen. Defaults to ``true``.
- **flip_y** (*Optional*, boolean): Flip the vertical axis on the screen. Defaults to ``true``.
- **offset_x** (*Optional*, int): Set this option if some horizontal pixel is missing. Numbers are only allowed between ``-32~32``. Defaults to ``0``.
- **offset_y** (*Optional*, int): Set this option if some vertical pixel is missing. Numbers are only allowed between ``-32~32``. Defaults to ``0``.
- **offset_x** (*Optional*, int): Set this option if some horizontal pixel is missing. Numbers are only allowed between ``0~128``. Defaults to ``0``.
- **offset_y** (*Optional*, int): Set this option if some vertical pixel is missing. Numbers are only allowed between ``0~128``. Defaults to ``0``.
- **invert** (*Optional*, boolean): Invert all pixel state on the display. Defaults to ``false``.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
See :ref:`display-engine` for more information.
@ -168,6 +172,7 @@ See Also
- :doc:`index`
- :apiref:`ssd1306_base/ssd1306_base.h`
- `SH110x Library <https://github.com/adafruit/Adafruit_SH110x>`__ by `Adafruit <https://www.adafruit.com/>`__
- `SSD1306 Library <https://github.com/adafruit/Adafruit_SSD1306>`__ by `Adafruit <https://www.adafruit.com/>`__
- `SSD1305 Library <https://github.com/adafruit/Adafruit_SSD1305>`__ by `Adafruit <https://www.adafruit.com/>`__
- :ghedit:`Edit`

191
components/display/st7567.rst Normal file
View File

@ -0,0 +1,191 @@
ST7567 LCD Graphic Display
==========================
.. seo::
:description: Instructions for setting up ST7567 Mono STN-LCD display drivers.
:image: st7567.jpg
.. _st7567:
Usage
-----
The ``st7567`` display platform allows you to use wide range of 128x64 display modules based on
Sitronix ST7567 chipset family (ST7567A, ST7567S, ST7567G, etc.) (`datasheet <https://github.com/latonita/datasheets-storage/blob/main/lcd-modules/ST7567A_V1.2b.pdf>`__,
`Sitronix <https://www.sitronix.com.tw/en/products/industrial-display-driver-ic/mono-stn-lcd-driver-ic/>`__,
`Aliexpress <https://www.aliexpress.com/af/st7567s.html>`__) with ESPHome.
Note that this component is for displays that are connected via the :ref:`I²C Bus <i2c>` (see :ref:`st7567-i2c`)
or 3-Wire or 4-Wire :ref:`SPI bus <spi>` (see :ref:`st7567-spi`).
It's a monochrome LCD graphic display.
.. figure:: images/st7567-full.jpg
:align: center
:width: 75.0%
ST7567A based LCD Graphic Display (I²C)
.. note::
**Voltage:** Check your module specs for required power. Most of the modules are tolerant to range of voltages from 3.3V to 5V, but some might require either 5V or 3.3V.
**Electrical interference:** To reduce malfunction caused by noise, datasheet recommends to "use the refresh sequence regularly in a specified interval".
Noone knows what exact interval is - it varies based on your electrical environment - some might need it every hour, for example.
Without doing refresh sequence picture on LCD might get glitchy after some time.
You can plan refresh by using ``interval:`` section and calling ``request_refresh()`` function, after that it will perform display
refresh sequence on next component update.
.. _st7567-i2c:
Over I²C
--------
Connect ``SDA`` and ``SCL`` pins on a module to pins you chose for the :ref:`I²C Bus <i2c>`.
If your display module has ``RESET`` pin you may optionally connect it to a pin on the
ESP which may improve reliability. For power, connect ``VCC`` to 3.3V and ``GND`` to ``GND``.
.. code-block:: yaml
# Example minimal configuration entry
i2c:
sda: D1
scl: D2
display:
- platform: st7567_i2c
id: my_display
lambda: |-
it.print(0, 0, id(my_font), "Hello World!");
interval:
- interval: 1h
then:
- lambda: id(my_display).request_refresh();
Configuration variables:
************************
- **address** (*Optional*, int): Manually specify the :ref:`I²C <i2c>` address of the display. Defaults to 0x3F.
- **i2c_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`I²C Component <i2c>` if you want
to use multiple I²C buses.
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin. Defaults to not connected.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``1s``.
- **pages** (*Optional*, list): Show pages instead of a single lambda. See :ref:`display-pages`.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
- **invert_colors** (*Optional*, boolean): Display hardware color invesion. Defaults to ``false``.
- **rotation** (*Optional*): Set the rotation of the display. Everything you draw in ``lambda:`` will be rotated
by this option. One of ``0°`` (default), ``90°``, ``180°``, ``270°``.
- **transform** (*Optional*): Transform the display presentation using hardware. All defaults are ``false``.
- **mirror_x** (*Optional*, boolean): If true, mirror the physical X axis.
- **mirror_y** (*Optional*, boolean): If true, mirror the physical Y axis.
**Speeding up the bus:** To speed up the display update process you can select higher I²C frequencies, for example:
.. code-block:: yaml
# Example increased I²C bus speed
i2c:
sda: D1
scl: D2
frequency: 400kHz
**Hardware rotation:** 180 degree rotation can be implemented in hardware as in the following example:
.. code-block:: yaml
# Example using transform section to achieve 180° rotation using hardware
display:
- platform: st7567_i2c
id: my_display
transform:
mirror_x: true
mirror_y: true
lambda: |-
it.print(0, 0, id(my_font), "Hello World!");
.. _st7567-spi:
Over SPI
--------
Connect ``D0`` to the ``CLK`` pin you chose for the :ref:`SPI bus <spi>`, connect ``D1`` to the ``MOSI`` pin and ``DC`` and ``CS``
to some GPIO pins on the ESP. For power, connect ``VCC`` to 3.3V and ``GND`` to ``GND``.
Optionally you can also connect the ``RESET`` pin to a pin on the ESP which may improve reliability.
.. code-block:: yaml
# Example minimal configuration entry
spi:
clk_pin: D1
mosi_pin: D2
display:
- platform: st7567_spi
id: my_display
dc_pin: D3
lambda: |-
it.print(0, 0, id(my_font), "Hello World!");
interval:
- interval: 1h
then:
- lambda: id(my_display).request_refresh();
Configuration variables:
************************
- **dc_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The DC pin.
- **cs_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The Chip Select (CS) pin.
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin. Defaults to not connected.
- **spi_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`SPI Component <spi>` if you want
to use multiple SPI buses.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``1s``.
- **pages** (*Optional*, list): Show pages instead of a single lambda. See :ref:`display-pages`.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
- **invert_colors** (*Optional*, boolean): Display hardware color invesion. Defaults to ``false``.
- **rotation** (*Optional*): Set the rotation of the display. Everything you draw in ``lambda:`` will be rotated
by this option. One of ``0°`` (default), ``90°``, ``180°``, ``270°``.
- **transform** (*Optional*): Transform the display presentation using hardware. All defaults are ``false``.
- **mirror_x** (*Optional*, boolean): If true, mirror the physical X axis.
- **mirror_y** (*Optional*, boolean): If true, mirror the physical Y axis.
**Hardware rotation:** 180 degree rotation can be implemented in hardware as in the following example:
.. code-block:: yaml
# Example using transform section to achieve 180° rotation using hardware
display:
- platform: st7567_spi
id: my_display
dc_pin: D3
transform:
mirror_x: true
mirror_y: true
lambda: |-
it.print(0, 0, id(my_font), "Hello World!");
See Also
--------
- :doc:`index`
- :ref:`display-engine`
- :ref:`Display Menu <display_menu>`
- :ref:`i2c`
- :ref:`spi`
- :apiref:`st7567/st7567.h`
- :ghedit:`Edit`

199
components/display/st7701s.rst Normal file
View File

@ -0,0 +1,199 @@
ST7701S Display Driver
======================
.. seo::
:description: Instructions for setting up ST7701S 16 bit "RGB" parallel displays
:image: indicator.jpg
.. _st7701s:
Models
------
This display driver supports displays with 16 bit parallel interfaces, often referred to as "RGB". It currently
supports the ST7701S chip.
This driver has been tested with the following displays:
- Seeed Sensecap Indicator
- Makerfabs 4" display
Usage
-----
This component requires an ESP32 (usually an ESP32-S3 because of the number of GPIO pins required) and the use of
ESP-IDF. PSRAM is a requirement due to the size of the display buffer.
.. figure:: images/indicator.jpg
:align: center
:width: 75.0%
Sensecap Indicator display
.. code-block:: yaml
# Example minimal configuration entry
display:
- platform: st7701s
dimensions:
width: 480
height: 480
cs_pin: REPLACE_ME
reset_pin: REPLACE_ME
de_pin: REPLACE_ME
hsync_pin: REPLACE_ME
vsync_pin: REPLACE_ME
pclk_pin: REPLACE_ME
# Replace XX with the correct pin number
data_pins:
red:
- XX #r1
- XX #r2
- XX #r3
- XX #r4
- XX #r5
green:
- XX #g0
- XX #g1
- XX #g2
- XX #g3
- XX #g4
- XX #g5
blue:
- XX #b1
- XX #b2
- XX #b3
- XX #b4
- XX #b5
Configuration variables:
************************
- **init_sequence** (*Optional*, A list of byte arrays): Specifies the init sequence for the display
- **data_pins** (**Required**): A list of pins used for the databus. Specified in 3 groups.
- **red**: (**Required**, :ref:`Pin Schema <config-pin_schema>`) Exactly 5 pin numbers for the red databits, listed from least to most significant bit.
- **green**: (**Required**, :ref:`Pin Schema <config-pin_schema>`) Exactly 6 pin numbers for the green databits, listed from least to most significant bit.
- **blue**: (**Required**, :ref:`Pin Schema <config-pin_schema>`) Exactly 5 pin numbers for the blue databits, listed from least to most significant bit.
- **de_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The DE pin.
- **dc_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The DC pin.
- **pclk_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The PCLK pin.
- **hsync_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The Horizontal sync pin.
- **vsync_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The Vertical sync pin.
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
- **hsync_pulse_width** (*Optional*, int): The horizontal sync pulse width.
- **hsync_front_porch** (*Optional*, int): The horizontal front porch length.
- **hsync_back_porch** (*Optional*, int): The horizontal back porch length.
- **vsync_pulse_width** (*Optional*, int): The vertical sync pulse width.
- **vsync_front_porch** (*Optional*, int): The vertical front porch length.
- **vsync_back_porch** (*Optional*, int): The vertical back porch length.
- **pclk_frequency** (*Optional*): Set the pixel clock speed. Default is 8MHz.
- **pclk_inverted** (*Optional* bool): If the pclk is active negative (default is True)
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``5s``.
- **auto_clear_enabled** (*Optional*, boolean): Whether to automatically clear the display in each loop (''true'', default),
or to keep the existing display content (must overwrite explicitly, e.g., only on data change).
- **pages** (*Optional*, list): Show pages instead of a single lambda. See :ref:`display-pages`.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **color_order** (*Optional*): Should be one of ``bgr`` (default) or ``rgb``.
- **dimensions** (**Required**): Dimensions of the screen, specified either as *width* **x** *height* (e.g ``320x240``) or with separate config keys.
- **height** (**Required**, int): Specifies height of display in pixels.
- **width** (**Required**, int): Specifies width of display.
- **offset_width** (*Optional*, int): Specify an offset for the x-direction of the display, typically used when an LCD is smaller than the maximum supported by the driver chip. Default is 0
- **offset_height** (*Optional*, int): Specify an offset for the y-direction of the display. Default is 0.
- **data_rate** (*Optional*): Set the data rate of the SPI interface to the display. One of ``80MHz``, ``40MHz``,
``20MHz``, ``10MHz``, ``5MHz``, ``2MHz``, ``1MHz`` (default), ``200kHz``, ``75kHz`` or ``1kHz``.
- **spi_mode** (*Optional*): Set the mode for the SPI interface to the display. Default is ``MODE0`` but some displays require ``MODE3``.
- **invert_colors** (*Optional*): With this boolean option you can invert the display colors. **Note** some of the displays have this option set automatically to true and can't be changed.
- **rotation** (*Optional*): Rotate the display presentation in software. Choose one of ``0°``, ``90°``, ``180°``, or ``270°``. This option cannot be used with ``transform``.
- **transform** (*Optional*): Transform the display presentation using hardware. All defaults are ``false``. This option cannot be used with ``rotation``.
- **swap_xy** (*Optional*, boolean): If true, exchange the x and y axes.
- **mirror_x** (*Optional*, boolean): If true, mirror the x axis.
- **mirror_y** (*Optional*, boolean): If true, mirror the y axis.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
See :ref:`display-engine` for more information.
**Note:** To rotate the display in hardware use one of the following combinations:
- 90 degrees - use ``swap_xy`` with ``mirror_x``
- 180 degrees - use ``mirror_x`` with ``mirror_y``
- 270 degrees - use ``swap_xy`` with ``mirror_y``
The horizontal and vertical ``pulse_width``, ``front_porch`` and ``back_porch`` values are optional, but may require
changing for a specific display. Refer to the manufacturer's sample code for suitable values. These specify timing
requirements for the display.
The ``init_sequence`` requires a list of elements, one of which may be a single integer selecting a canned init
sequence (the default and currently the only sequence is 1), the remainder must be byte arrays providing additional
init commands, each consisting of a command byte followed by zero or more data bytes.
These will be collected and sent to the display via SPI during initialisation.
Example configurations
----------------------
Seeed Sensecap Indicator
************************
.. code-block:: yaml
display:
- platform: st7701s
auto_clear_enabled: false
update_interval: never
spi_mode: MODE3
color_order: RGB
dimensions:
width: 480
height: 480
invert_colors: true
transform:
mirror_x: true
mirror_y: true
cs_pin:
pca9554: p_c_a
number: 4
reset_pin:
pca9554: p_c_a
number: 5
de_pin: 18
hsync_pin: 16
vsync_pin: 17
pclk_pin: 21
init_sequence:
- 1 # select canned init sequence number 1
- [ 0xE0, 0x1F ] # Set sunlight readable enhancement
data_pins:
red:
- 4 #r1
- 3 #r2
- 2 #r3
- 1 #r4
- 0 #r5
green:
- 10 #g0
- 9 #g1
- 8 #g2
- 7 #g3
- 6 #g4
- 5 #g5
blue:
- 15 #b1
- 14 #b2
- 13 #b3
- 12 #b4
- 11 #b5
lambda: |-
it.fill(COLOR_BLACK);
it.print(0, 0, id(my_font), id(my_red), TextAlign::TOP_LEFT, "Hello World!");
See Also
--------
- :doc:`index`
- :apiref:`st7701s/st7701s.h`
- :ghedit:`Edit`

17
components/display/st7789v.rst
View File

@ -25,6 +25,12 @@ The TTGO T-Display module shown has the display attached to the module's board a
cannot be changed. Other display modules have pin headers or other connectors which must be connected appropriately
to an ESP module.
.. warning::
This component has been made redundant since the ST7789V is now supported by the :ref:`ILI9XXX component <ili9xxx>`. It is recommended
that you use the ``ili9xxx`` component as it will be maintained, whereas this component may not be, or may be removed completely
in the future.
.. note::
Displays larger than the 135x240 pixel display on the TTGO T-Display shown require a significant amount of RAM
@ -72,6 +78,7 @@ If you do specify them they will override any default.
- ``Adafruit RR 280x240`` (round-rectangular display -- some pixels are "deleted" from corners to form rounded shape)
- ``Adafruit S2 TFT FEATHER 240X135``
- ``LILYGO T-Embed 170X320``
- ``Waveshare 1.47in 172X320`` (round-rectangular display -- some pixels are "deleted" from corners to form rounded shape)
- ``Custom`` For other displays not listed above
- **height** (**Required**, int): Sets height of display in pixels. Defaults depends ``model``.
@ -177,6 +184,16 @@ Items marked RQ are hardware dependent but required and not preset. Items marked
- 46
- 12
- 11
* - Waveshare 1.47in 172X320
- 320/172
- 34/0
- 21
- 22
- 23
- 4
-
- 18
- 19
* - Custom
- RQ
- RQ

16
components/display/waveshare_epaper.rst
View File

@ -7,8 +7,9 @@ Waveshare E-Paper Display
The ``waveshare_epaper`` display platform allows you to use
some E-Paper displays sold by `Waveshare <https://www.waveshare.com/product/displays/e-paper.htm>`__
with ESPHome. The 2.13" `TTGO module <https://github.com/lewisxhe/TTGO-EPaper-Series>`__ with an ESP32 on the board
is supported as well. Depending on your specific revision of the board you might need to try out the ``-b73`` or ``-b1``
with ESPHome. The 2.13" `TTGO module <https://github.com/lewisxhe/TTGO-EPaper-Series>`__ and the
`Waveshare Cloud Module <https://www.waveshare.com/wiki/2.13inch_e-Paper_Cloud_Module>`__ with an ESP32
on the board are supported as well. Depending on your specific revision of the TTGO board you might need to try out the ``-b73`` or ``-b1``
version (see below).
The 1.54" `Good Display gdew0154m09 <https://www.good-display.com/product/206.html>`__
as used in the `M5Stack Core Ink <https://shop.m5stack.com/products/m5stack-esp32-core-ink-development-kit1-54-elnk-display>`__
@ -88,10 +89,17 @@ Configuration variables:
- ``2.13in-ttgo-b74`` - T5_V2.3.1 with B74 display tested
- ``2.13in-ttgo-b1`` - T5_V2.3 with B1 display tested
- ``2.13in-ttgo-dke`` - T5_V2.3 with DKE group display (DEPG0213BN) tested
- ``2.13inv2`` - 2.13in V2 display (Pico e-Paper 2.13v2 and Cloud Module)
- ``2.13inv3`` - 2.13in V3 display (Pico e-Paper 2.13v3)
- ``2.70in`` - currently not working with the HAT Rev 2.1 version
- ``2.70inv2``
- ``2.70in-b`` - Black/White/Red
- ``2.70in-bv2`` - Black/White/Red
- ``2.90in``
- ``2.90inv2``
- ``2.90inv2-r2`` - 2.9in V2 display, but with different initialization and full/partial display refresh management than ``2.90inv2``
- ``2.90in-b`` - B/W rendering only
- ``2.90in-bV3`` - B/W rendering only
- ``4.20in``
- ``4.20in-bV2`` - B/W rendering only
- ``5.83in``
@ -114,13 +122,13 @@ Configuration variables:
- **busy_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The BUSY pin. Defaults to not connected.
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin. Defaults to not connected.
Make sure you pull this pin high (by connecting it to 3.3V with a resistor) if not connected to a GPIO pin.
The B74 display variant requires the reset pin.
The 2.13" B74 and V2 display variants require the reset pin.
- **rotation** (*Optional*): Set the rotation of the display. Everything you draw in ``lambda:`` will be rotated
by this option. One of ``0°`` (default), ``90°``, ``180°``, ``270°``.
- **full_update_every** (*Optional*, int): E-Paper displays have two modes of switching to the next image: A partial
update that only changes the pixels that have changed and a full update mode that first clears the entire display
and then re-draws the image. The former is much quicker and nicer, but every so often a full update needs to happen
because artifacts accumulate. On the ``1.54in``, ``1.54inv2``, ``2.13in``, ``2.90in`` and ``2.90inv2`` models you have the option to switch only
because artifacts accumulate. On the ``1.54in``, ``1.54inv2``, ``2.13in``, ``2.13inv2``, ``2.90in`` and ``2.90inv2`` models, you have the option to only
do a full-redraw every x-th time using this option. Defaults to ``30`` on the described models and a full update for
all other models.
- **reset_duration** (*Optional*, :ref:`config-time`): Duration for the display reset operation. Defaults to ``200ms``.

241
components/display_menu/graphical_display_menu.rst Normal file
View File

@ -0,0 +1,241 @@
.. _graphical_display_menu:
Graphical Display Menu
======================
.. seo::
:description: Instructions for setting up a simple hierarchical menu on displays.
:image: lcd_menu.png
The component provides an infrastructure for setting up a hierarchical menu
on graphical displays. This offers the user an interactive method to display
labels, control entities like ``switch``, ``select``, ``number`` available locally on the
ESPHome node, without the requirement of a network connection.
.. figure:: images/graphical_display_menu.jpg
:align: center
:width: 60.0%
Overview
--------
The integration implements the :ref:`Display Menu <display_menu>` integration providing
a hierarchical menu primarily intended to be controlled either by a rotary encoder
with a button or a five-button joystick controller.
The component needs to be connected to an instance of a display supporting ESPHome's rendering
engine such as :doc:`E-Paper displays </components/display/waveshare_epaper>` or :doc:`OLED displays </components/display/ssd1306>`.
.. code-block:: yaml
# Example configuration entry
graphical_display_menu:
id: my_graphical_display_menu
display: my_display_component
on_redraw:
then:
component.update: my_display_component
active: false
mode: rotary
items:
...
Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **display** (*Optional*, :ref:`config-id`): ID of the display to render to. See
:ref:`drawing_modes` for more details
- **font** (:ref:`Font <display-fonts>`): Specifies the font to use
- **foreground_color** (*Optional*, :ref:`config-color`): Specifies the foreground color to use.
Defaults to COLOR_ON
- **background_color** (*Optional*, :ref:`config-color`): Specifies the background color to use.
Defaults to COLOR_OFF
Automations:
- **on_redraw** (*Optional*, :ref:`Automation <automation>`): An automation to perform
when the menu needs to be redrawn. This can be useful if your display has slow refresh rates.
For example E-Ink displays that are used with `display_interval: never`
Additional configuration is described in the :ref:`Display Menu <display_menu>` component.
.. _drawing_modes:
Drawing Modes
-------------
Pop Up Mode
***********
When a **display** is specified the menu will create a :ref:`page <display-pages>` as part of the initialisation. It will render to the entire
of the display when invoked. This is useful when you may want to use the display for other purposes but show a menu in response to user
interaction.
.. note::
Pop Up Mode requires that your display makes use of :ref:`pages <display-pages>`. If you are using a drawing lambda, without pages, it will not
behave as expected. Instead you will have to use Advanced Mode
Advanced Drawing Mode
*********************
If you do not specify a **display** when setting up a menu you will be responsible for controlling drawing of the menu. This also allows you to
render the menu to a smaller portion than the available screen size. It May be useful in situations where you want to display a menu as part of a
larger user interface (for example rendering a sensor graph and a control menu next to it)
.. code-block:: yaml
# Example configuration entry
graphical_display_menu:
- id: my_menu
# Note: No display specified
active: true
display:
- platform: waveshare_epaper
id: my_display_component
pages:
- id: advanced_drawing_mode_page
lambda: |-
const auto display_width = it.get_width();
const auto display_height = it.get_height();
auto half_display_width = (int)(display_width / 2.0f);
// This will render the menu to the right half of the screen leaving the left half for other drawing purposes
// Arguments: it.menu(x, y, menu, width, height);
it.menu(half_display_width, 0, id(my_menu), half_display_width, display_height);
Emulating Pop Up Mode
*********************
If you wish to emulate Pop Up Mode the following sample will emulate the same behaviour. This can
be useful if you're using a display without :ref:`pages <display-pages>` or if you have other
requirements that requires control over how and where the menu is rendered.
.. code-block:: yaml
graphical_display_menu:
id: my_menu
items:
# ... other items here ...
# An exit menu item (or some other mechanism) that calls display_menu.hide
- type: command
on_value:
then:
- display_menu.hide: my_menu
display:
- platform: ..
lambda: |-
const auto width = it.get_width();
const auto height = it.get_height();
if (id(my_menu).is_active()) {
it.menu(0, 0, id(my_menu), width, height);
} else {
it.print(0, 0, id(font), "Menu is hidden, other drawing would go here here");
}
Controlling Menu Item Rendering
-------------------------------
By default menu items with a value will be rendered between a set of parenthesis. This can be
controlled via the `menu_item_value` parameter.
- **menu_item_value** (*Optional*, :ref:`config-lambda`): Specifies how to render values for
menu items that have values (eg. Selects, numbers). Defaults to rendering the value as
"(value here)". Receives a MenuItemValueArguments as the argument`it`.
.. code-block:: yaml
graphical_display_menu:
menu_item_value: !lambda |-
// Will render your menu item value as "My menu label ~my value here~"" normally and "My menu label *my value here*" when in edit mode
std::string label = " ";
if (it->is_item_selected && it->is_menu_editing) {
label.append("*");
label.append(it->item->get_value_text());
label.append("*");
} else {
label.append("~");
label.append(it->item->get_value_text());
label.append("~");
}
return label;
.. note::
Ensure that all characters you use in the menu_item_value are available glyphs for your :ref:`font <display-fonts>`
User Interaction Example
------------------------
The below example is a more complete example showing how you might use a rotary encoder and button to display/hide the menu and move through the available options
.. code-block:: yaml
# Example configuration entry
display:
- platform: waveshare_epaper
id: my_display_component
pages:
- id: graph_page
lambda: |-
it.print(0, 0, id(my_font), "My menu is not currently active");
font:
- file: ...
id: my_font
size: 16
graphical_display_menu:
id: my_graphical_display_menu
display: my_display_component
on_redraw:
then:
component.update: my_display_component
active: false
mode: rotary
items:
- type: Label
text: Menu Item 1
- type: Label
text: Menu Item 2
# Rotary encoder to provide navigation
sensor:
- platform: rotary_encoder
...
filters:
debounce: 30ms
on_anticlockwise:
- display_menu.up: my_graphical_display_menu
on_clockwise:
- display_menu.down: my_graphical_display_menu
# A debounced GPIO push button is used to 'click'
binary_sensor:
- platform: gpio
...
filters:
- delayed_on: 30ms
- delayed_off: 30ms
on_press:
- if:
condition:
display_menu.is_active: my_graphical_display_menu
then:
- display_menu.enter: my_graphical_display_menu
else:
- display_menu.show: my_graphical_display_menu
See Also
--------
- :ref:`Display Menu <display_menu>`
- :ref:`Display <display-engine>`
- :ref:`display-fonts`
- :ref:`display-pages`
- :apiref:`graphical_display_menu/graphical_display_menu.h`
- :ghedit:`Edit`

BIN
components/display_menu/images/graphical_display_menu.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 101 KiB

23
components/esp32_ble_tracker.rst
View File

@ -264,6 +264,29 @@ Stops the bluetooth scanning. It can be started again with the above start scan
on_...:
- esp32_ble_tracker.stop_scan:
Use on single-core chips
------------------------
On dual-core devices the WiFi component runs on core 1, while this component runs on core 0.
When using this component on single core chips such as the ESP32-C3 both WiFi and ``ble_tracker`` must run on
the same core, and this has been known to cause issues when connecting to WiFi. A work-around for this is to
enable the tracker only while the native API is connected. The following config will achieve this:
.. code-block:: yaml
esp32_ble_tracker:
scan_parameters:
continuous: false
api:
encryption:
key: !secret encryption_key
on_client_connected:
- esp32_ble_tracker.start_scan:
continuous: true
on_client_disconnected:
- esp32_ble_tracker.stop_scan:
See Also
--------

1
components/esp32_camera.rst
View File

@ -162,6 +162,7 @@ Automations:
when a stream starts.
- **on_stream_stop** (*Optional*, :ref:`Automation <automation>`): An automation to perform
when a stream stops.
- **on_image** (*Optional*, :ref:`Automation <automation>`): An automation called when image taken. Image is available as ``image`` variable of type :apistruct:`esp32_camera::CameraImageData`.
Test Setting:

17
components/esphome.rst
View File

@ -40,8 +40,9 @@ Advanced options:
- **build_path** (*Optional*, string): Customize where ESPHome will store the build files
for your node. By default, ESPHome puts the PlatformIO project it uses to build the
firmware in the ``.esphome/build/<NODE>`` directory, but you can customize this
behavior using this option.
firmware in the ``.esphome/build/<NODE>`` (or into path from ``ESPHOME_BUILD_PATH`` environment variable if specified) directory,
but you can customize this behavior using this option. Official docker image automatically use `/build` folder
as default one in case it is mounted to it.
- **platformio_options** (*Optional*, mapping): Additional options to pass over to PlatformIO in the
platformio.ini file. See :ref:`esphome-platformio_options`.
- **includes** (*Optional*, list of files): A list of C/C++ files to include in the main (auto-generated) sketch file
@ -57,6 +58,10 @@ Advanced options:
- **name** (**Required**, string): Name of the project
- **version** (**Required**, string): Version of the project
- **on_update** (*Optional*, :ref:`Automation <automation>`): An automation to perform when the device firmware is updated.
This compares the above ``version`` field with the ``version`` that was in the previous firmware
as long as the ``name`` matches.
The ``version`` is stored in flash memory when the firmware is first run for future comparisons.
- **min_version** (*Optional*, string): The minimum ESPHome version required to compile this configuration.
See :ref:`esphome-min_version`.
- **compile_process_limit** (*Optional*, int): The maximum number of simultaneous compile processes to run.
@ -324,15 +329,15 @@ The same procedure can be done for changing the static IP of a device.
Adding the MAC address as a suffix to the device name
-----------------------------------------------------
Using ``name_add_mac_suffix`` allows :doc:`creators </guides/creators>` to
provision multiple devices at the factory with a single firmware and still
Using ``name_add_mac_suffix`` allows :doc:`creators </guides/creators>` to
provision multiple devices at the factory with a single firmware and still
have unique identification for customer installs.
.. note::
End users will need to create an individual YAML config file if they want to OTA update the
End users will need to create an individual YAML config file if they want to OTA update the
devices in the future. Creators can facilitate this process by providing ``dashboard_import`` URL
for end users. This allows them to easily update their devices as new features are made available
for end users. This allows them to easily update their devices as new features are made available
upstream.

60
components/ethernet.rst
View File

@ -14,7 +14,7 @@ This component and the Wi-Fi component may **not** be used simultaneously, even
.. code-block:: yaml
# Example configuration entry
# Example configuration entry for RMII chips
ethernet:
type: LAN8720
mdc_pin: GPIO23
@ -28,6 +28,18 @@ This component and the Wi-Fi component may **not** be used simultaneously, even
gateway: 10.0.0.1
subnet: 255.255.255.0
.. code-block:: yaml
# Example configuration entry for SPI chips
ethernet:
type: W5500
clk_pin: GPIO19
mosi_pin: GPIO21
miso_pin: GPIO23
cs_pin: GPIO18
interrupt_pin: GPIO36
reset_pin: GPIO22
Configuration variables:
------------------------
@ -35,13 +47,17 @@ Configuration variables:
Supported chipsets are:
- ``LAN8720``
- ``RTL8201``
- ``DP83848``
- ``IP101``
- ``JL1101``
- ``KSZ8081``
- ``KSZ8081RNA``
- ``LAN8720`` (RMII)
- ``RTL8201`` (RMII)
- ``DP83848`` (RMII)
- ``IP101`` (RMII)
- ``JL1101`` (RMII)
- ``KSZ8081`` (RMII)
- ``KSZ8081RNA`` (RMII)
- ``W5500`` (SPI)
RMII configuration variables:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- **mdc_pin** (**Required**, :ref:`config-pin`): The MDC pin of the board.
Usually this is ``GPIO23``.
@ -58,6 +74,24 @@ Configuration variables:
- **phy_addr** (*Optional*, int): The PHY addr type of the Ethernet controller. Defaults to 0.
- **power_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The pin controlling the
power/reset status of the Ethernet controller. Leave unspecified for no power pin (default).
SPI configuration variables:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- **clk_pin** (**Required**, :ref:`config-pin`): The SPI clock pin.
- **mosi_pin** (**Required**, :ref:`config-pin`): The SPI MOSI pin.
- **miso_pin** (**Required**, :ref:`config-pin`): The SPI MISO pin.
- **cs_pin** (**Required**, :ref:`config-pin`): The SPI chip select pin.
- **interrupt_pin** (*Optional*, :ref:`config-pin`): The interrupt pin.
- **reset_pin** (*Optional*, :ref:`config-pin`): The reset pin.
- **clock_speed** (*Optional*, float): The SPI clock speed.
Any frequency between `8Mhz` and `80Mhz` is allowed, but the nearest integer division
of `80Mhz` is used, i.e. `16Mhz` (`80Mhz` / 5) is used when `15Mhz` is configured.
Default: `26.67Mhz`.
Advanced common configuration variables:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- **manual_ip** (*Optional*): Manually configure the static IP of the node.
- **static_ip** (**Required**, IPv4 address): The static IP of your node.
@ -83,6 +117,10 @@ Configuration variables:
clock signal that will not travel reliably over these types of connections. For more
information and wiring details refer to the link in the *See also* section.
.. note::
SPI based chips do *not* use :doc:`spi`. This means that SPI pins can't be shared with other devices.
Configuration examples
----------------------
@ -98,6 +136,10 @@ Configuration examples
phy_addr: 0
power_pin: GPIO12
.. note::
WROVER version of Olimex POE cards change CLK to ping GPIO0, configuration must be `clk_mode: GPIO0_OUT`.
**Olimex ESP32-EVB**:
@ -222,7 +264,7 @@ Configuration examples
clk_mode: GPIO17_OUT
phy_addr: 1
**LILYGO T-ETH-Lite**:
**LILYGO T-ETH-Lite ESP32**:
.. code-block:: yaml

1
components/fan/hbridge.rst
View File

@ -56,6 +56,7 @@ Configuration variables:
will allow 1% increments in the output. Defaults to ``100``.
- **name** (**Required**, string): The name for this fan.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **preset_modes** (*Optional*): A list of preset modes for this fan. Preset modes can be used in automations (i.e. `on_preset_set`).
- All other options from :ref:`Fan Component <config-fan>`.
.. _fan-hbridge_brake_action:

103
components/fan/index.rst
View File

@ -73,12 +73,20 @@ MQTT options:
Automation triggers:
- **on_state** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the fan state is changed. See :ref:`fan-on_state_trigger`.
- **on_turn_on** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the fan is turned on. See :ref:`fan-on_turn_on_off_trigger`.
- **on_turn_off** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the fan is turned off. See :ref:`fan-on_turn_on_off_trigger`.
- **on_direction_set** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the fan direction is changed. See :ref:`fan-on_direction_set_trigger`.
- **on_oscillating_set** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the fan oscillating state is changed. See :ref:`fan-on_oscillating_set_trigger`.
- **on_speed_set** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the fan speed is set/changed. See :ref:`fan-on_speed_set_trigger`.
when the fan speed is changed. See :ref:`fan-on_speed_set_trigger`.
- **on_preset_set** (*Optional*, :ref:`Action <config-action>`): An automation to perform
when the fan preset mode is changed. See :ref:`fan-on_preset_set_trigger`.
.. _fan-toggle_action:
@ -173,6 +181,24 @@ This :ref:`condition <config-condition>` passes if the given fan is on or off.
then:
- script.execute: my_script
.. _fan-on_state_trigger:
``fan.on_state`` Trigger
------------------------
This trigger is activated each time the fan state is changed. It will fire when the state is either set via API e.g. in Home Assistant or locally by an automation or a lambda function.
A pointer to the ``Fan`` is available as a variable called ``x``.
.. code-block:: yaml
fan:
- platform: speed # or any other platform
# ...
on_state:
- logger.log:
format: "Fan State changed! Fan Speed is %d!"
args: [ x->speed ]
.. _fan-on_turn_on_off_trigger:
``fan.on_turn_on`` / ``fan.on_turn_off`` Trigger
@ -191,12 +217,49 @@ if a command to turn the fan on or off already matches the current state.
on_turn_off:
- logger.log: "Fan Turned Off!"
.. _fan-on_direction_set_trigger:
``fan.on_direction_set`` Trigger
--------------------------------
This trigger is activated each time the fan direction is changed. It will fire when the direction is either set via API e.g. in Home Assistant or locally by an automation or a lambda function.
The new direction is available as a variable called ``x``. (``0`` is FORWARD, ``1`` is REVERSE)
.. code-block:: yaml
fan:
- platform: speed # or any other platform
# ...
on_direction_set:
- logger.log:
format: "Fan Direction was changed to %s!"
args: [ x == 0 ? "FORWARD" : "REVERSE" ]
.. _fan-on_oscillating_set_trigger:
``fan.on_oscillating_set`` Trigger
----------------------------------
This trigger is activated each time the fan oscillating state is changed. It will fire when the state is either set via API e.g. in Home Assistant or locally by an automation or a lambda function.
The new oscillating state is available as a variable called ``x``.
.. code-block:: yaml
fan:
- platform: speed # or any other platform
# ...
on_oscillating_set:
- logger.log:
format: "Fan Oscillating State was changed to %s!"
args: [ ONOFF(x) ]
.. _fan-on_speed_set_trigger:
``fan.on_speed_set`` Trigger
----------------------------
This trigger is activated each time the fan speed is changed. It will fire when the speed is either set via API e.g. in Home Assistant or locally by an automation or a lambda function.
The new speed is available as a variable called ``x``.
.. code-block:: yaml
@ -204,7 +267,27 @@ This trigger is activated each time the fan speed is changed. It will fire when
- platform: speed # or any other platform
# ...
on_speed_set:
- logger.log: "Fan Speed was changed!"
- logger.log:
format: "Fan Speed was changed to %d!"
args: [ x ]
.. _fan-on_preset_set_trigger:
``fan.on_preset_set`` Trigger
-----------------------------
This trigger is activated each time the fan preset mode is changed. It will fire when the preset mode is either set via API e.g. in Home Assistant or locally by an automation or a lambda function.
The new mode is available as a variable called ``x``.
.. code-block:: yaml
fan:
- platform: speed # or any other platform
# ...
on_preset_set:
- logger.log:
format: "Fan preset mode was changed to %s!"
args: [ x.c_str() ]
Lambda calls
------------
@ -256,6 +339,17 @@ advanced stuff (see the full API Reference for more info).
// Fan direction is reverse, do something else here
}
- ``preset_mode``: Retrieve the current preset mode of the fan.
.. code-block:: yaml
// Within lambda, get the fan preset mode and conditionally do something
if (id(my_fan).preset_mode == "auto") {
// Fan preset mode is "auto", do something here
} else {
// Fan preset mode is not "auto", do something else here
}
- ``turn_off()``/``turn_on()``/``toggle()``: Manually turn the fan ON/OFF from code.
Similar to the ``fan.turn_on``, ``fan.turn_off``, and ``fan.toggle`` actions,
but can be used in complex lambda expressions.
@ -273,6 +367,11 @@ advanced stuff (see the full API Reference for more info).
call.set_direction(FanDirection::REVERSE);
call.perform();
// Set a preset mode
auto call = id(my_fan).turn_on();
call.set_preset_mode("auto");
call.perform();
// Toggle the fan on/off
auto call = id(my_fan).toggle();
call.perform();

6
components/fan/speed.rst
View File

@ -23,9 +23,8 @@ supports speed settings.
Configuration variables:
------------------------
- **output** (**Required**, :ref:`config-id`): The id of the
:ref:`float output <output>` to use for this fan.
- **name** (**Required**, string): The name for this fan.
- **name** (*Optional*, string): The name for this fan.
- **output** (**Required**, :ref:`config-id`): The id of the :ref:`float output <output>` to use for this fan.
- **oscillation_output** (*Optional*, :ref:`config-id`): The id of the
:ref:`output <output>` to use for the oscillation state of this fan. Default is empty.
- **direction_output** (*Optional*, :ref:`config-id`): The id of the
@ -34,6 +33,7 @@ Configuration variables:
to calculate the percentages for each speed. E.g. ``2`` means that you have 50% and 100% while ``100``
will allow 1% increments in the output. Defaults to ``100``.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **preset_modes** (*Optional*): A list of preset modes for this fan. Preset modes can be used in automations (i.e. `on_preset_set`).
- All other options from :ref:`Fan Component <config-fan>`.
See Also

41
components/fan/template.rst Normal file
View File

@ -0,0 +1,41 @@
Template Fan
============
.. seo::
:description: Instructions for setting up template fans.
:image: fan.svg
The ``template`` fan platform lets you create a fan interface using only triggers.
.. figure:: images/fan-ui.png
:align: center
:width: 80.0%
.. code-block:: yaml
# Example configuration entry
fan:
- platform: template
name: "Virtual Fan"
on_state:
- do something
on_speed_set:
- do something
Configuration variables:
------------------------
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **name** (*Optional*, string): The name for this fan.
- **has_direction** (*Optional*, boolean): Indicates if there should be a control for direction. Default is ``false``.
- **has_oscillating** (*Optional*, boolean): Indicates if there should be a control for oscillating. Default is ``false``.
- **speed_count** (*Optional*, int): Set the number of supported discrete speed levels. Default is only on/off.
- **preset_modes** (*Optional*): A list of preset modes for this fan. Preset modes can be used in automations (i.e. `on_preset_set`).
- All other options from :ref:`Fan Component <config-fan>`.
See Also
--------
- :doc:`/components/fan/index`
- :apiref:`template/fan/template_fan.h`
- :ghedit:`Edit`

105
components/fingerprint_grow.rst
View File

@ -38,10 +38,21 @@ If available on your reader model, it's recommended to connect 3.3VT (touch indu
# Declare Grow Fingerprint Reader
fingerprint_grow:
sensing_pin: GPIO12
sensor_power_pin:
number: GPIO18
inverted: true
idle_period_to_sleep: 5s
on_finger_scan_start:
...
on_finger_scan_matched:
...
on_finger_scan_unmatched:
...
on_finger_scan_misplaced:
...
on_finger_scan_invalid:
...
on_enrollment_scan:
...
on_enrollment_done:
@ -60,10 +71,15 @@ Base Configuration:
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the UART hub.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **sensing_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): Pin connected to the reader's finger detection signal (WAKEUP) output.
- **sensor_power_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): Output pin responsible for toogling the sensor power on and off.
- **password** (*Optional*, int): Password to use for authentication. Defaults to ``0x00``.
- **new_password** (*Optional*, int): Sets a new password to use for authentication. See :ref:`fingerprint_grow-set_new_password` for more information.
- **idle_period_to_sleep** (*Optional*, :ref:`config-time`): The sensor idle period to wait before powering it off (sleep). Defaults to ``5s``. See :ref:`fingerprint_grow-sleep_mode` for more information.
- **on_finger_scan_start** (*Optional*, :ref:`Automation <automation>`): An action to be performed when the finger touches the sensor. See :ref:`fingerprint_grow-on_finger_scan_start`.
- **on_finger_scan_matched** (*Optional*, :ref:`Automation <automation>`): An action to be performed when an enrolled fingerprint is scanned. See :ref:`fingerprint_grow-on_finger_scan_matched`.
- **on_finger_scan_unmatched** (*Optional*, :ref:`Automation <automation>`): An action to be performed when an unknown fingerprint is scanned. See :ref:`fingerprint_grow-on_finger_scan_unmatched`.
- **on_finger_scan_misplaced** (*Optional*, :ref:`Automation <automation>`): An action to be performed when the finger is not entirely touching the sensor. See :ref:`fingerprint_grow-on_finger_scan_misplaced`.
- **on_finger_scan_invalid** (*Optional*, :ref:`Automation <automation>`): An action to be performed when the scan of a fingerprint failed. See :ref:`fingerprint_grow-on_finger_scan_invalid`.
- **on_enrollment_scan** (*Optional*, :ref:`Automation <automation>`): An action to be performed when a fingerprint is scanned during enrollment. See :ref:`fingerprint_grow-on_enrollment_scan`.
- **on_enrollment_done** (*Optional*, :ref:`Automation <automation>`): An action to be performed when a fingerprint is enrolled. See :ref:`fingerprint_grow-on_enrollment_done`.
- **on_enrollment_failed** (*Optional*, :ref:`Automation <automation>`): An action to be performed when a fingerprint enrollment failed. See :ref:`fingerprint_grow-on_enrollment_failed`.
@ -118,6 +134,32 @@ Sensor
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- All other options from :ref:`Sensor <config-sensor>`.
.. _fingerprint_grow-sleep_mode:
Sleep Mode
----------
The sensor idle power consumption is roughly 20mA. If you plan to keep the device running continuously, it is wise to implement the Sleep Mode, which puts the sensor to sleep (power off) a few seconds after the last communication (configurable with ``idle_period_to_sleep``). It can only be implemented along with the Touch Sensing Feature, since it uses the touch feedback to wake up the sensor.
To implement this feature, you will need one more free GPIO pin to toggle the sensor power on and off and two external components: a 10kOhms resistor and a PNP transistor (like a BC327).
This is a wiring example for the R503 and below you can find the respective configuration:
.. figure:: images/fingeprint_grow-sleep_mode_wiring.jpg
:align: center
:width: 50.0%
.. code-block:: yaml
uart:
rx_pin: GPIO16
tx_pin: GPIO17
baud_rate: 57600
fingerprint_grow:
sensing_pin: GPIO4
sensor_power_pin:
number: GPIO18
inverted: true
idle_period_to_sleep: 5s
.. _fingerprint_grow-set_new_password:
@ -144,6 +186,36 @@ The ``new_password:`` configuration option is meant to be compiled, flashed to t
password: 0x72AB96CD # Update the existing password with the new one
.. _fingerprint_grow-on_finger_scan_start:
``on_finger_scan_start`` Trigger
------------------------------------
With this configuration option, you can trigger an automation when a finger is detected touching the sensor. Very useful to indicate to the user via AuraLed that the sensor has detected the finger touch and will perform the scan. This trigger will **only** activate if your fingerprint sensor is configured with the ``sensing_pin`` option.
.. code-block:: yaml
on_finger_scan_start:
- fingerprint_grow.aura_led_control:
state: ALWAYS_ON
color: GREEN
speed: 0
count: 0
.. _fingerprint_grow-on_finger_scan_invalid:
``on_finger_scan_invalid`` Trigger
----------------------------------
With this configuration option you can write complex automations whenever a scan fails, e.g. when the finger is not placed correctly on the reader. This is different from ``on_finger_scan_unmatched`` which is triggered when an unknown fingerprint is scanned. This option works best with the ``sensing_pin`` option defined.
.. code-block:: yaml
on_finger_scan_invalid:
- text_sensor.template.publish:
id: fingerprint_state
state: "Invalid finger"
.. _fingerprint_grow-on_finger_scan_matched:
``on_finger_scan_matched`` Trigger
@ -188,6 +260,21 @@ With this configuration option you can write complex automations whenever an unk
id: fingerprint_state
state: "Unauthorized finger"
.. _fingerprint_grow-on_finger_scan_misplaced:
``on_finger_scan_misplaced`` Trigger
------------------------------------
With this configuration option, you can create automations for situations when the finger is in contact with the sensor but not fully covering it, enabling you to perform a successful scan.
This trigger will **only** activate if your fingerprint sensor is configured with the ``sensing_pin`` option. It serves as a useful indicator to alert the user when their touch on the sensor is insufficient.
.. code-block:: yaml
on_finger_scan_misplaced:
- text_sensor.template.publish:
id: fingerprint_state
state: "Misplaced finger"
.. _fingerprint_grow-on_enrollment_scan:
``on_enrollment_scan`` Trigger
@ -341,6 +428,12 @@ Controls the Aura LED on the reader. Only available on select models. NOTE: The
count: 2
# Sample Aura LED config for all reader triggers
fingerprint_grow:
on_finger_scan_start:
- fingerprint_grow.aura_led_control:
state: ALWAYS_ON
color: GREEN
speed: 0
count: 0
on_finger_scan_matched:
- fingerprint_grow.aura_led_control:
state: BREATHING
@ -353,6 +446,12 @@ Controls the Aura LED on the reader. Only available on select models. NOTE: The
speed: 25
color: RED
count: 2
on_finger_scan_misplaced:
- fingerprint_grow.aura_led_control:
state: FLASHING
speed: 25
color: PURPLE
count: 2
on_enrollment_scan:
- fingerprint_grow.aura_led_control:
state: FLASHING
@ -420,6 +519,9 @@ Sample code
fingerprint_grow:
sensing_pin: GPIO12
on_finger_scan_invalid:
- homeassistant.event:
event: esphome.test_node_finger_scan_invalid
on_finger_scan_matched:
- homeassistant.event:
event: esphome.test_node_finger_scan_matched
@ -429,6 +531,9 @@ Sample code
on_finger_scan_unmatched:
- homeassistant.event:
event: esphome.test_node_finger_scan_unmatched
on_finger_scan_misplaced:
- homeassistant.event:
event: esphome.frontdoor_finger_scan_misplaced
on_enrollment_scan:
- homeassistant.event:
event: esphome.test_node_enrollment_scan

BIN
components/images/fingeprint_grow-sleep_mode_wiring.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

BIN
components/images/pn7150-full.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 180 KiB

BIN
components/images/pn716x-full.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 180 KiB

BIN
components/images/pylontech.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 45 KiB

BIN
components/images/rj45_pinout.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

BIN
components/images/seeed-mr24hpc1-card.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
components/images/seeed-mr24hpc1-mmwave-kit.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
components/images/seeed-mr24hpc1.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

1
components/index.rst
View File

@ -11,6 +11,7 @@ Components
fan/index
light/index
number/index
datetime/index
output/index
select/index
sensor/index

4
components/light/esp32_rmt_led_strip.rst
View File

@ -44,11 +44,15 @@ Configuration variables
- ``BRG``
- **is_rgbw** (*Optional*, boolean): Set to ``true`` if the strip is RGBW. Defaults to ``false``.
- **is_wrgb** (*Optional*, boolean): Set to ``true`` if the strip is WRGB. Defaults to ``false``.
- **max_refresh_rate** (*Optional*, :ref:`config-time`):
A time interval used to limit the number of commands a light can handle per second. For example
16ms will limit the light to a refresh rate of about 60Hz. Defaults to sending commands as quickly as
changes are made to the lights.
- All other options from :ref:`Light <config-light>`.
Manual Timings
**************

8
components/light/index.rst
View File

@ -708,6 +708,7 @@ the strip and shifts them forward every ``add_led_interval``.
num_leds: 1
add_led_interval: 100ms
reverse: false
gradient: false
Configuration variables:
@ -720,7 +721,8 @@ Configuration variables:
- **blue** (*Optional*, percentage): The percentage the blue color channel should be on. Defaults to ``100%``.
- **random** (*Optional*, boolean): If set to ``true``, will overwrite the RGB colors by a new, randomly-chosen
color each time. Defaults to ``false``.
- **num_leds** (*Optional*, int): The number of leds of this type to have before moving on to the next color.
- **num_leds** (**Required**, positive int): The number of LEDs of this type to have before transitioning to the next color. If ``gradient`` is true, this will be the number of LEDs over which the color transition will occur.
- **gradient** (*Optional*, boolean): If ``true`` the current color will transition with a gradient over ``num_leds`` to the next color. Defaults to ``false``.
- **add_led_interval** (*Optional*, :ref:`config-time`): The interval with which to shift in new leds at the
beginning of the strip. Defaults to ``100ms``.
@ -1090,10 +1092,14 @@ It is also possible to use LedFx_ to control the lights. Please use the connecti
effects:
- wled:
# port: 21324
# blank_on_start: True
# sync_group_mask: 0
Configuration variables:
- **port** (*Optional*, int): The port to run the UDP server on. Defaults to ``21324``.
- **blank_on_start** (*Optional*, boolean): Whether or not to blank all LEDs when effect starts. Deaults to ``True``.
- **sync_group_mask** (*Optional*, int): Used with WLED Notifier. The Sync Group mask value that specifies which WLED Sync Groups to listen to. Defaults to ``0`` (All Sync Groups). Sync Groups 1, 2, 3, 4, 5, 6, 7, 8 use masks 1, 2, 4, 8, 16, 32, 64, 128. Combine mask values to listen to multiple Sync Groups.
.. note::

2
components/light/neopixelbus.rst
View File

@ -13,7 +13,7 @@ NeoPixelBus Light
The ``neopixelbus`` light platform allows you to create RGB lights
in ESPHome for an individually addressable lights like NeoPixel or WS2812.
in ESPHome for individually addressable lights like NeoPixel or WS2812.
It is very similar to the :doc:`fastled` platform.
In fact, most addressable lights are supported through both light platforms. The

1
components/light/rp2040_pio_led_strip.rst
View File

@ -42,6 +42,7 @@ Configuration variables
- **is_rgbw** (*Optional*, boolean): Set to ``true`` if the strip is RGBW. Defaults to ``false``.
- All other options from :ref:`Light <config-light>`.
Manual Timings

3
components/light/sonoff_d1.rst
View File

@ -22,8 +22,7 @@ ESP8266 side. Bi-directional symmetric request / response protocol is implemente
between ESP8266 and MCU. ``sonoff_d1`` component implements this protocol and
translates between HA light commands and serial messages.
For detailed instructions on how to replace the stock firmware with ESPHome see :doc:`/devices/sonoff_s20`.
You will need to locate GPIO0 pin and serial port. Photos below should help.
To replace the stock firmware with ESPHome you will need to locate GPIO0 pin and serial port. Photos below should help.
.. figure:: images/sonoff_d1_gpio0.jpg
:align: center

112
components/logger.rst
View File

@ -10,7 +10,7 @@ Logger Component
The logger component automatically logs all log messages through the
serial port and through MQTT topics (if there is an MQTT client in the
configuration). By default, all logs with a severity ``DEBUG`` or higher will be shown.
Increasing the log level severity (to e.g ``INFO`` or ``WARNING``) can help with the performance of the application and memory size.
Increasing the log level severity (to e.g ``INFO`` or ``WARN``) can help with the performance of the application and memory size.
.. code-block:: yaml
@ -35,8 +35,8 @@ Advanced settings:
- **tx_buffer_size** (*Optional*, int): The size of the buffer used
for log messages. Decrease this if you’re having memory problems.
Defaults to ``512``.
- **hardware_uart** (*Optional*, string): The Hardware UART to use for logging.
Defaults to ``UART0``.
- **hardware_uart** (*Optional*, string): The Hardware UART to use for logging. The default varies depending on
the specific processor/chip and framework you are using. See the :ref:`table below <logger-default_hardware_interfaces>`.
- **esp8266_store_log_strings_in_flash** (*Optional*, boolean): If set to false, disables storing
log strings in the flash section of the device (uses more memory). Defaults to true.
- **on_message** (*Optional*, :ref:`Automation <automation>`): An action to be
@ -52,23 +52,99 @@ Advanced settings:
Hardware UARTs
--------------
The logger component makes use of platform-specific hardware UARTs for serial logging.
By default, the logger will occupy ``UART0``. The ESP32 has three hardware UARTs, all of
which can be used for both transmit and receive. The ESP8266 only has two hardware UARTs,
one of which is transmit-only. The ESP8266 ``UART0`` can also be 'swapped' to TX/RX on the
CTS/RTS pins, if you need to use GPIO1 and GPIO3 for something else. Note that the common
NodeMCU boards have their USB-UART Adapters fixed to the default GPIOs used by ``UART0``,
so if you use anything else you will not get log messages over the on-board USB.
The logger component makes use of platform-specific hardware UARTs for serial logging. For example, the ESP32
has three hardware UARTs, all of which can be used for both transmit and receive. The ESP8266 only has two
hardware UARTs, one of which is transmit-only. The ESP8266's ``UART0`` can also be "swapped" to TX/RX on the
CTS/RTS pins in the event that you need to use GPIO1 and GPIO3 for something else.
Possible Hardware UART configurations:
Note that many common boards have their USB-to-serial adapters fixed to the default GPIOs used by ``UART0``,
so if you use any other configuration you will not get log messages over the on-board USB.
- ``UART0`` - TX: GPIO1, RX: GPIO3
- ``UART0_SWAP`` - TX: GPIO15, RX: GPIO13 (Only on ESP8266)
- ``UART1`` - TX: GPIO2, RX: None (Only on ESP8266)
- ``UART1`` - TX: GPIO9, RX: GPIO10 (Only on ESP32)
- ``UART2`` - TX: GPIO16, RX: GPIO17 (Only on ESP32 but not ESP32S2, ESP32S3 or ESP32C3)
- ``USB_CDC`` - uses the USB CDC driver (Only on ESP32S2 and ESP32S3)
- ``USB_SERIAL_JTAG`` - uses the USB Serial/JTAG driver (Only on ESP32S3 and ESP32C3)
Default UART GPIO Pins
**********************
.. list-table::
:header-rows: 1
* -
- ``UART0``
- ``UART0_SWAP``
- ``UART1``
- ``UART2``
- ``USB_CDC``
- ``USB_SERIAL_JTAG``
* - ESP8266
- TX: 1, RX: 3
- TX: 15, RX: 13
- TX: 2, RX: N/A
- N/A
- N/A
- N/A
* - ESP32
- TX: 1, RX: 3
- N/A
- TX: 9, RX: 10
- TX: 16, RX: 17
- N/A
- N/A
* - ESP32-C3
- TX: 21, RX: 20
- N/A
- Undefined
- N/A
- N/A
- 18/19
* - ESP32-S2
- TX: 43, RX: 44
- N/A
- TX: 17, RX: 18
- N/A
- 19/20
- N/A
* - ESP32-S3
- TX: 43, RX: 44
- N/A
- TX: 17, RX: 18
- Undefined
- 19/20
- 19/20
*Undefined* means that the logger component cannot use this harware UART at this time.
.. _logger-default_hardware_interfaces:
Default Hardware Interfaces
---------------------------
Because of the wide variety of boards and processors/chips available, we've selected varying default
hardware interfaces for logging. Many newer boards based on ESP32 variants (such as the C3, S2 and S3)
are using the ESP's on-board USB hardware peripheral while boards based on older processors (such as
the original ESP32 or ESP8266) continue to use USB-to-serial bridge ICs for communication.
.. list-table::
:header-rows: 1
* -
- Arduino
- ESP-IDF
* - ESP8266
- ``UART0``
- N/A
* - ESP32
- ``UART0``
- ``UART0``
* - ESP32-C3
- ``USB_CDC``
- ``USB_SERIAL_JTAG``
* - ESP32-S2
- ``USB_CDC``
- ``USB_CDC``
* - ESP32-S3
- ``USB_CDC``
- ``USB_SERIAL_JTAG``
* - RP2040
- ``USB_CDC``
- N/A
.. _logger-log_levels:

112
components/micro_wake_word.rst Normal file
View File

@ -0,0 +1,112 @@
Micro Wake Word
================
.. seo::
:description: Instructions for creating a custom wake word using microWakeWord.
:image: voice-assistant.svg
ESPHome implements an on-device wake word detection framework from `microWakeWord <https://github.com/kahrendt/microWakeWord>`__.
This repository/library allows you to create a custom wake word for your ESPHome device.
The training process is described on the `microWakeWord GitHub repository <https://github.com/kahrendt/microWakeWord>`__.
The ``micro_wake_word`` component requires an **ESP32-S3 with PSRAM** to function.
.. code-block:: yaml
# Shorthand name
micro_wake_word:
model: okay_nabu
# Github shorthand URL
micro_wake_word:
model: github://esphome/micro-wake-word-models/models/okay_nabu.json
Configuration variables:
------------------------
- **model** (**Required**, string): The model to use. This can be one of:
- A simple name of a model that exists in the official `ESPHome Models repository <https://github.com/esphome/micro-wake-word-models>`__.
e.g. ``okay_nabu``.
- A github shorthand URL to a model JSON file.
e.g. ``github://esphome/micro-wake-word-models/models/okay_nabu.json@main``.
- A full URL to a model JSON file.
e.g. ``https://github.com/esphome/micro-wake-word-models/raw/main/models/okay_nabu.json``.
- **on_wake_word_detected** (*Optional*, Automation): An automation to perform when the wake word is detected.
The ``wake_word`` phrase from the model manifest is provided as a ``std::string`` to any actions in this automation.
The below two options are provided by the JSON file, but can be overridden in YAML.
- **probability_cutoff** (*Optional*, percentage): The probability cutoff for the wake word detection.
If the probability of the wake word is below this value, the wake word is not detected.
A larger value reduces the number of false accepts but increases the number of false rejections.
- **sliding_window_average_size** (*Optional*, int): The size of the sliding window average for the wake word detection. A small value lowers latency but may increase the number of false accepts.
Model JSON
----------
.. code-block:: json
{
"type": "micro",
"wake_word": "okay nabu",
"author": "Kevin Ahrendt",
"website": "https://www.kevinahrendt.com/",
"model": "./okay_nabu.tflite",
"version": 1,
"micro": {
"probability_cutoff": 0.5,
"sliding_window_average_size": 10
}
}
The model JSON file contains the following fields that are all **required** unless otherwise specified:
- **type** (string): The type of the model. This should always be ``micro``.
- **wake_word** (string): The wake word that the model is trained to detect.
- **author** (string): The name of the author that trained the model.
- **website** (string): The website of the author.
- **model** (string): The relative or absolute path or URL to the TFLite trained model file.
- **version** (int): The version of the JSON schema. Currently only version ``1`` exists.
- **micro** (object): The microWakeWord specific configuration.
- **probability_cutoff** (float): The probability cutoff for the wake word detection.
If the probability of the wake word is below this value, the wake word is not detected.
- **sliding_window_average_size** (int): The size of the sliding window average for the wake word detection.
- **minimum_esphome_version** (*Optional* version): The minimum ESPHome version required to use this model.
Automations
-----------
``micro_wake_word.start`` Action
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Starts the wake word detection.
``micro_wake_word.stop`` Action
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Stops the wake word detection.
Example usage
-------------
.. code-block:: yaml
micro_wake_word:
model: okay_nabu
on_wake_word_detected:
then:
- voice_assistant.start:
wake_word: !lambda return wake_word;
See Also
--------
- :doc:`voice_assistant`
- :apiref:`micro_wake_word/micro_wake_word.h`
- :ghedit:`Edit`

4
components/microphone/i2s_audio.rst
View File

@ -12,7 +12,7 @@ This platform only works on ESP32 based chips.
.. warning::
Audio and voice components consume a significant amount of resources (RAM, CPU) on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. In particular, Bluetooth/BLE components are known to cause issues when used in
combination with Voice Assistant and/or other audio components.
@ -41,9 +41,11 @@ Configuration variables:
- ``internal``: Use the internal ADC of the ESP32. Only supported on ESP32, no variant support.
- **channel** (*Optional*, enum): The channel of the microphone. One of ``left`` or ``right``. Defaults to ``right``.
- **sample_rate** (*Optional*, positive integer): I2S sample rate. Defaults to ``16000``.
- **bits_per_sample** (*Optional*, enum): The bit depth of the audio samples. Note that while set to ``32bit``, the samples
will be scaled down to 16bit before being forwarded.
One of ``16bit`` or ``32bit``. Defaults to ``16bit``.
- **use_apll** (*Optional*, boolean): I2S using APLL as main I2S clock, enable it to get accurate clock. Defaults to ``false``.
- **i2s_audio_id** (*Optional*, :ref:`config-id`): The ID of the :ref:`I²S Audio <i2s_audio>` you wish to use for this microphone.
- All other options from :ref:`Microphone <config-microphone>`

34
components/modbus.rst
View File

@ -7,9 +7,32 @@ Modbus Component
:description: Instructions for setting up Modbus in ESPHome.
:keywords: Modbus
The ModBUS protocol is used by many consumer and industrial devices for communication.
This component allows components in ESPHome to communicate to those devices.
ModBUS requires a :ref:`UART Bus <uart>` to communicate.
The Modbus protocol is used by many consumer and industrial devices for communication.
This component allows components in ESPHome to communicate to those devices via RTU protocol. You can access the coils, inputs, holding, read registers from your devices as sensors, switches, selects, numbers or various other ESPHome components and present them to your favorite Home Automation system. You can even write them as binary or float ouptputs from ESPHome.
The various sub-components implement some of the Modbus functions below (depending on their required functionality):
+---------------+----------------------------+
| Function Code | Description |
+===============+============================+
| 1 | Read Coil Status |
+---------------+----------------------------+
| 2 | Read Discrete input Status |
+---------------+----------------------------+
| 3 | Read Holding Registers |
+---------------+----------------------------+
| 4 | Read Input Registers |
+---------------+----------------------------+
| 5 | Write Single Coil |
+---------------+----------------------------+
| 6 | Write Single Register |
+---------------+----------------------------+
| 15 | Write Multiple Coils |
+---------------+----------------------------+
| 16 | Write Multiple Registers |
+---------------+----------------------------+
Modbus RTU requires a :ref:`UART Bus <uart>` to communicate.
.. code-block:: yaml
@ -45,10 +68,11 @@ See Also
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- `Modbus RTU Protocol Description <https://www.modbustools.com/modbus.html>`__
- :ref:`uart`
- :apiref:`modbus/modbus.h`

412
components/modbus_controller.rst
View File

@ -2,11 +2,11 @@ Modbus Controller
=================
.. seo::
:description: Instructions for setting up the ModBUS Controller component.
:description: Instructions for setting up the Modbus Controller component.
:image: modbus.png
The ``modbus_controller`` component creates a RS485 connection to control a ModBUS slave device, letting your ESPHome node to act as a ModBUS master.
You can access the coils and registers from your slave ModBUS device as sensors, switches or various other ESPHome components and present them to your favorite Home Automation system.
The ``modbus_controller`` component creates a RS485 connection to control a Modbus server (slave) device, letting your ESPHome node to act as a Modbus client (master).
You can access the coils, inputs, holding, read registers from your devices as sensors, switches, selects, numbers or various other ESPHome components and present them to your favorite Home Automation system. You can even write them as binary or float ouptputs from ESPHome.
.. figure:: /images/modbus.png
:align: center
@ -26,7 +26,7 @@ See `How is this RS485 module working? <https://electronics.stackexchange.com/qu
The transceiver connects to the UART of the MCU. For ESP32, pin ``16`` to ``TXD`` and pin ``17`` to ``RXD`` are the default ones but any other pins can be used as well. ``3.3V`` to ``VCC`` and naturally ``GND`` to ``GND``.
On the bus side, you need 120 Ohm termination resistors at the ends of the bus cable as per ModBUS standard. Some transceivers have this already solderes onboard, and some slave devices may have them preinstalled with a jumper or a dip switch.
On the bus side, you need 120 Ohm termination resistors at the ends of the bus cable as per Modbus standard. Some transceivers have this already soldered onboard, while some slave devices may have them available via a jumper or a DIP switch.
.. note::
@ -34,7 +34,7 @@ On the bus side, you need 120 Ohm termination resistors at the ends of the bus c
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.
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(s) instead, causing errors.
Serial logging can be disabled by setting ``baud_rate: 0``.
@ -46,17 +46,15 @@ On the bus side, you need 120 Ohm termination resistors at the ends of the bus c
level: <level>
baud_rate: 0
Configuration variables:
------------------------
- **modbus_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the ``modbus`` hub.
- **address** (**Required**, :ref:`config-id`): The ModBUS address of the slave device
- **address** (**Required**, :ref:`config-id`): The Modbus address of the slave device
- **command_throttle** (*Optional*, :ref:`config-time`): minimum time in between 2 requests to the device. Default is ``0ms``.
Some ModBUS slave devices limit the rate of requests from the master, the interval between sending requests can be altered.
Some Modbus slave devices limit the rate of requests from the master, so this allows the interval between requests to be altered.
- **update_interval** (*Optional*, :ref:`config-time`): The interval that the sensors should be checked.
Defaults to 60 seconds.
@ -66,7 +64,6 @@ Configuration variables:
slaves, this avoids waiting for timeouts allowing to read other slaves in the same bus. When the slave
responds to a command, it'll be marked online again.
Example
-------
The following code creates a ``modbus_controller`` hub talking to a ModBUS device at address ``1`` with ``115200`` bps
@ -76,54 +73,56 @@ Technically there is no difference between the "inline" and the standard definit
.. code-block:: yaml
# Example configuration entry
uart:
id: mod_bus
tx_pin: 17
rx_pin: 16
baud_rate: 115200
stop_bits: 1
...
modbus:
flow_control_pin: 5
id: modbus1
modbus_controller:
- id: epever
address: 0x1 ## address of the ModBUS slave device on the bus
modbus_id: modbus1
setup_priority: -10
text_sensor:
- name: "rtc_clock"
platform: modbus_controller
modbus_controller_id: epever
id: rtc_clock
internal: true
register_type: holding
address: 0x9013 ## address of the register inside the ModBUS slave device
register_count: 3
raw_encode: HEXBYTES
response_size: 6
switch:
- platform: modbus_controller
modbus_controller_id: epever
id: reset_to_fabric_default
name: "Reset to Factory Default"
register_type: coil
address: 0x15
bitmask: 1
- id: modbus_device
address: 0x1 ## address of the Modbus slave device on the bus
modbus_id: modbus1
setup_priority: -10
sensor:
- platform: modbus_controller
modbus_controller_id: epever
name: "Battery Capacity"
id: battery_capacity
register_type: holding
address: 0x9001
unit_of_measurement: "AH"
value_type: U_WORD
- platform: modbus_controller
modbus_controller_id: modbus_device
name: "Battery Capacity"
register_type: holding
address: 0x9001 ## address of the register inside the Modbus slave device
unit_of_measurement: "AH"
value_type: U_WORD
switch:
- platform: modbus_controller
modbus_controller_id: modbus_device
name: "Reset to Factory Default"
register_type: coil
address: 0x15
bitmask: 1
text_sensor:
- name: "rtc_clock"
platform: modbus_controller
modbus_controller_id: modbus_device
id: rtc_clock
internal: true
register_type: holding
address: 0x9013
register_count: 3
raw_encode: HEXBYTES
response_size: 6
The configuration example above creates a ``modbus_controller`` hub talking to a Modbus device at address ``1`` with a baudrate of ``115200`` bps, implementing a sensor, a switch and a text sensor.
Check out the various Modbus components available at the bottom of the document in the :ref:`modbusseealso` section. They can be directly defined *(inline)* under the ``modbus_controller`` hub or as standalone components. Technically there is no difference between the *inline* and the standard definitions approach.
Below you find a few general tips about using Modbus in more advanced scenarios. Applicable component functionalities have links pointing here:
.. _bitmasks:
Bitmasks
--------
@ -166,7 +165,7 @@ Some devices use decimal values in read registers to show multiple binary states
| bit 15 | Binary Sensor 15 | 32768 | 8000 |
+------------+------------------+-----------+-----------+
For example, when reading register ``15``, a decimal value of ``12288`` is the sum of ``4096`` + ``8192``, meaning the corresponding bits ``12`` and ``13`` are ``1``, the other bits are ``0``.
In the example below, register ``15``, holds several binary values. It stores the decimal value ``12288``, which is the sum of ``4096`` + ``8192``, meaning the corresponding bits ``12`` and ``13`` are ``1``, the other bits are ``0``.
To gather some of these bits as binary sensors in ESPHome, use ``bitmask``:
@ -174,39 +173,166 @@ To gather some of these bits as binary sensors in ESPHome, use ``bitmask``:
binary_sensor:
- platform: modbus_controller
modbus_controller_id: ventilation_system
modbus_controller_id: modbus1
name: Alarm bit0
entity_category: diagnostic
device_class: problem
register_type: read
address: 15
bitmask: 0x1
- platform: modbus_controller
modbus_controller_id: ventilation_system
modbus_controller_id: modbus1
name: Alarm bit1
entity_category: diagnostic
device_class: problem
register_type: read
address: 15
bitmask: 0x2
- platform: modbus_controller
modbus_controller_id: ventilation_system
modbus_controller_id: modbus1
name: Alarm bit10
entity_category: diagnostic
device_class: problem
register_type: read
address: 15
bitmask: 0x400
- platform: modbus_controller
modbus_controller_id: ventilation_system
modbus_controller_id: modbus1
name: Alarm bit15
entity_category: diagnostic
device_class: problem
register_type: read
address: 15
bitmask: 0x8000
.. _modbus_custom_command:
Using ``custom_command``
------------------------
``custom_command`` can be used to create an arbitrary modbus command. Combined with a lambda any response can be handled.
This example re-implements the command to read the registers 0x156 (Total active energy) and 0x158 Total (reactive energy) from a SDM-120.
SDM-120 returns the values as floats using 32 bits in 2 registers.
.. code-block:: yaml
uart:
id: mod_uart
...
modbus:
send_wait_time: 200ms
uart_id: mod_uart
id: mod_bus
modbus_controller:
- id: sdm
address: 2
modbus_id: mod_bus
command_throttle: 100ms
setup_priority: -10
update_interval: 30s
sensors:
- platform: modbus_controller
modbus_controller_id: sdm
name: "Total active energy"
id: total_energy
# address: 0x156
# register_type: "read"
## reimplement using custom_command
# 0x2 : modbus device address
# 0x4 : modbus function code
# 0x1 : high byte of modbus register address
# 0x56: low byte of modbus register address
# 0x00: high byte of total number of registers requested
# 0x02: low byte of total number of registers requested
custom_command: [ 0x2, 0x4, 0x1, 0x56,0x00, 0x02]
value_type: FP32
unit_of_measurement: kWh
accuracy_decimals: 1
- platform: modbus_controller
modbus_controller_id: sdm
name: "Total reactive energy"
# address: 0x158
# register_type: "read"
custom_command: [0x2, 0x4, 0x1, 0x58, 0x00, 0x02]
## the command returns an float value using 4 bytes
lambda: |-
ESP_LOGD("Modbus Sensor Lambda","Got new data" );
union {
float float_value;
uint32_t raw;
} raw_to_float;
if (data.size() < 4 ) {
ESP_LOGE("Modbus Sensor Lambda", "invalid data size %d",data.size());
return NAN;
}
raw_to_float.raw = data[0] << 24 | data[1] << 16 | data[2] << 8 | data[3];
ESP_LOGD("Modbus Sensor Lambda", "FP32 = 0x%08X => %f", raw_to_float.raw, raw_to_float.float_value);
return raw_to_float.float_value;
unit_of_measurement: kVArh
accuracy_decimals: 1
.. _modbus_register_count:
Optimizing modbus communications
--------------------------------
``register_count`` is an option only required for uncommon response encodings or to optimizie modbus communications.
It describes the number of registers this data point spans, overriding 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 one register is 16 bits (one 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 one register for a FP32 value (instead of the default of two), set ``register_count: 1`` and ``response_size: 4``.
``register_count`` can also be used to skip a number of registers in consecutive range.
An example is an SDM meter, with interesting data in register addresses 0, 2, 4 and 6:
.. code-block:: yaml
- platform: modbus_controller
name: "Voltage Phase 1"
address: 0
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Voltage Phase 2"
address: 2
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Voltage Phase 3"
address: 4
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Current Phase 1"
address: 6
register_type: "read"
value_type: FP32
accuracy_decimals: 1
The configuration above will generate *one* modbus command *read multiple registers from 0 to 6*.
Maybe you don’t care about the data in register addresses 2 and 4, which are voltage values for Phase 2 and Phase 3 (or you have a SDM-120).
Of course, you can delete the sensors your don’t care about, but then you'd have a gap in the addresses. If you remove the registers at address 2 and 4, *two* commands will be generated -- *read register 0* and *read register 6*. To avoid generating multiple commands and thus reduce activity on the bus, ``register_count`` can be used to fill the gaps:
.. code-block:: yaml
- platform: modbus_controller
name: "Voltage Phase 1"
address: 0
unit_of_measurement: "V"
register_type: "read"
value_type: FP32
register_count: 6
- platform: modbus_controller
name: "Current Phase 1"
address: 6
register_type: "read"
value_type: FP32
Because the option ``register_count: 6`` is used for the first sensor, *one* command *read multiple registers from 0 to 6* will be used but the values in between will be ignored.
.. note:: *Calculation:* FP32 is a 32 bit value and uses 2 registers. Therefore, to skip the 2 FP32 registers the size of these 2 registers must be added to the default size for the first register. So we have 2 for address 0, 2 for address 2 and 2 for address 4 thus ``register_count`` must be 6.
Protocol decoding example
-------------------------
@ -214,87 +340,87 @@ Protocol decoding example
.. code-block:: yaml
sensors:
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_voltage
name: "array_rated_voltage"
address: 0x3000
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
skip_updates: 60
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_voltage
name: "array_rated_voltage"
address: 0x3000
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
skip_updates: 60
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_current
name: "array_rated_current"
address: 0x3001
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 2
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_current
name: "array_rated_current"
address: 0x3001
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 2
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_power
name: "array_rated_power"
address: 0x3002
unit_of_measurement: "W"
register_type: read
value_type: U_DWORD_R
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_power
name: "array_rated_power"
address: 0x3002
unit_of_measurement: "W"
register_type: read
value_type: U_DWORD_R
accuracy_decimals: 1
filters:
- multiply: 0.01
-platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_voltage
name: "battery_rated_voltage"
address: 0x3004
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_voltage
name: "battery_rated_voltage"
address: 0x3004
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_current
name: "battery_rated_current"
address: 0x3005
unit_of_measurement: "A"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_current
name: "battery_rated_current"
address: 0x3005
unit_of_measurement: "A"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_power
name: "battery_rated_power"
address: 0x3006
unit_of_measurement: "W"
register_type: read
value_type: U_DWORD_R
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_power
name: "battery_rated_power"
address: 0x3006
unit_of_measurement: "W"
register_type: read
value_type: U_DWORD_R
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever id: charging_mode
name: "charging_mode"
address: 0x3008
unit_of_measurement: ""
register_type: read
value_type: U_WORD
accuracy_decimals: 0
- platform: modbus_controller
modbus_controller_id: epever id: charging_mode
name: "charging_mode"
address: 0x3008
unit_of_measurement: ""
register_type: read
value_type: U_WORD
accuracy_decimals: 0
To minimize the required transactions all registers with the same base address are read in one request.
@ -379,8 +505,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
.. note::
Write support is only implemented for switches and selects.
However the C++ code provides the required API to write to a ModBUS device.
Write support is only implemented for switches and selects; however, the C++ code provides the required API to write to a Modbus device.
These methods can be called from a lambda.
@ -413,7 +538,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
// create the payload
std::vector<uint16_t> rtc_data = {uint16_t((minutes << 8) | seconds), uint16_t((day << 8) | hour),
uint16_t((year << 8) | month)};
// Create a ModBUS command item with the time information as the payload
// Create a Modbus command item with the time information as the payload
esphome::modbus_controller::ModbusCommandItem set_rtc_command =
esphome::modbus_controller::ModbusCommandItem::create_write_multiple_command(controller, 0x9013, 3, rtc_data);
// Submit the command to the send queue
@ -517,17 +642,20 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
filters:
- multiply: 0.01
.. _modbusseealso:
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/output/modbus_controller`
- `ModBUS RTU Protocol Description <https://www.modbustools.com/modbus.html>`__
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- `Modbus RTU Protocol Description <https://www.modbustools.com/modbus.html>`__
- `EPEVER MPPT Solar Charge Controller (Tracer-AN Series) <https://devices.esphome.io/devices/epever_mptt_tracer_an>`__
- `Genvex, Nibe, Alpha-Innotec heat recovery ventilation <https://devices.esphome.io/devices/Genvex-Nibe-AlphaInnotec-heat-recovery-ventilation>`__
- :ghedit:`Edit`

4
components/mqtt.rst
View File

@ -81,6 +81,8 @@ Configuration variables:
for verifying SSL connections. See :ref:`mqtt-ssl_fingerprints`.
for more information.
- **certificate_authority** (*Optional*, string): Only with ``esp-idf``. CA certificate in PEM format. See :ref:`mqtt-tls-idf` for more information
- **client_certificate** (*Optional*, string): Only on ``esp32``. Client certificate in PEM format.
- **client_certificate_key** (*Optional*, string): Only on ``esp32``. Client private key in PEM format.
- **skip_cert_cn_check** (*Optional*, bool): Only with ``esp-idf``. Don't verify if the common name in the server certificate matches the value of ``broker``.
- **idf_send_async** (*Optional*, bool): Only with ``esp-idf``. If true publishing the message happens from the internal mqtt task. The client only enqueues the message. Defaults to ``false``.
The advantage of asyncronous publishing is that it doesn't block the esphome main thread. The disadvantage is a delay (up to 1-2 seconds) until the messages are actually sent out.
@ -351,6 +353,7 @@ MQTT can have some overrides for specific options.
name: "Component Name"
# Optional variables:
qos: 1
retain: true
availability:
topic: livingroom/status
@ -364,6 +367,7 @@ Configuration variables:
- **name** (**Required**, string): The name to use for the MQTT
Component.
- **qos** (*Optional*, int): The [Quality of Service](https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/) level for publishing. Defaults to 0.
- **retain** (*Optional*, boolean): If all MQTT state messages should
be retained. Defaults to ``true``.
- **discovery** (*Optional*, boolean): Manually enable/disable

8
components/network.rst
View File

@ -14,11 +14,19 @@ networks (WiFi, Ethernet).
# Example configuration
network:
enable_ipv6: true
min_ipv6_addr_count: 2
Configuration variables:
------------------------
- **enable_ipv6** (*Optional*, boolean): Enables IPv6 support. Defaults to ``false``.
- **min_ipv6_addr_count** (*Optional*, integer): ESPHome considers the network to be connected when it has one IPv4 address and this number of IPv6 addresses. Defaults to ``0`` so as to not hang on boot with networks where IPv6 is not enabled. ``2`` is typically a reasonable value for configurations requiring IPv6.
.. note::
The `lwIP <https://savannah.nongnu.org/projects/lwip/>`_ library used for the network component currently only implements IPv6 SLAAC according to `RFC4862 <https://datatracker.ietf.org/doc/rfc4862/>`_. The interface identifier (IID) is directly generated from the device MAC address.
This has various security and privacy implications decribed in `RFC7721 <https://datatracker.ietf.org/doc/rfc7721/>`_, as this might leak outside of the smart home network and makes the device uniquely identifiable.
Therefore, the address generation does not comply to `RFC7217 <https://datatracker.ietf.org/doc/rfc7217/>`_.
See Also
--------

2
components/number/index.rst
View File

@ -55,7 +55,7 @@ Configuration variables:
for a list of available options. Requires Home Assistant Core 2021.12 or newer.
Defaults to ``"auto"``.
- **device_class** (*Optional*, string): The device class for the number.
See https://developers.home-assistant.io/docs/core/entity/number/#available-device-classes
See https://www.home-assistant.io/integrations/number/#device-class
for a list of available options.
Automations:

47
components/number/modbus_controller.rst
View File

@ -12,8 +12,8 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **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)
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **value_type** (**Required**): datatype of the modbus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first):
- ``U_WORD`` (unsigned 16 bit integer from 1 register = 16bit)
- ``S_WORD`` (signed 16 bit integer from 1 register = 16bit)
@ -28,14 +28,16 @@ Configuration variables:
- ``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 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 components with the same address will be updated in one request. skip_updates applies for all components in the same range.
- **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
- **step** (*Optional*, float): The granularity with which the number can be set. Defaults to 1.
- **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 *Function Code 6 (Preset Single Registers)* is used for setting the holding register if only one register is set. If your device only supports *Function Code 16 (Preset Multiple Registers)* set this option to ``true``.
- **skip_updates** (*Optional*, int): By default, all sensors 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 components by address ranges to reduce number of transactions. All components with the same starting address will be updated in one request. ``skip_updates`` applies for *all* components in the same range.
- **register_count** (*Optional*, int): The number of consecutive registers this read request should span or skip in a single command. Default is 1. See :ref:`modbus_register_count` for more details.
- **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): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a 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.
- **custom_command** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_command`` 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_command` how to use ``custom_command``
@ -71,19 +73,24 @@ Configuration variables:
- ``return <anything>; and fill payload with data`` if the payload is added from the lambda then these 16 bit words will be sent
- ``return {};`` if you don't want write the command to the device (or do it from the lambda).
- **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>`.
All other options from :ref:`Number <config-number>`.
**Example**
Example:
--------
.. code-block:: yaml
number:
- platform: modbus_controller
modbus_controller_id: epever
modbus_controller_id: modbus1
id: battery_capacity_number
name: "Battery Cap Number"
address: 0x9001
value_type: U_WORD
multiply: 1.0
- platform: modbus_controller
modbus_controller_id: modbus1
id: battery_capacity_number
name: "Battery Cap Number"
address: 0x9001
@ -94,17 +101,17 @@ All other options from :ref:`Number <config-number>`.
uint16_t b_capacity = x ;
payload.push_back(b_capacity);
return x * 1.0 ;
## multiply is ignored because lamdba is used
multiply: 1.0
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- https://www.modbustools.com/modbus.html
- :ghedit:`Edit`

5
components/ota.rst
View File

@ -54,6 +54,9 @@ Configuration variables:
performed after a failed OTA update. See :ref:`ota-on_error`.
- **on_state_change** (*Optional*, :ref:`Automation<automation>`): An action to be
performed when an OTA update state change happens. See :ref:`ota-on_state_change`.
- **version** (*Optional*, int): Version of OTA protocol to use. Version 2 is more stable.
To downgrade to legacy ESPHome, the device should be updated with OTA version 1 first.
Defaults to ``2``.
.. note::
@ -174,7 +177,7 @@ enum. These values are:
then:
- if:
condition:
lambda: return state == ota::OTA_STARTED
lambda: return state == ota::OTA_STARTED;
then:
- logger.log: "OTA start"

3
components/output/mcp4728.rst
View File

@ -11,9 +11,6 @@ The MCP4728 output component allows to use `12bit external quad DAC
<https://www.adafruit.com/product/4470>`__
in order to have analog outputs on any board by using :ref:`I²C <i2c>`. Devices default address is ``0x60``.
If you only have one, it is not necessary to explicitly specify the ``mcp4728:`` component in the config unless you need to change the parameters.
It will be automatically created with the default settings if you use it.
.. code-block:: yaml
# Example configuration entry

63
components/output/modbus_controller.rst
View File

@ -2,17 +2,15 @@ Modbus Controller Output
========================
.. seo::
:description: Instructions for setting up a modbus_controller device sensor.
:description: Instructions for setting up a modbus_controller device output.
The ``modbus_controller`` platform creates a output from a modbus_controller.
The ``modbus_controller`` platform creates an output from a modbus_controller. The goal is to write a value to a modbus register on a device.
Configuration variables:
------------------------
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **name** (**Required**, string): The name of the sensor.
- **address** (**Required**, int): start address of the first register in a range
- **value_type** (**Required**): data type of the modbus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first)
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **value_type** (**Required**): data type of the modbus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first).
- ``U_WORD`` (unsigned 16 bit integer from 1 register = 16bit)
- ``S_WORD`` (signed 16 bit integer from 1 register = 16bit)
@ -27,14 +25,19 @@ Configuration variables:
- ``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_type** (*Optional*):
- ``coil``: Write Coil - Write the ON/OFF status of a discrete coil in the device with *Function Code 5 or 15*. This will create a binary output.
- ``holding``: Write Holding Registers - write contents of holding registers in the device with *Function Code 6 or 16*. This will create a float output.
- **multiply** (*Optional*, float): multiply the incoming value with this factor before writing it to the device. Ignored if ``write_lambda`` is defined. Only valid for ``register_type: holding``.
- **use_write_multiple** (*Optional*, boolean): By default the modbus command *Function Code 6 (Preset Single Registers)* is used for setting the holding register if only one register is set. If your device only supports *Function Code 16 (Preset Multiple Registers)* set this option to ``true``.
- **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``.
You can directly define the payload by adding data to payload then the return value is ignored and the content of payload is used.
Parameters passed into the lambda
- **x** (float): The float value to be sent to the modbus device for ``register_type: holding``
- **x** (bool): The boolean value to be sent to the modbus device for ``register_type: coil``
- **x** (float or bool): The float value to be sent to the modbus device for ``register_type: holding`` or the boolean value to be sent to the modbus device for ``register_type: coil``
- **payload** (```std::vector<uint16_t>&payload```):
- for ``register_type: holding``: empty vector for the payload. The lamdba can add 16 bit raw modbus register words.
@ -49,41 +52,51 @@ Configuration variables:
- ``return <anything>; and fill payload with data`` if the payload is added from the lambda then these 16 bit words will be sent
- ``return {};`` if you don't want write the command to the device (or do it from the lambda).
- **register_type** (*Optional*): ``coil`` to create a binary outout or ``holding`` to create a float output.
- **multiply** (*Optional*, float): multiply the new value with this factor before sending the requests. Ignored if lambda is defined. Only valid for ``register_type: holding``.
- **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.
- **offset** (*Optional*, int): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a 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.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
All other options from :ref:`Output <config-output>`.
**Example**
Example:
--------
.. code-block:: yaml
output:
- platform: modbus_controller
modbus_controller_id: epever
id: battery_capacity_output
write_lambda: |-
ESP_LOGD("main","Modbus Output incoming value = %f",x);
uint16_t b_capacity = x ;
payload.push_back(b_capacity);
return x * 1.0 ;
address: 0x9001
value_type: U_WORD
- platform: modbus_controller
modbus_controller_id: modbus1
address: 2048
register_type: holding
value_type: U_WORD
multiply: 1000
**The same with lambda:**
.. code-block:: yaml
output:
- platform: modbus_controller
modbus_controller_id: modbus1
address: 2048
value_type: U_WORD
write_lambda: |-
ESP_LOGD("main","Modbus Output incoming value = %f",x);
uint16_t value = x ;
payload.push_back(value);
return x * 1000 ;
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- https://www.modbustools.com/modbus.html
- :ghedit:`Edit`

4
components/output/my9231.rst
View File

@ -97,9 +97,7 @@ Sonoff B1 configuration example
This component can be used with a Sonoff B1 smart light bulb. To flash
the Sonoff B1, open the plastic cover and connect/solder wires to the
PCB pads (3.3V, RX, TX, GND, GPIO0). If you connect GPIO0 to GND
during power up, the device enters flash mode. For more information
about flashing Sonoff devices, see:
:doc:`/devices/sonoff_s20`. All LEDs are connected to a
during power up, the device enters flash mode. All LEDs are connected to a
chain of two MY9321 chips that are connected to GPIO12 and GPIO14. A
complete configuration for a Sonoff B1 looks like:

2
components/pca9554.rst
View File

@ -59,7 +59,7 @@ binary sensor or GPIO switch.
- platform: gpio
name: "PCF9554A Pin #0"
pin:
pca9554: pcf9554a_device
pca9554: pca9554a_device
# Use pin number 0
number: 0
# One of INPUT or OUTPUT

381
components/pn7150.rst Normal file
View File

@ -0,0 +1,381 @@
PN7150 NFC
==========
.. seo::
:description: Instructions for setting up PN7150 NFC tag readers and tags in ESPHome
:image: pn7150.jpg
:keywords: PN7150, NFC, RFID
.. _pn7150-component:
Component/Hub
-------------
The ``pn7150`` component allows you to use PN7150 NFC controllers with ESPHome. This component is a global hub that
establishes a connection to the PN7150 via :ref:`I²C <i2c>`.
.. figure:: images/pn7150-full.jpg
:align: center
:width: 70.0%
An :ref:`I²C <i2c>` bus must be defined within your device's ESPHome configuration to use the PN7150.
ESPHome supports both card/tag reading/writing as well as card/tag emulation with this component. By default,
only read/write mode is enabled; card/tag emulation is enabled only if the ``emulation_message`` configuration
variable is defined (see below). Regardless, reader/writer (polling) mode and card/tag emulation mode may be
independently enabled and disabled by using the corresponding :ref:`pn7150-actions` (see below).
In addition, the :doc:`binary_sensor/nfc` platform may be used to quickly and easily identify tags presented to the reader.
.. code-block:: yaml
pn7150_i2c:
dwl_req_pin: 17
irq_pin: 35
ven_pin: 16
wkup_req_pin: 21
emulation_message: https://www.home-assistant.io/tag/pulse_ce
tag_ttl: 1000ms
Configuration variables:
************************
- **dwl_req_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7150's
``DWL_REQ`` line. Used to invoke the PN7150's firmware update mode; may be used in a future release.
- **irq_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7150's ``IRQ`` line.
- **ven_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7150's ``VEN`` line.
- **wkup_req_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7150's
``WKUP_REQ`` line. May be used to improve power management in a future release.
- **emulation_message** (*Optional*, string): When scanned by another NFC card/tag reader (such as a smartphone), this
string is used as the content for an NDEF-formatted response. This allows the PN7150 to act as a tag in addition to a
tag reader/writer.
- **tag_ttl** (*Optional*, :ref:`config-time`): The duration that must elapse after the PN7150 is no longer able to
"see" a tag before it is considered to have been removed from the reader.
- **on_tag** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a tag is first read. See
:ref:`pn7150-on_tag`.
- **on_tag_removed** (*Optional*, :ref:`Automation <automation>`): An automation to perform after a tag is removed. See
:ref:`pn7150-on_tag_removed`.
- **on_emulated_tag_scan** (*Optional*, :ref:`Automation <automation>`): An automation to perform when the PN7150 is
scanned by another tag reader (such as a smartphone). See :ref:`pn7150-on_emulated_tag_scan`.
- **i2c_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`I²C Component <i2c>` if you need
to use multiple I²C buses.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this component.
.. _pn7150-actions:
Actions
-------
.. _pn7150-set_clean_mode:
``tag.set_clean_mode`` Action
*****************************
Use this action to invoke "clean mode" -- the next tag presented to the PN7150 will be "cleaned", removing all data
from the tag.
.. code-block:: yaml
on_...:
then:
- tag.set_clean_mode: my_pn7150_id
.. _pn7150-set_format_mode:
``tag.set_format_mode`` Action
******************************
Use this action to invoke "format mode" -- the next tag presented to the PN7150 will be "formatted", leaving only an
empty NDEF message structure on the tag.
.. code-block:: yaml
on_...:
then:
- tag.set_format_mode: my_pn7150_id
.. _pn7150-set_read_mode:
``tag.set_read_mode`` Action
****************************
Use this action to invoke "read mode" -- the next tag presented to the PN7150 will be read. This is the default mode
that the component operates in.
.. code-block:: yaml
on_...:
then:
- tag.set_read_mode: my_pn7150_id
.. _pn7150-set_write_message:
``tag.set_write_message`` Action
********************************
Use this action to set the NDEF message used for "write mode" (see below).
.. code-block:: yaml
on_...:
then:
- tag.set_write_message:
message: https://www.home-assistant.io/tag/pulse
include_android_app_record: false
- **message** (**Required**, string, templatable): The string to include in the tag's first NDEF record; typically
a URL as shown.
- **include_android_app_record** (*Optional*, boolean): Include a second NDEF record required for some Android
operating systems. Defaults to ``true``.
.. _pn7150-set_write_mode:
``tag.set_write_mode`` Action
*****************************
Use this action to invoke "write mode" -- the next tag presented to the PN7150 will have its NDEF message set to the
message defined by the ``tag.set_write_message`` action (see above). **Note that a message must be set before this mode
may be invoked.**
.. code-block:: yaml
on_...:
then:
- tag.set_write_mode: my_pn7150_id
.. _pn7150-set_emulation_message:
``tag.set_emulation_message`` Action
************************************
Use this action to set the NDEF message used for card (tag) emulation mode, when enabled (see below).
.. code-block:: yaml
on_...:
then:
- tag.set_emulation_message:
message: https://www.home-assistant.io/tag/pulse
include_android_app_record: false
- **message** (**Required**, string, templatable): The string to include in the (emulated) tag's first NDEF record;
typically a URL as shown.
- **include_android_app_record** (*Optional*, boolean): Include a second NDEF record required for some Android
operating systems. Defaults to ``true``.
.. _pn7150-emulation_off:
``tag.emulation_off`` Action
****************************
Use this action to disable card (tag) emulation mode. The PN7150 will no longer respond to requests from other readers,
such as smartphones.
.. code-block:: yaml
on_...:
then:
- tag.emulation_off: my_pn7150_id
.. _pn7150-emulation_on:
``tag.emulation_on`` Action
***************************
Use this action to enable card (tag) emulation mode. The PN7150 will respond to requests from other readers, such as
smartphones.
**Note:** when card/tag emulation is enabled, polling (detecting a nearby card/tag) frequency is decreased; this
typically results in slightly slower detection of cards/tags presented to the PN7150. This behavior is normal and should
be expected; it is the result of the PN7150 toggling between polling and listening modes to support both functions.
.. code-block:: yaml
on_...:
then:
- tag.emulation_on: my_pn7150_id
.. _pn7150-polling_off:
``tag.polling_off`` Action
****************************
Use this action to disable card (tag) reading/writing. The PN7150 will no longer read or write cards/tags.
.. code-block:: yaml
on_...:
then:
- tag.polling_off: my_pn7150_id
.. _pn7150-polling_on:
``tag.polling_on`` Action
***************************
Use this action to enable card (tag) reading/writing. The PN7150 will read or write cards/tags.
.. code-block:: yaml
on_...:
then:
- tag.polling_on: my_pn7150_id
Triggers
--------
.. _pn7150-on_tag:
``on_tag`` Trigger
******************
This automation will be triggered immediately after the PN7150 module identifies a tag and reads its NDEF
message (if one is present).
The parameter ``x`` this trigger provides is of type ``std::string`` and is the tag UID in the format
``74-10-37-94``. The example configuration below will publish the tag ID on the MQTT topic ``pn7150/tag``.
See :ref:`pn7150-ndef_reading` below for how to use the second ``tag`` parameter that is provided to this trigger.
.. code-block:: yaml
pn7150_i2c:
# ...
on_tag:
then:
- mqtt.publish:
topic: pn7150/tag
payload: !lambda 'return x;'
A tag scanned event can also be sent to the Home Assistant tag component
using :ref:`api-homeassistant_tag_scanned_action`.
.. code-block:: yaml
pn7150_i2c:
# ...
on_tag:
then:
- homeassistant.tag_scanned: !lambda 'return x;'
You could also send the value to Home Assistant via a :doc:`template sensor </components/sensor/template>`:
.. code-block:: yaml
pn7150_i2c:
# ...
on_tag:
then:
- text_sensor.template.publish:
id: nfc_tag
state: !lambda 'return x;'
text_sensor:
- platform: template
name: "NFC Tag"
id: nfc_tag
.. _pn7150-on_tag_removed:
``on_tag_removed`` Trigger
**************************
This automation will be triggered after the ``tag_ttl`` interval (see above) when the PN7150 no longer "sees" a
previously scanned tag.
The parameter ``x`` this trigger provides is of type ``std::string`` and is the removed tag UID in the format
``74-10-37-94``. The example configuration below will publish the removed tag ID on the MQTT topic ``pn7150/tag_removed``.
.. code-block:: yaml
pn7150_i2c:
# ...
on_tag_removed:
then:
- mqtt.publish:
topic: pn7150/tag_removed
payload: !lambda 'return x;'
.. _pn7150-on_emulated_tag_scan:
``on_emulated_tag_scan`` Trigger
********************************
If card/tag emulation is enabled, this automation will be triggered when another reader (such as a smartphone) scans
the PN7150 and reads the NDEF message it responds with. No parameters are available to this action because data is only
sent *from* the PN7150 *to* the scanning device.
.. code-block:: yaml
pn7150_i2c:
# ...
on_emulated_tag_scan:
then:
- rtttl.play: "alert:d=32,o=5,b=160:e6,p,e6,p,e6"
.. _pn7150-ndef:
NDEF
====
The PN7150 supports reading NDEF messages from and writing NDEF messages to cards/tags.
.. _pn7150-ndef_reading:
NDEF Reading
------------
Given an NFC tag formatted and written using the Home Assistant Companion App, the following example will send the tag
ID contained within its NDEF message to Home Assistant using the :ref:`api-homeassistant_tag_scanned_action`.
If no NDEF record is found with a tag ID, the tag's UID will be sent to Home Assistant, instead.
The ``tag`` variable is available to any actions that run within the ``on_tag`` and ``on_tag_removed`` triggers.
.. code-block:: yaml
pn7150_i2c:
# ...
on_tag:
then:
- homeassistant.tag_scanned: !lambda "return tag.has_ha_tag_id() ? tag.get_ha_tag_id() : x;"
.. _pn7150-ndef_writing:
NDEF Writing
------------
The examples below illustrate how NDEF messages may be written to cards/tags via the PN7150. Note that a
:doc:`button </components/button/index>` is a great mechanism to use to trigger these actions.
The first example will write a simple, fixed NDEF message to a tag.
.. code-block:: yaml
on_...
then:
- tag.set_write_message:
message: https://www.home-assistant.io/tag/pulse
include_android_app_record: false # optional
- tag.set_write_mode: my_pn7150_id
The next example can be used to write a (pseudo) random UUID to a tag in the same manner as the Home Assistant
Companion App.
.. code-block:: yaml
on_...
then:
- tag.set_write_message:
message: !lambda "return nfc::get_random_ha_tag_ndef();"
- tag.set_write_mode: my_pn7150_id
See Also
--------
- :doc:`index`
- :doc:`binary_sensor/pn532`
- :doc:`binary_sensor/rc522`
- :doc:`binary_sensor/rdm6300`
- :apiref:`pn7150/pn7150.h`
- :ghedit:`Edit`

439
components/pn7160.rst Normal file
View File

@ -0,0 +1,439 @@
PN7160 NFC
==========
.. seo::
:description: Instructions for setting up PN7160 NFC tag readers and tags in ESPHome
:image: pn716x.jpg
:keywords: PN7160, NFC, RFID
.. _pn7160-component:
Component/Hub
-------------
The ``pn7160`` component allows you to use PN7160 NFC controllers with ESPHome. This component is a global hub that
establishes a connection to the PN7160 via :ref:`SPI <spi>` or :ref:`I²C <i2c>`.
.. figure:: images/pn716x-full.jpg
:align: center
:width: 70.0%
Within ESPHome, the PN7160 can be configured to use either the SPI **or** I²C protocol for data communication.
Note that there are different versions of the IC for each bus type, each with a different part number; in other
words, **the bus type cannot be changed by jumpers/switches as it is determed at the time of manufacture.**
You must determine which version of the IC you have and then configure the corresponding bus -- either the
:ref:`SPI bus <spi>` or the :ref:`I²C bus <i2c>`.
ESPHome supports both card/tag reading/writing as well as card/tag emulation with this component. By default,
only read/write mode is enabled; card/tag emulation is enabled only if the ``emulation_message`` configuration
variable is defined (see below). Regardless, reader/writer (polling) mode and card/tag emulation mode may be
independently enabled and disabled by using the corresponding :ref:`pn7160-actions` (see below).
In addition, the :doc:`binary_sensor/nfc` platform may be used to quickly and easily identify tags presented to the reader.
.. _pn7160-spi:
Over SPI
--------
The ``pn7160_spi`` component allows you to use :ref:`SPI-equipped <spi>` PN7160 NFC controllers with with ESPHome.
.. code-block:: yaml
pn7160_spi:
cs_pin: 15
dwl_req_pin: 17
irq_pin: 35
ven_pin: 16
wkup_req_pin: 21
emulation_message: https://www.home-assistant.io/tag/pulse_ce
tag_ttl: 1000ms
Configuration variables:
************************
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's ``NSS`` (chip
select) line.
- **dwl_req_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's
``DWL_REQ`` line. Used to invoke the PN7160's firmware update mode; may be used in a future release.
- **irq_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's ``IRQ`` line.
- **ven_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's ``VEN`` line.
- **wkup_req_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's
``WKUP_REQ`` line. May be used to improve power management in a future release.
- **emulation_message** (*Optional*, string): When scanned by another NFC card/tag reader (such as a smartphone), this
string is used as the content for an NDEF-formatted response. This allows the PN7160 to act as a tag in addition to a
tag reader/writer.
- **tag_ttl** (*Optional*, :ref:`config-time`): The duration that must elapse after the PN7160 is no longer able to
"see" a tag before it is considered to have been removed from the reader.
- **on_tag** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a tag is first read. See
:ref:`pn7160-on_tag`.
- **on_tag_removed** (*Optional*, :ref:`Automation <automation>`): An automation to perform after a tag is removed. See
:ref:`pn7160-on_tag_removed`.
- **on_emulated_tag_scan** (*Optional*, :ref:`Automation <automation>`): An automation to perform when the PN7160 is
scanned by another tag reader (such as a smartphone). See :ref:`pn7160-on_emulated_tag_scan`.
- **spi_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`SPI Component <spi>` if you want
to use multiple SPI buses.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this component.
.. _pn7160-i2c:
Over I²C
--------
The ``pn7160_i2c`` component allows you to use :ref:`I²C-equipped <i2c>` PN7160 NFC controllers with ESPHome.
.. code-block:: yaml
pn7160_i2c:
dwl_req_pin: 17
irq_pin: 35
ven_pin: 16
wkup_req_pin: 21
emulation_message: https://www.home-assistant.io/tag/pulse_ce
tag_ttl: 1000ms
Configuration variables:
************************
- **dwl_req_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's
``DWL_REQ`` line. Used to invoke the PN7160's firmware update mode; may be used in a future release.
- **irq_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's ``IRQ`` line.
- **ven_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's ``VEN`` line.
- **wkup_req_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The pin connected to the PN7160's
``WKUP_REQ`` line. May be used to improve power management in a future release.
- **emulation_message** (*Optional*, string): When scanned by another NFC card/tag reader (such as a smartphone), this
string is used as the content for an NDEF-formatted response. This allows the PN7160 to act as a tag in addition to a
tag reader/writer.
- **tag_ttl** (*Optional*, :ref:`config-time`): The duration that must elapse after the PN7160 is no longer able to
"see" a tag before it is considered to have been removed from the reader.
- **on_tag** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a tag is first read. See
:ref:`pn7160-on_tag`.
- **on_tag_removed** (*Optional*, :ref:`Automation <automation>`): An automation to perform after a tag is removed. See
:ref:`pn7160-on_tag_removed`.
- **on_emulated_tag_scan** (*Optional*, :ref:`Automation <automation>`): An automation to perform when the PN7160 is
scanned by another tag reader (such as a smartphone). See :ref:`pn7160-on_emulated_tag_scan`.
- **i2c_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`I²C Component <i2c>` if you need
to use multiple I²C buses.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this component.
.. _pn7160-actions:
Actions
-------
.. _pn7160-set_clean_mode:
``tag.set_clean_mode`` Action
*****************************
Use this action to invoke "clean mode" -- the next tag presented to the PN7160 will be "cleaned", removing all data
from the tag.
.. code-block:: yaml
on_...:
then:
- tag.set_clean_mode: my_pn7160_id
.. _pn7160-set_format_mode:
``tag.set_format_mode`` Action
******************************
Use this action to invoke "format mode" -- the next tag presented to the PN7160 will be "formatted", leaving only an
empty NDEF message structure on the tag.
.. code-block:: yaml
on_...:
then:
- tag.set_format_mode: my_pn7160_id
.. _pn7160-set_read_mode:
``tag.set_read_mode`` Action
****************************
Use this action to invoke "read mode" -- the next tag presented to the PN7160 will be read. This is the default mode
that the component operates in.
.. code-block:: yaml
on_...:
then:
- tag.set_read_mode: my_pn7160_id
.. _pn7160-set_write_message:
``tag.set_write_message`` Action
********************************
Use this action to set the NDEF message used for "write mode" (see below).
.. code-block:: yaml
on_...:
then:
- tag.set_write_message:
message: https://www.home-assistant.io/tag/pulse
include_android_app_record: false
- **message** (**Required**, string, templatable): The string to include in the tag's first NDEF record; typically
a URL as shown.
- **include_android_app_record** (*Optional*, boolean): Include a second NDEF record required for some Android
operating systems. Defaults to ``true``.
.. _pn7160-set_write_mode:
``tag.set_write_mode`` Action
*****************************
Use this action to invoke "write mode" -- the next tag presented to the PN7160 will have its NDEF message set to the
message defined by the ``tag.set_write_message`` action (see above). **Note that a message must be set before this mode
may be invoked.**
.. code-block:: yaml
on_...:
then:
- tag.set_write_mode: my_pn7160_id
.. _pn7160-set_emulation_message:
``tag.set_emulation_message`` Action
************************************
Use this action to set the NDEF message used for card (tag) emulation mode, when enabled (see below).
.. code-block:: yaml
on_...:
then:
- tag.set_emulation_message:
message: https://www.home-assistant.io/tag/pulse
include_android_app_record: false
- **message** (**Required**, string, templatable): The string to include in the (emulated) tag's first NDEF record;
typically a URL as shown.
- **include_android_app_record** (*Optional*, boolean): Include a second NDEF record required for some Android
operating systems. Defaults to ``true``.
.. _pn7160-emulation_off:
``tag.emulation_off`` Action
****************************
Use this action to disable card (tag) emulation mode. The PN7160 will no longer respond to requests from other readers,
such as smartphones.
.. code-block:: yaml
on_...:
then:
- tag.emulation_off: my_pn7160_id
.. _pn7160-emulation_on:
``tag.emulation_on`` Action
***************************
Use this action to enable card (tag) emulation mode. The PN7160 will respond to requests from other readers, such as
smartphones.
**Note:** when card/tag emulation is enabled, polling (detecting a nearby card/tag) frequency is decreased; this
typically results in slightly slower detection of cards/tags presented to the PN7160. This behavior is normal and should
be expected; it is the result of the PN7160 toggling between polling and listening modes to support both functions.
.. code-block:: yaml
on_...:
then:
- tag.emulation_on: my_pn7160_id
.. _pn7160-polling_off:
``tag.polling_off`` Action
****************************
Use this action to disable card (tag) reading/writing. The PN7160 will no longer read or write cards/tags.
.. code-block:: yaml
on_...:
then:
- tag.polling_off: my_pn7160_id
.. _pn7160-polling_on:
``tag.polling_on`` Action
***************************
Use this action to enable card (tag) reading/writing. The PN7160 will read or write cards/tags.
.. code-block:: yaml
on_...:
then:
- tag.polling_on: my_pn7160_id
Triggers
--------
.. _pn7160-on_tag:
``on_tag`` Trigger
******************
This automation will be triggered immediately after the PN7160 module identifies a tag and reads its NDEF
message (if one is present).
The parameter ``x`` this trigger provides is of type ``std::string`` and is the tag UID in the format
``74-10-37-94``. The example configuration below will publish the tag ID on the MQTT topic ``pn7160/tag``.
See :ref:`pn7160-ndef_reading` below for how to use the second ``tag`` parameter that is provided to this trigger.
.. code-block:: yaml
pn7160_...:
# ...
on_tag:
then:
- mqtt.publish:
topic: pn7160/tag
payload: !lambda 'return x;'
A tag scanned event can also be sent to the Home Assistant tag component
using :ref:`api-homeassistant_tag_scanned_action`.
.. code-block:: yaml
pn7160_...:
# ...
on_tag:
then:
- homeassistant.tag_scanned: !lambda 'return x;'
You could also send the value to Home Assistant via a :doc:`template sensor </components/sensor/template>`:
.. code-block:: yaml
pn7160_...:
# ...
on_tag:
then:
- text_sensor.template.publish:
id: nfc_tag
state: !lambda 'return x;'
text_sensor:
- platform: template
name: "NFC Tag"
id: nfc_tag
.. _pn7160-on_tag_removed:
``on_tag_removed`` Trigger
**************************
This automation will be triggered after the ``tag_ttl`` interval (see above) when the PN7160 no longer "sees" a
previously scanned tag.
The parameter ``x`` this trigger provides is of type ``std::string`` and is the removed tag UID in the format
``74-10-37-94``. The example configuration below will publish the removed tag ID on the MQTT topic ``pn7160/tag_removed``.
.. code-block:: yaml
pn7160_...:
# ...
on_tag_removed:
then:
- mqtt.publish:
topic: pn7160/tag_removed
payload: !lambda 'return x;'
.. _pn7160-on_emulated_tag_scan:
``on_emulated_tag_scan`` Trigger
********************************
If card/tag emulation is enabled, this automation will be triggered when another reader (such as a smartphone) scans
the PN7160 and reads the NDEF message it responds with. No parameters are available to this action because data is only
sent *from* the PN7160 *to* the scanning device.
.. code-block:: yaml
pn7160_...:
# ...
on_emulated_tag_scan:
then:
- rtttl.play: "alert:d=32,o=5,b=160:e6,p,e6,p,e6"
.. _pn7160-ndef:
NDEF
====
The PN7160 supports reading NDEF messages from and writing NDEF messages to cards/tags.
.. _pn7160-ndef_reading:
NDEF Reading
------------
Given an NFC tag formatted and written using the Home Assistant Companion App, the following example will send the tag
ID contained within its NDEF message to Home Assistant using the :ref:`api-homeassistant_tag_scanned_action`.
If no NDEF record is found with a tag ID, the tag's UID will be sent to Home Assistant, instead.
The ``tag`` variable is available to any actions that run within the ``on_tag`` and ``on_tag_removed`` triggers.
.. code-block:: yaml
pn7160_...:
# ...
on_tag:
then:
- homeassistant.tag_scanned: !lambda "return tag.has_ha_tag_id() ? tag.get_ha_tag_id() : x;"
.. _pn7160-ndef_writing:
NDEF Writing
------------
The examples below illustrate how NDEF messages may be written to cards/tags via the PN7160. Note that a
:doc:`button </components/button/index>` is a great mechanism to use to trigger these actions.
The first example will write a simple, fixed NDEF message to a tag.
.. code-block:: yaml
on_...
then:
- tag.set_write_message:
message: https://www.home-assistant.io/tag/pulse
include_android_app_record: false # optional
- tag.set_write_mode: my_pn7160_id
The next example can be used to write a (pseudo) random UUID to a tag in the same manner as the Home Assistant
Companion App.
.. code-block:: yaml
on_...
then:
- tag.set_write_message:
message: !lambda "return nfc::get_random_ha_tag_ndef();"
- tag.set_write_mode: my_pn7160_id
See Also
--------
- :doc:`index`
- :doc:`binary_sensor/pn532`
- :doc:`binary_sensor/rc522`
- :doc:`binary_sensor/rdm6300`
- :apiref:`pn7160/pn7160.h`
- :ghedit:`Edit`

6
components/power_supply.rst
View File

@ -33,10 +33,14 @@ Configuration variables:
- **enable_time** (*Optional*, :ref:`config-time`): The time
that the power supply needs for startup. The output component will
wait for this period of time after turning on the PSU and before
switching the output on. Defaults to ``20ms``.
switching the output on. Defaults to ``20ms``. Maximum of less than ``5s``.
- **keep_on_time** (*Optional*, :ref:`config-time`): The time the
power supply should be kept enabled after the last output that used
it has been switch off. Defaults to ``10s``.
- **enable_on_boot** (*Optional*, bool): If the power supply should be enabled when the power supply
component is setup. Defaults to false. The startup delay will be applied (other component setup will be blocked
until the delay has elapsed.) This is useful for power supplies that will never be turned off and avoids the need
to specifically configure the power supply in a different component.
See the :ref:`output component base configuration <config-output>`
for information on how to apply the power supply for a specific output.

197
components/pylontech.rst Normal file
View File

@ -0,0 +1,197 @@
Pylontech Battery
=================
.. seo::
:description: Instructions for setting up Pylontech Battery in ESPHome.
:image: pylontech.jpg
The Pylontech component allows you to pull data from Pylontech Batteries into ESPHome.
It uses :ref:`UART <uart>` for communication.
Once configured, you can use sensors as described below for your projects.
.. figure:: images/pylontech.jpg
:align: center
:width: 50.0%
Pylontech Batteries
Hardware Setup
--------------
You can connect to Pylontech Batteries using the port labeled "Console".
Any connections via CAN or RS485 (e.g. to an inverter) are untouched and remain functional.
The console port offers a RS232 interface using a RJ10 or RJ45 connector.
The voltage levels are *not* TTL-compatible. A RS232 transceiver must be placed between the Batteries and the ESPHome device.
MAX3232-based transceivers have been tested and work well.
If you have multiple batteries you need to connect to the master battery's console port.
.. list-table:: Pylontech RJ45 Console Port (US2000C, US3000C)
:header-rows: 1
* - RJ45 Pin
- Function
- Connect to
* - 3
- Pylontech TX
- ESPHome RX via transceiver
* - 6
- Pylontech RX
- ESPHome TX via transceiver
* - 8
- GND
- GND
.. figure:: images/rj45_pinout.jpg
:align: center
:width: 70.0%
RJ45 pinout
.. list-table:: Pylontech RJ10 Console Pinout (US2000B)
:header-rows: 1
* - RJ410 Pin
- Function
- Connect to
* - 2
- Pylontech RX
- ESPHome TX via transceiver
* - 3
- Pylontech TX
- ESPHome RX via transceiver
* - 4
- GND
- GND
Component/Hub
-------------
.. code-block:: yaml
# Example configuration entry
pylontech:
Configuration variables:
~~~~~~~~~~~~~~~~~~~~~~~~
- **id** (**Required**, :ref:`config-id`): The id to use for this Pylontech component.
- **uart_id** (*Optional*): The uart Bus ID
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the sensor. Defaults to ``60s``.
Sensor
------
All values are reported for every Pylontech battery individually.
.. code-block:: yaml
# Example configuration entry
sensor:
- platform: pylontech
battery: 1
voltage:
name: "Battery1 Voltage"
current:
name: "Battery1 Current"
coulomb:
name: "Battery1 State of Charge"
Configuration variables:
~~~~~~~~~~~~~~~~~~~~~~~~
- **pylontech_id** (*Optional*): Manually specify the ID of the pylontech instance if there are multiple.
- **battery** (**Required**): Which battery to monitor. 1 stands for the main battery, 2..6 for child batteries.
- **voltage** (*Optional*): Voltage of the battery. All options from :ref:`Sensor <config-sensor>`.
- **current** (*Optional*): Current flowing into the battery. Negative when discharging. All options from :ref:`Sensor <config-sensor>`.
- **coulomb** (*Optional*): State of Charge in percent. All options from :ref:`Sensor <config-sensor>`.
- **temperature** (*Optional*): Temperature. All options from :ref:`Sensor <config-sensor>`.
- **temperature_low** (*Optional*): Historic minimum temperature. All options from :ref:`Sensor <config-sensor>`.
- **temperature_high** (*Optional*): Historic maximum temperature. All options from :ref:`Sensor <config-sensor>`.
- **voltage_low** (*Optional*): Voltage of the lowest cell. All options from :ref:`Sensor <config-sensor>`.
- **voltage_high** (*Optional*): Voltage of the highest cell. All options from :ref:`Sensor <config-sensor>`.
- **mos_temperature** (*Optional*): Temperature of the mosfets. All options from :ref:`Sensor <config-sensor>`.
Text Sensor
-----------
.. code-block:: yaml
# Example configuration entry
text_sensor:
- platform: pylontech
pylontech_id: pylontech0
battery: 1
base_state:
id: bat1_base_state
name: "Battery1 Base State"
Configuration variables:
~~~~~~~~~~~~~~~~~~~~~~~~
- **pylontech_id** (**Optional**): Manually specify the ID of the pylontech instance if there are multiple.
- **battery** (**Required**): Which battery to monitor. 1 stands for the main battery, 2..6 for child batteries.
- **base_state** (*Optional*): Base state. Usually reads ``Dischg``, ``Charge`` or ``Idle``. All options from :ref:`Text Sensor <config-text_sensor>`.
- **voltage_state** (*Optional*): Voltage state. Usually reads ``Normal``. All options from :ref:`Text Sensor <config-text_sensor>`.
- **current_state** (*Optional*): Current state. Usually reads ``Normal``. All options from :ref:`Text Sensor <config-text_sensor>`.
- **temperature_state** (*Optional*): Temperature state. Usually reads ``Normal``. All options from :ref:`Text Sensor <config-text_sensor>`.
Energy Monitoring
-----------------
By combining :doc:`template sensors </components/sensor/template>` and :doc:`integration sensors </components/sensor/integration>`
one can monitor the energy flowing into and out of all batteries combined, ready for `Homeassistant Energy Monitoring <https://www.home-assistant.io/docs/energy/battery/>`__.
.. code-block:: yaml
sensor:
- platform: template
id: pylontech_power
name: "Pylontech power"
unit_of_measurement: W
lambda: |-
auto pwr1 = id(bat1_voltage).state * id(bat1_current).state;
auto pwr2 = id(bat2_voltage).state * id(bat2_current).state;
auto pwr = pwr1 + pwr2;
id(combined_charge_power).publish_state(max(pwr, 0.0f));
id(combined_discharge_power).publish_state(max(-pwr, 0.0f));
return pwr;
update_interval: 5s
device_class: power
state_class: measurement
- platform: template
id: combined_charge_power
- platform: template
id: combined_discharge_power
- platform: integration
name: "Pylontech charging"
sensor: combined_charge_power
time_unit: h
state_class: total_increasing
device_class: energy
unit_of_measurement: "Wh"
- platform: integration
name: "Pylontech discharging"
sensor: combined_discharge_power
time_unit: h
state_class: total_increasing
device_class: energy
unit_of_measurement: "Wh"
See Also
--------
- `Pylontech-Battery-Monitoring <https://github.com/irekzielinski/Pylontech-Battery-Monitoring>`__
- `nodered-pylontech-console-reader <https://github.com/juanhaywood/nodered-pylontech-console-reader>`__
- :ref:`uart`
- :ghedit:`Edit`

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