Upstream/esphome-docs
1
0
Fork 0
mirror of https://github.com/esphome/esphome-docs.git synced 2025-02-28 03:41:57 +01:00
Code Issues Projects Releases Wiki Activity

Merge branch 'current' into next

Browse Source
This commit is contained in:
Jesse Hills 2024-02-13 09:44:35 +13:00
commit 9f189c737a
No known key found for this signature in database
GPG Key ID: BEAAE804EFD8E83A
29 changed files with 605 additions and 537 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
changelog/2023.12.0.rst
View File

@ -104,6 +104,20 @@ Release 2023.12.7 - January 17
- Create RingBuffer for VoiceAssistant :esphomepr:`6102` by :ghuser:`jesserockz`
- Inkplate6: Fix crash with initial set of greyscale :esphomepr:`6038` by :ghuser:`clydebarrow`
Release 2023.12.8 - January 19
------------------------------
- Let show_*_page actions depend on "Display" :esphomepr:`6092` by :ghuser:`guillempages`
- Fix some Voice Assistant bugs :esphomepr:`6121` by :ghuser:`jesserockz`
Release 2023.12.9 - January 22
------------------------------
- fix sen5x negative temperature :esphomepr:`6082` by :ghuser:`ssieb`
- negative values for all DHT22 variants :esphomepr:`6074` by :ghuser:`ssieb`
- fix negative temperature for pmsx003 :esphomepr:`6083` by :ghuser:`ssieb`
- fix: negative temperatures on PMS5003T sensors :esphomepr:`6100` by :ghuser:`aschmitz`
Full list of changes
--------------------

2
components/binary_sensor/index.rst
View File

@ -35,7 +35,7 @@ Configuration variables:
you want the binary sensor to use that name, you can set ``name: None``.
- **device_class** (*Optional*, string): The device class for the
sensor. See https://developers.home-assistant.io/docs/core/entity/binary-sensor/#available-device-classes
sensor. See https://www.home-assistant.io/integrations/binary_sensor/#device-class
for a list of available options.
- **icon** (*Optional*, icon): Manually set the icon to use for the binary sensor in the frontend.
- **filters** (*Optional*, list): A list of filters to apply on the binary sensor values such as

48
components/binary_sensor/modbus_controller.rst
View File

@ -16,26 +16,25 @@ Configuration variables:
- **name** (**Required**, string): The name of the sensor.
- **register_type** (**Required**): type of the modbus register.
- ``coil``: Function 01 (01hex) Read Coils - Reads the ON/OFF status of discrete coils in the device.
- ``discrete_input``: Function 02(02hex) - Reads the ON/OFF status of discrete inputs in the device.
- ``holding``: Function 03 (03hex) Read Holding Registers - Read the binary contents of holding registers in the device.
- ``read``: Function 04 (04hex) Read Input Registers - Read the binary contents of input registers in the device.
- ``coil``: Coils are 1-bit registers (ON/OFF values) that are used to control discrete outputs. Read and Write access. Modbus *Function Code 1 (Read Coil Status)* will be used.
- ``discrete_input``: discrete input register (read only coil) are similar to coils but can only be read. Modbus *Function Code 2 (Read Input Status)* will be used.
- ``holding``: Holding Registers - Holding registers are the most universal 16-bit register. Read and Write access. Modbus *Function Code 3 (Read Holding Registers)* will be used.
- ``read``: Read Input Registers - registers are 16-bit registers used for input, and may only be read. Modbus *Function Code 4 (Read Input Registers)* will be used.
- **address** (**Required**, int): start address of the first register in a range
- **bitmask** (*Optional*, int): Some values are packed in a response. The bitmask is used to determined if the result is true or false
- **skip_updates** (*Optional*, int): By default all sensors of a modbus_controller are updated together. For data points that don't change very frequently updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **bitmask** (*Optional*, int): sometimes multiple values are packed in a single register's response. The bitmask is used to determined if the result is true or false. See :ref:`bitmasks`.
- **skip_updates** (*Optional*, int): By default all sensors of a modbus_controller are updated together. For data points that don't change very frequently updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle. Note: The modbus_controller groups components by address ranges to reduce number of transactions. All components with the same starting address will be updated in one request. ``skip_updates`` applies for *all* components in the same range.
- **register_count** (*Optional*, int): The number of consecutive registers this read request should span or skip in a single command. Default is 1. See :ref:`modbus_register_count` for more details.
- **response_size** (*Optional*, int): Size of the response for the register in bytes. Defaults to register_count*2.
- **force_new_range** (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting ``force_new_range: true`` enforces the start of a new range at that address.
- **custom_command** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_command`` is used ``address`` and ``register_type`` can't be used.
custom data must contain all required bytes including the modbus device address. The crc is automatically calculated and appended to the command.
See :ref:`modbus_custom_command` how to use ``custom_command``
Custom data must contain all required bytes including the modbus device address. The CRC is automatically calculated and appended to the command.
See :ref:`modbus_custom_command` how to use ``custom_command``.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda to be evaluated every update interval to get the new value of the sensor
Parameters
Lambda to be evaluated every update interval to get the new value of the sensor. Parameters:
- **x** (bool): The parsed float value of the modbus data
- **data** (std::vector<uint8_t): vector containing the complete raw modbus response bytes for this sensor
- **data** (std::vector<uint8_t>): vector containing the complete raw modbus response bytes for this sensor
- **item** (const pointer to a ModbusBinarySensor object): The sensor object itself.
Possible return values for the lambda:
@ -43,21 +42,19 @@ Configuration variables:
- ``return true/false;`` the new value for the sensor.
- **offset** (*Optional*, int): not required for most cases
offset from start address in bytes. If more than one register is read a modbus read registers command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type
The value for offset depends on the register type. If a binary_sensor is created from an input register the offset is in bytes. For coil and discrete input resisters the LSB of the first data byte contains the coil addressed in the request. The other coils follow toward the high-order end of this byte and from low order to high order in subsequent bytes. For the registers offset is the position of the relevant bit.
To get the value of the coil register 2 can be retrieved using address: 2 / offset: 0 or address: 0 / offset 2
- **offset** (*Optional*, int): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a command, this value is used to find the start of this datapoint relative to the start address. The component calculates the size of the range based on offset and size of the value type. The value for offset depends on the register type. If a binary_sensor is created from an input register, the offset is in bytes. For coil and discrete input resisters, the LSB of the first data byte contains the coil addressed in the request. The other coils follow toward the high-order end of this byte and from low order to high order in subsequent bytes. For registers, the offset is the position of the relevant bit. To get the value of the coil register, 2 can be retrieved using ``address: 2`` / ``offset: 0`` or ``address: 0`` / ``offset 2``.
- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
Example
Example:
--------
.. code-block:: yaml
binary_sensor:
- platform: modbus_controller
modbus_controller_id: epever
id: battery_internal_resistance_abnormal
name: "Battery internal resistance abnormal"
modbus_controller_id: modbus1
name: "Error status"
register_type: read
address: 0x3200
bitmask: 0x80 #(bit 8)
@ -65,11 +62,14 @@ Example
See Also
--------
- :apiclass:`:modbus_controller::ModbusBinarySensor`
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- https://www.modbustools.com/modbus.html
- :apiclass:`:modbus_controller::ModbusBinarySensor`
- :ghedit:`Edit`

2
components/button/index.rst
View File

@ -57,7 +57,7 @@ Configuration variables:
See https://developers.home-assistant.io/docs/core/entity/#generic-properties
for a list of available options. Set to ``""`` to remove the default entity category.
- **device_class** (*Optional*, string): The device class for the button.
See https://developers.home-assistant.io/docs/core/entity/button/#available-device-classes
See https://www.home-assistant.io/integrations/button/#device-class
for a list of available options.
Automations:

2
components/cover/index.rst
View File

@ -36,7 +36,7 @@ Configuration variables:
you want the cover to use that name, you can set ``name: None``.
- **device_class** (*Optional*, string): The device class for the
sensor. See https://www.home-assistant.io/components/cover/ for a list of available options.
sensor. See https://www.home-assistant.io/integrations/cover/#device-class for a list of available options.
- **icon** (*Optional*, icon): Manually set the icon to use for the cover in the frontend.
Advanced options:

2
components/display/inkplate6.rst
View File

@ -282,7 +282,7 @@ Inkplate 6 Plus Touchscreen
***************************
The Inkplate 6 Plus has a built in touchscreen supported by ESPHome. Note you need to enable pin 12 on the mcp23017 to enable the touchscreen
Below is a config example with touchscreen power swtich:
Below is a config example with touchscreen power switch:
.. code-block:: yaml

4
components/ethernet.rst
View File

@ -98,6 +98,10 @@ Configuration examples
phy_addr: 0
power_pin: GPIO12
.. note::
WROVER version of Olimex POE cards change CLK to ping GPIO0, configuration must be `clk_mode: GPIO0_OUT`.
**Olimex ESP32-EVB**:

3
components/light/esp32_rmt_led_strip.rst
View File

@ -50,6 +50,9 @@ Configuration variables
16ms will limit the light to a refresh rate of about 60Hz. Defaults to sending commands as quickly as
changes are made to the lights.
- All other options from :ref:`Light <config-light>`.
Manual Timings
**************

1
components/light/rp2040_pio_led_strip.rst
View File

@ -42,6 +42,7 @@ Configuration variables
- **is_rgbw** (*Optional*, boolean): Set to ``true`` if the strip is RGBW. Defaults to ``false``.
- All other options from :ref:`Light <config-light>`.
Manual Timings

2
components/logger.rst
View File

@ -10,7 +10,7 @@ Logger Component
The logger component automatically logs all log messages through the
serial port and through MQTT topics (if there is an MQTT client in the
configuration). By default, all logs with a severity ``DEBUG`` or higher will be shown.
Increasing the log level severity (to e.g ``INFO`` or ``WARNING``) can help with the performance of the application and memory size.
Increasing the log level severity (to e.g ``INFO`` or ``WARN``) can help with the performance of the application and memory size.
.. code-block:: yaml

34
components/modbus.rst
View File

@ -7,9 +7,32 @@ Modbus Component
:description: Instructions for setting up Modbus in ESPHome.
:keywords: Modbus
The ModBUS protocol is used by many consumer and industrial devices for communication.
This component allows components in ESPHome to communicate to those devices.
ModBUS requires a :ref:`UART Bus <uart>` to communicate.
The Modbus protocol is used by many consumer and industrial devices for communication.
This component allows components in ESPHome to communicate to those devices via RTU protocol. You can access the coils, inputs, holding, read registers from your devices as sensors, switches, selects, numbers or various other ESPHome components and present them to your favorite Home Automation system. You can even write them as binary or float ouptputs from ESPHome.
The various sub-components implement some of the Modbus functions below (depending on their required functionality):
+---------------+----------------------------+
| Function Code | Description |
+===============+============================+
| 1 | Read Coil Status |
+---------------+----------------------------+
| 2 | Read Discrete input Status |
+---------------+----------------------------+
| 3 | Read Holding Registers |
+---------------+----------------------------+
| 4 | Read Input Registers |
+---------------+----------------------------+
| 5 | Write Single Coil |
+---------------+----------------------------+
| 6 | Write Single Register |
+---------------+----------------------------+
| 15 | Write Multiple Coils |
+---------------+----------------------------+
| 16 | Write Multiple Registers |
+---------------+----------------------------+
Modbus RTU requires a :ref:`UART Bus <uart>` to communicate.
.. code-block:: yaml
@ -45,10 +68,11 @@ See Also
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- `Modbus RTU Protocol Description <https://www.modbustools.com/modbus.html>`__
- :ref:`uart`
- :apiref:`modbus/modbus.h`

412
components/modbus_controller.rst
View File

@ -2,11 +2,11 @@ Modbus Controller
=================
.. seo::
:description: Instructions for setting up the ModBUS Controller component.
:description: Instructions for setting up the Modbus Controller component.
:image: modbus.png
The ``modbus_controller`` component creates a RS485 connection to control a ModBUS slave device, letting your ESPHome node to act as a ModBUS master.
You can access the coils and registers from your slave ModBUS device as sensors, switches or various other ESPHome components and present them to your favorite Home Automation system.
The ``modbus_controller`` component creates a RS485 connection to control a Modbus server (slave) device, letting your ESPHome node to act as a Modbus client (master).
You can access the coils, inputs, holding, read registers from your devices as sensors, switches, selects, numbers or various other ESPHome components and present them to your favorite Home Automation system. You can even write them as binary or float ouptputs from ESPHome.
.. figure:: /images/modbus.png
:align: center
@ -26,7 +26,7 @@ See `How is this RS485 module working? <https://electronics.stackexchange.com/qu
The transceiver connects to the UART of the MCU. For ESP32, pin ``16`` to ``TXD`` and pin ``17`` to ``RXD`` are the default ones but any other pins can be used as well. ``3.3V`` to ``VCC`` and naturally ``GND`` to ``GND``.
On the bus side, you need 120 Ohm termination resistors at the ends of the bus cable as per ModBUS standard. Some transceivers have this already solderes onboard, and some slave devices may have them preinstalled with a jumper or a dip switch.
On the bus side, you need 120 Ohm termination resistors at the ends of the bus cable as per Modbus standard. Some transceivers have this already soldered onboard, while some slave devices may have them available via a jumper or a DIP switch.
.. note::
@ -34,7 +34,7 @@ On the bus side, you need 120 Ohm termination resistors at the ends of the bus c
For hardware serial only a limited set of pins can be used. Either ``tx_pin: GPIO1`` and ``rx_pin: GPIO3`` or ``tx_pin: GPIO15`` and ``rx_pin: GPIO13``.
The disadvantage of using the hardware uart is that you can't use serial logging because the serial logs would be sent to the ModBUS device and cause errors.
The disadvantage of using the hardware UART is that you can't use serial logging because the serial logs would be sent to the Modbus device(s) instead, causing errors.
Serial logging can be disabled by setting ``baud_rate: 0``.
@ -46,17 +46,15 @@ On the bus side, you need 120 Ohm termination resistors at the ends of the bus c
level: <level>
baud_rate: 0
Configuration variables:
------------------------
- **modbus_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the ``modbus`` hub.
- **address** (**Required**, :ref:`config-id`): The ModBUS address of the slave device
- **address** (**Required**, :ref:`config-id`): The Modbus address of the slave device
- **command_throttle** (*Optional*, :ref:`config-time`): minimum time in between 2 requests to the device. Default is ``0ms``.
Some ModBUS slave devices limit the rate of requests from the master, the interval between sending requests can be altered.
Some Modbus slave devices limit the rate of requests from the master, so this allows the interval between requests to be altered.
- **update_interval** (*Optional*, :ref:`config-time`): The interval that the sensors should be checked.
Defaults to 60 seconds.
@ -66,7 +64,6 @@ Configuration variables:
slaves, this avoids waiting for timeouts allowing to read other slaves in the same bus. When the slave
responds to a command, it'll be marked online again.
Example
-------
The following code creates a ``modbus_controller`` hub talking to a ModBUS device at address ``1`` with ``115200`` bps
@ -76,54 +73,56 @@ Technically there is no difference between the "inline" and the standard definit
.. code-block:: yaml
# Example configuration entry
uart:
id: mod_bus
tx_pin: 17
rx_pin: 16
baud_rate: 115200
stop_bits: 1
...
modbus:
flow_control_pin: 5
id: modbus1
modbus_controller:
- id: epever
address: 0x1 ## address of the ModBUS slave device on the bus
modbus_id: modbus1
setup_priority: -10
text_sensor:
- name: "rtc_clock"
platform: modbus_controller
modbus_controller_id: epever
id: rtc_clock
internal: true
register_type: holding
address: 0x9013 ## address of the register inside the ModBUS slave device
register_count: 3
raw_encode: HEXBYTES
response_size: 6
switch:
- platform: modbus_controller
modbus_controller_id: epever
id: reset_to_fabric_default
name: "Reset to Factory Default"
register_type: coil
address: 0x15
bitmask: 1
- id: modbus_device
address: 0x1 ## address of the Modbus slave device on the bus
modbus_id: modbus1
setup_priority: -10
sensor:
- platform: modbus_controller
modbus_controller_id: epever
name: "Battery Capacity"
id: battery_capacity
register_type: holding
address: 0x9001
unit_of_measurement: "AH"
value_type: U_WORD
- platform: modbus_controller
modbus_controller_id: modbus_device
name: "Battery Capacity"
register_type: holding
address: 0x9001 ## address of the register inside the Modbus slave device
unit_of_measurement: "AH"
value_type: U_WORD
switch:
- platform: modbus_controller
modbus_controller_id: modbus_device
name: "Reset to Factory Default"
register_type: coil
address: 0x15
bitmask: 1
text_sensor:
- name: "rtc_clock"
platform: modbus_controller
modbus_controller_id: modbus_device
id: rtc_clock
internal: true
register_type: holding
address: 0x9013
register_count: 3
raw_encode: HEXBYTES
response_size: 6
The configuration example above creates a ``modbus_controller`` hub talking to a Modbus device at address ``1`` with a baudrate of ``115200`` bps, implementing a sensor, a switch and a text sensor.
Check out the various Modbus components available at the bottom of the document in the :ref:`modbusseealso` section. They can be directly defined *(inline)* under the ``modbus_controller`` hub or as standalone components. Technically there is no difference between the *inline* and the standard definitions approach.
Below you find a few general tips about using Modbus in more advanced scenarios. Applicable component functionalities have links pointing here:
.. _bitmasks:
Bitmasks
--------
@ -166,7 +165,7 @@ Some devices use decimal values in read registers to show multiple binary states
| bit 15 | Binary Sensor 15 | 32768 | 8000 |
+------------+------------------+-----------+-----------+
For example, when reading register ``15``, a decimal value of ``12288`` 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``:
@ -174,39 +173,166 @@ To gather some of these bits as binary sensors in ESPHome, use ``bitmask``:
binary_sensor:
- platform: modbus_controller
modbus_controller_id: ventilation_system
modbus_controller_id: modbus1
name: Alarm bit0
entity_category: diagnostic
device_class: problem
register_type: read
address: 15
bitmask: 0x1
- platform: modbus_controller
modbus_controller_id: ventilation_system
modbus_controller_id: modbus1
name: Alarm bit1
entity_category: diagnostic
device_class: problem
register_type: read
address: 15
bitmask: 0x2
- platform: modbus_controller
modbus_controller_id: ventilation_system
modbus_controller_id: modbus1
name: Alarm bit10
entity_category: diagnostic
device_class: problem
register_type: read
address: 15
bitmask: 0x400
- platform: modbus_controller
modbus_controller_id: ventilation_system
modbus_controller_id: modbus1
name: Alarm bit15
entity_category: diagnostic
device_class: problem
register_type: read
address: 15
bitmask: 0x8000
.. _modbus_custom_command:
Using ``custom_command``
------------------------
``custom_command`` can be used to create an arbitrary modbus command. Combined with a lambda any response can be handled.
This example re-implements the command to read the registers 0x156 (Total active energy) and 0x158 Total (reactive energy) from a SDM-120.
SDM-120 returns the values as floats using 32 bits in 2 registers.
.. code-block:: yaml
uart:
id: mod_uart
...
modbus:
send_wait_time: 200ms
uart_id: mod_uart
id: mod_bus
modbus_controller:
- id: sdm
address: 2
modbus_id: mod_bus
command_throttle: 100ms
setup_priority: -10
update_interval: 30s
sensors:
- platform: modbus_controller
modbus_controller_id: sdm
name: "Total active energy"
id: total_energy
# address: 0x156
# register_type: "read"
## reimplement using custom_command
# 0x2 : modbus device address
# 0x4 : modbus function code
# 0x1 : high byte of modbus register address
# 0x56: low byte of modbus register address
# 0x00: high byte of total number of registers requested
# 0x02: low byte of total number of registers requested
custom_command: [ 0x2, 0x4, 0x1, 0x56,0x00, 0x02]
value_type: FP32
unit_of_measurement: kWh
accuracy_decimals: 1
- platform: modbus_controller
modbus_controller_id: sdm
name: "Total reactive energy"
# address: 0x158
# register_type: "read"
custom_command: [0x2, 0x4, 0x1, 0x58, 0x00, 0x02]
## the command returns an float value using 4 bytes
lambda: |-
ESP_LOGD("Modbus Sensor Lambda","Got new data" );
union {
float float_value;
uint32_t raw;
} raw_to_float;
if (data.size() < 4 ) {
ESP_LOGE("Modbus Sensor Lambda", "invalid data size %d",data.size());
return NAN;
}
raw_to_float.raw = data[0] << 24 | data[1] << 16 | data[2] << 8 | data[3];
ESP_LOGD("Modbus Sensor Lambda", "FP32 = 0x%08X => %f", raw_to_float.raw, raw_to_float.float_value);
return raw_to_float.float_value;
unit_of_measurement: kVArh
accuracy_decimals: 1
.. _modbus_register_count:
Optimizing modbus communications
--------------------------------
``register_count`` is an option only required for uncommon response encodings or to optimizie modbus communications.
It describes the number of registers this data point spans, overriding the defaults determined by ``value_type``. If no value for ``register_count`` is provided, it is calculated based on the register type. The default size for one register is 16 bits (one word). Some devices are not adhering to this convention and have registers larger than 16 bits. In this case, ``register_count`` and ``response_size`` must be set. For example, if your Modbus device uses one register for a FP32 value (instead of the default of two), set ``register_count: 1`` and ``response_size: 4``.
``register_count`` can also be used to skip a number of registers in consecutive range.
An example is an SDM meter, with interesting data in register addresses 0, 2, 4 and 6:
.. code-block:: yaml
- platform: modbus_controller
name: "Voltage Phase 1"
address: 0
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Voltage Phase 2"
address: 2
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Voltage Phase 3"
address: 4
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Current Phase 1"
address: 6
register_type: "read"
value_type: FP32
accuracy_decimals: 1
The configuration above will generate *one* modbus command *read multiple registers from 0 to 6*.
Maybe you don’t care about the data in register addresses 2 and 4, which are voltage values for Phase 2 and Phase 3 (or you have a SDM-120).
Of course, you can delete the sensors your don’t care about, but then you'd have a gap in the addresses. If you remove the registers at address 2 and 4, *two* commands will be generated -- *read register 0* and *read register 6*. To avoid generating multiple commands and thus reduce activity on the bus, ``register_count`` can be used to fill the gaps:
.. code-block:: yaml
- platform: modbus_controller
name: "Voltage Phase 1"
address: 0
unit_of_measurement: "V"
register_type: "read"
value_type: FP32
register_count: 6
- platform: modbus_controller
name: "Current Phase 1"
address: 6
register_type: "read"
value_type: FP32
Because the option ``register_count: 6`` is used for the first sensor, *one* command *read multiple registers from 0 to 6* will be used but the values in between will be ignored.
.. note:: *Calculation:* FP32 is a 32 bit value and uses 2 registers. Therefore, to skip the 2 FP32 registers the size of these 2 registers must be added to the default size for the first register. So we have 2 for address 0, 2 for address 2 and 2 for address 4 thus ``register_count`` must be 6.
Protocol decoding example
-------------------------
@ -214,87 +340,87 @@ Protocol decoding example
.. code-block:: yaml
sensors:
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_voltage
name: "array_rated_voltage"
address: 0x3000
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
skip_updates: 60
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_voltage
name: "array_rated_voltage"
address: 0x3000
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
skip_updates: 60
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_current
name: "array_rated_current"
address: 0x3001
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 2
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_current
name: "array_rated_current"
address: 0x3001
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 2
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_power
name: "array_rated_power"
address: 0x3002
unit_of_measurement: "W"
register_type: read
value_type: U_DWORD_R
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: array_rated_power
name: "array_rated_power"
address: 0x3002
unit_of_measurement: "W"
register_type: read
value_type: U_DWORD_R
accuracy_decimals: 1
filters:
- multiply: 0.01
-platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_voltage
name: "battery_rated_voltage"
address: 0x3004
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_voltage
name: "battery_rated_voltage"
address: 0x3004
unit_of_measurement: "V"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_current
name: "battery_rated_current"
address: 0x3005
unit_of_measurement: "A"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_current
name: "battery_rated_current"
address: 0x3005
unit_of_measurement: "A"
register_type: read
value_type: U_WORD
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_power
name: "battery_rated_power"
address: 0x3006
unit_of_measurement: "W"
register_type: read
value_type: U_DWORD_R
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever
id: battery_rated_power
name: "battery_rated_power"
address: 0x3006
unit_of_measurement: "W"
register_type: read
value_type: U_DWORD_R
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: epever id: charging_mode
name: "charging_mode"
address: 0x3008
unit_of_measurement: ""
register_type: read
value_type: U_WORD
accuracy_decimals: 0
- platform: modbus_controller
modbus_controller_id: epever id: charging_mode
name: "charging_mode"
address: 0x3008
unit_of_measurement: ""
register_type: read
value_type: U_WORD
accuracy_decimals: 0
To minimize the required transactions all registers with the same base address are read in one request.
@ -379,8 +505,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
.. note::
Write support is only implemented for switches and selects.
However the C++ code provides the required API to write to a ModBUS device.
Write support is only implemented for switches and selects; however, the C++ code provides the required API to write to a Modbus device.
These methods can be called from a lambda.
@ -413,7 +538,7 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
// create the payload
std::vector<uint16_t> rtc_data = {uint16_t((minutes << 8) | seconds), uint16_t((day << 8) | hour),
uint16_t((year << 8) | month)};
// Create a ModBUS command item with the time information as the payload
// Create a Modbus command item with the time information as the payload
esphome::modbus_controller::ModbusCommandItem set_rtc_command =
esphome::modbus_controller::ModbusCommandItem::create_write_multiple_command(controller, 0x9013, 3, rtc_data);
// Submit the command to the send queue
@ -517,17 +642,20 @@ The response is mapped to the sensor based on ``register_count`` and offset in b
filters:
- multiply: 0.01
.. _modbusseealso:
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/output/modbus_controller`
- `ModBUS RTU Protocol Description <https://www.modbustools.com/modbus.html>`__
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- `Modbus RTU Protocol Description <https://www.modbustools.com/modbus.html>`__
- `EPEVER MPPT Solar Charge Controller (Tracer-AN Series) <https://devices.esphome.io/devices/epever_mptt_tracer_an>`__
- `Genvex, Nibe, Alpha-Innotec heat recovery ventilation <https://devices.esphome.io/devices/Genvex-Nibe-AlphaInnotec-heat-recovery-ventilation>`__
- :ghedit:`Edit`

2
components/number/index.rst
View File

@ -55,7 +55,7 @@ Configuration variables:
for a list of available options. Requires Home Assistant Core 2021.12 or newer.
Defaults to ``"auto"``.
- **device_class** (*Optional*, string): The device class for the number.
See https://developers.home-assistant.io/docs/core/entity/number/#available-device-classes
See https://www.home-assistant.io/integrations/number/#device-class
for a list of available options.
Automations:

47
components/number/modbus_controller.rst
View File

@ -12,8 +12,8 @@ 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 mod_bus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first)
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **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):
- ``U_WORD`` (unsigned 16 bit integer from 1 register = 16bit)
- ``S_WORD`` (signed 16 bit integer from 1 register = 16bit)
@ -28,14 +28,16 @@ Configuration variables:
- ``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)
- **skip_updates** (*Optional*, int): By default all sensors of a modbus_controller are updated together. For data points that don't change very frequently updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle
Note: The modbus_controller groups component by address ranges to reduce number of transactions. All components with the same address will be updated in one request. skip_updates applies for all components in the same range.
- **response_size** (*Optional*): Size of the response for the register in bytes. Defaults to register_count*2.
- **force_new_range** (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting ``force_new_range: true`` enforces the start of a new range at that address.
- **offset** (*Optional*, int): only required for uncommon response encodings offset from start address in bytes. If more than one register is read a modbus read registers command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type
- **min_value** (*Optional*, float): The minimum value this number can be.
- **max_value** (*Optional*, float): The maximum value this number can be.
- **step** (*Optional*, float): The granularity with which the number can be set. Defaults to 1
- **step** (*Optional*, float): The granularity with which the number can be set. Defaults to 1.
- **multiply** (*Optional*, float): multiply the new value with this factor before sending the requests. Ignored if lambda is defined.
- **use_write_multiple** (*Optional*, boolean): By default the modbus command *Function Code 6 (Preset Single Registers)* is used for setting the holding register if only one register is set. If your device only supports *Function Code 16 (Preset Multiple Registers)* set this option to ``true``.
- **skip_updates** (*Optional*, int): By default, all sensors of a modbus_controller are updated together. For data points that don't change very frequently, updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle. Note: The modbus_controller groups components by address ranges to reduce number of transactions. All components with the same starting address will be updated in one request. ``skip_updates`` applies for *all* components in the same range.
- **register_count** (*Optional*, int): The number of consecutive registers this read request should span or skip in a single command. Default is 1. See :ref:`modbus_register_count` for more details.
- **response_size** (*Optional*): Size of the response for the register in bytes. Defaults to register_count*2.
- **force_new_range** (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting ``force_new_range: true`` enforces the start of a new range at that address.
- **offset** (*Optional*, int): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type.
- **custom_command** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_command`` is used ``address`` and ``register_type`` can't be used.
custom data must contain all required bytes including the modbus device address. The crc is automatically calculated and appended to the command.
See :ref:`modbus_custom_command` how to use ``custom_command``
@ -71,19 +73,24 @@ Configuration variables:
- ``return <anything>; and fill payload with data`` if the payload is added from the lambda then these 16 bit words will be sent
- ``return {};`` if you don't want write the command to the device (or do it from the lambda).
- **multiply** (*Optional*, float): multiply the new value with this factor before sending the requests. Ignored if lambda is defined.
- **use_write_multiple** (*Optional*, boolean): By default the modbus command ``Preset Single Registers`` (function code 6) is used for setting the holding register if only 1 register is set. If your device only supports ``Preset Multiple Registers`` (function code 16) set this option to true.
- All other options from :ref:`Number <config-number>`.
All other options from :ref:`Number <config-number>`.
**Example**
Example:
--------
.. code-block:: yaml
number:
- platform: modbus_controller
modbus_controller_id: epever
modbus_controller_id: modbus1
id: battery_capacity_number
name: "Battery Cap Number"
address: 0x9001
value_type: U_WORD
multiply: 1.0
- platform: modbus_controller
modbus_controller_id: modbus1
id: battery_capacity_number
name: "Battery Cap Number"
address: 0x9001
@ -94,17 +101,17 @@ All other options from :ref:`Number <config-number>`.
uint16_t b_capacity = x ;
payload.push_back(b_capacity);
return x * 1.0 ;
## multiply is ignored because lamdba is used
multiply: 1.0
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- https://www.modbustools.com/modbus.html
- :ghedit:`Edit`

63
components/output/modbus_controller.rst
View File

@ -2,17 +2,15 @@ Modbus Controller Output
========================
.. seo::
:description: Instructions for setting up a modbus_controller device sensor.
:description: Instructions for setting up a modbus_controller device output.
The ``modbus_controller`` platform creates a output from a modbus_controller.
The ``modbus_controller`` platform creates an output from a modbus_controller. The goal is to write a value to a modbus register on a device.
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**): data type of the modbus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first)
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **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)
@ -27,14 +25,19 @@ Configuration variables:
- ``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)
- **register_type** (*Optional*):
- ``coil``: Write Coil - Write the ON/OFF status of a discrete coil in the device with *Function Code 5 or 15*. This will create a binary output.
- ``holding``: Write Holding Registers - write contents of holding registers in the device with *Function Code 6 or 16*. This will create a float output.
- **multiply** (*Optional*, float): multiply the incoming value with this factor before writing it to the device. Ignored if ``write_lambda`` is defined. Only valid for ``register_type: holding``.
- **use_write_multiple** (*Optional*, boolean): By default the modbus command *Function Code 6 (Preset Single Registers)* is used for setting the holding register if only one register is set. If your device only supports *Function Code 16 (Preset Multiple Registers)* set this option to ``true``.
- **write_lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda is evaluated before the modbus write command is created. The value is passed in as ``float x`` and an empty vector is passed in as ``std::vector<uint16_t>&payload``.
You can directly define the payload by adding data to payload then the return value is ignored and the content of payload is used.
Parameters passed into the lambda
- **x** (float): The float value to be sent to the modbus device for ``register_type: holding``
- **x** (bool): The boolean value to be sent to the modbus device for ``register_type: coil``
- **x** (float or bool): The float value to be sent to the modbus device for ``register_type: holding`` or the boolean value to be sent to the modbus device for ``register_type: coil``
- **payload** (```std::vector<uint16_t>&payload```):
- for ``register_type: holding``: empty vector for the payload. The lamdba can add 16 bit raw modbus register words.
@ -49,41 +52,51 @@ Configuration variables:
- ``return <anything>; and fill payload with data`` if the payload is added from the lambda then these 16 bit words will be sent
- ``return {};`` if you don't want write the command to the device (or do it from the lambda).
- **register_type** (*Optional*): ``coil`` to create a binary outout or ``holding`` to create a float output.
- **multiply** (*Optional*, float): multiply the new value with this factor before sending the requests. Ignored if lambda is defined. Only valid for ``register_type: holding``.
- **offset** (*Optional*, int): only required for uncommon response encodings
offset from start address in bytes. If more than one register is read a modbus read registers command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type
- **use_write_multiple** (*Optional*, boolean): By default the modbus command ``Preset Single Registers`` (function code 6) is used for setting the holding register if only 1 register is set. If your device only supports ``Preset Multiple Registers`` (function code 16) set this option to true.
- **offset** (*Optional*, int): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
All other options from :ref:`Output <config-output>`.
**Example**
Example:
--------
.. code-block:: yaml
output:
- platform: modbus_controller
modbus_controller_id: epever
id: battery_capacity_output
write_lambda: |-
ESP_LOGD("main","Modbus Output incoming value = %f",x);
uint16_t b_capacity = x ;
payload.push_back(b_capacity);
return x * 1.0 ;
address: 0x9001
value_type: U_WORD
- platform: modbus_controller
modbus_controller_id: modbus1
address: 2048
register_type: holding
value_type: U_WORD
multiply: 1000
**The same with lambda:**
.. code-block:: yaml
output:
- platform: modbus_controller
modbus_controller_id: modbus1
address: 2048
value_type: U_WORD
write_lambda: |-
ESP_LOGD("main","Modbus Output incoming value = %f",x);
uint16_t value = x ;
payload.push_back(value);
return x * 1000 ;
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- https://www.modbustools.com/modbus.html
- :ghedit:`Edit`

