Merge branch 'esphome:current' into current
This commit is contained in:
optimusprimespace
GitHub
commit
4202df26a7
|
|
@ -0,0 +1,7 @@
|
|||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: daily
|
||||
open-pull-requests-limit: 10
|
||||
|
|
@ -20,18 +20,18 @@ jobs:
|
|||
steps:
|
||||
-
|
||||
name: Checkout source code
|
||||
uses: actions/checkout@v2.3.4
|
||||
uses: actions/checkout@v3.1.0
|
||||
-
|
||||
name: Set up Docker Buildx
|
||||
uses: docker/setup-buildx-action@v1.5.1
|
||||
uses: docker/setup-buildx-action@v2
|
||||
-
|
||||
name: Login to DockerHub
|
||||
uses: docker/login-action@v1.10.0
|
||||
uses: docker/login-action@v2
|
||||
with:
|
||||
username: ${{ secrets.DOCKER_USER }}
|
||||
password: ${{ secrets.DOCKER_PASSWORD }}
|
||||
- name: Login to GitHub Container Registry
|
||||
uses: docker/login-action@v1.10.0
|
||||
uses: docker/login-action@v2
|
||||
with:
|
||||
registry: ghcr.io
|
||||
username: ${{ github.repository_owner }}
|
||||
|
|
@ -39,7 +39,7 @@ jobs:
|
|||
-
|
||||
name: Build and push
|
||||
id: docker_build
|
||||
uses: docker/build-push-action@v2.6.1
|
||||
uses: docker/build-push-action@v3
|
||||
with:
|
||||
context: .
|
||||
push: true
|
||||
|
|
|
|||
|
|
@ -19,9 +19,9 @@ jobs:
|
|||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/checkout@v3.1.0
|
||||
- name: Set up Python 3.8
|
||||
uses: actions/setup-python@v2
|
||||
uses: actions/setup-python@v4
|
||||
with:
|
||||
python-version: 3.8
|
||||
- name: Install dependencies
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ jobs:
|
|||
stale:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/stale@v4
|
||||
- uses: actions/stale@v6
|
||||
with:
|
||||
days-before-pr-stale: 60
|
||||
days-before-pr-close: 7
|
||||
|
|
@ -35,7 +35,7 @@ jobs:
|
|||
close-issues:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/stale@v4
|
||||
- uses: actions/stale@v6
|
||||
with:
|
||||
days-before-pr-stale: -1
|
||||
days-before-pr-close: -1
|
||||
|
|
|
|||
|
|
@ -4,4 +4,4 @@ ports:
|
|||
|
||||
tasks:
|
||||
- before: pip3 install -r requirements.txt
|
||||
command: make webserver
|
||||
command: make live-html
|
||||
|
|
|
|||
2
Doxygen
2
Doxygen
|
|
@ -38,7 +38,7 @@ PROJECT_NAME = "ESPHome"
|
|||
# could be handy for archiving the generated documentation or if some version
|
||||
# control system is used.
|
||||
|
||||
PROJECT_NUMBER = 2022.8.0
|
||||
PROJECT_NUMBER = 2022.10.2
|
||||
|
||||
# Using the PROJECT_BRIEF tag one can provide an optional one line description
|
||||
# for a project that appears at the top of each page and should give viewer a
|
||||
|
|
|
|||
2
Makefile
2
Makefile
|
|
@ -1,5 +1,5 @@
|
|||
ESPHOME_PATH = ../esphome
|
||||
ESPHOME_REF = 2022.8.0
|
||||
ESPHOME_REF = 2022.10.2
|
||||
|
||||
.PHONY: html html-strict cleanhtml deploy help live-html Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png minify
|
||||
|
||||
|
|
|
|||
|
|
@ -3,3 +3,4 @@
|
|||
# Moved components
|
||||
# e.g: /components/sensors/abc.html /components/sensors/xyz.html 301
|
||||
/components/sensor/sgp40.html /components/sensor/sgp4x.html 301
|
||||
/components/binary_sensor/xpt2046.html /components/touchscreen/xpt2046.html 301
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 156 KiB |
|
|
@ -186,3 +186,7 @@ div.index-shields {
|
|||
margin-left: 32px;
|
||||
}
|
||||
}
|
||||
|
||||
.breadcrumbs li {
|
||||
display: inline;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
2022.8.0
|
||||
2022.10.2
|
||||
|
|
@ -27,6 +27,17 @@
|
|||
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9">
|
||||
{% endblock %}
|
||||
|
||||
{% block relbar_top %}
|
||||
{% if parents|length > 0 %}
|
||||
<ul class="breadcrumbs">
|
||||
{%- for doc in parents %}
|
||||
<li><a href="{{ doc.link|e }}">{{ doc.title }}</a> ➔</li>
|
||||
{%- endfor %}
|
||||
<li>{{title}}</li>
|
||||
</ul>
|
||||
{% endif %}
|
||||
{% endblock %}
|
||||
|
||||
{% block footer %}
|
||||
<div id="upgrade-footer">
|
||||
A new version has been release since you last visited this page: {{ release }} 🎉
|
||||
|
|
|
|||
|
|
@ -0,0 +1,139 @@
|
|||
ESPHome 2022.10.0 - 19th October 2022
|
||||
=====================================
|
||||
|
||||
.. seo::
|
||||
:description: Changelog for ESPHome 2022.10.0.
|
||||
:image: /_static/changelog-2022.10.0.png
|
||||
:author: Jesse Hills
|
||||
:author_twitter: @jesserockz
|
||||
|
||||
.. imgtable::
|
||||
:columns: 2
|
||||
|
||||
BLE Client RSSI Sensor, components/sensor/ble_client, bluetooth.svg
|
||||
ZHLT01 IR Climate, components/climate/climate_ir, air-conditioner-ir.svg
|
||||
|
||||
|
||||
|
||||
This month we have been busy upgrading the Bluetooth Proxy support for Home Assistant.
|
||||
This meant there are many PRs awaiting reviews for new components that were unable to be
|
||||
reviewed and merged in time. We will be trying to pack the next release.
|
||||
|
||||
Python Version 3.9
|
||||
------------------
|
||||
|
||||
ESPHome now requires Python 3.9 or newer. This is taken care of if you use the Home Assistant addon
|
||||
or docker image. If using pip, you will need to upgrade your Python version manually before ESPHome will
|
||||
upgrade.
|
||||
|
||||
BLE Client Sensors
|
||||
------------------
|
||||
|
||||
Due to adding a new RSSI sensor to the ``ble_client`` sensor platform, a new ``type`` configuration variable.
|
||||
You will get a validation error when you try to install and you have not added a ``type`` to your
|
||||
existing configurations.
|
||||
|
||||
XPT2046 Touchscreen
|
||||
-------------------
|
||||
|
||||
The ``xpt2046`` touchscreen component has been updated to be a platform of ``touchscreen`` instead of a
|
||||
top level component. This requires a small change to your configuration, see :doc:`/components/touchscreen/xpt2046`
|
||||
for the new way to configure.
|
||||
|
||||
Release 2022.10.1 - October 26
|
||||
------------------------------
|
||||
|
||||
- Update bluetooth proxy limit as soon as connection requested :esphomepr:`3935` by :ghuser:`jesserockz`
|
||||
- Add water & precipitation_intensity sensor device classes :esphomepr:`3940` by :ghuser:`frenck`
|
||||
- Fixed touch release issue using the interrupt pin :esphomepr:`3925` by :ghuser:`nielsnl68`
|
||||
- Add wind_speed sensor device class :esphomepr:`3941` by :ghuser:`frenck`
|
||||
|
||||
Release 2022.10.2 - November 1
|
||||
------------------------------
|
||||
|
||||
- Fix bluetooth_proxy not connecting :esphomepr:`3967` by :ghuser:`jesserockz`
|
||||
|
||||
Full list of changes
|
||||
--------------------
|
||||
|
||||
Breaking Changes
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
- Thermostat remove deprecated config :esphomepr:`3643` by :ghuser:`MrMDavidson` (breaking-change)
|
||||
- Bump python min to 3.9 :esphomepr:`3871` by :ghuser:`jesserockz` (breaking-change)
|
||||
- Refactor xpt2046 to be a touchscreen platform :esphomepr:`3793` by :ghuser:`nielsnl68` (breaking-change)
|
||||
- Add ble RSSI sensor for connected devices :esphomepr:`3860` by :ghuser:`RoboMagus` (breaking-change)
|
||||
|
||||
Beta Changes
|
||||
^^^^^^^^^^^^
|
||||
|
||||
- fix never calling preset change trigger :esphomepr:`3864` by :ghuser:`glmnet`
|
||||
- Modbus QWORD fix :esphomepr:`3856` by :ghuser:`dudanov`
|
||||
- Send true and not RSSI in ble_presence :esphomepr:`3904` by :ghuser:`fjouault`
|
||||
- Remove address type map from bluetooth proxy :esphomepr:`3905` by :ghuser:`jesserockz`
|
||||
|
||||
All changes
|
||||
^^^^^^^^^^^
|
||||
|
||||
- Update mcp23s17.cpp :esphomepr:`3797` by :ghuser:`pawel3410`
|
||||
- Allow CORS for web_server :esphomepr:`3819` by :ghuser:`zhzhzhy`
|
||||
- Dont fail fast on CI for docker :esphomepr:`3832` by :ghuser:`jesserockz`
|
||||
- Thermostat remove deprecated config :esphomepr:`3643` by :ghuser:`MrMDavidson` (breaking-change)
|
||||
- Add support for parsing the short local name in the tracker :esphomepr:`3854` by :ghuser:`bdraco`
|
||||
- Add display GPIO setup instruction for Aliexpress display :esphomepr:`3851` by :ghuser:`kbx81`
|
||||
- fix dump preset string type :esphomepr:`3863` by :ghuser:`glmnet`
|
||||
- Bump CI to python 3.9 :esphomepr:`3869` by :ghuser:`jesserockz`
|
||||
- Add cg.with_local_variable :esphomepr:`3577` by :ghuser:`jpeletier`
|
||||
- Fix time/automation (cron) wdt crash when time jumps ahead too much :esphomepr:`3844` by :ghuser:`jpeletier`
|
||||
- Bump pyupgrade from 2.37.3 to 3.0.0 :esphomepr:`3867` by :ghuser:`dependabot[bot]`
|
||||
- Add min_version to esphome config :esphomepr:`3866` by :ghuser:`jesserockz`
|
||||
- Bump python min to 3.9 :esphomepr:`3871` by :ghuser:`jesserockz` (breaking-change)
|
||||
- Bump pylint from 2.15.2 to 2.15.3 :esphomepr:`3870` by :ghuser:`dependabot[bot]`
|
||||
- Add new sensor device classes :esphomepr:`3895` by :ghuser:`jesserockz`
|
||||
- Refactor xpt2046 to be a touchscreen platform :esphomepr:`3793` by :ghuser:`nielsnl68` (breaking-change)
|
||||
- Proxy friendly host url resolution for `use_address` with path. :esphomepr:`3653` by :ghuser:`RoboMagus`
|
||||
- Update webserver index file :esphomepr:`3896` by :ghuser:`jesserockz`
|
||||
- Correctly set ble_write UUIDs based on their lengths. :esphomepr:`3885` by :ghuser:`RoboMagus`
|
||||
- Fix default unit for ble_rssi sensor :esphomepr:`3874` by :ghuser:`RoboMagus`
|
||||
- Exposing coordinates from touchscreen binary sensor :esphomepr:`3891` by :ghuser:`gpambrozio`
|
||||
- Fix type annotation on `extract_registry_entry_config` :esphomepr:`3623` by :ghuser:`quentinmit`
|
||||
- Add ble RSSI sensor for connected devices :esphomepr:`3860` by :ghuser:`RoboMagus` (breaking-change)
|
||||
- Fix pulse_meter filter logic :esphomepr:`3321` by :ghuser:`cstaahl`
|
||||
- Add support for ZHLT01 heatpump IR protocol :esphomepr:`3655` by :ghuser:`cfeenstra1024`
|
||||
- Send GATT error events to HA :esphomepr:`3884` by :ghuser:`jesserockz`
|
||||
- Do not require CS pin for ST7789V :esphomepr:`3888` by :ghuser:`definitio`
|
||||
- fix never calling preset change trigger :esphomepr:`3864` by :ghuser:`glmnet`
|
||||
- Modbus QWORD fix :esphomepr:`3856` by :ghuser:`dudanov`
|
||||
- Send true and not RSSI in ble_presence :esphomepr:`3904` by :ghuser:`fjouault`
|
||||
- Remove address type map from bluetooth proxy :esphomepr:`3905` by :ghuser:`jesserockz`
|
||||
|
||||
Past Changelogs
|
||||
---------------
|
||||
|
||||
- :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`
|
||||
|
|
@ -15,6 +15,19 @@ ESPHome 2022.8.0 - 17th August 2022
|
|||
Feedback Cover, components/cover/feedback, feedback_cover.svg
|
||||
SMT100, components/sensor/smt100, smt100.jpg, Moisture & Temperature
|
||||
Whynter IR Climate, components/climate/climate_ir, air-conditioner-ir.svg
|
||||
Bluetooth Proxy, components/bluetooth_proxy, bluetooth.svg
|
||||
|
||||
|
||||
Bluetooth Proxy
|
||||
---------------
|
||||
|
||||
ESPHome 2022.8.2 brings a new feature that allows you to use your ESP32 devices as Bluetooth Proxies for Home Assistant.
|
||||
They will forward the BLE Advertisements to Home Assistant which will then trigger a discovery and allow you to set up
|
||||
an integration for the found devices. This allows you to set up multiple ESP32 Bluetooth Proxies around the area to make
|
||||
sure all advertisements are received reliably.
|
||||
|
||||
We have created a few examples that are ready to flash directly from your browser for some specific devices:
|
||||
https://esphome.github.io/bluetooth-proxies/
|
||||
|
||||
|
||||
Sprinkler controller
|
||||
|
|
@ -37,6 +50,23 @@ the :doc:`/components/sensor/integration` and :doc:`/components/sensor/total_dai
|
|||
The BedJet climate introduced recently has also undergone a refactoring to allow different
|
||||
platforms to extend the functionality available from ESPHome.
|
||||
|
||||
Release 2022.8.1 - September 1
|
||||
------------------------------
|
||||
|
||||
- fix grow password setting :esphomepr:`3722` by :ghuser:`ssieb`
|
||||
- Fix SPI HW selection for ESP32 variants :esphomepr:`3728` by :ghuser:`kbx81`
|
||||
|
||||
Release 2022.8.2 - September 6
|
||||
------------------------------
|
||||
|
||||
- Initial bluetooth_proxy support :esphomepr:`3736` by :ghuser:`jesserockz` (new-integration)
|
||||
- Ignore NaN states in the integration component :esphomepr:`3767` by :ghuser:`anatoly-savchenkov`
|
||||
- Update modbus_controller.cpp :esphomepr:`3768` by :ghuser:`Avirsaam`
|
||||
|
||||
Release 2022.8.3 - September 6
|
||||
------------------------------
|
||||
|
||||
- Fix HA addon auth using HA credentials :esphomepr:`3758` by :ghuser:`jesserockz`
|
||||
|
||||
Full list of changes
|
||||
--------------------
|
||||
|
|
|
|||
|
|
@ -0,0 +1,194 @@
|
|||
ESPHome 2022.9.0 - 21st September 2022
|
||||
======================================
|
||||
|
||||
.. seo::
|
||||
:description: Changelog for ESPHome 2022.9.0.
|
||||
:image: /_static/changelog-2022.9.0.png
|
||||
:author: Jesse Hills
|
||||
:author_twitter: @jesserockz
|
||||
|
||||
.. imgtable::
|
||||
:columns: 4
|
||||
|
||||
DPS310, components/sensor/dps310, dps310.jpg
|
||||
MCP9600, components/sensor/mcp9600, mcp9600.jpg
|
||||
TM1621, components/display/tm1621, tm1621.jpg
|
||||
MPL3115A2, components/sensor/mpl3115a2, mpl3115a2.jpg
|
||||
uFire EC sensor, components/sensor/ufire_ec, ufire_ec.png
|
||||
uFire ISE sensor, components/sensor/ufire_ise, ufire_ise.png
|
||||
Factory Reset Switch, components/switch/factory_reset, restart-alert.svg
|
||||
Factory Reset Button, components/button/factory_reset, restart-alert.svg
|
||||
TM1638, components/display/tm1638, tm1638.jpg
|
||||
BL0942, components/sensor/bl0942, bl0942.png
|
||||
|
||||
|
||||
ESPHome Editor
|
||||
--------------
|
||||
|
||||
The editor used in ESPHome has been swapped out for Monaco thanks to :ghuser:`glmnet`. He has
|
||||
been working hard to make the experience of writing your YAML configurations easier and it now
|
||||
supports auto completion with popups to show you more information.
|
||||
|
||||
Factory Reset
|
||||
-------------
|
||||
|
||||
A new Factory Reset switch and button has been added this release, allowing resetting of information such
|
||||
as counters, restored values, and more importantly, the wifi credentials of a device that has been set up
|
||||
using the captive portal such as pre-flashed devices you would have purchased.
|
||||
|
||||
Bluetooth Active Connections
|
||||
----------------------------
|
||||
|
||||
ESPHome 2022.9.3 adds active connections to the ``bluetooth_proxy`` component allowing Home Assistant
|
||||
to connect to and control supported devices.
|
||||
|
||||
Release 2022.9.1 - September 22
|
||||
-------------------------------
|
||||
|
||||
- Revert "fix spi timing issues" :esphomepr:`3838` by :ghuser:`jesserockz`
|
||||
|
||||
Release 2022.9.2 - September 29
|
||||
-------------------------------
|
||||
|
||||
- Bump dashboard to 20220925.0 :esphomepr:`3846` by :ghuser:`glmnet`
|
||||
|
||||
Release 2022.9.3 - October 6
|
||||
----------------------------
|
||||
|
||||
- Bluetooth Proxy active connections :esphomepr:`3817` by :ghuser:`jesserockz`
|
||||
|
||||
Release 2022.9.4 - October 7
|
||||
----------------------------
|
||||
|
||||
- Add network type to mdns service message :esphomepr:`3880` by :ghuser:`jesserockz`
|
||||
- Bump esphome-dashboard to 20221007.0 :esphomepr:`3881` by :ghuser:`jesserockz`
|
||||
- Dont add wifi block to yaml if discovered device uses ethernet :esphomepr:`3882` by :ghuser:`jesserockz`
|
||||
|
||||
Full list of changes
|
||||
--------------------
|
||||
|
||||
New Components
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
- Add dps310 sensor support :esphomepr:`3704` by :ghuser:`kbx81` (new-integration)
|
||||
- Support for MCP9600 Thermocouple Amplifier :esphomepr:`3700` by :ghuser:`MrEditor97` (new-integration)
|
||||
- Add support to tm1621 display :esphomepr:`3737` by :ghuser:`Philippe12` (new-integration)
|
||||
- u-fire EC sensor :esphomepr:`3774` by :ghuser:`pvizeli` (new-integration)
|
||||
- Add support for MPL3115A2 Pressure/Altitude and Temperature Sensor :esphomepr:`3371` by :ghuser:`kbickar` (new-integration)
|
||||
- Add support for BL0942 voltage, current, energy and power Sensor :esphomepr:`3777` by :ghuser:`dbuezas` (new-integration)
|
||||
- Add Factory Reset button and switch :esphomepr:`3724` by :ghuser:`anatoly-savchenkov` (new-integration)
|
||||
- Add support for TM1638 Led and Key component :esphomepr:`3340` by :ghuser:`skykingjwc` (new-integration)
|
||||
- Add uFire ISE sensor :esphomepr:`3789` by :ghuser:`pvizeli` (new-integration)
|
||||
|
||||
Beta Changes
|
||||
^^^^^^^^^^^^
|
||||
|
||||
- null initialize total sensor for pulse counter :esphomepr:`3803` by :ghuser:`RoboMagus`
|
||||
- Sim800l add calls, multiline sms and ussd :esphomepr:`3630` by :ghuser:`glmnet`
|
||||
- Unify 'nullptr' initalization of class members; :esphomepr:`3805` by :ghuser:`RoboMagus`
|
||||
- Initialize all child sensors to nullptr :esphomepr:`3808` by :ghuser:`jesserockz`
|
||||
- Remove floating point calculation from ac_dimmer ISR :esphomepr:`3770` by :ghuser:`Azimath`
|
||||
- split pronto codes if they are too long :esphomepr:`3812` by :ghuser:`ssieb`
|
||||
- [BME280] raise standby time :esphomepr:`3804` by :ghuser:`h3ndrik`
|
||||
- Make sprinkler reset_resume() method public :esphomepr:`3824` by :ghuser:`kbx81`
|
||||
- Bump dashboard to 20220919.1 :esphomepr:`3828` by :ghuser:`balloob`
|
||||
- Fix-esphome-validation-line-number :esphomepr:`3815` by :ghuser:`glmnet`
|
||||
- Bump dashboard to 20220920.0 :esphomepr:`3831` by :ghuser:`balloob`
|
||||
- Bump dashboard to 20220920.1 :esphomepr:`3834` by :ghuser:`glmnet`
|
||||
|
||||
All changes
|
||||
^^^^^^^^^^^
|
||||
|
||||
- support modifying the apds9960 settings :esphomepr:`3708` by :ghuser:`ssieb`
|
||||
- Add support for pvvx mithermometer display via ble client :esphomepr:`3333` by :ghuser:`puuu`
|
||||
- Improve OTA error messages adding return codes :esphomepr:`3698` by :ghuser:`IgnacioHR`
|
||||
- Send CR also for commands for sim800l :esphomepr:`3719` by :ghuser:`ssieb`
|
||||
- hydreon_rgxx: Support lens_bad, em_sat and temperature :esphomepr:`3642` by :ghuser:`functionpointer`
|
||||
- wifi: support 802.11k and 802.11v :esphomepr:`3600` by :ghuser:`stintel`
|
||||
- Add final validate for i2c with mix/max frequency :esphomepr:`3727` by :ghuser:`jesserockz`
|
||||
- Add dps310 sensor support :esphomepr:`3704` by :ghuser:`kbx81` (new-integration)
|
||||
- Let favicon be cached :esphomepr:`3729` by :ghuser:`slovdahl`
|
||||
- Add bitmap font support :esphomepr:`3573` by :ghuser:`justfalter`
|
||||
- add log messages for bad pronto codes :esphomepr:`3738` by :ghuser:`ssieb`
|
||||
- add color compare operator's :esphomepr:`3730` by :ghuser:`nielsnl68`
|
||||
- Support for MCP9600 Thermocouple Amplifier :esphomepr:`3700` by :ghuser:`MrEditor97` (new-integration)
|
||||
- Support high update rates and fix several bugs in the cse7766 component. :esphomepr:`3675` by :ghuser:`fhriley`
|
||||
- Add Prometheus metrics relabeling :esphomepr:`3734` by :ghuser:`jangrewe`
|
||||
- mcp23017: read output latch registers during setup :esphomepr:`3744` by :ghuser:`andyboeh`
|
||||
- Captive portal show nearby WiFi with no ssid configured :esphomepr:`3748` by :ghuser:`anatoly-savchenkov`
|
||||
- Remove unnecessary schema extension on template button :esphomepr:`3753` by :ghuser:`jesserockz`
|
||||
- Tidy up switch schemas :esphomepr:`3754` by :ghuser:`jesserockz`
|
||||
- Add IP101 support to Ethernet component :esphomepr:`3751` by :ghuser:`kbx81`
|
||||
- Add BedJet Fan child component :esphomepr:`3735` by :ghuser:`jhansche`
|
||||
- ibeacon support for the ble_rssi sensor :esphomepr:`3745` by :ghuser:`wjtje`
|
||||
- Add AEHA IR Protocol :esphomepr:`3726` by :ghuser:`hazi`
|
||||
- Add sum type to binary_sensor_map :esphomepr:`3541` by :ghuser:`fbrthld`
|
||||
- Bump aioesphomeapi from 10.11.0 to 10.13.0 :esphomepr:`3740` by :ghuser:`dependabot[bot]`
|
||||
- Bump pylint from 2.14.5 to 2.15.0 :esphomepr:`3746` by :ghuser:`dependabot[bot]`
|
||||
- Esp32 pulsecounter optional pcnt :esphomepr:`3691` by :ghuser:`RoboMagus`
|
||||
- Bump black from 22.6.0 to 22.8.0 :esphomepr:`3760` by :ghuser:`dependabot[bot]`
|
||||
- Various ili9341 fixes :esphomepr:`3756` by :ghuser:`nielsnl68`
|
||||
- Add the same docker tags as used in HA :esphomepr:`3752` by :ghuser:`andrey-yantsen`
|
||||
- Bump pytest from 7.1.1 to 7.1.3 :esphomepr:`3766` by :ghuser:`dependabot[bot]`
|
||||
- Remove unneeded line (spi component adds it) :esphomepr:`3778` by :ghuser:`jesserockz`
|
||||
- Move crc16 to helpers :esphomepr:`3780` by :ghuser:`jesserockz`
|
||||
- YAML linting :esphomepr:`3779` by :ghuser:`jesserockz`
|
||||
- Add support to tm1621 display :esphomepr:`3737` by :ghuser:`Philippe12` (new-integration)
|
||||
- u-fire EC sensor :esphomepr:`3774` by :ghuser:`pvizeli` (new-integration)
|
||||
- Add support for MPL3115A2 Pressure/Altitude and Temperature Sensor :esphomepr:`3371` by :ghuser:`kbickar` (new-integration)
|
||||
- Add support for BL0942 voltage, current, energy and power Sensor :esphomepr:`3777` by :ghuser:`dbuezas` (new-integration)
|
||||
- Bump pylint from 2.15.0 to 2.15.2 :esphomepr:`3785` by :ghuser:`dependabot[bot]`
|
||||
- Add Factory Reset button and switch :esphomepr:`3724` by :ghuser:`anatoly-savchenkov` (new-integration)
|
||||
- [MPU6050] Support devices with WHOAMI 0x98 :esphomepr:`3784` by :ghuser:`CarlosGS`
|
||||
- Bump zeroconf from 0.39.0 to 0.39.1 :esphomepr:`3782` by :ghuser:`dependabot[bot]`
|
||||
- Add support for TM1638 Led and Key component :esphomepr:`3340` by :ghuser:`skykingjwc` (new-integration)
|
||||
- Remove status_set_error from ufire_ec :esphomepr:`3792` by :ghuser:`pvizeli`
|
||||
- Bump frenck/action-yamllint from 1.2.0 to 1.3.0 :esphomepr:`3798` by :ghuser:`dependabot[bot]`
|
||||
- esp32_ble_tracker continuous and one shot scanning modes :esphomepr:`3649` by :ghuser:`jonofmac`
|
||||
- Add stop action for ble scanning :esphomepr:`3799` by :ghuser:`jesserockz`
|
||||
- Add Prometheus Service Discovery for online devices :esphomepr:`3788` by :ghuser:`cznewt`
|
||||
- Allow ble tracker to subscribe to ota start and stop the scanning :esphomepr:`3800` by :ghuser:`jesserockz`
|
||||
- Add uFire ISE sensor :esphomepr:`3789` by :ghuser:`pvizeli` (new-integration)
|
||||
- fix spi timing issues :esphomepr:`3763` by :ghuser:`IgnacioHR`
|
||||
- null initialize total sensor for pulse counter :esphomepr:`3803` by :ghuser:`RoboMagus`
|
||||
- Sim800l add calls, multiline sms and ussd :esphomepr:`3630` by :ghuser:`glmnet`
|
||||
- Unify 'nullptr' initalization of class members; :esphomepr:`3805` by :ghuser:`RoboMagus`
|
||||
- Initialize all child sensors to nullptr :esphomepr:`3808` by :ghuser:`jesserockz`
|
||||
- Remove floating point calculation from ac_dimmer ISR :esphomepr:`3770` by :ghuser:`Azimath`
|
||||
- split pronto codes if they are too long :esphomepr:`3812` by :ghuser:`ssieb`
|
||||
- [BME280] raise standby time :esphomepr:`3804` by :ghuser:`h3ndrik`
|
||||
- Make sprinkler reset_resume() method public :esphomepr:`3824` by :ghuser:`kbx81`
|
||||
- Bump dashboard to 20220919.1 :esphomepr:`3828` by :ghuser:`balloob`
|
||||
- Fix-esphome-validation-line-number :esphomepr:`3815` by :ghuser:`glmnet`
|
||||
- Bump dashboard to 20220920.0 :esphomepr:`3831` by :ghuser:`balloob`
|
||||
- Bump dashboard to 20220920.1 :esphomepr:`3834` by :ghuser:`glmnet`
|
||||
|
||||
Past Changelogs
|
||||
---------------
|
||||
|
||||
- :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,7 +2,7 @@ Changelog
|
|||
=========
|
||||
|
||||
.. redirect::
|
||||
:url: /changelog/2022.8.0.html
|
||||
:url: /changelog/2022.10.0.html
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
import os
|
||||
import json
|
||||
|
||||
|
||||
|
||||
def setup(app):
|
||||
"""Setup connects events to the components output builder"""
|
||||
app.connect("html-page-context", add_component_details)
|
||||
app.connect("build-finished", create_output)
|
||||
app.compoents_output = {}
|
||||
|
||||
is_production = os.getenv("NETLIFY") == "true"
|
||||
|
||||
return {
|
||||
"version": "1.0.0",
|
||||
"parallel_read_safe": True,
|
||||
"parallel_write_safe": not is_production,
|
||||
}
|
||||
|
||||
|
||||
def add_component_details(app, pagename, templatename, context, doctree):
|
||||
"""As each page is built, collect page details for the output."""
|
||||
if pagename.startswith("components/"):
|
||||
page_key = pagename[11:].replace("/", "_")
|
||||
component_name = pagename.split("/")[-1]
|
||||
page_data = {
|
||||
"title": context["title"],
|
||||
"url": context["pageurl"],
|
||||
"path": context["pagename"],
|
||||
}
|
||||
if os.path.exists(os.path.join(app.builder.srcdir, "images", component_name + ".png")):
|
||||
page_data["image"] = app.builder.config.html_baseurl + "/_images/" + component_name + ".png"
|
||||
elif os.path.exists(os.path.join(app.builder.srcdir, "images", component_name + ".jpg")):
|
||||
page_data["image"] = app.builder.config.html_baseurl + "/_images/" + component_name + ".jpg"
|
||||
|
||||
app.compoents_output[page_key] = page_data
|
||||
|
||||
|
||||
def create_output(app, exception):
|
||||
"""Generates the components.json from the collected component pages"""
|
||||
with open(os.path.join(app.builder.outdir, "components.json"), "wt") as f:
|
||||
f.write(json.dumps(app.compoents_output))
|
||||
|
|
@ -40,7 +40,23 @@ Configuration variables:
|
|||
|
||||
- **too_cold** (*Optional*): ``true`` if the sensor reports being too cold. Hydreon only mentions this feature for the RG-9.
|
||||
|
||||
- **name** (**Required**, string): The name for the voltage sensor.
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
|
||||
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
|
||||
- **lens_bad** (*Optional*): ``true`` if the sensor reports the lens being bad.
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
|
||||
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
|
||||
- **em_sat** (*Optional*): ``true`` if the sensor reports the Emitter being saturated.
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ This automation is triggered when the client disconnects from a BLE device.
|
|||
-------------------------------
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
Example usage:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,45 @@
|
|||
Bluetooth Proxy
|
||||
===============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the Bluetooth Proxy in ESPHome.
|
||||
:image: bluetooth.svg
|
||||
|
||||
Home Assistant can expand its Bluetooth reach by communicating through
|
||||
the Bluetooth proxy component in ESPHome. Place your ESPHome devices close to the
|
||||
Bluetooth devices that you want to interact with for the best
|
||||
experience.
|
||||
|
||||
If you're looking to create a device that is just a Bluetooth Proxy, see our `Bluetooth Proxy installer <https://esphome.github.io/bluetooth-proxies/>`__ website.
|
||||
|
||||
The Bluetooth proxy depends on :doc:`esp32_ble_tracker` so make sure to add that to your configuration.
|
||||
|
||||
.. note::
|
||||
|
||||
Bluetooth proxy requires Home Assistant 2022.9 or later.
|
||||
|
||||
.. note::
|
||||
|
||||
The Bluetooth proxy of ESPHome currently only provides Home Assistant with passive sensor
|
||||
data that is advertised by certain devices. Not all devices are supported and ESPHome does not decode or keep a list.
|
||||
To find out if your device is supported, please search for it in the `Home Assistant Integrations <https://www.home-assistant.io/integrations/>`__ list.
|
||||
|
||||
The Individual device integrations in Home Assistant (such as BTHome) will receive the data from the Bluetooth Integration in Home Assistant
|
||||
which automatically aggregates all ESPHome bluetooth proxies with any USB Bluetooth Adapters you might have.
|
||||
|
||||
Configuration:
|
||||
--------------
|
||||
|
||||
.. code-block::
|
||||
|
||||
bluetooth_proxy:
|
||||
|
||||
- **active** (*Optional*, boolean): Enables proxying active connections. Defaults to ``false``. Requires Home Assistant 2022.10 or later.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`esp32_ble_tracker`
|
||||
- :apiref:`bluetooth_proxy/bluetooth_proxy.h`
|
||||
- BTHome `<https://bthome.io/>`__
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
Factory Reset Button
|
||||
====================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up buttons that can remotely invalidate all ESPHome preferences stored in flash and reboot ESP.
|
||||
:image: restart.svg
|
||||
|
||||
The ``factory_reset`` button allows you to remotely invalidate (reset) all ESPHome :ref:`preferences <preferences-flash_write_interval>` stored in flash memory and reboot your node.
|
||||
After reboot all states, parameters and variables will be reinitialized with their default values. This is useful:
|
||||
|
||||
- for devices preflashed with ESPHome to reset behavior back to factory state
|
||||
- in case of moving a device to a new environment or starting a new use-case (e.g. reset counters or state)
|
||||
- for privacy concerns when giving away a device
|
||||
|
||||
.. note::
|
||||
|
||||
**USE WITH GREAT CAUTION!** All credentials, global variables, counters and saved states stored in non-volatile memory will be lost with no chance of recovering them.
|
||||
Even raw reading of flash memory with ``esptool`` will not help, since data is physically erased from flash memory.
|
||||
|
||||
For devices configured using :doc:`captive portal </components/captive_portal>`, this will reset WiFi settings as well, thus making such devices offline.
|
||||
You'll need to be in close proximity to your device to configure it again using a built-in WiFi access point and captive portal.
|
||||
|
||||
|
||||
.. figure:: images/factory-rst-ui.png
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
button:
|
||||
- platform: factory_reset
|
||||
name: Restart with Factory Default Settings
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **name** (**Required**, string): The name of the button.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Button <config-button>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`shutdown`
|
||||
- :doc:`restart`
|
||||
- :doc:`safe_mode`
|
||||
- :doc:`/components/switch/factory_reset`
|
||||
- :doc:`template`
|
||||
- :apiref:`factory_reset/factory_reset_button.h`
|
||||
- :ghedit:`Edit`
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 7.4 KiB |
|
|
@ -25,6 +25,9 @@ Configuration variables:
|
|||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`shutdown`
|
||||
- :doc:`safe_mode`
|
||||
- :doc:`factory_reset`
|
||||
- :doc:`/components/switch/restart`
|
||||
- :doc:`template`
|
||||
- :apiref:`restart/button/restart_button.h`
|
||||
|
|
|
|||
|
|
@ -33,6 +33,8 @@ See Also
|
|||
|
||||
- :doc:`shutdown`
|
||||
- :doc:`restart`
|
||||
- :doc:`factory_reset`
|
||||
- :doc:`/components/switch/safe_mode`
|
||||
- :doc:`template`
|
||||
- :apiref:`safe_mode/safe_mode_button.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -32,6 +32,9 @@ See Also
|
|||
--------
|
||||
|
||||
- :doc:`restart`
|
||||
- :doc:`safe_mode`
|
||||
- :doc:`factory_reset`
|
||||
- :doc:`/components/switch/shutdown`
|
||||
- :doc:`template`
|
||||
- :apiref:`shutdown/shutdown_button.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -68,32 +68,6 @@ From :ref:`lambdas <config-lambda>`, you can call methods to do some advanced st
|
|||
- lambda: |-
|
||||
id(bedjet_1).upgrade_firmware();
|
||||
|
||||
``bedjet`` Climate Platform
|
||||
---------------------------
|
||||
|
||||
The `climate` platform exposes the BedJet's climate-related functionality, including
|
||||
setting the mode and target temperature.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
climate:
|
||||
- platform: bedjet
|
||||
id: my_bedjet_climate_entity
|
||||
name: "My BedJet"
|
||||
bedjet_id: bedjet_1
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **name** (**Required**, string): The name of the climate device.
|
||||
- **bedjet_id** (**Required**, :ref:`config-id`): The ID of the Bedjet component.
|
||||
- **heat_mode** (*Optional*, string): The primary heating mode to use for ``HVACMode.HEAT``:
|
||||
- ``"heat"`` (Default) - Setting ``hvac_mode=heat`` uses the BedJet "HEAT" mode.
|
||||
- ``"extended"`` - Setting ``hvac_mode=heat`` uses BedJet "EXT HEAT" mode.
|
||||
- Whichever is not selected will be made available as a custom preset.
|
||||
- All other options from :ref:`Climate <config-climate>`.
|
||||
|
||||
- ``.send_local_time``: If `time_id` is set, attempt to sync the clock now.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
|
@ -118,6 +92,61 @@ Configuration variables:
|
|||
- lambda: |-
|
||||
id(my_bedjet_fan).set_clock(22, 10);
|
||||
|
||||
|
||||
``bedjet`` Climate
|
||||
------------------
|
||||
|
||||
The ``climate`` platform exposes the BedJet's climate-related functionality, including
|
||||
setting the mode and target temperature.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
climate:
|
||||
- platform: bedjet
|
||||
id: my_bedjet_climate_entity
|
||||
name: "My BedJet"
|
||||
bedjet_id: bedjet_1
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **name** (**Required**, string): The name of the climate device.
|
||||
- **bedjet_id** (**Required**, :ref:`config-id`): The ID of the Bedjet component.
|
||||
- **heat_mode** (*Optional*, string): The primary heating mode to use for ``HVACMode.HEAT``:
|
||||
|
||||
- ``heat`` (Default) - Setting ``hvac_mode=heat`` uses the BedJet "HEAT" mode.
|
||||
- ``extended`` - Setting ``hvac_mode=heat`` uses BedJet "EXT HEAT" mode.
|
||||
|
||||
Whichever is not selected will be made available as a custom preset.
|
||||
|
||||
- All other options from :ref:`Climate <config-climate>`.
|
||||
|
||||
``bedjet`` Fan
|
||||
--------------
|
||||
|
||||
The `fan` platform exposes the BedJet's fan-related functionality, including
|
||||
on/off and speed control.
|
||||
|
||||
When the BedJet is already on, turning the Fan component off will set the BedJet unit's mode to
|
||||
``OFF``. If it was not already on, it will be turned on to mode ``FAN_ONLY``.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
fan:
|
||||
- platform: bedjet
|
||||
id: my_bedjet_fan_entity
|
||||
name: "My BedJet Fan"
|
||||
bedjet_id: bedjet_1
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **name** (**Required**, string): The name of the fan device.
|
||||
- **bedjet_id** (**Required**, :ref:`config-id`): The ID of the Bedjet component.
|
||||
- Other options from :ref:`Fan <config-fan>`.
|
||||
|
||||
Known issues:
|
||||
-------------
|
||||
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ This platform utilises the library's generic one-size-fits-all API, which might
|
|||
|
||||
Additional configuration must be specified for this platform:
|
||||
|
||||
- **protocol** (**Required**, string): Choose one of Arduino-HeatpumpIR's supported protcols: ``aux``, ``ballu``, ``carrier_mca``, ``carrier_nqv``, ``daikin_arc417``, ``daikin_arc480``, ``daikin``, ``electroluxyal``, ``fuego``, ``fujitsu_awyz``, ``gree``, ``greeya``, ``greeyac``, ``greeyan``, ``hisense_aud``, ``hitachi``, ``hyundai``, ``ivt``, ``midea``, ``mitsubishi_fa``, ``mitsubishi_fd``, ``mitsubishi_fe``, ``mitsubishi_heavy_fdtc``, ``mitsubishi_heavy_zj``, ``mitsubishi_heavy_zm``, ``mitsubishi_heavy_zmp``, ``mitsubishi_heavy_kj``, ``mitsubishi_msc``, ``mitsubishi_msy``, ``mitsubishi_sez``, ``panasonic_ckp``, ``panasonic_dke``, ``panasonic_jke``, ``panasonic_lke``, ``panasonic_nke``, ``samsung_aqv``, ``samsung_fjm``, ``sharp``, ``toshiba_daiseikai``, ``toshiba``
|
||||
- **protocol** (**Required**, string): Choose one of Arduino-HeatpumpIR's supported protcols: ``aux``, ``ballu``, ``carrier_mca``, ``carrier_nqv``, ``daikin_arc417``, ``daikin_arc480``, ``daikin``, ``electroluxyal``, ``fuego``, ``fujitsu_awyz``, ``gree``, ``greeya``, ``greeyac``, ``greeyan``, ``hisense_aud``, ``hitachi``, ``hyundai``, ``ivt``, ``midea``, ``mitsubishi_fa``, ``mitsubishi_fd``, ``mitsubishi_fe``, ``mitsubishi_heavy_fdtc``, ``mitsubishi_heavy_zj``, ``mitsubishi_heavy_zm``, ``mitsubishi_heavy_zmp``, ``mitsubishi_heavy_kj``, ``mitsubishi_msc``, ``mitsubishi_msy``, ``mitsubishi_sez``, ``panasonic_ckp``, ``panasonic_dke``, ``panasonic_jke``, ``panasonic_lke``, ``panasonic_nke``, ``samsung_aqv``, ``samsung_fjm``, ``sharp``, ``toshiba_daiseikai``, ``toshiba``, ``zhlt01``
|
||||
- **horizontal_default** (**Required**, string): What to default to when the AC unit's horizontal direction is *not* set to swing. Options are: ``left``, ``mleft``, ``middle``, ``mright``, ``right``, ``auto``
|
||||
- **vertical_default** (**Required**, string): What to default to when the AC unit's vertical direction is *not* set to swing. Options are: ``down``, ``mdown``, ``middle``, ``mup``, ``up``, ``auto``
|
||||
- **max_temperature** (**Required**, float): The maximum temperature that the AC unit supports being set to.
|
||||
|
|
@ -120,6 +120,8 @@ Additional configuration must be specified for this platform:
|
|||
internal temperature sensor; a value of 2 minutes seems to work well. See :doc:`/components/sensor/index`
|
||||
for more information.
|
||||
|
||||
- The ``zhlt01`` protocol supports multiple AC brands: Eurom, Chigo, Tristar, Tecnomaster, Elgin, Geant, Tekno, Topair, Proma, Sumikura, JBS, Turbo Air, Nakatomy, Celestial Air, Ager, Blueway, Airlux, etc.
|
||||
|
||||
.. _ir-receiver_id:
|
||||
|
||||
Using a Receiver
|
||||
|
|
|
|||
|
|
@ -27,9 +27,9 @@ All climate platforms in ESPHome inherit from the climate configuration schema.
|
|||
climate:
|
||||
- platform: ...
|
||||
visual:
|
||||
min_temperature: 18 °C
|
||||
max_temperature: 25 °C
|
||||
temperature_step: 0.1 °C
|
||||
min_temperature: 18
|
||||
max_temperature: 25
|
||||
temperature_step: 0.1
|
||||
|
||||
Configuration variables:
|
||||
|
||||
|
|
|
|||
|
|
@ -52,8 +52,6 @@ modes that Home Assistant offers.
|
|||
- platform: thermostat
|
||||
name: "Thermostat Climate Controller"
|
||||
sensor: my_temperature_sensor
|
||||
default_target_temperature_low: 20 °C
|
||||
default_target_temperature_high: 22 °C
|
||||
min_cooling_off_time: 300s
|
||||
min_cooling_run_time: 300s
|
||||
min_heating_off_time: 300s
|
||||
|
|
@ -66,6 +64,11 @@ modes that Home Assistant offers.
|
|||
idle_action:
|
||||
- switch.turn_off: air_cond
|
||||
- switch.turn_off: heater
|
||||
default_preset: Home
|
||||
preset:
|
||||
- name: Home
|
||||
default_target_temperature_low: 20 °C
|
||||
default_target_temperature_high: 22 °C
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -74,7 +77,6 @@ modes that Home Assistant offers.
|
|||
- platform: thermostat
|
||||
name: "Thermostat Climate Controller"
|
||||
sensor: my_temperature_sensor
|
||||
default_target_temperature_low: 20 °C
|
||||
min_heating_off_time: 300s
|
||||
min_heating_run_time: 300s
|
||||
min_idle_time: 30s
|
||||
|
|
@ -82,6 +84,11 @@ modes that Home Assistant offers.
|
|||
- switch.turn_on: heater
|
||||
idle_action:
|
||||
- switch.turn_off: heater
|
||||
default_preset: Home
|
||||
preset:
|
||||
- name: Home
|
||||
default_target_temperature_low: 20 °C
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -90,7 +97,6 @@ modes that Home Assistant offers.
|
|||
- platform: thermostat
|
||||
name: "Thermostat Climate Controller"
|
||||
sensor: my_temperature_sensor
|
||||
default_target_temperature_high: 22 °C
|
||||
min_cooling_off_time: 300s
|
||||
min_cooling_run_time: 300s
|
||||
min_idle_time: 30s
|
||||
|
|
@ -98,6 +104,11 @@ modes that Home Assistant offers.
|
|||
- switch.turn_on: air_cond
|
||||
idle_action:
|
||||
- switch.turn_off: air_cond
|
||||
default_preset: Home
|
||||
preset:
|
||||
- name: Home
|
||||
default_target_temperature_high: 22 °C
|
||||
|
||||
|
||||
|
||||
Controller Behavior and Hysteresis
|
||||
|
|
@ -163,7 +174,7 @@ Default Target Temperatures and Mode
|
|||
|
||||
These configuration items determine default values the thermostat controller should use when it starts.
|
||||
|
||||
- **default_mode** (*Optional*, *Deprecated*, climate mode): The default climate mode the controller should
|
||||
- **default_mode** (*Optional*, *Deprecated*, climate mode): The default climate mode the controller should
|
||||
use if it is unable to restore it from memory. One of:
|
||||
|
||||
- ``off`` (default)
|
||||
|
|
@ -173,16 +184,16 @@ These configuration items determine default values the thermostat controller sho
|
|||
- ``dry``
|
||||
- ``fan_only``
|
||||
- ``auto``
|
||||
|
||||
|
||||
This value is used the first time your device starts after ESPHome is initially installed onto it. Add
|
||||
this option into your configuration if you want your thermostat component to start in a climate mode other
|
||||
than ``off``. If this option is not configured, you'll need to manually change the climate mode later via
|
||||
the front end (Home Assistant), an ESPHome action, automation, or from within a lambda elsewhere in your
|
||||
device's configuration.
|
||||
|
||||
- **default_target_temperature_low** (*Optional*, *Deprecated*, float): The default low target
|
||||
- **default_target_temperature_low** (*Optional*, float): The default low target
|
||||
temperature for the control algorithm. This can be dynamically set in the frontend later.
|
||||
- **default_target_temperature_high** (*Optional*, *Deprecated*, float): The default high target
|
||||
- **default_target_temperature_high** (*Optional*, float): The default high target
|
||||
temperature for the control algorithm. This can be dynamically set in the frontend later.
|
||||
|
||||
**At least one of** ``default_target_temperature_low`` **and** ``default_target_temperature_high``
|
||||
|
|
@ -191,8 +202,8 @@ device's configuration.
|
|||
.. note::
|
||||
|
||||
**default_mode**, **default_target_temperature_low**, and **default_target_temperature_high** are
|
||||
deprecated and will be removed in a future release. You should migrate your configuration to using
|
||||
a :ref:`preset <thermostat-preset>` which allows for more flexibility and customisation
|
||||
being removed in a future release. In the future you will need to migrate your configuration to using
|
||||
a :ref:`preset <thermostat-preset>` which will allow for more flexibility and customisation
|
||||
|
||||
Note that ``min_temperature`` and ``max_temperature`` from the base climate component are used to define
|
||||
the range of allowed temperature values in the thermostat component. See :doc:`/components/climate/index`.
|
||||
|
|
@ -315,22 +326,6 @@ Set Point Options/Behavior
|
|||
- **supplemental_heating_delta** (*Required with* ``supplemental_heating_action``, float): When the temperature
|
||||
difference between the lower set point and the current temperature exceeds this value,
|
||||
``supplemental_heating_action`` will be called immediately.
|
||||
- **away_config** (*Optional*, *Deprecated*): Additionally specify target temperature range settings for away mode.
|
||||
Away mode can be used to have a second set of target temperatures (for example, while the user is
|
||||
away or sleeping/at night).
|
||||
|
||||
- **default_target_temperature_low** (*Optional*, float): The default low target temperature for the control
|
||||
algorithm when Away mode is selected. This can be dynamically set in the frontend later.
|
||||
- **default_target_temperature_high** (*Optional*, float): The default high target temperature for the control
|
||||
algorithm when Away mode is selected. This can be dynamically set in the frontend later.
|
||||
|
||||
**If configured, at least one of** ``default_target_temperature_low`` **and** ``default_target_temperature_high``
|
||||
**must be specified in the away mode configuration.**
|
||||
|
||||
.. note::
|
||||
|
||||
**away_config** is deprecated and will be removed in a future release. You should migrate your configuration
|
||||
to using a :ref:`preset <thermostat-preset>` which allows for more flexibility and customisation
|
||||
|
||||
.. _thermostat-preset:
|
||||
|
||||
|
|
@ -343,19 +338,19 @@ experience and automation.
|
|||
|
||||
- **preset**: (*Optional*, list)
|
||||
|
||||
- **name** (*Required*, string): Name of the preset. If this is one of the *standard* presets (``eco``, ``away``,
|
||||
- **name** (*Required*, string): Name of the preset. If this is one of the *standard* presets (``eco``, ``away``,
|
||||
``boost``, ``comfort``, ``home``, ``sleep``, or ``activity``) it is considered a *standard* preset. Any other
|
||||
string will make the preset a *custom* preset. *Standard* and *custom* presets are functionally equivalent,
|
||||
the only difference is that when switching the mode via :ref:`climate.control Action <climate-control_action>`
|
||||
you will need to use the `preset` or `custom_preset` property as appropriate. The Home Assistant
|
||||
you will need to use the `preset` or `custom_preset` property as appropriate. The Home Assistant
|
||||
`climate.set_preset_mode` service treats them identically
|
||||
- **default_target_temperature_low** (*Optional*, float): The default low target temperature when switching to
|
||||
- **default_target_temperature_low** (*Optional*, float): The default low target temperature when switching to
|
||||
this preset
|
||||
- **default_target_temperature_high** (*Optional*, float): The default high target temperature when switching
|
||||
to this preset.
|
||||
- **mode** (*Optional*, climate mode): The mode the thermostat should switch to when this preset is activated.
|
||||
If not specified, the thermostat's mode will remain unchanged when the preset is activated. One of:
|
||||
|
||||
|
||||
- ``heat_cool``
|
||||
- ``cool``
|
||||
- ``heat``
|
||||
|
|
@ -378,7 +373,7 @@ experience and automation.
|
|||
- **swing_mode** (*Optional*, climate swing mode): The fan swing mode the thermostat should switch to when this
|
||||
preset is activated. If not specified, the thermostat's fan swing mode will remain unchanged when the preset
|
||||
is activated. One of:
|
||||
|
||||
|
||||
- ``off``
|
||||
- ``both``
|
||||
- ``horizontal``
|
||||
|
|
@ -422,6 +417,67 @@ experience and automation.
|
|||
preset_change:
|
||||
- logger.log: Preset has been changed!
|
||||
|
||||
Default Preset
|
||||
**************
|
||||
|
||||
These configuration items determine default values the thermostat controller should use when it starts.
|
||||
|
||||
- **default_preset** (*Optional*, string): The name of the preset to use by default. Must match a preset
|
||||
as per :ref:`preset <thermostat-preset>`.
|
||||
- **on_boot_restore_from**: (*Optional*, on_boot_restore_from): Controls what the thermostat will do when
|
||||
it first boots. One of:
|
||||
|
||||
- ``memory`` (default): The thermostat will restore any settings from last time it was running.
|
||||
- ``default_preset``: The thermostat will always switch to the preset specified by **default_preset**
|
||||
|
||||
.. note::
|
||||
|
||||
You can specify a ``default_preset`` and set ``on_boot_restore_from`` to ``memory``. In this mode when
|
||||
the settings from last boot cannot be retrieved, for any reason, then the specified ``default_preset``
|
||||
will be applied.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# This climate controller, on first boot, will switch to "My Startup Preset". Subsequent boots would
|
||||
# restore to whatever mode it was in prior to the reboot
|
||||
climate:
|
||||
- platform: thermostat
|
||||
name: "From Memory Thermostat"
|
||||
default_preset: My Startup Preset
|
||||
on_boot_restore_from: memory
|
||||
preset:
|
||||
- name: My Startup Preset
|
||||
default_target_temperature_low: 17
|
||||
default_target_temperature_high: 26
|
||||
fan_mode: OFF
|
||||
swing_mode: OFF
|
||||
mode: OFF
|
||||
# Custom preset
|
||||
- name: A custom preset
|
||||
default_target_temperature_low: 21
|
||||
default_target_temperature_high: 23
|
||||
fan_mode: HIGH
|
||||
mode: HEAT_COOL
|
||||
|
||||
# This climate controller will always switch to "Every Start Preset"
|
||||
climate:
|
||||
- platform: thermostat
|
||||
name: "Default Preset Thermostat"
|
||||
default_preset: Every Start Preset
|
||||
on_boot_restore_from: default_preset
|
||||
preset:
|
||||
- name: Every Start Preset
|
||||
default_target_temperature_low: 17
|
||||
default_target_temperature_high: 26
|
||||
fan_mode: OFF
|
||||
swing_mode: OFF
|
||||
mode: OFF
|
||||
# Custom preset
|
||||
- name: A custom preset
|
||||
default_target_temperature_low: 21
|
||||
default_target_temperature_high: 23
|
||||
fan_mode: HIGH
|
||||
mode: HEAT_COOL
|
||||
|
||||
Additional Actions/Behavior
|
||||
***************************
|
||||
|
|
@ -487,7 +543,7 @@ Hysteresis Values
|
|||
|
||||
- While this platform uses the term temperature everywhere, it can also be used to regulate other values.
|
||||
For example, controlling humidity is also possible with this platform.
|
||||
- ``min_temperature`` and ``max_temperature`` from the base climate component are used the define the range of
|
||||
- ``min_temperature`` and ``max_temperature`` from the base climate component are used the define the range of
|
||||
adjustability and the defaults will probably not make sense for control of things like humidity. See
|
||||
:doc:`/components/climate/index`.
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Movement Sensors
|
|||
|
||||
If movement feedback is available, the cover no longer operates in *optimistic mode* (assuming that movement starts
|
||||
as soon as an action is triggered) and can also react to commands issued to cover from an external control and still
|
||||
keep states in sync (useful for "smartization" of and existing cover).
|
||||
keep states in sync (useful for "smartization" of an existing cover).
|
||||
|
||||
When there are no specific endstop sensors, and if the cover has builtin endstops and no external control logic,
|
||||
these movement sensors can optionally be use to infer the endstop state.
|
||||
|
|
@ -198,7 +198,7 @@ Most options can be left untouched, but some modifications are needed:
|
|||
id: open_binary_sensor
|
||||
sensor_id: open_current_sensor
|
||||
threshold: 0.5
|
||||
filter:
|
||||
filters:
|
||||
- delayed_off: 0.8s
|
||||
- platform: analog_threshold
|
||||
id: open_obstacle_binary_sensor
|
||||
|
|
|
|||
|
|
@ -200,7 +200,7 @@ Lambdas
|
|||
From :ref:`lambdas <config-lambda>`, you can access the current state of the cover (note that these
|
||||
fields are read-only, if you want to act on the cover, use the ``make_call()`` method as shown above).
|
||||
|
||||
- ``position``: Retrieve the current position of the cover, as a value between ``0.0`` (open) and ``1.0`` (closed).
|
||||
- ``position``: Retrieve the current position of the cover, as a value between ``0.0`` (closed) and ``1.0`` (open).
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
|
|
|
|||
|
|
@ -64,6 +64,13 @@ Configuration variables:
|
|||
The stop button on the UI is always enabled even when the cover is stopped and each press
|
||||
on the button will cause the ``stop_action`` to be performed.
|
||||
|
||||
.. note::
|
||||
|
||||
The state of the cover can be restored from flash after a node reboot, with
|
||||
``esp8266_restore_from_flash: true`` option set.
|
||||
See :doc:`esp8266_restore_from_flash </components/esphome>` for details.
|
||||
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 426 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
|
|
@ -149,10 +149,11 @@ 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! Granted the reason for it is actually not having to worry about the licensing of font files :)
|
||||
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`` file from somewhere on the internet and place it, for example,
|
||||
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:
|
||||
|
|
@ -169,12 +170,15 @@ Next, create a ``font:`` section in your configuration:
|
|||
id: roboto
|
||||
size: 20
|
||||
|
||||
- file: "fonts/tom-thumb.bdf"
|
||||
id: tomthumb
|
||||
|
||||
display:
|
||||
# ...
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **file** (**Required**): The path (relative to where the .yaml file is) of the TrueType font
|
||||
- **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``.
|
||||
|
|
@ -200,12 +204,13 @@ Configuration variables:
|
|||
|
||||
**Local Fonts**:
|
||||
|
||||
- **path** (**Required**, string): The path (relative to where the .yaml file is) of the TrueType font file.
|
||||
- **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. Defaults to ``20``.
|
||||
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
|
||||
|
|
@ -216,7 +221,7 @@ Configuration variables:
|
|||
.. note::
|
||||
|
||||
To use fonts you will need to have the python ``pillow`` package installed, as ESPHome uses that package
|
||||
to translate the TrueType files into an internal format. If you're running this as a Home Assistant
|
||||
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``.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ CS to your set ``cs_pin`` and finally GND to GND.
|
|||
|
||||
You can even daisy-chain multiple MAX7219s by connecting the DOUT of the previous chip in the chain to the
|
||||
next DIN. With more than ~3 chips the 3.3V will probably not be enough, so then you will have to potentially
|
||||
use a logic level converted.
|
||||
use a logic level converter.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,234 @@
|
|||
PVVX MiThermometer Display
|
||||
==========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up BLE devices with PVVX MiThermometer custom firmware as displays.
|
||||
:image: /components/sensor/images/xiaomi_lywsd03mmc.jpg
|
||||
|
||||
The ``pvvx_mithermometer`` display platform allows you to use devices running the `ATC_MiThermometer firmware <https://github.com/pvvx/ATC_MiThermometer>`__ by pvvx as display drivers with ESPHome.
|
||||
|
||||
.. figure:: /components/sensor/images/xiaomi_lywsd03mmc.jpg
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
Xiaomi LYWSD03MMC.
|
||||
|
||||
The data to be displayed is transmitted as external data via BLE.
|
||||
To do this, a ``ble_client`` component must be set up.
|
||||
This component can also synchronize the time of the pvvx device by transmitting a timestamp on each connection.
|
||||
After the data has been transmitted, the BLE connection is terminated in order to be able to receive the advertising data required for the ``pvvx_mithermometer`` sensor platform.
|
||||
|
||||
The pvvx firmware refreshes the screen periodically (can be set as minimum LCD refresh rate in the firmware configuration).
|
||||
By default, the internal sensor data and, if available and valid (``validity_period``), the external data are switched every 2.5 s.
|
||||
Further firmware configuration makes it possible to activate other display modes such as time and battery status.
|
||||
The firmware configuration can be changed via browser using `TelinkMiFlasher.html <https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html>`__.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_ble_tracker:
|
||||
|
||||
ble_client:
|
||||
- mac_address: "A4:C1:38:B1:CD:7F"
|
||||
id: pvvx_ble_display
|
||||
|
||||
display:
|
||||
- platform: pvvx_mithermometer
|
||||
ble_client_id: pvvx_ble_display
|
||||
lambda: |-
|
||||
it.print_bignum(23.1);
|
||||
it.print_unit(pvvx_mithermometer::UNIT_DEG_C);
|
||||
it.print_smallnum(33);
|
||||
it.print_percent(true);
|
||||
it.print_happy(true);
|
||||
it.print_bracket(true);
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **ble_client_id** (**Required**, :ref:`config-id`): ID of the associated BLE client.
|
||||
- **time_id** (*Optional*, :ref:`config-id`): ID of a :doc:`/components/time` component. If set, the time will be synchronized with every connection.
|
||||
- **disconnect_delay** (*Optional*, :ref:`config-time`): The amount of time the BLE connection is maintained before being disconnected again. Defaults to ``5s``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to transmit the display data. Defaults to ``60s``.
|
||||
- **validity_period** (*Optional*, :ref:`config-time`): The time periode for which the pvvx device should display the information. Defaults to ``5min``.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use to define the information to be displayed.
|
||||
See :ref:`display-pvvx_mithermometer_lambda` for more information.
|
||||
- **auto_clear_enabled** (*Optional*, boolean): Whether to automatically clear the display data before each lambda call,
|
||||
or to keep the existing display content (must overwrite explicitly, e.g., only on data change). Defaults to ``true``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
.. _display-pvvx_mithermometer_lambda:
|
||||
|
||||
Rendering Lambda
|
||||
----------------
|
||||
|
||||
The ``pvvx_mithermometer`` displays can only show two numbers with optional units and a smiley face. Therefore, the API is tailord to these limitations.
|
||||
In the lambda you're passed a variable called ``it`` as with all other displays. In this case however, ``it`` is a ``PVVXDisplay`` instance (see API Reference).
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: pvvx_mithermometer
|
||||
# ...
|
||||
lambda: |-
|
||||
// Print -2.1 as big number (first row)
|
||||
it.print_bignum(-2.1);
|
||||
// Print °C next to the big number
|
||||
it.print_unit(pvvx_mithermometer::UNIT_DEG_C);
|
||||
// Print 88 as small number (second row)
|
||||
it.print_smallnum(88);
|
||||
// Print % next to the small number
|
||||
it.print_percent(true);
|
||||
// Print the low battery symbol
|
||||
it.print_battery(true);
|
||||
|
||||
// Print a happy smiley. Results in " ^_^ "
|
||||
it.print_happy(true);
|
||||
// Print a sad smiley. Results in " -∧- "
|
||||
it.print_sad(true);
|
||||
// The comination of happy and sad simley results in " Δ△Δ "
|
||||
|
||||
// Print round brackets around the simley
|
||||
it.print_bracket(true);
|
||||
// The final result is "(Δ△Δ)"
|
||||
|
||||
|
||||
Valid values for the big number (``it.print_bignum()``) are from -99.5 to 1999.5. Smaller values are displayed as ``Lo``, larger ones as ``Hi``. It will be printed to the screen. If not defined, a 0 will be displayed.
|
||||
|
||||
Valid values for the small number (``it.print_smallnum()``) are from -9 to 99. Smaller values are displayed as ``Lo``, larger ones as ``Hi``. If not defined, a 0 will be displayed.
|
||||
|
||||
Possible values for the unit of the big number (``it.print_unit()``) are:
|
||||
|
||||
- ``pvvx_mithermometer::UNIT_NONE``: do not show a unit
|
||||
- ``pvvx_mithermometer::UNIT_DEG_GHE``: show ``°Г``
|
||||
- ``pvvx_mithermometer::UNIT_MINUS``: show ``-``
|
||||
- ``pvvx_mithermometer::UNIT_DEG_F``: show ``°F``
|
||||
- ``pvvx_mithermometer::UNIT_LOWDASH``: show ``_``
|
||||
- ``pvvx_mithermometer::UNIT_DEG_C``: show ``°C``
|
||||
- ``pvvx_mithermometer::UNIT_LINES``: show ``=``
|
||||
- ``pvvx_mithermometer::UNIT_DEG_E``: show ``°E``
|
||||
|
||||
The appearance of the smiley can be defined by combining the functions ``it.print_happy()``, ``it.print_sad()`` and ``it.print_bracket(true)``:
|
||||
|
||||
=================== =============== ================= ==========
|
||||
``print_bracket()`` ``print_sad()`` ``print_happy()`` result
|
||||
=================== =============== ================= ==========
|
||||
false false false
|
||||
false false true ``^_^``
|
||||
false true false ``-∧-``
|
||||
false true true ``Δ△Δ``
|
||||
true false false ``( )``
|
||||
true false true ``(^_^)``
|
||||
true true false ``(-∧-)``
|
||||
true true true ``(Δ△Δ)``
|
||||
=================== =============== ================= ==========
|
||||
|
||||
|
||||
Display states of other sensors
|
||||
*******************************
|
||||
|
||||
The following example display the sensor states of a MiFlora sensor on a pvvx display. The time is also synchronized.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
time:
|
||||
- platform: homeassistant
|
||||
id: homeassistant_time
|
||||
|
||||
esp32_ble_tracker:
|
||||
|
||||
ble_client:
|
||||
- mac_address: "A4:C1:38:B1:CD:7F"
|
||||
id: pvvx_ble_display
|
||||
|
||||
sensor:
|
||||
- platform: pvvx_mithermometer
|
||||
mac_address: "A4:C1:38:B1:CD:7F"
|
||||
temperature:
|
||||
name: "PVVX Temperature"
|
||||
humidity:
|
||||
name: "PVVX Humidity"
|
||||
battery_level:
|
||||
name: "PVVX Battery-Level"
|
||||
battery_voltage:
|
||||
name: "PVVX Battery-Voltage"
|
||||
- platform: xiaomi_hhccjcy01
|
||||
mac_address: '94:2B:FF:5C:91:61'
|
||||
temperature:
|
||||
name: "Xiaomi HHCCJCY01 Temperature"
|
||||
id: miflora_temperature
|
||||
moisture:
|
||||
name: "Xiaomi HHCCJCY01 Moisture"
|
||||
id: miflora_moisture
|
||||
illuminance:
|
||||
name: "Xiaomi HHCCJCY01 Illuminance"
|
||||
conductivity:
|
||||
name: "Xiaomi HHCCJCY01 Soil Conductivity"
|
||||
|
||||
display:
|
||||
- platform: pvvx_mithermometer
|
||||
ble_client_id: pvvx_ble_display
|
||||
update_interval: 10min
|
||||
validity_period: 15min
|
||||
time_id: homeassistant_time
|
||||
lambda: |-
|
||||
double temp = id(miflora_temperature).state;
|
||||
double moisture = id(miflora_moisture).state;
|
||||
it.print_bignum(temp);
|
||||
it.print_unit(pvvx_mithermometer::UNIT_DEG_C);
|
||||
it.print_smallnum(moisture);
|
||||
it.print_percent();
|
||||
if (temp < 5 || temp > 30 || moisture < 10 || moisture > 50) {
|
||||
it.print_sad();
|
||||
} else {
|
||||
it.print_happy();
|
||||
}
|
||||
|
||||
Only synchronize the time once a day
|
||||
************************************
|
||||
|
||||
The following example will synchronized the time of the pvvx device once a day.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
time:
|
||||
- platform: homeassistant
|
||||
id: homeassistant_time
|
||||
|
||||
esp32_ble_tracker:
|
||||
|
||||
ble_client:
|
||||
- mac_address: "A4:C1:38:B1:CD:7F"
|
||||
id: pvvx_ble_display
|
||||
|
||||
sensor:
|
||||
- platform: pvvx_mithermometer
|
||||
mac_address: "A4:C1:38:B1:CD:7F"
|
||||
temperature:
|
||||
name: "PVVX Temperature"
|
||||
humidity:
|
||||
name: "PVVX Humidity"
|
||||
battery_level:
|
||||
name: "PVVX Battery-Level"
|
||||
battery_voltage:
|
||||
name: "PVVX Battery-Voltage"
|
||||
|
||||
display:
|
||||
- platform: pvvx_mithermometer
|
||||
ble_client_id: pvvx_ble_display
|
||||
update_interval: 24h
|
||||
validity_period: 0s
|
||||
time_id: homeassistant_time
|
||||
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`index`
|
||||
- :doc:`/components/ble_client`
|
||||
- :doc:`/components/sensor/xiaomi_ble`
|
||||
- :apiref:`pvvx_mithermometer/display/pvvx_display.h`
|
||||
- `ATC_MiThermometer firmware <https://github.com/pvvx/ATC_MiThermometer>`__ by `pvvx <https://github.com/pvvx>`__
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -63,7 +63,7 @@ Configuration variables:
|
|||
- ``Adafruit RR 280x240`` (round-rectangular display -- some pixels are "deleted" from corners to form rounded shape)
|
||||
- ``Custom`` (see details below)
|
||||
|
||||
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The CS pin.
|
||||
- **cs_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The CS pin.
|
||||
- **dc_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The DC pin.
|
||||
- **reset_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
|
||||
- **height** (*Optional*, int): When ``model`` is set to "Custom", use this to specify the ``height`` of the display
|
||||
|
|
|
|||
|
|
@ -0,0 +1,92 @@
|
|||
TM1621 LCD Display
|
||||
========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up TM1621 LCD Display.
|
||||
:image: tm1621.jpg
|
||||
|
||||
The ``tm1621`` display platform allows you to use the popular TM1621 LCD display drivers with ESPHome, that can find in Sonoff device like THR316D, THR320D, POWR316D or POWR320D
|
||||
|
||||
.. figure:: images/tm1621-full.jpg
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
TM1621 LCD Display.
|
||||
|
||||
The LCD have four signal, ``cs`` for chip select, ``data`` for data signal, ``read`` for reading data dir and ``write`` for writing data dir
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
display:
|
||||
platform: tm1621
|
||||
id: tm1621_display
|
||||
cs_pin: GPIO17
|
||||
data_pin: GPIO5
|
||||
read_pin: GPIO23
|
||||
write_pin: GPIO18
|
||||
lambda: |-
|
||||
it.printf(0, "%.1f", id(my_sensor1).state);
|
||||
it.display_celsius(true);
|
||||
it.printf(1, "%.1f", id(my_sensor2).state);
|
||||
it.display_humidity(true);
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin you have the CS line.
|
||||
- **data_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin you have the DATA line.
|
||||
- **read_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin you have the READ line.
|
||||
- **write_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin you have the WRITE line.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the TM1621.
|
||||
See :ref:`display-tm1621_lambda` for more information.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``1s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
.. _display-tm1621_lambda:
|
||||
|
||||
Rendering Lambda
|
||||
----------------
|
||||
|
||||
The TM1621 has a similar API to the fully fledged :ref:`display-engine`, but it's only a subset as the TM1621
|
||||
LCD displays don't have a concept of individual pixels. In the lambda you're passed a variable called ``it``
|
||||
as with all other displays. In this case however, ``it`` is a TM1621 instance (see API Reference).
|
||||
|
||||
The most basic operation with the TM1621 is wiring a simple number to the screen as in the configuration example
|
||||
at the top of this page. But even though you're passing in a string (here ``"0123"``), ESPHome converts it
|
||||
into a representation that the TM1621 can understand.
|
||||
|
||||
Each of the three methods (``print`` and ``printf``) all optionally take a the line number (0 for first line and 1 for the second).
|
||||
This argument is ``0`` by default.
|
||||
|
||||
Also note that the ``.`` (dot) character is special because when ESPHome encounters it in the string the dot
|
||||
segment of the previous position will be enabled.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: tm1621
|
||||
# ...
|
||||
lambda: |-
|
||||
it.printf(0, "%.1f", id(my_sensor1).state);
|
||||
it.display_celsius(true);
|
||||
it.printf(1, "%.1f", id(my_sensor2).state);
|
||||
it.display_humidity(true);
|
||||
|
||||
|
||||
Please see :ref:`display-printf` for a quick introduction into the ``printf`` formatting rules.
|
||||
|
||||
Also we have five function to display or not some unites:
|
||||
- °C on the first line : ``display_celsius(bool)``
|
||||
- °F on the first line : ``display_fahrenheit(bool)``
|
||||
- %HR on the second line : ``display_humidity(bool)``
|
||||
- V on the first line and A on the second line : ``display_voltage(bool)``
|
||||
- kW/h on the first line and W on the second line : ``display_kwh(bool)``
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`index`
|
||||
- :apiref:`tm1621/tm1621.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -0,0 +1,188 @@
|
|||
TM1638 7 Segment Display Keypad & LED Module
|
||||
============================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up TM1638 7 Segment Display Keypad & LED Module
|
||||
:image: tm1638.jpg
|
||||
|
||||
The ``tm1638`` display platform allows you to use the popular TM1638 7 Segment Display Keypad & LED Module with ESPHome.
|
||||
|
||||
.. figure:: images/tm1638-full.jpg
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
TM1638 8-Segment Display Keypad & LED Module.
|
||||
|
||||
The module can be powered with 5v DC. To display the colon punctuation use the
|
||||
``.`` in the colon place. (See clock example below)
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
display:
|
||||
platform: tm1638
|
||||
id: tm1638_display
|
||||
stb_pin: 5
|
||||
clk_pin: 18
|
||||
dio_pin: 23
|
||||
intensity: 5
|
||||
update_interval: 5s
|
||||
lambda: |-
|
||||
it.print("0123");
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **stb_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin you have the STB line hooked up to.
|
||||
- **clk_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin you have the CLK line hooked up to.
|
||||
- **dio_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin you have the DIO line hooked up to.
|
||||
- **intensity** (*Optional*, int): The intensity with which the TM1638 should drive the outputs. Range is from
|
||||
0 (least intense) to 7 (the default). This setting will affect the 7 segment display and the 8 individual LED lights.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the TM1638.
|
||||
See :ref:`display-tm1638_lambda` for more information.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``1s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
.. _display-tm1638_lambda:
|
||||
|
||||
Rendering Lambda
|
||||
----------------
|
||||
|
||||
The TM1638 has a similar API to the fully fledged :ref:`display-engine`, but it's only a subset as the TM1638
|
||||
7-segment Display Keypad & LED Module does not have a concept of individual pixels. In the lambda you're passed a variable called ``it``
|
||||
as with all other displays. In this case however, ``it`` is a TM1638 instance (see API Reference).
|
||||
|
||||
The most basic operation with the TM1638 is writing a simple number to the screen as in the configuration example
|
||||
at the top of this page. But even though you're passing in a string (here ``"0123"``), ESPHome converts it
|
||||
into a representation that the TM1638 can understand: The exact pixels that should be turned on. And of course,
|
||||
not all characters can be represented. You can see a full list of characters :ref:`at the MAX7219 docs <display-max7219_characters>`.
|
||||
|
||||
Each of the three methods (``print``, ``printf`` and ``strftime``) all optionally take a position argument at the
|
||||
beginning which can be used to print the text at a specific position. This argument is ``0`` by default which
|
||||
means the first character of the first TM1638. For example to start the first character of your text at
|
||||
the end of the TM1638, you would write ``it.print(3, "0");``.
|
||||
|
||||
Also note that the ``.`` (dot) character is special because when ESPHome encounters it in the string the dot
|
||||
segment of the previous position will be enabled.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: tm1638
|
||||
# ...
|
||||
lambda: |-
|
||||
// Print 0 at position 0 (left)
|
||||
it.print("0");
|
||||
// Result: "0 "
|
||||
|
||||
// Print 1 at position 1 (second character)
|
||||
it.print(1, "1");
|
||||
// Result: "01 "
|
||||
|
||||
// Let's write a sensor value (let's assume it's 42.1)
|
||||
it.printf(0, "%.1f", id(my_sensor).state);
|
||||
// Result: "42.1 " (the dot will appear on the "2" segment)
|
||||
|
||||
// Overwrite the previous content with blank
|
||||
it.print(" ");
|
||||
// Print a right-padded sensor value with 0 digits after the decimal
|
||||
it.printf("S%3.0f", id(my_sensor).state);
|
||||
// Result: "S 42"
|
||||
|
||||
// Print the current time
|
||||
it.strftime("%H.%M");
|
||||
// Result for 10:06:42 -> "10:06" on a display with : and "10.06" on a display with .
|
||||
|
||||
Please see :ref:`display-printf` for a quick introduction into the ``printf`` formatting rules and
|
||||
:ref:`display-strftime` for an introduction into the ``strftime`` time formatting.
|
||||
|
||||
Creating a digital clock
|
||||
************************
|
||||
|
||||
The following example creates a typical digital clock with the ``:`` colon flashing every second.
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
||||
time:
|
||||
- platform: homeassistant
|
||||
id: homeassistant_time
|
||||
|
||||
display:
|
||||
platform: tm1638
|
||||
clk_pin: 18
|
||||
dio_pin: 23
|
||||
stb_pin: 5
|
||||
update_interval: 500ms
|
||||
lambda: |-
|
||||
static int i = 0;
|
||||
i++;
|
||||
if ((i % 2) == 0)
|
||||
it.strftime("%H.%M", id(homeassistant_time).now());
|
||||
else
|
||||
it.strftime("%H%M", id(homeassistant_time).now());
|
||||
|
||||
|
||||
LEDs
|
||||
----------------
|
||||
The TM1638 7 Segment Display Keypad & LED Module has 8 LED lights across the top or middle of the display, depending on the board. These LEDs can be exposed as :doc:`switches </components/switch/index>` or :doc:`outputs </components/output/index>` with the led property set between 0 and 7. The board has the LEDs labelled 1-8, but the leds use zero based addressing. The LED labelled "1" is LED 0 in the configuration.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
switch:
|
||||
- platform: tm1638
|
||||
id: TM1638Led1
|
||||
led: 0
|
||||
|
||||
output:
|
||||
- platform: tm1638
|
||||
id: TM1638Led2
|
||||
led: 1
|
||||
|
||||
|
||||
|
||||
Buttons
|
||||
----------------
|
||||
The TM1638 7 Segment Display Keypad & LED Module has 8 buttons across the top or middle of the display, depending on the board. These buttons are exposed as binary sensor components with the key property set between 0 and 7, They can be accessed via the binary sensor component configuration. As with the LEDs the buttons are labeled 1-8 on the board, but use zero based addressing. Therefore the button labelled "1" is key 0 in the configuration. See :doc:`/components/binary_sensor/index`
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: tm1638
|
||||
name: "TM1638 Button 1"
|
||||
id: TM1638Button1
|
||||
key: 0
|
||||
filters:
|
||||
- delayed_on: 10ms
|
||||
on_press:
|
||||
then:
|
||||
- switch.turn_on: TM1638Led1
|
||||
on_release:
|
||||
then:
|
||||
- switch.turn_off: TM1638Led1
|
||||
|
||||
- platform: tm1638
|
||||
name: "TM1638 Button 2"
|
||||
id: TM1638Button2
|
||||
key: 1
|
||||
filters:
|
||||
- delayed_on: 10ms
|
||||
on_press:
|
||||
then:
|
||||
- output.turn_on: TM1638Led2
|
||||
on_release:
|
||||
then:
|
||||
- output.turn_off: TM1638Led2
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`index`
|
||||
- :doc:`/components/switch/index`
|
||||
- :doc:`/components/binary_sensor/index`
|
||||
- :apiref:`tm1638/tm1638.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -72,7 +72,10 @@ Configuration variables:
|
|||
impact on the device but can be used to debug the BLE stack. Defaults to ``5min``.
|
||||
- **active** (*Optional*, boolean): Whether to actively send scan requests to request more data
|
||||
after having received an advertising packet. With some devices this is necessary to receive all data,
|
||||
but also drains those devices' power a (tiny) bit more. Defaults to ``true``.
|
||||
but also drains those devices' power a bit more. Some devices don't need this, in that case
|
||||
you can save power and RF pollution by setting it to ``false``. Defaults to ``true``.
|
||||
- **continuous** (*Optional*, boolean): Whether to scan continuously (forever) or to only scan when
|
||||
asked to start a scan (with start_scan action). Defaults to ``true``.
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this ESP32 BLE Hub.
|
||||
|
||||
|
|
@ -86,14 +89,17 @@ Automations:
|
|||
- **on_ble_service_data_advertise** (*Optional*, :ref:`Automation <automation>`): An automation to
|
||||
perform when a Bluetooth advertising with service data is received. See
|
||||
:ref:`esp32_ble_tracker-on_ble_service_data_advertise`.
|
||||
- **on_scan_end** (*Optional*, :ref:`Automation <automation>`): An automation to perform when
|
||||
a BLE scan has completed (the duration of the scan). This works with continuous set to true or false.
|
||||
|
||||
|
||||
ESP32 Bluetooth Low Energy Tracker Automation
|
||||
---------------------------------------------
|
||||
|
||||
.. _esp32_ble_tracker-on_ble_advertise:
|
||||
|
||||
``on_ble_advertise``
|
||||
********************
|
||||
``on_ble_advertise`` Trigger
|
||||
************************************************
|
||||
|
||||
This automation will be triggered when a Bluetooth advertising is received. A variable ``x`` of type
|
||||
:apiclass:`esp32_ble_tracker::ESPBTDevice` is passed to the automation for use in lambdas.
|
||||
|
|
@ -128,8 +134,8 @@ Configuration variables:
|
|||
|
||||
.. _esp32_ble_tracker-on_ble_manufacturer_data_advertise:
|
||||
|
||||
``on_ble_manufacturer_data_advertise``
|
||||
**************************************
|
||||
``on_ble_manufacturer_data_advertise`` Trigger
|
||||
************************************************
|
||||
|
||||
This automation will be triggered when a Bluetooth advertising with manufcaturer data is received. A
|
||||
variable ``x`` of type ``std::vector<uint8_t>`` is passed to the automation for use in lambdas.
|
||||
|
|
@ -159,8 +165,8 @@ Configuration variables:
|
|||
|
||||
.. _esp32_ble_tracker-on_ble_service_data_advertise:
|
||||
|
||||
``on_ble_service_data_advertise``
|
||||
*********************************
|
||||
``on_ble_service_data_advertise`` Trigger
|
||||
************************************************
|
||||
|
||||
This automation will be triggered when a Bluetooth advertising with service data is received. A
|
||||
variable ``x`` of type ``std::vector<uint8_t>`` is passed to the automation for use in lambdas.
|
||||
|
|
@ -185,10 +191,82 @@ Configuration variables:
|
|||
- **service_uuid** (**Required**, string): 16 bit, 32 bit, or 128 bit BLE Service UUID.
|
||||
- See :ref:`Automation <automation>`.
|
||||
|
||||
``on_scan_end`` Trigger
|
||||
************************************************
|
||||
|
||||
This automation will be triggered when a Bluetooth scanning sequence has completed. If running
|
||||
with continuous set to true, this will trigger every time the scan completes (the duration of
|
||||
a scan).
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
esp32_ble_tracker:
|
||||
on_scan_end:
|
||||
- then:
|
||||
- lambda: |-
|
||||
ESP_LOGD("ble_auto", "The scan has ended!");
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- None
|
||||
|
||||
- See :ref:`Automation <automation>`.
|
||||
|
||||
``esp32_ble_tracker.start_scan`` Action
|
||||
************************************************
|
||||
|
||||
Start a Bluetooth scan. If there is a scan already in progress, then the action is ignored.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
esp32_ble_tracker:
|
||||
scan_parameters:
|
||||
continuous: false
|
||||
|
||||
on_...:
|
||||
- esp32_ble_tracker.start_scan:
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **continuous** (*Optional*, boolean): Whether to start the scan in continuous mode. Defaults to ``false``
|
||||
|
||||
.. note::
|
||||
|
||||
This action can also be written in :ref:`lambdas <config-lambda>`:
|
||||
.. code-block:: yaml
|
||||
|
||||
esp32_ble_tracker:
|
||||
id: ble_tracker_id
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
id(ble_tracker_id).start_scan()
|
||||
|
||||
``esp32_ble_tracker.stop_scan`` Action
|
||||
************************************************
|
||||
|
||||
Stops the bluetooth scanning. It can be started again with the above start scan action.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
esp32_ble_tracker:
|
||||
|
||||
on_...:
|
||||
- esp32_ble_tracker.stop_scan:
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`binary_sensor/ble_presence`
|
||||
- :doc:`text_sensor/ble_scanner`
|
||||
- :doc:`sensor/ble_rssi`
|
||||
- :doc:`sensor/b_parasite`
|
||||
- :doc:`sensor/xiaomi_ble`
|
||||
- :doc:`sensor/xiaomi_miscale`
|
||||
- :doc:`sensor/inkbird_ibsth1_mini`
|
||||
- :doc:`sensor/mopeka_pro_check`
|
||||
- :doc:`sensor/ruuvitag`
|
||||
- :doc:`ble_client`
|
||||
- :doc:`bluetooth_proxy`
|
||||
- :apiref:`esp32_ble_tracker/esp32_ble_tracker.h`
|
||||
- `ESP32 BLE for Arduino <https://github.com/nkolban/ESP32_BLE_Arduino>`__ by `Neil Kolban <https://github.com/nkolban>`__.
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ Automations:
|
|||
|
||||
- **on_stream_start** (*Optional*, :ref:`Automation <automation>`): An automation to perform
|
||||
when a stream starts.
|
||||
- **on_stream_end** (*Optional*, :ref:`Automation <automation>`): An automation to perform
|
||||
- **on_stream_stop** (*Optional*, :ref:`Automation <automation>`): An automation to perform
|
||||
when a stream stops.
|
||||
|
||||
Test Setting:
|
||||
|
|
|
|||
|
|
@ -50,6 +50,8 @@ Advanced options:
|
|||
|
||||
- **name** (**Required**, string): Name of the project
|
||||
- **version** (**Required**, string): Version of the project
|
||||
- **min_version** (*Optional*, string): The minimum ESPHome version required to compile this configuration.
|
||||
See :ref:`esphome-min_version`.
|
||||
|
||||
Old-style platform options, which have been moved to the platform-specific :doc:`esp32 </components/esp32>` and
|
||||
:doc:`esp8266 </components/esp8266>` sections but are still accepted here for compatibility reasons (usage not
|
||||
|
|
@ -129,11 +131,11 @@ too many WiFi/MQTT connection attempts, Over-The-Air updates being applied or th
|
|||
Configuration variables:
|
||||
|
||||
- **priority** (*Optional*, float): The priority to execute your custom shutdown code. A higher value
|
||||
means a high priority and in case of shutdown triggers that the code is executed **later**.
|
||||
means a high priority and in case of shutdown triggers that the code is executed **later**.
|
||||
Priority is used primarily for the initialization order of components. Shutdowns for these components are handled in *reverse* order, such that e.g. sensors (600) are shutdown before the hardware components (800) they depend on.
|
||||
Please note this is an ESPHome-internal value and any change will not be marked as a breaking change.
|
||||
Please note this is an ESPHome-internal value and any change will not be marked as a breaking change.
|
||||
Defaults to ``600``. For priority values refer to the list in the :ref:`esphome-on_boot` section.
|
||||
|
||||
|
||||
- See :ref:`Automation <automation>`.
|
||||
|
||||
.. _esphome-on_loop:
|
||||
|
|
@ -337,6 +339,14 @@ should be ``author_name.project_name``.
|
|||
name: "jesse.leds_party"
|
||||
version: "1.0.0"
|
||||
|
||||
.. _esphome-min_version:
|
||||
|
||||
Minimum ESPHome version
|
||||
-----------------------
|
||||
|
||||
This allows YAML files to specify the minimum version of ESPHome required to compile.
|
||||
This is useful in the case of packages where a published package might use features only
|
||||
available in a newer version of ESPHome. This allows for a more friendly error message.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -6,9 +6,11 @@ Ethernet Component
|
|||
:image: ethernet.svg
|
||||
:keywords: Ethernet, ESP32
|
||||
|
||||
This core ESPHome component sets up ethernet connections for ESP32s.
|
||||
This ESPHome component enables *wired* Ethernet connections for ESP32s.
|
||||
|
||||
Ethernet for ESP8266 is not supported.
|
||||
This component can't be used in same time than Wifi one, even if your ESP32 has both wired.
|
||||
|
||||
This component and the Wi-Fi component may **not** be used simultaneously, even if both are physically available.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -29,24 +31,23 @@ This component can't be used in same time than Wifi one, even if your ESP32 has
|
|||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **type** (**Required**, string): The type of LAN chipset. Must be one of
|
||||
``LAN8720`` or ``TLK110`` (see datasheet for more details).
|
||||
- **type** (**Required**, string): The type of LAN chipset/phy. Must be one of
|
||||
``LAN8720``, ``TLK110`` or ``IP101`` (see datasheet for more details).
|
||||
- **mdc_pin** (**Required**, :ref:`config-pin`): The MDC pin of the board.
|
||||
Usually this is ``GPIO23``.
|
||||
- **mdio_pin** (**Required**, :ref:`config-pin`): The MDIO pin of the board.
|
||||
Usually this is ``GPIO18``.
|
||||
- **clk_mode** (*Optional*, string): The clock mode of the data lines, this must be one
|
||||
of these values: (see datasheet of your board for more details)
|
||||
- **clk_mode** (*Optional*, string): The clock mode of the data lines. See your board's
|
||||
datasheet for more details. Must be one of the following values:
|
||||
|
||||
- ``GPIO0_IN`` (Default) - External clock
|
||||
- ``GPIO0_OUT`` - Internal clock
|
||||
- ``GPIO16_OUT`` - Internal clock
|
||||
- ``GPIO17_OUT`` - Internal clock
|
||||
|
||||
- **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 with which
|
||||
to control the power of the board. Leave unspecified for no power pin (default)
|
||||
|
||||
- **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).
|
||||
- **manual_ip** (*Optional*): Manually configure the static IP of the node.
|
||||
|
||||
- **static_ip** (**Required**, IPv4 address): The static IP of your node.
|
||||
|
|
@ -66,9 +67,10 @@ Configuration variables:
|
|||
|
||||
.. note::
|
||||
|
||||
If your ethernet board is not designed with an ESP32 built in, chances are that you are going
|
||||
to use flying leads, dupont wires, etc. to connect the ethernet to the ESP32. This is
|
||||
probably to fail as the ethernet interface uses a high frequency clock signal. For more
|
||||
If your Ethernet board is not designed with an ESP32 built in, it's common to attempt
|
||||
to use flying leads, dupont wires, etc. to connect the Ethernet controller to the ESP32.
|
||||
This approach is likely to fail, however, as the Ethernet interface uses a high frequency
|
||||
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.
|
||||
|
||||
Configuration for Olimex ESP32-POE
|
||||
|
|
@ -151,7 +153,7 @@ Configuration for OpenHacks LAN8720
|
|||
program properly.
|
||||
|
||||
Configuration for wESP32 board (up to rev.6)
|
||||
-------------------------------------------------
|
||||
--------------------------------------------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -167,6 +169,19 @@ Configuration for wESP32 board (up to rev.6)
|
|||
Revision 7 and upwards of the wESP32 board does not have a LAN8720 chip. Until support for the
|
||||
replacement RTL8201 is included in ESPHome, the wESP board rev.7 will not work with the above configuration.
|
||||
|
||||
Configuration for ESP32-Ethernet-Kit board
|
||||
------------------------------------------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
ethernet:
|
||||
type: IP101
|
||||
mdc_pin: GPIO23
|
||||
mdio_pin: GPIO18
|
||||
clk_mode: GPIO0_IN
|
||||
phy_addr: 1
|
||||
power_pin: GPIO5
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ nearby COVID-19 exposure notification bluetooth messages sent by phones running
|
|||
then:
|
||||
- lambda: |
|
||||
ESP_LOGD("main", "Got notification:");
|
||||
ESP_LOGD("main", " RPI: %s", hexencode(x.rolling_proximity_identifier).c_str());
|
||||
ESP_LOGD("main", " RPI: %s", format_hex_pretty(x.rolling_proximity_identifier).c_str());
|
||||
ESP_LOGD("main", " RSSI: %d", x.rssi);
|
||||
|
||||
Configuration variables:
|
||||
|
|
@ -67,7 +67,7 @@ minute, the indicator will be on.
|
|||
then:
|
||||
- lambda: |
|
||||
ESP_LOGD("main", "Got notification:");
|
||||
ESP_LOGD("main", " RPI: %s", hexencode(x.rolling_proximity_identifier).c_str());
|
||||
ESP_LOGD("main", " RPI: %s", format_hex_pretty(x.rolling_proximity_identifier).c_str());
|
||||
ESP_LOGD("main", " RSSI: %d", x.rssi);
|
||||
|
||||
# Stop existing timer so that turn_off doesn't get called
|
||||
|
|
|
|||
|
|
@ -6,9 +6,10 @@ Logger Component
|
|||
:image: file-document-box.svg
|
||||
|
||||
The logger component automatically logs all log messages through the
|
||||
serial port and through MQTT topics. By default, all logs with a
|
||||
severity higher than ``DEBUG`` will be shown. Decreasing the log level
|
||||
can help with the performance of the application and memory size.
|
||||
serial port and through MQTT topics (if there is an MQTT client in the
|
||||
configuration). By default, all logs with a severity higher than
|
||||
``DEBUG`` will be shown. Decreasing the log level can help with the
|
||||
performance of the application and memory size.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -54,7 +55,9 @@ The logger component makes use of platform-specific hardware UARTs for serial lo
|
|||
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.
|
||||
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.
|
||||
|
||||
Possible Hardware UART configurations:
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ via the I2S bus. This platform only works on ESP32 based chips.
|
|||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **dac_type** (**Required**, enum)
|
||||
- **dac_type** (**Required**, enum):
|
||||
|
||||
- ``external``: Use an external DAC, for example the NS4168, or UDA1334A.
|
||||
- ``internal``: Use the internal DAC
|
||||
|
|
|
|||
|
|
@ -290,6 +290,21 @@ You have to download the server CA certficiate in PEM format and add it to ``cer
|
|||
Usually these are .crt files and you can open them with any text editor.
|
||||
Also make sure to change the ``port`` of the mqtt broker. Most brokers use port 8883 for TLS connections.
|
||||
|
||||
.. warning::
|
||||
|
||||
MbedTLS, the library that handles TLS for the esp-idf, doesn't validate wildcard certificates.
|
||||
|
||||
The Common Name check only works if the CN is explicitly reported in the certificate.
|
||||
|
||||
- \*.example.com -> Fail
|
||||
- mqtt.example.com -> Success
|
||||
|
||||
If a secure connection is necessary for your device, you really want to set:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
skip_cert_cn_check: false
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
mqtt:
|
||||
|
|
@ -298,6 +313,7 @@ Also make sure to change the ``port`` of the mqtt broker. Most brokers use port
|
|||
discovery: true
|
||||
discovery_prefix: ${mqtt_prefix}/homeassistant
|
||||
log_topic: ${mqtt_prefix}/logs
|
||||
# Evaluate carefully skip_cert_cn_check
|
||||
skip_cert_cn_check: true
|
||||
idf_send_async: false
|
||||
certificate_authority: |
|
||||
|
|
|
|||
|
|
@ -309,8 +309,8 @@ advanced stuff (see the full API Reference for more info).
|
|||
call.perform();
|
||||
|
||||
Check the API reference for information on the methods that are available for
|
||||
the ``NumberCall`` object. You can for example also use ``call.to_min()``
|
||||
to set the number to its minimum value or ``call.increment(true)`` to increment
|
||||
the ``NumberCall`` object. You can for example also use ``call.number_to_min()``
|
||||
to set the number to its minimum value or ``call.number_increment(true)`` to increment
|
||||
the number by its step size with the cycle feature enabled.
|
||||
|
||||
- ``.state``: Retrieve the current value of the number. Is ``NAN`` if no value has been read or set.
|
||||
|
|
|
|||
|
|
@ -177,6 +177,9 @@ enum. These values are:
|
|||
Updating the password:
|
||||
----------------------
|
||||
|
||||
Changing an existing password:
|
||||
******************************
|
||||
|
||||
Since the password is used both for compiling and uploading the regular ``esphome <file> run``
|
||||
won't work of course. This issue can be worked around by executing the operations separately
|
||||
through an ``on_boot`` trigger:
|
||||
|
|
@ -191,6 +194,12 @@ through an ``on_boot`` trigger:
|
|||
password: "Old password"
|
||||
id: my_ota
|
||||
|
||||
Adding a password:
|
||||
******************
|
||||
|
||||
If OTA is already enabled without a password, simply add a ``password:`` line to the existing
|
||||
``ota:`` config block.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
|
|
|
|||
|
|
@ -45,8 +45,8 @@ Configuration variables:
|
|||
|
||||
.. _dac7678-output:
|
||||
|
||||
DAC Output
|
||||
----------
|
||||
DAC7678 Output
|
||||
--------------
|
||||
|
||||
The DAC7678 output component exposes a DAC7678 DAC channel of a global
|
||||
:ref:`DAC7678 hub <dac7678-component>` as a float
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ This action turns the output with the given ID on when executed.
|
|||
|
||||
on_...:
|
||||
then:
|
||||
- output.turn_on: relay_1
|
||||
- output.turn_on: light_1
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ This action turns the output with the given ID on when executed.
|
|||
|
||||
.. code-block:: cpp
|
||||
|
||||
id(relay_1).turn_on();
|
||||
id(light_1).turn_on();
|
||||
|
||||
.. _output-turn_off_action:
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ This action turns the output with the given ID off when executed.
|
|||
|
||||
on_...:
|
||||
then:
|
||||
- output.turn_off: relay_1
|
||||
- output.turn_off: light_1
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -90,7 +90,7 @@ This action turns the output with the given ID off when executed.
|
|||
|
||||
.. code-block:: cpp
|
||||
|
||||
id(relay_1).turn_off();
|
||||
id(light_1).turn_off();
|
||||
|
||||
.. _output-set_level_action:
|
||||
|
||||
|
|
@ -98,14 +98,14 @@ This action turns the output with the given ID off when executed.
|
|||
***************************
|
||||
|
||||
This action sets the float output to the given level when executed. Note: This only
|
||||
works with floating point outputs like ESP8266 PWM or LEDC.
|
||||
works with floating point outputs like ESP8266 PWM, LEDC or ``slow_pwm``.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
- output.set_level:
|
||||
id: output_1
|
||||
id: light_1
|
||||
level: 50%
|
||||
|
||||
.. note::
|
||||
|
|
@ -115,7 +115,7 @@ works with floating point outputs like ESP8266 PWM or LEDC.
|
|||
.. code-block:: cpp
|
||||
|
||||
// range is 0.0 (off) to 1.0 (on)
|
||||
id(relay_1).set_level(0.5);
|
||||
id(light_1).set_level(0.5);
|
||||
|
||||
Full Output Index
|
||||
-----------------
|
||||
|
|
@ -129,10 +129,13 @@ Full Output Index
|
|||
- :doc:`/components/fan/speed`
|
||||
- :apiref:`binary_output.h <output/binary_output.h>`,
|
||||
:apiref:`float_output.h <output/float_output.h>`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
*
|
||||
|
||||
- :ghedit:`Edit`
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -29,6 +29,7 @@ Configuration variables:
|
|||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **include_internal** (*Optional*, boolean): Whether ``internal`` entities should be displayed on the
|
||||
web interface. Defaults to ``false``.
|
||||
- **relabel** (*Optional*): Override metric labels. See :ref:`prometheus-relabel`
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -41,6 +42,32 @@ Configuration variables:
|
|||
static_configs:
|
||||
- targets: [<ip or node_name.local>]
|
||||
|
||||
Metric Relabeling
|
||||
-----------------
|
||||
|
||||
ESPHome allows you to do some basic relabeling of Prometheus metrics.
|
||||
This is useful if you want to have different metric names or IDs than those shown in Home Assistant or the web interface.
|
||||
|
||||
You can relabel metric name or ID labels by adding a ``relabel`` block in the ``prometheus`` configuration,
|
||||
and then adding a block with ``id`` and/or ``name`` fields for each sensor whose labels your want to override.
|
||||
|
||||
.. _prometheus-relabel:
|
||||
|
||||
``relabel``
|
||||
***********
|
||||
|
||||
Set the the ``id`` and ``name`` label values of the Prometheus metric for the sensor with the specified ID.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
prometheus:
|
||||
relabel:
|
||||
my_voltage_sensor:
|
||||
id: angry_pixies
|
||||
name: "Angry Pixies"
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
|
|
|
|||
|
|
@ -30,6 +30,7 @@ Configuration variables:
|
|||
- **dump** (*Optional*, list): Decode and dump these remote codes in the logs (at log.level=DEBUG).
|
||||
Set to ``all`` to dump all available codecs:
|
||||
|
||||
- **aeha**: Decode and dump AEHA infrared codes.
|
||||
- **coolix**: Decode and dump Coolix infrared codes.
|
||||
- **dish**: Decode and dump Dish infrared codes.
|
||||
- **jvc**: Decode and dump JVC infrared codes.
|
||||
|
|
@ -65,6 +66,9 @@ Configuration variables:
|
|||
|
||||
Automations:
|
||||
|
||||
- **on_aeha** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
|
||||
AEHA remote code has been decoded. A variable ``x`` of type :apiclass:`remote_base::AEHAData`
|
||||
is passed to the automation for use in lambdas.
|
||||
- **on_coolix** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
|
||||
Coolix remote code has been decoded. A variable ``x`` of type :apiclass:`remote_base::CoolixData`
|
||||
is passed to the automation for use in lambdas.
|
||||
|
|
@ -164,6 +168,12 @@ Configuration variables:
|
|||
|
||||
Remote code selection (exactly one of these has to be included):
|
||||
|
||||
- **aeha**: Trigger on a decoded AEHA remote code with the given data.
|
||||
|
||||
- **address** (**Required**, int): The address to trigger on, see dumper output for more info.
|
||||
- **data** (**Required**, 3-35 bytes list): The code to listen for, see :ref:`remote_transmitter-transmit_aeha`
|
||||
for more info. Usually you only need to copy this directly from the dumper output.
|
||||
|
||||
- **coolix**: Trigger on a decoded Coolix remote code with the given data.
|
||||
|
||||
- **data** (**Required**, int): The 24-bit Coolix code to trigger on, see dumper output for more info.
|
||||
|
|
|
|||
|
|
@ -78,6 +78,27 @@ Configuration variables:
|
|||
If you're looking for the same functionality as is default in the ``rpi_rf`` integration in
|
||||
Home Assistant, you'll want to set the **times** to 10 and the **wait_time** to 0s.
|
||||
|
||||
.. _remote_transmitter-transmit_aeha:
|
||||
|
||||
``remote_transmitter.transmit_aeha`` Action
|
||||
*********************************************
|
||||
|
||||
This :ref:`action <config-action>` sends a AEHA code to a remote transmitter.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
- remote_transmitter.transmit_aeha:
|
||||
address: 0x1FEF
|
||||
data: [0x1F, 0x3E, 0x06, 0x5F]
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **address** (**Required**, int): The address to send the command to, see dumper output for more details.
|
||||
- **data** (**Required**, list): The command to send, A length of 2-35 bytes can be specified for one packet.
|
||||
|
||||
AEHA refers to the Association for Electric Home Appliances in Japan, a format used by Panasonic and many other companies.
|
||||
|
||||
.. _remote_transmitter-transmit_coolix:
|
||||
|
||||
``remote_transmitter.transmit_coolix`` Action
|
||||
|
|
|
|||
|
|
@ -54,6 +54,12 @@ Base Configuration:
|
|||
- **address** (*Optional*, int): The I²C address of the sensor. Defaults to ``0x39``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval
|
||||
to check the sensor. Defaults to ``60s``.
|
||||
- **led_drive** (*Optional*, int): The LED drive level in mA. One of 100mA, 50mA, 25mA, 12.5mA. Defaults to ``100mA``.
|
||||
- **proximity_gain** (*Optional*, int): The proximity gain level. One of 1x, 2x, 4x, 8x. Defaults to ``4x``.
|
||||
- **ambient_light_gain** (*Optional*, int): The ambient light gain level. One of 1x, 4x, 16x, 64x. Defaults to ``4x``.
|
||||
- **gesture_led_drive** (*Optional*, int): The gesture LED drive level in mA. One of 100mA, 50mA, 25mA, 12.5mA. Defaults to ``100mA``.
|
||||
- **gesture_gain** (*Optional*, int): The proximity gain level. One of 1x, 2x, 4x, 8x. Defaults to ``4x``.
|
||||
- **gesture_wait_time** (*Optional*, int): The gesture wait time in ms. One of 0ms, 2.8ms, 5.6ms, 8.4ms, 14ms, 22.4ms, 30.8ms, 39.2ms. Defaults to ``2.8ms``.
|
||||
|
||||
Sensor
|
||||
------
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ This sensor is **mostly used for touch** devices but could be used for any ``bin
|
|||
Add your binary sensors as ``channels`` to the binary sensor map. The binary sensor map then publishes a value depending
|
||||
on the type of the binary sensor map and the values specified with each channel.
|
||||
|
||||
This platform currently supports only one measurement type: ``GROUP``, but others might get added later.
|
||||
This platform currently supports two measurement types: ``GROUP`` and ``SUM``, and others might get added later.
|
||||
You need to specify which type of mapping you want with the ``type:`` configuration value:
|
||||
|
||||
- ``GROUP`` Each channel has its own value. The sensor publishes the average value of all active
|
||||
|
|
@ -47,6 +47,45 @@ You need to specify which type of mapping you want with the ``type:`` configurat
|
|||
channel: 0
|
||||
id: touchkey0
|
||||
# ...
|
||||
|
||||
- ``SUM`` Each channel has its own value. The sensor publishes the sum of all active
|
||||
binary sensors values.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: binary_sensor_map
|
||||
id: group_0
|
||||
name: 'Group Map 0'
|
||||
type: sum
|
||||
channels:
|
||||
- binary_sensor: bit0
|
||||
value: 1
|
||||
- binary_sensor: bit1
|
||||
value: 2
|
||||
- binary_sensor: bit2
|
||||
value: 4
|
||||
- binary_sensor: bit3
|
||||
value: 8
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
pin: 4
|
||||
id: bit0
|
||||
|
||||
- platform: gpio
|
||||
pin: 5
|
||||
id: bit1
|
||||
|
||||
- platform: gpio
|
||||
pin: 6
|
||||
id: bit2
|
||||
|
||||
- platform: gpio
|
||||
pin: 7
|
||||
id: bit3
|
||||
# ...
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
|
|
|||
|
|
@ -0,0 +1,68 @@
|
|||
Belling BL0942 Energy Monitor
|
||||
==================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up BL0942 power monitors.
|
||||
:image: bl0942.png
|
||||
:keywords: BL0942, Aubess, Mini Smart Switch With Energy Monitor
|
||||
|
||||
The ``bl0942`` sensor platform allows you to use BL0942 energy monitors sensors with
|
||||
ESPHome. These are used in some Tuya-devices (e.g. Aubess Tuya WiFi Mini Smart Switch With Energy Monitor)
|
||||
|
||||
The communication with this integration is done over a :ref:`UART bus <uart>`.
|
||||
You must therefore have a ``uart:`` entry in your configuration with both the TX and RX pins set
|
||||
to some pins on your board and the baud rate set to 4800 with 1 stop bit.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
id: uart_bus
|
||||
tx_pin: TX
|
||||
rx_pin: RX
|
||||
baud_rate: 4800
|
||||
stop_bits: 1
|
||||
|
||||
sensor:
|
||||
- platform: bl0942
|
||||
uart_id: uart_bus
|
||||
voltage:
|
||||
name: 'BL0942 Voltage'
|
||||
current:
|
||||
name: 'BL0942 Current'
|
||||
power:
|
||||
name: 'BL0942 Power'
|
||||
filters:
|
||||
multiply: -1
|
||||
energy:
|
||||
name: 'BL0942 Energy'
|
||||
frequency:
|
||||
name: "BL0942 Frequency"
|
||||
accuracy_decimals: 2
|
||||
|
||||
update_interval: 60s
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **voltage** (*Optional*): The voltage value of the sensor in Volts.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
- **current** (*Optional*): The current value of the sensor in Amperes. All options from
|
||||
:ref:`Sensor <config-sensor>`.
|
||||
- **power** (*Optional*): The (active) power value of the sensor in Watts. Note that some power meters will report this in negative values (probably wired backwards), so you may want to use a filter to multiply it by -1. All options from :ref:`Sensor <config-sensor>`.
|
||||
- **energy** (*Optional*): Use the voltage value of the sensor in kWh.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
- **frequency** (*Optional*): The frequency value of the sensor in Hertz. All options from
|
||||
:ref:`Sensor <config-sensor>`.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the
|
||||
sensor. Defaults to ``60s``.
|
||||
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
|
||||
to use multiple UART buses.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :apiref:`bl0942/bl0942.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -6,7 +6,7 @@ BLE Client Sensor
|
|||
:image: bluetooth.svg
|
||||
|
||||
The ``ble_client`` component is a sensor platform that can
|
||||
query BLE devices for specific values of service characteristics.
|
||||
query BLE devices for RSSI or specific values of service characteristics.
|
||||
|
||||
For more information on BLE services and characteristics, see
|
||||
:doc:`/components/ble_client`.
|
||||
|
|
@ -21,6 +21,7 @@ For more information on BLE services and characteristics, see
|
|||
|
||||
sensor:
|
||||
- platform: ble_client
|
||||
type: characteristic
|
||||
ble_client_id: itag_black
|
||||
name: "iTag battery level"
|
||||
service_uuid: '180f'
|
||||
|
|
@ -28,20 +29,34 @@ For more information on BLE services and characteristics, see
|
|||
icon: 'mdi:battery'
|
||||
unit_of_measurement: '%'
|
||||
|
||||
- platform: ble_client
|
||||
type: rssi
|
||||
ble_client_id: itag_black
|
||||
name: "iTag RSSI"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **ble_client_id** (**Required**, :ref:`config-id`): ID of the associated BLE client.
|
||||
- **service_uuid** (**Required**, UUID): UUID of the service on the device.
|
||||
- **characteristic_uuid** (**Required**, UUID): UUID of the service's characteristic to query.
|
||||
- **descriptor_uuid** (*Optional*, UUID): UUID of the characteristic's descriptor to query.
|
||||
- **id** (*Optional*, :ref:`config-id`): The ID to use for code generation, and for reference by dependent components.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for converting a raw data
|
||||
reading to a sensor value. See :ref:`ble-sensor-lambda` for more information.
|
||||
- **notify** (*Optional*, boolean): Instruct the server to send notifications for this
|
||||
characteristic.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to poll the device.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
- **type** (**Required**): One of ``rssi``, ``characteristic``.
|
||||
|
||||
rssi options:
|
||||
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to poll the device.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
characteristic options:
|
||||
|
||||
- **ble_client_id** (**Required**, :ref:`config-id`): ID of the associated BLE client.
|
||||
- **service_uuid** (**Required**, UUID): UUID of the service on the device.
|
||||
- **characteristic_uuid** (**Required**, UUID): UUID of the service's characteristic to query.
|
||||
- **descriptor_uuid** (*Optional*, UUID): UUID of the characteristic's descriptor to query.
|
||||
- **id** (*Optional*, :ref:`config-id`): The ID to use for code generation, and for reference by dependent components.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for converting a raw data
|
||||
reading to a sensor value. See :ref:`ble-sensor-lambda` for more information.
|
||||
- **notify** (*Optional*, boolean): Instruct the server to send notifications for this
|
||||
characteristic.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to poll the device.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
Automations:
|
||||
|
||||
|
|
@ -64,6 +79,7 @@ variable ``x`` of type ``std::vector<uint8_t>``. The function must return a sing
|
|||
|
||||
sensor:
|
||||
- platform: ble_client
|
||||
type: characteristic
|
||||
ble_client_id: t_sensor
|
||||
name: "Temperature Sensor 32bit float"
|
||||
...
|
||||
|
|
|
|||
|
|
@ -24,6 +24,10 @@ instructions for setting up this platform.
|
|||
- platform: ble_rssi
|
||||
service_uuid: '11aa'
|
||||
name: "BLE Test Service 16 bit RSSI value"
|
||||
# RSSI based on iBeacon UUID
|
||||
- platform: ble_rssi
|
||||
ibeacon_uuid: '68586f1e-89c2-11eb-8dcd-0242ac130003'
|
||||
name: "BLE Test Service iBeacon RSSI value"
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -35,10 +39,18 @@ Configuration variables:
|
|||
|
||||
- **name** (**Required**, string): The name of the sensor.
|
||||
- **mac_address** (*Optional*, MAC Address): The MAC address to track for this
|
||||
sensor. Either this or ''service_uuid'' has to be present.
|
||||
sensor. Note that exactly one of ``mac_address``, ``service_uuid`` or ``ibeacon_uuid`` must be present.
|
||||
- **service_uuid** (*Optional*, 16 bit, 32 bit, or 128 bit BLE Service UUID): The BLE
|
||||
Service UUID which can be tracked if the device randomizes the MAC address. Either
|
||||
this or ''mac_address'' has to be present.
|
||||
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.
|
||||
- **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.
|
||||
- **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.
|
||||
- **ibeacon_minor** (*Optional*, int): The iBeacon minor identifier of the beacon that needs
|
||||
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.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ CSE7766 Power Sensor
|
|||
:keywords: cse7766, cse7759b, Sonoff Pow R2
|
||||
|
||||
The ``cse7766`` sensor platform allows you to use your CSE7766 voltage/current and power sensors
|
||||
(`datasheet <http://dl.itead.cc/S31/CSE7766.pdf>`__) sensors with
|
||||
(`datasheet <https://itead.cc/wp-content/uploads/2022/05/CSE7766.pdf>`__) sensors with
|
||||
ESPHome. This sensor is commonly found in Sonoff POW R2. CSE7759B is similar to CSE7766
|
||||
and works with this integration.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
DPS310 Atmospheric Pressure Sensor
|
||||
==================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up DPS310 atmospheric pressure sensors
|
||||
:image: dps310.jpg
|
||||
:keywords: DPS310
|
||||
|
||||
The ``dps310`` sensor platform allows you to use both the temperature and pressure sensors on
|
||||
your DPS310 atmospheric pressure sensor (`Adafruit <https://www.adafruit.com/product/4494>`__)
|
||||
with ESPHome. The :ref:`I²C <i2c>` component is required to be set up in your configuration.
|
||||
|
||||
.. figure:: images/dps310-full.jpg
|
||||
:align: center
|
||||
:width: 50.0%
|
||||
|
||||
DPS310 Atmospheric Pressure Sensor board from `Adafruit <https://www.adafruit.com/product/4494>`__
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: dps310
|
||||
temperature:
|
||||
name: "Outside Temperature"
|
||||
pressure:
|
||||
name: "Outside Pressure"
|
||||
address: 0x77
|
||||
update_interval: 60s
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **pressure** (**Required**): The information for the pressure sensor.
|
||||
|
||||
- **name** (**Required**, string): The name for the pressure sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **temperature** (**Required**): The information for the temperature.
|
||||
sensor
|
||||
|
||||
- **name** (**Required**, string): The name for the temperature
|
||||
sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **address** (*Optional*, int): Manually specify the I²C address of
|
||||
the sensor. Defaults to ``0x77``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the
|
||||
sensor. Defaults to ``60s``.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`bmp280`
|
||||
- :doc:`bme680`
|
||||
- :doc:`bmp085`
|
||||
- :apiref:`dps310/dps310.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -38,6 +38,8 @@ required to be set up in your configuration for this sensor to work.
|
|||
- platform: hydreon_rgxx
|
||||
too_cold:
|
||||
name: "too cold"
|
||||
lens_bad:
|
||||
name: "lens bad"
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -99,6 +101,12 @@ Configuration variables:
|
|||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **temperature** (*Optional*): Temperature +-5°C. Only on RG-9 Version 1.100 or later.
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the sensor. Defaults to ``60s``.
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 399 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 168 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
|
|
@ -0,0 +1,69 @@
|
|||
MCP9600 Thermocouple Amplifier
|
||||
===========================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the MCP9600 thermocouple amplifier
|
||||
:image: mcp9600.jpg
|
||||
:keywords: MCP9600
|
||||
|
||||
The ``mcp9600`` sensor platform allows you to use your MCP9600 and MCP9601
|
||||
(`datasheet <https://cdn-learn.adafruit.com/assets/assets/000/105/040/original/MCP960X-Data-Sheet-20005426%281%29.pdf>`__,
|
||||
`Adafruit`_) to measure the temperature of a connected thermocouple while also measuring the ambient temperature around the sensor with ESPHome. :ref:`I²C <i2c>` is
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. warning::
|
||||
|
||||
The :ref:`I²C <i2c>` bus must be set to a minimum of ``100khz`` due to the limitations of the MCP9600 and MCP9601.
|
||||
|
||||
.. figure:: images/mcp9600.jpg
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
MCP9600 Thermocouple Amplifier
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/4101
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: mcp9600
|
||||
hot_junction:
|
||||
name: "Thermocouple Temperature"
|
||||
cold_junction:
|
||||
name: "Ambient Temperature"
|
||||
thermocouple_type: K
|
||||
address: 0x67
|
||||
update_interval: 60s
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **hot_junction** (*Optional*): The information for the Hot Junction temperature sensor.
|
||||
|
||||
- **name** (**Required**, string): The name for the temperature
|
||||
sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **cold_junction** (*Optional*): The information for the Cold Junction temperature sensor.
|
||||
|
||||
- **name** (**Required**, string): The name for the temperature sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **thermocouple_type** (*Optional*): Set the thermocouple type. Options are:
|
||||
K, J, T, N, S, E, B and R type thermocouple. Defaults to ``K``.
|
||||
- **address** (*Optional*, int): Manually specify the I²C address of
|
||||
the sensor. Defaults to ``0x67``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the
|
||||
sensor. Defaults to ``60s``.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :apiref:`mcp9600/mcp9600.h`
|
||||
- `Adafruit MCP9600 Library <https://github.com/adafruit/Adafruit_MCP9600>`__ by `Adafruit <https://www.adafruit.com/>`__
|
||||
- `SparkFun MCP9600 Library <https://github.com/sparkfun/SparkFun_MCP9600_Arduino_Library>`__ by `SparkFun <https://www.sparkfun.com/>`__
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
MPL3115A2 Barometric Pressure/Altitude/Temperature Sensor
|
||||
=========================================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MPL3115A2 atmospheric pressure sensors.
|
||||
:image: mpl3115a2.jpg
|
||||
:keywords: MPL3115A2
|
||||
|
||||
The ``mpl3115a2`` sensor platform allows you to use your MPL3115A2 atmospheric pressure sensors
|
||||
(`datasheet <https://www.nxp.com/docs/en/data-sheet/MPL3115A2.pdf>`__,
|
||||
`Adafruit`_) temperature and pressure sensors with ESPHome. The :ref:`I²C <i2c>` is
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. figure:: images/mpl3115a2-full.jpg
|
||||
:align: center
|
||||
:width: 50.0%
|
||||
|
||||
MPL3115A2 Barometric Pressure/Altitude/Temperature Sensor
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/1893
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: mpl3115a2
|
||||
temperature:
|
||||
name: "MPL3115A2 Temperature"
|
||||
pressure:
|
||||
name: "MPL3115A2 Pressure"
|
||||
update_interval: 10s
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
The MPL3115A2 can be configured to output either pressure or altitude depending on which
|
||||
sensor is configured.
|
||||
|
||||
- **pressure** (**Optional**): The information for the pressure sensor.
|
||||
|
||||
- **name** (**Required**, string): The name for the pressure sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **altitude** (**Optional**): The information for the altitude sensor.
|
||||
|
||||
- **name** (**Required**, string): The name for the altitude sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **temperature** (**Optional**): The information for the temperature sensor.
|
||||
|
||||
- **name** (**Required**, string): The name for the temperature sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **address** (*Optional*, int): Manually specify the I²C address of
|
||||
the sensor. Defaults to ``0x60``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the
|
||||
sensor. Defaults to ``60s``.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`bmp280`
|
||||
- :doc:`bme280`
|
||||
- :doc:`bmp085`
|
||||
- :doc:`ms5611`
|
||||
- :apiref:`mpl3115a2/mpl3115a2.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -38,10 +38,13 @@ Configuration variables:
|
|||
- **falling_edge** (*Optional*): What to do when a falling edge is
|
||||
detected. One of ``DISABLE``, ``INCREMENT`` and ``DECREMENT``.
|
||||
Defaults to ``DISABLE``.
|
||||
|
||||
|
||||
- **use_pcnt** (*Optional*, boolean): Use hardware ``PCNT`` pulse counter. Only supported on ESP32. Defaults to ``true``.
|
||||
|
||||
- **internal_filter** (*Optional*, :ref:`config-time`): If a pulse shorter than this
|
||||
time is detected, it’s discarded and no pulse is counted. Defaults to ``13us``. On the ESP32,
|
||||
this value can not be higher than ``13us``, for the ESP8266 you can use larger intervals too.
|
||||
time is detected, it’s discarded and no pulse is counted. Defaults to ``13us``. On the ESP32, when using the hardware pulse counter
|
||||
this value can not be higher than ``13us``, for the ESP8266 or with ``use_pcnt: false`` you can use larger intervals too.
|
||||
If you enable this, set up the ``count_mode`` to increase on the falling edge, not leading edge. For S0 pulse meters that are used to meter power consumption 50-100 ms is a reasonable value.
|
||||
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the sensor. Defaults to ``60s``.
|
||||
|
|
@ -88,7 +91,7 @@ measure the total consumed energy in kWh.
|
|||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: pulse_counter
|
||||
- platform: pulse_counter
|
||||
pin: 12
|
||||
unit_of_measurement: 'kW'
|
||||
name: 'Power Meter House'
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ a better understanding of these sensors.
|
|||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
To use rotary encoders in ESPHome, first identify the two pins encoding th step value.
|
||||
To use rotary encoders in ESPHome, first identify the two pins encoding the step value.
|
||||
These are often called ``CLK`` and ``DT`` as in above image. Note if the values this sensor
|
||||
outputs go in the wrong direction, you can just swap these two pins.
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ Configuration variables:
|
|||
The second pin for determining the step value. Must not be a pin from an external I/O expander.
|
||||
- **name** (**Required**, string): The name of the rotary encoder sensor.
|
||||
- **pin_reset** (*Optional*, :ref:`Pin Schema <config-pin_schema>`):
|
||||
An optional pin that resets the step value. This is useful with rotary encoders that have have a
|
||||
An optional pin that resets the step value. This is useful with rotary encoders that have a
|
||||
third pin. Defaults to no reset pin.
|
||||
- **resolution** (*Optional*, string): The resolution of the sensor, this controls how many
|
||||
pulses are generated by one step:
|
||||
|
|
@ -72,7 +72,7 @@ Configuration variables:
|
|||
- **max_value** (*Optional*, int): The maximum value this rotary encoder will go to, turning
|
||||
the knob further will not increase the number. Defaults to no maximum.
|
||||
- **publish_initial_value** (*Optional*, boolean): Controls whether the value is published
|
||||
upon start of ESPHome. By default the value is only published when it changes, causing an
|
||||
upon start of ESPHome. By default, the value is only published when it changes, causing an
|
||||
"unknown" value at first. If you set this option to true, the value is published once after
|
||||
boot and when it changes. Defaults to ``false``.
|
||||
- **restore_mode** (*Optional*): Control how the Rotary Encoder attempts to restore state on bootup.
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ SGP40 Volatile Organic Compound Sensor and SGP41 VOC and NOx Sensor
|
|||
:description: Instructions for setting up SGP40/SGP41 Volatile Organic Compound and NOx sensor
|
||||
:image: sgp40.jpg
|
||||
|
||||
The ``sgp4x`` sensor platform allows you to use your Sensirion SGP40
|
||||
(`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/9_Gas_Sensors/Sensirion_Gas_Sensors_SGP40_Datasheet.pdf>`__) or SGP41
|
||||
The ``sgp4x`` sensor platform allows you to use your Sensirion SGP40
|
||||
(`datasheet <https://sensirion.com/media/documents/296373BB/6203C5DF/Sensirion_Gas_Sensors_Datasheet_SGP40.pdf>`__) or SGP41
|
||||
(`datasheet <https://sensirion.com/media/documents/5FE8673C/61E96F50/Sensirion_Gas_Sensors_Datasheet_SGP41.pdf>`__) with ESPHome.
|
||||
The type of sensor used is automatically detected.
|
||||
The :ref:`I²C Bus <i2c>` is required to be set up in your configuration for this sensor to work.
|
||||
|
|
@ -41,15 +41,15 @@ Configuration variables:
|
|||
|
||||
- **name** (**Required**, string): The name of the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **algorithm_tuning** (*Optional*): The VOC algorithm can be customized by tuning 6 different parameters. For more details see `Engineering Guidelines for SEN5x <https://sensirion.com/media/documents/25AB572C/61E961EA/Sensirion_Engineering_Guidelines_SEN5x.pdf>`__
|
||||
- **algorithm_tuning** (*Optional*): The VOC algorithm can be customized by tuning 6 different parameters. For more details see `Engineering Guidelines for SEN5x <https://sensirion.com/media/documents/25AB572C/62B463AA/Sensirion_Engineering_Guidelines_SEN5x.pdf>`__
|
||||
|
||||
- **index_offset** (*Optional*): VOC index representing typical (average) conditions. Allowed values are in range 1..250. The default value is 100.
|
||||
- **index_offset** (*Optional*): VOC index representing typical (average) conditions. Allowed values are in range 1..250. The default value is 100.
|
||||
- **learning_time_offset_hours** (*Optional*): Time constant to estimate the VOC algorithm offset from the history in hours. Past events will be forgotten after about twice the learning time. Allowed values are in range 1..1000. The default value is 12 hour
|
||||
- **learning_time_gain_hours** (*Optional*): Time constant to estimate the VOC algorithm gain from the history in hours. Past events will be forgotten after about twice the learning time. Allowed values are in range 1..1000. The default value is 12 hours.
|
||||
- **learning_time_gain_hours** (*Optional*): Time constant to estimate the VOC algorithm gain from the history in hours. Past events will be forgotten after about twice the learning time. Allowed values are in range 1..1000. The default value is 12 hours.
|
||||
- **gating_max_duration_minutes** (*Optional*): Maximum duration of gating in minutes (freeze of estimator during high VOC index signal). Zero disables the gating. Allowed values are in range 0..3000. The default value is 180 minutes
|
||||
- **std_initial** (*Optional*): Initial estimate for standard deviation. Lower value boosts events during initial learning period, but may result in larger device-todevice variations. Allowed values are in range 10..5000. The default value is 50.
|
||||
- **gain_factor:** (*Optional*): Gain factor to amplify or to attenuate the VOC index output. Allowed values are in range 1..1000. The default value is 230.
|
||||
|
||||
- **gain_factor** (*Optional*): Gain factor to amplify or to attenuate the VOC index output. Allowed values are in range 1..1000. The default value is 230.
|
||||
|
||||
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
|
|
@ -57,14 +57,14 @@ Configuration variables:
|
|||
|
||||
- **name** (**Required**, string): The name of the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **algorithm_tuning** (*Optional*): The NOx algorithm can be customized by tuning 5 different parameters.For more details see `Engineering Guidelines for SEN5x <https://sensirion.com/media/documents/25AB572C/61E961EA/Sensirion_Engineering_Guidelines_SEN5x.pdf>`__
|
||||
|
||||
- **index_offset** (*Optional*): NOx index representing typical (average) conditions. Allowed values are in range 1..250. The default value is 100.
|
||||
- **algorithm_tuning** (*Optional*): The NOx algorithm can be customized by tuning 5 different parameters.For more details see `Engineering Guidelines for SEN5x <https://sensirion.com/media/documents/25AB572C/62B463AA/Sensirion_Engineering_Guidelines_SEN5x.pdf>`__
|
||||
|
||||
- **index_offset** (*Optional*): NOx index representing typical (average) conditions. Allowed values are in range 1..250. The default value is 100.
|
||||
- **learning_time_offset_hours** (*Optional*): Time constant to estimate the NOx algorithm offset from the history in hours. Past events will be forgotten after about twice the learning time. Allowed values are in range 1..1000. The default value is 12 hour
|
||||
- **learning_time_gain_hours** (*Optional*): Time constant to estimate the NOx algorithm gain from the history in hours. Past events will be forgotten after about twice the learning time. Allowed values are in range 1..1000. The default value is 12 hours.
|
||||
- **learning_time_gain_hours** (*Optional*): Time constant to estimate the NOx algorithm gain from the history in hours. Past events will be forgotten after about twice the learning time. Allowed values are in range 1..1000. The default value is 12 hours.
|
||||
- **gating_max_duration_minutes** (*Optional*): Maximum duration of gating in minutes (freeze of estimator during high NOx index signal). Zero disables the gating. Allowed values are in range 0..3000. The default value is 180 minutes
|
||||
- **std_initial** (*Optional*): The initial estimate for standard deviation parameter has no impact for NOx. This parameter is still in place for consistency reasons with the VOC tuning parameters command. This parameter must always be set to 50.
|
||||
- **gain_factor:** (*Optional*)
|
||||
- **gain_factor** (*Optional*): Gain factor to amplify or to attenuate the VOC index output. Allowed values are in range 1..1000. The default value is 230.
|
||||
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,12 +42,12 @@ The communication with this integration is done over a UART bus using a simple A
|
|||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **counts** (*Optional*): Raw measurement data from the sensor electronics (dimensionless quantity). Higher counts mean less moisture. May be used for material specific calibrations.
|
||||
- **counts** (*Optional*): Raw measurement data from the sensor electronics (dimensionless quantity). Higher counts mean less moisture. May be used for material specific calibrations.
|
||||
|
||||
- **name** (**Required**): Sensor name.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **Permittivity** (*Optional*): Permittivity or dielectric coefficient of the material to be measured (dimensionless quantity. Higher permittivity means higher water content. May be used for material specific calibration.
|
||||
- **dielectric_constant** (*Optional*): Dielectric coefficient or permittivity of the material to be measured (dimensionless quantity). Higher permittivity means higher water content. May be used for material specific calibration.
|
||||
|
||||
- **name** (**Required**): Sensor name.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
|
@ -66,7 +66,7 @@ Configuration variables:
|
|||
|
||||
- **name** (**Required**): Sensor name.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
|
||||
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
|
||||
to use multiple UART buses.
|
||||
|
||||
|
|
|
|||
|
|
@ -107,10 +107,13 @@ In teleinfo platform:
|
|||
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
|
||||
to use multiple UART buses.
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation or multiple hubs.
|
||||
|
||||
Sensor
|
||||
******
|
||||
|
||||
- **tag_name** (**Required**, string): Specify the tag you want to retrieve from the Teleinformation.
|
||||
- **teleinfo_id** (*Optional*, :ref:`config-id`): Specify the ID of used hub.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
|
|
@ -118,6 +121,7 @@ Text Sensor
|
|||
***********
|
||||
|
||||
- **tag_name** (**Required**, string): Specify the tag you want to retrieve from the Teleinformation.
|
||||
- **teleinfo_id** (*Optional*, :ref:`config-id`): Specify the ID of used hub.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Text Sensor <config-text_sensor>`.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Configuration variables:
|
|||
Lambda to be evaluated every update interval to get the new value of the sensor
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to publish the value of the
|
||||
sensor, either the result of the lambda function or if no lambda function the last value
|
||||
published using the publish action. Defaults to ``60s``.
|
||||
published using the publish action. Set to ``never`` to disable updates. Defaults to ``60s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,106 @@
|
|||
uFire Isolated EC sensor
|
||||
========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up uFire Isolated EC sensor in esphome
|
||||
:image: ufire_ec.png
|
||||
:keywords: ufire ec sensor temperature esphome
|
||||
|
||||
The ``ufire_ec`` sensor platform allows you to use your uFire Isolated EC sensor
|
||||
with ESPHome. The :ref:`I²C Bus <i2c>` is required to be set up in your
|
||||
configuration for this sensor to work. It requires also to have a temperature
|
||||
sensor in the liquid tank; this can be on the same board or an external sensor
|
||||
linked to the uFire EC configuration.
|
||||
|
||||
.. figure:: images/ufire_ec.png
|
||||
:align: center
|
||||
:width: 100.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: ufire_ec
|
||||
id: ufire_ec_board
|
||||
temperature:
|
||||
id: temperature_liquit
|
||||
name: Temperature
|
||||
ec:
|
||||
name: EC
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **address** (**Optional**, int): Specify the I²C address of the sensor. Defaults to ``0x3C``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the
|
||||
sensor. Defaults to ``60s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- **temperature_sensor** (*Optional*, :ref:`config-id`): Set the ID of the temperature
|
||||
sensor. Only needed if the onboard temperature sensor is not used.
|
||||
- **ec** (*Optional*, :ref:`Sensor <config-sensor>`): Set the EC sensor configuration. All options from :ref:`Sensor <config-sensor>`.
|
||||
- **temperature** (*Optional*, :ref:`Sensor <config-sensor>`): Set the onboard temperature sensor configuration. All options from :ref:`Sensor <config-sensor>`.
|
||||
- **temperature_compensation** (*Optional*, float): Set the temperature compensation for the EC
|
||||
sensor. Defaults to ``21.0``.
|
||||
- **temperature_coefficient** (*Optional*, float): Set the temperature coefficient for the EC
|
||||
sensor. Defaults to ``0.019``.
|
||||
|
||||
.. _sensor-ufire_ec-calibrate_probe_action:
|
||||
|
||||
``sensor.ufire_ec.calibrate_probe`` Action
|
||||
------------------------------------------
|
||||
|
||||
The EC probe have to be calibrated. For this you need know the EC reference value and temperature
|
||||
of the calibration solution.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: ufire_ec
|
||||
id: ufire_ec_board
|
||||
# ...
|
||||
|
||||
# in some trigger
|
||||
on_...:
|
||||
- sensor.ufire_ec_board.calibrate_probe:
|
||||
id: ufire_ec_board
|
||||
solution: 0.146
|
||||
temperature: !lambda "return id(temperature_liquit).state;"
|
||||
|
||||
Configuration options:
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The ID of the ufire EC sensor.
|
||||
- **solution** (**Required**, float): Solution reference EC value.
|
||||
- **temperature** (**Required**, float): Solution current temperature.
|
||||
|
||||
.. _sensor-ufire_ec-reset_action:
|
||||
|
||||
``sensor.ufire_ec.reset`` Action
|
||||
--------------------------------
|
||||
|
||||
Reset the current calibration on the sensor.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: ufire_ec
|
||||
id: ufire_ec_board
|
||||
# ...
|
||||
|
||||
# in some trigger
|
||||
on_...:
|
||||
- sensor.ufire_ec_board.reset:
|
||||
id: ufire_ec_board
|
||||
|
||||
Configuration options:
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The ID of the ufire EC sensor.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :apiref:`ufire_ec/ufire_ec.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -0,0 +1,132 @@
|
|||
uFire ISE pH sensor
|
||||
===================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up uFire ISE pH sensor in esphome
|
||||
:image: ufire_ise.png
|
||||
:keywords: ufire ph sensor temperature esphome
|
||||
|
||||
The ``ufire_ise`` sensor platform allows you to use your uFire ISE pH sensor with
|
||||
ESPHome. The :ref:`I²C Bus <i2c>` is
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
It required also to have an temperature sensor in the liquit tank; this can
|
||||
be on the same board or external sensor linked to the uFire ISE pH configuration.
|
||||
|
||||
.. figure:: images/ufire_ise.png
|
||||
:align: center
|
||||
:width: 100.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: ufire_ise
|
||||
id: ufire_ise_board
|
||||
temperature:
|
||||
id: temperature_liquit
|
||||
name: Temperature
|
||||
ph:
|
||||
name: pH
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **address** (**Optional**, int): Specify the I²C address of the sensor. Defaults to ``0x3f``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the
|
||||
sensor. Defaults to ``60s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||
- **temperature_sensor** (*Optional*, :ref:`config-id`): Set the ID of the temperature
|
||||
sensor. Only needed if the onboard temperature sensor is not used.
|
||||
- **ph** (*Optional*, :ref:`Sensor <config-sensor>`): Set the pH sensor configuration. All options from :ref:`Sensor <config-sensor>`.
|
||||
- **temperature** (*Optional*, :ref:`Sensor <config-sensor>`): Set the onboard temperature sensor configuration. All options from :ref:`Sensor <config-sensor>`.
|
||||
Can't be used together with ``temperature_sensor``.
|
||||
|
||||
.. _sensor-ufire_ise-calibrate_probe_high_action:
|
||||
|
||||
``sensor.ufire_ise.calibrate_probe_high`` Action
|
||||
------------------------------------------------
|
||||
|
||||
The pH probe have to be calibrated. For this you need know the pH reference value and temperature
|
||||
of the calibration high solution.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: ufire_ise
|
||||
id: ufire_ise_board
|
||||
# ...
|
||||
|
||||
# in some trigger
|
||||
on_...:
|
||||
- sensor.ufire_ise_board.calibrate_probe_high:
|
||||
id: ufire_ise_board
|
||||
solution: 7.0
|
||||
temperature: !lambda "return id(temperature_liquit).state;"
|
||||
|
||||
Configuration options:
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The ID of the ufire pH sensor.
|
||||
- **solution** (**Required**, float): Solution reference pH value.
|
||||
- **temperature** (**Required**, float): Solution current temperature.
|
||||
|
||||
.. _sensor-ufire_ise-calibrate_probe_low_action:
|
||||
|
||||
``sensor.ufire_ise.calibrate_probe_low`` Action
|
||||
-----------------------------------------------
|
||||
|
||||
The pH probe have to be calibrated. For this you need know the pH reference value and temperature
|
||||
of the calibration low solution.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: ufire_ise
|
||||
id: ufire_ise_board
|
||||
# ...
|
||||
|
||||
# in some trigger
|
||||
on_...:
|
||||
- sensor.ufire_ise_board.calibrate_probe_low:
|
||||
id: ufire_ise_board
|
||||
solution: 4.0
|
||||
temperature: !lambda "return id(temperature_liquit).state;"
|
||||
|
||||
Configuration options:
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The ID of the ufire pH sensor.
|
||||
- **solution** (**Required**, float): Solution reference pH value.
|
||||
- **temperature** (**Required**, float): Solution current temperature.
|
||||
|
||||
.. _sensor-ufire_ise-reset_action:
|
||||
|
||||
``sensor.ufire_ise.reset`` Action
|
||||
---------------------------------
|
||||
|
||||
Reset the current calibration on the sensor.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: ufire_ise
|
||||
id: ufire_ise_board
|
||||
# ...
|
||||
|
||||
# in some trigger
|
||||
on_...:
|
||||
- sensor.ufire_ise_board.reset:
|
||||
id: ufire_ise_board
|
||||
|
||||
Configuration options:
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The ID of the ufire pH sensor.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :apiref:`ufire_ise/ufire_ise.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -6,7 +6,7 @@ Xiaomi Mijia BLE Sensors
|
|||
:image: xiaomi_mijia_logo.jpg
|
||||
:keywords: Xiaomi, Mi Home, Mijia, BLE, Bluetooth, HHCCJCY01, GCLS002, HHCCPOT002, LYWSDCGQ, LYWSD02, CGG1, LYWSD03MMC, CGD1, JQJCY01YM, MUE4094RT, WX08ZM, MHO, C401, MHOC401
|
||||
|
||||
The ``xiaomi_ble`` sensor platform lets you track the output of Xiaomi Bluetooth Low Energy devices using the :doc:`/components/esp32_ble_tracker`. This component will track, for example, the temperature, humidity, moisture, conductivity, illuminance, formaldehyde, mosquito tablet and battery level of the device every time the sensor sends out a BLE broadcast. Contrary to other implementations, ``xiaomi_ble`` listens passively to advertisement packets and does not pair with the device. Hence ESPHome has no impact on battery life.
|
||||
The ``xiaomi_ble`` sensor platform lets you track the output of Xiaomi Bluetooth Low Energy devices using the :doc:`/components/esp32_ble_tracker`. This component will track, for example, the temperature, humidity, moisture, conductivity, illuminance, formaldehyde, mosquito tablet and battery level of the device every time the sensor sends out a BLE broadcast. Contrary to other implementations, ``xiaomi_ble`` listens passively to advertisement packets and does not pair with the device. Hence ESPHome has no impact on battery life. Thus, if you only use such sensors, you can safely set ``scan_parameters.active: false`` in ``esp32_ble_tracker`` configuration, to save from spamming your RF environment with useless scan requests.
|
||||
|
||||
Supported Devices
|
||||
-----------------
|
||||
|
|
@ -92,7 +92,7 @@ Configuration example:
|
|||
LYWSDCGQ
|
||||
********
|
||||
|
||||
Hygro thermometer, round body, segment LCD, broadcasts temperature, humidity and battery level.
|
||||
Hygro thermometer, round body, segment LCD, broadcasts temperature, humidity and battery level. This device is also known as MJ_HT_V1. In HA's native Xiaomi BLE integration, the device info page shows it as "MJ_HT_V1 (LYWSDCGQ by Xiaomi)".
|
||||
|
||||
.. figure:: images/xiaomi_lywsdcgq.jpg
|
||||
:align: center
|
||||
|
|
@ -567,7 +567,7 @@ It can sometimes take some time for the first BLE broadcast to be received. Once
|
|||
Obtaining The Bindkey
|
||||
---------------------
|
||||
|
||||
To set up an encrypted device such as the LYWSD03MMC (with Xiaomi stock firmware) and CGD1, you first need to obtain the bind key. The ``xiaomi_ble`` sensor component is not able to automatically generate a bind key so other workarounds are necessary.
|
||||
To set up an encrypted device such as the LYWSD03MMC (with Xiaomi stock firmware) and CGD1, you first need to obtain the bind key. The ``xiaomi_ble`` sensor component is not able to automatically generate a bindkey so other workarounds are necessary.
|
||||
|
||||
LYWSD03MMC/MHO-C401
|
||||
*******************
|
||||
|
|
@ -635,7 +635,11 @@ Avoid placing the ESP node in racks, close to routers/switches or other network
|
|||
Security considerations
|
||||
-----------------------
|
||||
|
||||
You should at least protect your sensors with a custom pairing PIN code.
|
||||
You should at least protect your sensors with a custom pairing PIN code. Choose a method employing bindkey in order to use encrypted communication over the air.
|
||||
|
||||
.. note::
|
||||
|
||||
Devices flashed with `PVVX MiThermometer <https://github.com/pvvx/ATC_MiThermometer>`__ custom firmware also support the `BTHome protocol <https://bthome.io/>`__ which can be used in conjunction with ESPHome's :doc:`/components/bluetooth_proxy` component to forward sensor data to Home Assistant.
|
||||
|
||||
|
||||
See Also
|
||||
|
|
@ -643,8 +647,10 @@ See Also
|
|||
|
||||
- :doc:`/components/esp32_ble_tracker`
|
||||
- :doc:`/components/sensor/index`
|
||||
- :doc:`/components/display/pvvx_mithermometer`
|
||||
- :apiref:`xiaomi_lywsd03mmc/xiaomi_ble.h`
|
||||
- :doc:`/components/ethernet`
|
||||
- :doc:`/components/bluetooth_proxy`
|
||||
- Passive BLE monitor integration for Home Assistant (ble_monitor custom component) `<https://github.com/custom-components/ble_monitor>`__
|
||||
by `@Magalex2x14 <https://github.com/Magalex2x14>`__ and `@Ernst79 <https://github.com/Ernst79>`__
|
||||
- Custom firmware (PVVX) for the Xiaomi Thermometer LYWSD03MMC `<https://github.com/pvvx/ATC_MiThermometer>`__
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ You have to replace the numbers in the lambdas to determine your weight which is
|
|||
- platform: template
|
||||
name: Impedance Aurélien
|
||||
id: impedance_user1
|
||||
unit_of_measurement: 'ohm'
|
||||
unit_of_measurement: 'Ω'
|
||||
icon: mdi:omega
|
||||
accuracy_decimals: 0
|
||||
- platform: template
|
||||
|
|
@ -103,7 +103,7 @@ You have to replace the numbers in the lambdas to determine your weight which is
|
|||
- platform: template
|
||||
name: Impedance Siham
|
||||
id: impedance_user2
|
||||
unit_of_measurement: 'ohm'
|
||||
unit_of_measurement: 'Ω'
|
||||
icon: mdi:omega
|
||||
accuracy_decimals: 0
|
||||
|
||||
|
|
|
|||
|
|
@ -9,10 +9,11 @@ Sim800L Component
|
|||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``SIM800L`` Component provides the ability to dial, send and receive SMS text messages. The device must be
|
||||
connected via a :doc:`UART bus </components/uart>` supporting both receiving and transmitting line.
|
||||
The UART bus must be configured at the same speed of the module which is by default 9600bps.
|
||||
The required connection wires are ``+VCC``, ``GND``, ``RX`` and ``TX``.
|
||||
The ``SIM800L`` Component provides the ability to dial, answer calls, send/receive SMS text messages and
|
||||
send/receive USSD codes. The device must be connected via a :doc:`UART bus </components/uart>`
|
||||
supporting both receiving and transmitting line. The UART bus must be configured at the same speed
|
||||
of the module which is by default 9600bps. The required connection wires are ``+VCC``, ``GND``,
|
||||
``RX`` and ``TX``.
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
@ -43,16 +44,6 @@ The required connection wires are ``+VCC``, ``GND``, ``RX`` and ``TX``.
|
|||
format: "Received '%s' from %s"
|
||||
args: [ 'message.c_str()', 'sender.c_str()' ]
|
||||
|
||||
sensor:
|
||||
- platform: sim800l
|
||||
rssi:
|
||||
name: "Sim800L RSSI"
|
||||
|
||||
binary_sensor:
|
||||
- platform: sim800l
|
||||
registered:
|
||||
name: "Sim800L Registered"
|
||||
|
||||
logger:
|
||||
baud_rate: 0 # disable uart logger on esp 8266
|
||||
|
||||
|
|
@ -62,10 +53,25 @@ Configuration variables:
|
|||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **on_sms_received** (*Optional*, :ref:`Automation <automation>`): An action to be
|
||||
performed when an SMS is received. See :ref:`sim800l-on_sms_received`.
|
||||
- **on_incoming_call** (*Optional*, :ref:`Automation <automation>`): An action to be
|
||||
performed when a call is received. See :ref:`sim800l-on_incoming_call`.
|
||||
- **on_call_connected** (*Optional*, :ref:`Automation <automation>`): An action to be
|
||||
performed when a call is connected, either because an outgoing call accepted is
|
||||
accepted or an incoming call answered.
|
||||
- **on_call_disconnected** (*Optional*, :ref:`Automation <automation>`): An action to be
|
||||
performed when a call is disconnected.
|
||||
|
||||
|
||||
Sensor
|
||||
------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: sim800l
|
||||
rssi:
|
||||
name: "Sim800L RSSI"
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **rssi** (*Optional*): The informed Received signal strength indication (RSSI) in dBm.
|
||||
|
|
@ -78,6 +84,13 @@ Configuration variables:
|
|||
Binary Sensor
|
||||
-------------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
binary_sensor:
|
||||
- platform: sim800l
|
||||
registered:
|
||||
name: "Sim800L Registered"
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **registered** (*Optional*): Indicates if the SIM800L has successfully registered in the cellular network.
|
||||
|
|
@ -103,6 +116,42 @@ under the variables named ``message`` and ``sender`` respectively.
|
|||
id(sms_sender).publish_state(sender);
|
||||
id(sms_message).publish_state(message);
|
||||
|
||||
.. _sim800l-on_incoming_call:
|
||||
|
||||
``on_incoming_call`` Trigger
|
||||
----------------------------
|
||||
|
||||
This automation triggers every time the SIM800L sends a RING / Caller ID message, this message
|
||||
is sent several times per call, presumably every time the phone "RINGs". The automation provides
|
||||
a ``caller_id`` string parameter which received information. The phone call is neither accepted
|
||||
or rejected.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_incoming_call:
|
||||
- logger.log:
|
||||
format: "Incoming call from '%s'"
|
||||
args: ["caller_id.c_str()"]
|
||||
- lambda: |-
|
||||
id(caller_id_text_sensor).publish_state(caller_id);
|
||||
- sim800l.disconnect
|
||||
- homeassistant.event:
|
||||
event: esphome.incoming_call_event
|
||||
data:
|
||||
payload: !lambda 'return id(caller_id_text_sensor).state;'
|
||||
|
||||
|
||||
``on_ussd_received`` Trigger
|
||||
----------------------------
|
||||
|
||||
With this configuration option you can write complex automations whenever the ussd code from network
|
||||
has been received.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_ussd_received:
|
||||
|
||||
|
||||
|
||||
.. _sim800l-send_sms_action:
|
||||
|
||||
|
|
@ -134,18 +183,11 @@ Configuration options:
|
|||
- **message** (**Required**, string, :ref:`templatable <config-templatable>`): The message content.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID of the SIM800L if you have multiple components.
|
||||
|
||||
.. note::
|
||||
|
||||
This action can also be written in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
id(sim800l1).send_sms("+15551234567", "The message content");
|
||||
|
||||
.. _sim800l-dial_action:
|
||||
|
||||
``sim800l.dial`` Action
|
||||
---------------------------
|
||||
-----------------------
|
||||
|
||||
Dial to a phone recipient using this action in automations.
|
||||
|
||||
|
|
@ -161,13 +203,41 @@ Configuration options:
|
|||
- **recipient** (**Required**, string, :ref:`templatable <config-templatable>`): The number to dial.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID of the SIM800L if you have multiple components.
|
||||
|
||||
.. note::
|
||||
|
||||
This action can also be written in :ref:`lambdas <config-lambda>`:
|
||||
``sim800l.connect`` Action
|
||||
--------------------------
|
||||
|
||||
.. code-block:: cpp
|
||||
Answers an incoming call.
|
||||
|
||||
id(sim800l1).dial("+15551234567");
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
- sim800l.connect
|
||||
|
||||
|
||||
``sim800l.disconnect`` Action
|
||||
-----------------------------
|
||||
|
||||
Disconnects a call, either dialed in or received.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
- sim800l.disconnect
|
||||
|
||||
|
||||
``sim800l.send_ussd`` Action
|
||||
----------------------------
|
||||
|
||||
Sends a ussd code to the network.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
- sim800l.send_ussd
|
||||
|
||||
|
||||
Getting started with Home Assistant
|
||||
|
|
@ -180,28 +250,46 @@ on Home Assistant and will also setup a service so you can send messages and dia
|
|||
|
||||
api:
|
||||
services:
|
||||
- service: send_sms
|
||||
variables:
|
||||
recipient: string
|
||||
message: string
|
||||
then:
|
||||
- sim800l.send_sms:
|
||||
recipient: !lambda 'return recipient;'
|
||||
message: !lambda 'return message;'
|
||||
- service: dial
|
||||
variables:
|
||||
recipient: string
|
||||
then:
|
||||
- sim800l.dial:
|
||||
recipient: !lambda 'return recipient;'
|
||||
- service: send_sms
|
||||
variables:
|
||||
recipient: string
|
||||
message: string
|
||||
then:
|
||||
- sim800l.send_sms:
|
||||
recipient: !lambda 'return recipient;'
|
||||
message: !lambda 'return message;'
|
||||
- service: dial
|
||||
variables:
|
||||
recipient: string
|
||||
then:
|
||||
- sim800l.dial:
|
||||
recipient: !lambda 'return recipient;'
|
||||
- service: connect
|
||||
then:
|
||||
- sim800l.connect
|
||||
- service: disconnect
|
||||
then:
|
||||
- sim800l.disconnect
|
||||
- service: send_ussd
|
||||
variables:
|
||||
ussdCode: string
|
||||
then:
|
||||
- sim800l.send_ussd:
|
||||
ussd: !lambda 'return ussdCode;'
|
||||
|
||||
text_sensor:
|
||||
- platform: template
|
||||
id: sms_sender
|
||||
name: "Sms Sender"
|
||||
- platform: template
|
||||
id: sms_message
|
||||
name: "Sms Message"
|
||||
- platform: template
|
||||
id: sms_sender
|
||||
name: "Sms Sender"
|
||||
- platform: template
|
||||
id: sms_message
|
||||
name: "Sms Message"
|
||||
- platform: template
|
||||
id: caller_id_text_sensor
|
||||
name: "Caller ID"
|
||||
- platform: template
|
||||
id: ussd_message
|
||||
name: "Ussd Code"
|
||||
|
||||
uart:
|
||||
baud_rate: 9600
|
||||
|
|
@ -210,9 +298,22 @@ on Home Assistant and will also setup a service so you can send messages and dia
|
|||
|
||||
sim800l:
|
||||
on_sms_received:
|
||||
- lambda: |-
|
||||
id(sms_sender).publish_state(sender);
|
||||
id(sms_message).publish_state(message);
|
||||
- lambda: |-
|
||||
id(sms_sender).publish_state(sender);
|
||||
id(sms_message).publish_state(message);
|
||||
on_incoming_call:
|
||||
- lambda: |-
|
||||
id(caller_id_text_sensor).publish_state(caller_id);
|
||||
on_call_connected:
|
||||
- logger.log:
|
||||
format: Call connected
|
||||
on_call_disconnected:
|
||||
- logger.log:
|
||||
format: Call disconnected
|
||||
on_ussd_received:
|
||||
- lambda: |-
|
||||
id(ussd_message).publish_state(ussd);
|
||||
|
||||
|
||||
Now your latest received SMS and sender number will be displayed by the text sensors.
|
||||
|
||||
|
|
@ -238,10 +339,10 @@ Relay management commands received from an authorized sender:
|
|||
|
||||
sim800l:
|
||||
on_sms_received:
|
||||
- lambda: |-
|
||||
if ( (id(sms_sender).state == "+79991234567") && ( (id(sms_message).state == "relay_1_on") OR (id(sms_message).state == "Relay_1_on") ) ) {
|
||||
id(relay_1).turn_on();
|
||||
}
|
||||
- lambda: |-
|
||||
if ( (id(sms_sender).state == "+79991234567") && ( (id(sms_message).state == "relay_1_on") OR (id(sms_message).state == "Relay_1_on") ) ) {
|
||||
id(relay_1).turn_on();
|
||||
}
|
||||
switch:
|
||||
- platform: gpio
|
||||
id: relay_1
|
||||
|
|
|
|||
|
|
@ -78,12 +78,12 @@ examples that are ready for you to copy and paste!
|
|||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **main_switch** (**Required** with more than one valve, *string*): The name for the sprinkler
|
||||
- **main_switch** (*Optional*, *string*): Required with more than one valve. The name for the sprinkler
|
||||
controller's main switch as it will appear in the front end. This switch, when turned on, calls the
|
||||
``sprinkler.resume_or_start_full_cycle`` action; when turned off, it calls the ``sprinkler.shutdown``
|
||||
action (see below). It will appear to be "on" when any valve on the controller is active. This switch
|
||||
will not appear in the front end if the controller is configured with only one valve.
|
||||
- **auto_advance_switch** (**Required** with more than one valve, *string*): The name for the
|
||||
- **auto_advance_switch** (*Optional*, *string*): Required with more than one valve. The name for the
|
||||
sprinkler controller's "auto-advance" switch as it will appear in the front end. When this switch is
|
||||
turned on while a valve is active, when the valve's ``run_duration`` is reached, the sprinkler
|
||||
controller will automatically advance to the next enabled valve as a part of a "full cycle" of the
|
||||
|
|
|
|||
|
|
@ -273,82 +273,22 @@ Configuration variables:
|
|||
Home Assistant Configuration
|
||||
----------------------------
|
||||
|
||||
This component will not show up in the Home Assistant front-end (Overview) automatically because
|
||||
Home Assistant does not support steppers natively.
|
||||
|
||||
You can add the stepper component code below to your Home Assistant configuration (``configuration.yaml``) to
|
||||
be able to control the stepper from the front-end.
|
||||
The easiest way to control your stepper from Home Assistant is to add a ``number`` to your ESPHome
|
||||
configuration. See :ref:`Number <config-number>` for more information.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Add a slider control to Home Assistant to set an integer value
|
||||
input_number:
|
||||
stepper_control:
|
||||
number:
|
||||
- platform: template
|
||||
name: Stepper Control
|
||||
initial: 0
|
||||
min: -1000
|
||||
max: 1000
|
||||
min_value: -100
|
||||
max_value: 100
|
||||
step: 1
|
||||
mode: slider
|
||||
|
||||
# Do something when the slider changes
|
||||
automation:
|
||||
- alias: Write Stepper Value to ESP
|
||||
trigger:
|
||||
platform: state
|
||||
entity_id: input_number.stepper_control
|
||||
action:
|
||||
# Replace livingroom with the name you gave the ESP
|
||||
- service: esphome.livingroom_control_stepper
|
||||
data_template:
|
||||
target: '{{ trigger.to_state.state | int }}'
|
||||
|
||||
In the above code, "stepper_control" is the ID of a numeric input field. It must be unique and it is
|
||||
used in the automation section as a reference name. The display name for this field is in
|
||||
stepper_control's ``name`` key.
|
||||
|
||||
If you want your user interface to give you more control over your stepper controller, such as
|
||||
setting the acceleration, deceleration, etc, then you can add more input fields after ``stepper_control``
|
||||
but before ``automation``. They can be a simple number-entry field (mode: box) or a slider like this.
|
||||
Each of these extra input fields needs an associated input parameter defined on the ESPHome device's
|
||||
API service.
|
||||
|
||||
The automation section tells Home Assistant what to do when the slider changes. It needs a trigger
|
||||
(state of the ``stepper_control`` slider) and an action. In the trigger section, ``entity_id`` must refer
|
||||
back to the configuration ID that triggers the automation. For us, that is the ``stepper_control``
|
||||
field in the ``input_number`` item. That's why the value is ``input_number.stepper_control``.
|
||||
|
||||
In the action section, the service name is vital to get right: it's the glue that connects Home Automation's
|
||||
front-end to the ESPHome device configuration. While you might expect the syntax to be ``esphome.<your_device>.<api_service>``,
|
||||
the correct syntax is to join the device ID to the API service ID with an underscore,
|
||||
as in ``esphome.livingroom_control_stepper`` where "Livingroom" is a device in ESPHome and "control_stepper" is an
|
||||
API service for that device.
|
||||
|
||||
The template string is used to get the "state" value from the ``target`` field (defined in the target section) on the
|
||||
``input_number`` component of the Home Assistant front-end. This value is then passed to the API service as defined in
|
||||
the ESPHome device's configuration. The ``data_template`` section lists one value for each of the input parameters on
|
||||
the service being called by the automation. In our case, the ESPHome device has an API service with a single parameter,
|
||||
"target". If you called this "my_target", then the last line above should be ``my_target: '{{ trigger.to_state.state | int }}'``.
|
||||
Getting this linkage right is very important.
|
||||
|
||||
The following code needs to go in the ESPHome configuration file for this device. Above, we mention "API service"
|
||||
a lot. This code is where that is defined. You may have already added it (or something similar). Note
|
||||
that the input variable for the ``control_stepper`` service is called ``target``. That's what matches with the
|
||||
automation configuration above. Also note that the variable ``target`` is defined as an integer. That means it
|
||||
must be an integer number, not a string.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# ESPHome configuration
|
||||
api:
|
||||
services:
|
||||
- service: control_stepper
|
||||
variables:
|
||||
target: int
|
||||
set_action:
|
||||
then:
|
||||
- stepper.set_target:
|
||||
id: my_stepper
|
||||
target: !lambda 'return target;'
|
||||
target: !lambda 'return x;'
|
||||
|
||||
stepper:
|
||||
- platform: ...
|
||||
|
|
|
|||
|
|
@ -0,0 +1,51 @@
|
|||
Factory Reset Switch
|
||||
====================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up switches that can remotely invalidate all ESPHome preferences stored in flash and reboot ESP.
|
||||
:image: restart.svg
|
||||
|
||||
The ``factory_reset`` switch allows you to remotely invalidate (reset) all ESPHome :ref:`preferences <preferences-flash_write_interval>` stored in flash memory and reboot your node.
|
||||
After reboot all states, parameters and variables will be reinitialized with their default values. This is useful:
|
||||
|
||||
- for devices preflashed with ESPHome to reset behavior back to factory state
|
||||
- in case of moving a device to a new environment or starting a new use-case (e.g. reset counters or state)
|
||||
- for privacy concerns when giving away a device
|
||||
|
||||
.. note::
|
||||
|
||||
**USE WITH GREAT CAUTION!** All credentials, global variables, counters and saved states stored in non-volatile memory will be lost with no chance of recovering them.
|
||||
Even raw reading of flash memory with ``esptool`` will not help, since data is physically erased from flash memory.
|
||||
|
||||
For devices configured using :doc:`captive portal </components/captive_portal>`, this will reset WiFi settings as well, thus making such devices offline.
|
||||
You'll need to be in close proximity to your device to configure it again using a built-in WiFi access point and captive portal.
|
||||
|
||||
|
||||
.. figure:: images/factory-rst-ui.png
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
switch:
|
||||
- platform: factory_reset
|
||||
name: Restart with Factory Default Settings
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **name** (**Required**, string): The name of the switch.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Switch <config-switch>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`shutdown`
|
||||
- :doc:`restart`
|
||||
- :doc:`safe_mode`
|
||||
- :doc:`/components/button/factory_reset`
|
||||
- :doc:`template`
|
||||
- :apiref:`factory_reset/factory_reset_switch.h`
|
||||
- :ghedit:`Edit`
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 8.4 KiB |
|
|
@ -29,9 +29,10 @@ Configuration variables:
|
|||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/button/restart`
|
||||
- :doc:`shutdown`
|
||||
- :doc:`safe_mode`
|
||||
- :doc:`factory_reset`
|
||||
- :doc:`/components/button/restart`
|
||||
- :doc:`template`
|
||||
- :apiref:`restart/switch/restart_switch.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -33,6 +33,8 @@ See Also
|
|||
|
||||
- :doc:`shutdown`
|
||||
- :doc:`restart`
|
||||
- :doc:`factory_reset`
|
||||
- :doc:`/components/button/safe_mode`
|
||||
- :doc:`template`
|
||||
- :apiref:`safe_mode/safe_mode_switch.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -32,6 +32,9 @@ See Also
|
|||
--------
|
||||
|
||||
- :doc:`restart`
|
||||
- :doc:`safe_mode`
|
||||
- :doc:`factory_reset`
|
||||
- :doc:`/components/button/shutdown`
|
||||
- :doc:`template`
|
||||
- :apiref:`shutdown/shutdown_switch.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
|
|
@ -80,7 +80,7 @@ See Also
|
|||
- :ref:`Binary Sensor Filters <binary_sensor-filters>`
|
||||
- :doc:`Inkplate 6 Plus </components/display/inkplate6>`
|
||||
- :doc:`EKTF2232 </components/touchscreen/ektf2232>`
|
||||
- :doc:`XPT2046 </components/binary_sensor/xpt2046>`
|
||||
- :doc:`XPT2046 </components/touchscreen/xpt2046>`
|
||||
- :apiref:`touchscreen/touchscreen.h`
|
||||
- :apiref:`touchscreen/binary_sensor/touchscreen_binary_sensor.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
XPT2046 Touch Screen Controller
|
||||
==================================
|
||||
XPT2046 Touch Screen Controller (Updated version)
|
||||
==================================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up XPT2046 touch screen controller with ESPHome
|
||||
|
|
@ -8,10 +8,7 @@ XPT2046 Touch Screen Controller
|
|||
|
||||
.. _xpt2046-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``xpt2046`` component allows using the touch screen controllers
|
||||
The ``xpt2046`` touchscreen platform allows using the touch screen controllers
|
||||
based on the XPT2046 chip
|
||||
(`datasheet <https://datasheetspdf.com/pdf-file/746665/XPTEK/XPT2046/1>`__,
|
||||
`AZ-Delivery`_) with ESPHome. Many cheap LCD displays contain this controller.
|
||||
|
|
@ -28,32 +25,20 @@ The :ref:`SPI <spi>` is required to be set up in your configuration for this sen
|
|||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
xpt2046:
|
||||
id: touchscreen
|
||||
touchscreen:
|
||||
platform: xpt2046
|
||||
id: my_touchscreen
|
||||
cs_pin: 17
|
||||
irq_pin: 16
|
||||
interrupt_pin: 16
|
||||
update_interval: 50ms
|
||||
report_interval: 1s
|
||||
threshold: 400
|
||||
dimension_x: 240
|
||||
dimension_y: 320
|
||||
calibration_x_min: 3860
|
||||
calibration_x_max: 280
|
||||
calibration_y_min: 340
|
||||
calibration_y_max: 3860
|
||||
swap_x_y: false
|
||||
|
||||
binary_sensor:
|
||||
- platform: xpt2046
|
||||
xpt2046_id: touchscreen
|
||||
id: touch_key0
|
||||
x_min: 80
|
||||
x_max: 160
|
||||
y_min: 106
|
||||
y_max: 212
|
||||
on_state:
|
||||
- lambda: 'ESP_LOGI("main", "key0: %s", (x ? "touch" : "release"));'
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
|
@ -66,12 +51,12 @@ Base Configuration:
|
|||
- **cs_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The chip select pin.
|
||||
Often marked ``T_CS`` on the board.
|
||||
|
||||
- **irq_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The touch detection pin.
|
||||
- **interrupt_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The touch detection pin.
|
||||
Often marked ``T_IRQ`` on the board. If not specified the component will use polling
|
||||
via SPI.
|
||||
via SPI. This key is renamed from **irq_pin**
|
||||
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the
|
||||
sensor. If ``irq_pin`` is specified the touch will be detected nearly instantaneously and this setting
|
||||
sensor. If ``interrupt_pin`` is specified the touch will be detected nearly instantaneously and this setting
|
||||
will be used only for the release detection. Defaults to ``50ms``.
|
||||
|
||||
- **report_interval** (*Optional*, :ref:`config-time`): The interval to periodically
|
||||
|
|
@ -79,12 +64,6 @@ Base Configuration:
|
|||
|
||||
- **threshold** (*Optional*, int): The value to detect the touch or release. Defaults to ``400``.
|
||||
|
||||
- **dimension_x** (*Optional*, int): The dimension of the display in the horizontal
|
||||
direction. Usually in pixels but a percentage can be useful as well. Defaults to ``100``.
|
||||
|
||||
- **dimension_y** (*Optional*, int): The dimension of the display in the vertical
|
||||
direction. Usually in pixels but a percentage can be useful as well. Defaults to ``100``.
|
||||
|
||||
- **calibration_x_min** (*Optional*, int): The raw value corresponding to the left
|
||||
(or top if ``swap_x_y`` is specified) edge of the display. See :ref:`xpt2046-calibration`
|
||||
for the process to calibrate the touch screen. Defaults to ``0``.
|
||||
|
|
@ -100,65 +79,8 @@ Base Configuration:
|
|||
|
||||
- **swap_x_y** (*Optional*, boolean): If true the x and y axes are swapped. Defaults to ``false``.
|
||||
|
||||
- **on_state** (*Optional*, :ref:`Automation <automation>`): An automation to perform
|
||||
when the touch screen is pressed or released. See :ref:`xpt2046-on_state`.
|
||||
- All other options from :ref:`config-touchscreen`.
|
||||
|
||||
.. _xpt2046-on_state:
|
||||
|
||||
``on_state`` Action
|
||||
-------------------
|
||||
|
||||
This automation will be triggered when the XPT2046 touch screen detects a touch, a release
|
||||
or periodically each ``report_interval`` while touched.
|
||||
|
||||
This trigger provides three arguments: ``x`` and ``y`` are of the type int and specify the
|
||||
coordinates of the touch and a bool ``touched`` specifying whether a touch or release was
|
||||
detected.
|
||||
|
||||
Additionally to the coordinates, the touch status and the raw values needed for the calibration
|
||||
can be accessed as member variables.
|
||||
|
||||
The following code
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
xpt2046:
|
||||
on_state:
|
||||
- lambda: |-
|
||||
ESP_LOGI("main", "args x=%d, y=%d, touched=%s", x, y, (touched ? "touch" : "release"));
|
||||
ESP_LOGI("main", "member x=%d, y=%d, touched=%d, x_raw=%d, y_raw=%d, z_raw=%d",
|
||||
id(touchscreen).x,
|
||||
id(touchscreen).y,
|
||||
(int) id(touchscreen).touched,
|
||||
id(touchscreen).x_raw,
|
||||
id(touchscreen).y_raw,
|
||||
id(touchscreen).z_raw
|
||||
);
|
||||
|
||||
produces
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
[20:17:37][I][main:065]: args x=145, y=261, touched=touch
|
||||
[20:17:37][I][main:073]: member x=145, y=261, touched=1, x_raw=1686, y_raw=3218, z_raw=424
|
||||
[20:17:37][I][main:065]: args x=145, y=261, touched=release
|
||||
[20:17:37][I][main:073]: member x=145, y=261, touched=0, x_raw=0, y_raw=0, z_raw=0
|
||||
|
||||
Binary Sensor
|
||||
-------------
|
||||
|
||||
The ``xpt2046`` binary sensor allows you to setup areas on the touch screen as virtual
|
||||
buttons. First, setup a :ref:`xpt2046-component` and then use this binary sensor platform
|
||||
to create individual binary sensors for each virtual button.
|
||||
|
||||
- **name** (*Optional*, string): The name for the binary sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **xpt2046_id** (*Optional*, :ref:`config-id`): Specify the ID of the component the sensor is part of. Useful when you have more than one touch screen.
|
||||
- **x_min** (**Required**, int): Left coordinate of the screen area to be detected as the virtual button.
|
||||
- **x_max** (**Required**, int): Right coordinate of the screen area to be detected as the virtual button.
|
||||
- **y_min** (**Required**, int): Top coordinate of the screen area to be detected as the virtual button.
|
||||
- **y_max** (**Required**, int): Bottom coordinate of the screen area to be detected as the virtual button.
|
||||
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
|
||||
.. _xpt2046-calibration:
|
||||
|
||||
|
|
@ -168,7 +90,7 @@ Calibration
|
|||
To match the point of the touch to the display coordinates the touch screen has to be calibrated.
|
||||
The XPT2046 component returns raw values in the 0 to 4095 range. Those raw values are available
|
||||
as the ``x_raw`` and ``y_raw`` member variables and for example write them out as in the example
|
||||
:ref:`xpt2046-on_state`. The goal of the calibration is to identify the raw values corresponding
|
||||
:ref:`touchscreen-on_touch`. The goal of the calibration is to identify the raw values corresponding
|
||||
to the edges of the screen.
|
||||
|
||||
The calibration assumes a display oriented in a way that you will be using it, i.e. your
|
||||
|
|
@ -179,20 +101,17 @@ values nor ``swap_x_y``.
|
|||
.. code-block:: yaml
|
||||
|
||||
# Touchscreen
|
||||
xpt2046:
|
||||
id: touchscreen
|
||||
touchscreen:
|
||||
platform: xpt2046
|
||||
id: my_touchscreen
|
||||
cs_pin: 17
|
||||
irq_pin: 16
|
||||
dimension_x: 240
|
||||
dimension_y: 320
|
||||
on_state:
|
||||
on_touch:
|
||||
- lambda: |-
|
||||
if (touched)
|
||||
ESP_LOGI("cal", "x=%d, y=%d, x_raw=%d, y_raw=%d",
|
||||
id(touchscreen).x,
|
||||
id(touchscreen).y,
|
||||
id(touchscreen).x_raw,
|
||||
id(touchscreen).y_raw
|
||||
ESP_LOGI("cal", "x=%d, y=%d, x_raw=%d, y_raw=%0d",
|
||||
id(my_touchscreen).x,
|
||||
id(my_touchscreen).y,
|
||||
id(my_touchscreen).x_raw,
|
||||
id(my_touchscreen).y_raw
|
||||
);
|
||||
|
||||
Get a stylus or a similar object, run the project and touch the corners of the screen at
|
||||
|
|
@ -230,7 +149,8 @@ The vertical direction is fine. The configuration would thus be
|
|||
|
||||
.. code-block:: yaml
|
||||
|
||||
xpt2046:
|
||||
touchscreen:
|
||||
platform: xpt2046
|
||||
calibration_x_min: 3848
|
||||
calibration_x_max: 281
|
||||
calibration_y_min: 347
|
||||
|
|
@ -250,14 +170,14 @@ Note that the touch screen is not extremely precise and there might be nonlinear
|
|||
or similar errors so don't expect a pixel-perfect precision. You can verify the touchpoint
|
||||
using a display lambda similar to the following.
|
||||
|
||||
.. code-block:: none
|
||||
.. code-block:: yaml
|
||||
|
||||
display:
|
||||
- platform: ili9341
|
||||
lambda: |-
|
||||
it.fill(BLACK);
|
||||
if (id(touchscreen).touched)
|
||||
it.filled_circle(id(touchscreen).x, id(touchscreen).y, 10, RED);
|
||||
if (id(my_touchscreen).touched)
|
||||
it.filled_circle(id(my_touchscreen).x, id(my_touchscreen).y, 10, RED);
|
||||
|
||||
To be exact, the component does the following
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ The type of ``x`` variable is depending on ``datapoint_type`` configuration vari
|
|||
datapoint_type: raw
|
||||
then:
|
||||
- lambda: |-
|
||||
ESP_LOGD("main", "on_datapoint_update %s", hexencode(x).c_str());
|
||||
ESP_LOGD("main", "on_datapoint_update %s", format_hex_pretty(x).c_str());
|
||||
id(voltage).publish_state((x[0] << 8 | x[1]) * 0.1);
|
||||
id(current).publish_state((x[3] << 8 | x[4]) * 0.001);
|
||||
id(power).publish_state((x[6] << 8 | x[7]) * 0.1);
|
||||
|
|
@ -126,7 +126,7 @@ The type of ``x`` variable is depending on ``datapoint_type`` configuration vari
|
|||
then:
|
||||
- lambda: |-
|
||||
if (x.type == tuya::TuyaDatapointType::RAW) {
|
||||
ESP_LOGD("main", "on_datapoint_update %s", hexencode(x.value_raw).c_str());
|
||||
ESP_LOGD("main", "on_datapoint_update %s", format_hex_pretty(x.value_raw).c_str());
|
||||
} else {
|
||||
ESP_LOGD("main", "on_datapoint_update %hhu", x.type);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -85,6 +85,9 @@ Configuration variables:
|
|||
The downside is that this option connects to the first network the ESP sees, even if that network is very far away and
|
||||
better ones are available.
|
||||
|
||||
- **enable_btm** (*Optional*, bool): Only on ``esp32`` with ``esp-idf``. Enable 802.11v BSS Transition Management support.
|
||||
- **enable_rrm** (*Optional*, bool): Only on ``esp32`` with ``esp-idf``. Enable 802.11k Radio Resource Management support.
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
Access Point Mode
|
||||
|
|
|
|||
7
conf.py
7
conf.py
|
|
@ -39,7 +39,8 @@ sys.path.append(os.path.abspath("."))
|
|||
extensions = [
|
||||
"github",
|
||||
"seo",
|
||||
"sitemap",
|
||||
"components",
|
||||
"sitemap"
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
|
|
@ -66,9 +67,9 @@ author = "ESPHome"
|
|||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
version = "2022.8"
|
||||
version = "2022.10"
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = "2022.8.0"
|
||||
release = "2022.10.2"
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
|
|
|
|||
|
|
@ -55,6 +55,7 @@ Configuration example:
|
|||
# a notification is received, the corresponding binary_sensor
|
||||
# is briefly toggled.
|
||||
- platform: ble_client
|
||||
type: characteristic
|
||||
ble_client_id: itag_black
|
||||
name: "Black iTag btn"
|
||||
service_uuid: 'ffe0'
|
||||
|
|
@ -73,12 +74,18 @@ Configuration example:
|
|||
# support this characteristic, you will see 'Unknown' in the
|
||||
# HA frontend.
|
||||
- platform: ble_client
|
||||
type: characteristic
|
||||
ble_client_id: itag_black
|
||||
name: "Black iTag Battery"
|
||||
service_uuid: '180f'
|
||||
characteristic_uuid: '2a19'
|
||||
icon: 'mdi:battery'
|
||||
unit_of_measurement: '%'
|
||||
# This entry queries polls the RSSI when the tag is connected.
|
||||
- platform: ble_client
|
||||
type: rssi
|
||||
ble_client_id: itag_black
|
||||
name: "Black iTag RSSI"
|
||||
|
||||
Explanation
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Cookbook
|
||||
Devices
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -274,7 +274,7 @@ global variables can be used to store the state of a garage door.
|
|||
- id: my_global_string
|
||||
type: std::string
|
||||
restore_value: no # Strings cannot be saved/restored
|
||||
initial_value: '"hello world"'
|
||||
initial_value: '"Global value is"'
|
||||
|
||||
# In an automation
|
||||
on_press:
|
||||
|
|
@ -287,7 +287,7 @@ global variables can be used to store the state of a garage door.
|
|||
id(my_global_int) += 10;
|
||||
}
|
||||
|
||||
ESP_LOGD(TAG, "Global value is: %d", id(my_global_int));
|
||||
ESP_LOGD(TAG, "%s: %d", id(my_global_string), id(my_global_int));
|
||||
|
||||
Configuration variables:
|
||||
|
||||
|
|
@ -337,7 +337,6 @@ All Triggers
|
|||
- :ref:`switch.on_turn_on / switch.on_turn_off <switch-on_turn_on_off_trigger>`
|
||||
- :doc:`remote_receiver.on_* </components/remote_receiver>`
|
||||
- :doc:`sun.on_sunrise </components/sun>` / :doc:`sun.on_sunset </components/sun>`
|
||||
- :ref:`switch.on_turn_on/off <switch-on_turn_on_off_trigger>`
|
||||
- :ref:`sim800l.on_sms_received <sim800l-on_sms_received>`
|
||||
- :ref:`rf_bridge.on_code_received <rf_bridge-on_code_received>`
|
||||
- :ref:`ota.on_begin <ota-on_begin>` / :ref:`ota.on_progress <ota-on_progress>` /
|
||||
|
|
@ -731,6 +730,12 @@ script was already running.
|
|||
then:
|
||||
- script.execute: my_script
|
||||
|
||||
or as lambda
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
lambda: 'id(my_script).execute();'
|
||||
|
||||
.. _script-stop_action:
|
||||
|
||||
``script.stop`` Action
|
||||
|
|
@ -758,6 +763,12 @@ will not be executed.
|
|||
then:
|
||||
- script.stop: my_script
|
||||
|
||||
or as lambda
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
lambda: 'id(my_script).stop();'
|
||||
|
||||
.. _script-wait_action:
|
||||
|
||||
``script.wait`` Action
|
||||
|
|
@ -784,6 +795,8 @@ of the script are running in parallel, this will block until all of them have te
|
|||
- script.execute: my_script
|
||||
- script.wait: my_script
|
||||
|
||||
This can't be used in a lambda as it would block all functioning of the device. The script wouldn't even get to run.
|
||||
|
||||
.. _script-is_running_condition:
|
||||
|
||||
``script.is_running`` Condition
|
||||
|
|
@ -802,6 +815,15 @@ of the given id is running, not how many.
|
|||
then:
|
||||
- logger.log: Script is running!
|
||||
|
||||
or as lambda
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
lambda: -|
|
||||
if(id(my_script).is_running() {
|
||||
ESP_LOGI("main", "Script is running!");
|
||||
}
|
||||
|
||||
.. _for_condition:
|
||||
|
||||
``for`` Condition
|
||||
|
|
|
|||
|
|
@ -272,6 +272,10 @@ config in the main yaml file. All definitions from packages will be merged with
|
|||
config in non-destructive way so you could always override some bits and pieces of package
|
||||
configuration.
|
||||
|
||||
Dictionaries are merged key-by-key. Lists of components are merged by component
|
||||
ID if specified. Other lists are merged by concatenation. All other config
|
||||
values are replaced with the later value.
|
||||
|
||||
Local packages
|
||||
**************
|
||||
|
||||
|
|
|
|||
|
|
@ -681,32 +681,6 @@ Standard for the esphome-core codebase:
|
|||
|
||||
|
||||
|
||||
ESPHome via Gitpod
|
||||
******************
|
||||
|
||||
An alternative to a local checkout and build is doing so via `Gitpod <https://www.gitpod.io>`__.
|
||||
ESPHome will be installed for you and the dashboard wizard will run on startup.
|
||||
|
||||
You can also run the steps manually.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
python setup.py install
|
||||
|
||||
To start a command line wizard, run
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
python esphome my_configuration.yaml wizard
|
||||
|
||||
To get the web-based dashboard, use
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
python esphome my_configuration.yaml dashboard
|
||||
|
||||
and allow exposing the web app at port 6052.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue