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

Merge branch 'current' into next

Browse Source
This commit is contained in:
Jesse Hills 2023-02-08 23:37:59 +00:00
commit a6fff4b5f2
No known key found for this signature in database
GPG Key ID: BEAAE804EFD8E83A
18 changed files with 256 additions and 43 deletions

4
.devcontainer/devcontainer.json
View File

@ -1,10 +1,10 @@
// https://github.com/microsoft/vscode-dev-containers/tree/v0.183.0/containers/python-3
{
"name": "ESPHome - docs",
"image": "mcr.microsoft.com/vscode/devcontainers/python:0-3.6",
"image": "mcr.microsoft.com/vscode/devcontainers/python:0-3.10",
"postCreateCommand": "pip3 install -r requirements.txt -r requirements_test.txt",
"forwardPorts": [8000],
"settings": {
"settings": {
"python.pythonPath": "/usr/local/bin/python",
"python.languageServer": "Pylance",
"python.linting.enabled": true,

8
changelog/2022.12.0.rst
View File

@ -94,6 +94,14 @@ Release 2022.12.7 - January 26
- Fix BME280 initialization before wifi setup :esphomepr:`4190` by :ghuser:`pxe-la`
- Add a soft reset in setup() for bmp280 :esphomepr:`4329` by :ghuser:`melyux`
Release 2022.12.8 - January 27
------------------------------
- Upgrades add-on base image to 6.2.0 :esphomepr:`4310` by :ghuser:`frenck`
- Migrate old-style S6 scripts to s6-rc.d :esphomepr:`4311` by :ghuser:`frenck`
- Refactor NGINX configuration of Home Assistant Add-on :esphomepr:`4312` by :ghuser:`frenck`
- Add Home Assistant integration discovery :esphomepr:`4328` by :ghuser:`frenck`
Full list of changes
--------------------

4
components/deep_sleep.rst
View File

@ -30,6 +30,10 @@ even Over The Air updates.
run_duration: 10s
sleep_duration: 10min
.. note::
ESP8266 that have an onboard USB chip (e.g. D1 mini) one the chips' control lines is connected to the RST pin. This enables the flasher can reboot the ESP when required. This may interfere with deep sleep on some devices and prevent the ESP from waking when it's powered through its USB connector. Powering the ESP from a separate 3.3V source connected to the 3.3V pin and GND will solve this issue. In these cases using a USB to TTL adapter will allow you to log ESP activity.
Configuration variables:
------------------------

8
components/display/index.rst
View File

@ -170,6 +170,13 @@ Next, create a ``font:`` section in your configuration:
id: roboto
size: 20
- file:
type: gfonts
family: Roboto
weight: 900
id: font2
size: 16
- file: "fonts/tom-thumb.bdf"
id: tomthumb
@ -479,6 +486,7 @@ Configuration variables:
- **traces** (*Optional*): Use this to specify more than a single trace.
Trace specific fields:
- **sensor** (*Optional*, :ref:`config-id`): The sensor value to plot
- **line_thickness** (*Optional*): Defaults to 3
- **line_type** (*Optional*): Specifies the plot line-type. Can be one of the following: ``SOLID``, ``DOTTED``, ``DASHED``. Defaults to ``SOLID``.

54
components/display/st7789v.rst
View File

@ -217,35 +217,38 @@ appropriate lines of C code in the lambda to hide or show the image or text as y
name: "T-Display Button Input 1"
id: tdisplay_button_input_1
# We can still control the backlight independently
switch:
- platform: gpio
pin: GPIO4
name: "Backlight"
id: backlight
# Allow dimmable control of the backlight (pin GPIO4)
output:
- platform: ledc
pin: GPIO4
id: gpio4
image:
- file: "image.png"
id: my_image
resize: 200x200
type: RGB24
light:
- platform: monochromatic
output: gpio4
name: "Backlight"
time:
- platform: homeassistant
id: esptime
image:
- file: "image.png"
id: my_image
resize: 200x200
type: RGB24
spi:
clk_pin: GPIO18
mosi_pin: GPIO19
time:
- platform: homeassistant
id: esptime
display:
- platform: st7789v
backlight_pin: GPIO4
cs_pin: GPIO5
dc_pin: GPIO16
reset_pin: GPIO23
rotation: 270
lambda: |-
spi:
clk_pin: GPIO18
mosi_pin: GPIO19
display:
- platform: st7789v
cs_pin: GPIO5
dc_pin: GPIO16
reset_pin: GPIO23
rotation: 270
lambda: |-
it.rectangle(0, 0, it.get_width(), it.get_height(), id(my_blue));
it.rectangle(0, 20, it.get_width(), it.get_height(), id(my_blue)); // header bar
@ -263,6 +266,7 @@ appropriate lines of C code in the lambda to hide or show the image or text as y
it.print(235, 5, id(helvetica_12), id(my_red), TextAlign::TOP_RIGHT, "Offline");
}
See Also
--------

7
components/light/index.rst
View File

@ -203,6 +203,13 @@ them to zero.
// perform action:
call.perform();
Shorter example using auto call , call.set_brightness and call.perform.
.. code-block:: cpp
id(light_1).turn_on().set_brightness(1.0).perform();
.. note::
The ``red``, ``green`` and ``blue`` values only control the color of the light, not its

2
components/output/index.rst
View File

@ -43,7 +43,7 @@ Configuration variables:
Float outputs only:
- **min_power** (*Optional*, float): Sets the minimum output value of this output platform.
Must be in range from 0 to max_power. Defaults to ``0``.
Must be in range from 0 to max_power. Defaults to ``0``. If zero_means_zero is ``false`` this will be output value when the entity is turned off.
- **max_power** (*Optional*, float): Sets the maximum output value of this output platform.
Must be in range from min_power to 1. Defaults to ``1``.
- **zero_means_zero** (*Optional*, boolean): Sets the output to use actual 0 instead of ``min_power``.

6
components/output/modbus_controller.rst
View File

@ -12,7 +12,7 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **name** (**Required**, string): The name of the sensor.
- **address** (**Required**, int): start address of the first register in a range
- **value_type** (**Required**): datatype of the modbus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first)
- **value_type** (**Required**): data type of the modbus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first)
- ``U_WORD`` (unsigned 16 bit integer from 1 register = 16bit)
- ``S_WORD`` (signed 16 bit integer from 1 register = 16bit)
@ -21,9 +21,9 @@ Configuration variables:
- ``U_DWORD_R`` (unsigned 32 bit integer from 2 registers low word first)
- ``S_DWORD_R`` (signed 32 bit integer from 2 registers low word first)
- ``U_QWORD`` (unsigned 64 bit integer from 4 registers = 64bit)
- ``S_QWORD`` (unsigned 64 bit integer from 4 registers = 64bit)
- ``S_QWORD`` (signed 64 bit integer from 4 registers = 64bit)
- ``U_QWORD_R`` (unsigned 64 bit integer from 4 registers low word first)
- ``U_QWORD_R`` signed 64 bit integer from 4 registers low word first)
- ``S_QWORD_R`` signed 64 bit integer from 4 registers low word first)
- ``FP32`` (32 bit IEEE 754 floating point from 2 registers)
- ``FP32_R`` (32 bit IEEE 754 floating point - same as FP32 but low word first)

53
components/output/sm16716.rst
View File

@ -102,7 +102,7 @@ Configuration variables:
Feit Electric A19 Smart WiFi Bulb
---------------------------------
This component can be used with a Feit Electric A19 smart light bulb. You can use
This component can be used with a version of a Feit Electric A19 smart light bulb. You can use
tuya-convert to flash the bulb. The cold white LEDs are connected to PWM1 and the
warm white LEDs are connected to PWM2. The RGB LEDs are connected to a SM16716
chip that is connected to GPIO4 for clock, GPIO14 for data, and GPIO13 for power.
@ -174,7 +174,58 @@ 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
sm16716:
data_pin: GPIO12
clock_pin: GPIO14
num_channels: 3
num_chips: 1
output:
- platform: sm16716
id: output_red
channel: 2
power_supply: rgb_power
- platform: sm16716
id: output_green
channel: 1
power_supply: rgb_power
- platform: sm16716
id: output_blue
channel: 0
power_supply: rgb_power
- platform: esp8266_pwm
id: output_color_temperature
inverted: true
pin: GPIO5
- platform: esp8266_pwm
id: output_brightness
min_power: 0.05
zero_means_zero: true
pin: GPIO4
light:
- platform: rgbct
name: ${friendly_name}
id: outside
red: output_red
green: output_green
blue: output_blue
color_temperature: output_color_temperature
white_brightness: output_brightness
cold_white_color_temperature: 153 mireds
warm_white_color_temperature: 370 mireds
color_interlock: true
power_supply:
- id: rgb_power
pin: GPIO13
See Also
--------

2
components/rp2040.rst
View File

@ -34,7 +34,7 @@ This component contains platform-specific options for the RP2040 platform.
Configuration variables:
------------------------
- **board** (*Optional*, string): The board type. Valid options are ``rpipico`` and ``rpipicow``.
- **board** (*Optional*, string): The board type. Valid option is ``rpipicow``.
See Also
--------

6
components/sensor/ccs811.rst
View File

@ -1,11 +1,11 @@
CCS811 CO_2 and Volatile Organic Compound Sensor
================================================
CCS811 eCO_2 and Volatile Organic Compound Sensor
=================================================
.. seo::
:description: Instructions for setting up CCS811 sensors.
:image: ccs811.jpg
The ``ccs811`` sensor platform allows you to use CCS811 CO_2 and volatile organic compound sensors
The ``ccs811`` sensor platform allows you to use CCS811 eCO_2 and volatile organic compound sensors
(`Adafruit`_) with ESPHome.
.. note::

2
components/sensor/dallas.rst
View File

@ -89,7 +89,7 @@ Configuration variables:
- **index** (**Required**, int): The index of the sensor starting with 0.
So the first sensor will for example have index 0. :ref:`It’s recommended
to use address instead <dallas-getting-ids>`.
- **resolution** (*Optional*, int): An optional resolution from 8 to
- **resolution** (*Optional*, int): An optional resolution from 9 to
12. Higher means more accurate. Defaults to the maximum for most Dallas temperature sensors: 12.
- **dallas_id** (*Optional*, :ref:`config-id`): The ID of the :ref:`dallas hub <dallas-component>`.
Use this if you have multiple dallas hubs.

130
components/sensor/daly_bms.rst
View File

@ -228,6 +228,136 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
Control BMS
-----------
At this moment Daly sensor platform don't suppport controlling you BMS, but you can make some stuff using uart.write
First you need to setup binary sensors for charging and disharging MOS
.. code-block:: yaml
binary_sensor:
- platform: daly_bms
charging_mos_enabled:
name: "Daly Charging MOS"
id: bin_daly_chg_mos # binary MOS sensor must have ID to use with switch
internal: True # but you can make it internal to avoid duplication
discharging_mos_enabled:
name: "Daly Discharging MOS"
id: bin_daly_dischg_mos # binary MOS sensor must have ID to use with switch
internal: True # but you can make it internal to avoid duplication
Then you can add switches
.. code-block:: yaml
switch:
- platform: template
name: "Daly Charging MOS"
lambda: |-
if (id(bin_daly_chg_mos).state) {
return true;
} else {
return false;
}
turn_on_action:
- uart.write:
data: [0xA5, 0x40, 0xDA, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC8]
- logger.log:
format: "Send cmd to Daly: Set charge MOS on"
turn_off_action:
- uart.write:
data: [0xA5, 0x40, 0xDA, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC7]
- logger.log:
format: "Send cmd to Daly: Set charge MOS off"
- platform: template
name: "Daly Discharging MOS"
lambda: |-
if (id(bin_daly_dischg_mos).state) {
return true;
} else {
return false;
}
turn_on_action:
- uart.write:
data: [0xA5, 0x40, 0xD9, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC7]
- logger.log:
format: "Send cmd to Daly: Set discharge MOS on"
turn_off_action:
- uart.write:
data: [0xA5, 0x40, 0xD9, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC6]
- logger.log:
format: "Send cmd to Daly: Set discharge MOS off"
Also you can add select to change battery level
.. code-block:: yaml
select:
- platform: template
name: "Daly Battery Level setup"
optimistic: True
options:
- 100%
- 75%
- 50%
- 25%
- 0%
initial_option: 100%
set_action:
then:
- if:
condition:
lambda: 'return x == "100%";'
then:
- uart.write:
data: [0xA5, 0x40, 0x21, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0xE8, 0xF9]
- logger.log:
format: "Send cmd to Daly: Set SOC to 100%"
else:
- if:
condition:
lambda: 'return x == "75%";'
then:
- uart.write:
data: [0xA5, 0x40, 0x21, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0xEE, 0xFE]
- logger.log:
format: "Send cmd to Daly: Set SOC to 75%"
else:
- if:
condition:
lambda: 'return x == "50%";'
then:
- uart.write:
data: [0xA5, 0x40, 0x21, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0xF4, 0x03]
- logger.log:
format: "Send cmd to Daly: Set SOC to 50%"
else:
- if:
condition:
lambda: 'return x == "25%";'
then:
- uart.write:
data: [0xA5, 0x40, 0x21, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFA, 0x08]
- logger.log:
format: "Send cmd to Daly: Set SOC to 25%"
else:
- if:
condition:
lambda: 'return x == "0%";'
then:
- uart.write:
data: [0xA5, 0x40, 0x21, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0E]
- logger.log:
format: "Send cmd to Daly: Set SOC to 0%"
UART Connection
---------------

4
components/sensor/index.rst
View File