2
components/power_supply.rst
View File

@ -33,7 +33,7 @@ Configuration variables:
- **enable_time** (*Optional*, :ref:`config-time`): The time
that the power supply needs for startup. The output component will
wait for this period of time after turning on the PSU and before
switching the output on. Defaults to ``20ms``.
switching the output on. Defaults to ``20ms``. Maximum of less than ``5s``.
- **keep_on_time** (*Optional*, :ref:`config-time`): The time the
power supply should be kept enabled after the last output that used
it has been switch off. Defaults to ``10s``.

55
components/select/modbus_controller.rst
View File

@ -7,27 +7,12 @@ Modbus Controller Select
The ``modbus_controller`` Select platform allows you to create a Select from modbus
registers.
.. code-block:: yaml
# Example configuration entry
select:
- platform: modbus_controller
name: "Modbus Select Register 1000"
address: 1000
value_type: U_WORD
optionsmap:
"Zero": 0
"One": 1
"Two": 2
"Three": 3
Configuration variables:
------------------------
- **name** (**Required**, string): The name of the Select.
- **address** (**Required**, int): The start address of the first or only register
of the Select.
of the Select (can be decimal or hexadecimal).
- **optionsmap** (**Required**, Map[str, int]): Provide a mapping from options (str) of
this Select to values (int) of the modbus register and vice versa. All options and
all values have to be unique.
@ -48,11 +33,8 @@ Configuration variables:
required for uncommon response encodings or to
:ref:`optimize modbus communications<modbus_register_count>`. Overrides the defaults determined
by ``value_type``.
- **skip_updates** (*Optional*, int): By default all sensors of a modbus_controller are
updated together. For data points that don't change very frequently updates can be skipped. A
value of 5 would only update this sensor range in every 5th update cycle. Defaults to ``0``.
Note: The modbus_controller merges several registers into groups which are updated together. For
each group the smallest update cycle is used.
- **skip_updates** (*Optional*, int): By default, all sensors of a modbus_controller are updated together. For data points that don't change very frequently, updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle. Note: The modbus_controller groups components by address ranges to reduce number of transactions. All components with the same starting address will be updated in one request. ``skip_updates`` applies for *all* components in the same range.
- **register_count** (*Optional*, int): The number of consecutive registers this read request should span or skip in a single command. Default is 1. See :ref:`modbus_register_count` for more details.
- **force_new_range** (*Optional*, boolean): If possible sensors with sequential addresses are
grouped together and requested in one range. Setting this to ``true`` enforces the start of a new
range at that address.
@ -75,17 +57,13 @@ Configuration variables:
- **write_lambda** (*Optional*, :ref:`lambda <config-lambda>`): Lambda to be evaluated on every update
of the Sensor, before the new value is written to the modbus registers.
- **use_write_multiple** (*Optional*, boolean): By default the modbus command ``Preset Single Registers``
(function code 6) is used for setting the holding register if only 1 register is set. If your device only supports *Preset Multiple Registers* (function code 16) set this option to ``true``. Defaults
to ``false``.
- **use_write_multiple** (*Optional*, boolean): By default the modbus command *Function Code 6 (Preset Single Registers)*
is used for setting the holding register if only one register is set. If your device only supports *Function Code 16 (Preset Multiple Registers)* set this option to ``true``.
- **optimistic** (*Optional*, boolean): Whether to operate in optimistic mode - when in this mode,
any command sent to the Modbus Select will immediately update the reported state. Defaults
to ``false``.
- All other options from :ref:`Select <config-select>`.
.. code-block:: yaml
# example
@ -136,15 +114,34 @@ Possible return values for the lambda:
// ignore update
return {};
Example:
--------
.. code-block:: yaml
# Example configuration entry
select:
- platform: modbus_controller
name: "Modbus Select Register 1000"
address: 1000
value_type: U_WORD
optionsmap:
"Zero": 0
"One": 1
"Two": 2
"Three": 3
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :ref:`automation`
- https://www.modbustools.com/modbus.html
- :ghedit:`Edit`

2
components/sensor/index.rst
View File

@ -50,7 +50,7 @@ Configuration variables:
of measurement the sensor should advertise its values with. This does
not actually do any maths (conversion between units).
- **device_class** (*Optional*, string): The device class for the
sensor. See https://developers.home-assistant.io/docs/core/entity/sensor/#available-device-classes
sensor. See https://www.home-assistant.io/integrations/sensor/#device-class
for a list of available options. Set to ``""`` to remove the default device class of a sensor.
- **state_class** (*Optional*, string): The state class for the
sensor. See https://developers.home-assistant.io/docs/core/entity/sensor/#available-state-classes

14
components/sensor/mcp3008.rst
View File

@ -27,12 +27,13 @@ It uses the :ref:`SPI Bus <spi>` for communication.
Once configured, you can use any of the 8 pins as
sensors for your projects.
Each pin will respond with a voltage calculated off of the reference_voltage (default is 3.3v).
It calculates the voltage by multiplying the reference_voltage * value on the pin (basically the percentage of VREF)
Most configurations will set the reference_voltage = VREF (pin 13 on the chip)
Each pin will respond with a voltage calculated off of the ``reference_voltage`` (default is 3.3V).
It calculates the voltage by multiplying the ``reference_voltage`` by the value on the pin (basically the percentage of VREF).
If you want just the scaled value you can use the read_data function
Most configurations will establish the reference voltage by assigning it the value of VREF, which is located at pin 13 on the chip.
If you want just the scaled value you can use the read_data function:
``float MCP3008::read_data(uint8_t pin)``
.. code-block:: yaml
@ -68,8 +69,9 @@ If you want just the scaled value you can use the read_data function
name: Freezer Temperature
Configuration variables:
- **id** (**Required**, :ref:`config-id`): The id to use for this MCP3008 component.
- **cs_pin** (**Required**, int): The SPI cable select pin to use
- **cs_pin** (**Required**, int): The SPI cable select pin to use.
Sensor
@ -82,7 +84,7 @@ sensor platform to create individual sensors that will report the voltage to Hom
Configuration variables:
- **mcp3008_id** (**Required**, :ref:`config-id`): The id of the parent MCP3008 component.
- **number** (**Required**, int): The pin number of the MCP3008
- **number** (**Required**, int): The pin number of the MCP3008.
- **reference_voltage** (*Optional*, float): The reference voltage. Defaults to ``3.3V``.
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the sensor. Defaults to ``1s``.

205
components/sensor/modbus_controller.rst
View File

