Merge remote-tracking branch 'origin/current' into next
This commit is contained in:
Otto Winter
commit
c8d82f4397
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 = 1.11.1
|
||||
PROJECT_NUMBER = 1.11.2
|
||||
|
||||
# Using the PROJECT_BRIEF tag one can provide an optional one line description
|
||||
# for a project that appears at the top of each page and should give viewer a
|
||||
|
|
|
|||
2
Makefile
2
Makefile
|
|
@ -1,5 +1,5 @@
|
|||
ESPHOME_CORE_PATH = ../esphome-core
|
||||
ESPHOME_CORE_TAG = v1.11.1
|
||||
ESPHOME_CORE_TAG = v1.11.2
|
||||
|
||||
.PHONY: html cleanhtml deploy help webserver Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
1.11.1
|
||||
1.11.2
|
||||
|
|
@ -53,8 +53,9 @@ of time to find+fix some final bugs.
|
|||
|
||||
**How do I migrate from MQTT?**
|
||||
|
||||
First, make sure you run at least Home Assistant 0.85.0 (currently a `beta release <https://www.home-assistant.io/docs/installation/updating/#run-the-beta-version>`__). Then, go through the
|
||||
:ref:`migration guide here <api-mqtt_to_native>`.
|
||||
First, make sure you run at least Home Assistant 0.85.0 (currently a
|
||||
`beta release <https://www.home-assistant.io/docs/installation/updating/#run-the-beta-version>`__).
|
||||
Then, go through the :ref:`migration guide here <api-mqtt_to_native>`.
|
||||
|
||||
Python 3 Compatibility
|
||||
----------------------
|
||||
|
|
|
|||
|
|
@ -75,6 +75,23 @@ I've made that a top priority for the next release, but I've hit some road block
|
|||
prevented it from working in a stable way for this release (and I needed to finally get this darn
|
||||
release out).
|
||||
|
||||
Release 1.11.2 - February 26
|
||||
----------------------------
|
||||
|
||||
- docs: Fix units on the valid frequency values :docspr:`170` by :ghuser:`kwdavidson`
|
||||
- esphome: Allow non-pullup pins for dallas :esphomepr:`456`
|
||||
- core: Turn off light at 0% brightness :corepr:`526`
|
||||
- core: HLW8012 don't count a single pulse as power :corepr:`527`
|
||||
- core: Set initial brightness to 0 when turning light on :corepr:`528`
|
||||
- core: Allow white value of addressable lights to be controlled independently of brightness :corepr:`529`
|
||||
- core: Fix WiFi not connecting to open networks :corepr:`531`
|
||||
- esphome: Remove automatic update check :esphomepr:`457`
|
||||
- esphome: Fix mDNS library added only with OTA :esphomepr:`451`
|
||||
- docs: Merge dallas component :docspr:`179` by :ghuser:`FrengerH`
|
||||
- docs: Correct ultrasonic filter_nan example :docspr:`159` by :ghuser:`apeeters`
|
||||
- docs: Cookbook entry for Display component :docspr:`173` by :ghuser:`ahd71`
|
||||
- core: Fix light partition src offset :corepr:`525`
|
||||
|
||||
Release 1.11.1 - February 23
|
||||
----------------------------
|
||||
|
||||
|
|
@ -131,6 +148,7 @@ Beta Fixes
|
|||
|
||||
All changes
|
||||
-----------
|
||||
|
||||
- core: Attemp to fix the addressable flicker effect :corepr:`392` by :ghuser:`RomRider`
|
||||
- esphome: typing is only required for python < 3.5 :esphomepr:`341` by :ghuser:`dotlambda`
|
||||
- esphome: Fix install pillow in docker image :esphomepr:`338`
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ be travelling a lot (and enjoying my vacation 😎), so don't expect too many aw
|
|||
Pulse Counter for ESP8266, components/sensor/pulse_counter, pulse.svg
|
||||
Remote Transmitter, components/switch/remote_transmitter, remote.svg
|
||||
|
||||
Remote Receiver, components/remote_receiver, remote.svg
|
||||
Remote Receiver, components/binary_sensor/remote_receiver, remote.svg
|
||||
|
||||
New Components
|
||||
**************
|
||||
|
|
@ -52,8 +52,8 @@ New Components
|
|||
measure how much of the time a specific pin is HIGH or LOW. Can for example be used to detect if a status LED
|
||||
on an external device is blinking or permanently on.
|
||||
|
||||
- The new :doc:`remote receiver </components/remote_transmitter>` and
|
||||
:doc:`remote transmitter </components/remote_receiver>` components now allows you to use any 433MHz
|
||||
- The new :doc:`remote receiver </components/binary_sensor/remote_receiver>` and
|
||||
:doc:`remote transmitter </components/switch/remote_transmitter>` components now allows you to use any 433MHz
|
||||
receivers and senders with ESPHome. Currently, you will need to use the ``raw`` data as described in
|
||||
:ref:`this guide <finding_remote_codes>`, but in the future more protocols will be supported out of the box.
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ Breaking Changes
|
|||
- The ``receive_timeout`` option has been removed from the :doc:`i2c component </components/i2c>` as it
|
||||
turns out it didn't actually do anything.
|
||||
|
||||
- The ``ir_transmitter`` component has been renamed to :doc:`remote_transmitter </components/remote_transmitter>`
|
||||
- The ``ir_transmitter`` component has been renamed to :doc:`remote_transmitter </components/switch/remote_transmitter>`
|
||||
as it now works with all kinds of protocols, not just infrared-based ones.
|
||||
|
||||
- The ``pull_mode`` option of the :doc:`Pulse Counter </components/sensor/pulse_counter>` has been removed, please
|
||||
|
|
@ -190,6 +190,7 @@ for using esphomeyaml to create a simple wireless doorbell:
|
|||
|
||||
.. raw:: html
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/xCQoOZNdaGY" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/xCQoOZNdaGY"
|
||||
frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
|
||||
|
||||
.. disqus::
|
||||
|
|
|
|||
|
|
@ -10,10 +10,10 @@ Version 1.8.0
|
|||
|
||||
Waveshare E-Paper, components/display/waveshare_epaper, waveshare_epaper.jpg
|
||||
Nextion, components/display/nextion, nextion.jpg
|
||||
SSD1306, components/display/ssd1306_i2c, ssd1306.jpg
|
||||
SSD1306, components/display/ssd1306, ssd1306.jpg
|
||||
|
||||
MAX7219, components/display/max7219, max7219.jpg
|
||||
LCD Display, components/display/lcd_gpio, lcd.jpg
|
||||
LCD Display, components/display/lcd_display, lcd.jpg
|
||||
RCSwitch Integration, components/switch/remote_transmitter.html#rcswitch-remote-codes, remote.svg
|
||||
|
||||
SPI Bus, components/spi, spi.svg
|
||||
|
|
@ -21,8 +21,8 @@ Version 1.8.0
|
|||
Real Time Clock, components/time, clock-outline.svg
|
||||
|
||||
Uptime Sensor, components/sensor/uptime, timer.svg
|
||||
PN532, components/pn532, pn532.jpg
|
||||
RDM6300, components/rdm6300, rdm6300.jpg
|
||||
PN532, components/binary_sensor/pn532, pn532.jpg
|
||||
RDM6300, components/binary_sensor/rdm6300, rdm6300.jpg
|
||||
|
||||
BLE RSSI, components/sensor/ble_rssi, bluetooth.svg
|
||||
Xiaomi MiFlora, components/sensor/xiaomi_miflora, xiaomi_miflora.jpg
|
||||
|
|
@ -54,7 +54,7 @@ This release mainly focuses on these new features:
|
|||
- Lots of Bug Fixes - Now that most of the hardware has arrived from china, I was able to fix a bunch
|
||||
of bugs with a lot of integrations.
|
||||
- :doc:`Displays! </components/display/index>`
|
||||
- NFC/RFID Readers (:doc:`PN532 </components/pn532>` and :doc:`RDM6300 </components/rdm6300>`)
|
||||
- NFC/RFID Readers (:doc:`PN532 </components/binary_sensor/pn532>` and :doc:`RDM6300 </components/binary_sensor/rdm6300>`)
|
||||
- New :doc:`ESP32 BLE integrations </components/esp32_ble_tracker>` like :doc:`Xiaomi MiFlora </components/sensor/xiaomi_miflora>`
|
||||
- Core Changes like the addition of the :ref:`SPI bus <spi>` and :ref:`UART bus <uart>`
|
||||
- Lots of new :ref:`light effects <light-effects>` and support for cold-white/warm-white lights.
|
||||
|
|
@ -69,18 +69,30 @@ awesome projects ☀️
|
|||
|
||||
Special thanks to all the contributors for this release:
|
||||
|
||||
- esphomeyaml: Add ‘only-generate’ parameter to generate command to only generate the C++ code `#84 <https://github.com/OttoWinter/esphomeyaml/pull/84>`__ by `@apeeters <https://github.com/apeeters>`__
|
||||
- esphomeyaml: Fix esphomeyaml logs for tls enabled mqtt brokers `#118 <https://github.com/OttoWinter/esphomeyaml/pull/118>`__ by `@johnerikhalse <https://github.com/johnerikhalse>`__
|
||||
- esphomelib: Add Samsung IR codes `#141 <https://github.com/OttoWinter/esphomelib/pull/141>`__ by `@escoand <https://github.com/escoand>`__
|
||||
- esphomelib: Add support for SNTP and RTC `#76 <https://github.com/OttoWinter/esphomelib/pull/76>`__ by `@brandond <https://github.com/brandond>`__
|
||||
- esphomelib: Run travis jobs in parallel `#123 <https://github.com/OttoWinter/esphomelib/pull/123>`__ by `@lobradov <https://github.com/lobradov>`__
|
||||
- esphomelib: Fix typo in dallas error message `#125 <https://github.com/OttoWinter/esphomelib/pull/125>`__ by `@janpieper <https://github.com/janpieper>`__
|
||||
- esphomelib: Fix esphomelib examples `#124 <https://github.com/OttoWinter/esphomelib/pull/124>`__ by `@lobradov <https://github.com/lobradov>`__
|
||||
- esphomelib: Fix panic in binary_sensor template `#111 <https://github.com/OttoWinter/esphomelib/pull/111>`__ by `@nunofgs <https://github.com/nunofgs>`__
|
||||
- esphomelib: Add ESP8266 library dependency to Arduino IDE instructions `#99 <https://github.com/OttoWinter/esphomelib/pull/99>`__ by `@per1234 <https://github.com/per1234>`__
|
||||
- esphomelib: Fixing I2C readings `#98 <https://github.com/OttoWinter/esphomelib/pull/98>`__ by `@exxamalte <https://github.com/exxamalte>`__
|
||||
- esphomedocs: Note added about resetting the ESP after serial upload before OTA upload `#14 <https://github.com/OttoWinter/esphomedocs/pull/14>`__ by `@exxamalte <https://github.com/exxamalte>`__
|
||||
- esphomedocs: Add cookbook for dual relay cover `#10 <https://github.com/OttoWinter/esphomedocs/pull/10>`__ by `@aequitas <https://github.com/aequitas>`__
|
||||
- esphomeyaml: Add ‘only-generate’ parameter to generate command to only generate the C++ code
|
||||
`#84 <https://github.com/OttoWinter/esphomeyaml/pull/84>`__ by `@apeeters <https://github.com/apeeters>`__
|
||||
- esphomeyaml: Fix esphomeyaml logs for tls enabled mqtt brokers
|
||||
`#118 <https://github.com/OttoWinter/esphomeyaml/pull/118>`__ by `@johnerikhalse <https://github.com/johnerikhalse>`__
|
||||
- esphomelib: Add Samsung IR codes `#141 <https://github.com/OttoWinter/esphomelib/pull/141>`__
|
||||
by `@escoand <https://github.com/escoand>`__
|
||||
- esphomelib: Add support for SNTP and RTC `#76 <https://github.com/OttoWinter/esphomelib/pull/76>`__
|
||||
by `@brandond <https://github.com/brandond>`__
|
||||
- esphomelib: Run travis jobs in parallel `#123 <https://github.com/OttoWinter/esphomelib/pull/123>`__
|
||||
by `@lobradov <https://github.com/lobradov>`__
|
||||
- esphomelib: Fix typo in dallas error message `#125 <https://github.com/OttoWinter/esphomelib/pull/125>`__
|
||||
by `@janpieper <https://github.com/janpieper>`__
|
||||
- esphomelib: Fix esphomelib examples `#124 <https://github.com/OttoWinter/esphomelib/pull/124>`__
|
||||
by `@lobradov <https://github.com/lobradov>`__
|
||||
- esphomelib: Fix panic in binary_sensor template `#111 <https://github.com/OttoWinter/esphomelib/pull/111>`__
|
||||
by `@nunofgs <https://github.com/nunofgs>`__
|
||||
- esphomelib: Add ESP8266 library dependency to Arduino IDE instructions `#99 <https://github.com/OttoWinter/esphomelib/pull/99>`__
|
||||
by `@per1234 <https://github.com/per1234>`__
|
||||
- esphomelib: Fixing I2C readings `#98 <https://github.com/OttoWinter/esphomelib/pull/98>`__
|
||||
by `@exxamalte <https://github.com/exxamalte>`__
|
||||
- esphomedocs: Note added about resetting the ESP after serial upload before OTA upload
|
||||
`#14 <https://github.com/OttoWinter/esphomedocs/pull/14>`__ by `@exxamalte <https://github.com/exxamalte>`__
|
||||
- esphomedocs: Add cookbook for dual relay cover `#10 <https://github.com/OttoWinter/esphomedocs/pull/10>`__
|
||||
by `@aequitas <https://github.com/aequitas>`__
|
||||
|
||||
And in some more personal news, you might have noticed that I was not very active in online communications (github, discord, ...)
|
||||
and that's partly been due to me concentrating on other stuff (university applications, work and
|
||||
|
|
@ -94,7 +106,8 @@ Other notable changes
|
|||
|
||||
- Fixed certain occasions where esphomeyaml could run into recursive dependencies
|
||||
- Fixed i2c scans not showing up via MQTT
|
||||
- Improved build times by about 60%. Now, the build time should depend on the amount of components you're using, not the total esphomelib code base size.
|
||||
- Improved build times by about 60%. Now, the build time should depend on the amount of components you're using,
|
||||
not the total esphomelib code base size.
|
||||
- Fixed ESP32 Touch setup mode
|
||||
- Fixed template binary sensors
|
||||
- Added the option to specify ``never`` for ``update_interval`` to never
|
||||
|
|
@ -181,11 +194,15 @@ Changes in 1.8.2
|
|||
- esphomedocs: Typo in display docs `#28 <https://github.com/OttoWinter/esphomedocs/pull/28>`__ by `@yuanl <https://github.com/yuanl>`__
|
||||
- esphomedocs: Typo fix. `#33 <https://github.com/OttoWinter/esphomedocs/pull/33>`__ by `@corbanmailloux <https://github.com/corbanmailloux>`__
|
||||
- esphomelib: Fix typo "noting" `#172 <https://github.com/OttoWinter/esphomelib/pull/172>`__ by `@TheJulianJES <https://github.com/TheJulianJES>`__
|
||||
- esphomedocs: Added docker local USB port mapping `#31 <https://github.com/OttoWinter/esphomedocs/pull/31>`__ by `@ladefoged81 <https://github.com/ladefoged81>`__
|
||||
- esphomedocs: Fixed typo `#30 <https://github.com/OttoWinter/esphomedocs/pull/30>`__ by `@ladefoged81 <https://github.com/ladefoged81>`__
|
||||
- esphomedocs: Add missing (required) name to example. `#29 <https://github.com/OttoWinter/esphomedocs/pull/29>`__ by `@corbanmailloux <https://github.com/corbanmailloux>`__
|
||||
- esphomedocs: Added docker local USB port mapping `#31 <https://github.com/OttoWinter/esphomedocs/pull/31>`__
|
||||
by `@ladefoged81 <https://github.com/ladefoged81>`__
|
||||
- esphomedocs: Fixed typo `#30 <https://github.com/OttoWinter/esphomedocs/pull/30>`__
|
||||
by `@ladefoged81 <https://github.com/ladefoged81>`__
|
||||
- esphomedocs: Add missing (required) name to example. `#29 <https://github.com/OttoWinter/esphomedocs/pull/29>`__
|
||||
by `@corbanmailloux <https://github.com/corbanmailloux>`__
|
||||
- esphomedocs: Add ESP32 BLE workaround docs `#34 <https://github.com/OttoWinter/esphomedocs/pull/34>`__
|
||||
- esphomelib: Apply effect after changing colors `#169 <https://github.com/OttoWinter/esphomelib/pull/169>`__ by `@TheJulianJES <https://github.com/TheJulianJES>`__
|
||||
- esphomelib: Apply effect after changing colors `#169 <https://github.com/OttoWinter/esphomelib/pull/169>`__
|
||||
by `@TheJulianJES <https://github.com/TheJulianJES>`__
|
||||
- esphomelib: Add 64x48 SSD1306 Display `#161 <https://github.com/OttoWinter/esphomelib/pull/161>`__
|
||||
- esphomedocs: Fix output link `#35 <https://github.com/OttoWinter/esphomedocs/pull/35>`__
|
||||
- esphomedocs: Fix pulse counter API typo `#36 <https://github.com/OttoWinter/esphomedocs/pull/36>`__
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Changelog - Version 1.9.0
|
|||
|
||||
esphomeflasher, guides/faq.html#i-can-t-get-flashing-over-usb-to-work, logo.svg
|
||||
Total Daily Energy, components/sensor/total_daily_energy, sigma.svg
|
||||
MY9231/MY9291 LED driver, components/my9231, my9231.svg
|
||||
MY9231/MY9291 LED driver, components/output/my9231, my9231.svg
|
||||
|
||||
|
||||
It's time for another release of esphomelib: 1.9.0. This release is quite different from the last one,
|
||||
|
|
@ -96,7 +96,7 @@ New Features
|
|||
|
||||
.. code-block:: text
|
||||
|
||||
[13:57:33][I][application:092]: You're running esphomelib v1.9.0 compiled on Nov 3 2018, 13:55:11
|
||||
[13:57:33][I][application:092]: You're running esphomelib v1.9.0 compiled on Nov 3 2018, 13:55:11
|
||||
|
||||
- Stack traces in the USB logs are now automatically decoded to make debugging easier
|
||||
(:yamlpr:`214`)
|
||||
|
|
@ -114,7 +114,7 @@ New Features
|
|||
- Added :ref:`binary_sensor-on_multi_click` trigger to distinguish between double, long, and single clicks.
|
||||
(:libpr:`262`, :docspr:`77`, :yamlpr:`226`)
|
||||
|
||||
- Added an :ref:`pn532-on_tag` to :doc:`PN532 NFC Readers </components/pn532>` so that automations
|
||||
- Added an :ref:`pn532-on_tag` to :doc:`PN532 NFC Readers </components/binary_sensor/pn532>` so that automations
|
||||
can directly use the NFC tag ID
|
||||
(:libpr:`194`, :yamlpr:`189`, :docspr:`57`)
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ New Features
|
|||
- You now have to option to have a different log level for log messages sent over MQTT (:ref:`docs <mqtt-message>`,
|
||||
:yamlpr:`167`, :docspr:`51`)
|
||||
|
||||
- Added a color correction option to :doc:`FastLED addressable lights </components/light/fastled_clockless>`
|
||||
- Added a color correction option to :doc:`FastLED addressable lights </components/light/fastled>`
|
||||
(:libpr:`234`, :yamlpr:`200`, :docspr:`64`)
|
||||
|
||||
- Added a ``clean`` command to esphomeyaml to fix some occasional build errors
|
||||
|
|
|
|||
|
|
@ -1,56 +0,0 @@
|
|||
ADS1115 Hub
|
||||
===========
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up ADS1115 analog voltage multiplexer hubs.
|
||||
:image: ads1115.jpg
|
||||
:keywords: ADS1115
|
||||
|
||||
The ``ads1115`` domain creates a global hub so that you can later create
|
||||
individual sensors using the :doc:`ADS1115 Sensor Platform </components/sensor/ads1115>`.
|
||||
To use this hub, first setup the :ref:`I²C Bus <i2c>` and connect the sensor to the pins specified there.
|
||||
|
||||
.. figure:: sensor/images/ads1115-full.jpg
|
||||
:align: center
|
||||
:width: 50.0%
|
||||
|
||||
ADS1115 16-Bit ADC.
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/1085
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
ads1115:
|
||||
- address: 0x48
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **address** (**Required**, int): The i²c address of the sensor.
|
||||
See :ref:`I²C Addresses <ads1115_i2c_addresses>` for more information.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this ADS1115 Hub. Use this if you
|
||||
want to use multiple ADS1115 hubs at once.
|
||||
|
||||
.. _ads1115_i2c_addresses:
|
||||
|
||||
I²C Addresses
|
||||
-------------
|
||||
|
||||
In order to allow multiple sensors to be connected to the same i²c bus,
|
||||
the creators of this sensor hardware have included some options to
|
||||
change the i²c address.
|
||||
|
||||
- If the address pin is pulled to GND, the address is ``0x48`` (Default).
|
||||
- If the address pin is pulled to VCC, the address is ``0x49``.
|
||||
- If the address pin is tied to SDA, the address is ``0x4a``.
|
||||
- If the address pin is tied to SCL, the address is ``0x4B``.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`sensor/ads1115`
|
||||
- `i2cdevlib <https://github.com/jrowberg/i2cdevlib>`__ by `Jeff Rowberg <https://github.com/jrowberg>`__
|
||||
- :apiref:`sensor/ads1115_component.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -48,7 +48,7 @@ If you've previously used ESPHome with Home Assistant via MQTT and have enabled
|
|||
the upgrade process is unfortunately not just swapping out the ``mqtt`` for ``api`` in your configuration:
|
||||
Home Assistant's `entity registry <https://developers.home-assistant.io/docs/en/entity_registry_index.html>`__ complicates
|
||||
things a bit. If you don't follow these steps, all your new native API entities will have a trailing
|
||||
`_2` at the end of the entity ID.
|
||||
``_2`` at the end of the entity ID.
|
||||
|
||||
You can repeat these steps for all your nodes, or convert them over to the new native API one by one.
|
||||
|
||||
|
|
@ -70,32 +70,32 @@ You can repeat these steps for all your nodes, or convert them over to the new n
|
|||
|
||||
.. raw:: html
|
||||
|
||||
<textarea rows="10" cols="50" id="entity-reg-converter"></textarea>
|
||||
<button type="button" id="entity-reg-button">Convert Entity Registry</button>
|
||||
<script>
|
||||
var elem = document.getElementById("entity-reg-converter");
|
||||
elem.addEventListener("click", function() {
|
||||
elem.focus();
|
||||
elem.select();
|
||||
});
|
||||
document.getElementById("entity-reg-button").addEventListener("click", function() {
|
||||
try {
|
||||
data = JSON.parse(elem.value);
|
||||
} catch(e) {
|
||||
alert(e);
|
||||
}
|
||||
var entities = data.data.entities;
|
||||
var newEntities = [];
|
||||
for (var i = 0; i < entities.length; i++) {
|
||||
var entity = entities[i];
|
||||
if (entity.platform != "mqtt") {
|
||||
newEntities.push(entity);
|
||||
<textarea rows="10" cols="50" id="entity-reg-converter"></textarea>
|
||||
<button type="button" id="entity-reg-button">Convert Entity Registry</button>
|
||||
<script>
|
||||
var elem = document.getElementById("entity-reg-converter");
|
||||
elem.addEventListener("click", function() {
|
||||
elem.focus();
|
||||
elem.select();
|
||||
});
|
||||
document.getElementById("entity-reg-button").addEventListener("click", function() {
|
||||
try {
|
||||
data = JSON.parse(elem.value);
|
||||
} catch(e) {
|
||||
alert(e);
|
||||
}
|
||||
}
|
||||
data.data.entities = newEntities;
|
||||
elem.value = JSON.stringify(data, null, 4);
|
||||
});
|
||||
</script>
|
||||
var entities = data.data.entities;
|
||||
var newEntities = [];
|
||||
for (var i = 0; i < entities.length; i++) {
|
||||
var entity = entities[i];
|
||||
if (entity.platform != "mqtt") {
|
||||
newEntities.push(entity);
|
||||
}
|
||||
}
|
||||
data.data.entities = newEntities;
|
||||
elem.value = JSON.stringify(data, null, 4);
|
||||
});
|
||||
</script>
|
||||
|
||||
4. Stop Home Assistant - this is necessary for the entity registry changes not to become overriden.
|
||||
|
||||
|
|
@ -108,8 +108,8 @@ You can repeat these steps for all your nodes, or convert them over to the new n
|
|||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
api:
|
||||
# Example configuration entry
|
||||
api:
|
||||
|
||||
8. In Home Assistant, go to "Configuration" -> "Integrations" - if you've set up the ``discovery:`` component,
|
||||
you'll already see the ESP as a suggestion to be configured. But if you're having issues with that, you can
|
||||
|
|
|
|||
|
|
@ -1,14 +1,70 @@
|
|||
ESP32 Touch Pad Binary Sensor
|
||||
=============================
|
||||
ESP32 Touch Pad
|
||||
===============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the touch pad on the ESP32.
|
||||
:image: touch.png
|
||||
|
||||
.. _esp32-touch-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``esp32_touch`` component creates a global hub for detecting touches on
|
||||
the eight touch pads of the ESP32 as :ref:`binary senors <esp32-touch-binary-sensor>`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_touch:
|
||||
setup_mode: False
|
||||
|
||||
binary_sensor:
|
||||
- platform: esp32_touch
|
||||
name: "ESP32 Touch Pad GPIO27"
|
||||
pin: GPIO27
|
||||
threshold: 1000
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **setup_mode** (*Optional*, boolean): Whether debug messages with the touch pad value should
|
||||
be displayed in the logs. Useful for finding out suitable thresholds for the binary sensors, but
|
||||
spam the logs. See :ref:`setting up touch pads <esp32-touch-binary-sensor>`
|
||||
for more information. Defaults to false.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for code generation.
|
||||
|
||||
Advanced options (the defaults are usually quite good, but if you're having accuracy issues, use these):
|
||||
|
||||
- **iir_filter** (*Optional*, :ref:`config-time`): Optionally set up an
|
||||
`Infinite Impulse Response <https://en.wikipedia.org/wiki/Infinite_impulse_response>`__
|
||||
filter should be applied to all touch pads. This can increase the accuracy of the touch pads a lot, but
|
||||
higher values decrease the response time. A good value to start with is ``10ms``. Default is no IIR filter.
|
||||
- **sleep_duration** (*Optional*, :ref:`config-time`): Set a time period
|
||||
denoting the amount of time the touch peripheral should sleep between measurements. This can decrease
|
||||
power usage but make the sensor slower. Default is about 27 milliseconds.
|
||||
- **measurement_duration** (*Optional*, :ref:`config-time`): Set the conversion
|
||||
time for all touch pads. A longer conversion time means that more charge/discharge cycles of the touch pad
|
||||
can be performed, therefore increasing accuracy. Default is about 8ms, the maximum amount.
|
||||
- **low_voltage_reference** (*Optional*): The low voltage reference to use for the charge cycles. See
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``0.5V``, ``0.6V``, ``0.7V``, ``0.8V``. Default is ``0.5V``.
|
||||
- **high_voltage_reference** (*Optional*): The high voltage reference to use for the charge cycles. See
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``2.4V``, ``2.5V``, ``2.6V``, ``2.7V``. Default is ``2.7V``.
|
||||
- **voltage_attenuation** (*Optional*): The voltage attenuation to use for the charge cycles. See
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``1.5V``, ``1V``, ``0.5V``, ``0V``. Default is ``0V``.
|
||||
|
||||
.. _esp32-touch-binary-sensor:
|
||||
|
||||
Binary Sensor
|
||||
-------------
|
||||
|
||||
The ``esp32_touch`` binary sensor platform lets you use the touch peripheral of the
|
||||
ESP32 to detect if a certain pin is being "touched".
|
||||
|
||||
First, you need to setup the :doc:`global touch hub </components/esp32_touch>`. Then
|
||||
First, you need to setup the :ref:`global touch hub <esp32-touch-component>`. Then
|
||||
you can add individual touch pads as binary sensors. When a touch is detected on these pins, the binary
|
||||
sensor will report an ``ON`` state. And, of course, if no touch is detected, the binary sensor will report
|
||||
an ``OFF`` state.
|
||||
|
|
@ -29,7 +85,7 @@ an ``OFF`` state.
|
|||
threshold: 1000
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin to detect touch
|
||||
events on.
|
||||
|
|
@ -66,7 +122,7 @@ raw values mean that it is more likely that a touch is happening. For example, v
|
|||
1000 to 1600 usually mean the pad is not being touched, and values in the range of 600 and less
|
||||
mean the pad is probably being touched.
|
||||
|
||||
To find suitable threshold values, first configure the :doc:`ESP32 touch hub </components/esp32_touch>`
|
||||
To find suitable threshold values, first configure the :ref:`ESP32 touch hub <esp32-touch-component>`
|
||||
to output measured values using the ``setup_mode:`` configuration option. Next, add some binary sensors
|
||||
for the touch pads you want to observe. Also put some threshold in the configuration as seen below
|
||||
to make the validator happy, we are going to find good thresholds in a moment anyway.
|
||||
|
|
@ -98,7 +154,6 @@ down.
|
|||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/esp32_touch`
|
||||
- :doc:`/components/binary_sensor/index`
|
||||
- :apiref:`binary_sensor/esp32_touch_binary_sensor.h`
|
||||
- `esp-idf Touch Sensor API <https://esp-idf.readthedocs.io/en/latest/api-reference/peripherals/touch_pad.html>`__
|
||||
|
|
|
|||
|
|
@ -264,24 +264,24 @@ presses.
|
|||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_multi_click:
|
||||
- timing:
|
||||
- ON for at most 1s
|
||||
- OFF for at most 1s
|
||||
- ON for at most 1s
|
||||
- OFF for at least 0.2s
|
||||
then:
|
||||
- logger.log: "Double Clicked"
|
||||
- timing:
|
||||
- ON for 1s to 2s
|
||||
- OFF for at least 0.5s
|
||||
then:
|
||||
- logger.log: "Single Long Clicked"
|
||||
- timing:
|
||||
- ON for at most 1s
|
||||
- OFF for at least 0.5s
|
||||
then:
|
||||
- logger.log: "Single Short Clicked"
|
||||
on_multi_click:
|
||||
- timing:
|
||||
- ON for at most 1s
|
||||
- OFF for at most 1s
|
||||
- ON for at most 1s
|
||||
- OFF for at least 0.2s
|
||||
then:
|
||||
- logger.log: "Double Clicked"
|
||||
- timing:
|
||||
- ON for 1s to 2s
|
||||
- OFF for at least 0.5s
|
||||
then:
|
||||
- logger.log: "Single Long Clicked"
|
||||
- timing:
|
||||
- ON for at most 1s
|
||||
- OFF for at least 0.5s
|
||||
then:
|
||||
- logger.log: "Single Short Clicked"
|
||||
|
||||
.. _binary_sensor-is_on_condition:
|
||||
.. _binary_sensor-is_off_condition:
|
||||
|
|
|
|||
|
|
@ -1,18 +1,31 @@
|
|||
PN532 NFC/RFID Tag
|
||||
==================
|
||||
PN532 NFC/RFID
|
||||
==============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up NFC tags for the PN532 integration.
|
||||
:description: Instructions for setting up PN532 NFC tag readers and tags in ESPHome
|
||||
:image: pn532.jpg
|
||||
:keywords: PN532, NFC, RFID
|
||||
|
||||
The ``pn532`` binary sensor platform lets you track if an NFC/RFID tag with a given
|
||||
unique id (``uid``) is currently being detected by the PN532 or not.
|
||||
.. _pn532-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``pn532`` component allows you to use PN532 NFC/RFID controllers
|
||||
(`datasheet <https://cdn-shop.adafruit.com/datasheets/pn532ds.pdf>`__, `adafruit <https://www.adafruit.com/product/364>`__)
|
||||
with ESPHome. This component is a global hub that establishes the connection to the PN532 via :ref:`SPI <spi>` and
|
||||
outputs its data. Using the :ref:`PN532 binary sensors <pn532-tag>` you can then
|
||||
create individual binary sensors that track if an NFC/RFID tag is currently detected by the PN532.
|
||||
|
||||
.. figure:: images/pn532-full.jpg
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
See :doc:`/components/pn532` for instructions for setting up the connection to the PN532.
|
||||
See :ref:`pn532-setting_up_tags` for information on how to setup individual binary sensors for this component.
|
||||
|
||||
As the communication with the PN532 is done using SPI for this integration, you need to set the two switches on
|
||||
the board to the SPI mode (usually by setting the first one to OFF and the second one to ON). Additionally, you need
|
||||
to have an :ref:`spi bus <spi>` in your configuration with both the **miso_pin** and **mosi_pin** set.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -32,7 +45,74 @@ See :doc:`/components/pn532` for instructions for setting up the connection to t
|
|||
name: "PN532 NFC Tag"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin on the ESP that the chip select line
|
||||
is connected to.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The duration of each scan on the PN532. This affects the
|
||||
duration that the individual binary sensors stay active when they're found.
|
||||
If a device is not found within this time window, it will be marked as not present. Defaults to 1s.
|
||||
- **on_tag** (*Optional*, :ref:`Automation <automation>`): An automation to perform
|
||||
when a tag is read. See :ref:`pn532-on_tag`.
|
||||
- **spi_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`SPI Component <spi>` if you want
|
||||
to use multiple SPI buses.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this component.
|
||||
|
||||
.. figure:: images/pn532-spi.jpg
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
Example for hooking up the PN532 via SPI. Notice the position of the two switches on the right.
|
||||
|
||||
.. _pn532-on_tag:
|
||||
|
||||
``on_tag``
|
||||
----------
|
||||
|
||||
This automation will be triggered when the PN532 module responds with a tag. Please note that this
|
||||
can be called quite often (with an interval of ``update_interval``) as it's triggered repeatedly
|
||||
if the tag is re-read many times.
|
||||
|
||||
The parameter ``x`` this trigger provides is of type ``std::string`` and is the tag UID in the format
|
||||
``74-10-37-94``. The configuration below will for example publish the tag ID on the MQTT topic ``pn532/tag``.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pn532:
|
||||
# ...
|
||||
on_tag:
|
||||
then:
|
||||
- mqtt.publish:
|
||||
topic: pn532/tag
|
||||
payload: !lambda 'return x;'
|
||||
|
||||
.. _pn532-tag:
|
||||
|
||||
NFC/RFID Tag
|
||||
------------
|
||||
|
||||
The ``pn532`` binary sensor platform lets you track if an NFC/RFID tag with a given
|
||||
unique id (``uid``) is currently being detected by the PN532 or not.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
clk_pin: D0
|
||||
miso_pin: D1
|
||||
mosi_pin: D2
|
||||
|
||||
pn532:
|
||||
cs_pin: D3
|
||||
update_interval: 1s
|
||||
|
||||
binary_sensor:
|
||||
- platform: pn532
|
||||
uid: 74-10-37-94
|
||||
name: "PN532 NFC Tag"
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **uid** (**Required**, string): The unique ID of the NFC/RFID tag. This is a hyphen-separated list
|
||||
of hexadecimal values. For example ``74-10-37-94``.
|
||||
|
|
@ -60,8 +140,8 @@ each tag.
|
|||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/pn532`
|
||||
- :doc:`index`
|
||||
- :doc:`rdm6300`
|
||||
- :apiref:`binary_sensor/pn532_component.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,31 @@
|
|||
RDM6300 NFC/RFID Tag
|
||||
====================
|
||||
RDM6300 NFC/RFID
|
||||
================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up NFC tags for the RDM6300 integration.
|
||||
:description: Instructions for setting up RDM6300 NFC/RFID tag readers and tags in ESPHome.
|
||||
:image: rdm6300.jpg
|
||||
:keywords: RDM6300, NFC, RFID
|
||||
|
||||
The ``rdm6300`` binary sensor platform lets you track if an NFC/RFID tag with a given
|
||||
unique id (``uid``) is currently being detected by the RDM6300 or not.
|
||||
.. _rdm6300-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``rdm6300`` component allows you to use RDM6300 NFC/RFID controllers
|
||||
(`datasheet <https://elty.pl/upload/download/RFID/RDM630-Spec.pdf>`__, `iTead <https://www.itead.cc/rdm6300.html>`__)
|
||||
with ESPHome. This component is a global hub that establishes the connection to the RDM6300 via :ref:`UART <uart>` and
|
||||
translates the received data. Using the :ref:`RDM6300 binary sensors <rdm6300-tag>` you can then
|
||||
create individual binary sensors that track if an NFC/RFID tag is currently detected by the RDM6300.
|
||||
|
||||
.. figure:: images/rdm6300-full.jpg
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
See :doc:`/components/rdm6300` for instructions for setting up the connection to the RDM6300.
|
||||
See :ref:`rdm6300-setting_up_tags` for information on how to setup individual binary sensors for this component.
|
||||
|
||||
As the communication with the RDM6300 is done using UART, you need
|
||||
to have an :ref:`UART bus <uart>` in your configuration with the ``rx_pin`` connected to the data pin of the RDM6300 and
|
||||
with the baud rate set to 9600
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -29,7 +42,36 @@ See :doc:`/components/rdm6300` for instructions for setting up the connection to
|
|||
name: "RDM6300 NFC Tag"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
|
||||
to use multiple UART buses.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this component.
|
||||
|
||||
.. _rdm6300-tag:
|
||||
|
||||
NFC/RFID Tag
|
||||
------------
|
||||
|
||||
The ``rdm6300`` binary sensor platform lets you track if an NFC/RFID tag with a given
|
||||
unique id (``uid``) is currently being detected by the RDM6300 or not.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
rx_pin: D0
|
||||
baud_rate: 9600
|
||||
|
||||
rdm6300:
|
||||
|
||||
binary_sensor:
|
||||
- platform: rdm6300
|
||||
uid: 7616525
|
||||
name: "RDM6300 NFC Tag"
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **uid** (**Required**, integer): The unique ID of the NFC/RFID tag.
|
||||
- **name** (**Required**, string): The name of the binary sensor.
|
||||
|
|
@ -60,7 +102,7 @@ each tag.
|
|||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/rdm6300`
|
||||
- :doc:`pn532`
|
||||
- :doc:`/components/binary_sensor/index`
|
||||
- :apiref:`binary_sensor/rdm6300_component.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -1,9 +1,68 @@
|
|||
Remote Receiver Binary Sensor
|
||||
=============================
|
||||
Remote Receiver
|
||||
===============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up remote receiver binary sensors for infrared and RF codes.
|
||||
:image: remote.png
|
||||
:keywords: RF, infrared
|
||||
|
||||
.. _remote-receiver-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``remote_receiver`` component lets you receive and decode any remote signal, these can
|
||||
for example be infrared remotes or 433MHz signals.
|
||||
|
||||
The component is split up into two parts: the remote receiver hub which can be used to
|
||||
receive, decode and dump all remote codes, and individual
|
||||
:ref:`remote receiver binary sensors <remote-receiver-binary-sensor>` which will trigger when they
|
||||
hear their own configured signal.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
remote_receiver:
|
||||
pin: GPIO32
|
||||
dump: all
|
||||
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin to receive the remote signal on.
|
||||
- **dump** (*Optional*, list): Decode and dump these remote codes in the logs. Set to ``all`` to
|
||||
dump all available codecs:
|
||||
|
||||
- **lg**: Decode and dump LG infrared codes.
|
||||
- **nec**: Decode and dump NEC infrared codes.
|
||||
- **panasonic**: Decode and dump Panasonic infrared codes.
|
||||
- **jvc**: Decode and dump JVC infrared codes.
|
||||
- **samsung**: Decode and dump Samsung infrared codes.
|
||||
- **sony**: Decode and dump Sony infrared codes.
|
||||
- **rc_switch**: Decode and dump RCSwitch RF codes.
|
||||
- **rc5**: Decode and dump RC5 IR codes.
|
||||
- **raw**: Print all remote codes in their raw form. Useful for using arbitrary protocols.
|
||||
|
||||
- **tolerance** (*Optional*, int): The percentage that the remote signal lengths can deviate in the
|
||||
decoding process. Defaults to ``25%``.
|
||||
- **buffer_size** (*Optional*, int): The size of the internal buffer for storing the remote codes. Defaults to ``10kb``
|
||||
on the ESP32 and ``1kb`` on the ESP8266.
|
||||
- **filter** (*Optional*, :ref:`time <config-time>`): Filter any pulses that are shorter than this. Useful for removing
|
||||
glitches from noisy signals. Defaults to ``10us``.
|
||||
- **idle** (*Optional*, :ref:`time <config-time>`): The amount of time that a signal should remain stable (i.e. not
|
||||
change) for it to be considered complete. Defaults to ``10ms``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. Use this if you have
|
||||
multiple remote transmitters.
|
||||
|
||||
.. note::
|
||||
|
||||
See :ref:`finding_remote_codes` for a guide for setting this up.
|
||||
|
||||
.. _remote-receiver-binary-sensor:
|
||||
|
||||
Binary Sensor
|
||||
-------------
|
||||
|
||||
The ``remote_receiver`` binary sensor lets you track when a button on a remote control is pressed.
|
||||
|
||||
|
|
@ -25,12 +84,12 @@ then immediately OFF.
|
|||
command: 0x100BCBD
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **name** (**Required**, string): The name for the binary sensor.
|
||||
- The remote code, see :ref:`remote_transmitter-codes`. Only one
|
||||
of them can be specified per binary sensor.
|
||||
- **remote_receiver_id** (*Optional*, :ref:`config-id`): The id of the :doc:`/components/remote_receiver`.
|
||||
- **remote_receiver_id** (*Optional*, :ref:`config-id`): The id of the :ref:`remote-receiver-component`.
|
||||
Defaults to the first hub in your configuration.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
|
|
@ -61,8 +120,7 @@ See Also
|
|||
--------
|
||||
|
||||
- :doc:`index`
|
||||
- :doc:`/components/remote_receiver`
|
||||
- :doc:`/components/remote_transmitter`
|
||||
- :doc:`/components/switch/remote_transmitter`
|
||||
- `RCSwitch <https://github.com/sui77/rc-switch>`__ by `Suat Özgür <https://github.com/sui77>`__
|
||||
- `IRRemoteESP8266 <https://github.com/markszabo/IRremoteESP8266/>`__ by `Mark Szabo-Simon <https://github.com/markszabo>`__
|
||||
- :apiref:`remote/remote_receiver.h`
|
||||
|
|
|
|||
|
|
@ -9,10 +9,10 @@ The ``display`` component houses ESPHome's powerful rendering and display
|
|||
engine. Fundamentally, there are these types of displays:
|
||||
|
||||
- Text based displays like :doc:`7-Segment displays <max7219>` or
|
||||
:doc:`some LCD displays <lcd_gpio>`.
|
||||
:doc:`some LCD displays <lcd_display>`.
|
||||
- Displays like the :doc:`nextion` that have their own processors for rendering.
|
||||
- Binary displays which can toggle ON/OFF any pixel, like :doc:`E-Paper displays <waveshare_epaper>` or
|
||||
:doc:`OLED displays <ssd1306_spi>`.
|
||||
:doc:`OLED displays <ssd1306>`.
|
||||
|
||||
For the last type, ESPHome has a powerful rendering engine that can do
|
||||
many things like draw some basic shapes, print text with any font you want, or even show images.
|
||||
|
|
@ -243,7 +243,8 @@ As you can see, when you call ``printf`` most of the string is printed as-is, bu
|
|||
stuff after it is encountered, it is magically replaced by the argument after the format (here ``id(my_sensor).state``).
|
||||
|
||||
Every time you type a percent sign ``%`` in a printf format string, it will treat the following letters as a format tag
|
||||
until a so-called "specifier" is encountered (in this case ``f``). You can read more about it `here <https://www.tutorialspoint.com/c_standard_library/c_function_printf.htm>`__,
|
||||
until a so-called "specifier" is encountered (in this case ``f``). You can read more about it
|
||||
`here <https://www.tutorialspoint.com/c_standard_library/c_function_printf.htm>`__,
|
||||
but for ESPHome there are really just a few things you need to know.
|
||||
|
||||
Let's break ``%.1f`` down:
|
||||
|
|
|
|||
|
|
@ -1,15 +1,69 @@
|
|||
GPIO Character-Based LCD Display
|
||||
================================
|
||||
Character-Based LCD Display
|
||||
===========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up GPIO character-based LCD displays.
|
||||
:description: Instructions for setting up character-based LCD displays.
|
||||
:image: lcd.jpg
|
||||
|
||||
.. _lcd-pcf8574:
|
||||
|
||||
PCF8574
|
||||
-------
|
||||
|
||||
The ``lcd_pcf8574`` display platform allows you to use standard character-based LCD displays like
|
||||
`this one <https://docs.labs.mediatek.com/resource/linkit7697-arduino/en/tutorial/driving-1602-lcd-with-pcf8574-pcf8574a>`__
|
||||
with ESPHome. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
|
||||
and 2-4 rows), and not for LCD displays that can control each pixel individually.
|
||||
|
||||
This version of the LCD integration is for LCD displays with an PCF8574 connected to all the data pins. This has
|
||||
the benefit that you only need to connect two data wires to the ESP instead of the 6 or 10 with the :ref:`lcd-gpio`.
|
||||
As the communication with the :ref:`I²C Bus <i2c>`, you need to have an ``i2c:`` section in your configuration.
|
||||
|
||||
.. figure:: images/lcd-pcf8574.jpg
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
The PCF8574 chip attached to the LCD Display.
|
||||
|
||||
.. figure:: images/lcd-hello_world.jpg
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
i2c:
|
||||
sda: D0
|
||||
scl: D1
|
||||
|
||||
display:
|
||||
- platform: lcd_pcf8574
|
||||
dimensions: 18x4
|
||||
address: 0x3F
|
||||
lambda: |-
|
||||
it.print("Hello World!");
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **dimensions** (**Required**, string): The dimensions of the display with ``ROWSxCOLUMNS``. If you're not
|
||||
sure, power the display up and just count them.
|
||||
- **address** (*Optional*, int): The :ref:`I²C <i2c>` address of the PCF8574 chip, defaults to ``0x3F``.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
|
||||
See :ref:`display-lcd_lambda` for more information.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``1s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
.. _lcd-gpio:
|
||||
|
||||
GPIO
|
||||
----
|
||||
|
||||
The ``lcd_gpio`` display platform allows you to use standard character-based LCD displays like `this one <https://www.adafruit.com/product/181>`__
|
||||
with ESPHome. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
|
||||
and 2-4 rows), and not for LCD displays that can control each pixel individually. Also, this is the GPIO version of the LCD
|
||||
integration where each of the data pins of the LCD needs a dedicated GPIO pin on the ESP. These LCD displays are also
|
||||
commonly sold with a PCF8574 chip which only need two lines to the ESP, for that see :doc:`lcd_pcf8574`.
|
||||
commonly sold with a PCF8574 chip which only need two lines to the ESP, for that see :ref:`lcd-pcf8574`.
|
||||
|
||||
.. figure:: images/lcd-full.jpg
|
||||
:align: center
|
||||
|
|
@ -17,10 +71,6 @@ commonly sold with a PCF8574 chip which only need two lines to the ESP, for that
|
|||
|
||||
LCD Display.
|
||||
|
||||
.. figure:: images/lcd-hello_world.jpg
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
|
|
@ -38,7 +88,7 @@ commonly sold with a PCF8574 chip which only need two lines to the ESP, for that
|
|||
it.print("Hello World!");
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **dimensions** (**Required**, string): The dimensions of the display with ``ROWSxCOLUMNS``. If you're not
|
||||
sure, power the display up and just count them.
|
||||
|
|
@ -111,7 +161,9 @@ See Also
|
|||
--------
|
||||
|
||||
- :doc:`index`
|
||||
- :doc:`lcd_pcf8574`
|
||||
- :doc:`/components/switch/gpio`
|
||||
- :doc:`/components/binary_sensor/gpio`
|
||||
- :doc:`/components/pcf8574`
|
||||
- :apiref:`display/lcd_display.h`
|
||||
- `Arduino LiquidCrystal Library <https://www.arduino.cc/en/Reference/LiquidCrystal>`__
|
||||
- :ghedit:`Edit`
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
PCF8574 Character-Based LCD Display
|
||||
===================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the touch pad on the ESP32.
|
||||
:image: lcd.jpg
|
||||
|
||||
The ``lcd_pcf8574`` display platform allows you to use standard character-based LCD displays like `this one <https://docs.labs.mediatek.com/resource/linkit7697-arduino/en/tutorial/driving-1602-lcd-with-pcf8574-pcf8574a>`__
|
||||
with ESPHome. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
|
||||
and 2-4 rows), and not for LCD displays that can control each pixel individually.
|
||||
|
||||
This version of the LCD integration is for LCD displays with an PCF8574 connected to all the data pins. This has
|
||||
the benefit that you only need to connect two data wires to the ESP instead of the 6 or 10 with the :doc:`lcd_gpio`.
|
||||
As the communication with the :ref:`I²C Bus <i2c>`, you need to have an ``i2c:`` section in your configuration.
|
||||
|
||||
.. figure:: images/lcd-pcf8574.jpg
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
The PCF8574 chip attached to the LCD Display.
|
||||
|
||||
.. figure:: images/lcd-hello_world.jpg
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
i2c:
|
||||
sda: D0
|
||||
scl: D1
|
||||
|
||||
display:
|
||||
- platform: lcd_pcf8574
|
||||
dimensions: 18x4
|
||||
address: 0x3F
|
||||
lambda: |-
|
||||
it.print("Hello World!");
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **dimensions** (**Required**, string): The dimensions of the display with ``ROWSxCOLUMNS``. If you're not
|
||||
sure, power the display up and just count them.
|
||||
- **address** (*Optional*, int): The :ref:`I²C <i2c>` address of the PCF8574 chip, defaults to ``0x3F``.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
|
||||
See :ref:`display-lcd_lambda` for more information.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``1s``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`index`
|
||||
- :doc:`lcd_gpio`
|
||||
- :doc:`/components/pcf8574`
|
||||
- :apiref:`display/lcd_display.h`
|
||||
- `Arduino LiquidCrystal Library <https://www.arduino.cc/en/Reference/LiquidCrystal>`__
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -5,7 +5,8 @@ MAX7219 7-Segment Display
|
|||
:description: Instructions for setting up MAX7219 7-segment displays.
|
||||
:image: max7219.jpg
|
||||
|
||||
The ``max7219`` display platform allows you to use MAX7219 7-segment display drivers (`datasheet <https://datasheets.maximintegrated.com/en/ds/MAX7219-MAX7221.pdf>`__,
|
||||
The ``max7219`` display platform allows you to use MAX7219 7-segment display drivers (
|
||||
`datasheet <https://datasheets.maximintegrated.com/en/ds/MAX7219-MAX7221.pdf>`__,
|
||||
`hobbycomponents <https://hobbycomponents.com/displays/597-max7219-8-digit-seven-segment-display-module>`__)
|
||||
with ESPHome. Please note that this integration is *only* for 7-segment display, not matrix configurations.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,89 @@
|
|||
SSD1306 OLED Display over SPI
|
||||
=============================
|
||||
SSD1306 OLED Display
|
||||
====================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up SSD1306 OLED display drivers using an SPI bus
|
||||
:description: Instructions for setting up SSD1306 OLED display drivers.
|
||||
:image: ssd1306.jpg
|
||||
|
||||
.. _ssd1306-i2c:
|
||||
|
||||
Over I²C
|
||||
--------
|
||||
|
||||
The ``ssd1306_i2c`` display platform allows you to use
|
||||
SSD1306 (`datasheet <https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf>`__,
|
||||
`Adafruit <https://www.adafruit.com/product/326>`__)
|
||||
and SH1106 (`datasheet <https://www.elecrow.com/download/SH1106%20datasheet.pdf>`__,
|
||||
`electrodragon <https://www.electrodragon.com/product/1-3-12864-blue-oled-display-iicspi/>`__)
|
||||
displays with ESPHome. Note that this component is for displays that are connected via the :ref:`I²C Bus <i2c>`.
|
||||
If your SSD1306 or SH1106 is connected via the 4-Wire :ref:`SPI bus <spi>`, see :ref:`ssd1306-spi`.
|
||||
|
||||
.. figure:: images/ssd1306-full.jpg
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
SSD1306 OLED Display
|
||||
|
||||
Connect D0 to the SCL pin you chose for the :ref:`I²C Bus <i2c>`, and connect D1 to the SDA pin. For power, connect
|
||||
VCC to 3.3V and GND to GND. Optionally you can also connect the ``RESET`` pin to a pin on the ESP which may
|
||||
improve reliability.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
i2c:
|
||||
sda: D1
|
||||
scl: D2
|
||||
|
||||
display:
|
||||
- platform: ssd1306_i2c
|
||||
model: "SSD1306 128x64"
|
||||
reset_pin: D0
|
||||
address: 0x3C
|
||||
lambda: |-
|
||||
it.print(0, 0, id(font), "Hello World!");
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **model** (**Required**): The model of the display. Options are:
|
||||
|
||||
- ``SSD1306 128x32`` (SSD1306 with 128 columns and 32 rows)
|
||||
- ``SSD1306 128x64``
|
||||
- ``SSD1306 96x16``
|
||||
- ``SSD1306 64x48``
|
||||
- ``SH1106 128x32``
|
||||
- ``SH1106 128x64``
|
||||
- ``SH1106 96x16``
|
||||
- ``SH1106 64x48``
|
||||
|
||||
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin. Defaults to not connected.
|
||||
- **address** (*Optional*, int): Manually specify the :ref:`I²C <i2c>` address of the display. Defaults to 0x3C.
|
||||
- **rotation** (*Optional*): Set the rotation of the display. Everything you draw in ``lambda:`` will be rotated
|
||||
by this option. One of ``0°`` (default), ``90°``, ``180°``, ``270°``.
|
||||
- **external_vcc** (*Optional*, boolean): Set this to true if you have the VCC pin connected to an external power supply.
|
||||
Defaults to ``false``.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
|
||||
See :ref:`display-engine` for more information.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``5s``.
|
||||
- **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 speed up the display update process you can select higher i2c frequencies.
|
||||
|
||||
.. _ssd1306-spi:
|
||||
|
||||
Over SPI
|
||||
--------
|
||||
|
||||
The ``ssd1306_spi`` display platform allows you to use
|
||||
SSD1306 (`datasheet <https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf>`__, `Adafruit <https://www.adafruit.com/product/326>`__)
|
||||
and SH1106 (`datasheet <https://www.elecrow.com/download/SH1106%20datasheet.pdf>`__, `electrodragon <https://www.electrodragon.com/product/1-3-12864-blue-oled-display-iicspi/>`__)
|
||||
and SH1106 (`datasheet <https://www.elecrow.com/download/SH1106%20datasheet.pdf>`__,
|
||||
`electrodragon <https://www.electrodragon.com/product/1-3-12864-blue-oled-display-iicspi/>`__)
|
||||
displays with ESPHome. Note that this component is for displays that are connected via the 4-Wire :ref:`SPI bus <spi>`.
|
||||
If your SSD1306 or SH1106 is connected via the :ref:`I²C Bus <i2c>`, see :doc:`ssd1306_i2c`.
|
||||
If your SSD1306 or SH1106 is connected via the :ref:`I²C Bus <i2c>`, see :ref:`ssd1306-i2c`.
|
||||
|
||||
.. figure:: images/ssd1306-full.jpg
|
||||
:align: center
|
||||
|
|
@ -39,7 +113,7 @@ improve reliability.
|
|||
it.print(0, 0, id(font), "Hello World!");
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **model** (**Required**): The model of the display. Options are:
|
||||
|
||||
|
|
@ -1,77 +0,0 @@
|
|||
SSD1306 OLED Display over I²C
|
||||
=============================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up SSD1306 OLED display drivers using the i2c bus.
|
||||
:image: ssd1306.jpg
|
||||
|
||||
The ``ssd1306_i2c`` display platform allows you to use
|
||||
SSD1306 (`datasheet <https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf>`__, `Adafruit <https://www.adafruit.com/product/326>`__)
|
||||
and SH1106 (`datasheet <https://www.elecrow.com/download/SH1106%20datasheet.pdf>`__, `electrodragon <https://www.electrodragon.com/product/1-3-12864-blue-oled-display-iicspi/>`__)
|
||||
displays with ESPHome. Note that this component is for displays that are connected via the :ref:`I²C Bus <i2c>`.
|
||||
If your SSD1306 or SH1106 is connected via the 4-Wire :ref:`SPI bus <spi>`, see :doc:`ssd1306_spi`.
|
||||
|
||||
.. figure:: images/ssd1306-full.jpg
|
||||
:align: center
|
||||
:width: 75.0%
|
||||
|
||||
SSD1306 OLED Display
|
||||
|
||||
Connect D0 to the SCL pin you chose for the :ref:`I²C Bus <i2c>`, and connect D1 to the SDA pin. For power, connect
|
||||
VCC to 3.3V and GND to GND. Optionally you can also connect the ``RESET`` pin to a pin on the ESP which may
|
||||
improve reliability.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
i2c:
|
||||
sda: D1
|
||||
scl: D2
|
||||
|
||||
display:
|
||||
- platform: ssd1306_i2c
|
||||
model: "SSD1306 128x64"
|
||||
reset_pin: D0
|
||||
address: 0x3C
|
||||
lambda: |-
|
||||
it.print(0, 0, id(font), "Hello World!");
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **model** (**Required**): The model of the display. Options are:
|
||||
|
||||
- ``SSD1306 128x32`` (SSD1306 with 128 columns and 32 rows)
|
||||
- ``SSD1306 128x64``
|
||||
- ``SSD1306 96x16``
|
||||
- ``SSD1306 64x48``
|
||||
- ``SH1106 128x32``
|
||||
- ``SH1106 128x64``
|
||||
- ``SH1106 96x16``
|
||||
- ``SH1106 64x48``
|
||||
|
||||
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin. Defaults to not connected.
|
||||
- **address** (*Optional*, int): Manually specify the :ref:`I²C <i2c>` address of the display. Defaults to 0x3C.
|
||||
- **rotation** (*Optional*): Set the rotation of the display. Everything you draw in ``lambda:`` will be rotated
|
||||
by this option. One of ``0°`` (default), ``90°``, ``180°``, ``270°``.
|
||||
- **external_vcc** (*Optional*, boolean): Set this to true if you have the VCC pin connected to an external power supply.
|
||||
Defaults to ``false``.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
|
||||
See :ref:`display-engine` for more information.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``5s``.
|
||||
- **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 speed up the display update process you can select higher i2c frequencies.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`index`
|
||||
- :apiref:`display/ssd1306.h`
|
||||
- `SSD1306 Library <https://github.com/adafruit/Adafruit_SSD1306>`__ by `Adafruit <https://www.adafruit.com/>`__
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
ESP32 Touch Pad Hub
|
||||
===================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the touch pad feature on the ESP32.
|
||||
:image: touch.png
|
||||
|
||||
The ``esp32_touch`` component creates a global hub for detecting touches on
|
||||
the eight touch pads of the ESP32 as :doc:`binary senors </components/binary_sensor/esp32_touch>`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
esp32_touch:
|
||||
setup_mode: False
|
||||
|
||||
binary_sensor:
|
||||
- platform: esp32_touch
|
||||
name: "ESP32 Touch Pad GPIO27"
|
||||
pin: GPIO27
|
||||
threshold: 1000
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **setup_mode** (*Optional*, boolean): Whether debug messages with the touch pad value should
|
||||
be displayed in the logs. Useful for finding out suitable thresholds for the binary sensors, but
|
||||
spam the logs. See :doc:`setting up touch pads </components/binary_sensor/esp32_touch>`
|
||||
for more information. Defaults to false.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for code generation.
|
||||
|
||||
Advanced options (the defaults are usually quite good, but if you're having accuracy issues, use these):
|
||||
|
||||
- **iir_filter** (*Optional*, :ref:`config-time`): Optionally set up an
|
||||
`Infinite Impulse Response <https://en.wikipedia.org/wiki/Infinite_impulse_response>`__
|
||||
filter should be applied to all touch pads. This can increase the accuracy of the touch pads a lot, but
|
||||
higher values decrease the response time. A good value to start with is ``10ms``. Default is no IIR filter.
|
||||
- **sleep_duration** (*Optional*, :ref:`config-time`): Set a time period
|
||||
denoting the amount of time the touch peripheral should sleep between measurements. This can decrease
|
||||
power usage but make the sensor slower. Default is about 27 milliseconds.
|
||||
- **measurement_duration** (*Optional*, :ref:`config-time`): Set the conversion
|
||||
time for all touch pads. A longer conversion time means that more charge/discharge cycles of the touch pad
|
||||
can be performed, therefore increasing accuracy. Default is about 8ms, the maximum amount.
|
||||
- **low_voltage_reference** (*Optional*): The low voltage reference to use for the charge cycles. See
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``0.5V``, ``0.6V``, ``0.7V``, ``0.8V``. Default is ``0.5V``.
|
||||
- **high_voltage_reference** (*Optional*): The high voltage reference to use for the charge cycles. See
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``2.4V``, ``2.5V``, ``2.6V``, ``2.7V``. Default is ``2.7V``.
|
||||
- **voltage_attenuation** (*Optional*): The voltage attenuation to use for the charge cycles. See
|
||||
the `esp-idf docs <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/touch_pad.html#optimization-of-measurements>`__
|
||||
for a nice explanation of this. One of ``1.5V``, ``1V``, ``0.5V``, ``0V``. Default is ``0V``.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`binary_sensor/esp32_touch`
|
||||
- :apiref:`binary_sensor/esp32_touch_binary_sensor.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -19,7 +19,7 @@ put on external ones.
|
|||
i2c:
|
||||
sda: 21
|
||||
scl: 22
|
||||
scan: False
|
||||
scan: True
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
|
@ -30,8 +30,7 @@ Configuration variables:
|
|||
Defaults to the default of your board (usually GPIO22 for ESP32 and
|
||||
GPIO5 for ESP8266).
|
||||
- **scan** (*Optional*, boolean): If ESPHome should do a search of the I²C address space on startup.
|
||||
Note that this can slow down startup and is only recommended for when setting up new sensors. Defaults to
|
||||
``False``.
|
||||
Defaults to ``False``.
|
||||
- **frequency** (*Optional*, float): Set the frequency the I²C bus should operate on.
|
||||
Defaults to ``50kHz``. Values are ``50kHz``, ``100kHz``, ``200kHz``, ... ``800kHz``
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,20 @@
|
|||
FastLED Clockless Light
|
||||
=======================
|
||||
FastLED Light
|
||||
=============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up FastLED addressable lights like NEOPIXEL.
|
||||
:image: color_lens.png
|
||||
|
||||
.. _fastled-clockless:
|
||||
|
||||
Clockless
|
||||
---------
|
||||
|
||||
The ``fastled_clockless`` light platform allows you to create RGB lights
|
||||
in ESPHome for a :ref:`number of supported chipsets <fastled_clockless-chipsets>`.
|
||||
|
||||
Clockless FastLED lights differ from the
|
||||
:doc:`fastled_spi` in that they only have a single data wire to connect, and not separate data and clock wires.
|
||||
:ref:`fastled-spi` in that they only have a single data wire to connect, and not separate data and clock wires.
|
||||
|
||||
.. figure:: images/fastled_clockless-ui.png
|
||||
:align: center
|
||||
|
|
@ -27,7 +32,7 @@ Clockless FastLED lights differ from the
|
|||
name: "FastLED WS2811 Light"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **name** (**Required**, string): The name of the light.
|
||||
- **chipset** (**Required**, string): Set a chipset to use.
|
||||
|
|
@ -62,7 +67,7 @@ Configuration variables:
|
|||
.. _fastled_clockless-chipsets:
|
||||
|
||||
Supported Chipsets
|
||||
------------------
|
||||
******************
|
||||
|
||||
- ``NEOPIXEL``
|
||||
- ``WS2811``
|
||||
|
|
@ -89,11 +94,83 @@ Supported Chipsets
|
|||
- ``UCS1904``
|
||||
- ``UCS2903``
|
||||
|
||||
.. _fastled-spi:
|
||||
|
||||
SPI
|
||||
---
|
||||
|
||||
The ``fastled_spi`` light platform allows you to create RGB lights
|
||||
in ESPHome for a :ref:`number of supported chipsets <fastled_spi-chipsets>`.
|
||||
|
||||
SPI FastLED lights differ from the
|
||||
:ref:`fastled-clockless` in that they require two pins to be connected, one for a data and one for a clock signal
|
||||
whereas the clockless lights only need a single pin.
|
||||
|
||||
.. figure:: images/fastled_spi-ui.png
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
- platform: fastled_spi
|
||||
chipset: WS2801
|
||||
data_pin: GPIO23
|
||||
clock_pin: GPIO22
|
||||
num_leds: 60
|
||||
rgb_order: BRG
|
||||
name: "FastLED SPI Light"
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **name** (**Required**, string): The name of the light.
|
||||
- **chipset** (**Required**, string): Set a chipset to use. See :ref:`fastled_spi-chipsets` for options.
|
||||
- **data_pin** (**Required**, :ref:`config-pin`): The pin for the data line of the FastLED light.
|
||||
- **clock_pin** (**Required**, :ref:`config-pin`): The pin for the clock line of the FastLED light.
|
||||
- **num_leds** (**Required**, int): The number of LEDs attached.
|
||||
- **rgb_order** (*Optional*, string): The order of the RGB channels. Use this if your
|
||||
light doesn't seem to map the RGB light channels correctly. For example if your light
|
||||
shows up green when you set a red color through the frontend. Valid values are ``RGB``,
|
||||
``RBG``, ``GRB``, ``GBR``, ``BRG`` and ``BGR``. Defaults to ``RGB``.
|
||||
- **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 the default value for the used chipset.
|
||||
- **gamma_correct** (*Optional*, float): The `gamma correction
|
||||
factor <https://en.wikipedia.org/wiki/Gamma_correction>`__ for the light. Defaults to ``2.8``.
|
||||
- **color_correct** (*Optional*, list of percentages): The color correction for each channel. This denotes
|
||||
the maximum brightness of the red, green and blue channel. Defaults to ``color_correct: [100%, 100%, 100%]``.
|
||||
- **default_transition_length** (*Optional*, :ref:`config-time`): The length of
|
||||
the transition if no transition parameter is provided by Home Assistant. Defaults to ``1s``.
|
||||
- **power_supply** (*Optional*, :ref:`config-id`): The :doc:`/components/power_supply` to connect to
|
||||
this light. When the light is turned on, the power supply will automatically be switched on too.
|
||||
- **effects** (*Optional*, list): A list of :ref:`light effects <light-effects>` to use for this light.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
- **internal** (*Optional*, boolean): Mark this component as internal. Internal components will
|
||||
not be exposed to the frontend (like Home Assistant). Only specifying an ``id`` without
|
||||
a ``name`` will implicitly set this to true.
|
||||
- If MQTT enabled, all other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
|
||||
.. _fastled_spi-chipsets:
|
||||
|
||||
Supported Chipsets
|
||||
******************
|
||||
|
||||
- ``APA102``
|
||||
- ``DOTSTAR``
|
||||
- ``LPD8806``
|
||||
- ``P9813``
|
||||
- ``SK9822``
|
||||
- ``SM16716``
|
||||
- ``WS2801``
|
||||
- ``WS2803``
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/light/index`
|
||||
- :doc:`/components/light/fastled_spi`
|
||||
- :doc:`/components/power_supply`
|
||||
- :apiref:`light/fastled_light_output.h`
|
||||
- `Arduino FastLED library <https://github.com/FastLED/FastLED>`__
|
||||
|
|
@ -1,86 +0,0 @@
|
|||
FastLED SPI Light
|
||||
=================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up other FastLED addressable lights.
|
||||
:image: color_lens.png
|
||||
|
||||
The ``fastled_spi`` light platform allows you to create RGB lights
|
||||
in ESPHome for a :ref:`number of supported chipsets <fastled_spi-chipsets>`.
|
||||
|
||||
SPI FastLED lights differ from the
|
||||
:doc:`fastled_clockless` in that they require two pins to be connected, one for a data and one for a clock signal
|
||||
whereas the clockless lights only need a single pin.
|
||||
|
||||
.. figure:: images/fastled_spi-ui.png
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
light:
|
||||
- platform: fastled_spi
|
||||
chipset: WS2801
|
||||
data_pin: GPIO23
|
||||
clock_pin: GPIO22
|
||||
num_leds: 60
|
||||
rgb_order: BRG
|
||||
name: "FastLED SPI Light"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **name** (**Required**, string): The name of the light.
|
||||
- **chipset** (**Required**, string): Set a chipset to use. See :ref:`fastled_spi-chipsets` for options.
|
||||
- **data_pin** (**Required**, :ref:`config-pin`): The pin for the data line of the FastLED light.
|
||||
- **clock_pin** (**Required**, :ref:`config-pin`): The pin for the clock line of the FastLED light.
|
||||
- **num_leds** (**Required**, int): The number of LEDs attached.
|
||||
- **rgb_order** (*Optional*, string): The order of the RGB channels. Use this if your
|
||||
light doesn't seem to map the RGB light channels correctly. For example if your light
|
||||
shows up green when you set a red color through the frontend. Valid values are ``RGB``,
|
||||
``RBG``, ``GRB``, ``GBR``, ``BRG`` and ``BGR``. Defaults to ``RGB``.
|
||||
- **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 the default value for the used chipset.
|
||||
- **gamma_correct** (*Optional*, float): The `gamma correction
|
||||
factor <https://en.wikipedia.org/wiki/Gamma_correction>`__ for the light. Defaults to ``2.8``.
|
||||
- **color_correct** (*Optional*, list of percentages): The color correction for each channel. This denotes
|
||||
the maximum brightness of the red, green and blue channel. Defaults to ``color_correct: [100%, 100%, 100%]``.
|
||||
- **default_transition_length** (*Optional*, :ref:`config-time`): The length of
|
||||
the transition if no transition parameter is provided by Home Assistant. Defaults to ``1s``.
|
||||
- **power_supply** (*Optional*, :ref:`config-id`): The :doc:`/components/power_supply` to connect to
|
||||
this light. When the light is turned on, the power supply will automatically be switched on too.
|
||||
- **effects** (*Optional*, list): A list of :ref:`light effects <light-effects>` to use for this light.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
- **internal** (*Optional*, boolean): Mark this component as internal. Internal components will
|
||||
not be exposed to the frontend (like Home Assistant). Only specifying an ``id`` without
|
||||
a ``name`` will implicitly set this to true.
|
||||
- If MQTT enabled, all other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
|
||||
.. _fastled_spi-chipsets:
|
||||
|
||||
Supported Chipsets
|
||||
------------------
|
||||
|
||||
- ``APA102``
|
||||
- ``DOTSTAR``
|
||||
- ``LPD8806``
|
||||
- ``P9813``
|
||||
- ``SK9822``
|
||||
- ``SM16716``
|
||||
- ``WS2801``
|
||||
- ``WS2803``
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/light/index`
|
||||
- :doc:`/components/light/fastled_clockless`
|
||||
- :doc:`/components/power_supply`
|
||||
- :apiref:`light/fast_led_light_output.h`
|
||||
- `Arduino FastLED library <https://github.com/FastLED/FastLED>`__
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -8,9 +8,9 @@ Neopixelbus Light
|
|||
The ``neopixelbus`` light platform allows you to create RGB lights
|
||||
in ESPHome for a individually addressable lights like NeoPixel or WS2812.
|
||||
|
||||
It is very similar to the :doc:`fastled_clockless` and :doc:`fastled_spi` platforms;
|
||||
It is very similar to the :doc:`fastled` platform.
|
||||
in fact most addressable lights are supported through both light platforms. The
|
||||
difference is that they use different libraries: While the fastled platforms use
|
||||
difference is that they use different libraries: While the fastled platform uses
|
||||
the `FastLED <https://github.com/FastLED/FastLED>`__ library, this integration uses
|
||||
the `NeoPixelBus <https://github.com/Makuna/NeoPixelBus/>`__ library internally.
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ See Also
|
|||
--------
|
||||
|
||||
- :doc:`/components/light/index`
|
||||
- :doc:`/components/light/fastled_clockless`
|
||||
- :doc:`/components/light/fastled`
|
||||
- :doc:`/components/power_supply`
|
||||
- :apiref:`light/neo_pixel_light_output.h`
|
||||
- `NeoPixelBus library <https://github.com/Makuna/NeoPixelBus/wiki/ESP8266-NeoMethods>`__
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Light Partition
|
|||
:image: color_lens.png
|
||||
|
||||
The ``partition`` light platform allows you to combine multiple addressable light segments
|
||||
(like :doc:`fastled_clockless` or :doc:`neopixelbus`) into a single addressable light.
|
||||
(like :doc:`fastled` or :doc:`neopixelbus`) into a single addressable light.
|
||||
This platform also allows splitting up an addressable lights into multiple segments, so that
|
||||
segments can be individually controlled.
|
||||
|
||||
|
|
@ -61,7 +61,7 @@ See Also
|
|||
--------
|
||||
|
||||
- :doc:`/components/light/index`
|
||||
- :doc:`/components/light/fastled_clockless`
|
||||
- :doc:`/components/light/fastled`
|
||||
- :doc:`/components/light/neopixelbus`
|
||||
- :apiref:`light/addressable_light.h`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -1,145 +0,0 @@
|
|||
MY9231/MY9291 LED driver Component
|
||||
==================================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MY9231 and MY9291 LED drives in ESPHome.
|
||||
:image: my9231.png
|
||||
:keywords: MY9231, MY9291, Sonoff B1, Ai-thinker AiLight WiFi light bulb, Arilux E27 Smart Bulb
|
||||
|
||||
The MY9231/MY9291 component represents a MY9231/MY9291 LED diver chain
|
||||
(`MY9231 description <http://www.my-semi.com.tw/file/MY9231_BF_0.91.pdf>`__,
|
||||
`MY9291 description <http://www.my-semi.com.tw/file/MY9291_BF_0.91.pdf>`__) in
|
||||
ESPHome. Communication is done with two GPIO pins (DI and DCKI) and multiple
|
||||
driver chips can be chained. There are two models with different number of
|
||||
output channels (MY9291 with 4 channels and MY9231 with 3 channels). They are
|
||||
popular driver chips used in smart light blubs:
|
||||
|
||||
- Sonoff B1 (MY9231)
|
||||
- Ai-Thinker AiLight WiFi light bulb (MY9291)
|
||||
- Arilux E27 Smart Bulb (MY9231)
|
||||
|
||||
To use the channels of this components, you first need to setup the
|
||||
global ``my9231`` hub and give it an id, and then define the
|
||||
:doc:`individual output channels </components/output/my9231>`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
my9231:
|
||||
- data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: my9231
|
||||
id: 'my9231_output1'
|
||||
channel: 0
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **data_pin** (**Required**, :ref:`config-pin_schema`): The pin which DI is connected
|
||||
to.
|
||||
- **clock_pin** (**Required**, :ref:`config-pin_schema`): The pin which DCKI is
|
||||
connected to.
|
||||
- **num_channels** (*Optional*, int): Total number of channels of the whole
|
||||
chain. Must be in range from 3 to 1020. Defaults to 6.
|
||||
- **num_chips** (*Optional*, int): Number of chips in the chain. Must be
|
||||
in range from 1 to 255. Defaults to 2.
|
||||
- **bit_depths** (*Optional*, int): The bit depth to use for all output
|
||||
channels in this chain. Must be one of 8, 12, 14 or 16. Defaults to 16.
|
||||
- **update_on_boot** (*Optional*, boolean): Update/reset duty data at boot. Defaults to ``True``.
|
||||
- **id** (*Optional*, :ref:`config-id`): The id to use for
|
||||
this ``my9231`` component. Use this if you have multiple MY9231/MY9291 chains
|
||||
connected at the same time.
|
||||
|
||||
Sonoff B1 configuration example
|
||||
-------------------------------
|
||||
|
||||
This component can be used with a Sonoff B1 smart light blub. To flash
|
||||
the Sonoff B1, open the plastic cover and connect/solder wires to the
|
||||
PCB pads (3.3V, RX, TX, GND, GPIO0). If you connect GPIO0 to GND
|
||||
during power up, the device enters flash mode. For more information
|
||||
about flashing Sonoff devices, see:
|
||||
:doc:`/devices/sonoff_s20`. All LEDs are connected to a
|
||||
chain of two MY9321 chips that are connected to GPIO12 and GPIO14. A
|
||||
complete configuration for a Sonoff B1 looks like:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
esphome:
|
||||
name: <NAME_OF_NODE>
|
||||
platform: ESP8266
|
||||
board: esp01_1m
|
||||
|
||||
wifi:
|
||||
ssid: <YOUR_SSID>
|
||||
password: <YOUR_WIFI_PASSPHRASE>
|
||||
|
||||
api:
|
||||
|
||||
logger:
|
||||
|
||||
ota:
|
||||
password: <YOUR_OTA_PASSWORD>
|
||||
|
||||
my9231:
|
||||
data_pin: GPIO12 # GPIO13 for AiLight
|
||||
clock_pin: GPIO14 # GPIO15 for AiLight
|
||||
num_channels: 6
|
||||
num_chips: 2
|
||||
|
||||
output:
|
||||
- platform: my9231
|
||||
id: output_blue
|
||||
channel: 0
|
||||
- platform: my9231
|
||||
id: output_red
|
||||
channel: 1
|
||||
- platform: my9231
|
||||
id: output_green
|
||||
channel: 2
|
||||
- platform: my9231
|
||||
id: output_warm_white
|
||||
channel: 4
|
||||
- platform: my9231
|
||||
id: output_cold_white
|
||||
channel: 5
|
||||
|
||||
light:
|
||||
- platform: rgbww
|
||||
name: <LIGHT_NAME>
|
||||
red: output_red
|
||||
green: output_green
|
||||
blue: output_blue
|
||||
cold_white: output_cold_white
|
||||
warm_white: output_warm_white
|
||||
cold_white_color_temperature: 6500 K
|
||||
warm_white_color_temperature: 2800 K
|
||||
|
||||
.. note::
|
||||
|
||||
One of the features of the MY9231/MY9291 driver is that the chips
|
||||
remember their state after a power cycling. Unfortunately, the
|
||||
state of the driver can not be read. Therefore, if ESPHome can
|
||||
not restore the previous state, it will result in a mismatch of
|
||||
the driver output and the internal state (= MQTT state). So you
|
||||
can configure the behaviour on boot time:
|
||||
|
||||
``update_on_boot: True``
|
||||
On device power up/boot, the light may flash shortly, to the
|
||||
state before powering off.
|
||||
|
||||
``update_on_boot: False``
|
||||
On device power up/boot, the light show the last state, but the
|
||||
internal data will not reflect this state. Thus, the first fade
|
||||
is wrong, as well as the MQTT state.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`output/my9231`
|
||||
- :apiref:`output/my9231_output_component.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -36,12 +36,12 @@ Configuration variables:
|
|||
|
||||
.. 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.
|
||||
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.
|
||||
|
||||
Updating the password:
|
||||
----------------------
|
||||
|
|
|
|||
|
|
@ -1,12 +1,31 @@
|
|||
MY9231/MY9291 Output
|
||||
====================
|
||||
MY9231/MY9291 LED driver
|
||||
========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MY931 and MY9231 outputs.
|
||||
:description: Instructions for setting up MY9231 and MY9291 LED drives in ESPHome.
|
||||
:image: my9231.png
|
||||
:keywords: MY9231, MY9291, Sonoff B1, Ai-thinker AiLight WiFi light bulb, Arilux E27 Smart Bulb
|
||||
|
||||
The MY931/MY9291 output component exposes a MY931/MY9291 channel of a global
|
||||
:doc:`/components/my9231` as a float output.
|
||||
.. _my9231-component:
|
||||
|
||||
Component
|
||||
---------
|
||||
|
||||
The MY9231/MY9291 component represents a MY9231/MY9291 LED diver chain
|
||||
(`MY9231 description <http://www.my-semi.com.tw/file/MY9231_BF_0.91.pdf>`__,
|
||||
`MY9291 description <http://www.my-semi.com.tw/file/MY9291_BF_0.91.pdf>`__) in
|
||||
ESPHome. Communication is done with two GPIO pins (DI and DCKI) and multiple
|
||||
driver chips can be chained. There are two models with different number of
|
||||
output channels (MY9291 with 4 channels and MY9231 with 3 channels). They are
|
||||
popular driver chips used in smart light blubs:
|
||||
|
||||
- Sonoff B1 (MY9231)
|
||||
- Ai-Thinker AiLight WiFi light bulb (MY9291)
|
||||
- Arilux E27 Smart Bulb (MY9231)
|
||||
|
||||
To use the channels of this components, you first need to setup the
|
||||
global ``my9231`` hub and give it an id, and then define the
|
||||
:ref:`individual output channels <my9231-output>`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -22,20 +41,140 @@ The MY931/MY9291 output component exposes a MY931/MY9291 channel of a global
|
|||
channel: 0
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **data_pin** (**Required**, :ref:`config-pin_schema`): The pin which DI is connected
|
||||
to.
|
||||
- **clock_pin** (**Required**, :ref:`config-pin_schema`): The pin which DCKI is
|
||||
connected to.
|
||||
- **num_channels** (*Optional*, int): Total number of channels of the whole
|
||||
chain. Must be in range from 3 to 1020. Defaults to 6.
|
||||
- **num_chips** (*Optional*, int): Number of chips in the chain. Must be
|
||||
in range from 1 to 255. Defaults to 2.
|
||||
- **bit_depths** (*Optional*, int): The bit depth to use for all output
|
||||
channels in this chain. Must be one of 8, 12, 14 or 16. Defaults to 16.
|
||||
- **update_on_boot** (*Optional*, boolean): Update/reset duty data at boot. Defaults to ``True``.
|
||||
- **id** (*Optional*, :ref:`config-id`): The id to use for
|
||||
this ``my9231`` component. Use this if you have multiple MY9231/MY9291 chains
|
||||
connected at the same time.
|
||||
|
||||
Sonoff B1 configuration example
|
||||
-------------------------------
|
||||
|
||||
This component can be used with a Sonoff B1 smart light blub. To flash
|
||||
the Sonoff B1, open the plastic cover and connect/solder wires to the
|
||||
PCB pads (3.3V, RX, TX, GND, GPIO0). If you connect GPIO0 to GND
|
||||
during power up, the device enters flash mode. For more information
|
||||
about flashing Sonoff devices, see:
|
||||
:doc:`/devices/sonoff_s20`. All LEDs are connected to a
|
||||
chain of two MY9321 chips that are connected to GPIO12 and GPIO14. A
|
||||
complete configuration for a Sonoff B1 looks like:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
esphome:
|
||||
name: <NAME_OF_NODE>
|
||||
platform: ESP8266
|
||||
board: esp01_1m
|
||||
|
||||
wifi:
|
||||
ssid: <YOUR_SSID>
|
||||
password: <YOUR_WIFI_PASSPHRASE>
|
||||
|
||||
api:
|
||||
|
||||
logger:
|
||||
|
||||
ota:
|
||||
password: <YOUR_OTA_PASSWORD>
|
||||
|
||||
my9231:
|
||||
data_pin: GPIO12 # GPIO13 for AiLight
|
||||
clock_pin: GPIO14 # GPIO15 for AiLight
|
||||
num_channels: 6
|
||||
num_chips: 2
|
||||
|
||||
output:
|
||||
- platform: my9231
|
||||
id: output_blue
|
||||
channel: 0
|
||||
- platform: my9231
|
||||
id: output_red
|
||||
channel: 1
|
||||
- platform: my9231
|
||||
id: output_green
|
||||
channel: 2
|
||||
- platform: my9231
|
||||
id: output_warm_white
|
||||
channel: 4
|
||||
- platform: my9231
|
||||
id: output_cold_white
|
||||
channel: 5
|
||||
|
||||
light:
|
||||
- platform: rgbww
|
||||
name: <LIGHT_NAME>
|
||||
red: output_red
|
||||
green: output_green
|
||||
blue: output_blue
|
||||
cold_white: output_cold_white
|
||||
warm_white: output_warm_white
|
||||
cold_white_color_temperature: 6500 K
|
||||
warm_white_color_temperature: 2800 K
|
||||
|
||||
.. note::
|
||||
|
||||
One of the features of the MY9231/MY9291 driver is that the chips
|
||||
remember their state after a power cycling. Unfortunately, the
|
||||
state of the driver can not be read. Therefore, if ESPHome can
|
||||
not restore the previous state, it will result in a mismatch of
|
||||
the driver output and the internal state (= MQTT state). So you
|
||||
can configure the behaviour on boot time:
|
||||
|
||||
``update_on_boot: True``
|
||||
On device power up/boot, the light may flash shortly, to the
|
||||
state before powering off.
|
||||
|
||||
``update_on_boot: False``
|
||||
On device power up/boot, the light show the last state, but the
|
||||
internal data will not reflect this state. Thus, the first fade
|
||||
is wrong, as well as the MQTT state.
|
||||
|
||||
.. _my9231-output:
|
||||
|
||||
Driver Output
|
||||
-------------
|
||||
|
||||
The MY931/MY9291 output component exposes a MY931/MY9291 channel of a global
|
||||
:ref:`my9231-component` as a float output.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
my9231:
|
||||
- data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: my9231
|
||||
id: 'my9231_output1'
|
||||
channel: 0
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The id to use for this output component.
|
||||
- **channel** (**Required**, int): Chose the channel of the MY9231/MY9291 chain of
|
||||
this output component. Channel 0 is the most close channel.
|
||||
- **my9231_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the
|
||||
:doc:`/components/my9231`.
|
||||
:ref:`my9231-component`.
|
||||
Use this if you have multiple MY9231/MY9291 chains you want to use at the same time.
|
||||
- All other options from :ref:`Output <config-output>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/my9231`
|
||||
- :doc:`/components/output/index`
|
||||
- :doc:`/components/output/esp8266_pwm`
|
||||
- :doc:`/components/output/ledc`
|
||||
|
|
|
|||
|
|
@ -1,12 +1,55 @@
|
|||
PCA9685 PWM Output
|
||||
==================
|
||||
PCA9685
|
||||
=======
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up PCA9685 PWM controller outputs.
|
||||
:description: Instructions for setting up PCA9685 LED PWM drivers.
|
||||
:image: pca9685.jpg
|
||||
:keywords: PCA9685
|
||||
|
||||
.. _pca9685-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The PCA9685 component represents a PCA9685 12-bit PWM driver
|
||||
(`datasheet <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/ledc.html#configure-channel>`__,
|
||||
`adafruit <https://www.adafruit.com/product/815>`__) in ESPHome. It
|
||||
uses :ref:`I²C Bus <i2c>` for communication.
|
||||
|
||||
To use the channels of this components, you first need to setup the
|
||||
global ``pca9685`` hub and give it an id, and then define the
|
||||
:ref:`individual output channels <pca9685-output>`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
pca9685:
|
||||
frequency: 500
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: pca9685
|
||||
pca9685_id: 'pca9685_hub1'
|
||||
channel: 0
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **frequency** (**Required**, float): The frequency to let the
|
||||
component drive all PWM outputs at. Must be in range from 24Hz to
|
||||
1526Hz.
|
||||
- **address** (*Optional*, int): The I²C address of the driver.
|
||||
Defaults to ``0x00``.
|
||||
- **id** (*Optional*, :ref:`config-id`): The id to use for
|
||||
this pca9685 component. Use this if you have multiple PCA9685s connected at the same time
|
||||
|
||||
.. _pca9685-output:
|
||||
|
||||
PWM Output
|
||||
----------
|
||||
|
||||
The PCA9685 output component exposes a PCA9685 PWM channel of a global
|
||||
:doc:`PCA9685 hub </components/pca9685>` as a float
|
||||
:ref:`PCA9685 hub <pca9685-component>` as a float
|
||||
output.
|
||||
|
||||
.. figure:: images/pca9685-full.jpg
|
||||
|
|
@ -28,20 +71,19 @@ output.
|
|||
channel: 0
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **id** (**Required**, :ref:`config-id`): The id to use for this output component.
|
||||
- **channel** (**Required**, int): Chose the channel of the PCA9685 of
|
||||
this output component. Must be in range from 0 to 15.
|
||||
- **pca9685_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the
|
||||
:doc:`PCA9685 hub </components/pca9685>`.
|
||||
:ref:`PCA9685 hub <pca9685-component>`.
|
||||
Use this if you have multiple PCA9685s you want to use at the same time.
|
||||
- All other options from :ref:`Output <config-output>`.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/pca9685`
|
||||
- :doc:`/components/output/index`
|
||||
- :doc:`/components/output/esp8266_pwm`
|
||||
- :doc:`/components/output/ledc`
|
||||
|
|
|
|||
|
|
@ -1,48 +0,0 @@
|
|||
PCA9685 PWM Component
|
||||
=====================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up PCA9685 LED PWM drivers.
|
||||
:image: pca9685.jpg
|
||||
:keywords: PCA9685
|
||||
|
||||
The PCA9685 component represents a PCA9685 12-bit PWM driver
|
||||
(`datasheet <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/ledc.html#configure-channel>`__,
|
||||
`adafruit <https://www.adafruit.com/product/815>`__) in ESPHome. It
|
||||
uses :ref:`I²C Bus <i2c>` for communication.
|
||||
|
||||
To use the channels of this components, you first need to setup the
|
||||
global ``pca9685`` hub and give it an id, and then define the
|
||||
:doc:`individual output channels </components/output/pca9685>`.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
pca9685:
|
||||
frequency: 500
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: pca9685
|
||||
pca9685_id: 'pca9685_hub1'
|
||||
channel: 0
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **frequency** (**Required**, float): The frequency to let the
|
||||
component drive all PWM outputs at. Must be in range from 24Hz to
|
||||
1526Hz.
|
||||
- **address** (*Optional*, int): The I²C address of the driver.
|
||||
Defaults to ``0x00``.
|
||||
- **id** (*Optional*, :ref:`config-id`): The id to use for
|
||||
this pca9685 component. Use this if you have multiple PCA9685s connected at the same time
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`output/pca9685`
|
||||
- :apiref:`output/pca9685_output_component.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -2,7 +2,7 @@ PCF8574 I/O Expander
|
|||
====================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up PCA8574 digital port expanders in ESPHome.
|
||||
:description: Instructions for setting up PCF8574 digital port expanders in ESPHome.
|
||||
:image: pcf8574.jpg
|
||||
:keywords: Xiaomi, Mi Flora, BLE, Bluetooth
|
||||
|
||||
|
|
|
|||
|
|
@ -1,93 +0,0 @@
|
|||
PN532 NFC/RFID Controller Hub
|
||||
=============================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up PN532 NFC tag readers in ESPHome
|
||||
:image: pn532.jpg
|
||||
:keywords: PN532, NFC, RFID
|
||||
|
||||
The ``pn532`` component allows you to use PN532 NFC/RFID controllers
|
||||
(`datasheet <https://cdn-shop.adafruit.com/datasheets/pn532ds.pdf>`__, `adafruit <https://www.adafruit.com/product/364>`__)
|
||||
with ESPHome. This component is a global hub that establishes the connection to the PN532 via :ref:`SPI <spi>` and
|
||||
outputs its data. Using the :doc:`PN532 binary sensors </components/binary_sensor/pn532>` you can then
|
||||
create individual binary sensors that track if an NFC/RFID tag is currently detected by the PN532.
|
||||
|
||||
.. figure:: binary_sensor/images/pn532-full.jpg
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
See :ref:`pn532-setting_up_tags` for information on how to setup individual binary sensors for this component.
|
||||
|
||||
As the communication with the PN532 is done using SPI for this integration, you need to set the two switches on
|
||||
the board to the SPI mode (usually by setting the first one to OFF and the second one to ON). Additionally, you need
|
||||
to have an :ref:`spi bus <spi>` in your configuration with both the **miso_pin** and **mosi_pin** set.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
clk_pin: D0
|
||||
miso_pin: D1
|
||||
mosi_pin: D2
|
||||
|
||||
pn532:
|
||||
cs_pin: D3
|
||||
update_interval: 1s
|
||||
|
||||
binary_sensor:
|
||||
- platform: pn532
|
||||
uid: 74-10-37-94
|
||||
name: "PN532 NFC Tag"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The pin on the ESP that the chip select line
|
||||
is connected to.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The duration of each scan on the PN532. This affects the
|
||||
duration that the individual binary sensors stay active when they're found.
|
||||
If a device is not found within this time window, it will be marked as not present. Defaults to 1s.
|
||||
- **on_tag** (*Optional*, :ref:`Automation <automation>`): An automation to perform
|
||||
when a tag is read. See :ref:`pn532-on_tag`.
|
||||
- **spi_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`SPI Component <spi>` if you want
|
||||
to use multiple SPI buses.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this component.
|
||||
|
||||
.. figure:: binary_sensor/images/pn532-spi.jpg
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
||||
Example for hooking up the PN532 via SPI. Notice the position of the two switches on the right.
|
||||
|
||||
.. _pn532-on_tag:
|
||||
|
||||
``on_tag``
|
||||
----------
|
||||
|
||||
This automation will be triggered when the PN532 module responds with a tag. Please note that this
|
||||
can be called quite often (with an interval of ``update_interval``) as it's triggered repeatedly
|
||||
if the tag is re-read many times.
|
||||
|
||||
The parameter ``x`` this trigger provides is of type ``std::string`` and is the tag UID in the format
|
||||
``74-10-37-94``. The configuration below will for example publish the tag ID on the MQTT topic ``pn532/tag``.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pn532:
|
||||
# ...
|
||||
on_tag:
|
||||
then:
|
||||
- mqtt.publish:
|
||||
topic: pn532/tag
|
||||
payload: !lambda 'return x;'
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`binary_sensor/pn532`
|
||||
- :doc:`rdm6300`
|
||||
- `PN532 Library <https://github.com/adafruit/Adafruit-PN532/blob/master/Adafruit_PN532.cpp>`__ by `Adafruit <https://www.adafruit.com/>`__
|
||||
- :apiref:`binary_sensor/pn532_component.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
RDM6300 NFC/RFID Hub
|
||||
====================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up RDM6300 NFC/RFID tag readers in ESPHome.
|
||||
:image: rdm6300.jpg
|
||||
:keywords: RDM6300, NFC, RFID
|
||||
|
||||
The ``rdm6300`` component allows you to use RDM6300 NFC/RFID controllers
|
||||
(`datasheet <https://elty.pl/upload/download/RFID/RDM630-Spec.pdf>`__, `iTead <https://www.itead.cc/rdm6300.html>`__)
|
||||
with ESPHome. This component is a global hub that establishes the connection to the RDM6300 via :ref:`UART <uart>` and
|
||||
translates the received data. Using the :doc:`RDM6300 binary sensors </components/binary_sensor/rdm6300>` you can then
|
||||
create individual binary sensors that track if an NFC/RFID tag is currently detected by the RDM6300.
|
||||
|
||||
.. figure:: binary_sensor/images/rdm6300-full.jpg
|
||||
:align: center
|
||||
:width: 60.0%
|
||||
|
||||
See :ref:`rdm6300-setting_up_tags` for information on how to setup individual binary sensors for this component.
|
||||
|
||||
As the communication with the RDM6300 is done using UART, you need
|
||||
to have an :ref:`UART bus <uart>` in your configuration with the ``rx_pin`` connected to the data pin of the RDM6300 and
|
||||
with the baud rate set to 9600
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
rx_pin: D0
|
||||
baud_rate: 9600
|
||||
|
||||
rdm6300:
|
||||
|
||||
binary_sensor:
|
||||
- platform: rdm6300
|
||||
uid: 7616525
|
||||
name: "RDM6300 NFC Tag"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
|
||||
to use multiple UART buses.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this component.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`binary_sensor/rdm6300`
|
||||
- :doc:`pn532`
|
||||
- `RDM6300 Arduino Library <https://github.com/arliones/RDM6300-Arduino>`__ by `Arliones Hoeller Jr <https://github.com/arliones>`__
|
||||
- :apiref:`binary_sensor/rdm6300_component.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
Remote Receiver Component
|
||||
=========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up remote receivers in ESPHome.
|
||||
:image: remote.png
|
||||
:keywords: RF, infrared
|
||||
|
||||
The ``remote_receiver`` component lets you receive and decode any remote signal, these can
|
||||
for example be infrared remotes or 433MHz signals.
|
||||
|
||||
The component is split up into two parts: the remote receiver hub which can be used to
|
||||
receive, decode and dump all remote codes, and individual
|
||||
:doc:`remote receiver binary sensors <binary_sensor/remote_receiver>` which will trigger when they
|
||||
hear their own configured signal.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
remote_receiver:
|
||||
pin: GPIO32
|
||||
dump: all
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin to receive the remote signal on.
|
||||
- **dump** (*Optional*, list): Decode and dump these remote codes in the logs. Set to ``all`` to
|
||||
dump all available codecs:
|
||||
|
||||
- **lg**: Decode and dump LG infrared codes.
|
||||
- **nec**: Decode and dump NEC infrared codes.
|
||||
- **panasonic**: Decode and dump Panasonic infrared codes.
|
||||
- **jvc**: Decode and dump JVC infrared codes.
|
||||
- **samsung**: Decode and dump Samsung infrared codes.
|
||||
- **sony**: Decode and dump Sony infrared codes.
|
||||
- **rc_switch**: Decode and dump RCSwitch RF codes.
|
||||
- **rc5**: Decode and dump RC5 IR codes.
|
||||
- **raw**: Print all remote codes in their raw form. Useful for using arbitrary protocols.
|
||||
|
||||
- **tolerance** (*Optional*, int): The percentage that the remote signal lengths can deviate in the
|
||||
decoding process. Defaults to ``25%``.
|
||||
- **buffer_size** (*Optional*, int): The size of the internal buffer for storing the remote codes. Defaults to ``10kb``
|
||||
on the ESP32 and ``1kb`` on the ESP8266.
|
||||
- **filter** (*Optional*, :ref:`time <config-time>`): Filter any pulses that are shorter than this. Useful for removing
|
||||
glitches from noisy signals. Defaults to ``10us``.
|
||||
- **idle** (*Optional*, :ref:`time <config-time>`): The amount of time that a signal should remain stable (i.e. not
|
||||
change) for it to be considered complete. Defaults to ``10ms``.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. Use this if you have
|
||||
multiple remote transmitters.
|
||||
|
||||
.. note::
|
||||
|
||||
See :ref:`finding_remote_codes` for a guide for setting this up.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- `RCSwitch <https://github.com/sui77/rc-switch>`__ by `Suat Özgür <https://github.com/sui77>`__
|
||||
- `IRRemoteESP8266 <https://github.com/markszabo/IRremoteESP8266/>`__ by `Mark Szabo-Simon <https://github.com/markszabo>`__
|
||||
- :apiref:`remote/remote_receiver.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
Remote Transmitter Component
|
||||
============================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up remote transmitters in ESPHome
|
||||
:image: remote.png
|
||||
:keywords: RF, infrared
|
||||
|
||||
The ``remote_transmitter`` component lets you send infrared messages to control
|
||||
devices in your home. First, you need to setup a global hub that specifies which pin your remote
|
||||
sender is connected to. Afterwards you can create :doc:`individual
|
||||
switches </components/switch/remote_transmitter>` that each send a pre-defined remote signal to a device.
|
||||
|
||||
Use-cases are for example infrared remotes or 433MHz signals.
|
||||
|
||||
.. note::
|
||||
|
||||
This component is *much* more accurate on the ESP32, since that chipset has a dedicated
|
||||
peripheral for sending exact signal sequences.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
remote_transmitter:
|
||||
pin: GPIO32
|
||||
carrier_duty_percent: 50%
|
||||
|
||||
# Individual switches
|
||||
switch:
|
||||
- platform: remote_transmitter
|
||||
name: "Panasonic TV Off"
|
||||
panasonic:
|
||||
address: 0x4004
|
||||
command: 0x100BCBD
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin to transmit the remote signal on.
|
||||
- **carrier_duty_percent** (*Optional*, int): How much of the time the remote is on. For example, infrared
|
||||
protocols modulate the signal using a carrier signal. Set this is ``50%`` if you're working with IR leds and to
|
||||
``100%`` if working with a other things like 433MHz transmitters.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify
|
||||
the ID used for code generation. Use this if you have multiple remote transmitters.
|
||||
|
||||
.. note::
|
||||
|
||||
See :ref:`finding_remote_codes` for a guide for setting this up.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- `RCSwitch <https://github.com/sui77/rc-switch>`__ by `Suat Özgür <https://github.com/sui77>`__
|
||||
- `IRRemoteESP8266 <https://github.com/markszabo/IRremoteESP8266/>`__ by `Mark Szabo-Simon <https://github.com/markszabo>`__
|
||||
- :apiref:`remote/remote_transmitter.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
.. disqus::
|
||||
|
|
@ -6,11 +6,14 @@ ADS1115 Sensor
|
|||
:image: ads1115.jpg
|
||||
:keywords: ADS1115
|
||||
|
||||
The ``ads1115`` sensor allows you to use your ADS1115 sigma-delta ADC
|
||||
sensors (`datasheet <http://www.ti.com/lit/ds/symlink/ads1115.pdf>`__, `Adafruit`_) with ESPHome.
|
||||
First, setup a :doc:`ADS1115 Hub </components/ads1115>` for your ADS1115 sensor and then use this
|
||||
sensor platform to create individual sensors that will report the
|
||||
voltage to Home Assistant.
|
||||
.. _ads1115-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``ads1115`` domain creates a global hub so that you can later create
|
||||
individual sensors using the :ref:`ADS1115 Sensor Platform <ads1115-sensor>`.
|
||||
To use this hub, first setup the :ref:`I²C Bus <i2c>` and connect the sensor to the pins specified there.
|
||||
|
||||
.. figure:: images/ads1115-full.jpg
|
||||
:align: center
|
||||
|
|
@ -20,6 +23,46 @@ voltage to Home Assistant.
|
|||
|
||||
.. _Adafruit: https://www.adafruit.com/product/1085
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
ads1115:
|
||||
- address: 0x48
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **address** (**Required**, int): The i²c address of the sensor.
|
||||
See :ref:`I²C Addresses <ads1115_i2c_addresses>` for more information.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this ADS1115 Hub. Use this if you
|
||||
want to use multiple ADS1115 hubs at once.
|
||||
|
||||
.. _ads1115_i2c_addresses:
|
||||
|
||||
I²C Addresses
|
||||
-------------
|
||||
|
||||
In order to allow multiple sensors to be connected to the same i²c bus,
|
||||
the creators of this sensor hardware have included some options to
|
||||
change the i²c address.
|
||||
|
||||
- If the address pin is pulled to GND, the address is ``0x48`` (Default).
|
||||
- If the address pin is pulled to VCC, the address is ``0x49``.
|
||||
- If the address pin is tied to SDA, the address is ``0x4a``.
|
||||
- If the address pin is tied to SCL, the address is ``0x4B``.
|
||||
|
||||
.. _ads1115-sensor:
|
||||
|
||||
Sensor
|
||||
------
|
||||
|
||||
The ``ads1115`` sensor allows you to use your ADS1115 sigma-delta ADC
|
||||
sensors (`datasheet <http://www.ti.com/lit/ds/symlink/ads1115.pdf>`__, `Adafruit`_) with ESPHome.
|
||||
First, setup a :ref:`ADS1115 Hub <ads1115-component>` for your ADS1115 sensor and then use this
|
||||
sensor platform to create individual sensors that will report the
|
||||
voltage to Home Assistant.
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/1085
|
||||
|
||||
.. figure:: images/ads1115-ui.png
|
||||
:align: center
|
||||
:width: 80.0%
|
||||
|
|
@ -35,14 +78,14 @@ voltage to Home Assistant.
|
|||
name: "ADS1115 Channel A0-GND"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **multiplexer** (**Required**): The multiplexer channel of this sensor. Effectively means between which pins you
|
||||
want to measure voltage.
|
||||
- **gain** (**Required**, float): The gain of this sensor.
|
||||
- **name** (**Required**, string): The name for this sensor.
|
||||
- **ads1115_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the
|
||||
:doc:`ADS1115 Hub </components/ads1115>` you want to use this sensor.
|
||||
:ref:`ADS1115 Hub <ads1115-component>` you want to use this sensor.
|
||||
- **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.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,8 @@ 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 one wire protocol.
|
||||
:description: Instructions for setting up dallas temperature sensor hubs that can
|
||||
expose many temperature sensors on a single pin using the one wire protocol.
|
||||
:image: dallas.jpg
|
||||
:keywords: Dallas, ds18b20, onewire
|
||||
|
||||
|
|
@ -148,7 +149,8 @@ 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>`__
|
||||
- `Arduino DallasTemperature library <https://github.com/milesburton/Arduino-Temperature-Control-Library>`__
|
||||
by `Miles Burton <https://github.com/milesburton>`__
|
||||
- :apiref:`sensor/dallas_component.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
|
|
|
|||
|
|
@ -71,9 +71,9 @@ Configuration variables:
|
|||
|
||||
.. note::
|
||||
|
||||
If you're seeing lots of invalid temperature/humidity warnings in the logs, try manually setting the
|
||||
DHT model with the ``model:`` configuration variable. Other problems could be wrong pull-up resistor values
|
||||
on the DATA pin or too long cables.
|
||||
If you're seeing lots of invalid temperature/humidity warnings in the logs, try manually setting the
|
||||
DHT model with the ``model:`` configuration variable. Other problems could be wrong pull-up resistor values
|
||||
on the DATA pin or too long cables.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -7,8 +7,7 @@ HTU21D Temperature+Humidity Sensor
|
|||
:keywords: HTU21D
|
||||
|
||||
The HTU21D Temperature+Humidity sensor allows you to use your HTU21D
|
||||
(`datasheet <https://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Data+Sheet%7FHPC199_6%7FA6%7Fpdf%7FEnglish%7FENG_DS_HPC199_6_A6.pdf%7FCAT-HSC0004>`__,
|
||||
`adafruit <https://www.adafruit.com/product/1899>`__) sensors with
|
||||
(`adafruit <https://www.adafruit.com/product/1899>`__) sensors with
|
||||
ESPHome. The :ref:`I²C Bus <i2c>` is
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,8 +43,7 @@ Configuration variables:
|
|||
- **icon** (*Optional*, icon): Manually set the icon to use for the sensor in the frontend.
|
||||
- **accuracy_decimals** (*Optional*, int): Manually set the accuracy of decimals to use when reporting values.
|
||||
- **filters** (*Optional*): Specify filters to use for some basic
|
||||
transforming of values. Defaults to a basic sliding window moving
|
||||
average over the last few values. See :ref:`Sensor Filters <sensor-filters>` for more information.
|
||||
transforming of values. See :ref:`Sensor Filters <sensor-filters>` for more information.
|
||||
- **internal** (*Optional*, boolean): Mark this component as internal. Internal components will
|
||||
not be exposed to the frontend (like Home Assistant). Only specifying an ``id`` without
|
||||
a ``name`` will implicitly set this to true.
|
||||
|
|
|
|||
|
|
@ -7,8 +7,7 @@ MS5611 Atmospheric Pressure Sensor
|
|||
:keywords: MS5611
|
||||
|
||||
The ``ms5611`` sensor platform allows you to use your MS5611 atmospheric pressure sensors
|
||||
(`datasheet <https://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Data+Sheet%7FMS5611-01BA03%7FB3%7Fpdf%7FEnglish%7FENG_DS_MS5611-01BA03_B3.pdf%7FCAT-BLPS0036>`__,
|
||||
`hobbytronics`_) temperature and pressure sensors with ESPHome. The :ref:`I²C <i2c>` is
|
||||
(`hobbytronics`_) temperature and pressure sensors with ESPHome. The :ref:`I²C <i2c>` is
|
||||
required to be set up in your configuration for this sensor to work.
|
||||
|
||||
.. figure:: images/ms5611-full.jpg
|
||||
|
|
|
|||
|
|
@ -91,7 +91,8 @@ See Also
|
|||
- :doc:`/components/sensor/xiaomi_miflora`
|
||||
- :doc:`/components/sensor/index`
|
||||
- :apiref:`esp32_ble_tracker.h`
|
||||
- `Xiaomi Mijia BLE protocol <https://github.com/mspider65/Xiaomi-Mijia-Bluetooth-Temperature-and-Humidity-Sensor>`__ by `@mspider65 <https://github.com/mspider65>`__
|
||||
- `Xiaomi Mijia BLE protocol <https://github.com/mspider65/Xiaomi-Mijia-Bluetooth-Temperature-and-Humidity-Sensor>`__
|
||||
by `@mspider65 <https://github.com/mspider65>`__
|
||||
- `OpenMQTTGateway <https://github.com/1technophile/OpenMQTTGateway>`__ by `@1technophile <https://github.com/1technophile>`__
|
||||
- :ghedit:`Edit`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,65 @@
|
|||
Remote Transmitter Switch
|
||||
=========================
|
||||
Remote Transmitter
|
||||
==================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up switches that send out pre-defined sequences of IR or RF signals
|
||||
:image: remote.png
|
||||
:keywords: Infrared, IR, RF, Remote, TX
|
||||
|
||||
.. _remote-transmitter-component:
|
||||
|
||||
Component/Hub
|
||||
-------------
|
||||
|
||||
The ``remote_transmitter`` component lets you send infrared messages to control
|
||||
devices in your home. First, you need to setup a global hub that specifies which pin your remote
|
||||
sender is connected to. Afterwards you can create :ref:`individual
|
||||
switches <remote-transmitter-switch>` that each send a pre-defined remote signal to a device.
|
||||
|
||||
Use-cases are for example infrared remotes or 433MHz signals.
|
||||
|
||||
.. note::
|
||||
|
||||
This component is *much* more accurate on the ESP32, since that chipset has a dedicated
|
||||
peripheral for sending exact signal sequences.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
remote_transmitter:
|
||||
pin: GPIO32
|
||||
carrier_duty_percent: 50%
|
||||
|
||||
# Individual switches
|
||||
switch:
|
||||
- platform: remote_transmitter
|
||||
name: "Panasonic TV Off"
|
||||
panasonic:
|
||||
address: 0x4004
|
||||
command: 0x100BCBD
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin to transmit the remote signal on.
|
||||
- **carrier_duty_percent** (*Optional*, int): How much of the time the remote is on. For example, infrared
|
||||
protocols modulate the signal using a carrier signal. Set this is ``50%`` if you're working with IR leds and to
|
||||
``100%`` if working with a other things like 433MHz transmitters.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify
|
||||
the ID used for code generation. Use this if you have multiple remote transmitters.
|
||||
|
||||
.. note::
|
||||
|
||||
See :ref:`finding_remote_codes` for a guide for setting this up.
|
||||
|
||||
.. _remote-transmitter-switch:
|
||||
|
||||
Switch
|
||||
------
|
||||
|
||||
The ``remote_transmitter`` switch platform allows you to create switches
|
||||
that send a pre-defined remote control sequence
|
||||
using the :doc:`/components/remote_transmitter`. Every time
|
||||
using the :ref:`remote-transmitter-component`. Every time
|
||||
the switch is turned on, the configured remote signal is sent.
|
||||
|
||||
Use cases include, but are not limited to, infrared remotes, 433MHz signals and so on.
|
||||
|
|
@ -33,7 +84,7 @@ Use cases include, but are not limited to, infrared remotes, 433MHz signals and
|
|||
repeat: 25
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
************************
|
||||
|
||||
- **name** (**Required**, string): The name for the switch.
|
||||
- The remote code, see :ref:`remote_transmitter-codes`. Only one
|
||||
|
|
@ -43,7 +94,7 @@ Configuration variables:
|
|||
- **times** (int): The number of times the code should be sent. Defaults to ``1``.
|
||||
- **wait_time** (:ref:`time <config-time>`): The time to wait between repeats.
|
||||
|
||||
- **remote_transmitter_id** (*Optional*, :ref:`config-id`): The id of the :doc:`/components/remote_transmitter`.
|
||||
- **remote_transmitter_id** (*Optional*, :ref:`config-id`): The id of the :ref:`remote-transmitter-component`.
|
||||
Defaults to the first hub specified.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Switch <config-switch>`.
|
||||
|
|
@ -68,7 +119,7 @@ Configuration variables:
|
|||
.. _remote_transmitter-codes:
|
||||
|
||||
Remote Codes
|
||||
------------
|
||||
************
|
||||
|
||||
Supported remote codes:
|
||||
|
||||
|
|
@ -164,14 +215,17 @@ Configuration variables:
|
|||
Must be a string of 0s and 1s. For example ``'11001``.
|
||||
- **device** (**Required**, string): The device within the group, usually the state of the last 5 DIP switches.
|
||||
Must be a string of 0s and 1s. For example ``'01000``.
|
||||
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch is triggered. See :ref:`remote_transmitter-on_off_template`.
|
||||
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch
|
||||
is triggered. See :ref:`remote_transmitter-on_off_template`.
|
||||
- **protocol** (*Optional*, :ref:`RCSwitch protocol <rc_switch-protocol>`): The RCSwitch protocol to use. Defaults to ``1``.
|
||||
|
||||
- **rc_switch_type_b**: Send an RCSwitch `type B code <https://github.com/sui77/rc-switch/wiki/HowTo_OperateLowCostOutlets#type-b-two-rotarysliding-switches>`__.
|
||||
- **rc_switch_type_b**: Send an RCSwitch
|
||||
`type B code <https://github.com/sui77/rc-switch/wiki/HowTo_OperateLowCostOutlets#type-b-two-rotarysliding-switches>`__.
|
||||
|
||||
- **address** (**Required**, int): The number of the first rotary switch. For example ``4``.
|
||||
- **channel** (**Required**, int): The number of the first rotary switch. For example ``2``.
|
||||
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch is triggered. See :ref:`remote_transmitter-on_off_template`.
|
||||
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch
|
||||
is triggered. See :ref:`remote_transmitter-on_off_template`.
|
||||
- **protocol** (*Optional*, :ref:`RCSwitch protocol <rc_switch-protocol>`): The RCSwitch protocol to use. Defaults to ``1``.
|
||||
|
||||
- **rc_switch_type_c**: Send an RCSwitch `type C code <https://github.com/sui77/rc-switch/wiki/HowTo_OperateLowCostOutlets#type-c-intertechno>`__.
|
||||
|
|
@ -179,14 +233,16 @@ Configuration variables:
|
|||
- **family** (**Required**, string): The family of the device. Must be a character from ``a`` to ``p``.
|
||||
- **group** (**Required**, int): The group of the device. For example ``4``.
|
||||
- **address** (**Required**, int): The address of the device. For example ``2``.
|
||||
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch is triggered. See :ref:`remote_transmitter-on_off_template`.
|
||||
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch
|
||||
is triggered. See :ref:`remote_transmitter-on_off_template`.
|
||||
- **protocol** (*Optional*, :ref:`RCSwitch protocol <rc_switch-protocol>`): The RCSwitch protocol to use. Defaults to ``1``.
|
||||
|
||||
- **rc_switch_type_d**: Send an RCSwitch type D code.
|
||||
|
||||
- **group** (**Required**, string): The group of the device. Must be a character from ``a`` to ``d``.
|
||||
- **device** (**Required**, int): The address of the device. For example ``3``.
|
||||
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch is triggered. See :ref:`remote_transmitter-on_off_template`.
|
||||
- **state** (**Required**, boolean): Whether to send a "turn on" or "turn off" signal when this switch
|
||||
is triggered. See :ref:`remote_transmitter-on_off_template`.
|
||||
- **protocol** (*Optional*, :ref:`RCSwitch protocol <rc_switch-protocol>`): The RCSwitch protocol to use. Defaults to ``1``.
|
||||
|
||||
- **rc5**: Send a RC5 IR code.
|
||||
|
|
@ -210,7 +266,7 @@ Finding Remote Codes
|
|||
|
||||
Each remote transmitter uses a different protocol to send its information. So to replicate an infrared or 433MHz
|
||||
remote you will first need to "learn" these codes. You will first need to hook up a receiver and sniff the codes
|
||||
using the :doc:`remote receiver component </components/remote_receiver>` like this:
|
||||
using the :doc:`remote receiver component </components/binary_sensor/remote_receiver>` like this:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -240,9 +296,9 @@ Now you only need to set up the remote transmitter (which well *send* the code)
|
|||
.. code-block:: yaml
|
||||
|
||||
remote_transmitter:
|
||||
pin: GPIO23
|
||||
# Set to 100% when working with RF signals, and 50% if working with IR leds
|
||||
carrier_duty_percent: 100%
|
||||
pin: GPIO23
|
||||
# Set to 100% when working with RF signals, and 50% if working with IR leds
|
||||
carrier_duty_percent: 100%
|
||||
|
||||
And lastly, we need to set up the switch that, when turned on, will send our pre-defined remote code:
|
||||
|
||||
|
|
@ -370,8 +426,7 @@ See Also
|
|||
--------
|
||||
|
||||
- :doc:`index`
|
||||
- :doc:`/components/remote_transmitter`
|
||||
- :doc:`/components/remote_receiver`
|
||||
- :doc:`/components/binary_sensor/remote_receiver`
|
||||
- `RCSwitch <https://github.com/sui77/rc-switch>`__ by `Suat Özgür <https://github.com/sui77>`__
|
||||
- `IRRemoteESP8266 <https://github.com/markszabo/IRremoteESP8266/>`__ by `Mark Szabo-Simon <https://github.com/markszabo>`__
|
||||
- :apiref:`remote/remote_transmitter.h`
|
||||
|
|
|
|||
|
|
@ -51,7 +51,9 @@ Configuration variables:
|
|||
|
||||
- **id** (*Optional*, :ref:`config-id`): Specify the ID of the time for use in lambdas.
|
||||
- **timezone** (*Optional*, string): Manually tell ESPHome what timezone to use with `this format
|
||||
<https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html>`__ (warning: the format is quite complicated) or the simpler `TZ database name <https://en.wikipedia.org/wiki/List_of_tz_database_time_zones>`__ in the form <Region>/<City>.
|
||||
<https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html>`__ (warning: the
|
||||
format is quite complicated) or the simpler `TZ database name <https://en.wikipedia.org/wiki/List_of_tz_database_time_zones>`__
|
||||
in the form <Region>/<City>.
|
||||
ESPHome tries to automatically infer the timezone string based on the timezone of the computer that is running
|
||||
ESPHome, but this might not always be accurate.
|
||||
- **servers** (*Optional*, list of strings): Choose up to 3 NTP servers that are used for the clock source.
|
||||
|
|
|
|||
2
conf.py
2
conf.py
|
|
@ -73,7 +73,7 @@ author = 'Otto Winter'
|
|||
# The short X.Y version.
|
||||
version = '1.11'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = '1.11.1'
|
||||
release = '1.11.2'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,8 @@ BME280 Environment
|
|||
|
||||
The :doc:`/components/sensor/bme280` is a simple temperature, humidity, and pressure sensor with communication over I2C.
|
||||
With some simple math it is possible to either determine the height of the sensor, or the current pressure at sea level.
|
||||
This guide can be applied to any sensor measuring temperature and pressure at the same time, like the :doc:`/components/sensor/bmp280`, or :doc:`/components/sensor/bme680`.
|
||||
This guide can be applied to any sensor measuring temperature and pressure at the same time, like the
|
||||
:doc:`/components/sensor/bmp280`, or :doc:`/components/sensor/bme680`.
|
||||
|
||||
.. figure:: images/bme280-header.jpg
|
||||
:align: center
|
||||
|
|
@ -36,30 +37,38 @@ After validating the sensor is working, we can proceed and add some formulas.
|
|||
name: "Altitude"
|
||||
lambda: |-
|
||||
const float STANDARD_SEA_LEVEL_PRESSURE = 1013.25; //in hPa, see note
|
||||
return ((id(bme280_temperature).state + 273.15) / 0.0065) * (powf((STANDARD_SEA_LEVEL_PRESSURE / id(bme280_pressure).state), 0.190234) - 1); // in meter
|
||||
return ((id(bme280_temperature).state + 273.15) / 0.0065) *
|
||||
(powf((STANDARD_SEA_LEVEL_PRESSURE / id(bme280_pressure).state), 0.190234) - 1); // in meter
|
||||
update_interval: 15s
|
||||
- platform: template
|
||||
name: "Absolute Humidity"
|
||||
lambda: |-
|
||||
const float mw = 18.01534; // molar mass of water g/mol
|
||||
const float r = 8.31447215; // Universal gas constant J/mol/K
|
||||
return (6.112 * powf(2.718281828, (17.67 * id(bme280_temperature).state) / (id(bme280_temperature).state + 243.5)) * id(bme280_humidity).state * mw) / ((273.15 + id(bme280_temperature).state) * r); // in grams/m^3
|
||||
return (6.112 * powf(2.718281828, (17.67 * id(bme280_temperature).state) /
|
||||
(id(bme280_temperature).state + 243.5)) * id(bme280_humidity).state * mw) /
|
||||
((273.15 + id(bme280_temperature).state) * r); // in grams/m^3
|
||||
update_interval: 15s
|
||||
|
||||
Altitude and absolute humidity:
|
||||
-------------------------------
|
||||
|
||||
The first block ``sensor`` starts with the normal bme280 sensor components ``temperature``, ``pressure``, and ``humidity`` with each their own id.
|
||||
The first block ``sensor`` starts with the normal bme280 sensor components ``temperature``, ``pressure``,
|
||||
and ``humidity`` with each their own id.
|
||||
After the bme280 sensor, a :doc:`/components/sensor/template` is defined to calculate the altitude in a lambda.
|
||||
The variable ``STANDARD_SEA_LEVEL_PRESSURE`` (in hPa), should be filled in for your location.
|
||||
The formula derived from `here <https://github.com/finitespace/BME280/blob/master/src/EnvironmentCalculations.cpp>`, converts the currently measured pressure to the altitudes in meters including temperature compensation.
|
||||
The formula derived from `here <https://github.com/finitespace/BME280/blob/master/src/EnvironmentCalculations.cpp>`__,
|
||||
converts the currently measured pressure to the altitudes in meters including temperature compensation.
|
||||
|
||||
The lambda in the second :doc:`/components/sensor/template` defines two physical constants and converts the currently measured pressure to absolute humidity (grams/m^3).
|
||||
The lambda in the second :doc:`/components/sensor/template` defines two physical constants and
|
||||
converts the currently measured pressure to absolute humidity (grams/m^3).
|
||||
|
||||
.. note::
|
||||
|
||||
Calculating the altitude with the BME280 sensor accurately requires this value to be known at sea level for your location and day.
|
||||
This can be achieved by replacing the global constant ``STANDARD_SEA_LEVEL_PRESSURE`` by for example pulling this value live from the internet or a stationary sensor via MQTT.
|
||||
|
||||
This can be achieved by replacing the global constant ``STANDARD_SEA_LEVEL_PRESSURE`` by for example
|
||||
pulling this value live from the internet or a stationary sensor via MQTT.
|
||||
|
||||
Equivalent sea level pressure:
|
||||
------------------------------
|
||||
|
|
@ -85,7 +94,8 @@ Calculating the sea level pressure with a statically mounted sensor can be be us
|
|||
name: "Equivalent sea level pressure"
|
||||
lambda: |-
|
||||
const float STANDARD_ALTITUDE = 0.6; // in meters, see note
|
||||
return id(bme280_pressure).state / powf(1 - ((0.0065 * STANDARD_ALTITUDE) / (id(bme280_temperature).state + (0.0065 * STANDARD_ALTITUDE) + 273.15)), 5.257); // in hPa
|
||||
return id(bme280_pressure).state / powf(1 - ((0.0065 * STANDARD_ALTITUDE) /
|
||||
(id(bme280_temperature).state + (0.0065 * STANDARD_ALTITUDE) + 273.15)), 5.257); // in hPa
|
||||
update_interval: 15s
|
||||
|
||||
.. note::
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 4.7 KiB After Width: | Height: | Size: 4.7 KiB |
|
|
@ -10,7 +10,8 @@ Time & Temperature on OLED Display
|
|||
:align: left
|
||||
:width: 75.0%
|
||||
|
||||
In this example I have used a :doc:`SSD1306 OLED Display over I²C </components/display/ssd1306_i2c>` to show current time and two different temperature values from Home Assistant.
|
||||
In this example I have used a :doc:`SSD1306 OLED Display over I²C </components/display/ssd1306>` to
|
||||
show current time and two different temperature values from Home Assistant.
|
||||
|
||||
ESPHome has support for several different types of displays. The display used here is 1.3" with 128x64 monochrome pixels (``SH1106 128x64``).
|
||||
|
||||
|
|
@ -45,7 +46,7 @@ Get the time from Home Assistant to sync the onboard real-time-clock.
|
|||
Getting Temperature
|
||||
*******************
|
||||
|
||||
Next, we want to get two temperature sensors imported from Home Assistant.
|
||||
Next, we want to get two temperature sensors imported from Home Assistant.
|
||||
|
||||
I named them ``inside_temperature`` and ``outside_temperature``. You will use those references later.
|
||||
|
||||
|
|
@ -56,7 +57,7 @@ By adding ``internal: true`` to the sensors they won't be published back to Home
|
|||
sensor:
|
||||
- platform: homeassistant
|
||||
id: inside_temperature
|
||||
entity_id: sensor.mellanvaning_temperature
|
||||
entity_id: sensor.mellanvaning_temperature
|
||||
internal: true
|
||||
|
||||
- platform: homeassistant
|
||||
|
|
@ -68,8 +69,8 @@ Define the Fonts
|
|||
****************
|
||||
|
||||
- TrueType fonts are used. If you ever worked with fonts on microcontrollers you will love this!
|
||||
- Save font files in ``/config/esphome`` folder where your esphome configuration is stored.
|
||||
- The ``.ttf`` suffix must be lowercase and of course match your filename.
|
||||
- Save font files in ``/config/esphome`` folder where your esphome configuration is stored.
|
||||
- The ``.ttf`` suffix must be lowercase and of course match your filename.
|
||||
- Selection of fonts can be a little bit tricky for small sizes to look good. Experiment and share your findings in the comments below!
|
||||
|
||||
.. code-block:: yaml
|
||||
|
|
@ -90,7 +91,7 @@ Define the Fonts
|
|||
Display Definition
|
||||
******************
|
||||
|
||||
Now setup the communication to the display and start fill the screen with live data!
|
||||
Now setup the communication to the display and start fill the screen with live data!
|
||||
|
||||
The ``reset_pin`` was not used in my hardware configuration as the display didn't had that pin exposed.
|
||||
|
||||
|
|
@ -113,16 +114,16 @@ Note your ``address`` and ``model`` might be different, use the scan option to f
|
|||
it.printf(64, 0, id(font1), TextAlign::TOP_CENTER, "Mitt Smarta Hus");
|
||||
|
||||
// Print time in HH:MM format
|
||||
it.strftime(0, 60, id(font2), TextAlign::BASELINE_LEFT, "%H:%M", id(time).now());
|
||||
it.strftime(0, 60, id(font2), TextAlign::BASELINE_LEFT, "%H:%M", id(time).now());
|
||||
|
||||
// Print inside temperature (from homeassistant sensor)
|
||||
if (id(inside_temperature).has_state()) {
|
||||
if (id(inside_temperature).has_state()) {
|
||||
it.printf(127, 23, id(font3), TextAlign::TOP_RIGHT , "%.1f°", id(inside_temperature).state);
|
||||
}
|
||||
}
|
||||
|
||||
// Print outside temperature (from homeassistant sensor)
|
||||
if (id(outside_temperature).has_state()) {
|
||||
it.printf(127, 60, id(font3), TextAlign::BASELINE_RIGHT , "%.1f°", id(outside_temperature).state);
|
||||
if (id(outside_temperature).has_state()) {
|
||||
it.printf(127, 60, id(font3), TextAlign::BASELINE_RIGHT , "%.1f°", id(outside_temperature).state);
|
||||
}
|
||||
|
||||
Rendering
|
||||
|
|
@ -135,7 +136,7 @@ Rendering
|
|||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/display/ssd1306_i2c`
|
||||
- :doc:`/components/display/ssd1306`
|
||||
- :doc:`/components/display/index`
|
||||
- :doc:`/components/sensor/homeassistant`
|
||||
- :ghedit:`Edit`
|
||||
|
|
|
|||
|
|
@ -30,22 +30,22 @@ for some motors.
|
|||
|
||||
.. code-block:: yaml
|
||||
|
||||
esphome:
|
||||
esphome:
|
||||
name: cover
|
||||
platform: ESP8266
|
||||
board: esp01_1m
|
||||
|
||||
wifi:
|
||||
wifi:
|
||||
ssid: '***'
|
||||
password: '***'
|
||||
|
||||
api:
|
||||
api:
|
||||
|
||||
logger:
|
||||
logger:
|
||||
|
||||
ota:
|
||||
ota:
|
||||
|
||||
binary_sensor:
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
pin:
|
||||
number: 10
|
||||
|
|
@ -73,7 +73,7 @@ for some motors.
|
|||
}
|
||||
}
|
||||
|
||||
switch:
|
||||
switch:
|
||||
- platform: gpio
|
||||
pin: 12
|
||||
id: open
|
||||
|
|
@ -81,7 +81,7 @@ for some motors.
|
|||
pin: 5
|
||||
id: close
|
||||
|
||||
cover:
|
||||
cover:
|
||||
- platform: template
|
||||
name: "Cover"
|
||||
id: cover
|
||||
|
|
|
|||
|
|
@ -2,7 +2,8 @@ H801 RGBW LED controller
|
|||
========================
|
||||
|
||||
The H801 is pretty afordable and easy to hack and adapt to your needs. It can be found on `Aliexpress <https://s.click.aliexpress.com/e/bbnUDBZW>`__
|
||||
`Here <http://tinkerman.cat/closer-look-h801-led-wifi-controller/>`__ is an article about the hardware for those who have an interest for more details about the board.
|
||||
`Here <http://tinkerman.cat/closer-look-h801-led-wifi-controller/>`__ is an article about the
|
||||
hardware for those who have an interest for more details about the board.
|
||||
It can be used as a RGB, RGBW, RGB dual white or even control 5 individual monochromatic strips if you want or combinations of these.
|
||||
|
||||
.. figure:: images/h801.jpg
|
||||
|
|
@ -21,7 +22,7 @@ and the :doc:`ESP8266 Software PWM output </components/output/esp8266_pwm>` comp
|
|||
wifi:
|
||||
ssid: 'WIFI'
|
||||
password: 'WIFIPASS'
|
||||
manual_ip:
|
||||
manual_ip:
|
||||
static_ip: x.x.x.x
|
||||
gateway: x.x.x.x
|
||||
subnet: 255.255.255.0
|
||||
|
|
@ -37,15 +38,15 @@ and the :doc:`ESP8266 Software PWM output </components/output/esp8266_pwm>` comp
|
|||
- platform: esp8266_pwm
|
||||
pin: 12
|
||||
frequency: 1000 Hz
|
||||
id: pwm_b
|
||||
id: pwm_b
|
||||
- platform: esp8266_pwm
|
||||
pin: 15
|
||||
frequency: 1000 Hz
|
||||
id: pwm_g
|
||||
id: pwm_g
|
||||
- platform: esp8266_pwm
|
||||
pin: 13
|
||||
frequency: 1000 Hz
|
||||
id: pwm_r
|
||||
id: pwm_r
|
||||
- platform: esp8266_pwm
|
||||
pin: 14
|
||||
frequency: 1000 Hz
|
||||
|
|
@ -87,10 +88,12 @@ This LED strip can be used with the sketch as-is
|
|||
|
||||
For this type of led strip you have to swap the white and blue gpio numbers in the sketch
|
||||
|
||||
You will need to solder pins to the board inside the h801 (fortunately its pretty roomy and not a lot of components or stuff in the way part from the 2 wires on the back)
|
||||
You will need to solder pins to the board inside the h801 (fortunately its pretty roomy and
|
||||
not a lot of components or stuff in the way part from the 2 wires on the back)
|
||||
|
||||
3.3v, GND, TX and RX (RX to RX and TX to TX) needs to be connected to your serial adapter, the two other pins must be shorted by a jumper or a breadboard cable when flashing.
|
||||
(Remember to remove it after flashing)
|
||||
3.3v, GND, TX and RX (RX to RX and TX to TX) needs to be connected to your serial adapter, the
|
||||
two other pins must be shorted by a jumper or a breadboard cable when flashing.
|
||||
(Remember to remove it after flashing)
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ As many of the details on here a predicated on existing installations and knowle
|
|||
* You have installed the relevant environment and it is functional (Home Assisant, ESPHome).
|
||||
* You need to create your own secrets.yaml file.
|
||||
* You are proficient in reading instructions and capable of using a search engine.
|
||||
* You will look at the documentation on https://esphome.io/ (we may have missed something in this example).
|
||||
* You will look at the documentation on this website (we may have missed something in this example).
|
||||
* This serves only as a guide and errors and outlets are excluded.
|
||||
|
||||
.. warning::
|
||||
|
|
@ -137,6 +137,7 @@ Here is the configuration with the basic operations outlined above.
|
|||
|
||||
2. Programming
|
||||
**************
|
||||
|
||||
Follow the standard way of uploading to your Sonoff basic.
|
||||
|
||||
.. figure:: images/sonoff-fishpond-pump-1-programming.jpg
|
||||
|
|
@ -165,7 +166,7 @@ Both options USB and OTA are done by running the command:
|
|||
More details on programming can be found on :doc:`/devices/sonoff_basic`
|
||||
|
||||
3. Prepping and installing
|
||||
****************************
|
||||
**************************
|
||||
|
||||
* Ensure power is switched off.
|
||||
* You can now add your water level sensor wiring to the PCB and have it extrude, SAFELY, next to your connector block.
|
||||
|
|
|
|||
|
|
@ -145,7 +145,8 @@ Reset Causes
|
|||
------------
|
||||
|
||||
Additionally, the first line also contains the **reset cause**.
|
||||
These reset causes `are documented <https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf>`__:
|
||||
These reset causes `are documented
|
||||
<https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf>`__:
|
||||
|
||||
== ===================================
|
||||
0 Undefined
|
||||
|
|
|
|||
|
|
@ -192,7 +192,7 @@ Same configuration as the :doc:`Sonoff 4CH <sonoff_4ch>`.
|
|||
Sonoff B1, Ai-Thinker AiLight
|
||||
-----------------------------
|
||||
|
||||
See :doc:`/components/my9231`.
|
||||
See :doc:`/components/output/my9231`.
|
||||
|
||||
Sonoff T1 1CH, 2CH, 3CH
|
||||
-----------------------
|
||||
|
|
|
|||
|
|
@ -116,7 +116,8 @@ See https://randomnerdtutorials.com/how-to-flash-a-custom-firmware-to-sonoff/ fo
|
|||
|
||||
* Press and hold the toggle pin (long black pin next to LED and custom soldered pins).
|
||||
* Supply USB power to Sonoff via FTDI (e.g. plug in USB to the FTDI, or use a power switch as explained in link above).
|
||||
* Keep holding the toggle pin for approx 3-5 seconds now you should be ready to program. If you get a message unable to communicate when trying flash, check your TX/RX pin or retry entering boot mode again.
|
||||
* Keep holding the toggle pin for approx 3-5 seconds now you should be ready to program.
|
||||
If you get a message unable to communicate when trying flash, check your TX/RX pin or retry entering boot mode again.
|
||||
|
||||
Quick notes:
|
||||
|
||||
|
|
@ -140,58 +141,59 @@ You should get an output starting like this
|
|||
|
||||
.. code-block:: text
|
||||
|
||||
INFO Reading configuration...
|
||||
INFO Detected timezone 'SAST' with UTC offset 2
|
||||
INFO Generating C++ source...
|
||||
INFO Compiling app...
|
||||
INFO Running: platformio run -d fishpond
|
||||
********************************************************************************************************
|
||||
Obsolete PIO Core v3.6.3 is used (previous was 3.6.4b1)
|
||||
Please remove multiple PIO Cores from a system:
|
||||
https://docs.platformio.org/page/faq.html#multiple-pio-cores-in-a-system
|
||||
...
|
||||
lots of compile stuff
|
||||
...
|
||||
Memory Usage -> http://bit.ly/pio-memory-usage
|
||||
DATA: [====== ] 55.6% (used 45512 bytes from 81920 bytes)
|
||||
PROGRAM: [==== ] 38.1% (used 390576 bytes from 1023984 bytes)
|
||||
===================================== [SUCCESS] Took 4.70 seconds =====================================
|
||||
INFO Successfully compiled program.
|
||||
Found multiple options, please choose one:
|
||||
INFO Reading configuration...
|
||||
INFO Detected timezone 'SAST' with UTC offset 2
|
||||
INFO Generating C++ source...
|
||||
INFO Compiling app...
|
||||
INFO Running: platformio run -d fishpond
|
||||
********************************************************************************************************
|
||||
Obsolete PIO Core v3.6.3 is used (previous was 3.6.4b1)
|
||||
Please remove multiple PIO Cores from a system:
|
||||
https://docs.platformio.org/page/faq.html#multiple-pio-cores-in-a-system
|
||||
...
|
||||
lots of compile stuff
|
||||
...
|
||||
Memory Usage -> http://bit.ly/pio-memory-usage
|
||||
DATA: [====== ] 55.6% (used 45512 bytes from 81920 bytes)
|
||||
PROGRAM: [==== ] 38.1% (used 390576 bytes from 1023984 bytes)
|
||||
===================================== [SUCCESS] Took 4.70 seconds =====================================
|
||||
INFO Successfully compiled program.
|
||||
Found multiple options, please choose one:
|
||||
[1] /dev/ttyUSB0 (FT232R USB UART)
|
||||
[2] Over The Air (fishpond.device)
|
||||
(number): 1
|
||||
INFO Running: esptool.py --before default_reset --after hard_reset --chip esp8266 --port /dev/ttyUSB0 write_flash 0x0 fishpond/.pioenvs/fishpond/firmware.bin
|
||||
esptool.py v2.6
|
||||
Serial port /dev/ttyUSB0
|
||||
Connecting....
|
||||
Chip is ESP8266EX
|
||||
Features: WiFi
|
||||
MAC: xx:xx:xx:xx:xx:xx
|
||||
Uploading stub...
|
||||
Running stub...
|
||||
Stub running...
|
||||
Configuring flash size...
|
||||
Auto-detected Flash size: 1MB
|
||||
Compressed 394720 bytes to 267991...
|
||||
Wrote 394720 bytes (267991 compressed) at 0x00000000 in 23.8 seconds (effective 132.7 kbit/s)...
|
||||
Hash of data verified.
|
||||
(number): 1
|
||||
...
|
||||
esptool.py v2.6
|
||||
Serial port /dev/ttyUSB0
|
||||
Connecting....
|
||||
Chip is ESP8266EX
|
||||
Features: WiFi
|
||||
MAC: xx:xx:xx:xx:xx:xx
|
||||
Uploading stub...
|
||||
Running stub...
|
||||
Stub running...
|
||||
Configuring flash size...
|
||||
Auto-detected Flash size: 1MB
|
||||
Compressed 394720 bytes to 267991...
|
||||
Wrote 394720 bytes (267991 compressed) at 0x00000000 in 23.8 seconds (effective 132.7 kbit/s)...
|
||||
Hash of data verified.
|
||||
|
||||
Leaving...
|
||||
Hard resetting via RTS pin...
|
||||
INFO Successfully uploaded program.
|
||||
INFO Starting log output from /dev/ttyUSB0 with baud rate 115200
|
||||
Leaving...
|
||||
Hard resetting via RTS pin...
|
||||
INFO Successfully uploaded program.
|
||||
INFO Starting log output from /dev/ttyUSB0 with baud rate 115200
|
||||
|
||||
1.3. And then nothing will happen
|
||||
*********************************
|
||||
|
||||
Once you have flashed the device, nothing will happen. You need to power cycle the device. You will notice the LED will start to flash and then becomes solid once connected to the WiFi network.
|
||||
Once you have flashed the device, nothing will happen. You need to power cycle the device.
|
||||
You will notice the LED will start to flash and then becomes solid once connected to the WiFi network.
|
||||
|
||||
You can follow the logs produced by the running module by running the command
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
esphome <my-awesome>.yaml logs
|
||||
esphome <my-awesome>.yaml logs
|
||||
|
||||
Your output will possibly look like this
|
||||
|
||||
|
|
|
|||
|
|
@ -313,8 +313,10 @@ All Triggers
|
|||
|
||||
- :ref:`mqtt.on_message <mqtt-on_message>` / :ref:`mqtt.on_json_message <mqtt-on_json_message>`
|
||||
- :ref:`sensor.on_value <sensor-on_value>` / :ref:`sensor.on_raw_value <sensor-on_raw_value>` / :ref:`sensor.on_value_range <sensor-on_value_range>`
|
||||
- :ref:`binary_sensor.on_press <binary_sensor-on_press>` / :ref:`binary_sensor.on_release <binary_sensor-on_release>` / :ref:`binary_sensor.on_state <binary_sensor-on_state>`
|
||||
- :ref:`binary_sensor.on_click <binary_sensor-on_click>` / :ref:`binary_sensor.on_double_click <binary_sensor-on_double_click>` / :ref:`binary_sensor.on_multi_click <binary_sensor-on_multi_click>`
|
||||
- :ref:`binary_sensor.on_press <binary_sensor-on_press>` / :ref:`binary_sensor.on_release <binary_sensor-on_release>` /
|
||||
:ref:`binary_sensor.on_state <binary_sensor-on_state>`
|
||||
- :ref:`binary_sensor.on_click <binary_sensor-on_click>` / :ref:`binary_sensor.on_double_click <binary_sensor-on_double_click>` /
|
||||
:ref:`binary_sensor.on_multi_click <binary_sensor-on_multi_click>`
|
||||
- :ref:`esphome.on_boot <esphome-on_boot>` / :ref:`esphome.on_shutdown <esphome-on_shutdown>` / :ref:`esphome.on_loop <esphome-on_loop>`
|
||||
- :ref:`pn532.on_tag <pn532-on_tag>`
|
||||
- :ref:`time.on_time <time-on_time>`
|
||||
|
|
@ -363,8 +365,8 @@ time period.
|
|||
|
||||
.. code-block:: yaml
|
||||
|
||||
on_...:
|
||||
then:
|
||||
on_...:
|
||||
then:
|
||||
- switch.turn_on: relay_1
|
||||
- delay: 2s
|
||||
- switch.turn_off: relay_1
|
||||
|
|
|
|||
|
|
@ -54,9 +54,14 @@ RST primer:
|
|||
|
||||
.. code-block:: rst
|
||||
|
||||
My Sub-sub section
|
||||
My Sub-sub Section
|
||||
******************
|
||||
|
||||
.. note::
|
||||
|
||||
The length of the bar below the text **must** match the title Text length.
|
||||
Also, titles should be in Title Case
|
||||
|
||||
- **Links**: To create a link to an external resource (for example https://www.google.com), use
|
||||
``\`Link text <link_url>\`__``. For example:
|
||||
|
||||
|
|
@ -104,11 +109,11 @@ RST primer:
|
|||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Sample configuration entry
|
||||
switch:
|
||||
- platform: gpio
|
||||
name: "Relay #42"
|
||||
pin: GPIO13
|
||||
# Sample configuration entry
|
||||
switch:
|
||||
- platform: gpio
|
||||
name: "Relay #42"
|
||||
pin: GPIO13
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -125,10 +130,10 @@ RST primer:
|
|||
Optional figure caption.
|
||||
|
||||
.. figure:: images/dashboard.png
|
||||
:align: center
|
||||
:width: 40.0%
|
||||
:align: center
|
||||
:width: 40.0%
|
||||
|
||||
Optional figure caption.
|
||||
Optional figure caption.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -144,19 +149,19 @@ RST primer:
|
|||
|
||||
.. note::
|
||||
|
||||
This is a note.
|
||||
This is a note.
|
||||
|
||||
.. warning::
|
||||
|
||||
This is a warning.
|
||||
This is a warning.
|
||||
|
||||
.. note::
|
||||
|
||||
This is a note.
|
||||
This is a note.
|
||||
|
||||
.. warning::
|
||||
|
||||
This is a warning.
|
||||
This is a warning.
|
||||
|
||||
- **Italic and boldface font families**: To *italicize* text, use one asterisk around the text. To put
|
||||
**a strong emphasis** on a piece of text, put two asterisks around it.
|
||||
|
|
@ -193,7 +198,8 @@ RST primer:
|
|||
1. Ordered Item #1
|
||||
2. Ordered Item #2
|
||||
|
||||
- **imgtable**: ESPHome uses a custom RST directive to show the table on the front page (see `index.rst <https://github.com/esphome/esphome-docs/blob/current/index.rst>`__).
|
||||
- **imgtable**: ESPHome uses a custom RST directive to show the table on the front page (see
|
||||
`index.rst <https://github.com/esphome/esphome-docs/blob/current/index.rst>`__).
|
||||
New pages need to be added to the ``imgtable`` list. The syntax is CSV with <PAGE NAME>, <FILE NAME> (without RST),
|
||||
<IMAGE> (in top-level images/ directory). The aspect ratio of these images should be 8:10 (or 10:8) but exceptions are possible.
|
||||
|
||||
|
|
@ -210,6 +216,7 @@ please have a look at the `Sphinx reStructuredText Primer <http://www.sphinx-doc
|
|||
|
||||
Build
|
||||
*****
|
||||
|
||||
.. note::
|
||||
|
||||
The easiest way is to use the `esphome-docs docker image <https://hub.docker.com/r/esphome/esphome-docs/>`__:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,8 @@ Frequently Asked Questions
|
|||
Tips for using ESPHome
|
||||
----------------------
|
||||
|
||||
1. ESPHome supports (most of) `Home Assistant's YAML configuration directives <https://www.home-assistant.io/docs/configuration/splitting_configuration/>`__ like
|
||||
1. ESPHome supports (most of) `Home Assistant's YAML configuration directives
|
||||
<https://www.home-assistant.io/docs/configuration/splitting_configuration/>`__ like
|
||||
``!include``, ``!secret``. So you can store all your secret WiFi passwords and so on
|
||||
in a file called ``secrets.yaml`` within the directory where the configuration file is.
|
||||
|
||||
|
|
@ -252,11 +253,12 @@ And a docker compose file looks like this:
|
|||
|
||||
ESPHome uses mDNS to show online/offline state in the dashboard view. So for that feature
|
||||
to work you need to enable host networking mode
|
||||
|
||||
mDNS might not work if your Home Assistant server and your ESPHome nodes are on different subnets. If your router supports Avahi, you are able to get mDNS working over different subnets.
|
||||
|
||||
|
||||
mDNS might not work if your Home Assistant server and your ESPHome nodes are on different subnets.
|
||||
If your router supports Avahi, you are able to get mDNS working over different subnets.
|
||||
|
||||
Just follow the next steps:
|
||||
|
||||
|
||||
1. Enable Avahi on both subnets.
|
||||
2. Enable UDP traffic from ESPHome node's subnet to 224.0.0.251/32 on port 5353.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,13 +5,22 @@ This is a dummy file to include images in the sphinx output
|
|||
that will only be used in raw HTML and thus not auto-included.
|
||||
|
||||
.. image:: shield-discord.svg
|
||||
|
||||
.. image:: shield-github.svg
|
||||
|
||||
.. image:: shield-donate.svg
|
||||
|
||||
.. image:: shield-twitter.svg
|
||||
|
||||
.. image:: logo.svg
|
||||
|
||||
.. image:: logo-core.svg
|
||||
|
||||
.. image:: logo-docs.svg
|
||||
|
||||
.. image:: logo-flasher.svg
|
||||
|
||||
.. image:: logo-release.svg
|
||||
|
||||
.. image:: logo-text.svg
|
||||
|
||||
|
|
|
|||
30
index.rst
30
index.rst
|
|
@ -5,14 +5,17 @@ ESPHome
|
|||
:google-site-verification: Q5q5TFbCofxA8-cSa1Frv5Hj4RopF5zwEZf_zaNHqf4
|
||||
|
||||
.. seo::
|
||||
:description: ESPHome Homepage - Reimagining DIY Home Automation. ESPHome is a framework that tries to provide the best possible use experience for using ESP8266 and ESP32 microcontrollers for Home Automation. Just write a simple YAML configuration file and get your own customized firmware.
|
||||
:description: ESPHome Homepage - Reimagining DIY Home Automation. ESPHome is a framework that
|
||||
tries to provide the best possible use experience for using ESP8266 and ESP32 microcontrollers
|
||||
for Home Automation. Just write a simple YAML configuration file and get your own customized firmware.
|
||||
:image: logo.png
|
||||
|
||||
.. image:: /images/logo-text.svg
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<a href="https://github.com/esphome/esphome"><img src="/_images/shield-github.svg" alt="GitHub" style="max-width:100%;height:26px;width:116.1px;margin-top:10px;"></a>
|
||||
<a href="https://github.com/esphome/esphome"><img src="/_images/shield-github.svg" alt="GitHub"
|
||||
style="max-width:100%;height:26px;width:116.1px;margin-top:10px;"></a>
|
||||
<a href="https://discord.gg/KhAMKrd"><img src="/_images/shield-discord.svg" alt="Discord" style="max-width:100%;height:26px;width:126.3px;"></a>
|
||||
<a href="https://twitter.com/esphome_"><img src="/_images/shield-twitter.svg" alt="Twitter" style="max-width:100%;height:26px;width:122.1px;"></a>
|
||||
<a href="/guides/faq.html#donations"><img src="/_images/shield-donate.svg" alt="Donate" style="max-width:100%;height:26px;width:110.6px;"></a>
|
||||
|
|
@ -149,8 +152,8 @@ Binary Sensor Components
|
|||
Nextion Touch, components/binary_sensor/nextion, nextion.jpg
|
||||
Template Binary Sensor, components/binary_sensor/template, description.svg
|
||||
Remote Receiver, components/binary_sensor/remote_receiver, remote.svg
|
||||
PN532 Tag, components/binary_sensor/pn532, pn532.jpg
|
||||
RDM6300 Tag, components/binary_sensor/rdm6300, rdm6300.jpg
|
||||
PN532, components/binary_sensor/pn532, pn532.jpg
|
||||
RDM6300, components/binary_sensor/rdm6300, rdm6300.jpg
|
||||
Custom Binary Sensor, components/binary_sensor/custom, language-cpp.svg
|
||||
|
||||
Output Components
|
||||
|
|
@ -180,14 +183,13 @@ Light Components
|
|||
RGBW Light, components/light/rgbw, rgbw.png
|
||||
|
||||
RGBWW Light, components/light/rgbww, rgbw.png
|
||||
FastLED Clockless Light, components/light/fastled_clockless, color_lens.svg
|
||||
FastLED SPI Light, components/light/fastled_spi, color_lens.svg
|
||||
FastLED Light, components/light/fastled, color_lens.svg
|
||||
|
||||
NeoPixelBus Light, components/light/neopixelbus, color_lens.svg
|
||||
Light Partition, components/light/partition, color_lens.svg
|
||||
|
||||
Looking for WS2811 and similar individually addressable lights? Have a look at the
|
||||
:doc:`FastLED Clockless Light </components/light/fastled_clockless>`.
|
||||
:doc:`FastLED Light </components/light/fastled>`.
|
||||
|
||||
Switch Components
|
||||
-----------------
|
||||
|
|
@ -219,12 +221,10 @@ Display Components
|
|||
.. imgtable::
|
||||
|
||||
Display Core, components/display/index, folder-open.svg
|
||||
GPIO LCD, components/display/lcd_gpio, lcd.jpg
|
||||
PCF8574 LCD, components/display/lcd_pcf8574, lcd.jpg
|
||||
LCD Display, components/display/lcd_display, lcd.jpg
|
||||
MAX7219, components/display/max7219, max7219.jpg
|
||||
Nextion, components/display/nextion, nextion.jpg
|
||||
SSD1306 I2C, components/display/ssd1306_i2c, ssd1306.jpg
|
||||
SSD1306 SPI, components/display/ssd1306_spi, ssd1306.jpg
|
||||
SSD1306, components/display/ssd1306, ssd1306.jpg
|
||||
Waveshare E-Paper, components/display/waveshare_epaper, waveshare_epaper.jpg
|
||||
|
||||
Cover Components
|
||||
|
|
@ -252,21 +252,13 @@ Misc Components
|
|||
|
||||
.. imgtable::
|
||||
|
||||
Remote Transmitter Hub, components/remote_transmitter, remote.svg
|
||||
Remote Receiver Hub, components/remote_receiver, remote.svg
|
||||
PCA9685 Hub, components/pca9685, pca9685.jpg
|
||||
ADS1115 Hub, components/ads1115, ads1115.jpg
|
||||
Debug Component, components/debug, bug-report.svg
|
||||
PCF8574 I/O Expander, components/pcf8574, pcf8574.jpg
|
||||
ESP32 BLE Tracker, components/esp32_ble_tracker, bluetooth.svg
|
||||
ESP32 BLE Beacon, components/esp32_ble_beacon, bluetooth.svg
|
||||
ESP32 Touch Hub, components/esp32_touch, touch.svg
|
||||
Status LED, components/status_led, led-on.svg
|
||||
PN532, components/pn532, pn532.jpg
|
||||
RDM6300, components/rdm6300, rdm6300.jpg
|
||||
Time, components/time, clock-outline.svg
|
||||
Stepper, components/stepper/index, stepper.svg
|
||||
MY9231/MY9291 LED driver, components/my9231, my9231.svg
|
||||
ESP32 Ethernet, components/ethernet, ethernet.svg
|
||||
|
||||
Additional Custom Components
|
||||
|
|
|
|||
2
seo.py
2
seo.py
|
|
@ -10,7 +10,7 @@ class SEONode(nodes.General, nodes.Element):
|
|||
author=None, author_twitter=None, keywords=None):
|
||||
super(SEONode, self).__init__()
|
||||
self.title = title
|
||||
self.description = description
|
||||
self.description = description.replace('\n', ' ')
|
||||
self.image = image
|
||||
self.author = author
|
||||
self.author_twitter = author_twitter
|
||||
|
|
|
|||
97
travis.py
97
travis.py
|
|
@ -1,11 +1,12 @@
|
|||
from pathlib import Path
|
||||
import re
|
||||
import sys
|
||||
|
||||
errors = []
|
||||
|
||||
|
||||
def find_all(a_str, sub):
|
||||
for i, line in enumerate(a_str.splitlines(keepends=False)):
|
||||
for i, line in enumerate(a_str.splitlines()):
|
||||
column = 0
|
||||
while True:
|
||||
column = line.find(sub, column)
|
||||
|
|
@ -15,18 +16,108 @@ def find_all(a_str, sub):
|
|||
column += len(sub)
|
||||
|
||||
|
||||
section_regex = re.compile(r'^(=+|-+|\*+|~+)$')
|
||||
directive_regex = re.compile(r'^(\s*)\.\. (.*)::.*$')
|
||||
directive_arg_regex = re.compile(r'^(\s+):.*:\s*.*$')
|
||||
esphome_io_regex = re.compile(r'https://esphome.io/')
|
||||
|
||||
|
||||
for f in sorted(Path('.').glob('**/*.rst')):
|
||||
try:
|
||||
content = f.read_text('utf-8')
|
||||
except UnicodeDecodeError:
|
||||
errors.append("File {} is not readable as UTF-8. Please set your editor to UTF-8 mode."
|
||||
"".format(f))
|
||||
continue
|
||||
|
||||
if not content.endswith('\n'):
|
||||
errors.append("Newline at end of file missing. Please insert an empty line at end "
|
||||
"of file {}".format(f))
|
||||
|
||||
# Check tab character
|
||||
for line, col in find_all(content, '\t'):
|
||||
errors.append("File {} contains tab character on line {}:{}. "
|
||||
"Please convert tabs to spaces.".format(f, line, col))
|
||||
"Please convert tabs to spaces.".format(f, line + 1, col))
|
||||
# Check windows newline
|
||||
for line, col in find_all(content, '\r'):
|
||||
errors.append("File {} contains windows newline on line {}:{}. "
|
||||
"Please set your editor to unix newline mode.".format(f, line, col))
|
||||
"Please set your editor to unix newline mode.".format(f, line + 1, col))
|
||||
|
||||
lines = content.splitlines(keepends=False)
|
||||
|
||||
# Check whitespace at end of line
|
||||
for i, line in enumerate(lines):
|
||||
if line.rstrip() != line:
|
||||
errors.append("Lines must not contain spaces at the end of the line. Please "
|
||||
"remove spaces at the end of {}:{}".format(f, i+1))
|
||||
|
||||
for i, line in enumerate(lines):
|
||||
if i == 0:
|
||||
continue
|
||||
|
||||
if not section_regex.match(line):
|
||||
continue
|
||||
line_above = lines[i - 1]
|
||||
if len(line_above) != len(line):
|
||||
errors.append("The title length must match the bar length below it. See {}:{}"
|
||||
"".format(f, i+1))
|
||||
if i + 1 < len(lines) and lines[i + 1]:
|
||||
errors.append("Empty line after heading is missing. Please insert an "
|
||||
"empty line. See {}:{}".format(f, i+1))
|
||||
|
||||
for i, line in enumerate(lines):
|
||||
m = directive_regex.match(line)
|
||||
if m is None:
|
||||
continue
|
||||
base_indentation = len(m.group(1))
|
||||
directive_name = m.group(2)
|
||||
if directive_name.startswith('|') or directive_name == 'seo':
|
||||
continue
|
||||
# Match directive args
|
||||
for j in range(i + 1, len(lines)):
|
||||
if not directive_arg_regex.match(lines[j]):
|
||||
break
|
||||
else:
|
||||
# Reached end of file
|
||||
continue
|
||||
|
||||
# Empty line must follow
|
||||
if lines[j]:
|
||||
errors.append("Directive '{}' is not followed by an empty line. Please insert an "
|
||||
"empty line after {}:{}".format(directive_name, f, j))
|
||||
continue
|
||||
|
||||
k = j + 1
|
||||
for j in range(k, len(lines)):
|
||||
if not lines[j]:
|
||||
# Ignore Empty lines
|
||||
continue
|
||||
|
||||
num_spaces = len(lines[j]) - len(lines[j].lstrip())
|
||||
if num_spaces <= base_indentation:
|
||||
# Finished with this directive
|
||||
break
|
||||
num_indent = num_spaces - base_indentation
|
||||
if j == k and num_indent != 4:
|
||||
errors.append("Directive '{}' must be indented with 4 spaces, not {}. See "
|
||||
"{}:{}".format(directive_name, num_indent, f, j+1))
|
||||
break
|
||||
|
||||
# Check line length
|
||||
for i, line in enumerate(lines):
|
||||
max_line_length = 160
|
||||
if len(line) > max_line_length:
|
||||
errors.append("Lines must not be longer than {} characters. Line {}:{} is {} "
|
||||
"characters long. Please insert newlines."
|
||||
"".format(max_line_length, f, i+1, len(line)))
|
||||
|
||||
for i, line in enumerate(lines):
|
||||
if esphome_io_regex.search(line):
|
||||
if 'privacy.rst' in str(f) or 'web_server.rst' in str(f):
|
||||
continue
|
||||
errors.append("All links to esphome.io should be relative, please remove esphome.io "
|
||||
"from URL. See {}:{}".format(f, i+1))
|
||||
|
||||
|
||||
for error in errors:
|
||||
print(error)
|
||||
|
|
|
|||
|
|
@ -179,10 +179,10 @@ creating a POST request at ``/light/<id>/turn_on?brightness=128&transition=2`` w
|
|||
- **transition**: Transition to off in this duration in seconds.
|
||||
|
||||
Fan
|
||||
****
|
||||
***
|
||||
|
||||
Fans are similar to switches as they can be turned on/off and toggled. In addition, if the
|
||||
underlying fan supports it, fans in the web server also support the speed settings "low",
|
||||
underlying fan supports it, fans in the web server also support the speed settings "low",
|
||||
"medium" and "high" and an oscillation setting. To get the current state of a fan, create a
|
||||
GET request to ``/fan/<id>``.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue