Upstream/esphome-docs
1
0
Fork 0
mirror of https://github.com/esphome/esphome-docs.git synced 2024-09-26 04:02:50 +02:00
Code Issues Projects Releases Wiki Activity

document modbus fp32 datatype (#1590)

Browse Source 
Co-authored-by: Jesse Hills <3060199+jesserockz@users.noreply.github.com>
This commit is contained in:
Martin 2021-11-26 00:49:07 +01:00 committed by GitHub
parent a37d93d1a6
commit ce04f78066
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 257 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
components/binary_sensor/modbus_controller.rst
View File

@ -23,7 +23,10 @@ Configuration variables:
- **address**: (**Required**, integer): start address of the first register in a range
- **bitmask** : some values are packed in a response. The bitmask is used to determined if the result is true or false
- **skip_updates**: (*Optional*, integer): By default all sensors of 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
- **force_new_range**: (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting `foce_new_range: true` enforces the start of a new range at that address.
- **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_data** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_data`` 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_data` 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
- **offset**: (*Optional*, integer): not required for most cases

27
components/modbus_controller.rst
View File

@ -7,10 +7,6 @@ Modbus Controller
The ``modbus_controller`` component creates a RS485 connection to control a modbus device
.. warning::
If you are using the :doc:`logger` uart logging might interfere especially on esp8266. You can disable the uart logging with the ``baud_rate: 0`` option.
.. figure:: /images/modbus.png
:align: center
:width: 25%
@ -29,6 +25,25 @@ See [How is this RS485 Module Working?](https://electronics.stackexchange.com/qu
The controller connects to the UART of the MCU. For ESP32 GPIO PIN 16 to TXD PIN 17 to RXD are the default ports but any other pins can be used as well . 3.3V to VCC and GND to GND.
.. note::
If you are using an ESP8266, serial logging may cause problems reading from UART. For best results, hardware serial is recommended. Software serial may not be able to read all received data if other components spend a lot of time in the ``loop()``.
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.
Serial logging can be disabled by setting ``baud_rate: 0``.
See :doc:`logger` for more details
.. code-block:: yaml
logger:
level: <level>
baud_rate: 0
Configuration variables:
------------------------
@ -42,8 +57,8 @@ Configuration variables:
Because some modbus devices limit the rate of requests the interval between sending requests to the device can be modified.
Getting started with Home Assistant
-----------------------------------
Example
-------
The following code create a modbus_controller hub talking to a modbus device at address 1 with 115200 bps

33
components/number/modbus_controller.rst
View File

@ -18,27 +18,32 @@ Configuration variables:
- read: Read Input Registers - registers are 16-bit registers used for input, and may only be read
- **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)
- U_WORD (unsigned float from 1 register =16bit
- S_WORD (signed float from one register)
- U_DWORD (unsigned float from 2 registers = 32bit)
- S_DWORD (unsigned float from 2 registers = 32bit)
- U_DWORD_R (unsigend float from 2 registers low word first )
- S_DWORD_R (sigend float from 2 registers low word first )
- U_QWORD (unsigned float from 4 registers = 64bit
- S_QWORD (signed float from 4 registers = 64bit
- U_QWORD_R (unsigend float from 4 registers low word first )
- S_QWORD_R (sigend float from 4 registers low word first )
- U_WORD (unsigned 16 bit integer from 1 register = 16bit)
- S_WORD (signed 16 bit integer from 1 register = 16bit)
- U_DWORD (unsigned 32 bit integer from 2 registers = 32bit)
- S_DWORD (signed 32 bit integer from 2 registers = 32bit)
- U_DWORD_R (unsigned 32 bit integer from 2 registers low word first)
- S_DWORD_R (signed 32 bit integer from 2 registers low word first)
- U_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
- S_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
- U_QWORD_R (unsigned 64 bit integer from 4 registers low word first)
- U_QWORD_R signed 64 bit integer from 4 registers low word first)
- 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*, integer): By default all sensors of 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
The number of registers this data point spans. Default is 1
- **force_new_range**: (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting `foce_new_range: true` enforces the start of a new range at that address.
The number of registers this data point spans. Overrides the defaults determined by ``value_type``.
- **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
- **custom_data** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_data`` 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_data` 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.
- **write_lambda** (*Optional*, :ref:`lambda <config-lambda>`): Lambda called before send.
@ -53,7 +58,7 @@ Parameters passed into the lambda
- **x** (float): The parsed float value of the modbus data
- **data** (std::vector<uint8_t): vector containing the complete raw modbus response bytes for this sensor
note: because the response contains data for all registers in the same range you have to use `data[item->offset]` to get the first response byte for your sensor.
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
- **item** (const pointer to a SensorItem derived object): The sensor object itself.
Possible return values for the lambda:
@ -68,7 +73,7 @@ Possible return values for the lambda:
- **x** (float): The float value to be sent to the modbus device
- **payload** (`std::vector<uint16_t>&payload`): empty vector for the payload. The lamdba can add 16 bit raw modbus register words.
note: because the response contains data for all registers in the same range you have to use `data[item->offset]` to get the first response byte for your sensor.
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
- **item** (const pointer to a SensorItem derived object): The sensor object itself.
Possible return values for the lambda:

26
components/output/modbus_controller.rst
View File

@ -13,20 +13,22 @@ Configuration variables:
- **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)
- U_WORD (unsigned float from 1 register =16bit
- S_WORD (signed float from one register)
- U_DWORD (unsigned float from 2 registers = 32bit)
- S_DWORD (unsigned float from 2 registers = 32bit)
- U_DWORD_R (unsigend float from 2 registers low word first )
- S_DWORD_R (sigend float from 2 registers low word first )
- U_QWORD (unsigned float from 4 registers = 64bit
- S_QWORD (signed float from 4 registers = 64bit
- U_QWORD_R (unsigend float from 4 registers low word first )
- S_QWORD_R (sigend float from 4 registers low word first )
- U_WORD (unsigned 16 bit integer from 1 register = 16bit)
- S_WORD (signed 16 bit integer from 1 register = 16bit)
- U_DWORD (unsigned 32 bit integer from 2 registers = 32bit)
- S_DWORD (signed 32 bit integer from 2 registers = 32bit)
- U_DWORD_R (unsigned 32 bit integer from 2 registers low word first)
- S_DWORD_R (signed 32 bit integer from 2 registers low word first)
- U_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
- S_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
- U_QWORD_R (unsigned 64 bit integer from 4 registers low word first)
- U_QWORD_R signed 64 bit integer from 4 registers low word first)
- 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_count**: (*Optional*): only required for uncommon response encodings
The number of registers this data point spans. Default is 1
- **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`
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.
- **multiply** (*Optional*, float): multiply the new value with this factor before sending the requests. Ignored if lambda is defined.
- **offset**: (*Optional*, int): only required for uncommon response encodings
@ -40,7 +42,7 @@ All other options from :ref:`Output <config-output>`.
- **x** (float): The float value to be sent to the modbus device
- **payload** (`std::vector<uint16_t>&payload`): empty vector for the payload. The lamdba can add 16 bit raw modbus register words.
note: because the response contains data for all registers in the same range you have to use `data[item->offset]` to get the first response byte for your sensor.
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
- **item** (const pointer to a SensorItem derived object): The sensor object itself.
Possible return values for the lambda:

167
components/sensor/modbus_controller.rst
View File

@ -14,29 +14,38 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **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 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.
- **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)
- U_WORD (unsigned float from 1 register =16bit
- S_WORD (signed float from one register)
- U_DWORD (unsigned float from 2 registers = 32bit)
- S_DWORD (unsigned float from 2 registers = 32bit)
- U_DWORD_R (unsigend float from 2 registers low word first )
- S_DWORD_R (sigend float from 2 registers low word first )
- U_QWORD (unsigned float from 4 registers = 64bit
- S_QWORD (signed float from 4 registers = 64bit
- U_QWORD_R (unsigend float from 4 registers low word first )
- S_QWORD_R (sigend float from 4 registers low word first )
- U_WORD (unsigned 16 bit integer from 1 register = 16bit)
- S_WORD (signed 16 bit integer from 1 register = 16bit)
- U_DWORD (unsigned 32 bit integer from 2 registers = 32bit)
- S_DWORD (signed 32 bit integer from 2 registers = 32bit)
- U_DWORD_R (unsigned 32 bit integer from 2 registers low word first)
- S_DWORD_R (signed 32 bit integer from 2 registers low word first)
- U_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
- S_QWORD (unsigned 64 bit integer from 4 registers = 64bit)
- U_QWORD_R (unsigned 64 bit integer from 4 registers low word first)
- U_QWORD_R signed 64 bit integer from 4 registers low word first)
- 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)s
- **bitmask**: (*Optional*) 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*, integer): By default all sensors of 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
The number of registers this data point spans. Default is 1
- **force_new_range**: (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting `foce_new_range: true` enforces the start of a new range at that address.
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`` must be set. For example, if your modbus device uses 1 registers for a FP32 value instead the default of two set ``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_data** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_data`` 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_data` 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.
- **offset**: (*Optional*, int): only required for uncommon response encodings
@ -119,7 +128,7 @@ Parameters passed into the lambda
- **x** (float): The parsed float value of the modbus data
- **data** (std::vector<uint8_t): vector containing the complete raw modbus response bytes for this sensor
note: because the response contains data for all registers in the same range you have to use `data[item->offset]` to get the first response byte for your sensor.
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
- **item** (const pointer to a SensorItem derived object): The sensor object itself.
Possible return values for the lambda:
@ -127,6 +136,130 @@ Possible return values for the lambda:
- ``return <FLOATING_POINT_NUMBER>;`` the new value for the sensor.
- ``return NAN;`` if the state should be considered invalid to indicate an error (advanced).
.. _modbus_custom_data:
Using custom_data
-----------------
``custom_data`` 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
.. 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_controller`

43
components/switch/modbus_controller.rst
View File

@ -21,6 +21,49 @@ Configuration variables:
To get the value of the coil register 2 can be retrived using address: 2 / offset: 0 or address: 0 / offset 2
- **bitmask** : some values are packed in a response. The bitmask is used to determined if the result is true or false
- **skip_updates**: (*Optional*, integer): By default all sensors of 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_data** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_data`` 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_data` how to use ``custom_command``
- **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.
Lambda is evaluated before the modbus write command is created.
**Parameters passed into write_lambda**
- **x** (float): The float value to be sent to the modbus device
- **payload** (`std::vector<uint8_t>&payload`): empty vector for the payload. If payload is set in the lambda it is sent as a custom command and must include all required bytes for a modbus request
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
- **item** (const pointer to a Switch derived object): The sensor object itself.
Possible return values for the lambda:
- ``return <true / false>;`` the new value for the sensor.
- ``return <anything>; and fill payload with data`` if the payload is added from the lambda then these bytes will be sent
**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"
write_lambda: |-
ESP_LOGD("main","Modbus Switch incoming state = %f",x);
// return false ; // use this to just change the value
payload.push_back(0x1); // device address
payload.push_back(0x5); // force single coil
payload.push_back(0x00); // high byte address of the coil
payload.push_back(0x6); // low byte address of the coil
payload.push_back(0xFF); // ON = 0xFF00 OFF=0000
payload.push_back(0x00);
**Example**

9
components/text_sensor/modbus_controller.rst
View File

@ -25,9 +25,12 @@ Configuration variables:
- **raw_encode**: (*Optional*, NONE , HEXBYTES, COMMA) If the response is binary it can't be published directly. Since a text sensor only publishes strings the binary data can encoded
- HEXBYTES: 2 byte hex string. 0x2011 will be sent as "2011".
- COMMA: Byte values as integers, delimited by a coma. 0x2011 will be sent as "32,17"
- **force_new_range**: (*Optional*, boolean): If possible sensors with sequential addresses are grouped together and requested in one range. Setting `foce_new_range: true` enforces the start of a new range at that address.
- **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_data** (*Optional*, list of bytes): raw bytes for modbus command. This allows using non-standard commands. If ``custom_data`` 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_data` 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
Lambda to be evaluated every update interval to get the new value of the text_sensor
- **offset**: (*Optional*, integer): 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
@ -37,7 +40,7 @@ Parameters passed into the lambda
- **x** (std:string): The parsed float value of the modbus data
- **data** (std::vector<uint8_t): vector containing the complete raw modbus response bytes for this sensor
note: because the response contains data for all registers in the same range you have to use `data[item->offset]` to get the first response byte for your sensor.
note: because the response contains data for all registers in the same range you have to use ``data[item->offset]`` to get the first response byte for your sensor.
- **item** (const pointer to a SensorItem derived object): The sensor object itself.
Possible return values for the lambda: