Upstream/esphome-docs
1
0
Fork 0
mirror of https://github.com/esphome/esphome-docs.git synced 2025-04-02 18:06:51 +02:00
Code Issues Projects Releases Wiki Activity

Merge pull request from esphome/bump-2023.3.0b3

Browse Source 
2023.3.0b3
This commit is contained in:
Jesse Hills 2023-03-13 15:31:22 +13:00 committed by GitHub
commit 0f80fde3a0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
14 changed files with 96 additions and 13 deletions

2
Doxygen
View File

@ -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 = 2023.3.0b2
PROJECT_NUMBER = 2023.3.0b3
# 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
View File

@ -1,5 +1,5 @@
ESPHOME_PATH = ../esphome
ESPHOME_REF = 2023.3.0b2
ESPHOME_REF = 2023.3.0b3
.PHONY: html html-strict cleanhtml deploy help live-html Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png minify

2
_static/version
View File

@ -1 +1 @@
2023.3.0b2
2023.3.0b3

6
changelog/2023.3.0.rst
View File

@ -70,6 +70,12 @@ Beta Changes
- Drop unused, broken logging macros :esphomepr:`4534` by :ghuser:`oxan`
- Revert storing Font glyphs in manually-allocated memory :esphomepr:`4516` by :ghuser:`oxan`
- Correct BME680 gas calculation and heater_off :esphomepr:`4498` by :ghuser:`CarlosGS`
- Add support for new mpu6050 clones responding with 0x70 address :esphomepr:`4546` by :ghuser:`jakehdk`
- Add carbon dioxide device class to scd30 sensor schema. :esphomepr:`4547` by :ghuser:`murrayma`
- Feat: add support for hex color in color component :esphomepr:`4493` by :ghuser:`dorianim`
- Allow AUTO_LOAD to be a function :esphomepr:`4550` by :ghuser:`jesserockz`
- On the ILI9xxx display's enable the psram on esp32 and allow big screen :esphomepr:`4551` by :ghuser:`nielsnl68`
- Map gpio pins for touch on esp32-s2/s3 :esphomepr:`4552` by :ghuser:`jesserockz`
All changes
^^^^^^^^^^^

24
components/binary_sensor/esp32_touch.rst
View File

@ -104,7 +104,10 @@ Configuration variables:
Touch Pad Pins
--------------
8 pins on the ESP32 can be used to detect touches. These are (in the default "raw" pin names):
Below are the raw GPIO pin numbers that can be used as touch pads for each variant.
ESP32
*****
- ``GPIO0``
- ``GPIO2``
@ -117,6 +120,25 @@ Touch Pad Pins
- ``GPIO32``
- ``GPIO33``
ESP32-S2 & ESP32-S3
*******************
- ``GPIO1``
- ``GPIO2``
- ``GPIO3``
- ``GPIO4``
- ``GPIO5``
- ``GPIO6``
- ``GPIO7``
- ``GPIO8``
- ``GPIO9``
- ``GPIO10``
- ``GPIO11``
- ``GPIO12``
- ``GPIO13``
- ``GPIO14``
Finding thresholds
------------------

23
components/display/index.rst
View File

@ -465,13 +465,36 @@ A ``color`` component exists for just this purpose:
blue: 25%
white: 0%
Alternatively, you can use ``<color>_int`` to specify the color as an int value:
.. code-block:: yaml
color:
- id: my_light_red
red_int: 255
green_int: 51
blue_int: 64
white_int: 0
Or, if you are more comforatble with hex values, you can use ``hex``:
.. code-block:: yaml
color:
- id: my_light_red
hex: FF3340
Configuration variables:
- **red** (*Optional*, percentage): The percentage of the red component. Defaults to ``100%``.
- **red_int** (*Optional*, integer): The brightness of the red component on a scale of ``0`` to ``255``. Defaults to ``255``.
- **green** (*Optional*, percentage): The percentage of the green component. Defaults to ``100%``.
- **green_int** (*Optional*, integer): The brightness of the green component on a scale of ``0`` to ``255``. Defaults to ``255``.
- **blue** (*Optional*, percentage): The percentage of the blue component. Defaults to ``100%``.
- **blue_int** (*Optional*, integer): The brightness of the blue component on a scale of ``0`` to ``255``. Defaults to ``255``.
- **white** (*Optional*, percentage): The percentage of the white component. Defaults to ``100%``.
- **white_int** (*Optional*, integer): The brightness of the white component on a scale of ``0`` to ``255``. Defaults to ``255``.
- **hex** (*Optional*, string): The color in hexadecimal representation. Defaults to ``FFFFFF``.
RGB displays use red, green, and blue, while grayscale displays may use white.