@ -433,7 +433,7 @@ An average over the ``specified time period``, potentially throttling incoming v
For example a ``throttle_average: 60s`` will push out a value every 60 seconds, in case at least one sensor value is received within these 60 seconds.
In comparison to the ``throttle`` filter it won't discard any values. In comparison to the ``sliding_window_moving_average`` filter it supports variable sensor reporting rates without influencing the filter reporting interval (except for the first edge case).
In comparison to the ``throttle`` filter, it won't discard any values. In comparison to the ``sliding_window_moving_average`` filter, it supports variable sensor reporting rates without influencing the filter reporting interval (except for the first edge case).
``heartbeat``
*************
@ -648,7 +648,7 @@ advanced stuff (see the full API Reference for more info).
// For example, create a custom log message when a value is received:
ESP_LOGI("main", "Value of my sensor: %f", id(my_sensor).state);
- ``raw_state``: Retrieve the current value of the sensor that has not passed through any filters
- ``raw_state``: Retrieve the current value of the sensor that has not passed through any filters.
Is ``NAN`` if no value has been pushed by the sensor itself yet.
.. code-block:: cpp

1
guides/diy.rst
View File

@ -57,6 +57,7 @@ Blog Posts & Videos
- `Little thermostat based on AZ-Touch hardware and esphome <https://github.com/ingbenna/AZ-Touch_esphome_thermostat/>`_ by ingbenna
- `Converting a Carro Home DC Fan to ESPHome <https://1projectaweek.com/blog/2022/2/8/converting-a-carro-home-dc-fan-to-esp-home>`__ by `Bill Church <https://1projectaweek.com>`__
- `Automated Coffee Bean Roaster <https://hackaday.io/project/186852-automated-coffee-bean-roaster>`__ by `brooksben11 <https://hackaday.io/brooksben11>`__
- `Droplet Smart Irrigation System <https://github.com/PricelessToolkit/Droplet>`__ by `PricelessToolkit <https://github.com/PricelessToolkit>`__
Custom Components & Code
------------------------

2
guides/getting_started_command_line.rst
View File

@ -133,7 +133,7 @@ to your docker command to map a local USB device. Docker on Mac will not be able
.. code-block:: bash
docker run --rm -v "${PWD}":/config --device=/dev/ttyUSB0 -it esphome/esphome run livingroom.yaml
docker run --rm --privileged -v "${PWD}":/config --device=/dev/ttyUSB0 -it esphome/esphome run livingroom.yaml
Now when you go to the Home Assistant "Integrations" screen (under "Configuration" panel), you
should see the ESPHome device show up in the discovered section (although this can take up to 5 minutes).

2
guides/migrate_sonoff_tasmota.rst
View File

@ -58,7 +58,7 @@ Happy Hacking!
.. note::
If you are using Tasmota 8+ and get an error after uploading the firmware, go to the console and type ```SetOption78 1```, then restart the device and try the firmware again.
If you are using Tasmota 8+ on ESP8266 and get an error after uploading the firmware, first upload ``tasmota-minimal.bin.gz`` from Tasmota repository, next upload firmware generated from ESPHome. Another way to try is to simply ``gzip`` the ESPHome binary and upload the ``.gz`` file instead.
See Also
--------

4
guides/supporters.rst
View File

@ -571,6 +571,7 @@ Contributors
- `MartinWelsch (@MartinWelsch) <https://github.com/MartinWelsch>`__
- `MasterTim17 (@MasterTim17) <https://github.com/MasterTim17>`__
- `Christopher Masto (@masto) <https://github.com/masto>`__
- `Mat931 (@Mat931) <https://github.com/Mat931>`__
- `Mateus Demboski (@mateusdemboski) <https://github.com/mateusdemboski>`__
- `matikij (@matikij) <https://github.com/matikij>`__
- `Michel Marti (@matoxp) <https://github.com/matoxp>`__
@ -688,7 +689,6 @@ Contributors
- `Philippe FOUQUET (@Philippe12) <https://github.com/Philippe12>`__
- `pieterbrink123 (@pieterbrink123) <https://github.com/pieterbrink123>`__
- `Piotr Kubiak (@piotr-kubiak) <https://github.com/piotr-kubiak>`__
- `Tommy van der Vorst (@pixelspark) <https://github.com/pixelspark>`__
- `Peter Kuehne (@pkuehne) <https://github.com/pkuehne>`__
- `Plácido Revilla (@placidorevilla) <https://github.com/placidorevilla>`__
- `Marcus Kempe (@plopp) <https://github.com/plopp>`__
@ -907,4 +907,4 @@ Contributors
- `Zack Barett (@zsarnett) <https://github.com/zsarnett>`__
- `Christian Zufferey (@zuzu59) <https://github.com/zuzu59>`__
*This page was last updated January 26, 2023.*
*This page was last updated January 27, 2023.*