@ -15,13 +15,13 @@ Configuration variables:
- **name** (**Required**, string): The name of the sensor.
- **register_type** (**Required**): type of the modbus register.
- ``coil``: coils are also called discrete output. Coils are 1-bit registers (on/off values) that are used to control discrete outputs. Read and Write access. Modbus function code 1 (Read Coil Status) will be used
- ``discrete_input``: discrete input register (read only coil) are similar to coils but can only be read. Modbus function code 2 (Read Input Status) will be used.
- ``holding``: Holding Registers - Holding registers are the most universal 16-bit register. Read and Write access. Modbus function code 3 (Read Holding Registers) will be used.
- ``read``: Read Input Registers - registers are 16-bit registers used for input, and may only be read. Modbus function code 4 (Read Input Registers) will be used.
- ``coil``: Coils are 1-bit registers (ON/OFF values) that are used to control discrete outputs. They may be read and/or written. Modbus *Function Code 1 (Read Coil Status)* will be used.
- ``discrete_input``: discrete input register (read only coil) are similar to coils but can only be read. Modbus *Function Code 2 (Read Input Status)* will be used.
- ``holding``: Holding Registers - Holding registers are the most universal 16-bit register. They may be read and/or written. Modbus *Function Code 3 (Read Holding Registers)* will be used.
- ``read``: Read Input Registers - registers are 16-bit registers used for input, and may only be read. Modbus *Function Code 4 (Read Input Registers)* will be used.
- **address** (**Required**, int): start address of the first register in a range
- **value_type** (**Required**): datatype of the mod_bus register data. The default data type for modbus is a 16 bit integer in big endian format (MSB first)
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **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
@ -36,19 +36,11 @@ Configuration variables:
- ``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
- **bitmask** (*Optional*, int): some values are packed in a response. The bitmask can be used to extract a value from the response. For example, if the high byte value register 0x9013 contains the minute value of the current time. To only exctract this value use bitmask: 0xFF00. The result will be automatically right shifted by the number of 0 before the first 1 in the bitmask. For 0xFF00 (0b1111111100000000) the result is shifted 8 posistions. More than one sensor can use the same address/offset if the bitmask is different.
- **skip_updates** (*Optional*, int): By default all sensors of a modbus_controller are updated together. For data points that don't change very frequently updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle
Note: The modbus_controller groups component by address ranges to reduce number of transactions. All compoents with the same address will be updated in one request. skip_updates applies for all components in the same range.
- **register_count** (*Optional*): only required for uncommon response encodings or to :ref:`optimize modbus communications<modbus_register_count>`
The number of registers this data point spans. Overrides the defaults determined by ``value_type``.
If no value for ``register_count`` is provided, it is calculated based on the register type.
The default size for 1 register is 16 bits (1 Word). Some devices are not adhering to this convention and have registers larger than 16 bits. In this case ``register_count`` and ``response_size`` must be set. For example, if your modbus device uses 1 registers for a FP32 value instead the default of two set ``register_count: 1`` and ``response_size: 4``.
- **bitmask** (*Optional*, int): sometimes multiple values are packed in a single register's response. The bitmask can be used to extract a value from the response. See :ref:`bitmasks`.
- **skip_updates** (*Optional*, int): By default, all sensors of a modbus_controller are updated together. For data points that don't change very frequently, updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle. Note: The modbus_controller groups components by address ranges to reduce number of transactions. All components with the same starting address will be updated in one request. ``skip_updates`` applies for *all* components in the same range.
- **register_count** (*Optional*, int): The number of consecutive registers this read request should span or skip in a single command. Default is 1. See :ref:`modbus_register_count` for more details.
- **response_size** (*Optional*, int): Size of the response for the register in bytes. Defaults to register_count*2.
- **force_new_range** (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting ``force_new_range: true`` enforces the start of a new range at that address.
- **custom_command** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_command`` is used ``address`` and ``register_type`` can't be used.
custom data must contain all required bytes including the modbus device address. The crc is automatically calculated and appended to the command.
See :ref:`modbus_custom_command` how to use ``custom_command``
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda to be evaluated every update interval to get the new value of the sensor.
@ -64,23 +56,26 @@ Configuration variables:
- ``return <FLOATING_POINT_NUMBER>;`` the new value for the sensor.
- ``return NAN;`` if the state should be considered invalid to indicate an error (advanced).
- **offset** (*Optional*, int): only required for uncommon response encodings
offset from start address in bytes. If more than one register is read a modbus read registers command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type
For coil or discrete input registers offset is the position of the coil/register because these registers encode 8 coils in one byte.
- **custom_command** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_command`` is used ``address`` and ``register_type`` can't be used.
Custom data must contain all required bytes including the modbus device address. The CRC is automatically calculated and appended to the command.
See :ref:`modbus_custom_command` how to use ``custom_command``
- **offset** (*Optional*, int): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type. For ``coil`` or ``discrete_input`` registers offset is the position of the coil/register because these registers encode 8 coils in one byte.
- All other options from :ref:`Sensor <config-sensor>`.
Examples
--------
This example will send 2 modbus commands (device address 1 assumed)
The example below will send 2 modbus commands (device address 1 assumed):
0x1 0x4 0x31 0x0 0x0 0x02 x7f 0x37 ( read 2 registers starting at 0x3100)
``0x1 0x4 0x31 0x0 0x0 0x02 x7f 0x37`` (read 2 registers starting at 0x3100)
0x1 0x3 0x90 0x1 0x0 0x1 0xf8 0xca ( read 1 holding resister from 0x9001 )
``0x1 0x3 0x90 0x1 0x0 0x1 0xf8 0xca`` (read 1 holding resister from 0x9001)
.. code-block:: yaml
- platform: modbus_controller
modbus_controller_id: traceran
modbus_controller_id: modbus1
id: pv_input_voltage
name: "PV array input voltage"
address: 0x3100
@ -92,19 +87,7 @@ This example will send 2 modbus commands (device address 1 assumed)
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: traceran
id: pv_input_current
name: "PV array input current"
address: 0x3101
unit_of_measurement: "A" ## for any other unit the value is returned in minutes
register_type: read
value_type: U_WORD
accuracy_decimals: 2
filters:
- multiply: 0.01
- platform: modbus_controller
modbus_controller_id: traceran
modbus_controller_id: modbus1
name: "Battery Capacity"
id: battery_capacity
register_type: holding
@ -116,20 +99,20 @@ This example will send 2 modbus commands (device address 1 assumed)
The ``modbus`` sensor platform allows you use a lambda that gets called before data is published
using :ref:`lambdas <config-lambda>`.
This example logs the value as parsed and the raw modbus bytes received for this register range
The example below logs the value as parsed and the raw modbus bytes received for this register range:
.. code-block:: yaml
# Example configuration entry
sensor:
- platform: modbus_controller
modbus_controller_id: epever
id: battery_capacity
address: 0x9001
name: "Battery Capacity"
register_type: holding
value_type: U_WORD
lambda: |-
modbus_controller_id: modbus1
id: battery_capacity
address: 0x9001
name: "Battery Capacity"
register_type: holding
value_type: U_WORD
lambda: |-
ESP_LOGI("","Lambda incoming value=%f - data array size is %d",x,data.size());
ESP_LOGI("","Sensor properties: adress = 0x%X, offset = 0x%X value type=%d",item->start_address,item->offset,item->sensor_value_type);
int i=0 ;
@ -139,137 +122,15 @@ This example logs the value as parsed and the raw modbus bytes received for this
}
return x ;
.. _modbus_custom_command:
Using ``custom_command``
------------------------
``custom_command`` can be used to create an arbitrary modbus command. Combined with a lambda any response can be handled.
This example re-implements the command to read the registers 0x156 (Total active energy) and 0x158 Total (reactive energy) from a SDM-120.
SDM-120 returns the values as floats using 32 bits in 2 registers.
.. code-block:: yaml
modbus:
send_wait_time: 200ms
uart_id: mod_uart
id: mod_bus
modbus_controller:
- id: sdm
address: 2
modbus_id: mod_bus
command_throttle: 100ms
setup_priority: -10
update_interval: 30s
sensors:
- platform: modbus_controller
modbus_controller_id: sdm
name: "Total active energy"
id: total_energy
# address: 0x156
# register_type: "read"
## reimplement using custom_command
# 0x2 : modbus device address
# 0x4 : modbus function code
# 0x1 : high byte of modbus register address
# 0x56: low byte of modbus register address
# 0x00: high byte of total number of registers requested
# 0x02: low byte of total number of registers requested
custom_command: [ 0x2, 0x4, 0x1, 0x56,0x00, 0x02]
value_type: FP32
unit_of_measurement: kWh
accuracy_decimals: 1
- platform: modbus_controller
modbus_controller_id: sdm
name: "Total reactive energy"
# address: 0x158
# register_type: "read"
custom_command: [0x2, 0x4, 0x1, 0x58, 0x00, 0x02]
## the command returns an float value using 4 bytes
lambda: |-
ESP_LOGD("Modbus Sensor Lambda","Got new data" );
union {
float float_value;
uint32_t raw;
} raw_to_float;
if (data.size() < 4 ) {
ESP_LOGE("Modbus Sensor Lambda", "invalid data size %d",data.size());
return NAN;
}
raw_to_float.raw = data[0] << 24 | data[1] << 16 | data[2] << 8 | data[3];
ESP_LOGD("Modbus Sensor Lambda", "FP32 = 0x%08X => %f", raw_to_float.raw, raw_to_float.float_value);
return raw_to_float.float_value;
unit_of_measurement: kVArh
accuracy_decimals: 1
.. _modbus_register_count:
.. note:: **Optimize modbus communications**
``register_count`` can also be used to skip a register in consecutive range.
An example is a SDM meter:
.. code-block:: yaml
- platform: modbus_controller
name: "Voltage Phase 1"
address: 0
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Voltage Phase 2"
address: 2
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Voltage Phase 3"
address: 4
register_type: "read"
value_type: FP32
- platform: modbus_controller
name: "Current Phase 1"
address: 6
register_type: "read"
value_type: FP32
accuracy_decimals: 1
Maybe you don’t care about the Voltage value for Phase 2 and Phase 3 (or you have a SDM-120).
Of course, you can delete the sensors your don’t care about. But then you have a gap in the addresses. The configuration above will generate one modbus command `read multiple registers from 0 to 6`. If you remove the registers at address 2 and 4 then 2 commands will be generated `read register 0` and `read register 6`.
To avoid the generation of multiple commands and reduce the amount of uart communication ``register_count`` can be used to fill the gaps
.. code-block:: yaml
- platform: modbus_controller
name: "Voltage Phase 1"
address: 0
unit_of_measurement: "V"
register_type: "read"
value_type: FP32
register_count: 6
- platform: modbus_controller
name: "Current Phase 1"
address: 6
register_type: "read"
value_type: FP32
Because `register_count: 6` is used for the first register the command “read registers from 0 to 6” can still be used but the values in between are ignored.
**Calculation:** FP32 is a 32 bit value and uses 2 registers. Therefore, to skip the 2 FP32 registers the size of these 2 registers must be added to the default size for the first register.
So we have 2 for address 0, 2 for address 2 and 2 for address 4 then ``register_count`` must be 6.
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- `EPEVER MPPT Solar Charge Controller (Tracer-AN Series) <https://devices.esphome.io/devices/epever_mptt_tracer_an>`__
- :ghedit:`Edit`

15
components/sensor/pm1006.rst
View File

@ -70,21 +70,6 @@ Example config:
update_interval: 20s
If you run the PM1006 (2.5µm) or PM1006K (1, 2.5, 10µm) independent from the original MCU you need to send a serial command in the first 5 seconds after power is applied to the sensor. Otherwise the sensor will switch to PWM mode and does not repond to UART requests. A possibility to do this in ESPhome is to use an automation. `Source <https://community.home-assistant.io/t/ikea-vindriktning-air-quality-sensor/324599/300>`_
Example config:
.. code-block:: yaml
# Example configuration entry
on_boot:
priority: 240
then:
- uart.write:
id: ikea #id of the uart bus used for the PM1006
data: [0x11, 0x02, 0x0B, 0x01, 0xE1]
See Also
--------

4
components/sensor/pulse_meter.rst
View File

@ -9,12 +9,14 @@ The pulse meter sensor allows you to count the number and frequency of pulses on
for the :doc:`pulse counter integration </components/sensor/pulse_counter>`.
Rather than counting pulses over a fixed time interval, the pulse meter sensor measures the time between pulses. The precise manner in which this is done depends on the ``internal_filter_mode`` option. This leads to a higher resolution, especially for low pulse rates, as the pulse counter sensor is limited by the number of pulses within a time interval.
Here's a comparison of the two sensors; both are set to an update interval of 10 seconds (using the ``update_interval`` and the ``throttle_average`` option respectively):
Here's a comparison of the two sensors. The pulse meter is the smoother line. Both are set to an update interval of 10 seconds (using the ``update_interval`` and the ``throttle_average`` option respectively):
.. figure:: /images/pulse-counter_vs_pulse-meter.png
:align: center
:width: 50.0%
Please note that it is not possible to use both of these two sensors on the same pin at the same time.
.. code-block:: yaml
# Example configuration entry

2
components/switch/index.rst
View File

@ -65,7 +65,7 @@ Configuration variables:
for a list of available options. Requires Home Assistant 2021.11 or newer.
Set to ``""`` to remove the default entity category.
- **device_class** (*Optional*, string): The device class for the switch.
See https://developers.home-assistant.io/docs/core/entity/switch/#available-device-classes
See https://www.home-assistant.io/integrations/switch/#device-class
for a list of available options. Requires Home Assistant 2022.3 or newer.
- If MQTT enabled, All other options from :ref:`MQTT Component <config-mqtt-component>`.

71
components/switch/modbus_controller.rst
View File