2
components/fan/hbridge.rst
View File

@ -50,7 +50,7 @@ Configuration variables:
- **enable_pin** (*Optional*, :ref:`config-id`): The id of the
:ref:`float output <output>` connected to the Enable pin of the h-bridge (if h-bridge uses enable).
- **decay_mode** (*Optional*, string): The decay mode you want to use with
the h-bridge. Either ``slow`` (braking) or ``fast`` (coasting). Defaults to ``slow``.
the h-bridge. Either ``slow`` (coasting) or ``fast`` (braking). Defaults to ``slow``.
- **speed_count** (*Optional*, int): Set the number of supported discrete speed levels. The value is used
to calculate the percentages for each speed. E.g. ``2`` means that you have 50% and 100% while ``100``
will allow 1% increments in the output. Defaults to ``100``.

2
components/matrix_keypad.rst
View File

@ -64,7 +64,7 @@ Individual keys can be added independently to ESPHome as ``binary_sensor``:
id: key4
row: 1
col: 0
- platform: keypad
- platform: matrix_keypad
id: keyA
key: A

17
components/remote_receiver.rst
View File

@ -66,7 +66,9 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. Use this if you have
multiple remote receivers.
Automations:
------------
- **on_aeha** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
AEHA remote code has been decoded. A variable ``x`` of type :apiclass:`remote_base::AEHAData`
@ -143,6 +145,21 @@ Automations:
Toshiba AC remote code has been decoded. A variable ``x`` of type :apistruct:`remote_base::ToshibaAcData`
is passed to the automation for use in lambdas.
.. code-block:: yaml
# Example automation for decoded signals
remote_receiver:
...
on_samsung:
then:
- if:
condition:
or:
- lambda: 'return (x.data == 0xE0E0E01F);' # VOL+ newer type
- lambda: 'return (x.data == 0xE0E0E01F0);' # VOL+ older type
then:
- ...
.. _remote-receiver-binary-sensor:
Binary Sensor

3
components/sensor/mics_4514.rst
View File

