mirror of
https://github.com/esphome/esphome-docs.git
synced 2025-01-13 20:11:53 +01:00
Merge branch 'current' into beta
This commit is contained in:
Jesse Hills
commit
8cea8563f1
@ -63,6 +63,7 @@ Configuration variables:
|
||||
- **invert_colors** (*Optional*, boolean): Invert LCD colors. Default is false.
|
||||
- **eight_bit_color** (*Optional*, boolean): 8bit mode. Default is false. This saves 50% of the buffer required for the display.
|
||||
- **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
|
||||
- **update_interval** (*Optional*, :ref:`config-time`): Time between display updates. Default is 1s.
|
||||
|
||||
Memory notes:
|
||||
*************
|
||||
|
||||
@ -431,7 +431,10 @@ In comparison to the ``throttle`` filter it won't discard any values. In compari
|
||||
``heartbeat``
|
||||
*************
|
||||
|
||||
Send the last value that this sensor in the specified time interval.
|
||||
Send the value periodically with the specified time interval.
|
||||
If the sensor value changes during the interval the interval will not reset.
|
||||
The last value of the sensor will be sent.
|
||||
|
||||
So a value of ``10s`` will cause the filter to output values every 10s regardless
|
||||
of the input values.
|
||||
|
||||
|
||||
@ -3,12 +3,12 @@ MAX31856 Thermocouple Temperature Sensor
|
||||
|
||||
.. seo::
|
||||
:description: Instructions for setting up MAX31856 Thermocouple temperature sensors.
|
||||
:image: max31865.jpg
|
||||
:image: max31856.jpg
|
||||
|
||||
The ``MAX31856`` temperature sensor allows you to use your MAX31856 Thermocouple
|
||||
temperature sensor (`datasheet <https://datasheets.maximintegrated.com/en/ds/MAX31856.pdf>`__) with ESPHome
|
||||
|
||||
.. figure:: images/max31865-full.jpg
|
||||
.. figure:: images/max31856-full.jpg
|
||||
:align: center
|
||||
:width: 50.0%
|
||||
|
||||
|
||||
@ -43,7 +43,7 @@ to some pins on your board and the baud rate set to 9600.
|
||||
rx_pin: D1
|
||||
tx_pin: D2
|
||||
baud_rate: 9600
|
||||
|
||||
|
||||
modbus:
|
||||
|
||||
sensor:
|
||||
@ -96,6 +96,56 @@ This action resets the total energy value of the pzemac device with the given ID
|
||||
then:
|
||||
- pzemac.reset_energy: pzemac_1
|
||||
|
||||
Changing the address of a PZEM-004T:
|
||||
------------------------------------
|
||||
|
||||
You can use the following configuration to change the address of a sensor.
|
||||
You must set the ``address`` of the ``modbus_controller`` to the current address, and ``new_address`` of the ``on_boot`` lambda to the new one.
|
||||
|
||||
.. warning::
|
||||
|
||||
This should be used only once! After changing the address, this code should be removed from the ESP before using the actual sensor code.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
esphome:
|
||||
...
|
||||
on_boot:
|
||||
## configure controller settings at setup
|
||||
## make sure priority is lower than setup_priority of modbus_controller
|
||||
priority: -100
|
||||
then:
|
||||
- lambda: |-
|
||||
auto new_address = 0x03;
|
||||
|
||||
if(new_address < 0x01 || new_address > 0xF7) // sanity check
|
||||
{
|
||||
ESP_LOGE("ModbusLambda", "Address needs to be between 0x01 and 0xF7");
|
||||
return;
|
||||
}
|
||||
|
||||
esphome::modbus_controller::ModbusController *controller = id(pzem);
|
||||
auto set_addr_cmd = esphome::modbus_controller::ModbusCommandItem::create_write_single_command(
|
||||
controller, 0x0002, new_address);
|
||||
|
||||
delay(200) ;
|
||||
controller->queue_command(set_addr_cmd);
|
||||
ESP_LOGI("ModbusLambda", "PZEM Addr set");
|
||||
|
||||
modbus:
|
||||
send_wait_time: 200ms
|
||||
id: mod_bus_pzem
|
||||
|
||||
modbus_controller:
|
||||
- id: pzem
|
||||
## the current device addr
|
||||
address: 0x1
|
||||
modbus_id: mod_bus_pzem
|
||||
command_throttle: 0ms
|
||||
setup_priority: -10
|
||||
update_interval: 30s
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
|
||||
@ -36,6 +36,18 @@ outputs go in the wrong direction, you can just swap these two pins.
|
||||
pin_a: D1
|
||||
pin_b: D2
|
||||
|
||||
To modify additional parameters of pins like active state or pull-ups, you may add extra options.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Example of advanced pin configuration
|
||||
pin_a:
|
||||
number: D5
|
||||
inverted: true
|
||||
mode:
|
||||
input: true
|
||||
pullup: true
|
||||
|
||||
Configuration variables:
|
||||
------------------------
|
||||
|
||||
|
||||
@ -63,5 +63,6 @@ Configuration variables:
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/text_sensor/index`
|
||||
- :apiclass:`API Reference <text_sensor::TextSensor>`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
@ -18,11 +18,10 @@ Configuration variables:
|
||||
- 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
|
||||
- **address**: (**Required**, int): start address of the first register in a range
|
||||
- **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*, int): 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
|
||||
- **register_count**: (*Optional*): The number of registers this data point spans. Default is 1
|
||||
- **response_size**: (**Required**):response 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 encoded
|
||||
- **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".
|
||||
- ``COMMA``: Byte values as integers, delimited by a coma. 0x2011 will be sent as "32,17"
|
||||
@ -31,14 +30,14 @@ Configuration variables:
|
||||
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 sensor. It is called after the encoding according to **raw_encode**.
|
||||
- **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
|
||||
|
||||
- All options from :ref:`Text Sensor <config-text_sensor>`.
|
||||
|
||||
Parameters passed into the lambda
|
||||
|
||||
- **x** (std:string): The parsed float value of the modbus data
|
||||
- **x** (std:string): The parsed value of the modbus data according to **raw_encode**
|
||||
|
||||
- **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.
|
||||
@ -46,9 +45,8 @@ Parameters passed into the lambda
|
||||
|
||||
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).
|
||||
- ``return {};`` if you don't want to publish a new state (advanced).
|
||||
- ``return <std::string>;`` the new value for the sensor.
|
||||
- ``return {};`` uses the parsed value for the state (same as ``return x;``).
|
||||
|
||||
|
||||
|
||||
@ -58,55 +56,24 @@ Possible return values for the lambda:
|
||||
.. code-block:: yaml
|
||||
|
||||
text_sensor:
|
||||
- platform: template
|
||||
name: "RTC Time Sensor"
|
||||
id: template_rtc
|
||||
|
||||
- platform: modbus_controller
|
||||
modbus_controller_id: traceranx
|
||||
name: "rtc clock test"
|
||||
id: rtc_clock_test
|
||||
internal: true
|
||||
- platform: modbus_controller
|
||||
modbus_controller_id: modbus_device
|
||||
id: reg_1002_text
|
||||
bitmask: 0
|
||||
register_type: holding
|
||||
address: 0x9013
|
||||
register_count: 3
|
||||
hex_encode: true
|
||||
response_size: 6
|
||||
on_value:
|
||||
then:
|
||||
- lambda: |-
|
||||
ESP_LOGV("main", "decoding rtc hex encoded raw data: %s", x.c_str());
|
||||
uint8_t h=0,m=0,s=0,d=0,month_=0,y = 0 ;
|
||||
m = esphome::modbus_controller::byte_from_hex_str(x,0);
|
||||
s = esphome::modbus_controller::byte_from_hex_str(x,1);
|
||||
d = esphome::modbus_controller::byte_from_hex_str(x,2);
|
||||
h = esphome::modbus_controller::byte_from_hex_str(x,3);
|
||||
y = esphome::modbus_controller::byte_from_hex_str(x,4);
|
||||
month_ = esphome::modbus_controller::byte_from_hex_str(x,5);
|
||||
// Now check if the rtc time of the controller is ok and correct it
|
||||
time_t now = ::time(nullptr);
|
||||
struct tm *time_info = ::localtime(&now);
|
||||
int seconds = time_info->tm_sec;
|
||||
int minutes = time_info->tm_min;
|
||||
int hour = time_info->tm_hour;
|
||||
int day = time_info->tm_mday;
|
||||
int month = time_info->tm_mon + 1;
|
||||
int year = time_info->tm_year - 2000;
|
||||
// correct time if needed (ignore seconds)
|
||||
if (d != day || month_ != month || y != year || h != hour || m != minutes) {
|
||||
// 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
|
||||
esphome::modbus_controller::ModbusCommandItem set_rtc_command = esphome::modbus_controller::ModbusCommandItem::create_write_multiple_command(traceranx, 0x9013, 3, rtc_data);
|
||||
// Submit the command to the send queue
|
||||
traceranx->queue_command(set_rtc_command);
|
||||
ESP_LOGI("ModbusLambda", "EPSOLAR RTC set to %02d:%02d:%02d %02d.%02d.%04d", hour, minutes, seconds, day, month, year + 2000);
|
||||
}
|
||||
char buffer[20];
|
||||
// format time as YYYY:mm:dd hh:mm:ss
|
||||
sprintf(buffer,"%04d:%02d:%02d %02d:%02d:%02d",y+2000,month_,d,h,m,s);
|
||||
id(template_rtc).publish_state(buffer);
|
||||
address: 1002
|
||||
raw_encode: HEXBYTES
|
||||
name: Register 1002 (Text)
|
||||
lambda: |-
|
||||
uint16_t value = modbus_controller::word_from_hex_str(x, 0);
|
||||
switch (value) {
|
||||
case 1: return std::string("ready");
|
||||
case 2: return std::string("EV is present");
|
||||
case 3: return std::string("charging");
|
||||
case 4: return std::string("charging with ventilation");
|
||||
default: return std::string("Unknown");
|
||||
}
|
||||
return x;
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
@ -81,6 +81,7 @@ Configuration options:
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/text_sensor/index`
|
||||
- :ref:`automation`
|
||||
- :apiref:`template/text_sensor/template_text_sensor.h`
|
||||
- :ghedit:`Edit`
|
||||
|
||||
@ -110,3 +110,5 @@ Sample Configurations
|
||||
- `Universal menu system for devices with rotary encoder with push and SSD1306 I2C display <https://github.com/mikosoft83/pithy_screen_menu_system>`__ by :ghuser:`mikosoft83`
|
||||
- `Show heart rate sensor values sent over Bluetooth Low Energy on a display <https://github.com/koenvervloesem/ESPHome-Heart-Rate-Display>`__ by :ghuser:`koenvervloesem`
|
||||
- `ESPHome floor heating controller (proportional valves) <https://github.com/nliaudat/floor-heating-controller>`__ by :ghuser:`nliaudat`
|
||||
- `ESPHome Curtain/Cover/Shutter Switch from a noname Tuya switch <https://github.com/ludrao/esphome-shutterswitch>`__ by :ghuser:`ludrao`
|
||||
- `ESPHome Free your Thomson Guardian gate controller <https://github.com/ludrao/esphome-guardian>`__ by :ghuser:`ludrao`
|
||||
|
||||
@ -240,6 +240,11 @@ Some steps that can help with the issue:
|
||||
the log viewer on the web dashboard. In production, you will likely only have a single connection from
|
||||
Home Assistant, making this less of an issue. But beware that attaching a log viewer might
|
||||
have impact.
|
||||
- Reducing the Delivery Traffic Indication Message (DTIM) interval in the WiFi access point may help
|
||||
improve the ESP's WiFi reliability and responsiveness. This will cause WiFi devices in power
|
||||
save mode, such as the ESP, to be woken up more frequently. This may improve things for the ESP,
|
||||
although it may also increase power (and possibly battery) usage of other devices also using power
|
||||
save mode.
|
||||
|
||||
Docker Reference
|
||||
----------------
|
||||
|
||||
Loading…
Reference in New Issue
Block a user