@ -13,21 +13,18 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **name** (**Required**, string): The name of the sensor.
- **restore_mode** (*Optional*): See :ref:`Switch <config-switch>`, since this configuration variable is inherited. The default value for this setting is ``DISABLED`` (recommended).
``DISABLED`` leaves the initial state up to the hardware: usually the state lives in the device and ESPHome does not need to remember it. The switch frontend will show an undetermined
state until the real state is retrieved from the device on the next refresh. Use any other setting if a reboot of your ESPHome device is tied to a reboot of the modbus device.
- **register_type** (**Required**): type of the modbus register.
- **address** (**Required**, int): start address of the first register in a range
- **offset** (*Optional*, int): not required in most cases
offset from start address in bytes. If more than one register is read a modbus read registers command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type
The value for offset depends on the register type. For holding input registers the offset is in bytes. For coil and discrete input resisters the LSB of the first data byte contains the coil addressed in the request. The other coils follow toward the high-order end of this byte and from low order to high order in subsequent bytes. For the registers offset is the position of the relevant bit.
To get the value of the coil register 2 can be retrieved using address: 2 / offset: 0 or address: 0 / offset 2
- **bitmask** (*Optional*, int): Some values are packed in a response. The bitmask is used to determined if the result is true or false.
- **skip_updates** (*Optional*, int): By default all sensors of a modbus_controller are updated together. For data points that don't change very frequently updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle
- **use_write_multiple** (*Optional*, boolean): By default the modbus command ``Force Single Coil`` (function code 5) is used to send state changes to the device. If your device only supports ``Force Multiple Coils`` (function code 15) set this option to true.
- **custom_command** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_command`` is used ``address`` and ``register_type`` can't be used.
custom data must contain all required bytes including the modbus device address. The crc is automatically calculated and appended to the command.
See :ref:`modbus_custom_command` how to use ``custom_command``
- ``coil``: Coils are 1-bit registers (on/off values) that are used to control discrete outputs. They may be read and/or written. Modbus *Function Code 1 (Read Coil Status)* will be used.
- ``discrete_input``: discrete input register (read only coil) are similar to coils but can only be read. Modbus *Function Code 2 (Read Input Status)* will be used.
- ``holding``: Holding Registers - Holding registers are the most universal 16-bit register. They may be read and/or written. Modbus *Function Code 3 (Read Holding Registers)* will be used.
- ``read``: Read Input Registers - registers are 16-bit registers used for input, and may only be read. Modbus *Function Code 4 (Read Input Registers)* will be used.
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **skip_updates** (*Optional*, int): By default, all sensors of a modbus_controller are updated together. For data points that don't change very frequently, updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle. Note: The modbus_controller groups components by address ranges to reduce number of transactions. All components with the same starting address will be updated in one request. ``skip_updates`` applies for *all* components in the same range.
- **register_count** (*Optional*, int): The number of consecutive registers this read request should span or skip in a single command. Default is 1. See :ref:`modbus_register_count` for more details.
- **use_write_multiple** (*Optional*, boolean): By default the modbus command *Function Code 6 (Preset Single Registers)* is used for setting the holding register if only one register is set. If your device only supports *Function Code 16 (Preset Multiple Registers)* set this option to ``true``.
- **bitmask** (*Optional*, int): Some values are packed in a response. The bitmask is used to determined if the result is true or false. See :ref:`bitmasks`.
- **lambda** (*Optional*, :ref:`lambda <config-lambda>`):
Lambda to be evaluated every update interval to read the status of the switch.
- **write_lambda** (*Optional*, :ref:`lambda <config-lambda>`): Lambda called before send.
@ -46,7 +43,29 @@ Configuration variables:
- ``return <anything>; and fill payload with data`` if the payload is added from the lambda then these bytes will be sent.
- ``return {};`` in the case the lambda handles the sending of the value itself.
**Example**
- **custom_command** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_command`` is used ``address`` and ``register_type`` can't be used.
Custom data must contain all required bytes including the modbus device address. The CRC is automatically calculated and appended to the command.
See :ref:`modbus_custom_command` how to use ``custom_command``
- **offset** (*Optional*, int): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a command, this value is used to find the start of this datapoint relative to the start address. The component calculates the size of the range based on offset and size of the value type. The value for offset depends on the register type. For holding input registers, the offset is in bytes. For coil and discrete input resisters, the LSB of the first data byte contains the coil addressed in the request. The other coils follow toward the high-order end of this byte and from low order to high order in subsequent bytes. For registers, the offset is the position of the relevant bit. To get the value of the coil register, 2 can be retrieved using ``address: 2`` / ``offset: 0`` or ``address: 0`` / ``offset 2``.
- **restore_mode** (*Optional*): See :ref:`Switch <config-switch>`, since this configuration variable is inherited. The default value for this setting is ``DISABLED`` (recommended).
``DISABLED`` leaves the initial state up to the hardware: usually the state lives in the device and ESPHome does not need to remember it. The switch frontend will show an undetermined
state until the real state is retrieved from the device on the next refresh. Use any other setting if a reboot of your ESPHome device is tied to a reboot of the modbus device.
Examples:
---------
.. code-block:: yaml
switch:
- platform: modbus_controller
modbus_controller_id: epever
id: enable_load_test
register_type: coil
address: 2
name: "enable load test mode"
bitmask: 1
.. code-block:: yaml
@ -69,26 +88,12 @@ Configuration variables:
return true;
**Example**
.. code-block:: yaml
switch:
- platform: modbus_controller
modbus_controller_id: epever
id: enable_load_test
register_type: coil
address: 2
name: "enable load test mode"
bitmask: 1
Since offset is not zero the read command is part of a range and will be parsed when the range is updated.
The write command to be constructed uses the function code to determine the write command. For a coil it is write single coil.
Because the write command only touches one register start_address and offset have to be corrected.
The final command will be write_single_coil address 5 (start_address+offset) value 1 or 0
The final command will be write_single_coil *Function Code 5* address (start_address+offset) value 1 or 0
For holding registers the write command will be write_single_register. Because the offset for holding registers is given in bytes and the size of a register is 16 bytes the start_address is calculated as ``start_address + offset/2``
For holding registers the write command will be write_single_register (*Function Code 6 (Preset Single Registers)*). Because the offset for holding registers is given in bytes and the size of a register is 16 bytes the start_address is calculated as ``start_address + offset/2``
.. code-block:: yaml
@ -105,9 +110,13 @@ For holding registers the write command will be write_single_register. Because t
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- https://www.modbustools.com/modbus.html
- :ghedit:`Edit`

28
components/text_sensor/modbus_controller.rst
View File

@ -14,16 +14,16 @@ Configuration variables:
- **name** (**Required**, string): The name of the sensor.
- **register_type** (**Required**): type of the modbus register.
- ``coil``: coils are also called discrete outout. Coils are 1-bit registers (on/off values) that are used to control discrete outputs. Read and Write access
- ``discrete_input``: discrete input register (read only coil) are similar to coils but can only be read.
- ``holding``: Holding Registers - Holding registers are the most universal 16-bit register. Read and Write access
- ``read``: Read Input Registers - registers are 16-bit registers used for input, and may only be read
- ``coil``: Coils are 1-bit registers (on/off values) that are used to control discrete outputs. They may be read and/or written. Modbus *Function Code 1 (Read Coil Status)* will be used.
- ``discrete_input``: discrete input register (read only coil) are similar to coils but can only be read. Modbus *Function Code 2 (Read Input Status)* will be used.
- ``holding``: Holding Registers - Holding registers are the most universal 16-bit register. They may be read and/or written. Modbus *Function Code 3 (Read Holding Registers)* will be used.
- ``read``: Read Input Registers - registers are 16-bit registers used for input, and may only be read. Modbus *Function Code 4 (Read Input Registers)* will be used.
- **address** (**Required**, int): start address of the first register in a range
- **address** (**Required**, int): start address of the first register in a range (can be decimal or hexadecimal).
- **skip_updates** (*Optional*, int): By default all sensors of a modbus_controller are updated together. For data points that don't change very frequently updates can be skipped. A value of 5 would only update this sensor range in every 5th update cycle
- **register_count** (*Optional*): The number of registers this data point spans. Default is 1
- **response_size** (**Required**): Number of bytes of the response
- **raw_encode** (*Optional*, enum): If the response is binary it can't be published directly. Since a text sensor only publishes strings the binary data can be encoded
- **register_count** (*Optional*, int): The number of consecutive registers this read request should span or skip in a single command. Default is 1. See :ref:`modbus_register_count` for more details.
- **response_size** (**Required**): Number of bytes of the response.
- **raw_encode** (*Optional*, enum): If the response is binary it can't be published directly. Since a text sensor only publishes strings the binary data can be encoded:
- ``NONE``: Don't encode data.
- ``HEXBYTES``: 2 byte hex string. 0x2011 will be sent as "2011".
@ -48,12 +48,11 @@ Configuration variables:
- ``return <std::string>;`` the new value for the sensor.
- ``return {};`` uses the parsed value for the state (same as ``return x;``).
- **offset** (*Optional*, int): not required in most cases
offset from start address in bytes. If more than one register is read a modbus read registers command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type
- **offset** (*Optional*, int): Offset from start address in bytes (only required for uncommon response encodings). If more than one register is written in a command this value is used to find the start of this datapoint relative to start address. The component calculates the size of the range based on offset and size of the value type. The value for offset depends on the register type.
- All options from :ref:`Text Sensor <config-text_sensor>`.
**Example**
Example:
--------
.. code-block:: yaml
@ -79,9 +78,14 @@ Configuration variables:
See Also
--------
- :doc:`/components/modbus`
- :doc:`/components/modbus_controller`
- :doc:`/components/sensor/modbus_controller`
- :doc:`/components/binary_sensor/modbus_controller`
- :doc:`/components/output/modbus_controller`
- :doc:`/components/switch/modbus_controller`
- :doc:`/components/number/modbus_controller`
- :doc:`/components/select/modbus_controller`
- :doc:`/components/text_sensor/modbus_controller`
- https://www.modbustools.com/modbus.html
- :ghedit:`Edit`

2
components/touchscreen/index.rst
View File

@ -56,7 +56,7 @@ Configuration variables:
- **mirror_x** (*Optional*, boolean): If true, mirror the x axis.
- **mirror_y** (*Optional*, boolean): If true, mirror the y axis.
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the touchscreen. Defaults to ``never``.
- **update_interval** (*Optional*, :ref:`config-time`): The interval to check the touchscreen. Defaults to ``never``. **NOTE:** You should set this to ``50ms`` when you dont have set the **interupt_pin**.
- **calibration** (*Optional*): When the touchscreen is not given the right configuration settings. You can set them here.
- **x_min** (*Optional*, int): The raw value corresponding to the left

2
cookbook/power_meter.rst
View File