@ -10,9 +10,12 @@ This component exposes the different gas concentration sensors from the `MiCS-45
.. note::
The sensor has a 3-minute warmup period where data is unreliable and ESPHome will only start publishing sensor values after this time.
If the sensor was already powered only, such as if you restarted or updated your ESPHome device, then it will start publishing immediately.
The :ref:`I²C Bus <i2c>` is required to be set up in your configuration for this sensor to work.
.. code-block:: yaml
# Example configuration entry

7
components/time/index.rst
View File

@ -39,12 +39,19 @@ This :ref:`Condition <config-condition>` checks if time has been set and is vali
.. code-block:: yaml
# Example configuration
on_...:
if:
condition:
time.has_time:
then:
- logger.log: Time has been set and is valid!
# Example lambda
lambda: |-
if (id(my_time).now().is_valid()) {
//do something here
}
.. _time-on_time:

12
components/uart.rst
View File

@ -30,12 +30,12 @@ In some cases only **TX** or **RX** exists as the device at the other end only a
On the ESP32, this component uses the hardware UART units and is thus very accurate. On the ESP8266 however,
ESPHome has to use a software implementation as there are no other hardware UART units available other than the
ones used for logging. Therefore the UART data on the ESP8266 can have occasional data glitches especially with
higher baud rates..
higher baud rates.
.. note::
From ESPHome 2021.8 the ``ESP8266SoftwareSerial`` UART ``write_byte`` function had the parity bit fixed to be correct
for the data being sent. This could cause unexpected issues if you are using the Software Serial and have devices that
for the data being sent. This could cause unexpected issues if you are using the Software UART and have devices that
explicity check the parity. Most likely you will need to flip the ``parity`` flag in YAML.
@ -65,7 +65,7 @@ Configuration variables:
Hardware UARTs
--------------
Whenever possible, ESPHome will use the hardware UART unit on the processor for fast and accurate communication.
Whenever possible, ESPHome will use the hardware UART unit on the ESP8266 for fast and accurate communication.
When the hardware UARTs are all occupied, ESPHome will fall back to a software implementation that may not
be accurate at higher baud rates.
@ -74,12 +74,16 @@ be accurate at higher baud rates.
logger and leave others available. If you have configured the logger to use a different hardware UART, the pins
used for hardware sharing change accordingly.
The ESP32 has three UARTs. Any pair of GPIO pins can be used, as long as they support the proper output/input modes.
The ESP32 has three UARTs. ESP32 lite variant chips (ESP32-S3, ESP32-C3, ESP32-S2, etc) may have fewer UARTs (usually two). Any pair of GPIO pins can be used, as long as they support the proper output/input modes.
The ESP8266 has two UARTs; the second of which is TX-only. Only a limited set of pins can be used. ``UART0`` may
use either ``tx_pin: GPIO1`` and ``rx_pin: GPIO3``, or ``tx_pin: GPIO15`` and ``rx_pin: GPIO13``. ``UART1`` must
use ``tx_pin: GPIO2``. Any other combination of pins will result in use of a software UART.
.. note::
The the Software UART is only available on the ESP8266. It is not available on ESP32 and variants.
.. _uart-write_action:
``uart.write`` Action

2
conf.py
View File

@ -69,7 +69,7 @@ author = "ESPHome"
# The short X.Y version.
version = "2023.3"
# The full version, including alpha/beta/rc tags.
release = "2023.3.0b2"
release = "2023.3.0b3"
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.

5
guides/supporters.rst
View File

@ -246,6 +246,7 @@ Contributors
- `DrZoid (@docteurzoidberg) <https://github.com/docteurzoidberg>`__
- `Dominik (@DomiStyle) <https://github.com/DomiStyle>`__
- `Derek M. (@doolbneerg) <https://github.com/doolbneerg>`__
- `Dorian Zedler (@dorianim) <https://github.com/dorianim>`__
- `Mark Dietzer (@Doridian) <https://github.com/Doridian>`__
- `Jiang Sheng (@doskoi) <https://github.com/doskoi>`__
- `Robert Schütz (@dotlambda) <https://github.com/dotlambda>`__
@ -625,6 +626,7 @@ Contributors
- `Michael Davidson (@MrMDavidson) <https://github.com/MrMDavidson>`__
- `mtl010957 (@mtl010957) <https://github.com/mtl010957>`__
- `mulcmu (@mulcmu) <https://github.com/mulcmu>`__
- `Martin Murray (@murrayma) <https://github.com/murrayma>`__
- `Michel van de Wetering (@mvdwetering) <https://github.com/mvdwetering>`__
- `Michiel van Turnhout (@mvturnho) <https://github.com/mvturnho>`__
- `Martin Weinelt (@mweinelt) <https://github.com/mweinelt>`__
@ -807,7 +809,6 @@ Contributors
- `Stefan Staub (@sstaub) <https://github.com/sstaub>`__
- `St4n (@St4n) <https://github.com/St4n>`__
- `Stanislav Habich (@standahabich) <https://github.com/standahabich>`__
- `Stas (@stas-sl) <https://github.com/stas-sl>`__
- `stegm (@stegm) <https://github.com/stegm>`__
- `Stewart (@stewiem2000) <https://github.com/stewiem2000>`__
- `sticilface (@sticilface) <https://github.com/sticilface>`__
@ -910,4 +911,4 @@ Contributors
- `Zack Barett (@zsarnett) <https://github.com/zsarnett>`__
- `Christian Zufferey (@zuzu59) <https://github.com/zuzu59>`__
*This page was last updated March 9, 2023.*
*This page was last updated March 13, 2023.*