mirror of
https://github.com/esphome/esphome-docs.git
synced 2025-02-28 03:41:57 +01:00
Merge branch 'current' into next
This commit is contained in:
Jesse Hills
commit
696a828156
@ -14,6 +14,7 @@ RUN useradd -ms /bin/bash esphome
|
||||
USER esphome
|
||||
|
||||
WORKDIR /workspaces/esphome-docs
|
||||
ENV PATH="${PATH}:/home/esphome/.local/bin"
|
||||
|
||||
COPY requirements.txt ./
|
||||
RUN pip3 install --no-cache-dir --no-binary :all: -r requirements.txt
|
||||
|
||||
2
Doxygen
2
Doxygen
@ -38,7 +38,7 @@ PROJECT_NAME = "ESPHome"
|
||||
# could be handy for archiving the generated documentation or if some version
|
||||
# control system is used.
|
||||
|
||||
PROJECT_NUMBER = 2024.4.1
|
||||
PROJECT_NUMBER = 2024.4.2
|
||||
|
||||
# Using the PROJECT_BRIEF tag one can provide an optional one line description
|
||||
# for a project that appears at the top of each page and should give viewer a
|
||||
|
||||
2
Makefile
2
Makefile
@ -1,5 +1,5 @@
|
||||
ESPHOME_PATH = ../esphome
|
||||
ESPHOME_REF = 2024.4.1
|
||||
ESPHOME_REF = 2024.4.2
|
||||
|
||||
.PHONY: html html-strict cleanhtml deploy help live-html Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png minify
|
||||
|
||||
|
||||
@ -240,6 +240,11 @@ a:hover code {
|
||||
background: none;
|
||||
}
|
||||
|
||||
/* don't underline links that contain an image and nothing else */
|
||||
a:has(> img:only-child) {
|
||||
border-bottom: none;
|
||||
}
|
||||
|
||||
div.body p, div.body dd, div.body li, div.body blockquote {
|
||||
hyphens: none;
|
||||
}
|
||||
|
||||
@ -1 +1 @@
|
||||
2024.4.1
|
||||
2024.4.2
|
||||
@ -50,6 +50,15 @@ Release 2024.4.1 - April 23
|
||||
- Fix or filter :esphomepr:`6574` by :ghuser:`swoboda1337`
|
||||
|
||||
|
||||
Release 2024.4.2 - April 30
|
||||
---------------------------
|
||||
|
||||
- Fix SHT3xd fails sometimes in 2024.4.0 :esphomepr:`6592` by :ghuser:`mrtoy-me`
|
||||
- allow defaults with no include vars :esphomepr:`6613` by :ghuser:`ssieb`
|
||||
- Revert #6458 :esphomepr:`6650` by :ghuser:`tronikos`
|
||||
- [i2s_audio.microphone] Fixing adc bug :esphomepr:`6654` by :ghuser:`jesserockz`
|
||||
|
||||
|
||||
Full list of changes
|
||||
--------------------
|
||||
|
||||
|
||||
@ -27,8 +27,8 @@ Configuration variables:
|
||||
- **codes** (*Optional*, list of string): A list of codes for disarming the alarm, if *requires_code_to_arm* set to true then for arming the alarm too.
|
||||
- **requires_code_to_arm** (*Optional*, boolean): Code required for arming the alarm, *codes* must be provided.
|
||||
- **arming_away_time** (*Optional*, :ref:`config-time`): The exit delay before the alarm is armed to away mode. Defaults to ``0s``.
|
||||
- **arming_home_time** (*Optional*, :ref:`config-time`): The exit delay before the alarm is armed to home mode.
|
||||
- **arming_night_time** (*Optional*, :ref:`config-time`): The exit delay before the alarm is armed to night mode.
|
||||
- **arming_home_time** (*Optional*, :ref:`config-time`): The exit delay before the alarm is armed to home mode.
|
||||
- **arming_night_time** (*Optional*, :ref:`config-time`): The exit delay before the alarm is armed to night mode.
|
||||
- **pending_time** (*Optional*, :ref:`config-time`): The entry delay before the alarm is triggered. Defaults to ``0s``.
|
||||
- **trigger_time** (*Optional*, :ref:`config-time`): The time after a triggered alarm before resetting to previous state if the sensors are cleared/off. Defaults to ``0s``.
|
||||
- **binary_sensors** (*Optional*, *list*): A list of binary sensors the panel should use. Each consists of:
|
||||
@ -169,7 +169,7 @@ Example:
|
||||
name: Zone 1
|
||||
device_class: door
|
||||
pin:
|
||||
number: D1
|
||||
number: GPIOXX
|
||||
mode: INPUT_PULLUP
|
||||
inverted: True
|
||||
- platform: gpio
|
||||
@ -177,7 +177,7 @@ Example:
|
||||
name: Zone 2
|
||||
device_class: door
|
||||
pin:
|
||||
number: D2
|
||||
number: GPIOXX
|
||||
mode: INPUT_PULLUP
|
||||
inverted: True
|
||||
- platform: gpio
|
||||
@ -185,7 +185,7 @@ Example:
|
||||
name: Zone 3
|
||||
device_class: motion
|
||||
pin:
|
||||
number: D3
|
||||
number: GPIOXX
|
||||
mode: INPUT_PULLUP
|
||||
inverted: True
|
||||
- platform: gpio
|
||||
@ -193,7 +193,7 @@ Example:
|
||||
name: Zone 4
|
||||
device_class: door
|
||||
pin:
|
||||
number: D4
|
||||
number: GPIOXX
|
||||
mode: INPUT_PULLUP
|
||||
inverted: True
|
||||
- platform: homeassistant
|
||||
@ -206,7 +206,7 @@ Example:
|
||||
id: siren
|
||||
name: Siren
|
||||
icon: mdi:alarm-bell
|
||||
pin: D7
|
||||
pin: GPIOXX
|
||||
|
||||
|
||||
See Also
|
||||
|
||||
@ -75,20 +75,35 @@ Configuration variables:
|
||||
|
||||
.. _api-actions:
|
||||
|
||||
.. note::
|
||||
|
||||
Before a newly added ESPHome device can interact with the Home Assistant API it needs to be allowed to communicate
|
||||
with it. This setting can be found in the ESPHome integration (NOT in the Add-On) by clicking "CONFIGURE" for
|
||||
that device and enabling the "Allow device to make service calls" option.
|
||||
|
||||
Actions
|
||||
-------
|
||||
|
||||
Before using any of the actions below, you'll need to tell Home Assistant to allow your device to
|
||||
make service calls.
|
||||
|
||||
Open the ESPHome integration page on your Home Assistant instance:
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<a href="https://my.home-assistant.io/redirect/integration/?domain=esphome" target="_blank" rel="noreferrer noopener"><img src="https://my.home-assistant.io/badges/integration.svg" alt="Open your Home Assistant instance and show an integration." /></a>
|
||||
|
||||
Then:
|
||||
|
||||
#. Fnd your device in the device list
|
||||
#. Click the "configure" button next to it
|
||||
#. Check the "Allow the device to make Home Assistant service calls" box
|
||||
#. Then click "submit".
|
||||
|
||||
.. _api-homeassistant_event_action:
|
||||
|
||||
``homeassistant.event`` Action
|
||||
******************************
|
||||
|
||||
.. note::
|
||||
|
||||
Be sure to :ref:`follow the instructions above <api-actions>` to tell Home Assistant to allow
|
||||
your device to make service calls.
|
||||
|
||||
When using the native API with Home Assistant, you can create events in the Home Assistant event bus
|
||||
straight from ESPHome :ref:`Automations <automation>`.
|
||||
|
||||
@ -117,6 +132,11 @@ Configuration variables:
|
||||
``homeassistant.service`` Action
|
||||
********************************
|
||||
|
||||
.. note::
|
||||
|
||||
Be sure to :ref:`follow the instructions above <api-actions>` to tell Home Assistant to allow
|
||||
your device to make service calls.
|
||||
|
||||
When using the native API with Home Assistant, you can create Home Assistant service
|
||||
calls straight from ESPHome :ref:`Automations <automation>`.
|
||||
|
||||
@ -189,6 +209,11 @@ Then, in ESPHome:
|
||||
``homeassistant.tag_scanned`` Action
|
||||
************************************
|
||||
|
||||
.. note::
|
||||
|
||||
Be sure to :ref:`follow the instructions above <api-actions>` to tell Home Assistant to allow
|
||||
your device to make service calls.
|
||||
|
||||
When using the native API with Home Assistant, you can push tag_scanned to Home Assistant
|
||||
straight from ESPHome :ref:`Automations <automation>`.
|
||||
|
||||
|
||||
@ -32,17 +32,6 @@ a :doc:`/components/i2c` component (and its requisite GPIO pins) is required in
|
||||
id: "Radar"
|
||||
i2c_id: bus_a
|
||||
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
pin: GPIO21
|
||||
name: "Radar motion"
|
||||
|
||||
switch:
|
||||
# Switch to turn on/off RF emission
|
||||
- platform: at581x
|
||||
at581x_id: "Radar"
|
||||
name: "Enable Radar"
|
||||
|
||||
.. _at581x-component:
|
||||
|
||||
Component/Hub
|
||||
@ -87,7 +76,7 @@ The state of the radar detection is available via its GPIO pin. It's required to
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
name: "Human in front"
|
||||
pin: GPIO21
|
||||
pin: GPIOXX
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
@ -127,8 +116,8 @@ Actions
|
||||
|
||||
.. warning::
|
||||
|
||||
The hardware frontend reset option is only required to reset the frontend in case it is struck, before sending the
|
||||
new configuration. However, a frontend reset is always performed after changing the settings.
|
||||
The hardware frontend reset option is only required to reset the frontend in case it is struck, before sending the
|
||||
new configuration. However, a frontend reset is always performed after changing the settings.
|
||||
|
||||
The radar has several settings which can be changed. These settings are not saved in non-volatile memory
|
||||
and need to be set on each boot.
|
||||
|
||||
@ -30,7 +30,7 @@ required to be set up in your configuration for this sensor to work.
|
||||
cap1188:
|
||||
id: cap1188_component
|
||||
address: 0x29
|
||||
reset_pin: 14
|
||||
reset_pin: GPIOXX
|
||||
touch_threshold: 0x40
|
||||
allow_multiple_touches: true
|
||||
|
||||
|
||||
@ -1,22 +1,28 @@
|
||||
Custom Binary Sensor
|
||||
====================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Custom C++ binary sensors with ESPHome.
|
||||
:image: language-cpp.svg
|
||||
:keywords: C++, Custom
|
||||
|
||||
.. warning::
|
||||
|
||||
Custom components are deprecated, not recommended for new configurations
|
||||
and will be removed from ESPHome in a future release.
|
||||
Please look at creating a real ESPHome component and "importing" it into your
|
||||
configuration with :doc:`/components/external_components`.
|
||||
Custom components are deprecated, not recommended for new configurations and will be removed from ESPHome in a
|
||||
future release. Please look at creating a real ESPHome component and "importing" it into your configuration with
|
||||
:doc:`/components/external_components`.
|
||||
|
||||
You can find some basic documentation on creating your own components
|
||||
at :ref:`contributing_to_esphome`.
|
||||
You can find some basic documentation on creating your own components at :ref:`contributing_to_esphome`.
|
||||
|
||||
This integration can be used to create custom binary sensors in ESPHome
|
||||
using the C++ (Arduino) API.
|
||||
.. warning::
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide,
|
||||
the same principles apply here and binary sensors are very similar
|
||||
to sensors internally.
|
||||
While we try to keep the ESPHome YAML configuration options as stable as possible, the ESPHome API is less
|
||||
stable. If something in the APIs needs to be changed in order for something else to work, we will do so.
|
||||
|
||||
This component can be used to create custom binary sensors in ESPHome using the C++ (Arduino) API.
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide, the same principles apply here and binary
|
||||
sensors are very similar to sensors internally.
|
||||
|
||||
The example below is an example of a custom binary sensor; this custom sensor is essentially the
|
||||
same as the gpio binary sensor.
|
||||
|
||||
@ -130,8 +130,8 @@ an ``OFF`` state.
|
||||
|
||||
binary_sensor:
|
||||
- platform: esp32_touch
|
||||
name: "ESP32 Touch Pad GPIO27"
|
||||
pin: GPIO27
|
||||
name: "ESP32 Touch Pad"
|
||||
pin: GPIOXX
|
||||
threshold: 1000
|
||||
|
||||
Configuration variables:
|
||||
@ -164,7 +164,7 @@ If access to the raw values is required, a template sensor can be created that p
|
||||
binary_sensor:
|
||||
- platform: esp32_touch
|
||||
id: esp32_touch_pad
|
||||
pin: GPIO4
|
||||
pin: GPIOXX
|
||||
threshold: 0
|
||||
|
||||
sensor:
|
||||
@ -174,8 +174,8 @@ If access to the raw values is required, a template sensor can be created that p
|
||||
return id(esp32_touch_pad).get_value();
|
||||
update_interval: 3s
|
||||
|
||||
One example of use is a wide area pressure sensor that integrates a number of smaller sensors in an area. Make two strips
|
||||
of aluminium foil that sandwich paper, and connect one wire to a touch pin and the other to ground. Set up several sensors
|
||||
One example of use is a wide area pressure sensor that integrates a number of smaller sensors in an area. Make two strips
|
||||
of aluminium foil that sandwich paper, and connect one wire to a touch pin and the other to ground. Set up several sensors
|
||||
under a flexible object like a plastic mat, add the raw values, and apply a threshold.
|
||||
|
||||
.. _esp32-touch-pad-pins:
|
||||
|
||||
@ -17,17 +17,17 @@ Additional sensors for Haier Climate device. **These sensors are supported only
|
||||
# Example configuration entry
|
||||
uart:
|
||||
baud_rate: 9600
|
||||
tx_pin: 17
|
||||
rx_pin: 16
|
||||
tx_pin: GPIOXX
|
||||
rx_pin: GPIOXX
|
||||
id: ac_port
|
||||
|
||||
|
||||
climate:
|
||||
- platform: haier
|
||||
id: haier_ac
|
||||
protocol: hOn
|
||||
name: Haier AC
|
||||
uart_id: ac_port
|
||||
|
||||
|
||||
binary_sensor:
|
||||
- platform: haier
|
||||
haier_id: haier_ac
|
||||
@ -56,9 +56,9 @@ Configuration variables:
|
||||
All options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
- **indoor_electric_heating_status** (*Optional*): A binary sensor that indicates electrical heating system activity.
|
||||
All options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
- **indoor_fan_status** (*Optional*): A binary sensor that indicates indoor fan activity.
|
||||
- **indoor_fan_status** (*Optional*): A binary sensor that indicates indoor fan activity.
|
||||
All options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
- **outdoor_fan_status** (*Optional*): A binary sensor that indicates outdoor fan activity.
|
||||
- **outdoor_fan_status** (*Optional*): A binary sensor that indicates outdoor fan activity.
|
||||
All options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
|
||||
See Also
|
||||
|
||||
@ -12,12 +12,6 @@ For this sensor to work, a :doc:`/components/sensor/hydreon_rgxx` must be set up
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example RG-9 entry
|
||||
|
||||
uart:
|
||||
rx_pin: GPIO16
|
||||
tx_pin: GPIO17
|
||||
baud_rate: 9600
|
||||
|
||||
sensor:
|
||||
- platform: hydreon_rgxx
|
||||
model: "RG_9"
|
||||
|
||||
@ -42,7 +42,7 @@ you can then create individual binary sensors that track if an NFC/RFID tag is c
|
||||
spi:
|
||||
|
||||
rc522_spi:
|
||||
cs_pin: GPIO15
|
||||
cs_pin: GPIOXX
|
||||
|
||||
binary_sensor:
|
||||
- platform: rc522
|
||||
|
||||
@ -17,7 +17,7 @@ momentarily set a GPIO pin using a button.
|
||||
# Example configuration entry
|
||||
output:
|
||||
- platform: gpio
|
||||
pin: 25
|
||||
pin: GPIOXX
|
||||
id: output1
|
||||
|
||||
button:
|
||||
|
||||
@ -11,10 +11,6 @@ The ``uart`` button platform allows you to send a pre-defined sequence of bytes
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
baud_rate: 9600
|
||||
tx_pin: D0
|
||||
|
||||
button:
|
||||
- platform: uart
|
||||
name: "UART String Output"
|
||||
|
||||
@ -69,7 +69,7 @@ Configuration variables:
|
||||
- ``12K5BPS`` - Support by ``esp32_can`` depends on ESP32 variant
|
||||
- ``16KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
|
||||
- ``20KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
|
||||
- ``25KBPS``
|
||||
- ``25KBPS``
|
||||
- ``31K25BPS`` - Not supported by ``esp32_can``
|
||||
- ``33KBPS`` - Not supported by ``esp32_can``
|
||||
- ``40KBPS`` - Not supported by ``esp32_can``
|
||||
@ -197,8 +197,8 @@ You only need to specify the RX and TX pins. Any GPIO will work.
|
||||
# Example configuration entry
|
||||
canbus:
|
||||
- platform: esp32_can
|
||||
tx_pin: GPIO5
|
||||
rx_pin: GPIO4
|
||||
tx_pin: GPIOXX
|
||||
rx_pin: GPIOXX
|
||||
can_id: 4
|
||||
bit_rate: 50kbps
|
||||
on_frame:
|
||||
@ -209,28 +209,28 @@ You only need to specify the RX and TX pins. Any GPIO will work.
|
||||
|
||||
The table lists the specific bit rates supported by the component for ESP32 variants:
|
||||
=================== ======= ========== ========== ========== ========== ==========
|
||||
bit_rate ESP32 ESP32-S2 ESP32-S3 ESP32-C3 ESP32-C6 ESP32-H2
|
||||
bit_rate ESP32 ESP32-S2 ESP32-S3 ESP32-C3 ESP32-C6 ESP32-H2
|
||||
=================== ======= ========== ========== ========== ========== ==========
|
||||
1KBPS x x x x x
|
||||
5KBPS x x x x x
|
||||
10KBPS x x x x x
|
||||
12K5BPS x x x x x
|
||||
16KBPS x x x x x
|
||||
20KBPS x x x x x
|
||||
25KBPS x x x x x x
|
||||
31K25BPS
|
||||
33KBPS
|
||||
40KBPS
|
||||
50KBPS x x x x x x
|
||||
80KBPS
|
||||
83K38BPS
|
||||
95KBPS
|
||||
100KBPS x x x x x x
|
||||
125KBPS (Default) x x x x x x
|
||||
250KBPS x x x x x x
|
||||
500KBPS x x x x x x
|
||||
800KBPS x x x x x x
|
||||
1000KBPS x x x x x x
|
||||
1KBPS x x x x x
|
||||
5KBPS x x x x x
|
||||
10KBPS x x x x x
|
||||
12K5BPS x x x x x
|
||||
16KBPS x x x x x
|
||||
20KBPS x x x x x
|
||||
25KBPS x x x x x x
|
||||
31K25BPS
|
||||
33KBPS
|
||||
40KBPS
|
||||
50KBPS x x x x x x
|
||||
80KBPS
|
||||
83K38BPS
|
||||
95KBPS
|
||||
100KBPS x x x x x x
|
||||
125KBPS (Default) x x x x x x
|
||||
250KBPS x x x x x x
|
||||
500KBPS x x x x x x
|
||||
800KBPS x x x x x x
|
||||
1000KBPS x x x x x x
|
||||
=================== ======= ========== ========== ========== ========== ==========
|
||||
|
||||
|
||||
@ -273,7 +273,7 @@ For wiring up the MSP2515 please refer to the section below.
|
||||
# Example configuration entry
|
||||
canbus:
|
||||
- platform: mcp2515
|
||||
cs_pin: D5
|
||||
cs_pin: GPIOXX
|
||||
can_id: 4
|
||||
bit_rate: 50kbps
|
||||
on_frame:
|
||||
@ -359,7 +359,7 @@ Standard IDs and Extended IDs can coexist on the same segment.
|
||||
- platform: mcp2515
|
||||
id: my_mcp2515
|
||||
spi_id: McpSpi
|
||||
cs_pin: GPIO14
|
||||
cs_pin: GPIOXX
|
||||
can_id: 0x1fff
|
||||
use_extended_id: true
|
||||
bit_rate: 125kbps
|
||||
@ -385,9 +385,9 @@ Button is connected on a can node which sends an A message on ID 0x100 with payl
|
||||
|
||||
spi:
|
||||
id: McpSpi
|
||||
clk_pin: GPIO16
|
||||
mosi_pin: GPIO5
|
||||
miso_pin: GPIO4
|
||||
clk_pin: GPIOXX
|
||||
mosi_pin: GPIOXX
|
||||
miso_pin: GPIOXX
|
||||
|
||||
binary_sensor:
|
||||
- platform: template
|
||||
@ -398,7 +398,7 @@ Button is connected on a can node which sends an A message on ID 0x100 with payl
|
||||
- platform: mcp2515
|
||||
id: my_mcp2515
|
||||
spi_id: McpSpi
|
||||
cs_pin: GPIO14
|
||||
cs_pin: GPIOXX
|
||||
can_id: 4
|
||||
bit_rate: 125kbps
|
||||
on_frame:
|
||||
@ -430,15 +430,15 @@ Buttons are connected on the CAN-Node and also the motor is connected via CAN.
|
||||
|
||||
spi:
|
||||
id: McpSpi
|
||||
clk_pin: GPIO16
|
||||
mosi_pin: GPIO5
|
||||
miso_pin: GPIO4
|
||||
clk_pin: GPIOXX
|
||||
mosi_pin: GPIOXX
|
||||
miso_pin: GPIOXX
|
||||
|
||||
canbus:
|
||||
- platform: mcp2515
|
||||
id: my_mcp2515
|
||||
spi_id: McpSpi
|
||||
cs_pin: GPIO14
|
||||
cs_pin: GPIOXX
|
||||
can_id: 4
|
||||
bit_rate: 125kbps
|
||||
on_frame:
|
||||
|
||||
@ -76,7 +76,7 @@ controller unit.
|
||||
|
||||
# Example configuration entry
|
||||
remote_transmitter:
|
||||
pin: GPIO32
|
||||
pin: GPIOXX
|
||||
carrier_duty_percent: 50%
|
||||
|
||||
climate:
|
||||
@ -156,7 +156,7 @@ IR receiver.
|
||||
remote_receiver:
|
||||
id: rcvr
|
||||
pin:
|
||||
number: GPIO14
|
||||
number: GPIOXX
|
||||
inverted: true
|
||||
mode:
|
||||
input: true
|
||||
@ -283,8 +283,8 @@ Configuration variables:
|
||||
|
||||
- **set_fan_mode** (*Optional*, string): Select the fan modes desired or that are supported on your remote. Defaults to ``3levels``
|
||||
|
||||
- Options are: ``3levels`` , ``4levels``, ``quiet_4levels``.
|
||||
|
||||
- Options are: ``3levels`` , ``4levels``, ``quiet_4levels``.
|
||||
|
||||
- ``3levels``; Low [fan speed 1], Medium [2], High [3]
|
||||
- ``4levels``; Low [1], Middle [2], Medium [3], High [4]
|
||||
- ``quiet_4levels``; Low [1], Middle [2], Medium [3], High [4], Quiet [5]
|
||||
@ -292,10 +292,10 @@ Configuration variables:
|
||||
- **supports_dry** (*Optional*, boolean): Enables setting dry mode for this unit. Defaults to ``false``.
|
||||
- **supports_fan_only** (*Optional*, boolean): Enables setting fan only mode for this unit. Confirm that mode is supported on your remote. Defaults to ``false``.
|
||||
|
||||
- **horizontal_default** (*Optional*, string): What to default to when the AC unit's horizontal direction is *not* set to swing. Defaults to ``middle``.
|
||||
- **horizontal_default** (*Optional*, string): What to default to when the AC unit's horizontal direction is *not* set to swing. Defaults to ``middle``.
|
||||
|
||||
- Options are: ``left``, ``middle-left``, ``middle``, ``middle-right``, ``right``, ``auto``
|
||||
- **vertical_default** (*Optional*, string): What to default to when the AC unit's vertical direction is *not* set to swing. Defaults to ``middle``.
|
||||
- **vertical_default** (*Optional*, string): What to default to when the AC unit's vertical direction is *not* set to swing. Defaults to ``middle``.
|
||||
|
||||
- Options are: ``down``, ``middle-down``, ``middle``, ``middle-up``, ``up``, ``auto``
|
||||
|
||||
@ -423,8 +423,8 @@ Configuration variables:
|
||||
``zhlt01`` Climate
|
||||
---------------------
|
||||
|
||||
ZH/LT-01 is a remote control that is used with many locally branded split airconditioners.
|
||||
Supported brands include:
|
||||
ZH/LT-01 is a remote control that is used with many locally branded split airconditioners.
|
||||
Supported brands include:
|
||||
|
||||
- Eurom
|
||||
- Chigo
|
||||
|
||||
@ -1,21 +1,27 @@
|
||||
Custom Climate
|
||||
==============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Custom C++ climate components with ESPHome.
|
||||
:image: language-cpp.svg
|
||||
:keywords: C++, Custom
|
||||
|
||||
.. warning::
|
||||
|
||||
Custom components are deprecated, not recommended for new configurations
|
||||
and will be removed from ESPHome in a future release.
|
||||
Please look at creating a real ESPHome component and "importing" it into your
|
||||
configuration with :doc:`/components/external_components`.
|
||||
Custom components are deprecated, not recommended for new configurations and will be removed from ESPHome in a
|
||||
future release. Please look at creating a real ESPHome component and "importing" it into your configuration with
|
||||
:doc:`/components/external_components`.
|
||||
|
||||
You can find some basic documentation on creating your own components
|
||||
at :ref:`contributing_to_esphome`.
|
||||
You can find some basic documentation on creating your own components at :ref:`contributing_to_esphome`.
|
||||
|
||||
This integration can be used to create custom climate devices in ESPHome
|
||||
using the C++ (Arduino) API.
|
||||
.. warning::
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide,
|
||||
the same principles apply here.
|
||||
While we try to keep the ESPHome YAML configuration options as stable as possible, the ESPHome API is less
|
||||
stable. If something in the APIs needs to be changed in order for something else to work, we will do so.
|
||||
|
||||
This component can be used to create custom climate devices in ESPHome using the C++ (Arduino) API.
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide, the same principles apply here.
|
||||
|
||||
The example below is an example of a custom climate device - all climate devices must override
|
||||
two methods (:apiclass:`Climate <climate::Climate>`):
|
||||
|
||||
@ -58,18 +58,11 @@ This component requires a :ref:`uart` to be setup.
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
|
||||
uart:
|
||||
baud_rate: 9600
|
||||
tx_pin: 17
|
||||
rx_pin: 16
|
||||
id: ac_port
|
||||
|
||||
climate:
|
||||
- platform: haier
|
||||
id: haier_ac
|
||||
protocol: hOn
|
||||
name: Haier AC
|
||||
name: Haier AC
|
||||
uart_id: ac_port
|
||||
wifi_signal: true
|
||||
beeper: true
|
||||
|
||||
@ -25,17 +25,6 @@ The ``midea`` component creates a Midea air conditioner climate device.
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
|
||||
# Disable logging over UART (required)
|
||||
logger:
|
||||
baud_rate: 0
|
||||
|
||||
# UART settings for Midea dongle (required)
|
||||
uart:
|
||||
tx_pin: 1 # hardware dependant
|
||||
rx_pin: 3 # hardware dependant
|
||||
baud_rate: 9600
|
||||
|
||||
# Main settings
|
||||
climate:
|
||||
- platform: midea
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
Copy Integration
|
||||
================
|
||||
Copy Component
|
||||
==============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the copy integration in ESPHome
|
||||
:description: Instructions for setting up the copy component in ESPHome
|
||||
:image: content-copy.svg
|
||||
|
||||
The ``copy`` integration can be used to copy an existing component (like a sensor, switch, etc.)
|
||||
The ``copy`` component can be used to copy an existing component (like a sensor, switch, etc.)
|
||||
and create a duplicate mirroring the source's state and forwarding actions such as turning on to the source.
|
||||
|
||||
For each of the supported platforms, the configuration consists of the required configuration
|
||||
|
||||
@ -1,24 +1,29 @@
|
||||
Custom Cover
|
||||
============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Custom C++ covers with ESPHome.
|
||||
:image: language-cpp.svg
|
||||
:keywords: C++, Custom
|
||||
|
||||
.. warning::
|
||||
|
||||
Custom components are deprecated, not recommended for new configurations
|
||||
and will be removed from ESPHome in a future release.
|
||||
Please look at creating a real ESPHome component and "importing" it into your
|
||||
configuration with :doc:`/components/external_components`.
|
||||
Custom components are deprecated, not recommended for new configurations and will be removed from ESPHome in a
|
||||
future release. Please look at creating a real ESPHome component and "importing" it into your configuration with
|
||||
:doc:`/components/external_components`.
|
||||
|
||||
You can find some basic documentation on creating your own components
|
||||
at :ref:`contributing_to_esphome`.
|
||||
You can find some basic documentation on creating your own components at :ref:`contributing_to_esphome`.
|
||||
|
||||
This integration can be used to create custom covers in ESPHome
|
||||
using the C++ (Arduino) API.
|
||||
.. warning::
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide,
|
||||
the same principles apply here.
|
||||
While we try to keep the ESPHome YAML configuration options as stable as possible, the ESPHome API is less
|
||||
stable. If something in the APIs needs to be changed in order for something else to work, we will do so.
|
||||
|
||||
The example below is an example of a custom cover - all covers must override
|
||||
two methods:
|
||||
This component can be used to create custom covers in ESPHome using the C++ (Arduino) API.
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide, the same principles apply here.
|
||||
|
||||
The example below is an example of a custom cover - all covers must override two methods:
|
||||
|
||||
- ``get_traits``: This should return a :apiclass:`CoverTraits <cover::CoverTraits>` object
|
||||
representing the capabilities of the cover.
|
||||
|
||||
@ -45,7 +45,7 @@ Configuration variables:
|
||||
Supported devices
|
||||
-----------------
|
||||
|
||||
Tuya cover devices known to be supported by this integration:
|
||||
Tuya cover devices known to be supported by this component:
|
||||
|
||||
- Tuya ``M515EGWT`` (motor for bead chain roller blinds)
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
Demo Integration
|
||||
================
|
||||
Demo Component
|
||||
==============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the demo integration in ESPHome
|
||||
:description: Instructions for setting up the demo component in ESPHome
|
||||
:image: description.svg
|
||||
|
||||
The ``demo`` integration can be used for testing to generate sample instances of many
|
||||
different integrations (sensors, lights, ...)
|
||||
The ``demo`` component can be used for testing to generate sample instances of many
|
||||
different components (sensors, lights, ...)
|
||||
|
||||
.. figure:: images/demo-ui.png
|
||||
:align: center
|
||||
@ -20,7 +20,7 @@ different integrations (sensors, lights, ...)
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
This integration has no configuration variables
|
||||
This component has no configuration variables
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
@ -2,7 +2,7 @@ DF-Player mini
|
||||
==============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up DF Player Mini integration in ESPHome.
|
||||
:description: Instructions for setting up DF Player Mini component in ESPHome.
|
||||
:image: dfplayer.svg
|
||||
|
||||
The ``dfplayer`` (`datasheet <https://wiki.dfrobot.com/DFPlayer_Mini_SKU_DFR0299>`__), component
|
||||
@ -14,8 +14,7 @@ allows you to play sound and music stored in an SD card or USB flash drive.
|
||||
|
||||
DF-Player mini Module.
|
||||
|
||||
For this integration to work you need to have set up a :ref:`UART bus <uart>`
|
||||
in your configuration.
|
||||
For this component to work you need to have set up a :ref:`UART bus <uart>` in your configuration.
|
||||
|
||||
Overview
|
||||
--------
|
||||
@ -31,16 +30,7 @@ will be required.
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
tx_pin: GPIO2
|
||||
rx_pin: GPIO5
|
||||
baud_rate: 9600
|
||||
|
||||
# Declare DFPlayer mini module
|
||||
dfplayer:
|
||||
on_finished_playback:
|
||||
then:
|
||||
logger.log: 'Somebody press play!'
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
@ -114,11 +104,11 @@ Configuration options:
|
||||
``dfplayer.play_mp3`` Action
|
||||
----------------------------
|
||||
|
||||
Plays a track inside the folder ``mp3``. Files inside the folder must be numbered from 1
|
||||
Plays a track inside the folder ``mp3``. Files inside the folder must be numbered from 1
|
||||
to 9999, like ``0001.mp3``, ``0002.mp3``, ... etc.
|
||||
The folder name needs to be ``mp3``, placed under the SD card root directory, and the
|
||||
mp3 file name needs to be 4 digits, for example, "0001.mp3", placed under the mp3 folder.
|
||||
If you want, you can add additional text after the number in the filename, for example,
|
||||
The folder name needs to be ``mp3``, placed under the SD card root directory, and the
|
||||
mp3 file name needs to be 4 digits, for example, "0001.mp3", placed under the mp3 folder.
|
||||
If you want, you can add additional text after the number in the filename, for example,
|
||||
``0001hello.mp3``, but must always be referenced by number only in yaml.
|
||||
|
||||
.. code-block:: bash
|
||||
@ -345,8 +335,8 @@ Sample code
|
||||
.. code-block:: yaml
|
||||
|
||||
uart:
|
||||
tx_pin: GPIO2
|
||||
rx_pin: GPIO5
|
||||
tx_pin: GPIOXX
|
||||
rx_pin: GPIOXX
|
||||
baud_rate: 9600
|
||||
|
||||
dfplayer:
|
||||
|
||||
@ -19,18 +19,6 @@ The display requires that an :apiclass:`AddressableLight <light::AddressableLigh
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
light:
|
||||
- platform: fastled_clockless
|
||||
chipset: WS2812B
|
||||
pin: GPIO4
|
||||
num_leds: 64
|
||||
rgb_order: GRB
|
||||
name: "led_matrix"
|
||||
id: led_matrix_light
|
||||
default_transition_length: 0s
|
||||
color_correct: [50%, 50%, 50%]
|
||||
restore_mode: ALWAYS_ON
|
||||
|
||||
display:
|
||||
- platform: addressable_light
|
||||
id: led_matrix_display
|
||||
@ -61,10 +49,10 @@ Configuration variables:
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): The interval to call the lambda to update the display.
|
||||
Defaults to ``16ms``.
|
||||
- **pixel_mapper** (*Optional*, :ref:`lambda <config-lambda>`): A lambda that returns the integer address of the LED
|
||||
given the supplied the ``x`` and ``y`` pixel coordinate. By default, a left-to-right direct pixel mapper is used.
|
||||
given the supplied the ``x`` and ``y`` pixel coordinate. By default, a left-to-right direct pixel mapper is used.
|
||||
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
|
||||
``it`` will be an instance of :apiclass:`DisplayBuffer <display::DisplayBuffer>`.
|
||||
See :ref:`display-engine` for more information.
|
||||
See :ref:`display-engine` for more information.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
|
||||
|
||||
@ -73,7 +61,7 @@ Configuration variables:
|
||||
When enabled (the default, but also via ``it.set_enabled(true)``), any effect currently running on the
|
||||
addressable light will be disabled. When disabled (``it.set_enabled(false)``), the last configured effect will
|
||||
be restored.
|
||||
|
||||
|
||||
While the display is enabled, it is still possible to control the parent addressable light component in some
|
||||
limited capacity. Changing the brightness will still work, but changing the color will have no affect. It is not
|
||||
adivsable to enable any effects (ex: rainbow, color wipe, etc) while the display is enabled, as this will cause a
|
||||
|
||||
@ -55,8 +55,8 @@ beyond the basic SPI connections, and a reasonable amount of RAM, it is not well
|
||||
display:
|
||||
- platform: ili9xxx
|
||||
model: ili9341
|
||||
dc_pin: 27
|
||||
reset_pin: 33
|
||||
dc_pin: GPIOXX
|
||||
reset_pin: GPIOXX
|
||||
lambda: |-
|
||||
it.fill(COLOR_BLACK);
|
||||
it.print(0, 0, id(my_font), id(my_red), TextAlign::TOP_LEFT, "Hello World!");
|
||||
@ -180,13 +180,13 @@ To configure a dimmable backlight:
|
||||
# Define a PWM output on the ESP32
|
||||
output:
|
||||
- platform: ledc
|
||||
pin: 32
|
||||
id: gpio_32_backlight_pwm
|
||||
pin: GPIOXX
|
||||
id: backlight_pwm
|
||||
|
||||
# Define a monochromatic, dimmable light for the backlight
|
||||
light:
|
||||
- platform: monochromatic
|
||||
output: gpio_32_backlight_pwm
|
||||
output: backlight_pwm
|
||||
name: "Display Backlight"
|
||||
id: back_light
|
||||
restore_mode: ALWAYS_ON
|
||||
@ -204,8 +204,8 @@ To configure an image adaptive color pallet to show greater than 8 bit color dep
|
||||
display:
|
||||
- platform: ili9xxx
|
||||
model: ili9341
|
||||
dc_pin: 4
|
||||
reset_pin: 22
|
||||
dc_pin: GPIOXX
|
||||
reset_pin: GPIOXX
|
||||
rotation: 90
|
||||
id: tft_ha
|
||||
color_palette: IMAGE_ADAPTIVE
|
||||
@ -234,7 +234,7 @@ This config rotates the display into landscape mode using the driver chip.
|
||||
mirror_y: true
|
||||
color_order: bgr
|
||||
data_rate: 80MHz
|
||||
cs_pin: 10
|
||||
cs_pin: GPIOXX
|
||||
dc_pin: GPIO13
|
||||
reset_pin: GPIO9
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Display Component
|
||||
=================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up the display integration.
|
||||
:description: Instructions for setting up the display component.
|
||||
:image: folder-open.svg
|
||||
|
||||
The ``display`` component houses ESPHome's powerful rendering and display
|
||||
|
||||
@ -2,12 +2,12 @@ Character-Based LCD Display
|
||||
===========================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up character-based HD44780 LCD displays.
|
||||
:description: Instructions for setting up character-based HD44780 LCDs.
|
||||
:image: lcd.jpg
|
||||
|
||||
The ``lcd_pcf8574`` and ``lcd_gpio`` display components allow you to use HD44780-compatible, character-based LCD displays
|
||||
with ESPHome. This integration is only for LCD displays that display individual characters on a screen
|
||||
(usually 8-40 columns and 2-4 rows), and not for LCD displays that can control each pixel individually.
|
||||
The ``lcd_pcf8574`` and ``lcd_gpio`` display components allow you to use HD44780-compatible, character-based LCDs
|
||||
with ESPHome. This component is only for LCDs that display individual characters on a screen
|
||||
(usually 8-40 columns and 2-4 rows), and not for LCDs that can control each pixel individually.
|
||||
|
||||
.. figure:: images/lcd-hello_world.jpg
|
||||
:align: center
|
||||
@ -15,12 +15,12 @@ with ESPHome. This integration is only for LCD displays that display individual
|
||||
|
||||
.. note::
|
||||
|
||||
Multiple versions of the display exist, supporting different character sets:
|
||||
|
||||
Multiple versions of the display exist, supporting different character sets:
|
||||
|
||||
- HD44780UA00 English-Japanese which includes katakana characters, some Greek letters and mathematical symbols
|
||||
- HD44780UA02 English-European which includes Greek, Cyrillic and Western European characters (with some diacritics)
|
||||
- HD44780UBxx custom, manufacturer-specific character sets
|
||||
|
||||
|
||||
It is also possible to add eight user-defined characters.
|
||||
|
||||
.. _lcd-pcf8574:
|
||||
@ -28,7 +28,7 @@ with ESPHome. This integration is only for LCD displays that display individual
|
||||
lcd_pcf8574 Component
|
||||
---------------------
|
||||
|
||||
``lcd_pcf8574`` is for LCD displays with a PCF8574 GPIO expander module connected to all the data pins. This has the
|
||||
``lcd_pcf8574`` is for LCD displays with a PCF8574 GPIO expander module 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 six or ten as with the :ref:`lcd-gpio`.
|
||||
The communication happens via :ref:`I²C Bus <i2c>`, you need to have an ``i2c:`` section in your configuration.
|
||||
|
||||
@ -65,7 +65,7 @@ Configuration variables:
|
||||
|
||||
.. note::
|
||||
|
||||
If you're not seeing anything on the display, try turning the contrast potentiometer around on the
|
||||
If you're not seeing anything on the display, try turning the contrast potentiometer around on the
|
||||
PCF8574 board.
|
||||
|
||||
.. _lcd-gpio:
|
||||
@ -74,7 +74,7 @@ lcd_gpio Component
|
||||
------------------
|
||||
|
||||
The ``lcd_gpio`` version of this component addresses the screen directly and does not employ a GPIO expander module.
|
||||
Each of the data pins of the LCD needs a dedicated GPIO pin on the ESP. Connecting the screen this way offers
|
||||
Each of the data pins of the LCD needs a dedicated GPIO pin on the ESP. Connecting the screen this way offers
|
||||
faster refresh, especially in conjunction with an :ref:`LCD Menu <lcd_menu>`.
|
||||
|
||||
.. figure:: images/lcd_gpio.svg
|
||||
@ -90,12 +90,12 @@ faster refresh, especially in conjunction with an :ref:`LCD Menu <lcd_menu>`.
|
||||
- platform: lcd_gpio
|
||||
dimensions: 20x4
|
||||
data_pins:
|
||||
- GPIO32
|
||||
- GPIO33
|
||||
- GPIO5
|
||||
- GPIO17
|
||||
enable_pin: D4
|
||||
rs_pin: D5
|
||||
- GPIOXX
|
||||
- GPIOXX
|
||||
- GPIOXX
|
||||
- GPIOXX
|
||||
enable_pin: GPIOXX
|
||||
rs_pin: GPIOXX
|
||||
lambda: |-
|
||||
it.print("Hello World!");
|
||||
|
||||
@ -105,8 +105,8 @@ Configuration variables:
|
||||
- **dimensions** (**Required**, string): The dimensions of the display with ``COLUMNSxROWS``. If you're not
|
||||
sure, power the display on, turn contrast high up and just count them.
|
||||
- **data_pins** (**Required**, list of :ref:`pins <config-pin_schema>`): A list of the data pins you
|
||||
have hooked up to the LCD. The list can either be 4 items long (operating in 4-bit mode with
|
||||
either the first 4 data pins connected or the last 4 data pins connected), or 8 items long (when you have
|
||||
have hooked up to the LCD. The list can either be 4 items long (operating in 4-bit mode with
|
||||
either the first 4 data pins connected or the last 4 data pins connected), or 8 items long (when you have
|
||||
connected all 8 data pins).
|
||||
- **enable_pin** (**Required**, :ref:`pin <config-pin_schema>`): The pin you have ``E`` (``06``) hooked up to.
|
||||
- **rs_pin** (**Required**, :ref:`pin <config-pin_schema>`): The pin you have ``RS`` (``04``) hooked up to.
|
||||
@ -118,7 +118,7 @@ Configuration variables:
|
||||
|
||||
.. note::
|
||||
|
||||
If you're not seeing anything on the display, make sure you apply ``3.3V`` to the ``VEE`` (``03``) contrast control
|
||||
If you're not seeing anything on the display, make sure you apply ``3.3V`` to the ``VEE`` (``03``) contrast control
|
||||
pin of the board. You can use a potentiometer to make it adjustable.
|
||||
|
||||
|
||||
@ -177,7 +177,7 @@ The LCD display has the possibility to define up to eight user defined character
|
||||
``0`` to ``7`` and mirrored at ``8`` to ``15`` (i.e. ``\x08`` can be used instead of the ``\0`` that can
|
||||
be problematic in strings). Each character has eight lines of five bits, with the first line on the top
|
||||
and the most significant bit on the left, meaning that ``0b10000`` followed by six zeros and a ``0b00001``
|
||||
defines a dot at the upper left and lower right of the character.
|
||||
defines a dot at the upper left and lower right of the character.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -221,7 +221,7 @@ Keep in mind that the display lambda runs for every ``update_interval``, so if t
|
||||
it cannot be overridden from other parts.
|
||||
|
||||
With the ``lcd_gpio``, the backlight is lit by applying ``Vcc`` to the ``BLA`` (``15``) pin and connect ``BLK`` (``16``)
|
||||
pin to ``GND``. The backlight can draw more power than the microcontroller output pins can supply, so it is advisable
|
||||
pin to ``GND``. The backlight can draw more power than the microcontroller output pins can supply, so it is advisable
|
||||
to use a transistor as a switch to control the power for the backlight pins.
|
||||
|
||||
Below an example for a typical use-case where the backlight is turned on when a motion sensor activates and
|
||||
|
||||
@ -8,7 +8,7 @@ MAX7219 7-Segment Display
|
||||
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.
|
||||
with ESPHome. Please note that this component is *only* for 7-segment display, not matrix configurations.
|
||||
|
||||
.. figure:: images/max7219-full.jpg
|
||||
:align: center
|
||||
@ -16,7 +16,7 @@ with ESPHome. Please note that this integration is *only* for 7-segment display,
|
||||
|
||||
MAX7219 7-Segment Display.
|
||||
|
||||
As the communication with the MAX7219 is done using SPI for this integration, you need
|
||||
As the communication with the MAX7219 is done using SPI for this component, you need
|
||||
to have an :ref:`SPI bus <spi>` in your configuration with both the **mosi_pin** set (miso_pin is not required).
|
||||
Connect VCC to 3.3V (the manufacturer recommends 4+ V, but 3.3V seems to work fine), DIN to your ``mosi_pin`` and
|
||||
CS to your set ``cs_pin`` and finally GND to GND.
|
||||
|
||||
@ -5,7 +5,7 @@ MAX7219 Digit Display
|
||||
:description: Instructions for setting up MAX7219 Digit displays.
|
||||
:image: max7219digit.jpg
|
||||
|
||||
The ``max7219`` display platform allows you to use MAX7219 digit with ESPHome. Please note that this integration
|
||||
The ``max7219`` display platform allows you to use MAX7219 digit with ESPHome. Please note that this component
|
||||
is *only* for the digit "matrix" display, for the 7 segment display see :doc:`max7219`.
|
||||
|
||||
.. figure:: images/max7219digit.png
|
||||
@ -14,7 +14,7 @@ is *only* for the digit "matrix" display, for the 7 segment display see :doc:`ma
|
||||
|
||||
MAX7219 Digit Display.
|
||||
|
||||
As the communication with the MAX7219 Digit is done using SPI for this integration, you need
|
||||
As the communication with the MAX7219 Digit is done using SPI for this component, you need
|
||||
to have an :ref:`SPI bus <spi>` in your configuration with both the **mosi_pin** set (miso_pin is not required).
|
||||
Connect VCC to 3.3V (the manufacturer recommends 4+ V, but 3.3V seems to work fine), DIN to your ``mosi_pin`` and
|
||||
CS to your set ``cs_pin`` and finally GND to GND.
|
||||
|
||||
@ -18,15 +18,15 @@ with ESPHome.
|
||||
As the communication with the Nextion LCD display is done using UART, you need to have an :ref:`UART bus <uart>`
|
||||
in your configuration with ``rx_pin`` both the ``tx_pin`` set to the respective pins on the display.
|
||||
The Nextion uses a baud rate of 9600 by default. It may be configured to use a faster speed by adding (for
|
||||
example)
|
||||
example)
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
baud=115200 // Sets the baud rate to 115200
|
||||
bkcmd=0 // Tells the Nextion to not send responses on commands. This is the current default but can be set just in case
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
to the ``program.s`` source file (in the Nextion Editor) before the ``page`` line.
|
||||
This permits faster communication with the Nextion display and it is highly recommended when using :ref:`uart-hardware_uarts`. Without a hardware uart make sure to set the baud rate to 9600.
|
||||
|
||||
@ -36,17 +36,9 @@ The below example configures a UART for the Nextion display to use
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
id: uart_2
|
||||
rx_pin: GPIO16
|
||||
tx_pin: GPIO17
|
||||
baud_rate: 115200
|
||||
|
||||
|
||||
display:
|
||||
- platform: nextion
|
||||
id: nextion1
|
||||
uart_id: uart_2
|
||||
lambda: |-
|
||||
it.set_component_value("gauge", 50);
|
||||
it.set_component_text("textview", "Hello World!");
|
||||
@ -73,7 +65,7 @@ Configuration variables:
|
||||
- **on_wake** (*Optional*, :ref:`Action <config-action>`): An action to be performed when the Nextion wakes up. See :ref:`Nextion Automation <nextion-on_sleep>`.
|
||||
- **on_page** (*Optional*, :ref:`Action <config-action>`): An action to be performed after a page change. See :ref:`Nextion Automation <nextion-on_page>`.
|
||||
- **on_touch** (*Optional*, :ref:`Action <config-action>`): An action to be performed after a touch event (press or release). See :ref:`Nextion Automation <nextion-on_touch>`.
|
||||
|
||||
|
||||
.. _display-nextion_lambda:
|
||||
|
||||
Rendering Lambda
|
||||
@ -113,7 +105,7 @@ Lambda Calls
|
||||
************
|
||||
|
||||
Several methods are available for use within :ref:`lambdas <config-lambda>`; these permit advanced functionality beyond simple
|
||||
display updates. See the full :apiref:`nextion/nextion.h` for more info.
|
||||
display updates. See the full :apiref:`nextion/nextion.h` for more info.
|
||||
|
||||
.. _nextion_upload_tft:
|
||||
|
||||
@ -126,7 +118,7 @@ The developer tools in Home Assistant can be used to trigger the update. The bel
|
||||
services:
|
||||
- service: update_nextion
|
||||
then:
|
||||
- lambda: 'id(nextion1)->upload_tft();'
|
||||
- lambda: 'id(nextion1)->upload_tft();'
|
||||
|
||||
.. _nextion_update_all_components:
|
||||
|
||||
@ -178,7 +170,7 @@ The developer tools in Home Assistant can be used to trigger the update. The bel
|
||||
|
||||
.. _nextion_queue_types:
|
||||
|
||||
Queue Types:
|
||||
Queue Types:
|
||||
- SENSOR 0
|
||||
- BINARY_SENSOR 1
|
||||
- SWITCH 2
|
||||
@ -291,7 +283,7 @@ The following arguments will be available:
|
||||
Uploading A TFT File
|
||||
--------------------
|
||||
This will download the file from the tft_url and will transfer it over the UART to the Nextion.
|
||||
Once completed both the ESP and Nextion will reboot. During the upload process esphome will be
|
||||
Once completed both the ESP and Nextion will reboot. During the upload process esphome will be
|
||||
unresponsive and no logging will take place. This uses the same protocol as the Nextion editor and
|
||||
only updates the changes of the TFT file. If HTTPS/SSL is enabled it will be about 1kB/sec.
|
||||
|
||||
@ -304,7 +296,7 @@ To host the TFT file you can use Home Assistant itself or any other web server.
|
||||
|
||||
Home Assistant
|
||||
**************
|
||||
To host the TFT file from Home Assistant, create a www directory if it doesn't exist in your config
|
||||
To host the TFT file from Home Assistant, create a www directory if it doesn't exist in your config
|
||||
directory. You can create a subdirectory for those files as well.
|
||||
|
||||
For example if the file is located
|
||||
@ -321,8 +313,8 @@ The below NGINX example configuration will serve files out of the /var/www/nexti
|
||||
.. code-block:: nginx
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
access_log /var/log/nginx/nextion_access.log;
|
||||
listen 80;
|
||||
access_log /var/log/nginx/nextion_access.log;
|
||||
error_log /var/log/nginx/nextion_error.log;
|
||||
root /var/www/nextion;
|
||||
}
|
||||
|
||||
@ -50,9 +50,9 @@ ESP-IDF. PSRAM is a requirement due to the size of the display buffer. A :ref:`q
|
||||
color_order: rgb
|
||||
invert_colors: false
|
||||
brightness: 255
|
||||
cs_pin: 11
|
||||
reset_pin: 13
|
||||
enable_pin: 9
|
||||
cs_pin: GPIOXX
|
||||
reset_pin: GPIOXX
|
||||
enable_pin: GPIOXX
|
||||
|
||||
|
||||
Configuration variables:
|
||||
@ -150,17 +150,17 @@ Lilygo T-Display S3 AMOLED
|
||||
- 7
|
||||
- 48
|
||||
- 5
|
||||
|
||||
|
||||
i2c:
|
||||
sda: 3
|
||||
scl: 2
|
||||
|
||||
|
||||
touchscreen:
|
||||
- platform: cst816
|
||||
id: my_touchscreen
|
||||
interrupt_pin:
|
||||
number: 21
|
||||
|
||||
|
||||
display:
|
||||
- platform: qspi_amoled
|
||||
model: RM67162
|
||||
|
||||
@ -40,17 +40,13 @@ to an ESP module.
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example minimal configuration entry
|
||||
spi:
|
||||
clk_pin: GPIO18
|
||||
mosi_pin: GPIO19
|
||||
|
||||
display:
|
||||
- platform: st7789v
|
||||
model: TTGO TDisplay 135x240
|
||||
backlight_pin: GPIO4
|
||||
cs_pin: GPIO5
|
||||
dc_pin: GPIO16
|
||||
reset_pin: GPIO23
|
||||
backlight_pin: GPIOXX
|
||||
cs_pin: GPIOXX
|
||||
dc_pin: GPIOXX
|
||||
reset_pin: GPIOXX
|
||||
lambda: |-
|
||||
it.print(0, 0, id(font), "Hello World!");
|
||||
|
||||
@ -191,7 +187,7 @@ Items marked RQ are hardware dependent but required and not preset. Items marked
|
||||
- 22
|
||||
- 23
|
||||
- 4
|
||||
-
|
||||
-
|
||||
- 18
|
||||
- 19
|
||||
* - Custom
|
||||
|
||||
@ -22,10 +22,10 @@ The LCD have four signal, ``cs`` for chip select, ``data`` for data signal, ``re
|
||||
display:
|
||||
platform: tm1621
|
||||
id: tm1621_display
|
||||
cs_pin: GPIO17
|
||||
data_pin: GPIO5
|
||||
read_pin: GPIO23
|
||||
write_pin: GPIO18
|
||||
cs_pin: GPIOXX
|
||||
data_pin: GPIOXX
|
||||
read_pin: GPIOXX
|
||||
write_pin: GPIOXX
|
||||
lambda: |-
|
||||
it.printf(0, "%.1f", id(my_sensor1).state);
|
||||
it.display_celsius(true);
|
||||
@ -82,7 +82,7 @@ Also we have five function to display or not some unites:
|
||||
- °F on the first line : ``display_fahrenheit(bool)``
|
||||
- %HR on the second line : ``display_humidity(bool)``
|
||||
- V on the first line and A on the second line : ``display_voltage(bool)``
|
||||
- kW/h on the first line and W on the second line : ``display_kwh(bool)``
|
||||
- kW/h on the first line and W on the second line : ``display_kwh(bool)``
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
@ -23,9 +23,9 @@ The module can be powered with 5v DC. To display the colon punctuation use the
|
||||
display:
|
||||
platform: tm1638
|
||||
id: tm1638_display
|
||||
stb_pin: 5
|
||||
clk_pin: 18
|
||||
dio_pin: 23
|
||||
stb_pin: GPIOXX
|
||||
clk_pin: GPIOXX
|
||||
dio_pin: GPIOXX
|
||||
intensity: 5
|
||||
update_interval: 5s
|
||||
lambda: |-
|
||||
@ -113,9 +113,9 @@ The following example creates a typical digital clock with the ``:`` colon flash
|
||||
|
||||
display:
|
||||
platform: tm1638
|
||||
clk_pin: 18
|
||||
dio_pin: 23
|
||||
stb_pin: 5
|
||||
clk_pin: GPIOXX
|
||||
dio_pin: GPIOXX
|
||||
stb_pin: GPIOXX
|
||||
update_interval: 500ms
|
||||
lambda: |-
|
||||
static int i = 0;
|
||||
@ -132,16 +132,16 @@ The TM1638 7 Segment Display Keypad & LED Module has 8 LED lights across the top
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
switch:
|
||||
switch:
|
||||
- platform: tm1638
|
||||
id: TM1638Led1
|
||||
led: 0
|
||||
|
||||
|
||||
output:
|
||||
- platform: tm1638
|
||||
id: TM1638Led2
|
||||
led: 1
|
||||
|
||||
|
||||
|
||||
|
||||
Buttons
|
||||
@ -163,7 +163,7 @@ The TM1638 7 Segment Display Keypad & LED Module has 8 buttons across the top or
|
||||
on_release:
|
||||
then:
|
||||
- switch.turn_off: TM1638Led1
|
||||
|
||||
|
||||
- platform: tm1638
|
||||
name: "TM1638 Button 2"
|
||||
id: TM1638Button2
|
||||
|
||||
@ -23,7 +23,7 @@ single-color E-Ink displays are implemented and of those only a few modules.
|
||||
|
||||
Waveshare E-Paper 2.9 Inch E-Paper Display.
|
||||
|
||||
The communication ESPHome has chosen to use for this integration is 4-wire :ref:`SPI <spi>`, as it's the most stable
|
||||
The communication ESPHome has chosen to use for this component is 4-wire :ref:`SPI <spi>`, as it's the most stable
|
||||
and high-speed. So you need to make sure your board is set to the 4-wire SPI mode and have an ``spi:`` section in your
|
||||
configuration.
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ ESPHome node, without the requirement of a network connection.
|
||||
Overview
|
||||
--------
|
||||
|
||||
The integration implements the :ref:`Display Menu <display_menu>` integration providing
|
||||
The component implements the :ref:`Display Menu <display_menu>` component providing
|
||||
a hierarchical menu primarily intended to be controlled either by a rotary encoder
|
||||
with a button or a five-button joystick controller.
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ Display Menu
|
||||
|
||||
.. _display_menu:
|
||||
|
||||
The integration provides a menu primarily intended to be controlled either by a rotary encoder
|
||||
The component provides a menu primarily intended to be controlled either by a rotary encoder
|
||||
with a button or a five-button joystick controller. It allows to navigate a hierarchy of items
|
||||
and submenus with the ability to change the values and execute commands. The menu can
|
||||
be activated and deactivated on demand, allowing alternating between using the screen for
|
||||
@ -17,8 +17,8 @@ Overview
|
||||
--------
|
||||
|
||||
This document describes the configuration and automations common for the components implementing
|
||||
this integration. At the moment the character based LCD displays are supported using
|
||||
the :ref:`lcd_menu <lcd_menu>` integration and an instance of this is used in the configuration
|
||||
this component. At the moment the character based LCD displays are supported using
|
||||
the :ref:`lcd_menu <lcd_menu>` component and an instance of this is used in the configuration
|
||||
examples.
|
||||
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ ESPHome node, without the requirement of a network connection.
|
||||
Overview
|
||||
--------
|
||||
|
||||
The integration implements the :ref:`Display Menu <display_menu>` integration providing
|
||||
The component implements the :ref:`Display Menu <display_menu>` component providing
|
||||
a hierarchical menu primarily intended to be controlled either by a rotary encoder
|
||||
with a button or a five-button joystick controller.
|
||||
|
||||
|
||||
@ -14,16 +14,16 @@ directly integrate into Home Assistant through the native API.
|
||||
esp32_camera:
|
||||
name: My Camera
|
||||
external_clock:
|
||||
pin: GPIO27
|
||||
pin: GPIOXX
|
||||
frequency: 20MHz
|
||||
i2c_pins:
|
||||
sda: GPIO25
|
||||
scl: GPIO23
|
||||
data_pins: [GPIO17, GPIO35, GPIO34, GPIO5, GPIO39, GPIO18, GPIO36, GPIO19]
|
||||
vsync_pin: GPIO22
|
||||
href_pin: GPIO26
|
||||
pixel_clock_pin: GPIO21
|
||||
reset_pin: GPIO15
|
||||
sda: GPIOXX
|
||||
scl: GPIOXX
|
||||
data_pins: [GPIOXX, GPIOXX, GPIOXX, GPIOXX, GPIOXX, GPIOXX, GPIOXX, GPIOXX]
|
||||
vsync_pin: GPIOXX
|
||||
href_pin: GPIOXX
|
||||
pixel_clock_pin: GPIOXX
|
||||
reset_pin: GPIOXX
|
||||
resolution: 640x480
|
||||
jpeg_quality: 10
|
||||
|
||||
|
||||
@ -17,8 +17,8 @@ This component and the Wi-Fi component may **not** be used simultaneously, even
|
||||
# Example configuration entry for RMII chips
|
||||
ethernet:
|
||||
type: LAN8720
|
||||
mdc_pin: GPIO23
|
||||
mdio_pin: GPIO18
|
||||
mdc_pin: GPIOXX
|
||||
mdio_pin: GPIOXX
|
||||
clk_mode: GPIO0_IN
|
||||
phy_addr: 0
|
||||
|
||||
@ -33,12 +33,12 @@ This component and the Wi-Fi component may **not** be used simultaneously, even
|
||||
# Example configuration entry for SPI chips
|
||||
ethernet:
|
||||
type: W5500
|
||||
clk_pin: GPIO19
|
||||
mosi_pin: GPIO21
|
||||
miso_pin: GPIO23
|
||||
cs_pin: GPIO18
|
||||
interrupt_pin: GPIO36
|
||||
reset_pin: GPIO22
|
||||
clk_pin: GPIOXX
|
||||
mosi_pin: GPIOXX
|
||||
miso_pin: GPIOXX
|
||||
cs_pin: GPIOXX
|
||||
interrupt_pin: GPIOXX
|
||||
reset_pin: GPIOXX
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
@ -52,7 +52,7 @@ minute, the indicator will be on.
|
||||
|
||||
switch:
|
||||
- platform: gpio
|
||||
pin: GPIO22
|
||||
pin: GPIOXX
|
||||
id: led
|
||||
|
||||
script:
|
||||
|
||||
@ -14,18 +14,13 @@ The ``binary`` fan platform lets you represent any binary :ref:`output` as a fan
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
output:
|
||||
- id: fan_output
|
||||
platform: gpio
|
||||
pin: GPIO16
|
||||
|
||||
fan:
|
||||
- platform: binary
|
||||
output: fan_output
|
||||
name: "Living Room Fan"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
@ -23,14 +23,6 @@ The ``hbridge`` fan platform allows you to use a compatible *h-bridge* (L298N, D
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
output:
|
||||
- platform: ...
|
||||
id: motor_forward_pin
|
||||
pin: GPIO5
|
||||
- platform: ...
|
||||
id: motor_reverse_pin
|
||||
pin: GPIO4
|
||||
|
||||
fan:
|
||||
- platform: hbridge
|
||||
id: my_fan
|
||||
|
||||
@ -2,7 +2,7 @@ Grow Fingerprint Reader
|
||||
=======================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Grow Fingerprint Reader integration in ESPHome.
|
||||
:description: Instructions for setting up Grow Fingerprint Reader component in ESPHome.
|
||||
:image: fingerprint.svg
|
||||
|
||||
The ``fingerprint_grow`` component allows you to use your R307, R503, R503-RGB, ZFM-20, ... fingerprint sensors with ESPHome.
|
||||
@ -30,16 +30,10 @@ If available on your reader model, it's recommended to connect 3.3VT (touch indu
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
rx_pin: GPIO13
|
||||
tx_pin: GPIO15
|
||||
baud_rate: 57600
|
||||
|
||||
# Declare Grow Fingerprint Reader
|
||||
fingerprint_grow:
|
||||
sensing_pin: GPIO12
|
||||
sensing_pin: GPIOXX
|
||||
sensor_power_pin:
|
||||
number: GPIO18
|
||||
number: GPIOXX
|
||||
inverted: true
|
||||
idle_period_to_sleep: 5s
|
||||
|
||||
@ -93,46 +87,27 @@ Configuration variables:
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
|
||||
|
||||
Optional Sensor Configuration:
|
||||
|
||||
Sensor
|
||||
------
|
||||
|
||||
- **fingerprint_count**: The number of enrolled fingerprints stored on the reader.
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **last_finger_id**: The last matched enrolled fingerprint as set by :ref:`fingerprint_grow-on_finger_scan_matched`.
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **last_confidence**: The last matched confidence as set by :ref:`fingerprint_grow-on_finger_scan_matched`.
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **status**: The integer representation of the internal status register of the reader.
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **capacity**: The fingerprint storage capacity of the reader.
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
- **security_level**: The integer representation of the currently configured security level of the reader. Higher security levels reduce the false acceptance rate (FAR) at the expense of increasing the false rejection rate (FRR). Range is 1 (lowest) to 5 (highest).
|
||||
|
||||
- **name** (**Required**, string): The name for the sensor.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||
- All other options from :ref:`Sensor <config-sensor>`.
|
||||
All options from :ref:`Sensor <config-sensor>`.
|
||||
|
||||
.. _fingerprint_grow-sleep_mode:
|
||||
|
||||
@ -150,14 +125,14 @@ This is a wiring example for the R503 and below you can find the respective conf
|
||||
.. code-block:: yaml
|
||||
|
||||
uart:
|
||||
rx_pin: GPIO16
|
||||
tx_pin: GPIO17
|
||||
rx_pin: GPIOXX
|
||||
tx_pin: GPIOXX
|
||||
baud_rate: 57600
|
||||
|
||||
|
||||
fingerprint_grow:
|
||||
sensing_pin: GPIO4
|
||||
sensing_pin: GPIOXX
|
||||
sensor_power_pin:
|
||||
number: GPIO18
|
||||
number: GPIOXX
|
||||
inverted: true
|
||||
idle_period_to_sleep: 5s
|
||||
|
||||
@ -191,7 +166,7 @@ The ``new_password:`` configuration option is meant to be compiled, flashed to t
|
||||
``on_finger_scan_start`` Trigger
|
||||
------------------------------------
|
||||
|
||||
With this configuration option, you can trigger an automation when a finger is detected touching the sensor. Very useful to indicate to the user via AuraLed that the sensor has detected the finger touch and will perform the scan. This trigger will **only** activate if your fingerprint sensor is configured with the ``sensing_pin`` option.
|
||||
With this configuration option, you can trigger an automation when a finger is detected touching the sensor. Very useful to indicate to the user via AuraLed that the sensor has detected the finger touch and will perform the scan. This trigger will **only** activate if your fingerprint sensor is configured with the ``sensing_pin`` option.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -513,12 +488,12 @@ Sample code
|
||||
.. code-block:: yaml
|
||||
|
||||
uart:
|
||||
rx_pin: GPIO13
|
||||
tx_pin: GPIO15
|
||||
rx_pin: GPIOXX
|
||||
tx_pin: GPIOXX
|
||||
baud_rate: 57600
|
||||
|
||||
fingerprint_grow:
|
||||
sensing_pin: GPIO12
|
||||
sensing_pin: GPIOXX
|
||||
on_finger_scan_invalid:
|
||||
- homeassistant.event:
|
||||
event: esphome.test_node_finger_scan_invalid
|
||||
|
||||
@ -2,7 +2,7 @@ GPS Component
|
||||
=============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up GPS integration in ESPHome.
|
||||
:description: Instructions for setting up GPS component in ESPHome.
|
||||
:image: crosshairs-gps.svg
|
||||
|
||||
The ``gps`` component allows you to connect GPS modules to your ESPHome project.
|
||||
@ -16,15 +16,12 @@ Any GPS module that uses the standardized NMEA communication protocol will work.
|
||||
|
||||
.. _Adafruit: https://www.adafruit.com/product/746
|
||||
|
||||
For this integration to work you need to have set up a :ref:`UART bus <uart>`
|
||||
For this component to work you need to have set up a :ref:`UART bus <uart>`
|
||||
in your configuration - only the RX pin should be necessary.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
rx_pin: D7
|
||||
baud_rate: 9600
|
||||
|
||||
# Declare GPS module
|
||||
gps:
|
||||
|
||||
@ -20,8 +20,8 @@ connecting the wires from each device back to the two I²C pins on the ESP.
|
||||
|
||||
# Example configuration entry for ESP32
|
||||
i2c:
|
||||
sda: 21
|
||||
scl: 22
|
||||
sda: GPIOXX
|
||||
scl: GPIOXX
|
||||
scan: true
|
||||
id: bus_a
|
||||
|
||||
@ -51,12 +51,12 @@ Configuration variables:
|
||||
# Example configuration entry
|
||||
i2c:
|
||||
- id: bus_a
|
||||
sda: 13
|
||||
scl: 16
|
||||
sda: GPIOXX
|
||||
scl: GPIOXX
|
||||
scan: true
|
||||
- id: bus_b
|
||||
sda: 14
|
||||
scl: 15
|
||||
sda: GPIOXX
|
||||
scl: GPIOXX
|
||||
scan: true
|
||||
# Sensors should be specified as follows
|
||||
- platform: bme680
|
||||
|
||||
@ -14,8 +14,8 @@ This component only works on ESP32 based chips.
|
||||
|
||||
# Example configuration entry
|
||||
i2s_audio:
|
||||
i2s_lrclk_pin: GPIO33
|
||||
i2s_bclk_pin: GPIO19
|
||||
i2s_lrclk_pin: GPIOXX
|
||||
i2s_bclk_pin: GPIOXX
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
@ -20,10 +20,6 @@ The ``binary`` light platform creates a simple ON/OFF-only light from a
|
||||
name: "Desk Lamp"
|
||||
output: light_output
|
||||
|
||||
output:
|
||||
- id: light_output
|
||||
platform: gpio
|
||||
pin: GPIO16
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
@ -1,21 +1,27 @@
|
||||
Custom Light Output
|
||||
===================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Custom C++ lights with ESPHome.
|
||||
:image: language-cpp.svg
|
||||
:keywords: C++, Custom
|
||||
|
||||
.. warning::
|
||||
|
||||
Custom components are deprecated, not recommended for new configurations
|
||||
and will be removed from ESPHome in a future release.
|
||||
Please look at creating a real ESPHome component and "importing" it into your
|
||||
configuration with :doc:`/components/external_components`.
|
||||
Custom components are deprecated, not recommended for new configurations and will be removed from ESPHome in a
|
||||
future release. Please look at creating a real ESPHome component and "importing" it into your configuration with
|
||||
:doc:`/components/external_components`.
|
||||
|
||||
You can find some basic documentation on creating your own components
|
||||
at :ref:`contributing_to_esphome`.
|
||||
You can find some basic documentation on creating your own components at :ref:`contributing_to_esphome`.
|
||||
|
||||
This integration can be used to create custom lights in ESPHome
|
||||
using the C++ (Arduino) API.
|
||||
.. warning::
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide,
|
||||
the same principles apply here.
|
||||
While we try to keep the ESPHome YAML configuration options as stable as possible, the ESPHome API is less
|
||||
stable. If something in the APIs needs to be changed in order for something else to work, we will do so.
|
||||
|
||||
This component can be used to create custom lights in ESPHome using the C++ (Arduino) API.
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide, the same principles apply here.
|
||||
|
||||
All internal stuff (like effects, transitions etc) is handled by the light core
|
||||
and cannot be overridden. Light outputs are only responsible for displaying some state
|
||||
|
||||
@ -12,7 +12,7 @@ This is a component using the ESP32 RMT peripheral to drive most addressable LED
|
||||
light:
|
||||
- platform: esp32_rmt_led_strip
|
||||
rgb_order: GRB
|
||||
pin: GPIO13
|
||||
pin: GPIOXX
|
||||
num_leds: 30
|
||||
rmt_channel: 0
|
||||
chipset: ws2812
|
||||
|
||||
@ -47,7 +47,7 @@ Clockless FastLED lights differ from the
|
||||
light:
|
||||
- platform: fastled_clockless
|
||||
chipset: WS2811
|
||||
pin: GPIO23
|
||||
pin: GPIOXX
|
||||
num_leds: 60
|
||||
rgb_order: BRG
|
||||
name: "FastLED WS2811 Light"
|
||||
@ -126,8 +126,8 @@ whereas the clockless lights only need a single pin.
|
||||
light:
|
||||
- platform: fastled_spi
|
||||
chipset: WS2801
|
||||
data_pin: GPIO23
|
||||
clock_pin: GPIO22
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
num_leds: 60
|
||||
rgb_order: BRG
|
||||
name: "FastLED SPI Light"
|
||||
|
||||
@ -12,23 +12,12 @@ The ``hbridge`` light platform creates a dual color brightness controlled light
|
||||
:align: center
|
||||
:width: 40.0%
|
||||
|
||||
H-bridge lights are very common for Christmas lighting and they use 2 wires for a bunch of LEDs.
|
||||
H-bridge lights are very common for Christmas lighting and they use 2 wires for a bunch of LEDs.
|
||||
The pins are switched alternatively to allow two sets of lights to operate.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
|
||||
# Specify the two pins of the h-bridge as PWM pins
|
||||
output:
|
||||
- platform: esp8266_pwm
|
||||
id: pina
|
||||
pin: GPIO12
|
||||
- platform: esp8266_pwm
|
||||
id: pinb
|
||||
pin: GPIO14
|
||||
|
||||
# Create a light using the hbridge
|
||||
light:
|
||||
- platform: hbridge
|
||||
id: mainlight
|
||||
|
||||
@ -26,11 +26,6 @@ The ``monochromatic`` light platform creates a simple brightness-only light from
|
||||
name: "Kitchen Lights"
|
||||
output: output_component1
|
||||
|
||||
# Example output entry
|
||||
output:
|
||||
- platform: esp8266_pwm
|
||||
id: output_component1
|
||||
pin: D1
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
@ -18,7 +18,7 @@ in ESPHome for individually addressable lights like NeoPixel or WS2812.
|
||||
It is very similar to the :doc:`fastled` platform.
|
||||
In fact, most addressable lights are supported through both light platforms. The
|
||||
difference is that they use different libraries: while the fastled platform uses
|
||||
the `FastLED <https://github.com/FastLED/FastLED>`__ library, this integration uses
|
||||
the `FastLED <https://github.com/FastLED/FastLED>`__ library, this component uses
|
||||
the `NeoPixelBus <https://github.com/Makuna/NeoPixelBus/>`__ library internally.
|
||||
|
||||
.. code-block:: yaml
|
||||
@ -28,7 +28,7 @@ the `NeoPixelBus <https://github.com/Makuna/NeoPixelBus/>`__ library internally.
|
||||
- platform: neopixelbus
|
||||
type: GRB
|
||||
variant: WS2811
|
||||
pin: GPIO23
|
||||
pin: GPIOXX
|
||||
num_leds: 60
|
||||
name: "NeoPixel Light"
|
||||
|
||||
@ -129,7 +129,7 @@ settings vary by method:
|
||||
- **esp8266_uart**: An alternative method for ESP8266s that uses the UART peripheral to send data.
|
||||
Available on pin GPIO1 for bus 0, and GPIO2 for bus 1. Additional options:
|
||||
|
||||
- **bus** (*Optional*, int): The UART bus to use. If 0, the logger ``baud_rate`` option must
|
||||
- **bus** (*Optional*, int): The UART bus to use. If 0, the logger ``baud_rate`` option must
|
||||
be set to 0 and logs over USB/serial won't work.
|
||||
- **async** (*Optional*, boolean): Use an asynchronous transfer. Defaults to ``false``. If enabled,
|
||||
the logger must be disabled even if bus 1 is used.
|
||||
@ -154,7 +154,7 @@ The following method is available only for two-wire chips (specify ``data_pin``
|
||||
- **bus** (*Optional*, string): On ESP32s the SPI bus to be used can be selected. One of ``vspi`` and ``hspi``.
|
||||
- **speed** (*Optional*, int): The frequency to send data with. Defaults to ``10MHz``. One of
|
||||
``40MHz``, ``20MHz``, ``10MHz``, ``5MHz``, ``2MHz``, ``1MHz``, ``500KHz``.
|
||||
|
||||
|
||||
On ESP8266 only GPIO13 can be used for ``data_pin`` and only GPIO14 can be used for ``clock_pin``.
|
||||
|
||||
The ``method`` key also accepts a short-hand syntax consisting of a single value for historic reasons. Usage of
|
||||
|
||||
@ -28,12 +28,6 @@ The ``rgb`` light platform creates an RGB light from 3 :ref:`float output compon
|
||||
green: output_component2
|
||||
blue: output_component3
|
||||
|
||||
# Example output entry
|
||||
output:
|
||||
- platform: esp8266_pwm
|
||||
id: output_component1
|
||||
pin: D1
|
||||
# Repeat for green and blue output
|
||||
|
||||
Color Correction
|
||||
----------------
|
||||
@ -54,9 +48,8 @@ perceived intensity of different colors will generally vary. This can be done by
|
||||
|
||||
# Example output entry
|
||||
output:
|
||||
- platform: esp8266_pwm
|
||||
- platform: ...
|
||||
id: output_component1
|
||||
pin: D1
|
||||
max_power: 80%
|
||||
# Repeat for green and blue output
|
||||
|
||||
|
||||
@ -38,9 +38,8 @@ perceived intensity of different colors will generally vary. This can be done by
|
||||
|
||||
# Example output entry
|
||||
output:
|
||||
- platform: esp8266_pwm
|
||||
- platform: ...
|
||||
id: output_component1
|
||||
pin: D1
|
||||
max_power: 80%
|
||||
|
||||
.. note::
|
||||
|
||||
@ -44,9 +44,8 @@ perceived intensity of different colors will generally vary. This can be done by
|
||||
|
||||
# Example output entry
|
||||
output:
|
||||
- platform: esp8266_pwm
|
||||
- platform: ...
|
||||
id: output_component1
|
||||
pin: D1
|
||||
max_power: 80%
|
||||
|
||||
.. note::
|
||||
|
||||
@ -13,7 +13,7 @@ This is a component using the RP2040 PIO peripheral to drive most addressable LE
|
||||
- platform: rp2040_pio_led_strip
|
||||
name: led_strip
|
||||
id: led_strip
|
||||
pin: GPIO13
|
||||
pin: GPIOXX
|
||||
num_leds: 10
|
||||
pio: 0
|
||||
rgb_order: GRB
|
||||
|
||||
@ -8,7 +8,7 @@ SPI LED Strip Light
|
||||
The ``spi_led_strip`` light platform drives one or more SPI interfaced RGB LEDs. These LEDs are often used in strips, where
|
||||
each LED is individually addressable. This component requires an SPI interface to be configured.
|
||||
|
||||
This component has been tested with APA102 LEDs and the P9813 LED driver. It should also work with HD107 and SK9822 type
|
||||
This component has been tested with APA102 LEDs and the P9813 LED driver. It should also work with HD107 and SK9822 type
|
||||
LEDs, or any others with a similar interface - SPI, 8 bits per colour and BGR ordering.
|
||||
|
||||
.. figure:: images/apa102.jpg
|
||||
@ -18,14 +18,9 @@ LEDs, or any others with a similar interface - SPI, 8 bits per colour and BGR or
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
spi:
|
||||
mosi_pin: GPIO3
|
||||
clk_pin: GPIO9
|
||||
|
||||
light:
|
||||
- platform: spi_led_strip
|
||||
num_leds: 30
|
||||
color_correct: [80%, 60%, 100%]
|
||||
id: rgb_led
|
||||
name: "RGB LED Strip"
|
||||
data_rate: 1MHz
|
||||
|
||||
@ -22,7 +22,7 @@ When the device is in OK state, the LED will be restored to the state of the ``b
|
||||
light:
|
||||
- platform: status_led
|
||||
name: "Switch state"
|
||||
pin: GPIO2
|
||||
pin: GPIOXX
|
||||
|
||||
.. note::
|
||||
|
||||
@ -50,7 +50,7 @@ Configuration variables:
|
||||
.. code-block:: yaml
|
||||
|
||||
pin:
|
||||
number: GPIO2
|
||||
number: GPIOXX
|
||||
inverted: true
|
||||
|
||||
|
||||
|
||||
@ -22,19 +22,8 @@ Using an inexpensive RF transmitter and receiver you can control your devices vi
|
||||
|
||||
# Specify the two pins to connect the receiver and transmitter
|
||||
lightwaverf:
|
||||
read_pin: 13
|
||||
write_pin: 14
|
||||
|
||||
# Create a switch to trigger a light
|
||||
switch:
|
||||
- platform: template
|
||||
name: "Turn off sofa"
|
||||
id: light_off_ceiling_sofa
|
||||
turn_on_action:
|
||||
lightwaverf.send_raw:
|
||||
code: [0x04, 0x00, 0x00, 0x00, 0x0f, 0x03, 0x0d, 0x09, 0x08, 0x08]
|
||||
name: "Sofa"
|
||||
repeat: 1
|
||||
read_pin: GPIOXX
|
||||
write_pin: GPIOXX
|
||||
|
||||
|
||||
Note: To gather the RAW codes from the remote, setup the ``read_pin`` and observe in the logs the printing of the codes.
|
||||
|
||||
@ -16,7 +16,7 @@ The ``output`` lock platform allows you to use any output component as a lock.
|
||||
# Example configuration entry
|
||||
output:
|
||||
- platform: gpio
|
||||
pin: 25
|
||||
pin: GPIOXX
|
||||
id: 'generic_out'
|
||||
lock:
|
||||
- platform: output
|
||||
|
||||
@ -23,15 +23,15 @@ Component
|
||||
matrix_keypad:
|
||||
id: mykeypad
|
||||
rows:
|
||||
- pin: 21
|
||||
- pin: 19
|
||||
- pin: 18
|
||||
- pin: 5
|
||||
- pin: GPIOXX
|
||||
- pin: GPIOXX
|
||||
- pin: GPIOXX
|
||||
- pin: GPIOXX
|
||||
columns:
|
||||
- pin: 17
|
||||
- pin: 16
|
||||
- pin: 4
|
||||
- pin: 15
|
||||
- pin: GPIOXX
|
||||
- pin: GPIOXX
|
||||
- pin: GPIOXX
|
||||
- pin: GPIOXX
|
||||
keys: "123A456B789C*0#D"
|
||||
has_diodes: false
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ The ``max6956`` exists in 2 versions 20 or 28 ports, depending on the packaging.
|
||||
Once configured, you can use any of the 20 or 28 pins for your projects. Within ESPHome they emulate a real internal GPIO pin
|
||||
and can therefore be used with many of ESPHome's components such as the GPIO binary sensor or GPIO switch. Interrupt-on-change for inputs is not possible.
|
||||
|
||||
Pins can also be individualy configured as led driver and used with Light components. Current value can be set globaly or for each pin, through 16 possible levels. Driving RGB
|
||||
Pins can also be individualy configured as led driver and used with Light components. Current value can be set globaly or for each pin, through 16 possible levels. Driving RGB
|
||||
led requires 3 pins.
|
||||
|
||||
Any option accepting a :ref:`Pin Schema <config-pin_schema>` can theoretically be used.
|
||||
@ -48,7 +48,7 @@ Configuration variables:
|
||||
- **brightness_global** (*Optional*): Set the value of the current to be sink by all pins configured as led driver.
|
||||
Defaults to ``0``
|
||||
- **brightness_mode** (*Optional*): Define if the current to be sink will be confgured globaly or per pin configured as led driver.
|
||||
Defaults to ``global``
|
||||
Defaults to ``global``
|
||||
|
||||
|
||||
Binary Sensor Example
|
||||
@ -58,19 +58,7 @@ Binary Sensor Example
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration : pin as input with pullup
|
||||
i2c:
|
||||
id: bus_a
|
||||
sda: GPIO13
|
||||
scl: GPIO16
|
||||
scan: false
|
||||
|
||||
max6956:
|
||||
- id: max6956_1
|
||||
address: 0x40
|
||||
i2c_id: bus_a
|
||||
|
||||
# Individual input
|
||||
# Example configuration
|
||||
binary_sensor:
|
||||
- platform: gpio
|
||||
name: "MaxIn Pin 4"
|
||||
@ -78,7 +66,7 @@ Binary Sensor Example
|
||||
pin:
|
||||
max6956: max6956_1
|
||||
number: 4
|
||||
mode:
|
||||
mode:
|
||||
input: true
|
||||
pullup: true
|
||||
inverted: False
|
||||
@ -91,18 +79,7 @@ Switch Example
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration : pin as output
|
||||
i2c:
|
||||
id: bus_a
|
||||
sda: GPIO13
|
||||
scl: GPIO16
|
||||
|
||||
max6956:
|
||||
- id: max6956_1
|
||||
address: 0x40
|
||||
i2c_id: bus_a
|
||||
|
||||
# Individual output
|
||||
# Example configuration
|
||||
switch:
|
||||
- platform: gpio
|
||||
name: "MaxIn Pin 8"
|
||||
@ -110,9 +87,9 @@ Switch Example
|
||||
pin:
|
||||
max6956: max6956_1
|
||||
number: 8
|
||||
mode:
|
||||
mode:
|
||||
output: true
|
||||
inverted: False
|
||||
inverted: False
|
||||
|
||||
|
||||
Led driver Example
|
||||
@ -126,8 +103,8 @@ Led driver Example
|
||||
# Example configuration : pin as led driver, current globaly
|
||||
i2c:
|
||||
id: bus_a
|
||||
sda: GPIO13
|
||||
scl: GPIO16
|
||||
sda: GPIOXX
|
||||
scl: GPIOXX
|
||||
|
||||
switch:
|
||||
- platform: template
|
||||
@ -153,7 +130,7 @@ Led driver Example
|
||||
- max6956.set_brightness_global:
|
||||
id: max6956_1
|
||||
brightness_global: !lambda return x;
|
||||
|
||||
|
||||
max6956:
|
||||
- id: max6956_1
|
||||
address: 0x40
|
||||
@ -166,7 +143,7 @@ Led driver Example
|
||||
- platform: max6956
|
||||
pin: 4
|
||||
id: maxOut_pin4
|
||||
|
||||
|
||||
#led binded to output
|
||||
light:
|
||||
- platform: monochromatic
|
||||
@ -178,8 +155,8 @@ Led driver Example
|
||||
# Example configuration : pin as led driver, current managed individualy (RBG led)
|
||||
i2c:
|
||||
id: bus_a
|
||||
sda: GPIO13
|
||||
scl: GPIO16
|
||||
sda: GPIOXX
|
||||
scl: GPIOXX
|
||||
|
||||
max6956:
|
||||
- id: max6956_1
|
||||
@ -229,7 +206,7 @@ Led driver Example
|
||||
- output.set_level:
|
||||
id: maxOut_pin4
|
||||
level: !lambda return x/100;
|
||||
|
||||
|
||||
- platform: template
|
||||
name: "Number Green"
|
||||
id: number_LedGreen
|
||||
@ -256,7 +233,7 @@ Led driver Example
|
||||
on_value:
|
||||
- output.set_level:
|
||||
id: maxOut_pin6
|
||||
level: !lambda return x/100;
|
||||
level: !lambda return x/100;
|
||||
output:
|
||||
- platform: max6956
|
||||
pin: 4
|
||||
@ -275,7 +252,7 @@ Led driver Example
|
||||
gamma_correct: 1
|
||||
red: maxOut_pin4
|
||||
green: maxOut_pin5
|
||||
blue: maxOut_pin6
|
||||
blue: maxOut_pin6
|
||||
|
||||
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ The MCP23S08 component (`datasheet <http://ww1.microchip.com/downloads/en/Device
|
||||
# Example configuration entry
|
||||
mcp23s08:
|
||||
- id: 'mcp23s08_hub'
|
||||
cs_pin: D8
|
||||
cs_pin: GPIOXX
|
||||
deviceaddress: 0
|
||||
|
||||
# Individual outputs
|
||||
@ -94,7 +94,7 @@ binary sensor or GPIO switch.
|
||||
# Example configuration entry
|
||||
mcp23s17:
|
||||
- id: 'mcp23s17_hub'
|
||||
cs_pin: D8
|
||||
cs_pin: GPIOXX
|
||||
deviceaddress: 0
|
||||
|
||||
# Individual outputs
|
||||
|
||||
@ -15,7 +15,7 @@ via the :doc:`/components/i2s_audio`. This platform only works on ESP32 based ch
|
||||
- platform: i2s_audio
|
||||
name: ESPHome I2S Media Player
|
||||
dac_type: external
|
||||
i2s_dout_pin: GPIO22
|
||||
i2s_dout_pin: GPIOXX
|
||||
mode: mono
|
||||
|
||||
Configuration variables:
|
||||
@ -35,8 +35,8 @@ External DAC
|
||||
- **mute_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The GPIO pin to use to mute the media player.
|
||||
- **mode** (*Optional*, string): The mode of the I²S bus. Can be ``mono`` or ``stereo``. Defaults to ``mono``.
|
||||
- **i2s_audio_id** (*Optional*, :ref:`config-id`): The ID of the :ref:`I²S Audio <i2s_audio>` you wish to use for this media player.
|
||||
- **i2s_comm_fmt** (*Optional*, string): I2S communication format. By default MSB format is used (AC101, PCM5102A).
|
||||
Set to ``lsb`` if using an external DAC that uses Japanese (Least Significant Bit Justified) format (like PT8211).
|
||||
- **i2s_comm_fmt** (*Optional*, string): I2S communication format. By default MSB format is used (AC101, PCM5102A).
|
||||
Set to ``lsb`` if using an external DAC that uses Japanese (Least Significant Bit Justified) format (like PT8211).
|
||||
Can be ``msb`` or ``lsb``. Defaults to ``msb``.
|
||||
|
||||
For best results, keep the wires as short as possible.
|
||||
|
||||
@ -18,7 +18,7 @@ The :ref:`UART <uart>` must be configured with a baud rate 1200, 8 data bits, 2
|
||||
|
||||
Also, switching your stove on or off can behave different on the various MicroNova flavours.
|
||||
|
||||
Use this integration at your own risk.
|
||||
Use this component at your own risk.
|
||||
|
||||
Connecting your stove
|
||||
---------------------
|
||||
|
||||
@ -24,12 +24,12 @@ This platform only works on ESP32 based chips.
|
||||
- platform: i2s_audio
|
||||
id: external_mic
|
||||
adc_type: external
|
||||
i2s_din_pin: GPIO23
|
||||
i2s_din_pin: GPIOXX
|
||||
|
||||
- platform: i2s_audio
|
||||
id: adc_mic
|
||||
adc_type: internal
|
||||
adc_pin: GPIO35
|
||||
adc_pin: GPIOXX
|
||||
|
||||
|
||||
Configuration variables:
|
||||
@ -80,7 +80,7 @@ M5Stack Atom Echo
|
||||
microphone:
|
||||
- platform: i2s_audio
|
||||
adc_type: external
|
||||
i2s_din_pin: GPIO23
|
||||
i2s_din_pin: GPIOXX
|
||||
pdm: true
|
||||
|
||||
RaspiAudio Muse Luxe
|
||||
@ -90,7 +90,7 @@ RaspiAudio Muse Luxe
|
||||
|
||||
microphone:
|
||||
- platform: i2s_audio
|
||||
i2s_din_pin: GPIO35
|
||||
i2s_din_pin: GPIOXX
|
||||
adc_type: external
|
||||
pdm: false
|
||||
|
||||
|
||||
@ -78,7 +78,7 @@ Technically there is no difference between the "inline" and the standard definit
|
||||
...
|
||||
|
||||
modbus:
|
||||
flow_control_pin: 5
|
||||
flow_control_pin: GPIOXX
|
||||
id: modbus1
|
||||
|
||||
modbus_controller:
|
||||
@ -129,43 +129,43 @@ Bitmasks
|
||||
|
||||
Some devices use decimal values in read registers to show multiple binary states occupying only one register address. To decode them, you can use bitmasks according to the table below. The decimal value corresponding to a bit is always double of the previous one in the row. Multiple bits can be represented in a single register by making a sum of all the values corresponding to the bits.
|
||||
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| Alarm bit | Description | DEC value | HEX value |
|
||||
+============+==================+===========+===========+
|
||||
+============+==================+===========+===========+
|
||||
| bit 0 | Binary Sensor 0 | 1 | 1 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 1 | Binary Sensor 1 | 2 | 2 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 2 | Binary Sensor 2 | 4 | 4 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 3 | Binary Sensor 3 | 8 | 8 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 4 | Binary Sensor 4 | 16 | 10 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 5 | Binary Sensor 5 | 32 | 20 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 6 | Binary Sensor 6 | 64 | 40 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 7 | Binary Sensor 7 | 128 | 80 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 8 | Binary Sensor 8 | 256 | 100 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 9 | Binary Sensor 9 | 512 | 200 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 10 | Binary Sensor 10 | 1024 | 400 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 11 | Binary Sensor 11 | 2048 | 800 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 12 | Binary Sensor 12 | 4096 | 1000 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 13 | Binary Sensor 13 | 8192 | 2000 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 14 | Binary Sensor 14 | 16384 | 4000 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
| bit 15 | Binary Sensor 15 | 32768 | 8000 |
|
||||
+------------+------------------+-----------+-----------+
|
||||
+------------+------------------+-----------+-----------+
|
||||
|
||||
In the example below, register ``15``, holds several binary values. It stores the decimal value ``12288``, which is the sum of ``4096`` + ``8192``, meaning the corresponding bits ``12`` and ``13`` are ``1``, the other bits are ``0``.
|
||||
In the example below, register ``15``, holds several binary values. It stores the decimal value ``12288``, which is the sum of ``4096`` + ``8192``, meaning the corresponding bits ``12`` and ``13`` are ``1``, the other bits are ``0``.
|
||||
|
||||
To gather some of these bits as binary sensors in ESPHome, use ``bitmask``:
|
||||
|
||||
@ -513,7 +513,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
|
||||
The code synchronizes the localtime of MCU to the epever controller
|
||||
The time is set by writing 12 bytes to register 0x9013.
|
||||
Then battery charge settings are sent.
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
esphome:
|
||||
@ -565,7 +565,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
|
||||
0x04BA, // 900d Low Volt. Disconnect Volt. 11.8
|
||||
0x04BA // 900E Discharging Limit Voltage 11.8
|
||||
};
|
||||
|
||||
|
||||
// Boost and equalization periods
|
||||
std::vector<uint16_t> battery_settings2 = {
|
||||
0x0000, // 906B Equalize Duration (min.) 0
|
||||
@ -574,7 +574,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
|
||||
esphome::modbus_controller::ModbusCommandItem set_battery1_command =
|
||||
esphome::modbus_controller::ModbusCommandItem::create_write_multiple_command(controller, 0x9000, battery_settings1.size() ,
|
||||
battery_settings1);
|
||||
|
||||
|
||||
esphome::modbus_controller::ModbusCommandItem set_battery2_command =
|
||||
esphome::modbus_controller::ModbusCommandItem::create_write_multiple_command(controller, 0x906B, battery_settings3.size(),
|
||||
battery_settings2);
|
||||
@ -583,19 +583,19 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
|
||||
delay(200) ;
|
||||
controller->queue_command(set_battery2_command);
|
||||
ESP_LOGI("ModbusLambda", "EPSOLAR Battery set");
|
||||
|
||||
|
||||
uart:
|
||||
id: mod_bus
|
||||
tx_pin: 19
|
||||
rx_pin: 18
|
||||
tx_pin: GPIOXX
|
||||
rx_pin: GPIOXX
|
||||
baud_rate: 115200
|
||||
stop_bits: 1
|
||||
|
||||
|
||||
modbus:
|
||||
#flow_control_pin: 23
|
||||
#flow_control_pin: GPIOXX
|
||||
send_wait_time: 200ms
|
||||
id: mod_bus_epever
|
||||
|
||||
|
||||
modbus_controller:
|
||||
- id: epever
|
||||
## the Modbus device addr
|
||||
@ -604,7 +604,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
|
||||
command_throttle: 0ms
|
||||
setup_priority: -10
|
||||
update_interval: ${updates}
|
||||
|
||||
|
||||
sensor:
|
||||
- platform: modbus_controller
|
||||
modbus_controller_id: epever
|
||||
@ -617,7 +617,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
|
||||
accuracy_decimals: 1
|
||||
filters:
|
||||
- multiply: 0.01
|
||||
|
||||
|
||||
- platform: modbus_controller
|
||||
modbus_controller_id: epever
|
||||
id: array_rated_current
|
||||
@ -629,7 +629,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
|
||||
accuracy_decimals: 2
|
||||
filters:
|
||||
- multiply: 0.01
|
||||
|
||||
|
||||
- platform: modbus_controller
|
||||
modbus_controller_id: epever
|
||||
id: array_rated_power
|
||||
|
||||
@ -184,13 +184,12 @@ Home Assistant generates entity names for all discovered devices based on entity
|
||||
entity name (e.g. ``sensor.uptime``). Numeric suffixes are appended to entity names when
|
||||
multiple devices use the same name for a sensor, making it harder to distinguish between
|
||||
similar sensors on different devices. Home Assistant 2021.12 allows MQTT devices to change
|
||||
this behaviour by specifying ``object_id`` discovery attribute which replaces the sensor
|
||||
this behaviour by specifying the ``object_id`` discovery attribute which replaces the sensor
|
||||
name part of the generated entity name. Setting ``discovery_object_id_generator: device_name``
|
||||
in ESPHome MQTT integration configuration will cause Home Assistant to include device name
|
||||
in the ESPHome MQTT component configuration will cause Home Assistant to include device name
|
||||
in the generated entity names (e.g. ``sensor.uptime`` becomes ``sensor.<device name>_uptime``),
|
||||
making it easier to distinguish the entities in various entity lists.
|
||||
|
||||
|
||||
.. _mqtt-defaults:
|
||||
|
||||
Defaults
|
||||
@ -266,7 +265,7 @@ then run the ``mqtt-fingerprint`` script of ESPHome to get the certificate:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
esphome livingroom.yaml mqtt-fingerprint
|
||||
esphome mqtt-fingerprint livingroom.yaml
|
||||
> SHA1 Fingerprint: a502ff13999f8b398ef1834f1123650b3236fc07
|
||||
> Copy above string into mqtt.ssl_fingerprints section of livingroom.yaml
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ AC Dimmer Component
|
||||
===================
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up AC Dimmer integration in ESPHome.
|
||||
:description: Instructions for setting up AC Dimmer component in ESPHome.
|
||||
:image: ac_dimmer.svg
|
||||
|
||||
.. warning::
|
||||
@ -16,9 +16,8 @@ AC Dimmer Component
|
||||
The ``ac_dimmer`` component allows you to connect a dimmable light or other load
|
||||
which supports phase control dimming to your ESPHome project.
|
||||
|
||||
There are several already made boards which are compatible with this integration,
|
||||
for example the `RobotDyn dimmer
|
||||
<https://robotdyn.com/ac-light-dimmer-module-1-channel-3-3v-5v-logic-ac-50-60hz-220v-110v.html>`__.
|
||||
There are several already made boards which are compatible with this component, such as the
|
||||
`RobotDyn dimmer <https://robotdyn.com/ac-light-dimmer-module-1-channel-3-3v-5v-logic-ac-50-60hz-220v-110v.html>`__.
|
||||
|
||||
.. figure:: images/robotdyn_dimmer.jpg
|
||||
:align: center
|
||||
@ -34,9 +33,9 @@ for example the `RobotDyn dimmer
|
||||
output:
|
||||
- platform: ac_dimmer
|
||||
id: dimmer1
|
||||
gate_pin: D7
|
||||
gate_pin: GPIOXX
|
||||
zero_cross_pin:
|
||||
number: D6
|
||||
number: GPIOXX
|
||||
mode:
|
||||
input: true
|
||||
inverted: yes
|
||||
|
||||
@ -24,8 +24,8 @@ It is used in some smart light bulbs:
|
||||
|
||||
# Example configuration entry
|
||||
bp1658cj:
|
||||
data_pin: GPIO6
|
||||
clock_pin: GPIO7
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
max_power_color_channels: 4 # Valid values 0-15
|
||||
max_power_white_channels: 6 # Valid values 0-15
|
||||
|
||||
|
||||
@ -24,8 +24,8 @@ It is used in some smart light bulbs:
|
||||
|
||||
# Example configuration entry
|
||||
bp5758d:
|
||||
data_pin: GPIO3
|
||||
clock_pin: GPIO5
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
|
||||
|
||||
Configuration variables:
|
||||
|
||||
@ -1,17 +1,25 @@
|
||||
Custom Output
|
||||
=============
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up Custom C++ outputs with ESPHome.
|
||||
:image: language-cpp.svg
|
||||
:keywords: C++, Custom
|
||||
|
||||
.. warning::
|
||||
|
||||
Custom components are deprecated, not recommended for new configurations
|
||||
and will be removed from ESPHome in a future release.
|
||||
Please look at creating a real ESPHome component and "importing" it into your
|
||||
configuration with :doc:`/components/external_components`.
|
||||
Custom components are deprecated, not recommended for new configurations and will be removed from ESPHome in a
|
||||
future release. Please look at creating a real ESPHome component and "importing" it into your configuration with
|
||||
:doc:`/components/external_components`.
|
||||
|
||||
You can find some basic documentation on creating your own components
|
||||
at :ref:`contributing_to_esphome`.
|
||||
You can find some basic documentation on creating your own components at :ref:`contributing_to_esphome`.
|
||||
|
||||
This integration can be used to create custom binary and float :doc:`outputs </components/output/index>`
|
||||
.. warning::
|
||||
|
||||
While we try to keep the ESPHome YAML configuration options as stable as possible, the ESPHome API is less
|
||||
stable. If something in the APIs needs to be changed in order for something else to work, we will do so.
|
||||
|
||||
This component can be used to create custom binary and float :doc:`outputs </components/output/index>`
|
||||
in ESPHome using the C++ (Arduino) API.
|
||||
|
||||
Please first read :doc:`/components/sensor/custom` guide, the same principles apply here.
|
||||
|
||||
@ -15,7 +15,7 @@ like the one on the ESP32 (see :doc:`ledc`) are preferred.
|
||||
# Example configuration entry
|
||||
output:
|
||||
- platform: esp8266_pwm
|
||||
pin: D1
|
||||
pin: GPIOXX
|
||||
frequency: 1000 Hz
|
||||
id: pwm_output
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ will not show up in Home Assistant. See :doc:`/components/switch/gpio`.
|
||||
# Example configuration entry
|
||||
output:
|
||||
- platform: gpio
|
||||
pin: D1
|
||||
pin: GPIOXX
|
||||
id: gpio_d1
|
||||
|
||||
Configuration variables:
|
||||
|
||||
@ -12,6 +12,32 @@ of the ESP32 as an output component.
|
||||
The frequency range of LEDC is from 10Hz to 40MHz - however, higher frequencies require a smaller
|
||||
bit depth which means the output is not that accurate for frequencies above ~300kHz.
|
||||
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin to use LEDC on. Can only be GPIO0-GPIO33.
|
||||
- **id** (**Required**, :ref:`config-id`): The id to use for this output component.
|
||||
- **frequency** (*Optional*, float): At which frequency to run the LEDC
|
||||
channel’s timer. Defaults to 1000Hz.
|
||||
- All other options from :ref:`Output <config-output>`.
|
||||
|
||||
Advanced options:
|
||||
|
||||
- **channel** (*Optional*, int): Manually set the `LEDC
|
||||
channel <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/ledc.html#configure-channel>`__
|
||||
to use. Two adjacent channels share the same timer. Defaults to an automatic selection.
|
||||
|
||||
Note: When configuring custom frequencies for two or more outputs, ensure that you manually specify
|
||||
channel 0, 2, 4, 6 for each output. This will prevent issues that arise from automatic selection,
|
||||
which chooses adjacent channels with shared timers. See
|
||||
`Issue #3114 <https://github.com/esphome/issues/issues/3114>`__ for more details.
|
||||
|
||||
- **phase_angle** (*Optional*, float): Set a phase angle to the other channel of this timer.
|
||||
Range 0-360°, defaults to 0°
|
||||
|
||||
Note: this variable is only available for the esp-idf framework
|
||||
|
||||
Example Usage For a Light
|
||||
*************************
|
||||
|
||||
@ -20,8 +46,8 @@ Example Usage For a Light
|
||||
# Example configuration entry
|
||||
output:
|
||||
- platform: ledc
|
||||
pin: GPIO19
|
||||
id: gpio_19
|
||||
pin: GPIOXX
|
||||
id: gpio_
|
||||
|
||||
# Example usage in a light
|
||||
light:
|
||||
@ -63,31 +89,6 @@ Example Usage For a Piezo Buzzer
|
||||
id: buzzer
|
||||
level: "50%"
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin to use LEDC on. Can only be GPIO0-GPIO33.
|
||||
- **id** (**Required**, :ref:`config-id`): The id to use for this output component.
|
||||
- **frequency** (*Optional*, float): At which frequency to run the LEDC
|
||||
channel’s timer. Defaults to 1000Hz.
|
||||
- All other options from :ref:`Output <config-output>`.
|
||||
|
||||
Advanced options:
|
||||
|
||||
- **channel** (*Optional*, int): Manually set the `LEDC
|
||||
channel <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/ledc.html#configure-channel>`__
|
||||
to use. Two adjacent channels share the same timer. Defaults to an automatic selection.
|
||||
|
||||
Note: When configuring custom frequencies for two or more outputs, ensure that you manually specify
|
||||
channel 0, 2, 4, 6 for each output. This will prevent issues that arise from automatic selection,
|
||||
which chooses adjacent channels with shared timers. See
|
||||
`Issue #3114 <https://github.com/esphome/issues/issues/3114>`__ for more details.
|
||||
|
||||
- **phase_angle** (*Optional*, float): Set a phase angle to the other channel of this timer.
|
||||
Range 0-360°, defaults to 0°
|
||||
|
||||
Note: this variable is only available for the esp-idf framework
|
||||
|
||||
Recommended frequencies
|
||||
-----------------------
|
||||
|
||||
|
||||
@ -31,14 +31,9 @@ global ``my9231`` hub and give it an id, and then define the
|
||||
|
||||
# Example configuration entry
|
||||
my9231:
|
||||
- data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
- data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: my9231
|
||||
id: 'my9231_output1'
|
||||
channel: 0
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
@ -68,11 +63,6 @@ The MY931/MY9291 output component exposes a MY931/MY9291 channel of a global
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
my9231:
|
||||
- data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: my9231
|
||||
|
||||
@ -44,7 +44,7 @@ global ``pca9685`` hub and give it an id, and then define the
|
||||
output:
|
||||
# generate PWM from ESP32 ledc
|
||||
- platform: ledc
|
||||
pin: 25
|
||||
pin: GPIOXX
|
||||
id: extclk
|
||||
min_power: 1
|
||||
frequency: 40MHz
|
||||
@ -118,10 +118,10 @@ This output can be used for different PWM functions. E.g. output for light, fan
|
||||
- platform: pca9685
|
||||
channel: 0
|
||||
id: pwm01
|
||||
|
||||
|
||||
light:
|
||||
- platform: monochromatic
|
||||
name: 'main light'
|
||||
- platform: monochromatic
|
||||
name: 'main light'
|
||||
output: pwm01
|
||||
|
||||
See Also
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Sigma-Delta Output
|
||||
==================
|
||||
|
||||
This integration uses `sigma-delta modulation <https://en.wikipedia.org/wiki/Delta-sigma_modulation>`__
|
||||
This component uses `sigma-delta modulation <https://en.wikipedia.org/wiki/Delta-sigma_modulation>`__
|
||||
to output a floating-point value on a binary output. Unlike with :doc:`/components/output/slow_pwm`,
|
||||
it is possible to update the output value with each update cycle, not just at the end of a longer period.
|
||||
|
||||
@ -14,13 +14,13 @@ it is possible to update the output value with each update cycle, not just at th
|
||||
For example, if you choose to toggle the output at most once every 1 second and decide on a
|
||||
PWM period of 10 seconds, for reasonably frequent updates, with :doc:`/components/output/slow_pwm`
|
||||
there are only 10 possible levels, and for higher precision a longer update interval is needed,
|
||||
restricting the update rate.
|
||||
restricting the update rate.
|
||||
|
||||
A *sigma-delta* output is updated during each cycle, thus a higher precision can be achieved, without
|
||||
being constrained by a calculation timeframe (=period).
|
||||
|
||||
So instead of having to define a ``period`` where the width of the pulse determines the output level, here you
|
||||
choose an ``update_interval`` which acts like a clock signal from where the pulse density determines the output level.
|
||||
choose an ``update_interval`` which acts like a clock signal from where the pulse density determines the output level.
|
||||
|
||||
This component can be used as a drop-in replacement for :doc:`/components/output/slow_pwm` by changing the ``platform`` to
|
||||
``sigma_delta_output`` and changing ``period`` to ``update_interval`` (you usually want to set the *sigma-delta*'s
|
||||
@ -35,7 +35,7 @@ This component can be used as a drop-in replacement for :doc:`/components/output
|
||||
id: sd_heater_output
|
||||
|
||||
# Output to a pin
|
||||
pin: 15
|
||||
pin: GPIOXX
|
||||
|
||||
# Use the same output, but through automations
|
||||
turn_on_action:
|
||||
@ -44,9 +44,9 @@ This component can be used as a drop-in replacement for :doc:`/components/output
|
||||
turn_off_action:
|
||||
then:
|
||||
- output.turn_off: heater_relay
|
||||
|
||||
|
||||
- platform: gpio
|
||||
pin: 15
|
||||
pin: GPIOXX
|
||||
id: heater_relay
|
||||
|
||||
Configuration variables:
|
||||
|
||||
@ -22,7 +22,7 @@ heating element through a relay where a fast PWM update cycle would not be appro
|
||||
# Example configuration entry
|
||||
output:
|
||||
- platform: slow_pwm
|
||||
pin: D1
|
||||
pin: GPIOXX
|
||||
id: my_slow_pwm
|
||||
period: 15s
|
||||
|
||||
|
||||
@ -28,22 +28,11 @@ global ``sm16716`` hub and give it an id, and then define the
|
||||
|
||||
# Example configuration entry
|
||||
sm16716:
|
||||
data_pin: GPIO14
|
||||
clock_pin: GPIO4
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
num_channels: 3
|
||||
num_chips: 1
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: sm16716
|
||||
id: output_red
|
||||
channel: 0
|
||||
- platform: sm16716
|
||||
id: output_green
|
||||
channel: 1
|
||||
- platform: sm16716
|
||||
id: output_blue
|
||||
channel: 2
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
@ -69,13 +58,6 @@ The SM16716 output component exposes a SM16716 channel of a global
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sm16716:
|
||||
data_pin: GPIO14
|
||||
clock_pin: GPIO4
|
||||
num_channels: 3
|
||||
num_chips: 1
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: sm16716
|
||||
@ -174,7 +156,7 @@ A complete configuration for a Feit Electric A19 looks like:
|
||||
The white LEDs are much brighter than the color LEDs and will fully overpower
|
||||
the set color when the white level is set even a little bit high. You will need
|
||||
to set the white level to 0 in order to get usable colors from this bulb.
|
||||
|
||||
|
||||
Alternative Costco Feit A19 RGBCT bulb configuration:
|
||||
|
||||
.. code-block:: yaml
|
||||
@ -224,8 +206,8 @@ Alternative Costco Feit A19 RGBCT bulb configuration:
|
||||
power_supply:
|
||||
- id: rgb_power
|
||||
pin: GPIO13
|
||||
|
||||
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
|
||||
@ -27,31 +27,9 @@ global ``sm2135`` hub and give it an id, and then define the
|
||||
|
||||
# Example configuration entry
|
||||
sm2135:
|
||||
data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: sm2135
|
||||
id: output_red
|
||||
channel: 0
|
||||
max_power: 0.8
|
||||
- platform: sm2135
|
||||
id: output_green
|
||||
channel: 1
|
||||
max_power: 0.8
|
||||
- platform: sm2135
|
||||
id: output_blue
|
||||
channel: 2
|
||||
max_power: 0.8
|
||||
- platform: sm2135
|
||||
id: output_white
|
||||
channel: 3
|
||||
max_power: 0.8
|
||||
- platform: sm2135
|
||||
id: output_warmwhite
|
||||
channel: 4
|
||||
max_power: 0.8
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
@ -62,7 +40,7 @@ Configuration variables:
|
||||
- **id** (*Optional*, :ref:`config-id`): The id to use for
|
||||
this ``sm2135`` component. Use this if you have multiple SM2135 chains
|
||||
connected at the same time.
|
||||
- **cw_current** (*Optional*, current): The current used for the white channel.
|
||||
- **cw_current** (*Optional*, current): The current used for the white channel.
|
||||
Defaults to ``10mA``.
|
||||
Can be one of ``10mA``, ``15mA``, ``20mA``, ``25mA``, ``30mA``, ``35mA``, ``40mA``, ``45mA``, ``50mA``, ``55mA``, ``60mA``.
|
||||
- **rgb_current** (*Optional*, current): The current used for the RGB channel.
|
||||
@ -82,11 +60,6 @@ The SM2135 output component exposes a SM2135 channel of a global
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
sm2135:
|
||||
data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: sm2135
|
||||
|
||||
@ -21,8 +21,8 @@ global ``sm2235`` hub and give it an id, and then define the
|
||||
|
||||
# Example configuration entry
|
||||
sm2235:
|
||||
data_pin: GPIO4
|
||||
clock_pin: GPIO5
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
max_power_color_channels: 9
|
||||
max_power_white_channels: 9
|
||||
|
||||
|
||||
@ -24,8 +24,8 @@ global ``sm2335`` hub and give it an id, and then define the
|
||||
|
||||
# Example configuration entry
|
||||
sm2335:
|
||||
data_pin: GPIO4
|
||||
clock_pin: GPIO5
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
max_power_color_channels: 9
|
||||
max_power_white_channels: 9
|
||||
|
||||
|
||||
@ -22,14 +22,10 @@ The ``template`` output component can be used to create templated binary and flo
|
||||
id: output2
|
||||
level: !lambda return state;
|
||||
|
||||
- platform: esp8266_pwm
|
||||
- platform: ...
|
||||
id: output1
|
||||
pin: GPIO12
|
||||
inverted: true
|
||||
- platform: esp8266_pwm
|
||||
- platform: ...
|
||||
id: output2
|
||||
pin: GPIO14
|
||||
inverted: true
|
||||
|
||||
|
||||
|
||||
|
||||
@ -27,21 +27,9 @@ global ``tlc5947`` hub and give it an id, and then define the
|
||||
|
||||
# Example configuration entry
|
||||
tlc5947:
|
||||
data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
lat_pin: GPIO15
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: tlc5947
|
||||
id: output_red
|
||||
channel: 0
|
||||
- platform: tlc5947
|
||||
id: output_green
|
||||
channel: 1
|
||||
- platform: tlc5947
|
||||
id: output_blue
|
||||
channel: 2
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
lat_pin: GPIOXX
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
@ -66,12 +54,6 @@ The tlc5947 output component exposes a tlc5947 channel of a global
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
tlc5947:
|
||||
data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
lat_pin: GPIO15
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: tlc5947
|
||||
|
||||
@ -27,20 +27,9 @@ global ``tlc5971`` hub and give it an id, and then define the
|
||||
|
||||
# Example configuration entry
|
||||
tlc5971:
|
||||
data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
data_pin: GPIOXX
|
||||
clock_pin: GPIOXX
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: tlc5971
|
||||
id: output_red
|
||||
channel: 0
|
||||
- platform: tlc5971
|
||||
id: output_green
|
||||
channel: 1
|
||||
- platform: tlc5971
|
||||
id: output_blue
|
||||
channel: 2
|
||||
|
||||
Configuration variables:
|
||||
************************
|
||||
@ -63,11 +52,6 @@ The tlc5971 output component exposes a tlc5971 channel of a global
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
tlc5971:
|
||||
data_pin: GPIO12
|
||||
clock_pin: GPIO14
|
||||
|
||||
# Individual outputs
|
||||
output:
|
||||
- platform: tlc5971
|
||||
|
||||
@ -15,7 +15,7 @@ The ``x9c`` output platform allows you to add an output that controls a `X9C dig
|
||||
|
||||
The X9C family of digital potentiometers are available in different resistance values.
|
||||
|
||||
==================== =====================
|
||||
==================== =====================
|
||||
``X9C102`` ``1kΩ``
|
||||
-------------------- ---------------------
|
||||
``X9C103`` ``10kΩ``
|
||||
@ -33,9 +33,9 @@ All chips are controlled by a three wire interface and feature 100 possible wipe
|
||||
output:
|
||||
- platform: x9c
|
||||
id: x9c_pot
|
||||
cs_pin: GPIO25
|
||||
inc_pin: GPIO27
|
||||
ud_pin: GPIO26
|
||||
cs_pin: GPIOXX
|
||||
inc_pin: GPIOXX
|
||||
ud_pin: GPIOXX
|
||||
initial_value: 0.5
|
||||
|
||||
Configuration variables:
|
||||
|
||||
@ -37,16 +37,8 @@ There is a buffer to buffer up to 10 commands.
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
uart:
|
||||
- id: uart_bus
|
||||
tx_pin: GPIO18
|
||||
rx_pin: GPIO19
|
||||
# most devices use 2400 as baud_rate
|
||||
baud_rate: 2400
|
||||
|
||||
pipsolar:
|
||||
- uart_id: uart_bus
|
||||
id: inverter0
|
||||
- id: inverter0
|
||||
|
||||
Configuration variables:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -30,10 +30,10 @@ In addition, the :doc:`binary_sensor/nfc` platform may be used to quickly and ea
|
||||
.. code-block:: yaml
|
||||
|
||||
pn7150_i2c:
|
||||
dwl_req_pin: 17
|
||||
irq_pin: 35
|
||||
ven_pin: 16
|
||||
wkup_req_pin: 21
|
||||
dwl_req_pin: GPIOXX
|
||||
irq_pin: GPIOXX
|
||||
ven_pin: GPIOXX
|
||||
wkup_req_pin: GPIOXX
|
||||
emulation_message: https://www.home-assistant.io/tag/pulse_ce
|
||||
tag_ttl: 1000ms
|
||||
|
||||
@ -348,7 +348,7 @@ NDEF Writing
|
||||
The examples below illustrate how NDEF messages may be written to cards/tags via the PN7150. Note that a
|
||||
:doc:`button </components/button/index>` is a great mechanism to use to trigger these actions.
|
||||
|
||||
The first example will write a simple, fixed NDEF message to a tag.
|
||||
The first example will write a simple, fixed NDEF message to a tag.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
||||
@ -42,11 +42,11 @@ The ``pn7160_spi`` component allows you to use :ref:`SPI-equipped <spi>` PN7160
|
||||
.. code-block:: yaml
|
||||
|
||||
pn7160_spi:
|
||||
cs_pin: 15
|
||||
dwl_req_pin: 17
|
||||
irq_pin: 35
|
||||
ven_pin: 16
|
||||
wkup_req_pin: 21
|
||||
cs_pin: GPIOXX
|
||||
dwl_req_pin: GPIOXX
|
||||
irq_pin: GPIOXX
|
||||
ven_pin: GPIOXX
|
||||
wkup_req_pin: GPIOXX
|
||||
emulation_message: https://www.home-assistant.io/tag/pulse_ce
|
||||
tag_ttl: 1000ms
|
||||
|
||||
@ -87,10 +87,10 @@ The ``pn7160_i2c`` component allows you to use :ref:`I²C-equipped <i2c>` PN7160
|
||||
.. code-block:: yaml
|
||||
|
||||
pn7160_i2c:
|
||||
dwl_req_pin: 17
|
||||
irq_pin: 35
|
||||
ven_pin: 16
|
||||
wkup_req_pin: 21
|
||||
dwl_req_pin: GPIOXX
|
||||
irq_pin: GPIOXX
|
||||
ven_pin: GPIOXX
|
||||
wkup_req_pin: GPIOXX
|
||||
emulation_message: https://www.home-assistant.io/tag/pulse_ce
|
||||
tag_ttl: 1000ms
|
||||
|
||||
@ -406,7 +406,7 @@ NDEF Writing
|
||||
The examples below illustrate how NDEF messages may be written to cards/tags via the PN7160. Note that a
|
||||
:doc:`button </components/button/index>` is a great mechanism to use to trigger these actions.
|
||||
|
||||
The first example will write a simple, fixed NDEF message to a tag.
|
||||
The first example will write a simple, fixed NDEF message to a tag.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ after the last output has been disabled.
|
||||
# Example configuration entry
|
||||
power_supply:
|
||||
- id: 'power_supply1'
|
||||
pin: 13
|
||||
pin: GPIOXX
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
@ -20,7 +20,7 @@ which will trigger when they hear their own configured signal.
|
||||
|
||||
# Example configuration entry
|
||||
remote_receiver:
|
||||
pin: GPIO32
|
||||
pin: GPIOXX
|
||||
dump: all
|
||||
|
||||
Configuration variables:
|
||||
@ -218,10 +218,6 @@ then immediately OFF.
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example configuration entry
|
||||
remote_receiver:
|
||||
pin: GPIO32
|
||||
dump: all
|
||||
|
||||
binary_sensor:
|
||||
- platform: remote_receiver
|
||||
name: "Panasonic Remote Input"
|
||||
@ -455,7 +451,7 @@ Remote code selection (exactly one of these has to be included):
|
||||
|
||||
remote_receiver:
|
||||
pin:
|
||||
number: D4
|
||||
number: GPIOXX
|
||||
inverted: true
|
||||
mode:
|
||||
input: true
|
||||
@ -491,4 +487,3 @@ See Also
|
||||
- `IRRemoteESP8266 <https://github.com/markszabo/IRremoteESP8266/>`__ by `Mark Szabo-Simon <https://github.com/markszabo>`__
|
||||
- :apiref:`remote/remote_receiver.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
|
||||
@ -24,18 +24,9 @@ remote signals.
|
||||
|
||||
# Example configuration entry
|
||||
remote_transmitter:
|
||||
pin: GPIO32
|
||||
pin: GPIOXX
|
||||
carrier_duty_percent: 50%
|
||||
|
||||
# Individual switches
|
||||
switch:
|
||||
- platform: template
|
||||
name: "Panasonic TV Off"
|
||||
turn_on_action:
|
||||
remote_transmitter.transmit_panasonic:
|
||||
address: 0x4004
|
||||
command: 0x100BCBD
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
@ -293,7 +284,7 @@ Configuration variables:
|
||||
|
||||
- **id** (**Required**, int): The 24-bit ID to send. Each remote has a unique one.
|
||||
- **channel** (**Required**, int): The 8-bit channel to send, between 0 and 255 inclusive.
|
||||
- **button** (**Required**, int): The 4-bit button to send, between 0 and 15 inclusive.
|
||||
- **button** (**Required**, int): The 4-bit button to send, between 0 and 15 inclusive.
|
||||
- **check** (**Required**, int): The 4-bit check to send. Includes an indication that a button is being held down. See dumper output for more info.
|
||||
- All other options from :ref:`remote_transmitter-transmit_action`.
|
||||
|
||||
@ -934,7 +925,7 @@ remote_receiver instance:
|
||||
.. code-block:: yaml
|
||||
|
||||
remote_receiver:
|
||||
pin: D0
|
||||
pin: GPIOXX
|
||||
dump: all
|
||||
|
||||
Compile and upload the code. While viewing the log output from the ESP,
|
||||
@ -963,7 +954,7 @@ IR diode to a new pin on the ESP and configure a global ``remote_transmitter`` i
|
||||
.. code-block:: yaml
|
||||
|
||||
remote_transmitter:
|
||||
pin: D1
|
||||
pin: GPIOXX
|
||||
# Infrared remotes use a 50% carrier signal
|
||||
carrier_duty_percent: 50%
|
||||
|
||||
@ -1009,7 +1000,7 @@ First, connect the RF module to a pin on the ESP and set up a remote_receiver in
|
||||
.. code-block:: yaml
|
||||
|
||||
remote_receiver:
|
||||
pin: D0
|
||||
pin: GPIOXX
|
||||
dump: all
|
||||
# Settings to optimize recognition of RF devices
|
||||
tolerance: 50%
|
||||
@ -1041,7 +1032,7 @@ You should see log output like below:
|
||||
.. code-block:: yaml
|
||||
|
||||
remote_receiver:
|
||||
pin: D0
|
||||
pin: GPIOXX
|
||||
dump:
|
||||
- rc_switch
|
||||
tolerance: 50%
|
||||
@ -1059,7 +1050,7 @@ RF transmitter to a new pin on the ESP and configure a global ``remote_transmitt
|
||||
.. code-block:: yaml
|
||||
|
||||
remote_transmitter:
|
||||
pin: D1
|
||||
pin: GPIOXX
|
||||
# RF uses a 100% carrier signal
|
||||
carrier_duty_percent: 100%
|
||||
|
||||
|
||||
@ -127,7 +127,7 @@ Common beeps
|
||||
|
||||
You can do your own beep patterns too! Here's a short collection so you can just use right away or tweak them to your like:
|
||||
|
||||
.. code-block::
|
||||
.. code-block::
|
||||
|
||||
two_short:d=4,o=5,b=100:16e6,16e6
|
||||
long:d=1,o=5,b=100:e6
|
||||
@ -165,7 +165,7 @@ Sample code
|
||||
|
||||
output:
|
||||
- platform: esp8266_pwm
|
||||
pin: D1
|
||||
pin: GPIOXX
|
||||
id: rtttl_out
|
||||
|
||||
rtttl:
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user