diff --git a/changelog/v1.7.0.rst b/changelog/v1.7.0.rst index 7bb36297b..3336e2959 100644 --- a/changelog/v1.7.0.rst +++ b/changelog/v1.7.0.rst @@ -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 ` and - :doc:`remote transmitter ` components now allows you to use any 433MHz +- The new :doc:`remote receiver ` and + :doc:`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 `, 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 ` as it turns out it didn't actually do anything. -- The ``ir_transmitter`` component has been renamed to :doc:`remote_transmitter ` +- The ``ir_transmitter`` component has been renamed to :doc:`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 ` has been removed, please diff --git a/changelog/v1.8.0.rst b/changelog/v1.8.0.rst index f7f0e423f..0269c2fd3 100644 --- a/changelog/v1.8.0.rst +++ b/changelog/v1.8.0.rst @@ -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! ` -- NFC/RFID Readers (:doc:`PN532 ` and :doc:`RDM6300 `) +- NFC/RFID Readers (:doc:`PN532 ` and :doc:`RDM6300 `) - New :doc:`ESP32 BLE integrations ` like :doc:`Xiaomi MiFlora ` - Core Changes like the addition of the :ref:`SPI bus ` and :ref:`UART bus ` - Lots of new :ref:`light effects ` and support for cold-white/warm-white lights. diff --git a/changelog/v1.9.0.rst b/changelog/v1.9.0.rst index 02b5c2b89..ed97b117e 100644 --- a/changelog/v1.9.0.rst +++ b/changelog/v1.9.0.rst @@ -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, @@ -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 ` so that automations +- Added an :ref:`pn532-on_tag` to :doc:`PN532 NFC Readers ` 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 `, :yamlpr:`167`, :docspr:`51`) -- Added a color correction option to :doc:`FastLED addressable lights ` +- Added a color correction option to :doc:`FastLED addressable lights ` (:libpr:`234`, :yamlpr:`200`, :docspr:`64`) - Added a ``clean`` command to esphomeyaml to fix some occasional build errors diff --git a/components/ads1115.rst b/components/ads1115.rst deleted file mode 100644 index 6a75bd8e0..000000000 --- a/components/ads1115.rst +++ /dev/null @@ -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 `. -To use this hub, first setup the :ref:`I²C Bus ` 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 ` 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 `__ by `Jeff Rowberg `__ -- :apiref:`sensor/ads1115_component.h` -- :ghedit:`Edit` - -.. disqus:: diff --git a/components/binary_sensor/esp32_touch.rst b/components/binary_sensor/esp32_touch.rst index 07450b22c..b80c00e21 100644 --- a/components/binary_sensor/esp32_touch.rst +++ b/components/binary_sensor/esp32_touch.rst @@ -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 `. + +.. 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 ` + 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 `__ + 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 `__ + 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 `__ + 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 `__ + 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 `. Then +First, you need to setup the :ref:`global touch hub `. 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 ` +To find suitable threshold values, first configure the :ref:`ESP32 touch hub ` 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 `__ diff --git a/components/binary_sensor/pn532.rst b/components/binary_sensor/pn532.rst index c3916d3a1..a32d3b623 100644 --- a/components/binary_sensor/pn532.rst +++ b/components/binary_sensor/pn532.rst @@ -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 `__, `adafruit `__) +with ESPHome. This component is a global hub that establishes the connection to the PN532 via :ref:`SPI ` and +outputs its data. Using the :ref:`PN532 binary sensors ` 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 ` 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 `): 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 `): 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 ` 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` diff --git a/components/binary_sensor/rdm6300.rst b/components/binary_sensor/rdm6300.rst index df3c90c60..e52722038 100644 --- a/components/binary_sensor/rdm6300.rst +++ b/components/binary_sensor/rdm6300.rst @@ -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 `__, `iTead `__) +with ESPHome. This component is a global hub that establishes the connection to the RDM6300 via :ref:`UART ` and +translates the received data. Using the :ref:`RDM6300 binary sensors ` 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 ` 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 ` 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` diff --git a/components/binary_sensor/remote_receiver.rst b/components/binary_sensor/remote_receiver.rst index 631eb3dbe..7c9fde913 100644 --- a/components/binary_sensor/remote_receiver.rst +++ b/components/binary_sensor/remote_receiver.rst @@ -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 ` 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 `): Filter any pulses that are shorter than this. Useful for removing + glitches from noisy signals. Defaults to ``10us``. +- **idle** (*Optional*, :ref:`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 `. @@ -61,8 +120,7 @@ See Also -------- - :doc:`index` -- :doc:`/components/remote_receiver` -- :doc:`/components/remote_transmitter` +- :doc:`/components/switch/remote_transmitter` - `RCSwitch `__ by `Suat Özgür `__ - `IRRemoteESP8266 `__ by `Mark Szabo-Simon `__ - :apiref:`remote/remote_receiver.h` diff --git a/components/display/index.rst b/components/display/index.rst index 1bc60f64a..e0f478a39 100644 --- a/components/display/index.rst +++ b/components/display/index.rst @@ -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 ` or - :doc:`some LCD displays `. + :doc:`some LCD displays `. - 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 ` or - :doc:`OLED displays `. + :doc:`OLED displays `. For the last type, ESPHome has a powerful rendering engine that can do many things like draw some basic shapes, print text with any font you want, or even show images. diff --git a/components/display/lcd_gpio.rst b/components/display/lcd_display.rst similarity index 67% rename from components/display/lcd_gpio.rst rename to components/display/lcd_display.rst index 4263ee905..89f3f9618 100644 --- a/components/display/lcd_gpio.rst +++ b/components/display/lcd_display.rst @@ -1,15 +1,68 @@ -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 `__ +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 `, 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 ` address of the PCF8574 chip, defaults to ``0x3F``. +- **lambda** (*Optional*, :ref:`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 `__ 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 +70,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 +87,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 +160,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 `__ - :ghedit:`Edit` diff --git a/components/display/lcd_pcf8574.rst b/components/display/lcd_pcf8574.rst deleted file mode 100644 index ae481a504..000000000 --- a/components/display/lcd_pcf8574.rst +++ /dev/null @@ -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 `__ -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 `, 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 ` address of the PCF8574 chip, defaults to ``0x3F``. -- **lambda** (*Optional*, :ref:`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 `__ -- :ghedit:`Edit` - -.. disqus:: diff --git a/components/display/ssd1306_spi.rst b/components/display/ssd1306.rst similarity index 52% rename from components/display/ssd1306_spi.rst rename to components/display/ssd1306.rst index 1ddebd206..ee4216337 100644 --- a/components/display/ssd1306_spi.rst +++ b/components/display/ssd1306.rst @@ -1,15 +1,86 @@ -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 `__, `Adafruit `__) +and SH1106 (`datasheet `__, `electrodragon `__) +displays with ESPHome. Note that this component is for displays that are connected via the :ref:`I²C Bus `. +If your SSD1306 or SH1106 is connected via the 4-Wire :ref:`SPI bus `, 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 `, 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 `): The RESET pin. Defaults to not connected. +- **address** (*Optional*, int): Manually specify the :ref:`I²C ` 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 `): 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 `__, `Adafruit `__) and SH1106 (`datasheet `__, `electrodragon `__) displays with ESPHome. Note that this component is for displays that are connected via the 4-Wire :ref:`SPI bus `. -If your SSD1306 or SH1106 is connected via the :ref:`I²C Bus `, see :doc:`ssd1306_i2c`. +If your SSD1306 or SH1106 is connected via the :ref:`I²C Bus `, see :ref:`ssd1306-i2c`. .. figure:: images/ssd1306-full.jpg :align: center @@ -39,7 +110,7 @@ improve reliability. it.print(0, 0, id(font), "Hello World!"); Configuration variables: ------------------------- +************************ - **model** (**Required**): The model of the display. Options are: diff --git a/components/display/ssd1306_i2c.rst b/components/display/ssd1306_i2c.rst deleted file mode 100644 index c7280d1d1..000000000 --- a/components/display/ssd1306_i2c.rst +++ /dev/null @@ -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 `__, `Adafruit `__) -and SH1106 (`datasheet `__, `electrodragon `__) -displays with ESPHome. Note that this component is for displays that are connected via the :ref:`I²C Bus `. -If your SSD1306 or SH1106 is connected via the 4-Wire :ref:`SPI bus `, 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 `, 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 `): The RESET pin. Defaults to not connected. -- **address** (*Optional*, int): Manually specify the :ref:`I²C ` 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 `): 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 `__ by `Adafruit `__ -- :ghedit:`Edit` - -.. disqus:: diff --git a/components/esp32_touch.rst b/components/esp32_touch.rst deleted file mode 100644 index 4864e01cd..000000000 --- a/components/esp32_touch.rst +++ /dev/null @@ -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 `. - -.. 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 ` - 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 `__ - 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 `__ - 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 `__ - 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 `__ - 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:: diff --git a/components/light/fastled_clockless.rst b/components/light/fastled.rst similarity index 51% rename from components/light/fastled_clockless.rst rename to components/light/fastled.rst index 765be657a..c33034012 100644 --- a/components/light/fastled_clockless.rst +++ b/components/light/fastled.rst @@ -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 `. 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 `. + +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 `__ 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 ` 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 `. + +.. _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 `__ diff --git a/components/light/fastled_spi.rst b/components/light/fastled_spi.rst deleted file mode 100644 index a92ede928..000000000 --- a/components/light/fastled_spi.rst +++ /dev/null @@ -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 `. - -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 `__ 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 ` 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 `. - -.. _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 `__ -- :ghedit:`Edit` - -.. disqus:: diff --git a/components/light/neopixelbus.rst b/components/light/neopixelbus.rst index 2fedc655f..7c4065335 100644 --- a/components/light/neopixelbus.rst +++ b/components/light/neopixelbus.rst @@ -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 `__ library, this integration uses the `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 `__ diff --git a/components/light/partition.rst b/components/light/partition.rst index 035955348..00ed09381 100644 --- a/components/light/partition.rst +++ b/components/light/partition.rst @@ -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` diff --git a/components/my9231.rst b/components/my9231.rst deleted file mode 100644 index 338162732..000000000 --- a/components/my9231.rst +++ /dev/null @@ -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 `__, -`MY9291 description `__) 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 `. - -.. 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: - platform: ESP8266 - board: esp01_1m - - wifi: - ssid: - password: - - api: - - logger: - - 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: - 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:: diff --git a/components/output/my9231.rst b/components/output/my9231.rst index a079d3c28..b9e2340e2 100644 --- a/components/output/my9231.rst +++ b/components/output/my9231.rst @@ -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 `__, +`MY9291 description `__) 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 `. .. 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: + platform: ESP8266 + board: esp01_1m + + wifi: + ssid: + password: + + api: + + logger: + + 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: + 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 `. See Also -------- -- :doc:`/components/my9231` - :doc:`/components/output/index` - :doc:`/components/output/esp8266_pwm` - :doc:`/components/output/ledc` diff --git a/components/output/pca9685.rst b/components/output/pca9685.rst index 5336c504c..6231a30f0 100644 --- a/components/output/pca9685.rst +++ b/components/output/pca9685.rst @@ -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 `__, +`adafruit `__) in ESPHome. It +uses :ref:`I²C Bus ` 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 `. + +.. 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 ` as a float +:ref:`PCA9685 hub ` 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 `. + :ref:`PCA9685 hub `. Use this if you have multiple PCA9685s you want to use at the same time. - All other options from :ref:`Output `. See Also -------- -- :doc:`/components/pca9685` - :doc:`/components/output/index` - :doc:`/components/output/esp8266_pwm` - :doc:`/components/output/ledc` diff --git a/components/pca9685.rst b/components/pca9685.rst deleted file mode 100644 index 9ad6334f8..000000000 --- a/components/pca9685.rst +++ /dev/null @@ -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 `__, -`adafruit `__) in ESPHome. It -uses :ref:`I²C Bus ` 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 `. - -.. 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:: diff --git a/components/pcf8574.rst b/components/pcf8574.rst index 13eb31fa5..1f71c3386 100644 --- a/components/pcf8574.rst +++ b/components/pcf8574.rst @@ -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 diff --git a/components/pn532.rst b/components/pn532.rst deleted file mode 100644 index 2dd645465..000000000 --- a/components/pn532.rst +++ /dev/null @@ -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 `__, `adafruit `__) -with ESPHome. This component is a global hub that establishes the connection to the PN532 via :ref:`SPI ` and -outputs its data. Using the :doc:`PN532 binary sensors ` 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 ` 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 `): 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 `): 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 ` 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 `__ by `Adafruit `__ -- :apiref:`binary_sensor/pn532_component.h` -- :ghedit:`Edit` - -.. disqus:: diff --git a/components/rdm6300.rst b/components/rdm6300.rst deleted file mode 100644 index 6789c57f5..000000000 --- a/components/rdm6300.rst +++ /dev/null @@ -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 `__, `iTead `__) -with ESPHome. This component is a global hub that establishes the connection to the RDM6300 via :ref:`UART ` and -translates the received data. Using the :doc:`RDM6300 binary sensors ` 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 ` 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 ` 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 `__ by `Arliones Hoeller Jr `__ -- :apiref:`binary_sensor/rdm6300_component.h` -- :ghedit:`Edit` - -.. disqus:: diff --git a/components/remote_receiver.rst b/components/remote_receiver.rst deleted file mode 100644 index 2aa359271..000000000 --- a/components/remote_receiver.rst +++ /dev/null @@ -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 ` 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 `): Filter any pulses that are shorter than this. Useful for removing - glitches from noisy signals. Defaults to ``10us``. -- **idle** (*Optional*, :ref:`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 `__ by `Suat Özgür `__ -- `IRRemoteESP8266 `__ by `Mark Szabo-Simon `__ -- :apiref:`remote/remote_receiver.h` -- :ghedit:`Edit` - -.. disqus:: diff --git a/components/remote_transmitter.rst b/components/remote_transmitter.rst deleted file mode 100644 index 355ad4bcb..000000000 --- a/components/remote_transmitter.rst +++ /dev/null @@ -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 ` 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 `__ by `Suat Özgür `__ -- `IRRemoteESP8266 `__ by `Mark Szabo-Simon `__ -- :apiref:`remote/remote_transmitter.h` -- :ghedit:`Edit` - -.. disqus:: diff --git a/components/sensor/ads1115.rst b/components/sensor/ads1115.rst index c1e29853c..cc3362c89 100644 --- a/components/sensor/ads1115.rst +++ b/components/sensor/ads1115.rst @@ -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 `__, `Adafruit`_) with ESPHome. -First, setup a :doc:`ADS1115 Hub ` 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 `. +To use this hub, first setup the :ref:`I²C Bus ` 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 ` 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 `__, `Adafruit`_) with ESPHome. +First, setup a :ref:`ADS1115 Hub ` 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 ` you want to use this sensor. + :ref:`ADS1115 Hub ` 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. diff --git a/components/switch/remote_transmitter.rst b/components/switch/remote_transmitter.rst index 8e4224ceb..2e3217fcc 100644 --- a/components/switch/remote_transmitter.rst +++ b/components/switch/remote_transmitter.rst @@ -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 ` 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 `): 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 `. @@ -68,7 +119,7 @@ Configuration variables: .. _remote_transmitter-codes: Remote Codes ------------- +************ Supported remote codes: @@ -210,7 +261,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 ` like this: +using the :doc:`remote receiver component ` like this: .. code-block:: yaml @@ -240,9 +291,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 +421,7 @@ See Also -------- - :doc:`index` -- :doc:`/components/remote_transmitter` -- :doc:`/components/remote_receiver` +- :doc:`/components/binary_sensor/remote_receiver` - `RCSwitch `__ by `Suat Özgür `__ - `IRRemoteESP8266 `__ by `Mark Szabo-Simon `__ - :apiref:`remote/remote_transmitter.h` diff --git a/cookbook/display_time_temp_oled.rst b/cookbook/display_time_temp_oled.rst index 36c73a1fd..a49444892 100644 --- a/cookbook/display_time_temp_oled.rst +++ b/cookbook/display_time_temp_oled.rst @@ -10,7 +10,7 @@ Time & Temperature on OLED Display :align: left :width: 75.0% -In this example I have used a :doc:`SSD1306 OLED Display over I²C ` 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 ` 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``). @@ -135,7 +135,7 @@ Rendering See Also -------- -- :doc:`/components/display/ssd1306_i2c` +- :doc:`/components/display/ssd1306` - :doc:`/components/display/index` - :doc:`/components/sensor/homeassistant` - :ghedit:`Edit` diff --git a/devices/sonoff.rst b/devices/sonoff.rst index ebf3aa160..e1d808b6b 100644 --- a/devices/sonoff.rst +++ b/devices/sonoff.rst @@ -192,7 +192,7 @@ Same configuration as the :doc:`Sonoff 4CH `. Sonoff B1, Ai-Thinker AiLight ----------------------------- -See :doc:`/components/my9231`. +See :doc:`/components/output/my9231`. Sonoff T1 1CH, 2CH, 3CH ----------------------- diff --git a/index.rst b/index.rst index 6c1eff286..9242073ed 100644 --- a/index.rst +++ b/index.rst @@ -149,8 +149,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 +180,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 `. +:doc:`FastLED Light `. Switch Components ----------------- @@ -219,12 +218,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 +249,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