mirror of
https://github.com/esphome/esphome-docs.git
synced 2025-03-01 03:51:36 +01:00
Jesse Hills
GitHub
commit
5cf630b4b7
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 = 2024.5.5
|
||||
PROJECT_NUMBER = 2024.6.0b1
|
||||
|
||||
# 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 = 2024.5.5
|
||||
ESPHOME_REF = 2024.6.0b1
|
||||
PAGEFIND_VERSION=1.1.0
|
||||
PAGEFIND=pagefind
|
||||
NET_PAGEFIND=../pagefindbin/pagefind
|
||||
|
||||
@ -1 +1 @@
|
||||
2024.5.5
|
||||
2024.6.0b1
|
||||
348
changelog/2024.6.0.rst
Normal file
348
changelog/2024.6.0.rst
Normal file
@ -0,0 +1,348 @@
|
||||
ESPHome 2024.6.0 - 19th June 2024
|
||||
=================================
|
||||
|
||||
.. seo::
|
||||
:description: Changelog for ESPHome 2024.5.0.
|
||||
:image: /_static/changelog-2024.5.0.png
|
||||
:author: Jesse Hills
|
||||
:author_twitter: @jesserockz
|
||||
|
||||
.. imgtable::
|
||||
:columns: 3
|
||||
|
||||
ESPHome OTA Updates, components/ota, system-update.svg, dark-invert
|
||||
HTTP Request OTA Updates, components/ota_http_request, system-update.svg, dark-invert
|
||||
Managed Updates, components/update/http_request, system-update.svg, dark-invert
|
||||
|
||||
1-Wire, components/one_wire, one-wire.svg
|
||||
GDK101, components/sensor/gdk101, gdk101.jpg
|
||||
Beken SPI, components/light/beken_spi_led_strip, color_lens.svg, dark-invert
|
||||
|
||||
INA2XX, components/sensor/ina2xx, ina2xx.jpg
|
||||
LTR Light & Proximity Sensors, components/sensor/ltr_als_ps, ltr329.jpg, Lux
|
||||
Host SDL2 display, components/display/sdl, sdl.png
|
||||
|
||||
.. |ss| raw:: html
|
||||
|
||||
<strike>
|
||||
|
||||
.. |se| raw:: html
|
||||
|
||||
</strike>
|
||||
|
||||
An update on updates
|
||||
--------------------
|
||||
|
||||
So we have a few updates to update you on this |ss| update |se| release.
|
||||
Please do read these release notes carefully as there are quite a few breaking changes that
|
||||
we know will affect a large portion of users.
|
||||
|
||||
ESPHome branding
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
In April, Nabu Casa donated ESPHome to the newly found Open Home Foundation. This foundation,
|
||||
which also owns Home Assistant, fights for the rights of privacy, choice and sustainability
|
||||
of the smart home - and everyone that lives in one. This was done to create a bulwark against
|
||||
surveillance capitalism, the risk of buyout, and open-source projects becoming abandonware.
|
||||
To an extent, this protection extends even against our future selves—so that smart home users
|
||||
can continue to benefit for years, if not decades. No matter what comes.
|
||||
|
||||
As part of this new governance, we decided to align the branding of Home Assistant and ESPHome,
|
||||
the two consumer facing projects of the foundation, to communicate that we share a common vision.
|
||||
|
||||
This change has not had any impact on the day-to-day of ESPHome.
|
||||
Both Keith and myself will remain full-time employed at Nabu Casa, a commercial partner of
|
||||
the Open Home Foundation, to further develop ESPHome to be the best way for anyone to create
|
||||
smart home devices. To support our work,
|
||||
`subscribe to Home Assistant Cloud by Nabu Casa <https://www.nabucasa.com/>`__.
|
||||
|
||||
`Learn more about the Open Home Foundation <https://www.openhomefoundation.org/blog/announcing-the-open-home-foundation/>`__
|
||||
|
||||
Update Entities
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
So, we created ``update`` entities. These are similar to the ones that Home Assistant shows now when
|
||||
you have the ESPHome Add-on installed in Home Assistant OS, except those ones show you an update to the
|
||||
version of the ESPHome Add-on and in the background will compile and upload new firmware to your device.
|
||||
|
||||
These new ``update`` entities are a bit different. If you have acquired a device that was pre-installed
|
||||
with ESPHome, the vendor you acquired the device from is now able to compile the firmware and host it
|
||||
on a website along with a description of the firmware the device can read and present that there is an
|
||||
update available for this device. You do not need to adopt the device into the ESPHome dashboard, and
|
||||
you don't actually need the ESPHome dashboard installed. Using the new ``http_request`` OTA platform,
|
||||
the device will be able to download the firmware and update itself.
|
||||
|
||||
OTA Platforms
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
With the above mentioned ``http_request`` OTA platform, we made the decision to split out the current
|
||||
``ota`` server to its own platform to make the code more managable and to allow for more flexibility going forward.
|
||||
|
||||
Because of this, all configurations that currently have ``ota:`` in them will fail to validate after
|
||||
updating to this release.
|
||||
|
||||
You will need to change the configuration by adding a new line as below:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Old
|
||||
ota:
|
||||
|
||||
ota:
|
||||
password: "xxxx"
|
||||
|
||||
# New
|
||||
ota:
|
||||
platform: esphome
|
||||
|
||||
ota:
|
||||
platform: esphome
|
||||
password: "xxxx"
|
||||
|
||||
As part of this change also, :doc:`safe_mode </components/safe_mode>` has been pulled out into its own top level component.
|
||||
It is automatically included in any configuration that has an ``ota`` configuration block, so there is nothing you
|
||||
need to do unless you were overriding some of the safe mode specific configurations.
|
||||
|
||||
1-Wire
|
||||
^^^^^^
|
||||
|
||||
Up until now, the ``dallas`` sensor platform contained the only 1-wire implementation in ESPHome.
|
||||
There had been requests to add support for other 1-wire based components, so :ghuser:`ssieb` has
|
||||
made a new top level :doc:`1-wire </components/one_wire>` component that will allow for this.
|
||||
In doing so, the ``dallas`` sensor platform has been removed, and replaced with ``dallas_temp``
|
||||
to allow for other Dallas sensors to be implemented that are not temperature sensors.
|
||||
|
||||
HTTP(s) Requests
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The :doc:`http_request </components/http_request>` platform has been rewritten in this release to
|
||||
add support when using ESP-IDF or when using the :doc:`rp2040 </components/rp2040>` platform. This will
|
||||
also allow other ESPHome components to make HTTP(s) requests which includes the new ``http_request`` OTA platform and the
|
||||
``update`` entities.
|
||||
|
||||
As part of this, the configuration has been changed quite a bit so please read the documentation for the latest
|
||||
configuration options.
|
||||
|
||||
JSON parsing
|
||||
^^^^^^^^^^^^
|
||||
|
||||
An internal helper component ``json`` has had some minor, but breaking changes that now require the parsing
|
||||
callback function to return a boolean value, representing whether the parsing was successful or not.
|
||||
This is mostly an internal change, but could be used by :doc:`external components </components/external_components>`
|
||||
or lambdas in YAML.
|
||||
|
||||
|
||||
Full list of changes
|
||||
--------------------
|
||||
|
||||
New Features
|
||||
^^^^^^^^^^^^
|
||||
|
||||
- Add ADC multisampling :esphomepr:`6330` by :ghuser:`Mat931` (new-feature)
|
||||
- [voice_assistant] Timers :esphomepr:`6821` by :ghuser:`jesserockz` (new-feature)
|
||||
|
||||
New Components
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
- GDK101 support :esphomepr:`4703` by :ghuser:`Szewcson` (new-integration)
|
||||
- Add beken_spi_led_strip component :esphomepr:`6515` by :ghuser:`Mat931` (new-integration)
|
||||
- Separate ``OTABackend`` from OTA component :esphomepr:`6459` by :ghuser:`kbx81` (new-integration) (breaking-change)
|
||||
- SPI and I2C for ENS160 :esphomepr:`6369` by :ghuser:`latonita` (new-integration) (breaking-change)
|
||||
- INA228/INA229, INA238/INA239, INA237 power/energy/charge monitor (I2C, SPI) :esphomepr:`6138` by :ghuser:`latonita` (new-integration)
|
||||
- [haier] ``text_sensor`` and ``button`` platforms :esphomepr:`6780` by :ghuser:`paveldn` (new-integration)
|
||||
- LTR-303, LTR-329, LTR-553, LTR-556, LTR-559, LTR-659 Series of Lite-On Light (ALS) and Proximity(PS) sensors :esphomepr:`6076` by :ghuser:`latonita` (new-integration)
|
||||
- Add host time platform; remove host support from sntp. :esphomepr:`6854` by :ghuser:`clydebarrow` (new-integration)
|
||||
- [ota] http_request update platform :esphomepr:`5586` by :ghuser:`oarcher` (new-integration)
|
||||
- [core] Update Entities :esphomepr:`6885` by :ghuser:`jesserockz` (new-integration)
|
||||
- New 1-wire component :esphomepr:`6860` by :ghuser:`ssieb` (new-integration) (breaking-change)
|
||||
- [display] SDL2 display driver for host platform :esphomepr:`6825` by :ghuser:`clydebarrow` (new-integration)
|
||||
|
||||
New Platforms
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
- BedJet: expose the outlet temperature on the climate and as a sensor :esphomepr:`6633` by :ghuser:`javawizard` (new-platform)
|
||||
- mpr121: Add GPIO support :esphomepr:`6776` by :ghuser:`polyfloyd` (new-platform)
|
||||
|
||||
Breaking Changes
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
- Separate ``OTABackend`` from OTA component :esphomepr:`6459` by :ghuser:`kbx81` (new-integration) (breaking-change)
|
||||
- SPI and I2C for ENS160 :esphomepr:`6369` by :ghuser:`latonita` (new-integration) (breaking-change)
|
||||
- Uncouple safe_mode from OTA :esphomepr:`6759` by :ghuser:`kbx81` (breaking-change)
|
||||
- Fix incorrect naming of the AdaFruit MagTag display. :esphomepr:`6810` by :ghuser:`sasodoma` (breaking-change)
|
||||
- [http_request] Add esp-idf and rp2040 support :esphomepr:`3256` by :ghuser:`jesserockz` (breaking-change)
|
||||
- Allow parse_json to return a boolean result :esphomepr:`6884` by :ghuser:`jesserockz` (breaking-change)
|
||||
- New 1-wire component :esphomepr:`6860` by :ghuser:`ssieb` (new-integration) (breaking-change)
|
||||
|
||||
All changes
|
||||
^^^^^^^^^^^
|
||||
|
||||
- Add IRK support to ble_rssi :esphomepr:`6422` by :ghuser:`chbmuc`
|
||||
- Add new Error type to skip prepending path :esphomepr:`6716` by :ghuser:`jesserockz`
|
||||
- [github] Only save platformio cache for dev branch :esphomepr:`6711` by :ghuser:`jesserockz`
|
||||
- Only cache docker images on dev branch :esphomepr:`6714` by :ghuser:`jesserockz`
|
||||
- Add pylint to git pre-commit hooks :esphomepr:`6726` by :ghuser:`clydebarrow`
|
||||
- separate debug component for each platform in different file :esphomepr:`6715` by :ghuser:`tomaszduda23`
|
||||
- GDK101 support :esphomepr:`4703` by :ghuser:`Szewcson` (new-integration)
|
||||
- Typing hint and doc fixes :esphomepr:`6729` by :ghuser:`clydebarrow`
|
||||
- time_based_cover.cpp with manual control fix :esphomepr:`6719` by :ghuser:`Jorge-Crespo-Celdran`
|
||||
- [CST816] Add support for Hynitron Microelectronics CST826 capacitive touch :esphomepr:`6682` by :ghuser:`lboue`
|
||||
- Bump pytest from 8.1.1 to 8.2.0 :esphomepr:`6732` by :ghuser:`dependabot[bot]`
|
||||
- [web_server] Minor python formatting :esphomepr:`6735` by :ghuser:`jesserockz`
|
||||
- [esp32_ble] Fix compilation error on esp32c6 :esphomepr:`6734` by :ghuser:`jesserockz`
|
||||
- [core] Fix minor formatting issues :esphomepr:`6738` by :ghuser:`jesserockz`
|
||||
- [config] Improve error reporting :esphomepr:`6736` by :ghuser:`clydebarrow`
|
||||
- [tests] ``test2.yaml`` has become too large :esphomepr:`6750` by :ghuser:`kbx81`
|
||||
- Bump esphome-dashboard from 20240412.0 to 20240429.1 :esphomepr:`6743` by :ghuser:`dependabot[bot]`
|
||||
- BedJet: expose the outlet temperature on the climate and as a sensor :esphomepr:`6633` by :ghuser:`javawizard` (new-platform)
|
||||
- Add beken_spi_led_strip component :esphomepr:`6515` by :ghuser:`Mat931` (new-integration)
|
||||
- i2c: fix format string specifiers :esphomepr:`6746` by :ghuser:`ius`
|
||||
- Allow one timing to cancel others :esphomepr:`6744` by :ghuser:`lbilger`
|
||||
- fix rp2040_pio_led flicker and proper multi-strip support :esphomepr:`6194` by :ghuser:`Papa-DMan`
|
||||
- Mirage remote receiver & transmitter :esphomepr:`6479` by :ghuser:`heggi`
|
||||
- WPA2 Enterprise - Explicitly set TTLS Phase 2 :esphomepr:`6436` by :ghuser:`shxshxshxshx`
|
||||
- Fix Prometheus Output to Match Spec :esphomepr:`6032` by :ghuser:`sdwilsh`
|
||||
- Skip gpio validation :esphomepr:`5615` by :ghuser:`amcfague`
|
||||
- [core] Migrate to pyproject.toml :esphomepr:`6737` by :ghuser:`jesserockz`
|
||||
- [core] Move pytest config into pyproject.toml :esphomepr:`6740` by :ghuser:`jesserockz`
|
||||
- [core] Move pylint config into pyproject.toml :esphomepr:`6739` by :ghuser:`jesserockz`
|
||||
- [core] Fix running pylint via pre-commit from GUI apps :esphomepr:`6754` by :ghuser:`jesserockz`
|
||||
- Separate ``OTABackend`` from OTA component :esphomepr:`6459` by :ghuser:`kbx81` (new-integration) (breaking-change)
|
||||
- Add ADC multisampling :esphomepr:`6330` by :ghuser:`Mat931` (new-feature)
|
||||
- [core] Fix some extends cases :esphomepr:`6748` by :ghuser:`jesserockz`
|
||||
- Port wifi_component_esp32_arduino from tcpip_adapter to esp_netif :esphomepr:`6476` by :ghuser:`paravoid`
|
||||
- SPI and I2C for ENS160 :esphomepr:`6369` by :ghuser:`latonita` (new-integration) (breaking-change)
|
||||
- Fix wifi compile error on IDF 5.1+ :esphomepr:`6756` by :ghuser:`kbx81`
|
||||
- [core] Update some coroutine priorities :esphomepr:`6755` by :ghuser:`jesserockz`
|
||||
- INA228/INA229, INA238/INA239, INA237 power/energy/charge monitor (I2C, SPI) :esphomepr:`6138` by :ghuser:`latonita` (new-integration)
|
||||
- [nextion] Fix type on sprintf for IDF v5 :esphomepr:`6758` by :ghuser:`edwardtfn`
|
||||
- [core] Remove references to deleted setup.py :esphomepr:`6757` by :ghuser:`jesserockz`
|
||||
- Fix pip3 install :esphomepr:`6771` by :ghuser:`syssi`
|
||||
- [tests] make test_build_components work with venv without installing esphome :esphomepr:`6761` by :ghuser:`tomaszduda23`
|
||||
- separate deep_sleep component for each platform in different file :esphomepr:`6762` by :ghuser:`tomaszduda23`
|
||||
- Bump actions/checkout from 4.1.5 to 4.1.6 :esphomepr:`6764` by :ghuser:`dependabot[bot]`
|
||||
- add rp2040 support to the wizard :esphomepr:`6239` by :ghuser:`fodfodfod`
|
||||
- [ili9xxx] Add 18bit mode selection and custom init sequence :esphomepr:`6745` by :ghuser:`clydebarrow`
|
||||
- Tiny fix in automation.h - unused return value removed :esphomepr:`6760` by :ghuser:`latonita`
|
||||
- Uncouple safe_mode from OTA :esphomepr:`6759` by :ghuser:`kbx81` (breaking-change)
|
||||
- Add support for acting as Modbus server :esphomepr:`4874` by :ghuser:`JeroenVanOort`
|
||||
- Add on_safe_mode trigger :esphomepr:`6790` by :ghuser:`kbx81`
|
||||
- [sx1509] Output open drain pin mode :esphomepr:`6788` by :ghuser:`Swamp-Ig`
|
||||
- [ledc] Change some logging lines from debug to verbose :esphomepr:`6796` by :ghuser:`jesserockz`
|
||||
- [haier] ``text_sensor`` and ``button`` platforms :esphomepr:`6780` by :ghuser:`paveldn` (new-integration)
|
||||
- mpr121: Add GPIO support :esphomepr:`6776` by :ghuser:`polyfloyd` (new-platform)
|
||||
- [nextion] Add basic functions to Intelligent series :esphomepr:`6791` by :ghuser:`edwardtfn`
|
||||
- Fix incorrect naming of the AdaFruit MagTag display. :esphomepr:`6810` by :ghuser:`sasodoma` (breaking-change)
|
||||
- [tuya] add support for extended services :esphomepr:`6808` by :ghuser:`augs`
|
||||
- fix libretiny regression from #6715 :esphomepr:`6806` by :ghuser:`augs`
|
||||
- Make i2s_audio compatible with IDF 5+ :esphomepr:`6534` by :ghuser:`pimdo`
|
||||
- Fix compile errors on ESP32-C6 with latest ESP-IDF :esphomepr:`6822` by :ghuser:`DAVe3283`
|
||||
- Use uint8_t instead of uint32_t for 8-bit values on mitsubishi :esphomepr:`6824` by :ghuser:`DAVe3283`
|
||||
- Make SPI Ethernet (W5500) compatible with ESP-IDF v5 :esphomepr:`6778` by :ghuser:`fightforlife`
|
||||
- [wake_on_lan] Make component platform independent :esphomepr:`6815` by :ghuser:`clydebarrow`
|
||||
- Fix a bunch of components for IDF 5 compatibility and #6802 :esphomepr:`6805` by :ghuser:`kbx81`
|
||||
- Bump docker/login-action from 3.1.0 to 3.2.0 :esphomepr:`6823` by :ghuser:`dependabot[bot]`
|
||||
- Bump pytest-cov from 4.1.0 to 5.0.0 :esphomepr:`6580` by :ghuser:`dependabot[bot]`
|
||||
- Bump peter-evans/create-pull-request from 6.0.4 to 6.0.5 :esphomepr:`6635` by :ghuser:`dependabot[bot]`
|
||||
- Bump black from 24.4.0 to 24.4.2 :esphomepr:`6646` by :ghuser:`dependabot[bot]`
|
||||
- [voice_assistant] Timers :esphomepr:`6821` by :ghuser:`jesserockz` (new-feature)
|
||||
- [web_server] add entity sorting for v3 :esphomepr:`6445` by :ghuser:`RFDarter`
|
||||
- [micro_wake_word] Ensure model string is Path :esphomepr:`6826` by :ghuser:`synesthesiam`
|
||||
- Fix DHT reading timing for SI7021 on ESP32 :esphomepr:`6604` by :ghuser:`erdembey`
|
||||
- [core] Const-ify some Component fields :esphomepr:`6831` by :ghuser:`jesserockz`
|
||||
- LTR-303, LTR-329, LTR-553, LTR-556, LTR-559, LTR-659 Series of Lite-On Light (ALS) and Proximity(PS) sensors :esphomepr:`6076` by :ghuser:`latonita` (new-integration)
|
||||
- Update const.py added missing millimeter :esphomepr:`6834` by :ghuser:`NonaSuomy`
|
||||
- Fix log message in VA for IDF 5 :esphomepr:`6839` by :ghuser:`kbx81`
|
||||
- Replace random non-ascii-print characters with standard substitutes :esphomepr:`6840` by :ghuser:`ptr727`
|
||||
- Wireguard support for bk72 microcontrollers :esphomepr:`6842` by :ghuser:`droscy`
|
||||
- Add messages when WiFi and Ethernet components set 'warning' flag. :esphomepr:`6850` by :ghuser:`kpfleming`
|
||||
- [sntp] fix for ESP-IDF > 5.0 :esphomepr:`6769` by :ghuser:`HeMan`
|
||||
- Avoid unsafe git error when container user and file config volume permissions don't match :esphomepr:`6843` by :ghuser:`ptr727`
|
||||
- Add Ethernet MAC address to ethernet_info :esphomepr:`6835` by :ghuser:`ptr727`
|
||||
- Add host time platform; remove host support from sntp. :esphomepr:`6854` by :ghuser:`clydebarrow` (new-integration)
|
||||
- [wireguard] Implement workaround for crash on IDF 5+ :esphomepr:`6846` by :ghuser:`kbx81`
|
||||
- [ft5x06] Interrupt pin and code quality improvements :esphomepr:`6851` by :ghuser:`jesserockz`
|
||||
- [ethernet] Add config option to set arbitrary PHY register values :esphomepr:`6836` by :ghuser:`heythisisnate`
|
||||
- Add carrier_frequency option to remote_transmitter.transmit_aeha :esphomepr:`6792` by :ghuser:`svxa`
|
||||
- Add ``invert_position_report`` to ``tuya.cover`` :esphomepr:`6020` by :ghuser:`wrouesnel`
|
||||
- [Tuya Climate] Support both datapoint and pins for active state :esphomepr:`6789` by :ghuser:`zry98`
|
||||
- [config] Allow file: scheme for git external components :esphomepr:`6844` by :ghuser:`clydebarrow`
|
||||
- [ota] http_request update platform :esphomepr:`5586` by :ghuser:`oarcher` (new-integration)
|
||||
- [logger] Fix defines for development :esphomepr:`6870` by :ghuser:`jesserockz`
|
||||
- [docker] Avoid unsafe git error when container user and file config volume permissions don't match :esphomepr:`6873` by :ghuser:`ptr727`
|
||||
- [datetime] Add logs on DateCall perform :esphomepr:`6868` by :ghuser:`RFDarter`
|
||||
- fix: arduino media player sets wrong state for announcements :esphomepr:`6849` by :ghuser:`gnumpi`
|
||||
- [datetime] datetime-datetime strptime support value string without seconds :esphomepr:`6867` by :ghuser:`RFDarter`
|
||||
- Update webserver local assets to 20240608-093147 :esphomepr:`6874` by :ghuser:`esphomebot`
|
||||
- fix: arduino media player still sets wrong state. :esphomepr:`6875` by :ghuser:`gnumpi`
|
||||
- [http_request] Add esp-idf and rp2040 support :esphomepr:`3256` by :ghuser:`jesserockz` (breaking-change)
|
||||
- [i2s_speaker] A few fixes :esphomepr:`6872` by :ghuser:`jesserockz`
|
||||
- [voice_assistant] Write less data to speaker each loop :esphomepr:`6877` by :ghuser:`jesserockz`
|
||||
- Bump docker/build-push-action from 5.3.0 to 5.4.0 in /.github/actions/build-image :esphomepr:`6883` by :ghuser:`dependabot[bot]`
|
||||
- Allow parse_json to return a boolean result :esphomepr:`6884` by :ghuser:`jesserockz` (breaking-change)
|
||||
- Update webserver local assets to 20240610-230854 :esphomepr:`6886` by :ghuser:`esphomebot`
|
||||
- [core] Update Entities :esphomepr:`6885` by :ghuser:`jesserockz` (new-integration)
|
||||
- [Dockerfile] Sync platformio version with requirements.txt :esphomepr:`6888` by :ghuser:`ptr727`
|
||||
- [Deep sleep] Compilation error with IDF >= 5.* :esphomepr:`6879` by :ghuser:`asergunov`
|
||||
- [animation] Allow loading external url at build time :esphomepr:`6876` by :ghuser:`landonr`
|
||||
- [waveshare_epaper] Add support for 13.3in-k :esphomepr:`6443` by :ghuser:`pgericson`
|
||||
- Climate IR LG - Support fan only mode and all "on" commands :esphomepr:`3712` by :ghuser:`danieldabate`
|
||||
- [safe_mode] Allow user-defined interval for successful boot :esphomepr:`6882` by :ghuser:`NMartin354`
|
||||
- New 1-wire component :esphomepr:`6860` by :ghuser:`ssieb` (new-integration) (breaking-change)
|
||||
- [he60r] Don't publish state unless it has changed. [BUGFIX] :esphomepr:`6869` by :ghuser:`clydebarrow`
|
||||
- [image] Make PIL import local :esphomepr:`6864` by :ghuser:`guillempages`
|
||||
- [config] Retain path information in validated configuration :esphomepr:`6785` by :ghuser:`clydebarrow`
|
||||
- WebSocket overrides check_origin for reverse proxy configuration :esphomepr:`6845` by :ghuser:`gabest11`
|
||||
- [config] Early termination of validation steps on error :esphomepr:`6837` by :ghuser:`clydebarrow`
|
||||
- Fix media_player.volume_set when media player is not started :esphomepr:`6859` by :ghuser:`tetele`
|
||||
- [display] SDL2 display driver for host platform :esphomepr:`6825` by :ghuser:`clydebarrow` (new-integration)
|
||||
- [ili9xxx] Implement st7735 support :esphomepr:`6838` by :ghuser:`clydebarrow`
|
||||
|
||||
Past Changelogs
|
||||
---------------
|
||||
|
||||
- :doc:`2024.5.0`
|
||||
- :doc:`2024.4.0`
|
||||
- :doc:`2024.3.0`
|
||||
- :doc:`2024.2.0`
|
||||
- :doc:`2023.12.0`
|
||||
- :doc:`2023.11.0`
|
||||
- :doc:`2023.10.0`
|
||||
- :doc:`2023.9.0`
|
||||
- :doc:`2023.8.0`
|
||||
- :doc:`2023.7.0`
|
||||
- :doc:`2023.6.0`
|
||||
- :doc:`2023.5.0`
|
||||
- :doc:`2023.4.0`
|
||||
- :doc:`2023.3.0`
|
||||
- :doc:`2023.2.0`
|
||||
- :doc:`2022.12.0`
|
||||
- :doc:`2022.11.0`
|
||||
- :doc:`2022.10.0`
|
||||
- :doc:`2022.9.0`
|
||||
- :doc:`2022.8.0`
|
||||
- :doc:`2022.6.0`
|
||||
- :doc:`2022.5.0`
|
||||
- :doc:`2022.4.0`
|
||||
- :doc:`2022.3.0`
|
||||
- :doc:`2022.2.0`
|
||||
- :doc:`2022.1.0`
|
||||
- :doc:`2021.12.0`
|
||||
- :doc:`2021.11.0`
|
||||
- :doc:`2021.10.0`
|
||||
- :doc:`2021.9.0`
|
||||
- :doc:`2021.8.0`
|
||||
- :doc:`v1.20.0`
|
||||
- :doc:`v1.19.0`
|
||||
- :doc:`v1.18.0`
|
||||
- :doc:`v1.17.0`
|
||||
- :doc:`v1.16.0`
|
||||
- :doc:`v1.15.0`
|
||||
- :doc:`v1.14.0`
|
||||
- :doc:`v1.13.0`
|
||||
- :doc:`v1.12.0`
|
||||
- :doc:`v1.11.0`
|
||||
- :doc:`v1.10.0`
|
||||
- :doc:`v1.9.0`
|
||||
- :doc:`v1.8.0`
|
||||
- :doc:`v1.7.0`
|
||||
@ -2,7 +2,7 @@ Changelog
|
||||
=========
|
||||
|
||||
.. redirect::
|
||||
:url: /changelog/2024.5.0.html
|
||||
:url: /changelog/2024.6.0.html
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
|
||||
@ -49,6 +49,7 @@ Configuration variables:
|
||||
- **on_chime** (*Optional*, :ref:`Action <config-action>`): An automation to perform
|
||||
when a zone has been marked as chime in the configuration, and it changes from closed to open.
|
||||
See :ref:`alarm_control_panel_on_chime_trigger`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
|
||||
Automation:
|
||||
|
||||
@ -15,19 +15,6 @@ Additional sensors for Haier Climate device. **These sensors are supported only
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
baud_rate: 9600
|
||||
tx_pin: GPIOXX
|
||||
rx_pin: GPIOXX
|
||||
id: ac_port
|
||||
|
||||
climate:
|
||||
- platform: haier
|
||||
id: haier_ac
|
||||
protocol: hOn
|
||||
name: Haier AC
|
||||
uart_id: ac_port
|
||||
|
||||
binary_sensor:
|
||||
- platform: haier
|
||||
haier_id: haier_ac
|
||||
|
||||
@ -74,6 +74,7 @@ Advanced options:
|
||||
for a list of available options.
|
||||
Set to ``""`` to remove the default entity category.
|
||||
- If MQTT enabled, all other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
.. _binary_sensor-filters:
|
||||
|
||||
|
||||
@ -77,6 +77,37 @@ Configuration variables:
|
||||
- **release_threshold** (*Optional*, int): A per-channel override of the global release_threshold value. If not specified, uses the global value.
|
||||
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
|
||||
GPIO
|
||||
----
|
||||
|
||||
The ``mpr121`` also supports configuring its touch electrodes as GPIO inputs and outputs. To do so,
|
||||
specify an ``id`` in the configuration of the ``mpr121`` component. Then, configure a GPIO output or
|
||||
input using this ID in the ``mpr121`` field.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
output:
|
||||
- id: ext_5v_power
|
||||
platform: gpio
|
||||
pin:
|
||||
mpr121: mpr121_component
|
||||
number: 10
|
||||
mode: OUTPUT
|
||||
inverted: true
|
||||
|
||||
|
||||
The ``number`` refers to the ELEx pin number on the MPR121 chip. Only ELE4 up to including ELE11 are
|
||||
available as GPIO.
|
||||
|
||||
GPIO and touch functionality may be used at the same time, but not on the same pins.
|
||||
|
||||
It is also not valid to configure a pin as GPIO when a pin with a higher number is used as touch
|
||||
channel. This is because touch functionality is configured as a range, starting at ELE0.
|
||||
For example:
|
||||
|
||||
- Using channel 2 and 5 as touch and channel 6 as GPIO is okay
|
||||
- Using channel 2 and 5 as touch and channel 4 as GPIO is not okay
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
|
||||
34
components/button/haier.rst
Normal file
34
components/button/haier.rst
Normal file
@ -0,0 +1,34 @@
|
||||
Haier Climate Buttons
|
||||
=====================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up additional buttons for Haier climate devices.
|
||||
:image: haier.svg
|
||||
|
||||
Additional buttons for Haier AC cleaning. **These buttons are supported only by the hOn protocol**.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
button:
|
||||
- platform: haier
|
||||
haier_id: haier_ac
|
||||
self_cleaning:
|
||||
name: Haier start self cleaning
|
||||
steri_cleaning:
|
||||
name: Haier start 56°C steri-cleaning
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **haier_id** (**Required**, :ref:`config-id`): The id of Haier climate component
|
||||
- **self_cleaning** (*Optional*): A button that starts Haier climate self cleaning.
|
||||
All options from :ref:`Button <config-button>`.
|
||||
- **steri_cleaning** (*Optional*): A button that starts Haier climate 56°C Steri-Clean.
|
||||
All options from :ref:`Button <config-button>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`Haier Climate </components/climate/haier>`
|
||||
- :ghedit:`Edit`
|
||||
@ -59,6 +59,7 @@ Configuration variables:
|
||||
- **device_class** (*Optional*, string): The device class for the button.
|
||||
See https://www.home-assistant.io/integrations/button/#device-class
|
||||
for a list of available options.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
Automations:
|
||||
|
||||
|
||||
@ -5,10 +5,10 @@ Safe Mode Button
|
||||
:description: Instructions for setting up buttons that can remotely reboot the ESP in ESPHome into safe mode.
|
||||
:image: restart.svg
|
||||
|
||||
The ``safe_mode`` button allows you to remotely reboot your node into :ref:`Safe Mode <config-ota>`. This is useful in certain situations
|
||||
The ``safe_mode`` button allows you to remotely reboot your node into :doc:`/components/safe_mode`. This is useful in certain situations
|
||||
where a misbehaving component is preventing Over-The-Air updates from completing successfully.
|
||||
|
||||
This component requires :ref:`OTA <config-ota>` to be configured.
|
||||
This component requires :doc:`/components/safe_mode` to be configured.
|
||||
|
||||
.. figure:: images/safemode-ui.png
|
||||
:align: center
|
||||
|
||||
@ -119,6 +119,13 @@ Configuration variables:
|
||||
|
||||
Whichever is not selected will be made available as a custom preset.
|
||||
|
||||
- **temperature_source** (*Optional*, string): The temperature that should be used as the
|
||||
climate entity's current temperature:
|
||||
|
||||
- ``ambient`` (Default) - The temperature of the room the BedJet is in will be
|
||||
reported as the climate entity's current temperature.
|
||||
- ``outlet`` - The temperature of the air being discharged by the BedJet will be
|
||||
reported as the climate entity's current temperature.
|
||||
- All other options from :ref:`Climate <config-climate>`.
|
||||
|
||||
``bedjet`` Fan
|
||||
@ -146,6 +153,32 @@ Configuration variables:
|
||||
- **bedjet_id** (**Required**, :ref:`config-id`): The ID of the Bedjet component.
|
||||
- Other options from :ref:`Fan <config-fan>`.
|
||||
|
||||
``bedjet`` Sensor
|
||||
-----------------
|
||||
|
||||
The ``sensor`` platform exposes the BedJet's various temperature readings as sensors.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: bedjet
|
||||
bedjet_id: bedjet_1
|
||||
outlet_temperature:
|
||||
name: "My BedJet Outlet Temperature"
|
||||
ambient_temperature:
|
||||
name: "My BedJet Ambient Temperature"
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **outlet_temperature** (*Optional*): If specified, the temperature of the air being
|
||||
discharged from the BedJet will be reported as a sensor.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **ambient_temperature** (*Optional*): If specified, the temperature of the room the
|
||||
BedJet is in will be reported as a sensor.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
Known issues:
|
||||
-------------
|
||||
|
||||
|
||||
@ -315,6 +315,8 @@ See Also
|
||||
- `haier-esphome <https://github.com/paveldn/haier-esphome>`__
|
||||
- :doc:`Haier Climate Sensors </components/sensor/haier>`
|
||||
- :doc:`Haier Climate Binary Sensors </components/binary_sensor/haier>`
|
||||
- :doc:`Haier Climate Text Sensors </components/text_sensor/haier>`
|
||||
- :doc:`Haier Climate Buttons </components/button/haier>`
|
||||
- :doc:`/components/climate/index`
|
||||
- :apiref:`haier/climate/haier.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
@ -127,6 +127,7 @@ MQTT options:
|
||||
- **target_humidity_command_topic** (*Optional*, string): The topic to receive
|
||||
target humidity commands on.
|
||||
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
Climate Automation
|
||||
------------------
|
||||
|
||||
@ -11,23 +11,27 @@ Tuya climate requires a :doc:`/components/tuya` to be configured.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
[22:03:11][C][tuya:023]: Tuya:
|
||||
[22:03:11][C][tuya:032]: Datapoint 1: switch (value: ON)
|
||||
[22:03:11][C][tuya:032]: Datapoint 2: switch (value: OFF)
|
||||
[22:03:11][C][tuya:034]: Datapoint 3: int value (value: 20)
|
||||
[22:03:11][C][tuya:034]: Datapoint 4: int value (value: 19)
|
||||
[22:03:11][C][tuya:034]: Datapoint 5: int value (value: 0)
|
||||
[22:03:11][C][tuya:036]: Datapoint 7: enum (value: 1)
|
||||
[22:03:11][C][tuya:046]: Product: '{"p":"ynjanlglr4qa6dxf","v":"1.0.0","m":0}'
|
||||
[11:45:14][C][tuya:041]: Tuya:
|
||||
[11:45:14][C][tuya:056]: Datapoint 1: switch (value: OFF)
|
||||
[11:45:14][C][tuya:058]: Datapoint 2: int value (value: 65)
|
||||
[11:45:14][C][tuya:058]: Datapoint 3: int value (value: 54)
|
||||
[11:45:14][C][tuya:062]: Datapoint 4: enum (value: 1)
|
||||
[11:45:14][C][tuya:056]: Datapoint 5: switch (value: OFF)
|
||||
[11:45:14][C][tuya:056]: Datapoint 6: switch (value: OFF)
|
||||
[11:45:14][C][tuya:062]: Datapoint 102: enum (value: 0)
|
||||
[11:45:14][C][tuya:062]: Datapoint 103: enum (value: 1)
|
||||
[11:45:14][C][tuya:074]: Product: 'N8bUqOZ8HBQjU0K02.0.1'
|
||||
|
||||
On this controller, the data points are:
|
||||
On this controller (BAC-002-ELW), the data points are:
|
||||
|
||||
- 1 represents the climate on/off state.
|
||||
- 2 represents the child lock switch. (use the :doc:`/components/switch/tuya` component to control this)
|
||||
- 3 represents the target temperature.
|
||||
- 4 represents the current temperature.
|
||||
- 5 represents the timer but is not yet available to be used in ESPHome.
|
||||
- 7 represents the eco mode switch.
|
||||
- 2 represents the target temperature.
|
||||
- 3 represents the current temperature.
|
||||
- 4 represents the schedule mode but is not yet available to be used in ESPHome.
|
||||
- 5 represents the ECO mode switch.
|
||||
- 6 represents the child lock switch. (use the :doc:`/components/switch/tuya` component to control this)
|
||||
- 102 represents the HVAC mode (heating, cooling, fan-only, etc.).
|
||||
- 103 represents the fan speed (auto, low, medium, high, etc.).
|
||||
|
||||
Based on this, you can create the climate device as follows:
|
||||
|
||||
@ -37,12 +41,27 @@ Based on this, you can create the climate device as follows:
|
||||
- platform: tuya
|
||||
name: "My Climate Device"
|
||||
switch_datapoint: 1
|
||||
target_temperature_datapoint: 3
|
||||
current_temperature_datapoint: 4
|
||||
target_temperature_datapoint: 2
|
||||
current_temperature_datapoint: 3
|
||||
supports_heat: true
|
||||
supports_cool: true
|
||||
active_state:
|
||||
datapoint: 102
|
||||
cooling_value: 0
|
||||
heating_value: 1
|
||||
fanonly_value: 2
|
||||
fan_mode:
|
||||
datapoint: 103
|
||||
auto_value: 0
|
||||
high_value: 1
|
||||
medium_value: 2
|
||||
low_value: 3
|
||||
preset:
|
||||
eco:
|
||||
datapoint: 8
|
||||
datapoint: 5
|
||||
temperature: 28
|
||||
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
@ -52,13 +71,13 @@ Configuration variables:
|
||||
- **supports_heat** (*Optional*, boolean): Specifies if the device has a heating mode. Defaults to ``true``.
|
||||
- **supports_cool** (*Optional*, boolean): Specifies if the device has a cooling mode. Defaults to ``false``.
|
||||
- **switch_datapoint** (**Required**, int): The datapoint id number of the climate switch (device on/off).
|
||||
- **active_state** (*Optional*): Configuration for the Active State Configuration.
|
||||
- **active_state** (*Optional*): Configuration for the Active State detection (or HVAC mode setting and reporting).
|
||||
|
||||
- **datapoint** (**Required**, int): The datapoint id number of the active state - :ref:`see below <active_state_detection>`.
|
||||
- **heating_value** (*Optional*, int): The active state datapoint value the device reports when heating. Defaults to ``1`` - :ref:`see below <active_state_detection>`.
|
||||
- **cooling_value** (*Optional*, int): The active state datapoint value the device reports when cooling - :ref:`see below <active_state_detection>`.
|
||||
- **drying_value** (*Optional*, int): The active state datapoint value the device reports when in drying mode.
|
||||
- **fanonly_value** (*Optional*, int): The active state datapoint value the device reports when in Fan Only mode.
|
||||
- **heating_value** (*Optional*, int): The active state datapoint value when in heating mode. Defaults to ``1`` - :ref:`see below <active_state_detection>`.
|
||||
- **cooling_value** (*Optional*, int): The active state datapoint value when in cooling mode - :ref:`see below <active_state_detection>`.
|
||||
- **drying_value** (*Optional*, int): The active state datapoint value when in drying mode.
|
||||
- **fanonly_value** (*Optional*, int): The active state datapoint value when in fan-only mode.
|
||||
- **preset** (*Optional*): Configuration for presets.
|
||||
|
||||
- **eco** (*Optional*): Configuration for Eco preset.
|
||||
@ -100,13 +119,14 @@ If the device has different multipliers for current and target temperatures, **t
|
||||
Active state detection
|
||||
----------------------
|
||||
|
||||
Some Tuya climate devices report the active state (idle/heating/cooling) via a tuya data point. In this case, you can use the **active_state_datapoint** variable together with **active_state_heating_value** and **active_state_cooling_value**.
|
||||
Some Tuya climate devices don't have a data point for setting and reporting HVAC mode, they use a data point to report their active state (current action). In this case, you can just use the **active_state** configuration.
|
||||
|
||||
If your device does not make a data point available for this, it is possible to modify the hardware so that the relay outputs can be read by the ESP. Please refer to `this discussion <https://github.com/klausahrenberg/WThermostatBeca/issues/17>` for more details on the required modifications. You can then use the **heating_state_pin** and/or **cooling_state_pin** configuration variables to detect the current state.
|
||||
If your device uses a data point for HVAC mode, but not for reporting the active state, it is possible to modify the hardware so that the relay outputs can be read by the ESP. Please refer to `this discussion <https://github.com/klausahrenberg/WThermostatBeca/issues/17>`__ for more details on the required modifications. You can then use the **heating_state_pin** and/or **cooling_state_pin** configuration variables to detect the current state.
|
||||
|
||||
If none of the above variables are set, the current state is inferred from the difference between the current and target temperatures.
|
||||
If **supports_heat** is ``True`` and the current temperature is more than 1 °C below the target temperature, the device is expected to be heating.
|
||||
If **supports_cool** is ``True`` and the current temperature is more than 1 °C above the target temperature, the device is expected to be cooling.
|
||||
If none of the above variables are set, the active state is inferred from the difference between the current and target temperatures:
|
||||
|
||||
- If **supports_heat** is ``True`` and the current temperature is more than 1 °C below the target temperature, the device is expected to be heating.
|
||||
- If **supports_cool** is ``True`` and the current temperature is more than 1 °C above the target temperature, the device is expected to be cooling.
|
||||
|
||||
.. _temperature-multiplier:
|
||||
|
||||
|
||||
@ -63,6 +63,7 @@ MQTT options:
|
||||
- **tilt_command_topic** (*Optional*, string): The topic to receive
|
||||
cover tilt commands on.
|
||||
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
|
||||
.. _cover-open_action:
|
||||
|
||||
@ -40,6 +40,7 @@ Configuration variables:
|
||||
- **min_value** (*Optional*, int): The lowest position value, meaning cover closed. Defaults to 0.
|
||||
- **max_value** (*Optional*, int): the highest position value, meaning cover opened. Defaults to 255.
|
||||
- **invert_position** (*Optional*, boolean): Sets the direction of travel to be inverted, if direction_datapoint is configured.
|
||||
- **invert_position_report** (*Optional*, boolean): Invert reported position percentages calculated from `min_value` and `max_value` i.e. 70% becomes 30%. Defaults to false.
|
||||
- All other options from :ref:`Cover <config-cover>`.
|
||||
|
||||
Supported devices
|
||||
|
||||
@ -49,6 +49,7 @@ Configuration variables:
|
||||
Set to ``""`` to remove the default entity category.
|
||||
- **time_id** (**Required**, :ref:`config-id`): The ID of the time entity. Automatically set
|
||||
to the ID of a time component if only a single one is defined.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
MQTT Options:
|
||||
|
||||
|
||||
@ -21,6 +21,7 @@ With this display driver you can control the following displays:
|
||||
- M5STACK
|
||||
- S3BOX
|
||||
- S3BOX_LITE
|
||||
- ST7735
|
||||
- ST7796
|
||||
- ST7789V
|
||||
- TFT 2.4
|
||||
@ -40,7 +41,10 @@ ILI9341 (`datasheet <https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf>`__,
|
||||
displays from the same chip family with ESPHome. As this is a somewhat higher resolution display and requires additional pins
|
||||
beyond the basic SPI connections, and a reasonable amount of RAM, it is not well suited for the ESP8266.
|
||||
|
||||
**Note:** use of 16 bit colors requires double the amount of RAM as 8 bit, and may need PSRAM to be available.
|
||||
.. note::
|
||||
|
||||
Use of 16 bit colors requires double the amount of RAM as 8 bit, and may need PSRAM to be available.
|
||||
|
||||
|
||||
.. figure:: images/ili9341-full.jpg
|
||||
:align: center
|
||||
@ -69,8 +73,9 @@ Configuration variables:
|
||||
- ``M5STACK``, ``TFT 2.4``, ``TFT 2.4R``, ``S3BOX``, ``S3BOX_LITE``, ``WSPICOLCD``
|
||||
- ``ILI9341``, ``ILI9342``, ``ILI9486``, ``ILI9488``, ``ILI9488_A`` (alternative gamma configuration for ILI9488)
|
||||
- ``ILI9481``, ``ILI9481-18`` (18 bit mode)
|
||||
- ``ST7789V``, ``ST7796``
|
||||
- ``GC9A01A``
|
||||
- ``ST7789V``, ``ST7796``, ``ST7735``
|
||||
- ``GC9A01A``, ``CUSTOM``
|
||||
|
||||
|
||||
- **dc_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The DC pin.
|
||||
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
|
||||
@ -96,8 +101,8 @@ Configuration variables:
|
||||
- **offset_width** (*Optional*, int): Specify an offset for the x-direction of the display, typically used when an LCD is smaller than the maximum supported by the driver chip. Default is 0
|
||||
- **offset_height** (*Optional*, int): Specify an offset for the y-direction of the display. Default is 0.
|
||||
|
||||
- **invert_colors** (*Optional*): With this boolean option you can invert the display colors. **Note** some of the displays have this option set automatically to true and can't be changed.
|
||||
- **18bit_mode** (*Optional*): With this boolean option you can manual enable or disable the 18 bit color mode.
|
||||
- **invert_colors** (*Optional*): With this boolean option you can invert the display colors.
|
||||
- **pixel_mode** (*Optional*): Allows forcing the display into 18 or 16 bit mode. Options are ``18bit`` or ``16bit``. If unspecified, the pixel mode will be determined by the model choice. Not all displays will work in both modes.
|
||||
- **rotation** (*Optional*): Rotate the display presentation in software. Choose one of ``0°``, ``90°``, ``180°``, or ``270°``. This option cannot be used with ``transform``.
|
||||
- **transform** (*Optional*): Transform the display presentation using hardware. All defaults are ``false``. This option cannot be used with ``rotation``.
|
||||
|
||||
@ -105,18 +110,45 @@ Configuration variables:
|
||||
- **mirror_x** (*Optional*, boolean): If true, mirror the x axis.
|
||||
- **mirror_y** (*Optional*, boolean): If true, mirror the y axis.
|
||||
|
||||
**Note:** The ``rotation`` variable will do a software based rotation. It is better to use the **transform** to rotate the display in hardware. Use one of the following combinations:
|
||||
.. note::
|
||||
|
||||
The ``rotation`` variable will do a software based rotation.
|
||||
It is better to use the ``transform`` option to rotate the display in hardware. Use one of the following combinations:
|
||||
- 90 degrees - use ``swap_xy`` with ``mirror_x``
|
||||
- 180 degrees - use ``mirror_x`` with ``mirror_y``
|
||||
- 270 degrees - use ``swap_xy`` with ``mirror_y``
|
||||
|
||||
With 90 and 270 rotations you will also need to swap the **dimensions** ''height'' and ''width'' (see example below.
|
||||
With 90 and 270 rotations you will also need to swap the ``height`` and ``width`` in ``dimensions`` (see example below.
|
||||
|
||||
|
||||
|
||||
- **init_sequence** (*Optional*): Allows custom initialisation sequences to be added. See below for more information.
|
||||
|
||||
|
||||
To modify the SPI setting see :ref:`SPI bus <spi>` . The default **data_rate** is set to ``40MHz`` and the **spi_mode** mode is ``MODE0`` but some displays require ``MODE3`` (*).
|
||||
|
||||
**Note:** The maximum achievable data rate will depend on the chip type (e.g. ESP32 vs ESP32-S3) the pins used (on ESP32 using the default SPI pins allows higher rates) and the connection type (on-board connections will support higher rates than long cables or DuPont wires.) If in doubt, start with a low speed and test higher rates to find what works. A MISO pin should preferably not be specified, as this will limit the maximum rate in some circumstances, and is not required if the SPI bus is used only for the display.
|
||||
|
||||
Additional inititialisation sequences
|
||||
*************************************
|
||||
|
||||
The ``init_sequence`` option allows additional configuration of the driver chip. Provided commands will be sent to the
|
||||
driver chip in addition to, and after the chosen model's pre-defined commands. It requires a list of byte sequences:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
init_sequence:
|
||||
- [ 0xD0, 0x07, 0x42, 0x18]
|
||||
- [ 0xD1, 0x00, 0x07, 0x10]
|
||||
|
||||
|
||||
|
||||
Each entry represents a single-byte command followed by zero or more data bytes.
|
||||
|
||||
CUSTOM model
|
||||
************
|
||||
|
||||
The ``CUSTOM`` model selection is provided for otherwise unsupported displays, and requires both ``dimensions:`` and ``init_sequence:`` to be specfied. There is no pre-defined init sequence.
|
||||
|
||||
Configuration examples
|
||||
**********************
|
||||
|
||||
112
components/display/sdl.rst
Normal file
112
components/display/sdl.rst
Normal file
@ -0,0 +1,112 @@
|
||||
SDL2 Display on host platform
|
||||
=============================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up SDL2 display on host
|
||||
:image: sdl.png
|
||||
|
||||
.. _sdl:
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
The ``sdl`` display platform allows you to use create an ESPHome display on a desktop system running Linux or MacOS.
|
||||
This is particularly useful for designing display layouts, since compiling and running a host binary is much faster
|
||||
than compiling for and flashing a microcontroller target system.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
host:
|
||||
mac_address: "62:23:45:AF:B3:DD"
|
||||
|
||||
display:
|
||||
- platform: sdl
|
||||
id: sdl_display
|
||||
update_interval: 1s
|
||||
auto_clear_enabled: false
|
||||
show_test_card: true
|
||||
dimensions:
|
||||
width: 450
|
||||
height: 600
|
||||
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
|
||||
See :ref:`display-engine` for more information.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``1s``.
|
||||
- **sdl_options** (*Optional*, string): Build arguments if required to specify include or library paths. Should not be required if SDL2 is properly installed.
|
||||
- **pages** (*Optional*, list): Show pages instead of a single lambda. See :ref:`display-pages`.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
To build with this display you must have the
|
||||
`SDL2 <https://wiki.libsdl.org/SDL2/Installation>`__ package installed. The Sodium encryption library will
|
||||
also be required for any API calls. See below for installation hints.
|
||||
|
||||
MacOS SDL2 Installation
|
||||
-----------------------
|
||||
|
||||
The easiest way to install SDL2 on MacOS is using ``homebrew``:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
brew install sdl2 libsodium
|
||||
|
||||
It may also be necessary to run the command:
|
||||
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
|
||||
brew link sdl2 libsodium
|
||||
|
||||
|
||||
|
||||
To ensure that the files are symlinked correctly.
|
||||
You can check installation with the command ``sdl2-config --libs --cflags``.
|
||||
|
||||
You will need the XCode command-line tools installed to build for the host platform.
|
||||
|
||||
Linux SDL2 Installation
|
||||
-----------------------
|
||||
|
||||
On Debian/Ubuntu derived Linux systems you can install with ``apt``; also check that you have the necessary build
|
||||
tools installed, and you must be using a desktop system with a graphic display.
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
apt install libsdl2-dev libsodium-dev build-essential git
|
||||
|
||||
You can check installation with the command ``sdl2-config --libs --cflags``.
|
||||
|
||||
|
||||
Microsoft Windows
|
||||
-----------------
|
||||
|
||||
Although SDL2 is supported, natively running ESPHome on Windows isn't easy. However the *Windows Subsystem for Linux* (WSL) can be
|
||||
used to install and use a Linux development environment on Windows, which will enable use of ESPHome and SDL2 as per the
|
||||
Linux instructions above. See https://learn.microsoft.com/en-us/windows/wsl/install for more information on WSL.
|
||||
|
||||
Build and run
|
||||
-------------
|
||||
|
||||
The ``esphome`` command will not automatically run the build file on the ``host`` platform. Instead use ``esphome compile yourfile.yaml``
|
||||
then locate the executable file called ``program`` within the ``.esphome`` build tree:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
`find .esphome -name program`
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`SDL touchscreen <sdl_touchscreen>`
|
||||
- :doc:`index`
|
||||
- :apiref:`sdl/sdl_esphome.h`
|
||||
- :ghedit:`Edit`
|
||||
@ -22,6 +22,14 @@ It uses the :ref:`SPI Bus <spi>` for communication.
|
||||
|
||||
ST7735 Display
|
||||
|
||||
.. warning::
|
||||
|
||||
This component has been made redundant since the ST7735 is now supported by the :ref:`ILI9XXX component <ili9xxx>`. It is recommended
|
||||
that you use the ``ili9xxx`` component as it will be maintained, whereas this component may not be, or may be removed completely
|
||||
in the future. If migrating from this component to ``ili9xxx`` you may need to set the ``dimensions:`` option to
|
||||
specify the screen size and offsets in the ``ili9xxx`` config.
|
||||
|
||||
|
||||
There are numerous board types out there. Some initialize differently as well. This driver will take a few options to narrow down the right settings.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -112,8 +112,9 @@ Configuration variables:
|
||||
- ``7.50inV2`` - Can't use with an ESP8266 as it runs out of RAM
|
||||
- ``7.50inV2alt`` (alternative version to the above ``7.50inV2``)
|
||||
- ``7.50in-hd-b`` - Can't use with an ESP8266 as it runs out of RAM
|
||||
- ``gdey029t94`` - GooDisplay GDEY029T94, as used on the AdaFruit MagTag
|
||||
- ``gdew029t5`` - GooDisplay GDEW029T5, as used on the AdaFruit MagTag (previously incorrectly referred to as GDEY029T94)
|
||||
- ``1.54in-m5coreink-m09`` - GoodDisplay gdew0154m09, as used in the M5Stack Core Ink
|
||||
- ``13.3in-k`` - 13.3in, with the K model, 960x680, B/W rendering only
|
||||
|
||||
.. warning::
|
||||
|
||||
|
||||
@ -72,6 +72,12 @@ RMII configuration variables:
|
||||
- ``GPIO17_OUT`` - Internal clock
|
||||
|
||||
- **phy_addr** (*Optional*, int): The PHY addr type of the Ethernet controller. Defaults to 0.
|
||||
- **phy_registers** (*Optional*, mapping): Arbitrary PHY register values to set after Ethernet initialization.
|
||||
|
||||
- **address** (**Required**, hex): The register address as a hex number (e.g. ``0x10`` for address 16)
|
||||
- **value** (**Required**, hex): The value of the register to set as a hex number (e.g. ``0x1FFA``)
|
||||
- **page_id** (*Optional*, hex): (RTL8201 only) Register page number to select before writing (e.g. ``0x07`` for page 7)
|
||||
|
||||
- **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).
|
||||
|
||||
@ -230,6 +236,11 @@ Configuration examples
|
||||
mdio_pin: GPIO17
|
||||
clk_mode: GPIO0_IN
|
||||
phy_addr: 0
|
||||
phy_registers:
|
||||
- address: 0x10
|
||||
value: 0x1FFA
|
||||
page_id: 0x07
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -33,6 +33,14 @@ You can find some basic documentation on creating your own components at :ref:`c
|
||||
type: local
|
||||
path: my_components
|
||||
|
||||
# use a component from a local git repository
|
||||
- source:
|
||||
type: git
|
||||
url: file:///Users/user/path_to_repo
|
||||
ref: my_awesome_branch
|
||||
components: [my_awesome_component]
|
||||
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **source**: The location of the components you want to retrieve. See :ref:`external-components_local`
|
||||
@ -42,7 +50,7 @@ Configuration variables:
|
||||
|
||||
git options:
|
||||
|
||||
- **url** (**Required**, url): HTTP git repository url. See :ref:`external-components_git`.
|
||||
- **url** (**Required**, url): Git repository url. See :ref:`external-components_git`.
|
||||
- **ref** (*Optional*, string): Git ref (branch or tag). If not specified the default branch is used.
|
||||
- **username** (*Optional*, string): Username for the Git server, if one is required
|
||||
- **password** (*Optional*, string): Password for the Git server, if one is required
|
||||
@ -114,6 +122,8 @@ Retrieving components from git is the easiest way to use components not included
|
||||
The source components should be inside a ``components`` folder or inside an ``esphome/components``
|
||||
folder. The latter makes sharing a component from a forked ESPHome repository easier.
|
||||
|
||||
The url to the repository may be remote (``http:`` or ``https:`` scheme) or local (``file:`` scheme with an absolute path.)
|
||||
|
||||
Example of git repositories
|
||||
***************************
|
||||
|
||||
@ -165,6 +175,10 @@ HTTP git repositories in general are supported with this configuration:
|
||||
type: git
|
||||
url: http://repository_url/
|
||||
ref: branch_or_tag
|
||||
source:
|
||||
type: git
|
||||
url: file:///Users/user/path_to_repo
|
||||
ref: branch_or_tag
|
||||
|
||||
The source field accepts a short hand **github://** resource:
|
||||
|
||||
|
||||
@ -70,6 +70,7 @@ MQTT options:
|
||||
- **speed_command_topic** (*Optional*, string): The topic to receive
|
||||
speed commands on (options: LOW, MEDIUM, HIGH).
|
||||
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
Automation triggers:
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
HOST Platform
|
||||
Host Platform
|
||||
=============
|
||||
|
||||
.. seo::
|
||||
@ -35,4 +35,5 @@ See Also
|
||||
--------
|
||||
|
||||
- :doc:`esphome`
|
||||
- :doc:`/components/time/host`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
@ -7,7 +7,7 @@ HTTP Request
|
||||
:keywords: http, request
|
||||
|
||||
|
||||
The ``http_request`` component lets you make HTTP/HTTPS requests. First, you need to setup a component:
|
||||
The ``http_request`` component lets you make HTTP/HTTPS requests. To do so, you need to add it to your device's configuration:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -16,34 +16,58 @@ The ``http_request`` component lets you make HTTP/HTTPS requests. First, you nee
|
||||
useragent: esphome/device
|
||||
timeout: 10s
|
||||
|
||||
.. _http_request-configuration_variables:
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **useragent** (*Optional*, string): User-Agent header for requests. Defaults to ``ESPHome``.
|
||||
- **timeout** (*Optional*, :ref:`config-time`): Timeout for request. Defaults to ``5s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **follow_redirects** (*Optional*, boolean): Enable following HTTP redirects. Defaults to ``true``.
|
||||
- **redirect_limit** (*Optional*, integer): Maximum amount of redirects to follow when enabled. Defaults to ``3``.
|
||||
- **timeout** (*Optional*, :ref:`config-time`): Timeout for request. Defaults to ``5s``.
|
||||
- **useragent** (*Optional*, string): User-Agent header for requests. Defaults to
|
||||
``ESPHome/<version> (https://esphome.io)`` where ``<version>`` is the version of ESPHome the device is running.
|
||||
For example: ``ESPHome/2024.6.0 (https://esphome.io)``
|
||||
- **verify_ssl** (*Optional*, boolean): When set to ``true`` (default), SSL/TLS certificates will be validated upon
|
||||
connection; if invalid, the connection will be aborted. To accomplish this, ESP-IDF's default ESP x509 certificate
|
||||
bundle is included in the build. This certificate bundle includes the complete list of root certificates from
|
||||
Mozilla's NSS root certificate store. **May only be set to true when using the ESP-IDF framework; must be explicitly
|
||||
set to false when using the Arduino framework.**
|
||||
- **watchdog_timeout** (*Optional*, :ref:`config-time`): Change the watchdog timeout during connection/data transfer.
|
||||
May be useful on slow connections or connections with high latency. **Do not change this value unless you are
|
||||
experiencing device reboots due to watchdog timeouts;** doing so may prevent the device from rebooting due to a
|
||||
legitimate problem. **Only available on ESP32 and RP2040**.
|
||||
|
||||
ESP8266 Options:
|
||||
**For the ESP8266:**
|
||||
|
||||
- **esp8266_disable_ssl_support** (*Optional*, boolean): Whether to include SSL support on ESP8266s.
|
||||
Defaults to ``no``. See :ref:`esphome-esp8266_disable_ssl_support` for more info
|
||||
- **esp8266_disable_ssl_support** (*Optional*, boolean): Determines whether to include HTTPS/SSL support in the
|
||||
firmware binary. Excluding the SSL libraries from your build will result in a smaller binary, which may be
|
||||
necessary for memory-constrained devices (512 kB or 1 MB). If you see
|
||||
``Error: ESP does not have enough space to store OTA file`` in your device's logs, you may need to enable this
|
||||
option. Defaults to ``false``. By setting this option to ``true``:
|
||||
|
||||
.. _esphome-esp8266_disable_ssl_support:
|
||||
- HTTPS connections will not be possible
|
||||
- ``verify_ssl: false`` is implied
|
||||
|
||||
``esp8266_disable_ssl_support``
|
||||
-------------------------------
|
||||
.. warning::
|
||||
|
||||
This options allows you to disable inclusion of SSL libraries. This is required on a flash
|
||||
constrained devices (512k or 1M) which does not have enough space to support
|
||||
SSL and OTA concurrently. The flashing will fail with the following error
|
||||
``Error: ESP does not have enough space to store OTA file``.
|
||||
Setting ``verify_ssl`` to ``false`` **reduces security** when using HTTPS connections!
|
||||
|
||||
Without the root certificate bundle, certificates used by the remote HTTPS server cannot be verified, opening the
|
||||
HTTPS connection up to person-in-the-middle attacks.
|
||||
|
||||
To maximize security, do not set ``verify_ssl`` to ``false`` *unless:*
|
||||
|
||||
- a custom CA/self-signed certificate is used,
|
||||
- the Arduino framework is used, or
|
||||
- the device does not have sufficient memory to store the certificate bundle
|
||||
|
||||
**We strongly recommend using hardware which properly supports TLS/SSL.**
|
||||
|
||||
HTTP Request Actions
|
||||
--------------------
|
||||
|
||||
Component support a number of :ref:`actions <config-action>` that can be used to send requests.
|
||||
The ``http_request`` component supports a number of :ref:`actions <config-action>` that can be used to send requests.
|
||||
|
||||
.. _http_request-get_action:
|
||||
|
||||
@ -59,7 +83,6 @@ This :ref:`action <config-action>` sends a GET request.
|
||||
url: https://esphome.io
|
||||
headers:
|
||||
Content-Type: application/json
|
||||
verify_ssl: false
|
||||
on_response:
|
||||
then:
|
||||
- logger.log:
|
||||
@ -70,17 +93,15 @@ This :ref:`action <config-action>` sends a GET request.
|
||||
# Short form
|
||||
- http_request.get: https://esphome.io
|
||||
|
||||
Configuration variables:
|
||||
**Configuration variables:**
|
||||
|
||||
- **url** (**Required**, string, :ref:`templatable <config-templatable>`): URL to send request.
|
||||
- **url** (**Required**, string, :ref:`templatable <config-templatable>`): URL to which to send the request.
|
||||
- **headers** (*Optional*, mapping): Map of HTTP headers. Values are :ref:`templatable <config-templatable>`.
|
||||
- **verify_ssl** (*Optional*, boolean): Verify the SSL certificate of the endpoint. Defaults to ``true``.
|
||||
- **on_response** (*Optional*, :ref:`Automation <automation>`): An automation to perform when the request is finished.
|
||||
|
||||
.. note::
|
||||
|
||||
Currently ESPHome **can't verify the SSL certificate** of the endpoint.
|
||||
Set ``verify_ssl: false`` to make HTTPS request.
|
||||
- **capture_response** (*Optional*, boolean): when set to ``true``, the response data will be captured and placed into
|
||||
the ``body`` variable as a ``std::string`` for use in :ref:`lambdas <config-lambda>`. Defaults to ``false``.
|
||||
- **max_response_buffer_size** (*Optional*, integer): The maximum buffer size to be used to store the response.
|
||||
Defaults to ``1 kB``.
|
||||
- **on_response** (*Optional*, :ref:`Automation <automation>`): An automation to perform after the request is received.
|
||||
|
||||
.. _http_request-post_action:
|
||||
|
||||
@ -98,14 +119,14 @@ This :ref:`action <config-action>` sends a POST request.
|
||||
Content-Type: application/json
|
||||
json:
|
||||
key: value
|
||||
verify_ssl: false
|
||||
# Short form
|
||||
- http_request.post: https://esphome.io
|
||||
|
||||
Configuration variables:
|
||||
**Configuration variables:**
|
||||
|
||||
- **body** (*Optional*, string, :ref:`templatable <config-templatable>`): A HTTP body string to send with request.
|
||||
- **json** (*Optional*, mapping): A HTTP body in JSON format. Values are :ref:`templatable <config-templatable>`. See :ref:`http_request-examples`.
|
||||
- **json** (*Optional*, mapping): A HTTP body in JSON format. Values are :ref:`templatable <config-templatable>`.
|
||||
See :ref:`http_request-examples`.
|
||||
- All other options from :ref:`http_request-get_action`.
|
||||
|
||||
.. _http_request-send_action:
|
||||
@ -124,22 +145,23 @@ This :ref:`action <config-action>` sends a request.
|
||||
headers:
|
||||
Content-Type: application/json
|
||||
body: "Some data"
|
||||
verify_ssl: false
|
||||
|
||||
Configuration variables:
|
||||
**Configuration variables:**
|
||||
|
||||
- **method** (**Required**, string): HTTP method to use (``GET``, ``POST``, ``PUT``, ``DELETE``, ``PATCH``).
|
||||
- All other options from :ref:`http_request-post_action`.
|
||||
- All other options from :ref:`http_request-post_action` and :ref:`http_request-get_action`.
|
||||
|
||||
.. _http_request-on_response:
|
||||
|
||||
``on_response`` Trigger
|
||||
-----------------------
|
||||
|
||||
This automation will be triggered when the HTTP request is finished and will supply these parameters:
|
||||
This automation will be triggered when the HTTP request is complete.
|
||||
The following variables are available for use in :ref:`lambdas <config-lambda>`:
|
||||
|
||||
* ``status_code`` as ``int`` - http response code
|
||||
* ``duration_ms`` as ``uint32`` - time taken to complete the request
|
||||
- ``response`` as a ``HttpContainer`` object which contains ``content_length``, ``status_code`` and ``duration_ms``.
|
||||
- ``body`` as ``std::string`` which contains the response body when ``capture_response``
|
||||
(see :ref:`http_request-get_action`) is set to ``true``.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -147,14 +169,13 @@ This automation will be triggered when the HTTP request is finished and will sup
|
||||
then:
|
||||
- http_request.get:
|
||||
url: https://esphome.io
|
||||
verify_ssl: false
|
||||
on_response:
|
||||
then:
|
||||
- logger.log:
|
||||
format: "Response status: %d, Duration: %u ms"
|
||||
args:
|
||||
- status_code
|
||||
- duration_ms
|
||||
- response.status_code
|
||||
- response.duration_ms
|
||||
|
||||
|
||||
.. _http_request-examples:
|
||||
@ -181,15 +202,14 @@ Templatable values
|
||||
POST Body in JSON format (syntax 1)
|
||||
***********************************
|
||||
|
||||
**Note:** all values of the map should be a strings.
|
||||
It's impossible to send ``boolean`` or ``numbers`` with this syntax.
|
||||
**Note:** all values of the map must be strings. It is not possible to send JSON ``boolean`` or ``numbers`` with this
|
||||
syntax.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
- http_request.post:
|
||||
url: https://esphome.io
|
||||
verify_ssl: false
|
||||
json:
|
||||
key: !lambda |-
|
||||
return id(my_sensor).state;
|
||||
@ -204,16 +224,14 @@ POST Body in JSON format (syntax 2)
|
||||
**Note:** use this syntax to send ``boolean`` or ``numbers`` in JSON.
|
||||
|
||||
The JSON message will be constructed using the `ArduinoJson <https://github.com/bblanchon/ArduinoJson>`__ library.
|
||||
In the ``json`` option you have access to a ``root`` object which will represents the base object
|
||||
of the JSON message. You can assign values to keys by using the ``root["KEY_NAME"] = VALUE;`` syntax
|
||||
as seen below.
|
||||
In the ``json`` option you have access to a ``root`` object which represents the base object of the JSON message. You
|
||||
can assign values to keys by using the ``root["KEY_NAME"] = VALUE;`` syntax as shown below.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
- http_request.post:
|
||||
url: https://esphome.io
|
||||
verify_ssl: false
|
||||
json: |-
|
||||
root["key"] = id(my_sensor).state;
|
||||
root["greeting"] = "Hello World";
|
||||
@ -224,25 +242,25 @@ as seen below.
|
||||
GET values from a JSON body response
|
||||
************************************
|
||||
|
||||
Assuming that the server returns a response in a JSON object over HTTP similar to this:
|
||||
This example assumes that the server returns a response as a JSON object similar to this:
|
||||
``{"status":"play","vol":"42","mute":"0"}``
|
||||
|
||||
If you want to retrieve the value for the ``vol`` key and assign it to a template ``sensor`` or ``number`` component (with ``id`` set to ``player_volume``):
|
||||
If you want to retrieve the value for the ``vol`` key and assign it to a template ``sensor`` or ``number`` component
|
||||
whose ``id`` is set to ``player_volume``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
- http_request.get:
|
||||
url: https://esphome.io
|
||||
capture_response: true
|
||||
on_response:
|
||||
then:
|
||||
- lambda: |-
|
||||
json::parse_json(id(http_request_data).get_string(), [](JsonObject root) {
|
||||
json::parse_json(body, [](JsonObject root) {
|
||||
id(player_volume).publish_state(root["vol"]);
|
||||
});
|
||||
|
||||
**Note:** don't forget to set the ``id`` for the main ``http_request`` component, to ``http_request_data``.
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
BIN
components/images/dallas-log.png
Normal file
BIN
components/images/dallas-log.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
BIN
components/images/web_server-v3.png
Normal file
BIN
components/images/web_server-v3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
@ -30,5 +30,6 @@ Components
|
||||
time/index
|
||||
alarm_control_panel/index
|
||||
text/index
|
||||
update/index
|
||||
valve/index
|
||||
*
|
||||
|
||||
59
components/light/beken_spi_led_strip.rst
Normal file
59
components/light/beken_spi_led_strip.rst
Normal file
@ -0,0 +1,59 @@
|
||||
Beken SPI LED Strip
|
||||
===================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up addressable lights like NEOPIXEL on a Beken chip using the SPI DMA interface.
|
||||
:image: color_lens.svg
|
||||
|
||||
This is a component using the Beken SPI DMA interface to drive addressable LED strips.
|
||||
|
||||
.. warning::
|
||||
|
||||
Only works on pin P16, which is not available on many tuya modules.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: beken_spi_led_strip
|
||||
rgb_order: GRB
|
||||
pin: P16
|
||||
num_leds: 30
|
||||
chipset: ws2812
|
||||
name: "My Light"
|
||||
|
||||
Configuration variables
|
||||
-----------------------
|
||||
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin for the data line of the light.
|
||||
- **num_leds** (**Required**, int): The number of LEDs in the strip.
|
||||
- **chipset** (**Required**, enum): The chipset to apply known timings from.
|
||||
- ``WS2812``
|
||||
- ``SK6812``
|
||||
- ``APA106``
|
||||
- ``SM16703``
|
||||
|
||||
- **rgb_order** (**Required**, string): The RGB order of the strip.
|
||||
- ``RGB``
|
||||
- ``RBG``
|
||||
- ``GRB``
|
||||
- ``GBR``
|
||||
- ``BGR``
|
||||
- ``BRG``
|
||||
|
||||
- **is_rgbw** (*Optional*, boolean): Set to ``true`` if the strip is RGBW. Defaults to ``false``.
|
||||
- **is_wrgb** (*Optional*, boolean): Set to ``true`` if the strip is WRGB. Defaults to ``false``.
|
||||
- **max_refresh_rate** (*Optional*, :ref:`config-time`):
|
||||
A time interval used to limit the number of commands a light can handle per second. For example
|
||||
16ms will limit the light to a refresh rate of about 60Hz. Defaults to sending commands as quickly as
|
||||
changes are made to the lights.
|
||||
|
||||
- All other options from :ref:`Light <config-light>`.
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/light/index`
|
||||
- :doc:`/components/power_supply`
|
||||
- :apiref:`beken_spi_led_strip/beken_spi_led_strip.h`
|
||||
- :ghedit:`Edit`
|
||||
@ -83,6 +83,7 @@ Advanced options:
|
||||
for a list of available options.
|
||||
Set to ``""`` to remove the default entity category.
|
||||
- If MQTT enabled, all other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
.. _light-toggle_action:
|
||||
|
||||
|
||||
@ -44,6 +44,7 @@ Configuration variables:
|
||||
See https://developers.home-assistant.io/docs/core/entity/#generic-properties
|
||||
for a list of available options. Set to ``""`` to remove the default entity category.
|
||||
- If MQTT enabled, All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
.. _lock-lock_action:
|
||||
|
||||
|
||||
@ -62,6 +62,7 @@ Configuration variables:
|
||||
|
||||
- **disable_crc** (*Optional*, boolean): Ignores a bad CRC if set to ``true``. Defaults to ``false``
|
||||
|
||||
- **role** (*Optional*, string): The role of this component, ``client`` or ``server``. Defaults to ``client``.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
@ -5,15 +5,18 @@ Modbus Controller
|
||||
:description: Instructions for setting up the Modbus Controller component.
|
||||
:image: modbus.png
|
||||
|
||||
The ``modbus_controller`` component creates a RS485 connection to control a Modbus server (slave) device, letting your ESPHome node to act as a Modbus client (master).
|
||||
You can access the coils, inputs, holding, read registers from your devices as sensors, switches, selects, numbers or various other ESPHome components and present them to your favorite Home Automation system. You can even write them as binary or float ouptputs from ESPHome.
|
||||
|
||||
The ``modbus_controller`` component creates a RS485 connection to either:
|
||||
|
||||
- control a Modbus server (slave) device, letting your ESPHome node to act as a Modbus client (master). You can access the coils, inputs, holding, read registers from your devices as sensors, switches, selects, numbers or various other ESPHome components and present them to your favorite Home Automation system. You can even write them as binary or float ouptputs from ESPHome.
|
||||
- let your ESPHome node act as a Modbus server, allowing a ModBUS client to read data (like sensor values) from your ESPHome node.
|
||||
|
||||
To choose the role, set the ``role`` attribute of the :doc:`/components/modbus` upon which this ``modbus_controller`` component relies. ``client`` is the default.
|
||||
|
||||
.. figure:: /images/modbus.png
|
||||
:align: center
|
||||
:width: 25%
|
||||
|
||||
The ``modbus_controller`` component relies on the :doc:`/components/modbus`.
|
||||
|
||||
|
||||
|
||||
Hardware setup
|
||||
@ -64,8 +67,32 @@ Configuration variables:
|
||||
slaves, this avoids waiting for timeouts allowing to read other slaves in the same bus. When the slave
|
||||
responds to a command, it'll be marked online again.
|
||||
|
||||
Example
|
||||
-------
|
||||
- **server_registers** (*Optional*): A list of registers that are responded to when acting as a server.
|
||||
- **start_address** (**Required**, integer): start address of the first register in a range
|
||||
- **value_type** (*Optional*): datatype of the mod_bus register data. The default data type for ModBUS is a 16 bit integer in big endian format (MSB first)
|
||||
|
||||
- ``U_WORD``: unsigned 16 bit integer from 1 register = 16bit
|
||||
- ``S_WORD``: signed 16 bit integer from 1 register = 16bit
|
||||
- ``U_DWORD``: unsigned 32 bit integer from 2 registers = 32bit
|
||||
- ``S_DWORD``: signed 32 bit integer from 2 registers = 32bit
|
||||
- ``U_DWORD_R``: unsigned 32 bit integer from 2 registers low word first
|
||||
- ``S_DWORD_R``: signed 32 bit integer from 2 registers low word first
|
||||
- ``U_QWORD``: unsigned 64 bit integer from 4 registers = 64bit
|
||||
- ``S_QWORD``: signed 64 bit integer from 4 registers = 64bit
|
||||
- ``U_QWORD_R``: unsigned 64 bit integer from 4 registers low word first
|
||||
- ``S_QWORD_R``: signed 64 bit integer from 4 registers low word first
|
||||
- ``FP32``: 32 bit IEEE 754 floating point from 2 registers
|
||||
- ``FP32_R``: 32 bit IEEE 754 floating point - same as FP32 but low word first
|
||||
|
||||
Defaults to ``U_WORD``.
|
||||
|
||||
- **lambda** (**Required**, :ref:`lambda <config-lambda>`):
|
||||
Lambda that returns the value of this register.
|
||||
|
||||
|
||||
Example Client
|
||||
--------------
|
||||
|
||||
The following code creates a ``modbus_controller`` hub talking to a ModBUS device at address ``1`` with ``115200`` bps
|
||||
|
||||
ModBUS sensors can be directly defined (inline) under the ``modbus_controller`` hub or as standalone components
|
||||
@ -118,6 +145,56 @@ Technically there is no difference between the "inline" and the standard definit
|
||||
|
||||
The configuration example above creates a ``modbus_controller`` hub talking to a Modbus device at address ``1`` with a baudrate of ``115200`` bps, implementing a sensor, a switch and a text sensor.
|
||||
|
||||
Example Server
|
||||
--------------
|
||||
|
||||
The following code allows a ModBUS client to read a sensor value from your ESPHome node, that the node itself read from a ModBUS server.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
uart:
|
||||
- id: uart_modbus_client
|
||||
tx_pin: 32
|
||||
rx_pin: 34
|
||||
- id: uart_modbus_server
|
||||
tx_pin: 25
|
||||
rx_pin: 35
|
||||
|
||||
modbus:
|
||||
- uart_id: uart_modbus_client
|
||||
id: modbus_client
|
||||
- uart_id: uart_modbus_server
|
||||
id: modbus_server
|
||||
role: server
|
||||
|
||||
modbus_controller:
|
||||
- id: modbus_evse
|
||||
modbus_id: modbus_client
|
||||
address: 0x2
|
||||
update_interval: 5s
|
||||
- modbus_id: modbus_server
|
||||
address: 0x4
|
||||
server_registers:
|
||||
- start_address: 0x0002
|
||||
value_type: S_DWORD_R
|
||||
lambda: |-
|
||||
return id(evse_voltage_l1).state;
|
||||
|
||||
sensor:
|
||||
- platform: modbus_controller
|
||||
id: evse_voltage_l1
|
||||
modbus_controller_id: modbus_evse
|
||||
name: "EVSE voltage L1"
|
||||
register_type: holding
|
||||
address: 0x0000
|
||||
device_class: voltage
|
||||
value_type: S_DWORD_R
|
||||
accuracy_decimals: 1
|
||||
unit_of_measurement: V
|
||||
filters:
|
||||
- multiply: 0.1
|
||||
|
||||
|
||||
Check out the various Modbus components available at the bottom of the document in the :ref:`modbusseealso` section. They can be directly defined *(inline)* under the ``modbus_controller`` hub or as standalone components. Technically there is no difference between the *inline* and the standard definitions approach.
|
||||
|
||||
Below you find a few general tips about using Modbus in more advanced scenarios. Applicable component functionalities have links pointing here:
|
||||
|
||||
@ -57,6 +57,7 @@ Configuration variables:
|
||||
- **device_class** (*Optional*, string): The device class for the number.
|
||||
See https://www.home-assistant.io/integrations/number/#device-class
|
||||
for a list of available options.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
Automations:
|
||||
|
||||
@ -69,6 +70,7 @@ MQTT Options:
|
||||
|
||||
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
|
||||
|
||||
Number Automation
|
||||
-----------------
|
||||
|
||||
|
||||
52
components/one_wire.rst
Normal file
52
components/one_wire.rst
Normal file
@ -0,0 +1,52 @@
|
||||
.. _one_wire:
|
||||
|
||||
1-Wire Bus
|
||||
==========
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up a Dallas (Analog Devices) 1-Wire bus to communicate with 1-wire devices in ESPHome
|
||||
:image: one-wire.svg
|
||||
:keywords: Dallas, onewire, 1-wire
|
||||
|
||||
The ``one_wire`` component allows you to use supported 1-Wire devices in ESPHome.
|
||||
The 1-Wire bus the devices are connected to should have an external pullup resistor of
|
||||
about 4.7KΩ. For this, connect a resistor of *about* 4.7KΩ between ``3.3V``
|
||||
and the data pin. Values ± 1KΩ will, in most cases, work fine as well,
|
||||
if you don't have massively long wires.
|
||||
|
||||
GPIO
|
||||
----
|
||||
|
||||
The ``gpio`` platform uses the CPU to generate the bus signals on a GPIO pin.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
one_wire:
|
||||
- platform: gpio
|
||||
pin: GPIOXX
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **pin** (**Required**, number): The pin the sensor bus is connected to. Please note that 1-wire is a bi-directional bus so it requires both input and output from the pin.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. Required if you have multiple busses.
|
||||
|
||||
|
||||
Getting Sensor IDs
|
||||
******************
|
||||
|
||||
In order to find the addresses, simply start the firmware on your
|
||||
device with a configured one_wire hub and observe the log output.
|
||||
Note that you don't need to define the individual sensors just yet, as
|
||||
the scanning will happen even with no sensors configured.
|
||||
For example, you will see something like this:
|
||||
|
||||
.. figure:: images/dallas-log.png
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :apiref:`one_wire/one_wire_bus.h`
|
||||
- :ghedit:`Edit`
|
||||
- `Guidelines for Reliable Long Line 1-Wire Networks <https://www.analog.com/en/technical-articles/guidelines-for-reliable-long-line-1wire-networks.html>`__
|
||||
@ -1,89 +1,73 @@
|
||||
OTA Update Component
|
||||
====================
|
||||
ESPHome OTA Updates
|
||||
===================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Over-The-Air (OTA) updates for ESPs to upload firmwares remotely.
|
||||
:description: Instructions for setting up ESPHome's Over-The-Air (OTA) platform to allow remote updating of devices.
|
||||
:image: system-update.svg
|
||||
|
||||
.. _config-ota:
|
||||
|
||||
With the OTA (Over The Air) update component you can upload your
|
||||
firmware binaries to your node without having to use a USB cable for
|
||||
uploads. ESPHome natively supports this through its ``run`` and
|
||||
``upload`` helper scripts.
|
||||
ESPHome's Over-The-Air (OTA) platform allows you to remotely install modified/updated firmware binaries onto your
|
||||
ESPHome devices over their network (Wi-Fi or Ethernet) interface.
|
||||
|
||||
ESPHome also has an "OTA safe mode". If for some reason your
|
||||
node gets into a boot loop, ESPHome will automatically try to detect
|
||||
this and will go over into a safe mode after the configured unsuccessful boot
|
||||
attempts (Defaults to ``10``). In that mode, all components are disabled and only Serial
|
||||
Logging + Network(WiFi or Ethernet) + OTA are initialized, so that you can upload a new
|
||||
binary. You can trigger entering safe mode by either configuring a dedicated button or
|
||||
switch to do that or by pressing the reset button on the board for ``num_attempts`` times.
|
||||
This platform is used by both the ESPHome dashboard as well as the command line interface (CLI) (via
|
||||
``esphome run ...``) to install firmware onto supported devices.
|
||||
|
||||
In addition to OTA updates, ESPHome also supports a "safe mode" to help with recovery if/when updates don't work as
|
||||
expected. This is automatically enabled by this component, but it may be disabled if desired. See
|
||||
:doc:`/components/safe_mode` for details.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
ota:
|
||||
safe_mode: true
|
||||
password: !secret ota_password
|
||||
- platform: esphome
|
||||
safe_mode: true
|
||||
password: !secret ota_password
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **safe_mode** (*Optional*, boolean): Whether to enable safe mode.
|
||||
Defaults to ``true``.
|
||||
- **password** (*Optional*, string): The password to use for updates.
|
||||
- **port** (*Optional*, int): The port to use for OTA updates.
|
||||
Defaults:
|
||||
- **port** (*Optional*, int): The port to use for OTA updates. Defaults:
|
||||
|
||||
- ``3232`` for the ESP32
|
||||
- ``8266`` for the ESP8266
|
||||
- ``2040`` for the RP2040
|
||||
- ``8892`` for Beken chips
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **reboot_timeout** (*Optional*, :ref:`config-time`): The amount of time to wait before rebooting when in
|
||||
safe mode. Defaults to ``5min``.
|
||||
- **num_attempts** (*Optional*, int): The number of attempts to wait before entering safe mode. Defaults to ``10``.
|
||||
- **on_begin** (*Optional*, :ref:`Automation<automation>`): An action to be
|
||||
performed when an OTA update is started. See :ref:`ota-on_begin`.
|
||||
- **on_progress** (*Optional*, :ref:`Automation<automation>`): An action to be
|
||||
performed (multiple times) during an OTA update. See :ref:`ota-on_progress`.
|
||||
- **on_end** (*Optional*, :ref:`Automation<automation>`): An action to be
|
||||
performed after a successful OTA update. See :ref:`ota-on_end`.
|
||||
- **on_error** (*Optional*, :ref:`Automation<automation>`): An action to be
|
||||
performed after a failed OTA update. See :ref:`ota-on_error`.
|
||||
- **on_state_change** (*Optional*, :ref:`Automation<automation>`): An action to be
|
||||
performed when an OTA update state change happens. See :ref:`ota-on_state_change`.
|
||||
- **version** (*Optional*, int): Version of OTA protocol to use. Version 2 is more stable.
|
||||
To downgrade to legacy ESPHome, the device should be updated with OTA version 1 first.
|
||||
Defaults to ``2``.
|
||||
- **on_begin** (*Optional*, :ref:`Automation<automation>`): An action to be performed when an OTA update is started.
|
||||
See :ref:`ota-on_begin`.
|
||||
- **on_progress** (*Optional*, :ref:`Automation<automation>`): An action to be performed (approximately each second)
|
||||
while an OTA update is in progress. See :ref:`ota-on_progress`.
|
||||
- **on_end** (*Optional*, :ref:`Automation<automation>`): An action to be performed after a successful OTA update.
|
||||
See :ref:`ota-on_end`.
|
||||
- **on_error** (*Optional*, :ref:`Automation<automation>`): An action to be performed after a failed OTA update.
|
||||
See :ref:`ota-on_error`.
|
||||
- **on_state_change** (*Optional*, :ref:`Automation<automation>`): An action to be performed when an OTA update state
|
||||
change happens. See :ref:`ota-on_state_change`.
|
||||
- **version** (*Optional*, int): Version of OTA protocol to use. Version 2 is more stable. To downgrade to legacy
|
||||
ESPHome, the device should be updated with OTA version 1 first. Defaults to ``2``.
|
||||
|
||||
.. note::
|
||||
|
||||
Please be aware that ESP8266 modules must be reset after a serial
|
||||
upload before OTA can work.
|
||||
When you are trying to conduct an OTA update and receive an error message
|
||||
``Bad Answer: ERR: ERROR[11]: Invalid bootstrapping`` the reason is
|
||||
very likely that power-cycling the ESP module is required once after
|
||||
the serial upload.
|
||||
After a serial upload, ESP8266 modules must be reset before OTA updates will work. If you attempt to perform an OTA
|
||||
update and receive the error message ``Bad Answer: ERR: ERROR[11]: Invalid bootstrapping``, the ESP module/board
|
||||
must be power-cycled.
|
||||
|
||||
OTA Automation
|
||||
--------------
|
||||
.. _ota-automations:
|
||||
|
||||
The OTA component provides various automations that can be used to provide feedback
|
||||
during an OTA update. There are a few things to consider when making use of the
|
||||
provided automation triggers:
|
||||
OTA Automations
|
||||
---------------
|
||||
|
||||
- An OTA update blocks the main loop during its operation. This means that you
|
||||
won't be able to represent state changes using components that update their
|
||||
output only from within their ``loop()`` method. Explained differently: if you
|
||||
try to display the OTA progress using component X, but the update only appears
|
||||
after the OTA update finished, then component X cannot be used for providing
|
||||
OTA update feedback.
|
||||
The OTA component provides various :ref:`automations <automation>` that can be used to provide feedback during the OTA
|
||||
update process. When using these automation triggers, note that:
|
||||
|
||||
- Make sure that your automation actions do not take too much time, to prevent
|
||||
them from blocking the OTA update code for too long.
|
||||
- OTA updates block the main application loop while in progress. You won't be able to represent state changes using
|
||||
components that update their output only from within their ``loop()`` method. Explained differently: if you try to
|
||||
display the OTA progress using component X, but the update only appears after the OTA update finished, then component
|
||||
X cannot be used for providing OTA update feedback.
|
||||
- Your automation action(s) must not consume any significant amount of time; if they do, OTA updates may fail.
|
||||
|
||||
.. _ota-on_begin:
|
||||
|
||||
@ -104,9 +88,8 @@ This automation will be triggered when an OTA update is started.
|
||||
``on_progress``
|
||||
***************
|
||||
|
||||
Using this automation, it is possible to report on the OTA update progress.
|
||||
It will be triggered multiple times during the OTA update. You can get the actual
|
||||
progress percentage (a value between 0 and 100) from the trigger with variable ``x``.
|
||||
Using this automation, it is possible to report on the OTA update progress. It will be triggered repeatedly during the
|
||||
OTA update. You can get the actual progress percentage (a value between 0 and 100) from the trigger with variable ``x``.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -122,13 +105,12 @@ progress percentage (a value between 0 and 100) from the trigger with variable `
|
||||
``on_end``
|
||||
**********
|
||||
|
||||
This automation will be triggered when an OTA update has completed successfully,
|
||||
right before the device is rebooted.
|
||||
This automation will be triggered when an OTA update has completed successfully, immediately before the device is
|
||||
rebooted.
|
||||
|
||||
Because the update has completed, you can safely use an automation action that
|
||||
takes some time to complete. This can for example be useful if you want to flash
|
||||
a LED or so, in which case a pause would be required to make the LED light up
|
||||
for long enough, before the reboot turns it off.
|
||||
Because the update has completed, you can safely use (an) automation action(s) that takes some time to complete. If,
|
||||
for example, you want to flash an LED, multiple pauses/delays would be required to make the LED blink a few times,
|
||||
before the reboot. The OTA update can't fail at this point because it is already complete.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -142,11 +124,10 @@ for long enough, before the reboot turns it off.
|
||||
``on_error``
|
||||
************
|
||||
|
||||
This automation will be triggered when an OTA update has failed. You can get
|
||||
the internal error code with variable ``x``.
|
||||
This automation will be triggered when an OTA update has failed. You can get the internal error code with variable ``x``.
|
||||
|
||||
Just like for :ref:`ota-on_end`, you can safely use an automation that
|
||||
takes some time to complete, because the OTA update is no longer busy.
|
||||
Just like for :ref:`ota-on_end`, you can safely use an automation that takes some time to complete as the OTA update
|
||||
process has already finished.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -162,12 +143,11 @@ takes some time to complete, because the OTA update is no longer busy.
|
||||
``on_state_change``
|
||||
*******************
|
||||
|
||||
This automation will be triggered on every state change. You can get the actual
|
||||
state with variable ``state``, which will contain one of values for the OTAState
|
||||
enum. These values are:
|
||||
This automation will be triggered on every state change. You can get the actual state with variable ``state``, which
|
||||
will contain one of values for the ``OTAState`` enum. These values are:
|
||||
|
||||
- ``ota::OTA_STARTED``
|
||||
- ``ota::OTA_IN_PROGRESS`` (will be called multiple times during the update)
|
||||
- ``ota::OTA_IN_PROGRESS`` *(will be called repeatedly during the update)*
|
||||
- ``ota::OTA_COMPLETED``
|
||||
- ``ota::OTA_ERROR``
|
||||
|
||||
@ -182,15 +162,14 @@ enum. These values are:
|
||||
then:
|
||||
- logger.log: "OTA start"
|
||||
|
||||
Updating the password:
|
||||
----------------------
|
||||
Updating the Password
|
||||
---------------------
|
||||
|
||||
Changing an existing 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:
|
||||
Since the configured password is used for both compiling and uploading, the regular ``esphome run <file>`` command
|
||||
won't work. This issue can be worked around by executing the operations separately with an ``on_boot`` trigger:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -198,15 +177,19 @@ through an ``on_boot`` trigger:
|
||||
on_boot:
|
||||
- lambda: |-
|
||||
id(my_ota).set_auth_password("New password");
|
||||
|
||||
ota:
|
||||
password: "Old password"
|
||||
id: my_ota
|
||||
- platform: esphome
|
||||
id: my_ota
|
||||
password: "Old password"
|
||||
|
||||
Adding a password:
|
||||
******************
|
||||
After this trick has been used to change the password, the ``on_boot`` trigger may be removed and the old password
|
||||
replaced with the new password in the ``ota:`` section.
|
||||
|
||||
If OTA is already enabled without a password, simply add a ``password:`` line to the existing
|
||||
``ota:`` config block.
|
||||
Adding a Password
|
||||
*****************
|
||||
|
||||
If OTA is already enabled without a password, simply add a ``password:`` line to the existing ``ota:`` config block.
|
||||
|
||||
See Also
|
||||
--------
|
||||
@ -214,4 +197,5 @@ See Also
|
||||
- :apiref:`ota/ota_component.h`
|
||||
- :doc:`/components/button/safe_mode`
|
||||
- :doc:`/components/switch/safe_mode`
|
||||
- :doc:`/components/ota_http_request`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
110
components/ota_http_request.rst
Normal file
110
components/ota_http_request.rst
Normal file
@ -0,0 +1,110 @@
|
||||
OTA Update via HTTP Request
|
||||
===========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Over-The-Air (OTA) updates for ESPs to download firmwares remotely by HTTP.
|
||||
:image: system-update.svg
|
||||
|
||||
The OTA (Over The Air) via HTTP Request update component allows your devices to install updated firmware on their own.
|
||||
To use it, in your device's configuration, you specify a URL from which the device will download the binary
|
||||
file (firmware). To trigger the update, an ESPHome :ref:`action <config-action>` is used which initiates the
|
||||
download and installation of the new firmware. Once complete, the device is rebooted, invoking the new firmware.
|
||||
|
||||
Since the device functions as an HTTP(S) client, it can be on a foreign network or behind a firewall. This mechanism
|
||||
is primarily useful with either standalone or MQTT-only devices.
|
||||
|
||||
To use this platform, the :doc:`http_request` component must be present in your configuration.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
ota:
|
||||
- platform: http_request
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- All :ref:`automations <ota-automations>` supported by :doc:`ota`.
|
||||
|
||||
.. _ota_http_request-flash_action:
|
||||
|
||||
``ota.http_request.flash`` Action
|
||||
---------------------------------
|
||||
|
||||
This action triggers the download and installation of the updated firmware from the configured URL. As it's an
|
||||
ESPHome :ref:`action <config-action>`, it may be used in any ESPHome :ref:`automation(s) <automation>`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
- ota.http_request.flash:
|
||||
md5_url: http://example.com/firmware.md5
|
||||
url: https://example.com/firmware.bin
|
||||
- logger.log: "This message should be not displayed because the device reboots"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **md5** (*Optional*, string, :ref:`templatable <config-templatable>`): The
|
||||
`MD5sum <https://en.wikipedia.org/wiki/Md5sum>`_ of the firmware file pointed to by ``url`` (below). May not be used
|
||||
with ``md5_url`` (below); must be specified if ``md5_url`` is not.
|
||||
- **md5_url** (*Optional*, string, :ref:`templatable <config-templatable>`): The URL of the file containing an
|
||||
`MD5sum <https://en.wikipedia.org/wiki/Md5sum>`_ of the firmware file pointed to by ``url`` (below). May not be used
|
||||
with ``md5`` (above); must be specified if ``md5`` is not.
|
||||
- **url** (**Required**, string, :ref:`templatable <config-templatable>`): The URL of the binary file containing the
|
||||
(new) firmware to be installed.
|
||||
- **username** (*Optional*, string, :ref:`templatable <config-templatable>`): The username to use for HTTP basic
|
||||
authentication.
|
||||
- **password** (*Optional*, string, :ref:`templatable <config-templatable>`): The password to use for HTTP basic
|
||||
authentication.
|
||||
|
||||
.. note::
|
||||
|
||||
- You can obtain the ``firmware.bin`` file from either:
|
||||
|
||||
- **ESPHome dashboard** (HA add-on): download in *"Legacy format"*
|
||||
- **ESPHome CLI**: the directory ``.esphome/build/project/.pioenvs/project/firmware.bin``
|
||||
|
||||
...where *"project"* is the name of your ESPHome device/project.
|
||||
|
||||
You **cannot** use ``firmware-factory.bin`` or *"Modern format"* with this component.
|
||||
|
||||
- ``username`` and ``password`` must be `URL-encoded <https://en.wikipedia.org/wiki/Percent-encoding>`_ if they
|
||||
include special characters.
|
||||
|
||||
- The `MD5sum <https://en.wikipedia.org/wiki/Md5sum>`_ of the firmware binary file is an ASCII file (also known
|
||||
as "plain text", typically found in files with a ``.txt`` extension) consisting of 32 lowercase hexadecimal
|
||||
characters. It can be obtained and saved to a file with the following command(s):
|
||||
|
||||
- On macOS:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
md5 -q firmware.bin > firmware.md5
|
||||
|
||||
- On most Linux distributions:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
md5sum firmware.bin > firmware.md5
|
||||
|
||||
- On Windows/PowerShell:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
(Get-FileHash -Path firmware.bin -Algorithm md5).Hash.ToLower() | Out-File -FilePath firmware.md5 -Encoding ASCII
|
||||
|
||||
This will generate the MD5 hash of the ``firmware.bin`` file and write the resulting hash value to the
|
||||
``firmware.md5`` file. The ``md5_url`` configuration variable should point to this file on the web server.
|
||||
It is used by the OTA updating mechanism to ensure the integrity of the (new) firmware as it is installed.
|
||||
|
||||
**If, for any reason, the MD5sum provided does not match the MD5sum computed as the firmware is installed, the
|
||||
device will continue to use the original firmware and the new firmware is discarded.**
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/ota`
|
||||
- :doc:`/components/http_request`
|
||||
- :ghedit:`Edit`
|
||||
@ -59,6 +59,7 @@ Configuration variables:
|
||||
- **samsung36**: Decode and dump Samsung36 infrared codes.
|
||||
- **sony**: Decode and dump Sony infrared codes.
|
||||
- **toshiba_ac**: Decode and dump Toshiba AC infrared codes.
|
||||
- **mirage**: Decode and dump Mirage infrared codes.
|
||||
|
||||
- **tolerance** (*Optional*, int, :ref:`config-time` or mapping): The percentage or time that the remote signal lengths can
|
||||
deviate in the decoding process. Defaults to ``25%``.
|
||||
@ -189,6 +190,9 @@ Automations:
|
||||
- **on_toshiba_ac** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
|
||||
Toshiba AC remote code has been decoded. A variable ``x`` of type :apistruct:`remote_base::ToshibaAcData`
|
||||
is passed to the automation for use in lambdas.
|
||||
- **on_mirage** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
|
||||
Mirage remote code has been decoded. A variable ``x`` of type :apistruct:`remote_base::MirageData`
|
||||
is passed to the automation for use in lambdas.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -430,6 +434,11 @@ Remote code selection (exactly one of these has to be included):
|
||||
- **rc_code_1** (**Required**, int): The remote control code to trigger on, see dumper output for more details.
|
||||
- **rc_code_2** (*Optional*, int): The second part of the remote control code to trigger on, see dumper output for more details.
|
||||
|
||||
- **mirage**: Trigger on a Mirage remote code with the given code.
|
||||
|
||||
- **code** (**Required**, 14-bytes list): The code to listen for, see :ref:`remote_transmitter-transmit_mirage`
|
||||
for more info. Usually you only need to copy this directly from the dumper output.
|
||||
|
||||
.. note::
|
||||
|
||||
The **CanalSat** and **CanalSatLD** protocols use a higher carrier frequency (56khz) and are very similar.
|
||||
|
||||
@ -148,6 +148,8 @@ 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.
|
||||
- **carrier_frequency** (*Optional*, float): Set a frequency to send the signal
|
||||
with for infrared signals. Defaults to ``38000Hz``.
|
||||
|
||||
AEHA refers to the Association for Electric Home Appliances in Japan, a format used by Panasonic and many other companies.
|
||||
|
||||
@ -886,6 +888,23 @@ Configuration variables:
|
||||
|
||||
- All other options from :ref:`remote_transmitter-transmit_action`.
|
||||
|
||||
.. _remote_transmitter-transmit_mirage:
|
||||
|
||||
``remote_transmitter.transmit_mirage`` Action
|
||||
*********************************************
|
||||
|
||||
This :ref:`action <config-action>` sends a 112-bit Mirage code to a remote transmitter. 8-bits of checksum added automatically.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
- remote_transmitter.transmit_mirage:
|
||||
code: [0x56, 0x77, 0x00, 0x00, 0x22, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **code** (**Required**, list): The 14 byte Mirage code to send.
|
||||
- All other options from :ref:`remote_transmitter-transmit_action`.
|
||||
|
||||
Lambda calls
|
||||
************
|
||||
|
||||
53
components/safe_mode.rst
Normal file
53
components/safe_mode.rst
Normal file
@ -0,0 +1,53 @@
|
||||
Safe Mode
|
||||
=========
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up ESPHome's Safe Mode to help recover from repeated boot failures.
|
||||
:image: system-update.svg
|
||||
|
||||
Sometimes hardware and/or software doesn't behave as expected. ESPHome supports a "safe mode" to help recover from
|
||||
repeated boot failures/reboot loops. After a specified number (the default is ten) of boot failures, the safe mode may
|
||||
be invoked; in this mode, all components are disabled except serial logging, network (Wi-Fi or Ethernet) and the OTA
|
||||
component(s). In most cases, this will temporarily mitigate the issue, allowing you a chance to correct it, perhaps by
|
||||
uploading a new binary.
|
||||
|
||||
You can also force the invocation of safe mode by configuring a dedicated :doc:`button</components/button/safe_mode>`
|
||||
or :doc:`switch</components/switch/safe_mode>` component and/or by repeatedly pressing the reset button on the board
|
||||
for ``num_attempts`` times (see below).
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
safe_mode:
|
||||
|
||||
.. _safe_mode-configuration_variables:
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **disabled** (*Optional*, boolean): Set to ``true`` to disable safe_mode. :doc:`/components/ota` automatically sets
|
||||
up safe mode; this allows disabling it if/when it is not wanted.
|
||||
- **boot_is_good_after** (*Optional*, :ref:`config-time`): The amount of time after which the boot is considered successful.
|
||||
Defaults to ``1min``.
|
||||
- **num_attempts** (*Optional*, int): The number of failed boot attempts which must occur before invoking safe mode.
|
||||
Defaults to ``10``.
|
||||
- **reboot_timeout** (*Optional*, :ref:`config-time`): The amount of time to wait before rebooting when in safe mode.
|
||||
Defaults to ``5min``.
|
||||
- **on_safe_mode** (*Optional*, :ref:`Automation <automation>`): An action to be performed once when safe mode is invoked.
|
||||
|
||||
.. warning::
|
||||
|
||||
The ``on_safe_mode`` :ref:`automation <automation>` is intended for use by recovery actions **only**.
|
||||
|
||||
As mentioned above, in safe mode, all components are disabled except serial logging, network (Wi-Fi or Ethernet)
|
||||
and OTA component(s).
|
||||
|
||||
**All other components (for example, displays and sensors) are disabled and cannot be used.**
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :apiref:`safe_mode/safe_mode.h`
|
||||
- :doc:`/components/button/safe_mode`
|
||||
- :doc:`/components/switch/safe_mode`
|
||||
- :ghedit:`Edit`
|
||||
@ -48,6 +48,7 @@ Configuration variables:
|
||||
See https://developers.home-assistant.io/docs/core/entity/#generic-properties
|
||||
for a list of available options.
|
||||
Set to ``""`` to remove the default entity category.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
Automations:
|
||||
|
||||
|
||||
@ -35,6 +35,7 @@ Configuration variables:
|
||||
- **attenuation** (*Optional*): Only on ESP32. Specify the ADC
|
||||
attenuation to use. See :ref:`adc-esp32_attenuation`. Defaults to ``0db``.
|
||||
- **raw** (*Optional*): Allows to read the raw ADC output without any conversion or calibration. See :ref:`adc-raw`. Defaults to ``false``.
|
||||
- **samples** (*Optional*): The amount of ADC readings to take per sensor update. On the ESP32 this value is ignored if ``attenuation`` is set to ``auto``. Defaults to ``1``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval
|
||||
to check the sensor. Defaults to ``60s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
@ -199,6 +200,7 @@ on GPIO34.
|
||||
accuracy_decimals: 2
|
||||
update_interval: 60s
|
||||
attenuation: 12dB
|
||||
samples: 10
|
||||
filters:
|
||||
- multiply: 2.0 # The voltage divider requires us to multiply by 2
|
||||
|
||||
|
||||
@ -28,6 +28,10 @@ instructions for setting up this platform.
|
||||
- platform: ble_rssi
|
||||
mac_address: AC:37:43:77:5F:4C
|
||||
name: "BLE Google Home Mini RSSI value"
|
||||
# RSSI based on Identity Resolving Key (IRK)
|
||||
- platform: ble_rssi
|
||||
irk: 1234567890abcdef1234567890abcdef
|
||||
name: "BLE Tracker iPhone"
|
||||
# RSSI based on Service UUID
|
||||
- platform: ble_rssi
|
||||
service_uuid: '11aa'
|
||||
@ -47,13 +51,17 @@ Configuration variables:
|
||||
|
||||
- **name** (**Required**, string): The name of the sensor.
|
||||
- **mac_address** (*Optional*, MAC Address): The MAC address to track for this
|
||||
sensor. Note that exactly one of ``mac_address``, ``service_uuid`` or ``ibeacon_uuid`` must be present.
|
||||
sensor. Note that exactly one of ``mac_address``, ``irk``, ``service_uuid`` or ``ibeacon_uuid``
|
||||
must be present.
|
||||
- **irk** (*Optional*, 16 byte hex string): The Identity Resolving Key (IRK) to track for this
|
||||
sensor. Note that exactly one of ``mac_address``, ``irk``, ``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. Note that exactly one of
|
||||
``mac_address``, ``service_uuid`` or ``ibeacon_uuid`` must be present.
|
||||
``mac_address``, ``irk``, ``service_uuid`` or ``ibeacon_uuid`` must be present.
|
||||
- **ibeacon_uuid** (*Optional*, string): The `universally unique identifier <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__
|
||||
to identify the beacon that needs to be tracked. Note that exactly one of ``mac_address``,
|
||||
``service_uuid`` or ``ibeacon_uuid`` must be present.
|
||||
``irk``, ``service_uuid`` or ``ibeacon_uuid`` must be present.
|
||||
- **ibeacon_major** (*Optional*, int): The iBeacon major identifier of the beacon that needs
|
||||
to be tracked. Usually used to group beacons, for example for grouping all beacons in the
|
||||
same building.
|
||||
|
||||
@ -1,170 +0,0 @@
|
||||
Dallas Temperature Sensor
|
||||
=========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Dallas temperature sensor hubs that can
|
||||
expose many temperature sensors on a single pin using the 1-Wire protocol.
|
||||
:image: dallas.jpg
|
||||
:keywords: Dallas, ds18b20, onewire
|
||||
|
||||
.. _dallas-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``dallas`` component allows you to use your
|
||||
`DS18b20 <https://www.adafruit.com/product/374>`__
|
||||
(`datasheet <https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf>`__)
|
||||
and similar 1-Wire temperature sensors.
|
||||
|
||||
To use your :ref:`dallas sensor <dallas-sensor>`, first define a dallas “hub” with a pin and
|
||||
id, which you will later use to create the sensors. The 1-Wire bus the
|
||||
sensors are connected to should have an external pullup resistor of
|
||||
about 4.7KΩ. For this, connect a resistor of *about* 4.7KΩ between ``3.3V``
|
||||
and the data pin. Values ± 1KΩ will, in most cases, work fine as well,
|
||||
if you don't have massively long wires.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
dallas:
|
||||
- pin: GPIOXX
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **pin** (**Required**, number): The pin the sensor bus is connected to. Please note that 1-wire is a bi-directional bus so it requires both input and output from the pin.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval that the sensors should be checked.
|
||||
Defaults to 60 seconds.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
.. _dallas-sensor:
|
||||
|
||||
Sensor
|
||||
------
|
||||
|
||||
The ``dallas`` sensor allows you to use DS18B20 and similar sensors.
|
||||
First, you need to define a :ref:`dallas sensor component <dallas-component>`.
|
||||
The dallas sensor component (or "hub") is an internal model that defines which pins the DS18B20
|
||||
sensors are connected to. This is because with these sensors you can actually connect multiple
|
||||
sensors to a single pin and use them all at once.
|
||||
|
||||
To initialize a sensor, first supply either ``address`` **or** ``index`` to identify the sensor.
|
||||
|
||||
.. figure:: images/dallas-wired.jpg
|
||||
:align: center
|
||||
:width: 50.0%
|
||||
|
||||
Wired Version of the DS18B20 1-Wire Temperature Sensor.
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/374
|
||||
|
||||
.. figure:: images/temperature.png
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Individual sensors
|
||||
sensor:
|
||||
- platform: dallas
|
||||
address: 0x1C0000031EDD2A28
|
||||
name: "Living Room Temperature"
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **address** (**Required**, int): The address of the sensor. Use either
|
||||
this option or index.
|
||||
- **index** (**Required**, int): The index of the sensor starting with 0.
|
||||
So the first sensor will for example have index 0. :ref:`It’s recommended
|
||||
to use address instead <dallas-getting-ids>`.
|
||||
- **resolution** (*Optional*, int): An optional resolution from 9 to
|
||||
12. Higher means more accurate. Defaults to the maximum for most Dallas temperature sensors: 12.
|
||||
- **dallas_id** (*Optional*, :ref:`config-id`): The ID of the :ref:`dallas hub <dallas-component>`.
|
||||
Use this if you have multiple dallas hubs.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
.. _dallas-getting-ids:
|
||||
|
||||
Getting Sensor IDs
|
||||
******************
|
||||
|
||||
It is highly recommended to use the ``address`` attribute for creating
|
||||
dallas sensors, because if you have multiple sensors on a bus and the
|
||||
automatic sensor discovery fails, all sensors indices will be shifted by
|
||||
one. In order to get the address, simply start the firmware on your
|
||||
device with a configured dallas hub and observe the log output (the :ref:`log
|
||||
level <logger-log_levels>` must be set to at least
|
||||
``debug``!). Note that you don't need to define the individual sensors just yet, as
|
||||
the scanning will happen even with no sensors connected. For example with this configuration:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
dallas:
|
||||
- pin: GPIOXX
|
||||
|
||||
# Note you don't have to add any sensors at this point
|
||||
|
||||
You will find something like this:
|
||||
|
||||
.. figure:: images/dallas-log.png
|
||||
|
||||
Now we can add the individual sensors to our configuration:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
dallas:
|
||||
- pin: GPIOXX
|
||||
|
||||
sensor:
|
||||
- platform: dallas
|
||||
address: 0xA40000031F055028
|
||||
name: "Temperature #1"
|
||||
- platform: dallas
|
||||
address: 0xDD0000031EFB0428
|
||||
name: "Temperature #2"
|
||||
- platform: dallas
|
||||
# ...
|
||||
|
||||
Next, individually warm up or cool down the sensors and observe the log again.
|
||||
You will see the outputted sensor values changing when they're being warmed.
|
||||
When you're finished mapping each address to a name, just change the ``Temperature #1``
|
||||
to your assigned names and you should be ready.
|
||||
|
||||
Multiple dallas hubs
|
||||
********************
|
||||
|
||||
Use this if you have multiple dallas hubs:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
dallas:
|
||||
- pin: GPIOXX
|
||||
id: hub_1
|
||||
- pin: GPIOXX
|
||||
id: hub_2
|
||||
|
||||
sensor:
|
||||
- platform: dallas
|
||||
dallas_id: hub_1
|
||||
# ...
|
||||
- platform: dallas
|
||||
dallas_id: hub_2
|
||||
# ...
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`max6675`
|
||||
- `Arduino DallasTemperature library <https://github.com/milesburton/Arduino-Temperature-Control-Library>`__
|
||||
by `Miles Burton <https://github.com/milesburton>`__
|
||||
- :apiref:`dallas/dallas_component.h`
|
||||
- :ghedit:`Edit`
|
||||
- `Guidelines for Reliable Long Line 1-Wire Networks <https://www.analog.com/en/technical-articles/guidelines-for-reliable-long-line-1wire-networks.html>`__
|
||||
41
components/sensor/dallas_temp.rst
Normal file
41
components/sensor/dallas_temp.rst
Normal file
@ -0,0 +1,41 @@
|
||||
Dallas Temperature Sensor
|
||||
=========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Dallas 1-Wire temperature sensors
|
||||
:image: dallas.jpg
|
||||
:keywords: Dallas, ds18b20, onewire
|
||||
|
||||
The ``dallas_temp`` component allows you to use
|
||||
`DS18B20 <https://www.adafruit.com/product/374>`__
|
||||
(`datasheet <https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf>`__)
|
||||
and similar 1-Wire temperature sensors. A :ref:`1-Wire bus <one_wire>` is
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: dallas_temp
|
||||
address: 0x1234567812345628
|
||||
name: temperature
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **address** (*Optional*, int): The address of the sensor. Required if there is more than one device on the bus.
|
||||
- **resolution** (*Optional*, int): An optional resolution from 9 to 12. Higher means more accurate.
|
||||
Defaults to the maximum for most Dallas temperature sensors: 12.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval that the sensors should be checked.
|
||||
Defaults to 60 seconds.
|
||||
- **one_wire_id** (*Optional*, :ref:`one_wire`): The ID of the 1-Wire bus to use.
|
||||
Required if there is more than one bus.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- `Arduino DallasTemperature library <https://github.com/milesburton/Arduino-Temperature-Control-Library>`__
|
||||
by `Miles Burton <https://github.com/milesburton>`__
|
||||
- :apiref:`dallas_temp/dallas_temp.h`
|
||||
- :ghedit:`Edit`
|
||||
@ -6,8 +6,8 @@ ENS160 Sensor
|
||||
:keywords: ENS160
|
||||
|
||||
The ``ens160`` sensor platform allows you to use your ENS160
|
||||
(`datasheet <https://www.sciosense.com/wp-content/uploads/documents/SC-001224-DS-9-ENS160-Datasheet.pdf>`__) air-quality sensors with ESPHome. The :ref:`I²C <i2c>` component is
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
(`datasheet <https://www.sciosense.com/wp-content/uploads/documents/SC-001224-DS-9-ENS160-Datasheet.pdf>`__) air-quality sensors with ESPHome.
|
||||
The :ref:`I²C <i2c>` or :ref:`SPI <spi>` is required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -23,9 +23,9 @@ required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
# Example configuration entry I2C
|
||||
sensor:
|
||||
- platform: ens160
|
||||
- platform: ens160_i2c
|
||||
eco2:
|
||||
name: "ENS160 eCO2"
|
||||
tvoc:
|
||||
@ -38,7 +38,22 @@ required to be set up in your configuration for this sensor to work.
|
||||
compensation:
|
||||
temperature: id_temperature_sensor
|
||||
humidity: id_humidity_sensor
|
||||
|
||||
|
||||
# Example configuration entry SPI
|
||||
sensor:
|
||||
- platform: ens160_spi
|
||||
eco2:
|
||||
name: "ENS160 eCO2"
|
||||
tvoc:
|
||||
name: "ENS160 Total Volatile Organic Compounds"
|
||||
aqi:
|
||||
name: "ENS160 Air Quality Index"
|
||||
update_interval: 60s
|
||||
cs_pin: GPIO5
|
||||
compensation:
|
||||
temperature: id_temperature_sensor
|
||||
humidity: id_humidity_sensor
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
@ -65,11 +80,14 @@ Configuration variables:
|
||||
sensor. Defaults to ``60s``. The update interval should be greater than the measurement
|
||||
frequency of the ENS160 which is up to 1 second.
|
||||
|
||||
- **address** (*Optional*, int): *I²C only.* Manually specify the I²C address of
|
||||
the sensor. Defaults to ``0x53``. Another address can be ``0x52``.
|
||||
|
||||
- **cs_pin** (*Required*, :ref:`Pin Schema <config-pin_schema>`): *SPI only.* The Chip Select pin.
|
||||
|
||||
|
||||
Advanced:
|
||||
|
||||
- **address** (*Optional*, int): Manually specify the I²C address of
|
||||
the sensor. Defaults to ``0x53``. Another address can be ``0x52``.
|
||||
|
||||
- **compensation** (*Optional*): The block containing sensors used for compensation.
|
||||
Temperature and humidity compensation improves the accuracy of sensor readings. Without compensation, the
|
||||
ENS160 internally assumes 25°C temperature and 50% humidity, with readings noticeably diverting from real changes without compensation in temperature and humidity.
|
||||
|
||||
125
components/sensor/gdk101.rst
Normal file
125
components/sensor/gdk101.rst
Normal file
@ -0,0 +1,125 @@
|
||||
FTLab GDK101 Gamma Radiation Sensor Module
|
||||
==========================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up GDK101 Gamma Radiation Sensor Module
|
||||
:image: gdk101.jpg
|
||||
:keywords: gdk101
|
||||
|
||||
The **GDK101** sensor platform allows you to use your GDK101 sensor to monitor radiation levels at your place.
|
||||
|
||||
The GDK101 can measure average dose rate per 1 and 10 minutes, it also detect vibrations that can disturb the measurement.
|
||||
|
||||
The GDK101 requires setting up :ref:`I²C <i2c>` for data communication.
|
||||
|
||||
Module Pins
|
||||
-----------
|
||||
|
||||
============ ===============================================================
|
||||
Module Pin Description
|
||||
============ ===============================================================
|
||||
TX UART TX pin
|
||||
RX UART RX pin
|
||||
+5VIN Positive supply voltage
|
||||
GND1 Ground
|
||||
SDA I²C data bus
|
||||
SCL I²C clock bus
|
||||
|
||||
A0 Adress Jumper 1
|
||||
A1 Adress Jumper 2
|
||||
============ ===============================================================
|
||||
|
||||
============ ===============================================================
|
||||
I2C Address Jumpers State
|
||||
============ ===============================================================
|
||||
0x18 A0 Short, A1 Short
|
||||
0x19 A0 Open, A1 Short
|
||||
0x1A A0 Short, A1 Open
|
||||
0x1B A0 Open, A1 Open
|
||||
============ ===============================================================
|
||||
|
||||
.. figure:: images/gdk101.jpg
|
||||
:align: center
|
||||
:width: 50.0%
|
||||
|
||||
GDK101 Gamma Radiation Sensor Module.
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
gdk101:
|
||||
i2c_id: bus_a
|
||||
address: 0x18
|
||||
update_interval: 10s
|
||||
|
||||
- **address** (*Optional*, int): Manually specify the I²C address of
|
||||
the sensor. Defaults to ``0x18`` (``A0`` and ``A1`` shorted).
|
||||
The address is made up using the state of ``A0`` as bit 1 and the state of ``A1`` as bit 2, so a total of four addresses is possible.
|
||||
- **update_interval** (*Optional*, int): Manually defined update iterval of sensor. Default to 60s.
|
||||
- **i2c_id** (*Optional*, string): Optional name of the bus.
|
||||
|
||||
Sensor
|
||||
------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sensor:
|
||||
- platform: gdk101
|
||||
radiation_dose_per_1m:
|
||||
name: "GDK101 Radiation Dose @ 1 min"
|
||||
radiation_dose_per_10m:
|
||||
name: "GDK101 Radiation Dose @ 10 min"
|
||||
status:
|
||||
name: "GDK101 Status"
|
||||
version:
|
||||
name: "GDK101 FW Version"
|
||||
measurement_duration:
|
||||
name: "GDK101 Measuring Time"
|
||||
|
||||
A sensor platform to radiation data
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **radiation_dose_per_1m** (**Required**): Radiation average dose per 1 minute.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
- **radiation_dose_per_10m** (**Required**): Radiation average dose per 10 minutes.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
- **version** (**Required**): Fimware version of the module.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
- **status** (*Optional*): Sensor status.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
- **measurement_duration** (*Optional*): Total time of measurement.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
Binary Sensor
|
||||
-------------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
binary_sensor:
|
||||
- platform: gdk101
|
||||
vibrations:
|
||||
name: "GDK101 Vibrations"
|
||||
|
||||
Binary sensor that indicates if measurement was disturbed by vibrations.
|
||||
|
||||
Configuration variables:
|
||||
|
||||
- **vibrations** (**Required**): Vibration status.
|
||||
All options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :apiref:`gdk101/gdk101.h`
|
||||
- `Data Sheet <http://allsmartlab.com/eng/wp-content/uploads/sites/2/2017/01/GDK101datasheet_v1.6.pdf>`__
|
||||
- `Application Notes <https://merona.blob.core.windows.net/radonftlab-web/GDK101.zip>`__
|
||||
- `Arduino Sensors for Everyone blog post <https://arduino.steamedu123.com/entry/GDK101-Radiation-Sensor>`__
|
||||
- :ghedit:`Edit`
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 68 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 132 KiB |
BIN
components/sensor/images/gdk101.jpg
Normal file
BIN
components/sensor/images/gdk101.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 240 KiB |
BIN
components/sensor/images/ina228-full.jpg
Normal file
BIN
components/sensor/images/ina228-full.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 102 KiB |
BIN
components/sensor/images/ltr303-full.jpg
Normal file
BIN
components/sensor/images/ltr303-full.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
components/sensor/images/ltr303-spectral.png
Normal file
BIN
components/sensor/images/ltr303-spectral.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
BIN
components/sensor/images/ltr303-ui.png
Normal file
BIN
components/sensor/images/ltr303-ui.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
190
components/sensor/ina2xx.rst
Normal file
190
components/sensor/ina2xx.rst
Normal file
@ -0,0 +1,190 @@
|
||||
INA2xx family of digital power monitors
|
||||
=======================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up INA228, INA229, INA237, INA238, INA239 DC current, power, and charge sensors
|
||||
:image: ina228.jpg
|
||||
:keywords: ina228 ina229 ina237 ina238 ina239
|
||||
|
||||
.. figure:: images/ina228-full.jpg
|
||||
:align: center
|
||||
:width: 50.0%
|
||||
|
||||
INA228 Module with integrated shunt from Adafruit
|
||||
|
||||
Supported devices
|
||||
-----------------
|
||||
The ``ina2xx`` sensor platform allows you to use family of Texas Instruments current and power
|
||||
sensors with ESPHome. Appropriate interface (:ref:`I²C Bus <i2c>` or :ref:`SPI Bus <spi>`) is
|
||||
requred to be set up in your configuration for this sensor to work.
|
||||
|
||||
|
||||
|
||||
========================================================== ========== ==========================================================
|
||||
Product Protocol Description
|
||||
========================================================== ========== ==========================================================
|
||||
`INA228 <http://www.ti.com/lit/ds/symlink/ina228.pdf>`__ I²C 85-V, 20-Bit, Ultra-Precise Power/Energy/Charge Monitor
|
||||
`INA229 <http://www.ti.com/lit/ds/symlink/ina229.pdf>`__ SPI 85-V, 20-Bit, Ultra-Precise Power/Energy/Charge Monitor
|
||||
`INA238 <http://www.ti.com/lit/ds/symlink/ina238.pdf>`__ I²C 85-V, 16-Bit, High-Precision Power Monitor
|
||||
`INA239 <http://www.ti.com/lit/ds/symlink/ina239.pdf>`__ SPI 85-V, 16-Bit, High-Precision Power Monitor
|
||||
`INA237 <http://www.ti.com/lit/ds/symlink/ina237.pdf>`__ I²C 85-V, 16-Bit, Precision Power Monitor
|
||||
========================================================== ========== ==========================================================
|
||||
|
||||
All devices can measure a selectable full-scale differential input of ±163.84 mV
|
||||
or ±40.96 mV across the shunt with common-mode voltage support from –0.3 V to +85 V.
|
||||
|
||||
INA228 and INA229 are the most comprehensive devices of the family with extra features: 20-bit ADC resolution,
|
||||
energy and charge accumulation, and capability to utilize the temperature measurement to compensate
|
||||
for shunt resistor temperature variance.
|
||||
|
||||
Over I²C
|
||||
--------
|
||||
Use ``ina2xx_i2c`` component to connect INA228, INA237, or INA238 device over :ref:`I²C <i2c>` bus.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry for I²C
|
||||
sensor:
|
||||
- platform: ina2xx_i2c
|
||||
id: my_charge_sensor
|
||||
model: INA228
|
||||
address: 0x40
|
||||
shunt_resistance: 0.010 ohm
|
||||
max_current: 10 A
|
||||
adc_range: 0
|
||||
update_interval: 60s
|
||||
current: "INA228 Current"
|
||||
bus_voltage: "INA228 Bus Voltage"
|
||||
charge: "INA228 Charge"
|
||||
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **model** (**Required**, string): The model of the INA2xx sensor. Options are ``INA228``, ``INA237``, ``INA238``.
|
||||
- **address** (*Optional*, int): Manually specify the I²C address of the sensor. Defaults to ``0x40``.
|
||||
- **shunt_resistance** (**Required**, float): The value of the shunt resistor used for current calculation. No default value.
|
||||
- **max_current** (**Required**, float): The maximum current you are expecting. Component will use it to
|
||||
calibrate the sensor. No default value.
|
||||
- **adc_range** (*Optional*, ``0`` or ``1``): Selects the range for differential input across shunt
|
||||
resistor. ``0`` for ±163.84 mV, ``1`` for ±40.96 mV range. Defaults to ``0``.
|
||||
- **adc_time** (*Optional*, :ref:`config-time`): The time in microseconds to perform a single ADC conversion.
|
||||
Defaults to ``4120 us``. Valid values are ``50 us``, ``84 us``, ``150 us``, ``280 us``, ``540 us``,
|
||||
``1052 us``, ``2074 us``, ``4120 us``.
|
||||
|
||||
Instead of one time for all ADC measurements, separate configuration of conversion times for shunt voltage,
|
||||
bus voltage, and temperature measurements possible. Options are the same as for ``adc_time``.
|
||||
|
||||
- **bus_voltage** (*Optional*, :ref:`config-time`): Conversion time for bus voltage measurement.
|
||||
- **shunt_voltage** (*Optional*, :ref:`config-time`): Conversion time for shunt voltage measurement.
|
||||
- **temperature** (*Optional*, :ref:`config-time`): Conversion time for temperature measurement.
|
||||
|
||||
- **adc_averaging** (*Optional*, integer): Selects ADC sample averaging count. Defaults to ``128``.
|
||||
Valid values are ``1``, ``4``, ``16``, ``64``, ``128``, ``256``, ``512``, ``1024``.
|
||||
- **temperature_coefficient** (*Optional*, integer from ``0`` to ``16383``): Temperature coefficient (ppm/°C) of the
|
||||
shunt for temperature compensation correction. Only applicable to INA228 and INA229 devices. Zero value means
|
||||
no compensation is done. Defaults to ``0``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the sensor. Defaults to ``60s``.
|
||||
- All other options from :ref:`Sensor <config-sensor>` and :ref:`I²C device <i2c>`.
|
||||
|
||||
|
||||
Over SPI
|
||||
--------
|
||||
|
||||
Use ``ina2xx_spi`` component to connect INA229 or INA239 device over :ref:`SPI <spi>` bus.
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry for SPI
|
||||
sensor:
|
||||
- platform: ina2xx_spi
|
||||
cs_pin: GPIOXX
|
||||
model: INA239
|
||||
shunt_resistance: 0.001130 ohm
|
||||
max_current: 40 A
|
||||
adc_range: 0
|
||||
temperature_coefficient: 50
|
||||
current: "INA239 Current"
|
||||
power: "INA239 Power"
|
||||
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **model** (**Required**, string): The model of the INA2xx sensor. Options are ``INA229``, ``INA239``.
|
||||
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The Chip Select (CS) pin.
|
||||
- **shunt_resistance** (**Required**, float): The value of the shunt resistor used for current calculation. No default value.
|
||||
- **max_current** (**Required**, float): The maximum current you are expecting. Component will use it to
|
||||
calibrate the sensor. No default value.
|
||||
- **adc_range** (*Optional*, ``0`` or ``1``): Selects the range for differential input across shunt
|
||||
resistor. ``0`` for ±163.84 mV, ``1`` for ±40.96 mV range. Defaults to ``0``.
|
||||
- **adc_time** (*Optional*, :ref:`config-time`): The time in microseconds to perform a single ADC conversion.
|
||||
Defaults to ``4120 us``. Valid values are ``50 us``, ``84 us``, ``150 us``, ``280 us``, ``540 us``,
|
||||
``1052 us``, ``2074 us``, ``4120 us``.
|
||||
|
||||
Instead of one time for all ADC measurements, separate configuration of conversion times for shunt voltage,
|
||||
bus voltage, and temperature measurements possible. Options are the same as for ``adc_time``.
|
||||
|
||||
- **bus_voltage** (*Optional*, :ref:`config-time`): Conversion time for bus voltage measurement.
|
||||
- **shunt_voltage** (*Optional*, :ref:`config-time`): Conversion time for shunt voltage measurement.
|
||||
- **temperature** (*Optional*, :ref:`config-time`): Conversion time for temperature measurement.
|
||||
|
||||
- **adc_averaging** (*Optional*, integer): Selects ADC sample averaging count. Defaults to ``128``.
|
||||
Valid values are ``1``, ``4``, ``16``, ``64``, ``128``, ``256``, ``512``, ``1024``.
|
||||
- **temperature_coefficient** (*Optional*, integer from ``0`` to ``16383``): Temperature coefficient (ppm/°C) of the
|
||||
shunt for temperature compensation correction. Only applicable to INA228 and INA229 devices. Zero value means
|
||||
no compensation is done. Defaults to ``0``.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the sensor. Defaults to ``60s``.
|
||||
- All other options from :ref:`Sensor <config-sensor>` and :ref:`SPI device <spi>`.
|
||||
|
||||
|
||||
Sensors
|
||||
-------
|
||||
The component offers nine sensors. You can configure all or any subset of the sensors. Each configured sensor
|
||||
is reported separately on each update_interval. The ``name`` option is required for each sensor configured;
|
||||
all other options from :ref:`Sensor <config-sensor>` are also supported. Shorthand notation can be used for the sensors like this:
|
||||
``current: "Current"``.
|
||||
|
||||
- **current** (*Optional*): Calculated current output, A
|
||||
- **power** (*Optional*): Calculated power output, always positive, W
|
||||
- **shunt_voltage** (*Optional*): Differential voltage measured across the shunt, mV
|
||||
- **bus_voltage** (*Optional*): Bus voltage output, V
|
||||
- **temperature** (*Optional*): Internal die temperature measurement, °C
|
||||
- **energy** (*Optional*): Calculated energy output, Wh (*INA228/229 only*)
|
||||
- **energy_joules** (*Optional*): Calculated energy output, Joules (*INA228/229 only*)
|
||||
- **charge** (*Optional*): Calculated charge output, Ah (*INA228/229 only*)
|
||||
- **charge_coulombs** (*Optional*): Calculated charge output, Coulombs (*INA228/229 only*)
|
||||
|
||||
Lambda calls
|
||||
------------
|
||||
|
||||
The component exposes one function to reset INA228/INA229 energy and charge accumulators.
|
||||
|
||||
- ``reset_energy_counters()``
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
// Within lambda, reset counters.
|
||||
id(my_charge_sensor).reset_energy_counters();
|
||||
|
||||
To simplify the use of this function, you can use the following example to add a button to reset the counters.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
button:
|
||||
- platform: template
|
||||
name: "Reset counters"
|
||||
on_press:
|
||||
- lambda: "id(my_change_sensor).reset_energy_counters();"
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`ina219`
|
||||
- :doc:`ina226`
|
||||
- :doc:`ina3221`
|
||||
- :apiref:`ina2xx_base/ina2xx_base.h`
|
||||
- :ghedit:`Edit`
|
||||
@ -73,6 +73,7 @@ Configuration variables:
|
||||
See https://developers.home-assistant.io/docs/core/entity/#generic-properties
|
||||
for a list of available options.
|
||||
Set to ``""`` to remove the default entity category.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
Automations:
|
||||
|
||||
@ -644,7 +645,7 @@ with ``x``.
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: dallas
|
||||
- platform: dht
|
||||
# ...
|
||||
on_value:
|
||||
then:
|
||||
@ -672,7 +673,7 @@ So for example ``above: 5`` with no below would mean the range from 5 to positiv
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: dallas
|
||||
- platform: dht
|
||||
# ...
|
||||
on_value_range:
|
||||
- below: 5.0
|
||||
@ -704,7 +705,7 @@ trigger with ``x``.
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: dallas
|
||||
- platform: dht
|
||||
# ...
|
||||
on_raw_value:
|
||||
then:
|
||||
|
||||
186
components/sensor/ltr_als_ps.rst
Normal file
186
components/sensor/ltr_als_ps.rst
Normal file
@ -0,0 +1,186 @@
|
||||
Lite-On Ambient Light & Proximity Sensors
|
||||
=========================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up LTR303, LTR329, LTR553, LTR556, LTR559, LTR659 ambient light sensors/proximity sensors with ESPHome.
|
||||
:image: ltr303.jpg
|
||||
:keywords: LTR-329, LTR-303, LTR-553, LTR-556, LTR-559, LTR-659
|
||||
|
||||
|
||||
.. figure:: images/ltr303-full.jpg
|
||||
:align: center
|
||||
:width: 90.0%
|
||||
|
||||
LTR-329 and LTR-303 Ambient Light Sensors.
|
||||
|
||||
.. figure:: images/ltr303-ui.png
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
LTR-303 Sensor in Home Assistant UI.
|
||||
|
||||
The ``ltr_als_ps`` sensor platform allows you to use a range of LiteOn ambient light and proximity sensors
|
||||
with ESPHome. The :ref:`I²C Bus <i2c>` is required to be set up in your configuration for this sensor to work.
|
||||
|
||||
The family of sensors includes:
|
||||
|
||||
- Ambient Light Sensors **LTR-303ALS** and **LTR-329ALS**
|
||||
- Integrated Ambient Light and Proximity Sensors **LTR-553ALS**, **LTR-556ALS**, **LTR-559ALS**
|
||||
- Proximity Sensor **LTR-659ALS** (with PS gain control)
|
||||
|
||||
The sensors are very similar and share the same datasheet. First two have default I²C address ``0x29`` and the rest
|
||||
have default I²C address ``0x23``. The sensors are available on breakout boards from a number of vendors, for
|
||||
example `Adafruit`_ or `Pimoroni`_.
|
||||
|
||||
Proximity sensors are the same sort of sensors that you find in phones and tablets to disable the screen when you hold
|
||||
the device up to your ear. They might be useful for automated turning on or off of displays and control panels. An
|
||||
example is the CoreS3 board from M5Stack that has an LTR-559ALS sensor integrated just under the screen.
|
||||
|
||||
.. _Adafruit: http://www.adafruit.com/products/5610
|
||||
.. _Pimoroni: https://shop.pimoroni.com/products/ltr-559-light-proximity-sensor-breakout
|
||||
|
||||
Ambient light sensing
|
||||
---------------------
|
||||
|
||||
The sensor platform provides a linear response over a wide dynamic range from 0.01 lux to 64k lux and is well suited
|
||||
to applications under high ambient brightness. There are altogether six gain settings (1X, 2X, 4X, 8X, 48X and 96X)
|
||||
available for user to configure. Use higher gain for dimmer areas.
|
||||
|
||||
The devices consist of two photodiodes: The *CH0* diode is sensitive to both visible and infrared light and
|
||||
the *CH1* diode is sensitive only to infrared light.
|
||||
|
||||
.. figure:: images/ltr303-spectral.png
|
||||
:align: center
|
||||
:width: 100.0%
|
||||
|
||||
CH0 and CH1 typical spectral response
|
||||
|
||||
Ambient light illuminance calculation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Excerpt from the datasheet:
|
||||
|
||||
.. code-block::
|
||||
|
||||
RATIO = CH1/(CH0+CH1)
|
||||
IF (RATIO < 0.45)
|
||||
ALS_LUX = (1.7743 * CH0 + 1.1059 * CH1) / ALS_GAIN / ALS_INT
|
||||
ELSEIF (RATIO < 0.64 && RATIO >= 0.45)
|
||||
ALS_LUX = (4.2785 * CH0 – 1.9548 * CH1) / ALS_GAIN / ALS_INT
|
||||
ELSEIF (RATIO < 0.85 && RATIO >= 0.64)
|
||||
ALS_LUX = (0.5926 * CH0 + 0.1185 * CH1) / ALS_GAIN / ALS_INT
|
||||
ELSE
|
||||
ALS_LUX = 0
|
||||
END
|
||||
|
||||
|
||||
where:
|
||||
|
||||
- ``CH0`` and ``CH1`` are the sensor values (measurement counts) for Visible + IR (Ch0) and IR only (Ch1) sensors respectively.
|
||||
- ``ALS_GAIN`` is the gain multiplier
|
||||
- ``ALS_INT`` is the integration time in ms/100
|
||||
|
||||
|
||||
ALS Gain levels
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
The table lists gain values and corresponding illuminance range:
|
||||
|
||||
========= ================================
|
||||
Gain Illuminance range
|
||||
========= ================================
|
||||
``1X`` 1 lux to 64k lux (default)
|
||||
``2X`` 0.5 lux to 32k lux
|
||||
``4X`` 0.25 lux to 16k lux
|
||||
``8X`` 0.125 lux to 8k lux
|
||||
``48X`` 0.02 lux to 1.3k lux
|
||||
``96X`` 0.01 lux to 600 lux
|
||||
========= ================================
|
||||
|
||||
|
||||
This Wikipedia `article <https://en.wikipedia.org/wiki/Lux>`__ has a table of some lux values for comparison.
|
||||
|
||||
Proximity sensing
|
||||
-----------------
|
||||
|
||||
The proximity sensor has a built-in emitter and detector. The sensor detects reflected IR light from the emitter and
|
||||
gives a raw count value inversely exponential to the distance. A decrease in the count value means an object is getting
|
||||
further away from the sensor, and vice-versa. Neither of the datasheets provides any information on how to convert
|
||||
the raw count value to distance. The only way to do it is to test the sensor yourself and select the threshold
|
||||
according to your needs and environment. Exact numbers will depend on the type of the object, its color and
|
||||
reflectivity.
|
||||
|
||||
|
||||
Example configuration
|
||||
---------------------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: ltr_als_ps
|
||||
address: 0x23
|
||||
update_interval: 60s
|
||||
type: ALS_PS # or ALS or PS
|
||||
ambient_light: "Ambient light"
|
||||
# PS only section
|
||||
ps_cooldown: 5 s
|
||||
ps_high_threshold: 500
|
||||
on_ps_high_threshold:
|
||||
then:
|
||||
- .... # do something - light up the screen for example
|
||||
ps_counts: "Proximity counts"
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **address** (*Optional*, int): Manually specify the I²C address of the sensor. Default is ``0x29``.
|
||||
- **type** (*Optional*, string): The type of the sensor. Valid values are ``ALS_PS`` *(default)* for
|
||||
integrated sensors, ``ALS`` for ambient light only or ``PS`` for proximity only devices.
|
||||
- **auto_mode** (*Optional*, boolean): Automatic gain and integration time selection. Defaults to True.
|
||||
- **gain** (*Optional*, string): The gain the device will use. Higher values are better in low-light conditions.
|
||||
Valid values are ``1X`` *(default)*, ``2X``, ``4X``, ``8X``, ``48X``, ``96X``.
|
||||
- **integration_time** (*Optional*, :ref:`config-time`):
|
||||
The amount of time sensors are exposed. Longer means more accurate values.
|
||||
Valid values are: ``50ms`` *(default)*, ``100ms``, ``150ms``, ``200ms``, ``250ms``, ``300ms``, ``350ms``, ``400ms``.
|
||||
- **glass_attenuation_factor** (*Optional*, float): The attenuation factor of glass if it's behind some glass
|
||||
or plastic facia. Default is ``1.0`` means ``100%`` transmissivity. ``2`` means ``50%`` transmissivity etc.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval for checking the sensors.
|
||||
Defaults to ``60s``.
|
||||
- **ps_cooldown** (*Optional*, :ref:`config-time`): The "cooldown" period after the proximity sensor is triggered.
|
||||
Helps to avoid multiple calls. Defaults to ``5s``.
|
||||
- **ps_gain** (*Optional*, string): The gain the device will use for proximity sensor. Higher values are better in low-light conditions.
|
||||
Valid values are ``16X`` *(default)*, ``32X``, ``64X``. Only for **LTR-659ALS**.
|
||||
- **ps_high_threshold** (*Optional*, int): The threshold for the proximity sensor to trigger on object getting closer.
|
||||
Defaults to ``65535``, which implies it will never be triggered.
|
||||
- **ps_low_threshold** (*Optional*, int): The threshold for the proximity sensor to trigger on object getting further away.
|
||||
Defaults to ``0``, which implies it will never be triggered.
|
||||
- **on_ps_high_threshold** (*Optional*): Actions to perform when the proximity sensor is triggered
|
||||
on object getting closer.
|
||||
- **on_ps_low_threshold** (*Optional*): Actions to perform when the proximity sensor is triggered
|
||||
on object getting further away.
|
||||
|
||||
Sensors
|
||||
^^^^^^^
|
||||
This component offers five sensors for ALS-equipped devices and one sensor for PS-equipped devices.
|
||||
You can configure all or any subset of these sensors. Each configured sensor is reported separately
|
||||
on each ``update_interval``. Each is an ESPHome :ref:`sensor <config-sensor>` and may be configured
|
||||
accordingly; if you don’t need to configure additional :ref:`sensor <config-sensor>` variables, you
|
||||
may simply use the shorthand syntax for the sensor. For example: ``ambient_light: "Ambient light"``
|
||||
|
||||
- **ambient_light** (*Optional*): Illuminance of ambient light, close to human eye spectre, lx.
|
||||
- **infrared_counts** (*Optional*): Sensor counts from the IR-sensitive sensor (*CH1*), counts.
|
||||
- **full_spectrum_counts** (*Optional*): Sensor counts from the sensor sensitive to both visible light and IR (*CH0*), counts.
|
||||
- **actual_gain** (*Optional*): Gain value used to measure data, multiplier. Particularly useful when "auto_mode" is selected.
|
||||
- **actual_integration_time** (*Optional*): Integration time used to measure data, ms. Particularly useful when "auto_mode" is selected.
|
||||
- **ps_counts** (*Optional*) - Raw 11-bit reading from proximity sensor, counts.
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- `LTR-303ALS datasheet <https://github.com/latonita/datasheets-storage/blob/main/sensors/LTR-303ALS-01_DS_V1.pdf>`__
|
||||
- Application note `LTR-303ALS & LTR-329ALS Appendix A <https://github.com/latonita/datasheets-storage/blob/main/sensors/LTR-303%20329_Appendix%20A%20Ver_1.0_22%20Feb%202013.pdf>`__
|
||||
- `LTR-559ALS datasheet <https://github.com/latonita/datasheets-storage/blob/main/sensors/ltr-559als-01_ds_v1.pdf>`__
|
||||
- :apiref:`ltr_als_ps/ltr_als_ps.h`
|
||||
- :ghedit:`Edit`
|
||||
@ -46,7 +46,6 @@ See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`dallas`
|
||||
- :doc:`dht`
|
||||
- :doc:`adc`
|
||||
- :doc:`max6675`
|
||||
|
||||
@ -52,7 +52,6 @@ See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`dallas`
|
||||
- :doc:`dht`
|
||||
- :doc:`adc`
|
||||
- :doc:`max6675`
|
||||
|
||||
@ -61,7 +61,6 @@ See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`dallas`
|
||||
- :doc:`dht`
|
||||
- :doc:`adc`
|
||||
- :doc:`max6675`
|
||||
|
||||
@ -55,7 +55,6 @@ See Also
|
||||
--------
|
||||
|
||||
- :ref:`sensor-filters`
|
||||
- :doc:`dallas`
|
||||
- :doc:`dht`
|
||||
- :doc:`adc`
|
||||
- :doc:`sht3xd`
|
||||
|
||||
@ -68,6 +68,7 @@ Configuration variables:
|
||||
See https://www.home-assistant.io/integrations/switch/#device-class
|
||||
for a list of available options.
|
||||
- If MQTT enabled, All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
.. _switch-toggle_action:
|
||||
|
||||
|
||||
@ -5,9 +5,9 @@ Safe Mode Switch
|
||||
:description: Instructions for setting up switches that can remotely reboot the ESP in ESPHome into safe mode.
|
||||
:image: restart.svg
|
||||
|
||||
The ``safe_mode`` switch allows you to remotely reboot your node into :ref:`Safe Mode <config-ota>`. This is useful in certain situations where a misbehaving component, or low memory state is preventing Over-The-Air updates from completing successfully.
|
||||
The ``safe_mode`` switch allows you to remotely reboot your node into :doc:`/components/safe_mode`. This is useful in certain situations where a misbehaving component, or low memory state is preventing Over-The-Air updates from completing successfully.
|
||||
|
||||
This component requires :ref:`OTA <config-ota>` to be configured.
|
||||
This component requires :doc:`/components/safe_mode` to be configured.
|
||||
|
||||
.. figure:: images/safemode-ui.png
|
||||
:align: center
|
||||
|
||||
@ -190,7 +190,7 @@ The outputs can in turn be used to add PWM-enabled lights like the monochromatic
|
||||
- **inverted** (*Optional*, boolean): If all read and written values
|
||||
should be treated as inverted. Defaults to ``false``.
|
||||
- **mode** (*Optional*, string): A pin mode to set for the pin at. One of ``INPUT``,
|
||||
``INPUT_PULLUP`` or ``OUTPUT``.
|
||||
``INPUT_PULLUP``, ``OUTPUT``, or ``OUTPUT_OPEN_DRAIN``.
|
||||
|
||||
|
||||
And naturally you may use all automation functions with these SX1509 binary_sensors, switches and output (lights).
|
||||
|
||||
@ -50,6 +50,7 @@ Configuration variables:
|
||||
for a list of available options. Set to ``""`` to remove the default entity category.
|
||||
- **mode** (**Required**, string): Defines how the text should be displayed in the frontend.
|
||||
One of ``text`` or ``password``.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
Automations:
|
||||
|
||||
|
||||
@ -27,6 +27,8 @@ via text sensors.
|
||||
name: ESP IP Address 4
|
||||
dns_address:
|
||||
name: ESP DNS Address
|
||||
mac_address:
|
||||
name: ESP MAC Address
|
||||
|
||||
|
||||
Configuration variables:
|
||||
@ -38,6 +40,8 @@ Configuration variables:
|
||||
:ref:`Text Sensor <config-text_sensor>`.
|
||||
- **dns_address** (*Optional*): Expose the DNS Address of the ESP as text sensor.
|
||||
:ref:`Text Sensor <config-text_sensor>`.
|
||||
- **mac_address** (*Optional*): Expose the MAC Address of the ESP as text sensor.
|
||||
:ref:`Text Sensor <config-text_sensor>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
38
components/text_sensor/haier.rst
Normal file
38
components/text_sensor/haier.rst
Normal file
@ -0,0 +1,38 @@
|
||||
Haier Climate Text Sensors
|
||||
==========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up additional Text sensors for Haier climate devices.
|
||||
:image: haier.svg
|
||||
|
||||
Additional sensors for Haier Climate device. **These sensors are supported only by the hOn protocol**.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
text_sensor:
|
||||
- platform: haier
|
||||
haier_id: haier_ac
|
||||
appliance_name:
|
||||
name: Haier appliance name
|
||||
cleaning_status:
|
||||
name: Haier cleaning status
|
||||
protocol_version:
|
||||
name: Haier protocol version
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **haier_id** (**Required**, :ref:`config-id`): The id of haier climate component
|
||||
- **appliance_name** (*Optional*): A text sensor that indicates Haier appliance name.
|
||||
All options from :ref:`Text Sensor <config-text_sensor>`.
|
||||
- **cleaning_status** (*Optional*): A text sensor that indicates cleaning status. Possible values "No cleaning", "Self clean", "56°C Steri-Clean".
|
||||
All options from :ref:`Text Sensor <config-text_sensor>`.
|
||||
- **protocol_version** (*Optional*): A text sensor that indicates Haier protocol version.
|
||||
All options from :ref:`Text Sensor <config-text_sensor>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`Haier Climate </components/climate/haier>`
|
||||
- :ghedit:`Edit`
|
||||
@ -47,6 +47,7 @@ Configuration variables:
|
||||
for a list of available options.
|
||||
Set to ``""`` to remove the default entity category.
|
||||
- If MQTT enabled, All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
- If Webserver enabled, ``web_server_sorting_weight`` can be set. See :ref:`Webserver Entity Sorting <config-webserver-sorting>`.
|
||||
|
||||
Automations:
|
||||
|
||||
|
||||
21
components/time/host.rst
Normal file
21
components/time/host.rst
Normal file
@ -0,0 +1,21 @@
|
||||
Host Time Source
|
||||
================
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
time:
|
||||
- platform: host
|
||||
id: sntp_time
|
||||
timezone: Europe/Sofia
|
||||
|
||||
Configuration variables
|
||||
-----------------------
|
||||
|
||||
All options from :ref:`base_time_config`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/host`
|
||||
- :ghedit:`Edit`
|
||||
@ -9,7 +9,7 @@ cst816 Touch Screen Controller
|
||||
The ``cst816`` touchscreen platform allows using the touch screen controllers based on the CST816 series of chips with ESPHome.
|
||||
The :ref:`I²C <i2c>` is required to be set up in your configuration for this touchscreen to work.
|
||||
|
||||
This controller is used in the Lilygo T-Display S3 AMOLED. The component should work with CST816T, CST816S, CST820 and CST716
|
||||
This controller is used in the Lilygo T-Display S3 AMOLED. The component should work with CST816T, CST816S, CST820, CST826 and CST716
|
||||
controller chips.
|
||||
|
||||
|
||||
|
||||
35
components/touchscreen/sdl.rst
Normal file
35
components/touchscreen/sdl.rst
Normal file
@ -0,0 +1,35 @@
|
||||
SDL2 Touch Screen Emulator
|
||||
==========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up touch screen emulation with the sdl display driver.
|
||||
:keywords: sdl, touchscreen
|
||||
|
||||
.. _sdl_touchscreen:
|
||||
|
||||
The ``sdl`` touchscreen platform allows emulating a touch screen by using the mouse with the ``sdl`` display driver.
|
||||
The ``sdl`` display component must be configured to use this.
|
||||
|
||||
Base Touchscreen Configuration
|
||||
------------------------------
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
touchscreen:
|
||||
platform: sdl
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually set the ID of this touchscreen.
|
||||
|
||||
- All other options from :ref:`Touchscreen <config-touchscreen>`.
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :ref:`SDL display <sdl>`
|
||||
- :apiref:`sdl/sdl_touchscreen.h`
|
||||
- :ghedit:`Edit`
|
||||
77
components/update/http_request.rst
Normal file
77
components/update/http_request.rst
Normal file
@ -0,0 +1,77 @@
|
||||
Managed Updates via HTTP Request
|
||||
================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for using ESPHome's http_request update platform to manage updates on your devices.
|
||||
:image: system-update.svg
|
||||
:keywords: Updates, OTA, ESP32, ESP8266
|
||||
|
||||
This platform allows you to manage the deployment of updates to your ESPHome devices. It works by reading a
|
||||
:ref:`JSON manifest file <update_http_request-manifest_format>` and using it to determine the presence of an update.
|
||||
|
||||
To use it, the following components are required in your device's configuration:
|
||||
|
||||
- :doc:`/components/http_request`
|
||||
- :doc:`/components/ota_http_request`
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
update:
|
||||
- platform: http_request
|
||||
name: Firmware Update
|
||||
source: http://example.com/manifest.json
|
||||
|
||||
.. _update_http_request-configuration_variables:
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **source** (**Required**, string): The URL of the YAML manifest file containing the firmware metadata.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval at which to check for updates. Defaults to 6 hours.
|
||||
- All other options from :ref:`Update <config-update>`.
|
||||
|
||||
.. _update_http_request-manifest_format:
|
||||
|
||||
Update Manifest Format
|
||||
----------------------
|
||||
|
||||
This component expects the `ESP-Web-Tools manifest <https://github.com/esphome/esp-web-tools>`__ with an extension in
|
||||
the ``ota`` block that is structured as follows:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"name": "My ESPHome Project",
|
||||
"version": "2024.6.1",
|
||||
"builds": [
|
||||
{
|
||||
"chipFamily": "ESP32-C3",
|
||||
"ota": {
|
||||
"md5": "1234567890abcdef1234567890abcdef",
|
||||
"path": "/local/esp32c3/firmware.bin",
|
||||
"release_url": "http://example.com/releases/10",
|
||||
"summary": "Another update",
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
While ``release_url`` and ``summary`` are optional, all other fields shown here are required.
|
||||
|
||||
If ``path`` begins with:
|
||||
|
||||
- ``http`` or ``https``: ``path`` is treated as full URL which will be used to obtain the firmware binary.
|
||||
- A forward slash (``/``): ``path`` will be appended to the hostname (an "absolute" path) specified for ``source`` (as above).
|
||||
- Any other character: ``path`` will be appended to ``source`` (as specified above) after trimming the manifest file name.
|
||||
|
||||
Note that there may be multiple ``builds`` specified within a single JSON file.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`http_request`
|
||||
- :doc:`/components/ota_http_request`
|
||||
- :doc:`/components/ota`
|
||||
- :apiref:`update/update_entity.h`
|
||||
- :ghedit:`Edit`
|
||||
45
components/update/index.rst
Normal file
45
components/update/index.rst
Normal file
@ -0,0 +1,45 @@
|
||||
Update Core
|
||||
===========
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for using Update entities to manage updates on your ESPHome devices.
|
||||
:image: system-update.svg
|
||||
:keywords: Updates, OTA, ESP32, ESP8266
|
||||
|
||||
The `update` component allows your ESPHome devices to install updates from a remote source; instead of
|
||||
:doc:`"pushing" an update to your device </components/ota>`, the device can retrieve an update and install it on its own.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
update:
|
||||
- platform: ...
|
||||
|
||||
.. _config-update:
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **name** (*Optional*, string): The name to use for the update component.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- **device_class** (*Optional*, string): The device class for the update entity. See
|
||||
https://www.home-assistant.io/integrations/binary_sensor/#device-class for a list of available options.
|
||||
- **disabled_by_default** (*Optional*, boolean): If true, then this entity should not be added to any client's frontend
|
||||
(usually Home Assistant) without the user manually enabling it (via the Home Assistant UI). Defaults to ``false``.
|
||||
- **entity_category** (*Optional*, string): The category of the update entity. See
|
||||
https://developers.home-assistant.io/docs/core/entity/#generic-properties for a list of available options.
|
||||
- **icon** (*Optional*, icon): The icon to use for the update entity in the frontend.
|
||||
- **internal** (*Optional*, boolean): Mark this component as internal. Internal components will
|
||||
not be exposed to the frontend (like Home Assistant). Specifying an ``id`` without a ``name`` will
|
||||
implicitly set this to true.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
*
|
||||
|
||||
- :ghedit:`Edit`
|
||||
@ -82,6 +82,19 @@ Configuration:
|
||||
- **volume_multiplier** (*Optional*, float): Volume multiplier to apply to the assist pipeline.
|
||||
Must be larger than 0. Defaults to 1 (disabled).
|
||||
|
||||
- **on_timer_started** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a voice assistant
|
||||
timer has started. The timer is available as ``timer`` of type :apistruct:`voice_assistant::Timer`.
|
||||
- **on_timer_finished** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a voice assistant
|
||||
timer has finished. The timer is available as ``timer`` of type :apistruct:`voice_assistant::Timer`.
|
||||
- **on_timer_cancelled** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a voice assistant
|
||||
timer has been cancelled. The timer is available as ``timer`` of type :apistruct:`voice_assistant::Timer`.
|
||||
- **on_timer_updated** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a voice assistant
|
||||
timer has been updated (paused/resumed/duration changed). The timer is available as ``timer`` of type :apistruct:`voice_assistant::Timer`.
|
||||
- **on_timer_tick** (*Optional*, :ref:`Automation <automation>`): An automation to perform when the voice assistant timers
|
||||
tick is triggered.
|
||||
This is called every **1 second** while there are timers on this device.
|
||||
The timers are available as ``timers`` which is a ``std::vector`` (array) of type :apistruct:`voice_assistant::Timer`.
|
||||
|
||||
.. _voice_assistant-actions:
|
||||
|
||||
Voice Assistant Actions
|
||||
|
||||
@ -16,7 +16,6 @@ will take up *a lot* of memory and may decrease stability, especially on ESP8266
|
||||
|
||||
Web server version 1
|
||||
|
||||
|
||||
.. figure:: /components/images/web_server-v2.png
|
||||
:align: center
|
||||
:width: 86.0%
|
||||
@ -24,6 +23,13 @@ will take up *a lot* of memory and may decrease stability, especially on ESP8266
|
||||
Web server version 2
|
||||
|
||||
|
||||
.. figure:: /components/images/web_server-v3.png
|
||||
:align: center
|
||||
:width: 86.0%
|
||||
|
||||
Web server version 3
|
||||
|
||||
|
||||
To navigate to the web server in your browser, either use the IP address of the node or
|
||||
use ``<node_name>.local/`` (note the trailing forward slash) via mDNS.
|
||||
|
||||
@ -136,6 +142,26 @@ V2 embeds the css within the js file so is not required, however you could inclu
|
||||
|
||||
Copy https://oi.esphome.io/v2/www.js to a V2 folder in your yaml folder.
|
||||
|
||||
.. _config-webserver-sorting:
|
||||
|
||||
Entity sorting
|
||||
--------------
|
||||
|
||||
``web_server`` version 3 supports the sorting of the entitys.
|
||||
You can set a ``web_server_sorting_weight`` on each entity.
|
||||
Smaller numbers will be displayed first, defaults to 50.
|
||||
Example ``sensor`` configuration.
|
||||
``My Sensor 2`` is displayed first, then ``My Sensor 1``
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
sensor:
|
||||
- platform: template
|
||||
name: "My Sensor 1"
|
||||
web_server_sorting_weight: 10
|
||||
- platform: template
|
||||
name: "My Sensor 2"
|
||||
web_server_sorting_weight: -1
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
@ -255,6 +255,7 @@ These are advanced settings and you will usually need to consult your enterprise
|
||||
eap:
|
||||
username: bob
|
||||
password: VerySafePassword
|
||||
ttls_phase_2: mschapv2
|
||||
- ssid: EAP-TLS_EnterpriseNetwork
|
||||
eap:
|
||||
identity: bob
|
||||
@ -273,6 +274,8 @@ Configuration variables:
|
||||
- **certificate** (*Optional*, string): Path to a PEM encoded certificate to use for EAP-TLS authentication.
|
||||
- **key** (*Optional*, string): Path to a PEM encoded private key matching ``certificate`` for EAP-TLS authentication.
|
||||
Optionally encrypted with ``password``.
|
||||
- **ttls_phase_2** (*Optional*, string): The Phase 2 Authentication Method for EAP-TTLS.
|
||||
Can be ``pap``, ``eap``, ``mschap``, ``mschapv2`` or ``chap``, defaults to ``mschapv2``.
|
||||
|
||||
.. _wifi-on_connect_disconnect:
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ WireGuard Component
|
||||
|wireguard|_ is an extremely simple yet fast and modern VPN that utilizes
|
||||
state-of-the-art cryptography. This component uses a **custom**
|
||||
implementation not developed by original authors and currently
|
||||
available for ESP32 and ESP8266 platforms *only*.
|
||||
available for ESP32, ESP8266 and BK72xx microcontrollers *only*.
|
||||
|
||||
Please note that *"WireGuard" and the "WireGuard" logo are
|
||||
registered trademarks of Jason A. Donenfeld.* See
|
||||
|
||||
4
conf.py
4
conf.py
@ -67,9 +67,9 @@ author = "ESPHome"
|
||||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
version = "2024.5"
|
||||
version = "2024.6"
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = "2024.5.5"
|
||||
release = "2024.6.0b1"
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
|
||||
@ -349,6 +349,7 @@ All Triggers
|
||||
:ref:`ota.on_state_change <ota-on_state_change>`
|
||||
- :ref:`display.on_page_change <display-on_page_change-trigger>`
|
||||
- :ref:`cover.on_open <cover-on_open_trigger>` / :ref:`cover.on_closed <cover-on_closed_trigger>`
|
||||
- :ref:`safe_mode.on_safe_mode <safe_mode-configuration_variables>`
|
||||
- :ref:`wifi.on_connect / wifi.on_disconnect <wifi-on_connect_disconnect>`
|
||||
|
||||
All Actions
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
Contributors
|
||||
============
|
||||
|
||||
ESPHome is an open-source project, and everybody can contribute to it to make this
|
||||
project awesome. This list contains a list of people who have submitted patches
|
||||
that have made it into the `ESPHome organization's <https://github.com/esphome>`__ repositories.
|
||||
ESPHome is an open-source project of the `Open Home Foundation <https://www.openhomefoundation.org/>`__,
|
||||
and everybody can contribute to it to make this project awesome. This list contains a list of people who have
|
||||
submitted patches that have made it into the `ESPHome organization's <https://github.com/esphome>`__ repositories.
|
||||
|
||||
ESPHome is lead by `Jesse Hills (@jesserockz) <https://github.com/jesserockz>`__,
|
||||
ESPHome is led by `Jesse Hills (@jesserockz) <https://github.com/jesserockz>`__,
|
||||
who is funded to work on ESPHome full-time by `Nabu Casa <https://www.nabucasa.com>`__.
|
||||
To help fund development of ESPHome, subscribe to `Home Assistant Cloud by Nabu Casa <https://www.nabucasa.com>`__.
|
||||
|
||||
@ -173,7 +173,6 @@ Contributors
|
||||
- `Ben Kristinsson (@benediktkr) <https://github.com/benediktkr>`__
|
||||
- `Ben Hoff (@benhoff) <https://github.com/benhoff>`__
|
||||
- `Benoît Leforestier (@Benichou34) <https://github.com/Benichou34>`__
|
||||
- `Benjamin Aigner (@benjaminaigner) <https://github.com/benjaminaigner>`__
|
||||
- `benniju (@benniju) <https://github.com/benniju>`__
|
||||
- `Benno Pütz (@bennop) <https://github.com/bennop>`__
|
||||
- `Benny H (@benny-aus) <https://github.com/benny-aus>`__
|
||||
@ -330,6 +329,7 @@ Contributors
|
||||
- `Dan C Williams (@dancwilliams) <https://github.com/dancwilliams>`__
|
||||
- `Daniel Bjørnbakk (@danibjor) <https://github.com/danibjor>`__
|
||||
- `Daniel Baulig (@DanielBaulig) <https://github.com/DanielBaulig>`__
|
||||
- `Daniel D'Abate (@danieldabate) <https://github.com/danieldabate>`__
|
||||
- `danielionutmuresan (@danielionutmuresan) <https://github.com/danielionutmuresan>`__
|
||||
- `Daniel Kent (@danielkent-net) <https://github.com/danielkent-net>`__
|
||||
- `Daniel Kucera (@danielkucera) <https://github.com/danielkucera>`__
|
||||
@ -472,7 +472,6 @@ Contributors
|
||||
- `Josh Gwosdz (@erdii) <https://github.com/erdii>`__
|
||||
- `Eric Coffman (@ericbrian) <https://github.com/ericbrian>`__
|
||||
- `Eric Hiller (@erichiller) <https://github.com/erichiller>`__
|
||||
- `Ernst Klamer (@Ernst79) <https://github.com/Ernst79>`__
|
||||
- `Eduardo Roldan (@eroldan) <https://github.com/eroldan>`__
|
||||
- `ervede (@ervede) <https://github.com/ervede>`__
|
||||
- `escoand (@escoand) <https://github.com/escoand>`__
|
||||
@ -799,6 +798,7 @@ Contributors
|
||||
- `85368.MB (@M4dMikel) <https://github.com/M4dMikel>`__
|
||||
- `maaadc (@maaadc) <https://github.com/maaadc>`__
|
||||
- `Marc-Antoine Courteau (@macourteau) <https://github.com/macourteau>`__
|
||||
- `Madelena Mak (@Madelena) <https://github.com/Madelena>`__
|
||||
- `Matthias Diro (@madias123) <https://github.com/madias123>`__
|
||||
- `Massimiliano Ravelli (@madron) <https://github.com/madron>`__
|
||||
- `Alexandre-Jacques St-Jacques (@Maelstrom96) <https://github.com/Maelstrom96>`__
|
||||
@ -1374,4 +1374,4 @@ Contributors
|
||||
- `Christian Zufferey (@zuzu59) <https://github.com/zuzu59>`__
|
||||
- `Zynth-dev (@Zynth-dev) <https://github.com/Zynth-dev>`__
|
||||
|
||||
*This page was last updated June 5, 2024.*
|
||||
*This page was last updated June 12, 2024.*
|
||||
|
||||
BIN
images/gdk101.jpg
Normal file
BIN
images/gdk101.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
images/ina228.jpg
Normal file
BIN
images/ina228.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
BIN
images/ina2xx.jpg
Normal file
BIN
images/ina2xx.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.0 KiB |
BIN
images/ltr-ps.jpg
Normal file
BIN
images/ltr-ps.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.5 KiB |
BIN
images/ltr303.jpg
Normal file
BIN
images/ltr303.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
images/ltr329.jpg
Normal file
BIN
images/ltr329.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
images/ltr559.jpg
Normal file
BIN
images/ltr559.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.8 KiB |
19
images/one-wire.svg
Normal file
19
images/one-wire.svg
Normal file
@ -0,0 +1,19 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
viewBox="0 0 100 25"
|
||||
version="1.1"
|
||||
id="svg1"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<defs
|
||||
id="defs1" />
|
||||
<path
|
||||
d="M5,0 H95 a5 5 0 0 1 5 5 v15 a5 5 0 0 1 -5 5 H5 a5 5 0 0 1 -5 -5 V5 a5 5 0 0 1 5 -5 Z"
|
||||
style="fill:#000;"
|
||||
id="path1" />
|
||||
<path
|
||||
d="m 5.125,7.95 h 3 V 21 h 5.9 V 3.5 h -8.9 z m 20.049982,7.95 v -4.25 h -7.5 V 15.9 Z M 47.72495,13.575 44.67495,3.5 h -5.425 l -3.225,9.95 -3.05,-9.95 h -6.075 l 5.6,17.5 h 6.325 l 2.975,-9.35 2.825,9.35 h 6.325 l 5.6,-17.5 h -5.6 z m 14.374964,-7.35 c 2.075,0 3.4,-1.25 3.4,-2.975 0,-1.625 -1.325,-2.775 -3.4,-2.775 -2.075,0 -3.4,1.25 -3.4,2.875 0,1.625 1.325,2.875 3.4,2.875 z M 64.924914,21 V 7.325 h -5.65 V 21 Z M 73.899918,7.325 h -5.375 V 21 h 5.65 v -6.075 c 0,-2.175 1.2,-2.95 2.9,-2.95 0.4,0 0.75,0.025 1.25,0.1 v -5 c -1.9,0 -3.425,0.575 -4.425,1.725 z m 21.550007,6.825 c 0,-4.625 -3.475,-7.075 -7.525,-7.075 -4.425,0 -7.75,2.925 -7.75,7.075 0,4.075 3.25,7.1 8.275,7.1 2.725,0 4.65,-0.75 5.975,-2.2 l -2.95,-2.975 c -0.9,0.675 -1.6,1 -2.85,1 -1.4,0 -2.35,-0.55 -2.75,-1.6 h 9.5 c 0.025,-0.4 0.075,-0.925 0.075,-1.325 z m -7.475,-3.225 c 1.15,0 1.975,0.675 2.2,1.825 h -4.4 c 0.225,-1.15 1.025,-1.825 2.2,-1.825 z"
|
||||
id="component-text"
|
||||
style="font-weight:900;font-size:25px;font-family:Montserrat;letter-spacing:1.1px;fill:#fffffc"
|
||||
aria-label="1-Wire" />
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 1.4 KiB |
BIN
images/sdl.png
Normal file
BIN
images/sdl.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
29
index.rst
29
index.rst
@ -197,10 +197,22 @@ Management and Monitoring
|
||||
Debug, components/debug, bug-report.svg, dark-invert
|
||||
Logger, components/logger, file-document-box.svg, dark-invert
|
||||
OTA Updates, components/ota, system-update.svg, dark-invert
|
||||
OTA Updates via HTTP Request, components/ota_http_request, system-update.svg, dark-invert
|
||||
Prometheus, components/prometheus, prometheus.svg
|
||||
Safe Mode, components/safe_mode, restart-alert.svg
|
||||
Web Server, components/web_server, http.svg, dark-invert
|
||||
ESP32 Camera Web Server, components/esp32_camera_web_server, camera.svg, dark-invert
|
||||
|
||||
Update Management
|
||||
-----------------
|
||||
|
||||
Create update entities simplifying management of OTA updates.
|
||||
|
||||
.. imgtable::
|
||||
|
||||
Update Core, components/update/index, system-update.svg, dark-invert
|
||||
Managed Updates, components/update/http_request, system-update.svg, dark-invert
|
||||
|
||||
Hardware Peripheral Interfaces/Busses
|
||||
-------------------------------------
|
||||
|
||||
@ -211,6 +223,7 @@ Hardware Peripheral Interfaces/Busses
|
||||
I²S Audio, components/i2s_audio, i2s_audio.svg
|
||||
SPI Bus, components/spi, spi.svg
|
||||
UART, components/uart, uart.svg
|
||||
1-Wire, components/one_wire, one-wire.svg
|
||||
|
||||
I/O Expanders/Multiplexers
|
||||
--------------------------
|
||||
@ -355,6 +368,11 @@ Electricity
|
||||
HLW8012, components/sensor/hlw8012, hlw8012.svg, Voltage & Current & Power
|
||||
INA219, components/sensor/ina219, ina219.jpg, DC Current
|
||||
INA226, components/sensor/ina226, ina226.jpg, DC Current & Power
|
||||
INA228, components/sensor/ina2xx, ina228.jpg, DC Voltage & Current & Power & Charge
|
||||
INA229, components/sensor/ina2xx, ina2xx.jpg, DC Voltage & Current & Power & Charge
|
||||
INA237, components/sensor/ina2xx, ina2xx.jpg, DC Voltage & Current & Power
|
||||
INA238, components/sensor/ina2xx, ina2xx.jpg, DC Voltage & Current & Power
|
||||
INA239, components/sensor/ina2xx, ina2xx.jpg, DC Voltage & Current & Power
|
||||
INA260, components/sensor/ina260, ina260.jpg, DC Current & Power
|
||||
INA3221, components/sensor/ina3221, ina3221.jpg, 3-Ch DC current
|
||||
Kamstrup KMP, components/sensor/kamstrup_kmp, kamstrup_kmp.jpg, District Heating Meter
|
||||
@ -385,7 +403,7 @@ Environmental
|
||||
BMP280, components/sensor/bmp280, bmp280.jpg, Temperature & Pressure
|
||||
BMP388 and BMP390, components/sensor/bmp3xx, bmp388.jpg, Temperature & Pressure
|
||||
BMP581, components/sensor/bmp581, bmp581.jpg, Temperature & Pressure
|
||||
Dallas DS18B20, components/sensor/dallas, dallas.jpg, Temperature
|
||||
Dallas DS18B20, components/sensor/dallas_temp, dallas.jpg, Temperature
|
||||
DHT, components/sensor/dht, dht.jpg, Temperature & Humidity
|
||||
DHT12, components/sensor/dht12, dht12.jpg, Temperature & Humidity
|
||||
DPS310, components/sensor/dps310, dps310.jpg, Temperature & Pressure
|
||||
@ -439,7 +457,13 @@ Light
|
||||
APDS9960, components/sensor/apds9960, apds9960.jpg, Colour & Gesture
|
||||
AS7341, components/sensor/as7341, as7341.jpg, Spectral Color Sensor
|
||||
BH1750, components/sensor/bh1750, bh1750.jpg, Lux
|
||||
LTR303, components/sensor/ltr_als_ps, ltr303.jpg, Lux
|
||||
LTR329, components/sensor/ltr_als_ps, ltr329.jpg, Lux
|
||||
LTR390, components/sensor/ltr390, ltr390.jpg, Lux & UV
|
||||
LTR553, components/sensor/ltr_als_ps, ltr-ps.jpg, Lux & Proximity
|
||||
LTR556, components/sensor/ltr_als_ps, ltr-ps.jpg, Lux & Proximity
|
||||
LTR559, components/sensor/ltr_als_ps, ltr559.jpg, Lux & Proximity
|
||||
LTR659, components/sensor/ltr_als_ps, ltr-ps.jpg, Proximity
|
||||
MAX44009, components/sensor/max44009, max44009.svg, Lux
|
||||
TCS34725, components/sensor/tcs34725, tcs34725.jpg, Lux & RGB colour
|
||||
TSL2561, components/sensor/tsl2561, tsl2561.jpg, Lux
|
||||
@ -489,6 +513,7 @@ Miscellaneous
|
||||
uFire EC sensor, components/sensor/ufire_ec, ufire_ec.png, EC & Temperature
|
||||
uFire ISE sensor, components/sensor/ufire_ise, ufire_ise.png, pH & Temperature
|
||||
WireGuard, components/wireguard, wireguard_custom_logo.svg
|
||||
GDK101, components/sensor/gdk101, gdk101.jpg, Radiation
|
||||
|
||||
Motion
|
||||
******
|
||||
@ -661,6 +686,7 @@ Light Components
|
||||
.. imgtable::
|
||||
|
||||
Light Core, components/light/index, folder-open.svg, dark-invert
|
||||
Beken SPI, components/light/beken_spi_led_strip, color_lens.svg, dark-invert
|
||||
Binary Light, components/light/binary, lightbulb.svg, dark-invert
|
||||
Cold+Warm White Light, components/light/cwww, brightness-medium.svg, dark-invert
|
||||
Color Temperature Light, components/light/color_temperature, brightness-medium.svg, dark-invert
|
||||
@ -791,6 +817,7 @@ Display Hardware Platforms
|
||||
TM1638, components/display/tm1638, tm1638.jpg
|
||||
TM1651 Battery Display, components/tm1651, tm1651_battery_display.jpg
|
||||
Waveshare E-Paper, components/display/waveshare_epaper, waveshare_epaper.jpg
|
||||
Host SDL2 display, components/display/sdl, sdl.png
|
||||
|
||||
Touchscreen Components
|
||||
----------------------
|
||||
|
||||
Loading…
Reference in New Issue
Block a user