@ -17,7 +17,7 @@ Hooking it all up is quite easy: Just buy a suitable photoresistor (make sure th
.. note::
Some energy meters have an exposed `S0 port <https://en.wikipedia.org/wiki/S_interface/>`__ (which essentially just is a switch that closes), if that is the case the photodiode can be replaced with the following connection.
Some energy meters have an exposed `S0 port <https://en.wikipedia.org/wiki/S_interface>`__ (which essentially just is a switch that closes), if that is the case the photodiode can be replaced with the following connection.
.. code-block::

41
guides/made_for_esphome.rst
View File

@ -7,23 +7,38 @@ Made for ESPHome
:description: Information about the Made for ESPHome program
:image: /_static/made-for-esphome-black-on-white.png
ESPHome has a great and active community that loves creating and sharing projects.
You can apply for your project to get the Made for ESPHome stamp of approval.
This ensures that your project is powered by ESPHome and guarantees a
minimum level of customizability to users.
ESPHome has a wonderful and active community that loves creating and sharing projects.
You can apply for your project to get the ``Made for ESPHome`` stamp of approval.
This ensures that your project is powered by ESPHome and guarantees a minimum level of customizability to users.
Requirements
------------
Your product has to match the following requirements:
- Your project is powered by ESPHome
- Your project is powered by an ESP32
- Your ESPHome configuration is open source
- Users should be able to apply updates if your project sells ready-made devices
- Your project supports adoption via the ``dashboard_import`` feature of ESPHome
(see :doc:`Sharing </guides/creators>`)
- Your product name cannot contain **ESPHome** except in the case of *ending with* **for ESPHome**
- Your configuration utilises ``esp32_improv`` and ``improv_serial`` (if a USB connection is available) for easy end-user provisioning.
There are a number of requirements your project must meet. These may vary based on its design. They are:
For projects which utilize Wi-Fi
********************************
Wi-Fi is quite common but requires configuration of the SSID and passphrase.
As such, for easy end-user provisioning, your configuration must include:
- ``esp32_improv`` as described in :doc:`/components/esp32_improv`
- ``improv_serial`` as described in :doc:`/components/improv_serial`, if a USB connection is available (recommended)
Note that these are **not** required for projects that only provide a physical/wired Ethernet port for connectivity.
For all projects
****************
- Your project is powered by ESPHome (runs ESPHome as its firmware)
- Your project is powered by an ESP32 or *supported* ESP32 variant such as the S2, S3, C3, etc.
- Your ESPHome configuration is open source, available for end users to modify/update
- Users should be able to apply updates if your project sells ready-made devices
- Your project supports adoption via the ``dashboard_import`` feature of ESPHome (see :doc:`Sharing </guides/creators>`). In particular:
- There are **no** references to secrets or passwords
- Network configuration must assume defaults (no static IPs or DNS configured)
- All configuration is contained within a single YAML file
- Your product name cannot contain **ESPHome** except in the case of *ending with* **for ESPHome**
When your project matches all requirements of the Made for ESPHome program,
you can apply for permission to carry the logo by emailing esphome@nabucasa.com

61
guides/supporters.rst
View File

@ -30,7 +30,7 @@ Contributors
- `Alessandro Campolo (@a13ssandr0) <https://github.com/a13ssandr0>`__
- `Aalian Khan (@AalianKhan) <https://github.com/AalianKhan>`__
- `Adam Liddell (@aaliddell) <https://github.com/aaliddell>`__
- `Aapeli Vuorinen (@aapeliv) <https://github.com/aapeliv>`__
- `Aapeli (@aapeliv) <https://github.com/aapeliv>`__
- `Aaron Gamble (@aarongamble) <https://github.com/aarongamble>`__
- `Aaron S. Jackson (@AaronJackson) <https://github.com/AaronJackson>`__
- `Abel Matser (@abelmatser) <https://github.com/abelmatser>`__
@ -73,7 +73,7 @@ Contributors
- `Alexandre Danault (@AlexDanault) <https://github.com/AlexDanault>`__
- `Alex Iribarren (@alexiri) <https://github.com/alexiri>`__
- `Alex Mekkering (@AlexMekkering) <https://github.com/AlexMekkering>`__
- `Alex (@alexyao2015) <https://github.com/alexyao2015>`__
- `Alex Yao (@alexyao2015) <https://github.com/alexyao2015>`__
- `Alfredo (@alfredopironti) <https://github.com/alfredopironti>`__
- `Alibloke (@Alibloke) <https://github.com/Alibloke>`__
- `Alessandro Ranellucci (@alranel) <https://github.com/alranel>`__
@ -94,12 +94,12 @@ Contributors
- `Andreas Hergert (@andreashergert1984) <https://github.com/andreashergert1984>`__
- `Andrew J.Swan (@andrewjswan) <https://github.com/andrewjswan>`__
- `andrewpc (@andrewpc) <https://github.com/andrewpc>`__
- `Andrey Yantsen (@andrey-yantsen) <https://github.com/andrey-yantsen>`__
- `Andrew Y. (@andrey-yantsen) <https://github.com/andrey-yantsen>`__
- `Andrzej (@andriej) <https://github.com/andriej>`__
- `Andreas (@anduchs) <https://github.com/anduchs>`__
- `Andy2No (@Andy2No) <https://github.com/Andy2No>`__
- `AndyRPH (@AndyRPH) <https://github.com/AndyRPH>`__
- `Vegetto (@angelnu) <https://github.com/angelnu>`__
- `Angel Nunez Mencias (@angelnu) <https://github.com/angelnu>`__
- `Sergey Anisimov (@anisimovsergey) <https://github.com/anisimovsergey>`__
- `Nikolay Vasilchuk (@Anonym-tsk) <https://github.com/Anonym-tsk>`__
- `Anthony Keane (@anthonykeane) <https://github.com/anthonykeane>`__
@ -129,13 +129,13 @@ Contributors
- `Alexander Turlov (@aturlov) <https://github.com/aturlov>`__
- `aus (@aus) <https://github.com/aus>`__
- `AustinMorris (@AustinMorris) <https://github.com/AustinMorris>`__
- `Avirsaam (@Avirsaam) <https://github.com/Avirsaam>`__
- `Denis Demchenko (@Avirsaam) <https://github.com/Avirsaam>`__
- `Arsène von Wyss (@avonwyss) <https://github.com/avonwyss>`__
- `Andrew Weddle (@aweddle2) <https://github.com/aweddle2>`__
- `Alexis Iglauer (@ax42) <https://github.com/ax42>`__
- `Achilleas Pipinellis (@axilleas) <https://github.com/axilleas>`__
- `Kamil Trzciński (@ayufan) <https://github.com/ayufan>`__
- `Nicholas Peters (@Azimath) <https://github.com/Azimath>`__
- `Azimath (@Azimath) <https://github.com/Azimath>`__
- `Daniel (@azrael783) <https://github.com/azrael783>`__
- `B48D81EFCC (@B48D81EFCC) <https://github.com/B48D81EFCC>`__
- `Florian Mösch (@badbadc0ffee) <https://github.com/badbadc0ffee>`__
@ -150,7 +150,7 @@ Contributors
- `Bascht74 (@Bascht74) <https://github.com/Bascht74>`__
- `Viktr (@BbIKTOP) <https://github.com/BbIKTOP>`__
- `J. Nick Koston (@bdraco) <https://github.com/bdraco>`__
- `Maxim Ocheretianko (@bearpawmaxim) <https://github.com/bearpawmaxim>`__
- `Maxym Ocheretianko (@bearpawmaxim) <https://github.com/bearpawmaxim>`__
- `beaudeanadams (@beaudeanadams) <https://github.com/beaudeanadams>`__
- `Benjamin Freeman (@Beetix) <https://github.com/Beetix>`__
- `beikeland (@beikeland) <https://github.com/beikeland>`__
@ -160,6 +160,7 @@ Contributors
- `Ben-Schwabe (@Ben-Schwabe) <https://github.com/Ben-Schwabe>`__
- `Benas09 (@Benas09) <https://github.com/Benas09>`__
- `Ben Hoff (@benhoff) <https://github.com/benhoff>`__
- `Benoît Leforestier (@Benichou34) <https://github.com/Benichou34>`__
- `Benjamin Aigner (@benjaminaigner) <https://github.com/benjaminaigner>`__
- `benniju (@benniju) <https://github.com/benniju>`__
- `Benno Pütz (@bennop) <https://github.com/bennop>`__
@ -174,7 +175,7 @@ Contributors
- `Bert Hertogen (@berthertogen) <https://github.com/berthertogen>`__
- `Brandon (@bgulla) <https://github.com/bgulla>`__
- `Benedikt Hübschen (@bhuebschen) <https://github.com/bhuebschen>`__
- `Bierchermuesli (@Bierchermuesli) <https://github.com/Bierchermuesli>`__
- `Stef (@Bierchermuesli) <https://github.com/Bierchermuesli>`__
- `bigwoof (@bigwoof) <https://github.com/bigwoof>`__
- `Bill Church (@billchurch) <https://github.com/billchurch>`__
- `Brian Kaufman (@bkaufx) <https://github.com/bkaufx>`__
@ -196,7 +197,7 @@ Contributors
- `Casey Olson (@bookcasey) <https://github.com/bookcasey>`__
- `Borja Burgos (@borjaburgos) <https://github.com/borjaburgos>`__
- `Brian Orpin (@borpin) <https://github.com/borpin>`__
- `BoukeHaarsma23 (@BoukeHaarsma23) <https://github.com/BoukeHaarsma23>`__
- `bouhaa (@BoukeHaarsma23) <https://github.com/BoukeHaarsma23>`__
- `brabl2 (@brabl2) <https://github.com/brabl2>`__
- `brainiac27 (@brainiac27) <https://github.com/brainiac27>`__
- `brambo123 (@brambo123) <https://github.com/brambo123>`__
@ -392,7 +393,7 @@ Contributors
- `dr-oblivium (@dr-oblivium) <https://github.com/dr-oblivium>`__
- `Jean Louis-Guerin (@DrCoolzic) <https://github.com/DrCoolzic>`__
- `Drew Perttula (@drewp) <https://github.com/drewp>`__
- `drmodding (@drmodding) <https://github.com/drmodding>`__
- `Angel G (@drmodding) <https://github.com/drmodding>`__
- `drmpf (@drmpf) <https://github.com/drmpf>`__
- `drogfild (@drogfild) <https://github.com/drogfild>`__
- `Simone Rossetto (@droscy) <https://github.com/droscy>`__
@ -403,7 +404,7 @@ Contributors
- `Tom Soer (@dtx3k) <https://github.com/dtx3k>`__
- `dubit0 (@dubit0) <https://github.com/dubit0>`__
- `Mikkel Jeppesen (@Duckle29) <https://github.com/Duckle29>`__
- `Sergey V. DUDANOV (@dudanov) <https://github.com/dudanov>`__
- `Sergey Dudanov (@dudanov) <https://github.com/dudanov>`__
- `David Girón (@duhow) <https://github.com/duhow>`__
- `Duncan Findlay (@duncf) <https://github.com/duncf>`__
- `David van der Leij (@dvanderleij) <https://github.com/dvanderleij>`__
@ -424,7 +425,7 @@ Contributors
- `Eli Fidler (@efidler) <https://github.com/efidler>`__
- `egandro (@egandro) <https://github.com/egandro>`__
- `Erwin Kooi (@egeltje) <https://github.com/egeltje>`__
- `Maxime Michel (@Egglestron) <https://github.com/Egglestron>`__
- `Egglestron (@Egglestron) <https://github.com/Egglestron>`__
- `Eike (@ei-ke) <https://github.com/ei-ke>`__
- `Elazar Leibovich (@elazarl) <https://github.com/elazarl>`__
- `Eli (@eli-xciv) <https://github.com/eli-xciv>`__
@ -585,7 +586,7 @@ Contributors
- `Jimmy Hedman (@HeMan) <https://github.com/HeMan>`__
- `Hemi03 (@Hemi03) <https://github.com/Hemi03>`__
- `HengYongChao (@HengYongChao) <https://github.com/HengYongChao>`__
- `HepoH3 (@HepoH3) <https://github.com/HepoH3>`__
- `Andrei Solodovnikov (@HepoH3) <https://github.com/HepoH3>`__
- `Hermann Kraus (@herm) <https://github.com/herm>`__
- `Herr Frei (@herrfrei) <https://github.com/herrfrei>`__
- `highground88 (@highground88) <https://github.com/highground88>`__
@ -608,7 +609,7 @@ Contributors
- `Adrián Panella (@ianchi) <https://github.com/ianchi>`__
- `Ian Anderson (@ianderso) <https://github.com/ianderso>`__
- `Ian Leeder (@ianleeder) <https://github.com/ianleeder>`__
- `Jan Pobořil (@iBobik) <https://github.com/iBobik>`__
- `Honza Pobořil (@iBobik) <https://github.com/iBobik>`__
- `igg (@igg) <https://github.com/igg>`__
- `Ignacio Hernandez-Ros (@IgnacioHR) <https://github.com/IgnacioHR>`__
- `Ivan Grokhotkov (@igrr) <https://github.com/igrr>`__
@ -625,9 +626,7 @@ Contributors
- `Marc J (@InvncibiltyCloak) <https://github.com/InvncibiltyCloak>`__
- `IoT-devices LLC (@iotdevicesdev) <https://github.com/iotdevicesdev>`__
- `irtimaled (@irtimaled) <https://github.com/irtimaled>`__
- `Ingo Theiss (@itn3rd77) <https://github.com/itn3rd77>`__
- `itpeters (@itpeters) <https://github.com/itpeters>`__
- `Ivan Shvedunov (@ivan4th) <https://github.com/ivan4th>`__
- `Ivan Kravets (@ivankravets) <https://github.com/ivankravets>`__
- `Ivan Lisenkov (@ivlis) <https://github.com/ivlis>`__
- `J0RD4N300 (@J0RD4N300) <https://github.com/J0RD4N300>`__
@ -695,7 +694,7 @@ Contributors
- `joskfg (@joskfg) <https://github.com/joskfg>`__
- `Joscha Wagner (@jowgn) <https://github.com/jowgn>`__
- `Javier Peletier (@jpeletier) <https://github.com/jpeletier>`__
- `jsuanet (@jsuanet) <https://github.com/jsuanet>`__
- `Jos Suanet (@jsuanet) <https://github.com/jsuanet>`__
- `James Szalay (@jtszalay) <https://github.com/jtszalay>`__
- `Jules-R (@Jules-R) <https://github.com/Jules-R>`__
- `Julie Koubová (@juliekoubova) <https://github.com/juliekoubova>`__
@ -733,7 +732,7 @@ Contributors
- `Kevin P. Fleming (@kpfleming) <https://github.com/kpfleming>`__
- `Karl Q. (@kquinsland) <https://github.com/kquinsland>`__
- `Anandha Saravanan (@KratosMr) <https://github.com/KratosMr>`__
- `kroimon (@kroimon) <https://github.com/kroimon>`__
- `Stefan Rado (@kroimon) <https://github.com/kroimon>`__
- `krunkel (@krunkel) <https://github.com/krunkel>`__
- `kryptonitecb3 (@kryptonitecb3) <https://github.com/kryptonitecb3>`__
- `Kendell R (@KTibow) <https://github.com/KTibow>`__
@ -747,7 +746,7 @@ Contributors
- `Anton Viktorov (@latonita) <https://github.com/latonita>`__
- `Lawrie George (@lawriege) <https://github.com/lawriege>`__
- `Ludovic BOUÉ (@lboue) <https://github.com/lboue>`__
- `lcavalli (@lcavalli) <https://github.com/lcavalli>`__
- `Luca Cavalli (@lcavalli) <https://github.com/lcavalli>`__
- `Craig Fletcher (@leakypixel) <https://github.com/leakypixel>`__
- `Dominik Wagenknecht (@LeDominik) <https://github.com/LeDominik>`__
- `Benny de Leeuw (@leeuwte) <https://github.com/leeuwte>`__
@ -756,7 +755,7 @@ Contributors
- `Leo Winter (@LeoWinterDE) <https://github.com/LeoWinterDE>`__
- `Lubos Horacek (@lhoracek) <https://github.com/lhoracek>`__
- `Liionboy (@Liionboy) <https://github.com/Liionboy>`__
- `Juraj Liso (@LiJu09) <https://github.com/LiJu09>`__
- `LiJu09 (@LiJu09) <https://github.com/LiJu09>`__
- `Li Junru (@lijunru-hub) <https://github.com/lijunru-hub>`__
- `lillborje71 (@lillborje71) <https://github.com/lillborje71>`__
- `Caleb Pryor (@lilmansplace) <https://github.com/lilmansplace>`__
@ -945,7 +944,7 @@ Contributors
- `Ockert Marais (@OckertM) <https://github.com/OckertM>`__
- `Dave Walker (@oddsockmachine) <https://github.com/oddsockmachine>`__
- `Odd Stråbø (@oddstr13) <https://github.com/oddstr13>`__
- `Andrey Ganzevich (@odya) <https://github.com/odya>`__
- `Andrii Ganzevych (@odya) <https://github.com/odya>`__
- `ogatatsu (@ogatatsu) <https://github.com/ogatatsu>`__
- `Oğuzhan Başer (@oguzhanbaser) <https://github.com/oguzhanbaser>`__
- `Larry (@ojaksch) <https://github.com/ojaksch>`__
@ -956,7 +955,7 @@ Contributors
- `Onne (@onnlucky) <https://github.com/onnlucky>`__
- `optimusprimespace (@optimusprimespace) <https://github.com/optimusprimespace>`__
- `Oscar Bolmsten (@oscar-b) <https://github.com/oscar-b>`__
- `Otamay (@Otamay) <https://github.com/Otamay>`__
- `Mauri (@Otamay) <https://github.com/Otamay>`__
- `Otto Winter (@OttoWinter) <https://github.com/OttoWinter>`__
- `Maxime Dufour (@outscale-mdr) <https://github.com/outscale-mdr>`__
- `Ben Owen (@owenb321) <https://github.com/owenb321>`__
@ -1030,7 +1029,7 @@ Contributors
- `RadekHvizdos (@RadekHvizdos) <https://github.com/RadekHvizdos>`__
- `rafalstarczak (@rafalstarczak) <https://github.com/rafalstarczak>`__
- `Florian Ragwitz (@rafl) <https://github.com/rafl>`__
- `raineth (@raineth) <https://github.com/raineth>`__
- `Ben Winslow (@raineth) <https://github.com/raineth>`__
- `Ben V. Brown (@Ralim) <https://github.com/Ralim>`__
- `Benjamin G. (@Randomblock1) <https://github.com/Randomblock1>`__
- `randomllama (@randomllama) <https://github.com/randomllama>`__
@ -1051,7 +1050,7 @@ Contributors
- `Robert Gabrielson (@rgabrielson11) <https://github.com/rgabrielson11>`__
- `Rafael Goes (@rgriffogoes) <https://github.com/rgriffogoes>`__
- `rheinz (@rheinz) <https://github.com/rheinz>`__
- `richardhopton (@richardhopton) <https://github.com/richardhopton>`__
- `Richard Hopton (@richardhopton) <https://github.com/richardhopton>`__
- `Richard Klingler (@richardklingler) <https://github.com/richardklingler>`__
- `Richard Lewis (@richrd) <https://github.com/richrd>`__
- `Rishab Mehta (@rishabmehta7) <https://github.com/rishabmehta7>`__
@ -1153,7 +1152,7 @@ Contributors
- `sticilface (@sticilface) <https://github.com/sticilface>`__
- `Stijn Tintel (@stintel) <https://github.com/stintel>`__
- `Mathias Stock (@Stock-M) <https://github.com/Stock-M>`__
- `Strixx76 (@Strixx76) <https://github.com/Strixx76>`__
- `Daniel Jönsson (@Strixx76) <https://github.com/Strixx76>`__
- `stubs12 (@stubs12) <https://github.com/stubs12>`__
- `sud33p (@sud33p) <https://github.com/sud33p>`__
- `sumirati (@sumirati) <https://github.com/sumirati>`__
@ -1207,7 +1206,7 @@ Contributors
- `Thomas Langewouters (@thouters) <https://github.com/thouters>`__
- `Transylvania High Tech (@thtro) <https://github.com/thtro>`__
- `Thunderbiscuits (@Thunderbiscuits) <https://github.com/Thunderbiscuits>`__
- `tiagofreire-pt (@tiagofreire-pt) <https://github.com/tiagofreire-pt>`__
- `Tiago Freire (@tiagofreire-pt) <https://github.com/tiagofreire-pt>`__
- `Tijs-B (@Tijs-B) <https://github.com/Tijs-B>`__
- `Tim Boldt (@timboldt) <https://github.com/timboldt>`__
- `Tim Laurence (@timdaman) <https://github.com/timdaman>`__
@ -1217,7 +1216,7 @@ Contributors
- `Tinkerfish (@tinkerfish) <https://github.com/tinkerfish>`__
- `TJ Horner (@tjhorner) <https://github.com/tjhorner>`__
- `Christian (@Tntdruid) <https://github.com/Tntdruid>`__
- `Philipp Tölke (@toelke) <https://github.com/toelke>`__
- `Philipp Riederer (@toelke) <https://github.com/toelke>`__
- `tomaszduda23 (@tomaszduda23) <https://github.com/tomaszduda23>`__
- `Tom Brien (@TomBrien) <https://github.com/TomBrien>`__
- `Thomas Combriat (@tomcombriat) <https://github.com/tomcombriat>`__
@ -1230,7 +1229,7 @@ Contributors
- `Aleksandra M (@tort32) <https://github.com/tort32>`__
- `tracestep (@tracestep) <https://github.com/tracestep>`__
- `Trent Houliston (@TrentHouliston) <https://github.com/TrentHouliston>`__
- `Felix Eckhofer (@tribut) <https://github.com/tribut>`__
- `Felix E (@tribut) <https://github.com/tribut>`__
- `Trick van Staveren (@trickv) <https://github.com/trickv>`__
- `TripitakaBC (@TripitakaBC) <https://github.com/TripitakaBC>`__
- `Tobias (@tripplet) <https://github.com/tripplet>`__
@ -1280,7 +1279,7 @@ Contributors
- `whimsee (@whimsee) <https://github.com/whimsee>`__
- `wifwucite (@wifwucite) <https://github.com/wifwucite>`__
- `wilberforce (@wilberforce) <https://github.com/wilberforce>`__
- `wildekek (@wildekek) <https://github.com/wildekek>`__
- `Willem Vooijs (@wildekek) <https://github.com/wildekek>`__
- `Wingman3434 (@Wingman3434) <https://github.com/Wingman3434>`__
- `Emil Hesslow (@WizKid) <https://github.com/WizKid>`__
- `WJCarpenter (@wjcarpenter) <https://github.com/wjcarpenter>`__
@ -1299,7 +1298,7 @@ Contributors
- `Xose Pérez (@xoseperez) <https://github.com/xoseperez>`__
- `WitchKing (@xvil) <https://github.com/xvil>`__
- `Andrew Kroll (@xxxajk) <https://github.com/xxxajk>`__
- `Yaroslav (@Yarikx) <https://github.com/Yarikx>`__
- `Yaroslav Heriatovych (@Yarikx) <https://github.com/Yarikx>`__
- `Marcin Jaworski (@yawor) <https://github.com/yawor>`__
- `yousaf465 (@yousaf465) <https://github.com/yousaf465>`__
- `Yuval Aboulafia (@yuvalabou) <https://github.com/yuvalabou>`__
@ -1314,4 +1313,4 @@ Contributors
- `Zsolt Zsiros (@ZsZs73) <https://github.com/ZsZs73>`__
- `Christian Zufferey (@zuzu59) <https://github.com/zuzu59>`__
*This page was last updated January 17, 2024.*
*This page was last updated January 22, 2024.*