Open jesserockz opened 1 year ago
Seeing it for both SHT31-D and DHT11 temp/humidity sensors
[09:03:55][W][component:204]: Component sht3xd.sensor took a long time for an operation (0.06 s).
[09:03:55][W][component:205]: Components should block for at most 20-30ms.
sensor:
- platform: sht3xd
temperature:
name: "Bedroom AC Temperature"
id: temperature
on_value:
then:
- component.update: feelslike
[09:11:57][W][component:204]: Component dht.sensor took a long time for an operation (0.07 s).
[09:11:57][W][component:205]: Components should block for at most 20-30ms.
- platform: dht
pin: D6
temperature:
name: "Livingroom AC Temperature"
id: temperature
on_value:
then:
- component.update: feelslike
Same here on a DSMR sensor, the device has been working properly until end of june at least. Then after an update (don't recall to which version) I started to get this error and stopped getting the data in HA... I do not know why I no longer get the data its says it is sending (despite the warning) and if the warning and not receiving data is related...
LOG (some text, where indicated, removed for privacy reasons):
[22:46:26][I][app:102]: ESPHome version 2023.8.2 compiled on Aug 29 2023, 22:57:58
[22:46:26][C][wifi:379]: Local MAC: 0C:B8:15:F6:4E:28 [22:46:26][C][wifi:380]: SSID: '..removed..'[redacted] [22:46:26][C][wifi:381]: IP Address: 192.168.0.51 [22:46:26][C][wifi:383]: BSSID: 3C:84:6A:..partly removed... [redacted]
[22:46:26][C][wifi:386]: Signal strength: -77 dB ..here a nice graph that cannot be pasted was present.. [22:46:26][C][wifi:390]: Channel: 6 [22:46:26][C][wifi:391]: Subnet: 255.255.255.0 [22:46:26][C][wifi:392]: Gateway: 192.168.0.1 [22:46:26][C][wifi:393]: DNS1: ..removed...21 [22:46:26][C][wifi:394]: DNS2: ..removed...20
[22:46:26][C][logger:302]: Level: DEBUG [22:46:26][C][logger:303]: Log Baud Rate: 115200 [22:46:26][C][logger:305]: Hardware UART: UART0 [22:46:26][C][uart.arduino_esp32:124]: UART Bus 1: [22:46:26][C][uart.arduino_esp32:126]: RX Pin: GPIO13 [22:46:26][C][uart.arduino_esp32:128]: RX Buffer Size: 1800 [22:46:26][C][uart.arduino_esp32:130]: Baud Rate: 115200 baud [22:46:26][C][uart.arduino_esp32:131]: Data Bits: 8 [22:46:26][C][uart.arduino_esp32:132]: Parity: NONE [22:46:26][C][uptime.sensor:031]: State Class: 'total_increasing' [22:46:26][C][uptime.sensor:031]: Unit of Measurement: 's' [22:46:26][C][uptime.sensor:031]: Accuracy Decimals: 0
[22:46:26][D][sensor:094]: 'Energy Consumed Tariff 1': Sending state 1681.50403 kWh with 3 decimals of accuracy [22:46:26][D][sensor:094]: 'Energy Consumed Tariff 2': Sending state 1798.13696 kWh with 3 decimals of accuracy [22:46:26][D][sensor:094]: 'Energy Produced Tariff 1': Sending state 0.00000 kWh with 3 decimals of accuracy [22:46:26][D][sensor:094]: 'Energy Produced Tariff 2': Sending state 0.00000 kWh with 3 decimals of accuracy [22:46:26][D][sensor:094]: 'Power Consumed': Sending state 2032.00012 W with 0 decimals of accuracy [22:46:26][D][sensor:094]: 'Power Produced': Sending state 0.00000 W with 0 decimals of accuracy [22:46:26][D][sensor:094]: 'Electricity Failures': Sending state 7.00000 with 0 decimals of accuracy [22:46:26][D][sensor:094]: 'Long Electricity Failures': Sending state 2.00000 with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Voltage Phase 1': Sending state 233.39999 V with 1 decimals of accuracy [22:46:27][D][sensor:094]: 'Voltage Phase 2': Sending state 233.80000 V with 1 decimals of accuracy [22:46:27][D][sensor:094]: 'Voltage Phase 3': Sending state 231.70000 V with 1 decimals of accuracy [22:46:27][D][sensor:094]: 'Current Phase 1': Sending state 7.00000 A with 1 decimals of accuracy [22:46:27][D][sensor:094]: 'Current Phase 2': Sending state 0.00000 A with 1 decimals of accuracy [22:46:27][D][sensor:094]: 'Current Phase 3': Sending state 0.00000 A with 1 decimals of accuracy [22:46:27][D][sensor:094]: 'Power Consumed Phase 1': Sending state 1857.00000 W with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Power Consumed Phase 2': Sending state 110.00000 W with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Power Consumed Phase 3': Sending state 62.00000 W with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Power Produced Phase 1': Sending state 0.00000 W with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Power Produced Phase 2': Sending state 0.00000 W with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Power Produced Phase 3': Sending state 0.00000 W with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Gas Consumed': Sending state 1515.78296 m³ with 3 decimals of accuracy [22:46:27][D][text_sensor:064]: 'DSMR Identification': Sending state 'ISK5\2M550T-1013' [22:46:27][D][text_sensor:064]: 'DSMR Version': Sending state '50' [22:46:27][W][component:204]: Component dsmr took a long time for an operation (0.22 s). [22:46:27][C][dsmr:286]: Accuracy Decimals: 3
[22:46:27][C][dsmr:286]: Device Class: 'energy' [22:46:27][C][dsmr:286]: State Class: 'total_increasing' [22:46:27][C][dsmr:286]: Unit of Measurement: 'kWh' [22:46:27][C][dsmr:286]: Accuracy Decimals: 3 [22:46:27][C][dsmr:286]: State Class: 'total_increasing' [22:46:27][C][dsmr:286]: Unit of Measurement: 'kWh' [22:46:27][C][dsmr:286]: Accuracy Decimals: 3 [22:46:27][C][dsmr:286]: State Class: 'total_increasing'
[22:46:27][C][dsmr:286]: Device Class: 'power' [22:46:27][C][dsmr:286]: State Class: 'measurement' [22:46:27][C][dsmr:286]: Unit of Measurement: 'W' [22:46:27][C][dsmr:286]: Accuracy Decimals: 0
[22:46:27][C][dsmr:286]: State Class: '' [22:46:27][C][dsmr:286]: Unit of Measurement: '' [22:46:27][C][dsmr:286]: Accuracy Decimals: 0
[22:46:27][C][dsmr:286]: Device Class: 'current' [22:46:27][C][dsmr:286]: State Class: 'measurement' [22:46:27][C][dsmr:286]: Unit of Measurement: 'A' [22:46:27][C][dsmr:286]: Accuracy Decimals: 1
[22:46:27][C][dsmr:286]: Device Class: 'power' [22:46:27][C][dsmr:286]: Accuracy Decimals: 0
[22:46:27][C][dsmr:286]: Device Class: 'power' [22:46:27][C][dsmr:286]: State Class: 'measurement' [22:46:27][C][dsmr:286]: Unit of Measurement: 'W' [22:46:27][C][dsmr:286]: Accuracy Decimals: 0
[22:46:27][C][dsmr:286]: Device Class: 'power' [22:46:27][C][dsmr:286]: State Class: 'measurement' [22:46:27][C][dsmr:286]: Unit of Measurement: 'W' [22:46:27][C][dsmr:286]: Accuracy Decimals: 0
[22:46:27][C][dsmr:286]: Device Class: 'power' [22:46:27][C][dsmr:286]: State Class: 'measurement' [22:46:27][C][dsmr:286]: Unit of Measurement: 'W' [22:46:27][C][dsmr:286]: Accuracy Decimals: 0 [22:46:27][C][dsmr:286]: Unit of Measurement: 'W' [22:46:27][C][dsmr:286]: Accuracy Decimals: 0
[22:46:27][C][dsmr:286]: Device Class: 'power' [22:46:27][C][dsmr:286]: State Class: 'measurement' [22:46:27][C][dsmr:286]: Unit of Measurement: 'W' [22:46:27][C][dsmr:286]: Accuracy Decimals: 0
[22:46:27][C][dsmr:286]: Device Class: 'gas' [22:46:27][C][dsmr:286]: State Class: 'total_increasing' [22:46:27][C][dsmr:286]: Unit of Measurement: 'm³' [22:46:27][C][dsmr:286]: Accuracy Decimals: 3
[22:46:27][C][version.text_sensor:021]: Version Text Sensor 'ESPHome Version' [22:46:27][C][captive_portal:088]: Captive Portal:
[22:46:27][C][mdns:113]: Hostname: slimmemeter [22:46:27][C][ota:093]: Over-The-Air Updates: [22:46:27][C][ota:094]: Address: slimmemeter.local:3232 [22:46:27][C][ota:097]: Using Password. [22:46:27][C][api:138]: API Server: [22:46:27][C][api:139]: Address: slimmemeter.local:6053 [22:46:27][C][api:143]: Using noise encryption: NO [22:46:27][C][wifi_signal.sensor:009]: WiFi Signal 'Wi-Fi Signal' [22:46:27][C][wifi_signal.sensor:009]: Device Class: 'signal_strength' [22:46:27][C][wifi_signal.sensor:009]: State Class: 'measurement' [22:46:27][C][wifi_signal.sensor:009]: Unit of Measurement: 'dBm' [22:46:27][C][wifi_signal.sensor:009]: Accuracy Decimals: 0 [22:46:27][D][sensor:094]: 'Energy Consumed Tariff 1': Sending state 1681.50403 kWh with 3 decimals of accuracy [22:46:27][D][sensor:094]: 'Energy Consumed Tariff 2': Sending state 1798.13794 kWh with 3 decimals of accuracy [22:46:27][D][sensor:094]: 'Energy Produced Tariff 1': Sending state 0.00000 kWh with 3 decimals of accuracy [22:46:27][D][sensor:094]: 'Energy Produced Tariff 2': Sending state 0.00000 kWh with 3 decimals of accuracy [22:46:27][D][sensor:094]: 'Power Consumed': Sending state 2037.00000 W with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Power Produced': Sending state 0.00000 W with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Electricity Failures': Sending state 7.00000 with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Long Electricity Failures': Sending state 2.00000 with 0 decimals of accuracy [22:46:27][D][sensor:094]: 'Voltage Phase 1': Sending state 233.39999 V with 1 decimals of accuracy [22:46:28][D][sensor:094]: 'Voltage Phase 2': Sending state 233.89999 V with 1 decimals of accuracy [22:46:28][D][sensor:094]: 'Voltage Phase 3': Sending state 231.70000 V with 1 decimals of accuracy [22:46:28][D][sensor:094]: 'Current Phase 1': Sending state 7.00000 A with 1 decimals of accuracy [22:46:28][D][sensor:094]: 'Current Phase 2': Sending state 0.00000 A with 1 decimals of accuracy [22:46:28][D][sensor:094]: 'Current Phase 3': Sending state 0.00000 A with 1 decimals of accuracy [22:46:28][D][sensor:094]: 'Power Consumed Phase 1': Sending state 1859.00000 W with 0 decimals of accuracy [22:46:28][D][sensor:094]: 'Power Consumed Phase 2': Sending state 111.00000 W with 0 decimals of accuracy [22:46:28][D][sensor:094]: 'Power Consumed Phase 3': Sending state 62.00000 W with 0 decimals of accuracy [22:46:28][D][sensor:094]: 'Power Produced Phase 1': Sending state 0.00000 W with 0 decimals of accuracy [22:46:28][D][sensor:094]: 'Power Produced Phase 2': Sending state 0.00000 W with 0 decimals of accuracy [22:46:28][D][sensor:094]: 'Power Produced Phase 3': Sending state 0.00000 W with 0 decimals of accuracy [22:46:28][D][sensor:094]: 'Gas Consumed': Sending state 1515.78296 m³ with 3 decimals of accuracy [22:46:28][D][text_sensor:064]: 'DSMR Identification': Sending state 'ISK5\2M550T-1013' [22:46:28][D][text_sensor:064]: 'DSMR Version': Sending state '50' [22:46:28][W][component:204]: Component dsmr took a long time for an operation (0.21 s). [22:46:28][W][component:205]: Components should block for at most 20-30ms. [22:46:28][C][wifi_info:009]: WifiInfo IPAddress 'IP Address' [22:46:28][C][wifi_info:011]: WifiInfo SSID 'Wi-Fi SSID' [22:46:28][C][wifi_info:012]: WifiInfo BSSID 'Wi-Fi BSSID'
Config: esphome: name: slimmemeter
esp32: board: esp32dev framework: type: arduino
logger:
api:
ota: password: "..removed.."
wifi: ssid: !secret wifi_ssid password: !secret wifi_password
ap: ssid: "Slimmemeter Fallback Hotspot" password: "pLeiAz38VA7w"
captive_portal:
uart: rx_pin: number: GPIO13 inverted: false baud_rate: 115200 rx_buffer_size: 1800
dsmr:
id: dsmr_1
receive_timeout: 200ms
max_telegram_length: 1800
sensor:
text_sensor:
Hello all
Anyone found a workaround for sht4x sensors?
[ 29947][E][Wire.cpp:513] requestFrom(): i2cRead returned Error 263 [D][sht4x:080]: Sensor read failed [W][component:204]: Component sht4x.sensor took a long time for an operation (1.00 s). [W][component:205]: Components should block for at most 20-30ms.
I am getting a consistent error from the CAN bus integration. [20:49:10][W][component:204]: Component canbus took a long time for an operation (0.10 s). [20:49:10][W][component:205]: Components should block for at most 20-30ms.
I get it every few CAN frames. Here is a longer log…
[20:49:10][W][component:204]: Component canbus took a long time for an operation (0.10 s). [20:49:10][W][component:205]: Components should block for at most 20-30ms. [20:49:11][D][canbus:067]: received can message (#1) extended can_id=0x15fd0723 size=8 [20:49:11][D][can_id:057]: Received CAN message with ID: 15fd0723 [20:49:11][D][can_data:065]: Byte 0: a7 [20:49:11][D][can_data:065]: Byte 1: c0 [20:49:11][D][can_data:065]: Byte 2: 6f [20:49:11][D][can_data:065]: Byte 3: 77 [20:49:11][D][can_data:065]: Byte 4: ff [20:49:11][D][can_data:065]: Byte 5: 7f [20:49:11][D][can_data:065]: Byte 6: ff [20:49:11][D][can_data:065]: Byte 7: ff
[20:49:11][D][canbus:067]: received can message (#1) extended can_id=0xdf50b23 size=8 [20:49:11][D][can_id:057]: Received CAN message with ID: df50b23 [20:49:11][D][can_data:065]: Byte 0: cf [20:49:11][D][can_data:065]: Byte 1: bb [20:49:11][D][can_data:065]: Byte 2: 00 [20:49:11][D][can_data:065]: Byte 3: 00 [20:49:11][D][can_data:065]: Byte 4: 00 [20:49:11][D][can_data:065]: Byte 5: 00 [20:49:11][D][can_data:065]: Byte 6: 00 [20:49:11][D][can_data:065]: Byte 7: ff
[20:49:11][D][canbus:067]: received can message (#2) extended can_id=0x19f51323 size=8 [20:49:11][D][can_id:057]: Received CAN message with ID: 19f51323 [20:49:11][D][can_data:065]: Byte 0: 62 [20:49:11][D][can_data:065]: Byte 1: 00 [20:49:11][D][can_data:065]: Byte 2: ff [20:49:11][D][can_data:065]: Byte 3: ff [20:49:11][D][can_data:065]: Byte 4: ff [20:49:11][D][can_data:065]: Byte 5: ff [20:49:11][D][can_data:065]: Byte 6: ff [20:49:11][D][can_data:065]: Byte 7: ff
[20:49:11][W][component:204]: Component canbus took a long time for an operation (0.10 s). [20:49:11][W][component:205]: Components should block for at most 20-30ms. [20:49:12][D][canbus:067]: received can message (#1) extended can_id=0x15fd0723 size=8 [20:49:12][D][can_id:057]: Received CAN message with ID: 15fd0723 [20:49:12][D][can_data:065]: Byte 0: a9 [20:49:12][D][can_data:065]: Byte 1: c0 [20:49:12][D][can_data:065]: Byte 2: 6f [20:49:12][D][can_data:065]: Byte 3: 77 [20:49:12][D][can_data:065]: Byte 4: ff [20:49:12][D][can_data:065]: Byte 5: 7f [20:49:12][D][can_data:065]: Byte 6: ff [20:49:12][D][can_data:065]: Byte 7: ff
[20:49:12][W][component:204]: Component canbus took a long time for an operation (0.05 s). [20:49:12][W][component:205]: Components should block for at most 20-30ms. [20:49:12][D][canbus:067]: received can message (#1) extended can_id=0xdf50b23 size=8 [20:49:12][D][can_id:057]: Received CAN message with ID: df50b23 [20:49:12][D][can_data:065]: Byte 0: d0 [20:49:12][D][can_data:065]: Byte 1: bb [20:49:12][D][can_data:065]: Byte 2: 00 [20:49:12][D][can_data:065]: Byte 3: 00 [20:49:12][D][can_data:065]: Byte 4: 00 [20:49:12][D][can_data:065]: Byte 5: 00 [20:49:12][D][can_data:065]: Byte 6: 00 [20:49:12][D][can_data:065]: Byte 7: ff
[20:49:12][D][canbus:067]: received can message (#2) extended can_id=0x19f51323 size=8 [20:49:12][D][can_id:057]: Received CAN message with ID: 19f51323 [20:49:12][D][can_data:065]: Byte 0: 82 [20:49:12][D][can_data:065]: Byte 1: 00 [20:49:12][D][can_data:065]: Byte 2: ff [20:49:12][D][can_data:065]: Byte 3: ff [20:49:12][D][can_data:065]: Byte 4: ff [20:49:12][D][can_data:065]: Byte 5: ff [20:49:12][D][can_data:065]: Byte 6: ff [20:49:12][D][can_data:065]: Byte 7: ff
[20:49:12][W][component:204]: Component canbus took a long time for an operation (0.10 s). [20:49:12][W][component:205]: Components should block for at most 20-30ms. [20:49:13][D][canbus:067]: received can message (#1) extended can_id=0x15fd0723 size=8 [20:49:13][D][can_id:057]: Received CAN message with ID: 15fd0723 [20:49:13][D][can_data:065]: Byte 0: ab [20:49:13][D][can_data:065]: Byte 1: c0 [20:49:13][D][can_data:065]: Byte 2: 6f [20:49:13][D][can_data:065]: Byte 3: 77 [20:49:13][D][can_data:065]: Byte 4: ff [20:49:13][D][can_data:065]: Byte 5: 7f [20:49:13][D][can_data:065]: Byte 6: ff [20:49:13][D][can_data:065]: Byte 7: ff This is my yaml…
`spi: id: spi_bus clk_pin: GPIO18 miso_pin: GPIO19 mosi_pin: GPIO23
canbus:
platform: mcp2515 cs_pin: GPIO5 spi_id: spi_bus can_id: 0 use_extended_id: True bit_rate: 250kbps on_frame:
can_id: 0
use_extended_id: True
can_id_mask: 0
then:
lambda: |-
ESP_LOGD("can_id", "Received CAN message with ID: %x", can_id);
// Extracting the PGN directly uint32_t PGN = (can_id >> 8) & 0x3FFFF; // Masking to 18 bits after shifting
for (int i = 0; i < 8; i++) { ESP_LOGD("can_data", "Byte %d: %02x", i, x[i]); }
ESP_LOGD("can_id", "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"); `
same issue on 1 of 3 sonoff pow 3 I have here, Strange thing is, I've installed the binary on another sonoff pow 3 and it's software related, issue is persistent where ever the binary is installed on. There's not much more than the component cse7766 on it, ESP32 should be dealing this with ease.
Log says
[21:51:34][D][api:102]: Accepted 192.168.1.6
[21:51:34][W][component:204]: Component api took a long time for an operation (0.05 s).
[21:51:34][W][component:205]: Components should block for at most 20-30ms.
[21:51:34][D][api.connection:1031]: Home Assistant 2023.9.0 (192.168.1.6): Connected successfully
[21:51:34][D][time:045]: Synchronized time: 2023-09-07 21:51:34
yaml is on https://pastebin.com/YuM1zktF
[12:04:39][W][component:204]: Component esp32_ble_tracker took a long time for an operation (0.07 s).
[12:04:39][W][component:205]: Components should block for at most 20-30ms.
esphome:
name: nanobeacon
friendly_name: NanoBeacon
esp32:
board: esp32doit-devkit-v1
framework:
type: esp-idf
# Enable logging
logger:
level: VERY_VERBOSE
ota:
password: !secret ota_password
wifi:
ssid: !secret ding_wifi_ssid
password: !secret ding_wifi_password
# Enable Home Assistant API
api:
encryption:
key: ***************
button:
- platform: restart
name: "Restart"
esp32_ble_tracker:
scan_parameters:
active: False
bluetooth_proxy:
active: False
i2c:
sda: 21
scl: 22
scan: true
id: i2c_bus_a
same issue on 1 of 3 sonoff pow 3 I have here, Strange thing is, I've installed the binary on another sonoff pow 3 and it's software related, issue is persistent where ever the binary is installed on. There's not much more than the component cse7766 on it, ESP32 should be dealing this with ease.
Log says
[21:51:34][D][api:102]: Accepted 192.168.1.6 [21:51:34][W][component:204]: Component api took a long time for an operation (0.05 s). [21:51:34][W][component:205]: Components should block for at most 20-30ms. [21:51:34][D][api.connection:1031]: Home Assistant 2023.9.0 (192.168.1.6): Connected successfully [21:51:34][D][time:045]: Synchronized time: 2023-09-07 21:51:34
yaml is on https://pastebin.com/YuM1zktF
I agree, I am seeing the same just using simple SHT1x sensor. Everything was fine until the recent updates. Is it possible that ESPhome core code is not running efficiently as it should?
I know that warnings have been turned on in the code recently, however, we shouldn't be seeing this all the time. If I get time I'd have a closer look, but day job takes all my time at the moment.
Hi @jesserockz, I prepared two examples to show that there are maybe some issues to be addressed in ESPHome and not always the components fault (aka 'they are doing too much processing').
Slow Sensor operations
When a component has multiple sensors it is very hard to stay within the 20-30ms limit. This example shows that 7 sensors produce the warning as they use ~50ms (~7ms per sensor). This is without any network connection and potential issues caused by it. [Update] Just checked and the issue is the same as number 2 - synchronized logger. When removing the log statements inside the sensor everything is fine.
esphome: name: multiple_sensors esp32: board: esp32dev logger: interval: - interval: 1s then: lambda: |- id(sensor01).publish_state(42.0); id(sensor02).publish_state(42.0); id(sensor03).publish_state(42.0); id(sensor04).publish_state(42.0); id(sensor05).publish_state(42.0); id(sensor06).publish_state(42.0); id(sensor07).publish_state(42.0); sensor: - platform: template id: sensor01 - platform: template id: sensor02 - platform: template id: sensor03 - platform: template id: sensor04 - platform: template id: sensor05 - platform: template id: sensor06 - platform: template id: sensor07
[D][sensor:094]: 'sensor01': Sending state 42.00000 with 1 decimals of accuracy [D][sensor:094]: 'sensor02': Sending state 42.00000 with 1 decimals of accuracy [D][sensor:094]: 'sensor03': Sending state 42.00000 with 1 decimals of accuracy [D][sensor:094]: 'sensor04': Sending state 42.00000 with 1 decimals of accuracy [D][sensor:094]: 'sensor05': Sending state 42.00000 with 1 decimals of accuracy [D][sensor:094]: 'sensor06': Sending state 42.00000 with 1 decimals of accuracy [D][sensor:094]: 'sensor07': Sending state 42.00000 with 1 decimals of accuracy [W][component:204]: Component interval (update) took a long time for an operation (0.05 s). [W][component:205]: Components should block for at most 20-30ms.
Synchronized logger
The log writing operations are running synchronized with the component. This is an issue when logging much or when the log is written to network (API or MQTT). This has caused me a lot of grief when I was writing a timing critical component.
esphome: name: slow_logger esp32: board: esp32dev logger: baud_rate: 9600 interval: - interval: 1s then: lambda: |- ESP_LOGI("Test", "This is a short message via a slow connection. To show the issue of slow components."); ESP_LOGI("Test", "The same is true for fast connection and lots of messages."); ESP_LOGI("Test", "Especially problematic when writing timing critical components.");
[I][Test:014]: This is a short message via a slow connection. To show the issue of slow components. [I][Test:015]: The same is true for fast connection and lots of messages. [I][Test:016]: Especially problematic when writing timing critical components. [W][component:204]: Component interval (update) took a long time for an operation (0.25 s). [W][component:205]: Components should block for at most 20-30ms.
Mitigation for slow synchronized logger
I was able to mitigate the issue for local (serial) log by increasing the
baud_rate
of the logger to 2Mbitbaud_rate: 2000000
. This is far from perfect but a bit better.
Great, this post is a solution for me, thanks: "looger baud_rate: 2000000" on switching stopped Sonoff dual v1.6 restarting after 20 minutes.
same issue on 1 of 3 sonoff pow 3 I have here, Strange thing is, I've installed the binary on another sonoff pow 3 and it's software related, issue is persistent where ever the binary is installed on. There's not much more than the component cse7766 on it, ESP32 should be dealing this with ease. Log says
[21:51:34][D][api:102]: Accepted 192.168.1.6 [21:51:34][W][component:204]: Component api took a long time for an operation (0.05 s). [21:51:34][W][component:205]: Components should block for at most 20-30ms. [21:51:34][D][api.connection:1031]: Home Assistant 2023.9.0 (192.168.1.6): Connected successfully [21:51:34][D][time:045]: Synchronized time: 2023-09-07 21:51:34
yaml is on https://pastebin.com/YuM1zktF
I agree, I am seeing the same just using simple SHT1x sensor. Everything was fine until the recent updates. Is it possible that ESPhome core code is not running efficiently as it should?
I know that warnings have been turned on in the code recently, however, we shouldn't be seeing this all the time. If I get time I'd have a closer look, but day job takes all my time at the moment.
Removing and adding the device from HA made the warning go away for me
same issue on 1 of 3 sonoff pow 3 I have here, Strange thing is, I've installed the binary on another sonoff pow 3 and it's software related, issue is persistent where ever the binary is installed on. There's not much more than the component cse7766 on it, ESP32 should be dealing this with ease. Log says
[21:51:34][D][api:102]: Accepted 192.168.1.6 [21:51:34][W][component:204]: Component api took a long time for an operation (0.05 s). [21:51:34][W][component:205]: Components should block for at most 20-30ms. [21:51:34][D][api.connection:1031]: Home Assistant 2023.9.0 (192.168.1.6): Connected successfully [21:51:34][D][time:045]: Synchronized time: 2023-09-07 21:51:34
yaml is on https://pastebin.com/YuM1zktF
I agree, I am seeing the same just using simple SHT1x sensor. Everything was fine until the recent updates. Is it possible that ESPhome core code is not running efficiently as it should? I know that warnings have been turned on in the code recently, however, we shouldn't be seeing this all the time. If I get time I'd have a closer look, but day job takes all my time at the moment.
Removing and adding the device from HA made the warning go away for me
hmm, not for me unfortunately, but I'm glad you solved your thing there :-)
The recent updates cause my entire set of switches working on ESP8266 + Pcf8574At failed. I could not remember but it happened 3 days ago, i tried making an update on ESPhome to all device and all failed only one remained working. They all reported I2C not found (previous version worked fine) and report log as below: [17:55:01][W][component:204]: Component api took a long time for an operation (0.28 s). [17:55:01][W][component:205]: Components should block for at most 20-30ms. [17:55:03][D][api.connection:1031]: Home Assistant 2023.9.2 (192.168.100.250): Connected successfully [17:55:03][D][api.connection:171]: Home Assistant 2023.9.2 (192.168.100.250) requested disconnected [17:55:10][D][api:102]: Accepted 192.168.100.250 Please help me with thanks!
Same issue with ESP8266 D1 Mini with various temperature and air quality sensors.
With default I2C frequency, multiple sensors were warning at 400kHz, only API and sgp4x were warning at 800kHz, only spg4x is warning
Component sgp4x.sensor took a long time for an operation (0.06 s).
Same issue with ESP8266 D1 Mini with various temperature and air quality sensors.
With default I2C frequency, multiple sensors were warning at 400kHz, only API and sgp4x were warning at 800kHz, only spg4x is warning
Component sgp4x.sensor took a long time for an operation (0.06 s).
I have the same issue with sgp41 on ESP32
[W][component:204]: Component sgp4x.sensor took a long time for an operation (0.06 s).
[W][component:205]: Components should block for at most 20-30ms.
I get this issue with pulse_counter
here my config
sensor:
# The Pulse-Sensor is initiated and used indecritly via Copy-Platform (There is no other way if you want 2 Value Pairs from one Sensor/Pin)
# Source: https://github.com/esphome/issues/issues/3364#issuecomment-1153246628
# Begin Pulse Meter Sensor
- platform: pulse_counter
pin:
number: 4
# mode: INPUT_PULLUP
id: powermeter_pulse
internal_filter: 100ms
update_interval: 60s
count_mode:
falling_edge: INCREMENT # increment here due to 'internal filter', see esphome.io
rising_edge: DISABLE
total:
id: powermeter_total
OK, according to https://github.com/esphome/esphome/pull/5373 this all is related to delays and time outs on the logger component. PR 5373 will implement queing which will fix this, hopefully soon.
For all who don't want to wait, there is (brutal) work around that worked for me as an intermediate thing: Set log level to NONE and your sensors will send data to HA again
logger:
level: NONE
Screen seem to work just fine, but the logs are invaded by this "Component ssd1306_base took a long time for an operation" message.
substitutions: name: test1 friendly_name: test1
esphome: name: ${name} platform: ESP8266 board: d1_mini_pro friendly_name: ${friendly_name}
logger: baud_rate: 0 esp8266_store_log_strings_in_flash: false
ota:
wifi: ssid: !secret wifi_ssid password: !secret wifi_password
captive_portal:
mqtt: broker: !secret mqtt_host port: !secret mqtt_port username: !secret mqtt_username password: !secret mqtt_password id: test1
spi: force_sw: true clk_pin: 14 mosi_pin: 13
font:
display:
[23:56:28][I][mqtt:289]: MQTT Connected! [23:56:28][I][app:062]: setup() finished successfully! [23:56:28][W][component:204]: Component ssd1306_base took a long time for an operation (0.07 s). [23:56:28][W][component:205]: Components should block for at most 20-30ms. [23:56:28][I][app:102]: ESPHome version 2023.8.3 compiled on Sep 18 2023, 23:55:03
[23:56:28][C][wifi:379]: Local MAC: xxxxxxxxxxx [23:56:28][C][wifi:380]: SSID: [redacted] [23:56:28][C][wifi:381]: IP Address: xxx.xxx.xxx.xxx [23:56:28][C][wifi:382]: BSSID: [redacted]
[23:56:28][C][wifi:386]: Signal strength: -68 dB ▂▄▆█ [23:56:28][C][wifi:390]: Channel: 7 [23:56:28][C][wifi:391]: Subnet: 255.255.255.0 [23:56:28][C][wifi:392]: Gateway: xxx.xxx.xxx.xxx [23:56:28][C][wifi:393]: DNS1: xxx.xxx.xxx.xxx [23:56:28][C][wifi:394]: DNS2: xxx.xxx.xxx.xxx
[23:56:28][C][logger:302]: Level: DEBUG [23:56:28][C][logger:303]: Log Baud Rate: 0 [23:56:28][C][logger:305]: Hardware UART: UART0 [23:56:28][C][spi:125]: SPI bus: [23:56:28][C][spi:126]: CLK Pin: GPIO14 [23:56:28][C][spi:128]: MOSI Pin: GPIO13 [23:56:28][C][spi:130]: Using HW SPI: NO [23:56:28][C][ssd1306_spi:019]: SPI SSD1306 [23:56:28][C][ssd1306_spi:019]: Rotations: 0 ° [23:56:28][C][ssd1306_spi:019]: Dimensions: 128px x 64px [23:56:28][C][ssd1306_spi:020]: Model: SSD1306 128x64 [23:56:28][C][ssd1306_spi:021]: CS Pin: GPIO15 [23:56:28][C][ssd1306_spi:022]: DC Pin: GPIO0 [23:56:28][C][ssd1306_spi:023]: Reset Pin: GPIO2 [23:56:28][C][ssd1306_spi:024]: External VCC: NO [23:56:28][C][ssd1306_spi:025]: Flip X: YES [23:56:28][C][ssd1306_spi:026]: Flip Y: YES [23:56:28][C][ssd1306_spi:027]: Offset X: 0 [23:56:28][C][ssd1306_spi:028]: Offset Y: 0 [23:56:28][C][ssd1306_spi:029]: Inverted Color: NO [23:56:28][C][ssd1306_spi:030]: Update Interval: 1.0s [23:56:28][C][captive_portal:088]: Captive Portal:
[23:56:28][C][mdns:113]: Hostname: test1 [23:56:28][C][ota:093]: Over-The-Air Updates: [23:56:28][C][ota:094]: Address: test1.local:8266
[23:56:28][C][mqtt:131]: Server Address: xxx.xxx.xxx.xxx:1886 (xxx.xxx.xxx.xxx) [23:56:28][C][mqtt:133]: Username: [redacted] [23:56:28][C][mqtt:134]: Client ID: [redacted] [23:56:28][C][mqtt:136]: Discovery prefix: 'xxxxxxxx' [23:56:28][C][mqtt:137]: Discovery retain: YES [23:56:28][C][mqtt:139]: Topic Prefix: 'test1' [23:56:28][C][mqtt:141]: Log Topic: 'test1/debug'
[23:56:29][W][component:204]: Component ssd1306_base took a long time for an operation (0.07 s). [23:56:29][W][component:205]: Components should block for at most 20-30ms. [23:56:30][W][component:204]: Component ssd1306_base took a long time for an operation (0.07 s). [23:56:30][W][component:205]: Components should block for at most 20-30ms. [23:56:31][W][component:204]: Component ssd1306_base took a long time for an operation (0.07 s). [23:56:31][W][component:205]: Components should block for at most 20-30ms. [23:56:32][W][component:204]: Component ssd1306_base took a long time for an operation (0.07 s). [23:56:32][W][component:205]: Components should block for at most 20-30ms.
happening with default config https://devices.esphome.io/devices/Sonoff-POW-Elite-20a
20:19:37 [W] [component:204] Component cse7766.sensor took a long time for an operation (0.05 s).
20:19:37 [W] [component:205] Components should block for at most 20-30ms.
Same problem with modbus There's no way the modbus module can get through its tasks in "20-30ms" I think we need a setting to extend this time for slow sensors.
I didn't need the
logger:
level: NONE
as the config below still sends data...
esphome:
name: genvex
friendly_name: Genvex
esp8266:
board: d1_mini
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
ota:
password: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
wifi:
ssid: !secret office_ssid
password: !secret office_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Genvex Fallback Hotspot"
password: "xxxxxxxxxxxxx"
captive_portal:
packages:
remote_package:
url: https://github.com/heinekmadsen/esphome_components
ref: main
files: [components/genvexv2/optima250.yaml]
refresh: 0s
uart:
- id: uart_genvex
rx_pin: D1
tx_pin: D2
parity: EVEN
baud_rate: 19200
stop_bits: 1
modbus:
- id: genvex_modbus
uart_id: uart_genvex
modbus_controller:
id: genvex_modbus_controller
address: 1
modbus_id: genvex_modbus
update_interval: 60s
command_throttle: 10ms
log - error at end (14:47:51)
[14:47:37][C][logger:301]: Logger:
[14:47:37][C][logger:302]: Level: DEBUG
[14:47:37][C][logger:303]: Log Baud Rate: 115200
[14:47:37][C][logger:305]: Hardware UART: UART0
[14:47:37][C][uart.arduino_esp8266:102]: UART Bus:
[14:47:37][C][uart.arduino_esp8266:103]: TX Pin: GPIO4
[14:47:37][C][uart.arduino_esp8266:104]: RX Pin: GPIO5
[14:47:37][C][uart.arduino_esp8266:106]: RX Buffer Size: 256
[14:47:37][C][uart.arduino_esp8266:108]: Baud Rate: 19200 baud
[14:47:37][C][uart.arduino_esp8266:109]: Data Bits: 8
[14:47:37][C][uart.arduino_esp8266:110]: Parity: EVEN
[14:47:37][C][uart.arduino_esp8266:111]: Stop bits: 1
[14:47:37][C][uart.arduino_esp8266:115]: Using software serial
[14:47:37][C][modbus:143]: Modbus:
[14:47:37][C][modbus:145]: Send Wait Time: 250 ms
[14:47:37][C][modbus:146]: CRC Disabled: NO
[14:47:37][C][template.sensor:022]: Template Sensor 'Genvex Virkningsgrad'
[14:47:37][C][template.sensor:022]: State Class: 'measurement'
[14:47:37][C][template.sensor:022]: Unit of Measurement: ''
[14:47:37][C][template.sensor:022]: Accuracy Decimals: 1
[14:47:37][C][template.sensor:023]: Update Interval: 60.0s
[14:47:37][C][template.text_sensor:020]: Template Sensor 'Genvex Air Quality Index Humidity (AQI)'
[14:47:37][C][template.text_sensor:020]: Icon: 'mdi:water-percent'
[14:47:37][C][modbus.number:083]: modbus.numberModbus Number 'Genvex target temp'
[14:47:37][C][modbus.number:083]: modbus.numberModbus Number 'Genvex Ventilation speed'
[14:47:37][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex temp t1'
[14:47:37][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'temperature'
[14:47:37][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:37][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '°C'
[14:47:37][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex temp t3'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'temperature'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '°C'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex temp t4'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'temperature'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '°C'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex temp t7'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'temperature'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '°C'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex temp t2 panel'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'temperature'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '°C'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex Messured Humidity'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Device Class: 'humidity'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '%'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 1
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex inlet fan'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '%'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex extract fan'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '%'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex bypass'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '%'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex watervalve'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '%'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensorModbus Controller Sensor 'Genvex humidity fan control'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor State Class: ''
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Unit of Measurement: '%'
[14:47:38][C][modbus_controller.sensor:010]: modbus_controller.sensor Accuracy Decimals: 0
[14:47:38][C][modbus_controller.text_sensor:012]: Modbus Controller Text Sensor 'Genvex Alarm'
[14:47:38][C][modbus_controller.binary_sensor:009]: Modbus Controller Binary Sensor 'Genvex bypass onoff'
[14:47:38][C][status:034]: Status Binary Sensor 'Genvex Controller Status'
[14:47:38][C][status:034]: Device Class: 'connectivity'
[14:47:38][C][genvexv2.climate:133]: Genvexv2 Climate 'Genvex'
[14:47:38][C][modbus_controller:275]: ModbusController:
[14:47:38][C][modbus_controller:276]: Address: 0x01
[14:47:38][C][captive_portal:088]: Captive Portal:
[14:47:38][C][mdns:112]: mDNS:
[14:47:38][C][mdns:113]: Hostname: genvex
[14:47:38][C][ota:093]: Over-The-Air Updates:
[14:47:38][C][ota:094]: Address: genvex.local:8266
[14:47:38][C][ota:097]: Using Password.
[14:47:38][C][api:138]: API Server:
[14:47:38][C][api:139]: Address: genvex.local:6053
[14:47:38][C][api:141]: Using noise encryption: YES
[14:47:51][D][api:102]: Accepted 192.168.1.142
[14:47:51][W][component:204]: Component api took a long time for an operation (0.29 s).
[14:47:51][W][component:205]: Components should block for at most 20-30ms.
I think we need a setting to extend this time for slow sensors.
I like this idea and suggest going a little further:
(One thing which makes this setting more complicated: In my case I have the air quality sensor which actually gives multiple values simultaneously. If I have enabled only a few I get the data in under 30ms and no errors. If I enable all of them I get the error every time.)
I dont think the problem is because the sensors are slow. I have an esp32 natively processing CAN frames. I know it is super fast. But I get this error message all the time. There is something deeper than this.
I get the same repeating problem for an hlw8012 energy sensor (Shelly Plus 1PM UL):
Component hlw8012.sensor took a long time for an operation
@Robifz I dont think the problem is because the sensors are slow.
You might be right, I notice the message says
Component api took a long time for an operation (0.29 s).
I did not notice the word api
in there.
Isn't that HA accessing the ESPHome device ("component"?) rather than the device accessing its sensors?
I think we need a setting to extend this time for slow sensors.
I like this idea and suggest going a little further:
- A setting for slow sensors
- The ability for the sensor maintainer to indicate that a particular sensor needs the extra time (essentially let them set a default for the slow sensor so that users do not have to manually add it to avoid log reports)
- An indication to the end users to tell them that a certain slow sensor cannot be used with high refresh times (an extreme example, but the user would benefit from knowing that a sensor which takes 30s cannot be used with an update interval of less than 30)
(One thing which makes this setting more complicated: In my case I have the air quality sensor which actually gives multiple values simultaneously. If I have enabled only a few I get the data in under 30ms and no errors. If I enable all of them I get the error every time.)
It's possible to rewrite most components to avoid blocking the loop, i've rewriten an uart component ( which i suspect your air quality sensor is ) to reach that goal. The problem would be to change the update() logic for those components, the update should publish / trigger a sensor read ( one action only )
And here, basically we have two choices:
This is, I think the goal of this warning, along side having less people reporting freezing issues. It's even possible to implement this logic for display lambda updates although it's extremely tedious to do.
I'm getting this for home assistant integration control over esphome devices
23:01:08 | [W] | [api.connection:117] | Home Assistant 2023.9.3 (192.168.3.1) didn't respond to ping request in time. Disconnecting...
-- | -- | -- | --
23:01:08 | [D] | [api:102] | Accepted 192.168.3.1
23:01:08 | [W] | [component:204] | Component api took a long time for an operation (0.20 s).
23:01:08 | [W] | [component:205] | Components should block for at most 20-30ms.
23:01:08 | [D] | [api.connection:1031] | Home Assistant 2023.9.3 (192.168.3.1): Connected successfully
23:03:39 | [W] | [api.connection:117] | Home Assistant 2023.9.3 (192.168.3.1) didn't respond to ping request in time. Disconnecting...
23:03:39 | [D] | [api:102] | Accepted 192.168.3.1
23:03:39 | [W] | [component:204] | Component api took a long time for an operation (0.20 s).
23:03:39 | [W] | [component:205] | Components should block for at most 20-30ms.
23:03:39 | [D] | [api.connection:1031] | Home Assistant 2023.9.3 (192.168.3.1): Connected successfully
It seems like I lose control of the device when the connect drops.
I get this for pulse_counter and sml. It also reboots randomly, reset cause 4 (hw watchdog).
I get this using a ADS1115
I also have the same issue with the sm300d2 sensor
Same here with an esp32 d1 mini and Infrared transmitter
I also have the ### same issue with ESP8266 and ESP32 with ### uart and SML
The problem:
Log from ESP32
08:51:34 | [W] | [component:214] | **Component sml** took a long time for an operation (0.51 s). -- | -- | -- | -- 08:51:34 | [W] | [component:215] | Components should block for at most 20-30ms. 08:51:34 | [D] | [uart_debug:114] | <<< A9 08:51:34 | [W] | [component:214] | **Component uart** took a long time for an operation (0.14 s). 08:51:34 | [W] | [component:215] | Components should block for at most 20-30ms. 08:51:35 | [D] | [uart_debug:114] | <<< A9 08:51:36 | [D] | [uart_debug:114] | <<< 0A 08:51:36 | [W] | [component:214] | Component sml took a long time for an operation (1.04 s). 08:51:36 | [W] | [component:215] | Components should block for at most 20-30ms. 08:51:36 | [D] | [uart_debug:114] | <<< A9 08:51:36 | [W] | [component:214] | Component uart took a long time for an operation (0.26 s). 08:51:36 | [W] | [component:215] | Components should block for at most 20-30ms. 08:51:37 | [D] | [uart_debug:114] | <<< A9 08:51:38 | [D] | [uart_debug:114] | <<< AA 08:51:38 | [W] | [component:214] | Component sml took a long time for an operation (1.04 s). 08:51:38 | [W] | [component:215] | Components should block for at most 20-30ms. 08:51:38 | [D] | [uart_debug:114] | <<< 30 08:51:38 | [W] | [component:214] | Component uart took a long time for an operation (0.26 s). 08:51:38 | [W] | [component:215] | Components should block for at most 20-30ms. 08:51:39 | [D] | [uart_debug:114] | <<< 30 08:51:40 | [D] | [uart_debug:114] | <<< 2E LOGLEVEL DEBUG ### **Which version of ESPHome has the issue?** esphome-2023.9.3 with ESP8266 tested and 2023.10.0-dev with ESP32 tested **Can I hide this message?** No **Is it expected?** Nothing works... ### **Config:** ``` esphome: name: waermepumpe esp32: board: nodemcu-32s #restore_from_flash: False substitutions: wifi_fast_connect: "false" wifi_reboot_timeout: 0s accuracy: "2" time: - platform: sntp id: sntp_time timezone: Europe/Berlin # Enable logging logger: baud_rate: 0 level: DEBUG #esp32_store_log_strings_in_flash: False # Enable Home Assistant API api: password: "" ota: password: "" wifi: ssid: "###" password: "###" reboot_timeout: $wifi_reboot_timeout power_save_mode: none fast_connect: $wifi_fast_connect # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Waermepumpe Fallback Hotspot" password: "enxf6G8rl9ur" web_server: port: 80 captive_portal: null uart: - id: meter_in rx_pin: number: RX inverted: false mode: input: true pullup: false tx_pin: number: TX baud_rate: 9600 data_bits: 8 parity: NONE stop_bits: 1 rx_buffer_size: 512 debug: direction: RX after: timeout: 250ms bytes: 512 sequence: - uart.write: !lambda return bytes; - lambda: UARTDebug::log_hex(direction, bytes, 0); sml: - id: sml0 uart_id: meter_in sensor: - platform: sml name: "powerConsumeCurrent" id: "powerConsumeCurrent" sml_id: sml0 obis_code: "1-0:16.7.0" unit_of_measurement: W accuracy_decimals: 0 device_class: energy filters: - multiply: 1 - platform: sml name: "powerConsumeCurrentPhase1" id: "powerConsumeCurrentPhase1" sml_id: sml0 obis_code: "1-0:36.7.0" unit_of_measurement: W accuracy_decimals: 0 device_class: energy filters: - multiply: 1 - platform: sml name: "powerConsumeCurrentPhase2" id: "powerConsumeCurrentPhase2" sml_id: sml0 obis_code: "1-0:56.7.0" unit_of_measurement: W accuracy_decimals: 0 device_class: energy filters: - multiply: 1 - platform: sml name: "powerConsumeCurrentPhase3" id: "powerConsumeCurrentPhase3" sml_id: sml0 obis_code: "1-0:76.7.0" unit_of_measurement: W accuracy_decimals: 0 device_class: energy filters: - multiply: 1 - platform: sml name: "powerConsumeCounter" id: "powerConsumeCounter" sml_id: sml0 obis_code: "1-0:1.8.0" unit_of_measurement: Wh accuracy_decimals: 1 device_class: energy filters: - multiply: 0.1 - platform: sml name: "powerDeliverCounter" id: "powerDeliverCounter" sml_id: sml0 obis_code: "1-0:2.8.0" unit_of_measurement: Wh accuracy_decimals: 1 device_class: energy filters: - multiply: 0.1 ``` ![esphome_tooklongtimeissue_UART_SML](https://github.com/esphome/issues/assets/91227505/e3c1b95f-1292-4aeb-adc9-6b7d54d92423)Same here...
Log:
[12:13:06][W][component:204]: Component mhz19.sensor took a long time for an operation (0.05 s).
[12:13:06][W][component:205]: Components should block for at most 20-30ms.
[12:13:08][W][component:204]: Component lcd_base took a long time for an operation (0.49 s).
[12:13:08][W][component:205]: Components should block for at most 20-30ms.
Config excerpts
uart:
rx_pin: GPIO16
tx_pin: GPIO17
baud_rate: 9600
sensor:
- platform: mhz19
co2:
name: "MH-Z19 CO2"
unit_of_measurement: "ppm"
device_class: "carbon_dioxide"
state_class: "measurement"
id: co2val
temperature:
name: "MH-Z19 Temperature"
unit_of_measurement: "°C"
device_class: "temperature"
state_class: "measurement"
accuracy_decimals: 1
update_interval: 60s
automatic_baseline_calibration: false
id: sens1
display:
- platform: lcd_pcf8574
dimensions: 20x4
address: 0x27
update_interval: 5s
lambda: |-
it.printf(0, 0, "%.1fC %.0f%% %.0fppm", id(dhttemp).state, id(dhthum).state, id(co2val).state);
I wonder if this issue is being monitored by a developer. There has been no comment or update from anybody else than victims.
This will hide the message. I'm pretty sure this is working how the dev wants it to. It's super annoying and hiding the message should not be the answer but you get what you get with free software.
logger
level: DEBUG
logs:
component: ERROR
I dont think suppressing an error by setting a different log level is the proper way of handling bugs ;)
I agree 100%, but it is what it is.
Add to the bug repot, hide the error, and stop chasing your tail. I threw 2 days at it.
I copied the new files from the "maybe fix" (logger queue) into a local "venv" envirement with Version: 2023.10.0-dev and compile my config with "log_queue_length: 12" . The compiling task is working. But the result is still the old issue.
https://github.com/esphome/esphome/pull/5373
https://github.com/esphome/esphome/pull/5373#issuecomment-1755267673
new config:
esphome:
name: waermepumpe
esp32:
board: nodemcu-32s
#restore_from_flash: False
substitutions:
wifi_fast_connect: "false"
wifi_reboot_timeout: 0s
accuracy: "2"
time:
- platform: sntp
id: sntp_time
timezone: Europe/Berlin
# Enable logging
logger:
baud_rate: 0
level: DEBUG
log_queue_length: 12
#esp32_store_log_strings_in_flash: False
# Enable Home Assistant API
api:
password: ""
ota:
password: ""
wifi:
ssid: "###"
password: "###"
reboot_timeout: $wifi_reboot_timeout
power_save_mode: none
fast_connect: $wifi_fast_connect
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Waermepumpe Fallback Hotspot"
password: "enxf6G8rl9ur"
web_server:
port: 80
captive_portal: null
uart:
- id: meter_in
rx_pin:
number: RX
inverted: false
mode:
input: true
pullup: false
tx_pin:
number: TX
baud_rate: 9600
data_bits: 8
parity: NONE
stop_bits: 1
rx_buffer_size: 512
debug:
direction: RX
after:
timeout: 250ms
bytes: 512
sequence:
- uart.write: !lambda return bytes;
- lambda: UARTDebug::log_hex(direction, bytes, 0);
sml:
- id: sml0
uart_id: meter_in
sensor:
- platform: sml
name: "powerConsumeCurrent"
id: "powerConsumeCurrent"
sml_id: sml0
obis_code: "1-0:16.7.0"
unit_of_measurement: W
accuracy_decimals: 0
device_class: energy
filters:
- multiply: 1
- platform: sml
name: "powerConsumeCurrentPhase1"
id: "powerConsumeCurrentPhase1"
sml_id: sml0
obis_code: "1-0:36.7.0"
unit_of_measurement: W
accuracy_decimals: 0
device_class: energy
filters:
- multiply: 1
- platform: sml
name: "powerConsumeCurrentPhase2"
id: "powerConsumeCurrentPhase2"
sml_id: sml0
obis_code: "1-0:56.7.0"
unit_of_measurement: W
accuracy_decimals: 0
device_class: energy
filters:
- multiply: 1
- platform: sml
name: "powerConsumeCurrentPhase3"
id: "powerConsumeCurrentPhase3"
sml_id: sml0
obis_code: "1-0:76.7.0"
unit_of_measurement: W
accuracy_decimals: 0
device_class: energy
filters:
- multiply: 1
- platform: sml
name: "powerConsumeCounter"
id: "powerConsumeCounter"
sml_id: sml0
obis_code: "1-0:1.8.0"
unit_of_measurement: Wh
accuracy_decimals: 1
device_class: energy
filters:
- multiply: 0.1
- platform: sml
name: "powerDeliverCounter"
id: "powerDeliverCounter"
sml_id: sml0
obis_code: "1-0:2.8.0"
unit_of_measurement: Wh
accuracy_decimals: 1
device_class: energy
filters:
- multiply: 0.1
14:14:06 | [W] | [component:215] | Components should block for at most 20-30ms.
-- | -- | -- | --
14:14:07 | [D] | [uart_debug:114] | <<< 02
14:14:07 | [W] | [component:214] | Component uart took a long time for an operation (0.38 s).
14:14:07 | [W] | [component:215] | Components should block for at most 20-30ms.
14:14:08 | [D] | [uart_debug:114] | <<< 02
14:14:08 | [D] | [uart_debug:114] | <<< 28
14:14:08 | [W] | [component:214] | Component sml took a long time for an operation (1.04 s).
14:14:08 | [W] | [component:215] | Components should block for at most 20-30ms.
14:14:09 | [D] | [uart_debug:114] | <<< 30
14:14:09 | [W] | [component:214] | Component uart took a long time for an operation (0.13 s).
14:14:09 | [W] | [component:215] | Components should block for at most 20-30ms.
14:14:10 | [D] |
esphome:
name: esp32-duco-01
platform: ESP32
board: esp32dev
libraries:
- Wire
- u-fire/uFire SHT20@^1.1.1
includes:
- custom_components/duco/sht20.h
substitutions:
esp_name: esp32-duco-01
wifi:
ssid: "wifi"
password: !secret IOTDOM_wifi_key
use_address: 192.168.6.85
domain: !secret domain
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Fallback"
password: !secret Fallback
captive_portal:
# Enable logging
logger:
level: DEBUG
# Enable Home Assistant API
api:
ota:
web_server:
port: 80
time:
- platform: homeassistant
id: homeassistant_time
#esp32_ble_tracker:
#bluetooth_proxy:
# ! Warning ! the original Duco sensor can only be connected on sensor connector 1!
#
uart:
#UART For Sensor 1
# - rx_pin: GPIO13
# tx_pin: GPIO12
# baud_rate: 9600
# id: uart_sensor_1
#UART For Sensor 2
- rx_pin: GPIO25
tx_pin: GPIO26
baud_rate: 9600
id: uart_sensor_2
i2c:
#I2C For Sensor 1
- id: i2c_sensor_1
sda: GPIO19
scl: GPIO18
scan: false
frequency: 400kHz
#I2C For Sensor 2
- id: i2c_sensor_2
sda: GPIO16
scl: GPIO4
scan: false
frequency: 400kHz
# Status led
status_led:
pin:
number: GPIO33
#PWM output for controlling the motor.
output:
- platform: ledc
pin: GPIO15
inverted: true
id: open_air_mini
fan:
- platform: speed
output: open_air_mini
name: "${esp_name} - Fan"
id: ducofan
sensor:
- <<: !include includes/include-wifi-signal.yaml
- <<: !include includes/include-uptime-config.yaml
- platform: pulse_counter
pin: GPIO14
unit_of_measurement: 'RPM'
name: '${esp_name} - RPM'
# SENSOR CONNECTOR 1 - original Duco sensor connected on sensor connector 1!
- platform: custom
lambda: |-
auto sht20 = new SHT20();
App.register_component(sht20);
return {sht20->temperature_sensor, sht20->humidity_sensor, sht20->vpd_sensor, sht20->dew_point_sensor};
sensors:
- name: T
internal: True
id: sensor_temperature
accuracy_decimals: 2
- name: H
id: sensor_humidity
accuracy_decimals: 2
internal: True
on_value_range:
- below: 65
then:
- if:
condition:
switch.is_on: ducoauto
then:
- fan.turn_on:
id: ducofan
speed: 10
- above: 65
below: 70
then:
- if:
condition:
switch.is_on: ducoauto
then:
- fan.turn_on:
id: ducofan
speed: 20
- above: 70
below: 75
then:
- if:
condition:
switch.is_on: ducoauto
then:
- fan.turn_on:
id: ducofan
speed: 40
- above: 75
below: 80
then:
- if:
condition:
switch.is_on: ducoauto
then:
- fan.turn_on:
id: ducofan
speed: 60
- above: 80
below: 85
then:
- if:
condition:
switch.is_on: ducoauto
then:
- fan.turn_on:
id: ducofan
speed: 75
- above: 85
below: 90
then:
- if:
condition:
switch.is_on: ducoauto
then:
- fan.turn_on:
id: ducofan
speed: 85
- above: 90
then:
- if:
condition:
switch.is_on: ducoauto
then:
- fan.turn_on:
id: ducofan
speed: 100
- name: VPD
id: sensor_vpd
accuracy_decimals: 2
internal: True
- name: DP
id: sensor_dew_point
accuracy_decimals: 2
internal: True
# SENSOR CONNECTOR 2 - Combination of Senseair S8 & SHT-31 in one Sensor
- platform: sht3xd
i2c_id: i2c_sensor_2
temperature:
name: "${esp_name} - Sensor 2 - Temperature"
humidity:
name: "${esp_name} - Sensor 2 - Humidity"
icon: mdi:water-percent
address: 0x44
update_interval: 30s
- platform: senseair
uart_id: uart_sensor_2
#add sensor UART bus here
co2:
name: "${esp_name} - Sensor 2 - CO2"
update_interval: 30s
- platform: template
name: "${esp_name} - Fan Speed"
lambda: return id(ducofan).speed;
update_interval: 3s
unit_of_measurement: "%"
accuracy_decimals: 0
icon: mdi:fan
- platform: copy
name: "${esp_name} - Sensor 1 - Temperature"
unit_of_measurement: °C
accuracy_decimals: 2
source_id: sensor_temperature
filters:
- throttle: 60s
- platform: copy
name: "${esp_name} - Sensor 1 - Humidity"
unit_of_measurement: "%"
accuracy_decimals: 2
icon: mdi:water-percent
source_id: sensor_humidity
filters:
- throttle: 60s
- platform: copy
name: "${esp_name} - Sensor 1 - Vapour-pressure deficit"
unit_of_measurement: "kPa"
accuracy_decimals: 2
icon: mdi:air-humidifier
source_id: sensor_vpd
filters:
- throttle: 60s
- platform: copy
name: "${esp_name} - Sensor 1 - Dew point"
unit_of_measurement: °C
accuracy_decimals: 2
icon: mdi:water-thermometer-outline
source_id: sensor_dew_point
filters:
- throttle: 60s
text_sensor:
- <<: !include includes/include-uptime-human.yaml
- <<: !include includes/include-esphome-version.yaml
- <<: !include includes/include-wifi-info.yaml
switch:
- <<: !include includes/include-generic-restart-switch.yaml
- platform: template
name: "${esp_name} - Automatisch"
id: ducoauto
optimistic : True
#restore_state: yes
restore_mode: RESTORE_DEFAULT_ON
icon: mdi:fan-auto
#https://github.com/Flamingo-tech/Open-AIR/tree/main/Open%20Air%20Mini/Software
Hi @OttoWinter
Are you able to prioritise your review of https://github.com/esphome/esphome/pull/5373 ? This issue is affecting a large number of people (possibly everyone), and it would be good to get this likely fix merged.
Thanks.
hello i have the same problem with à sps30 i am on a d1 mini esp8266 if i pass on a esp32 can i solve the problem ?
Jacques
You might want to try English if you want your issue to be solved 😏
I get this error when including the st7789v in the M5StickC Plus.
[22:29:15][W][component:214]: Component st7789v.display took a long time for an operation (0.12 s).
[22:29:15][W][component:215]: Components should block for at most 20-30ms.
config excerpt:
spi:
clk_pin: GPIO13
mosi_pin: GPIO15
display:
- platform: st7789v
model: TTGO TDisplay 135x240
# backlight_pin: LDO2
cs_pin: GPIO5
dc_pin: GPIO23
reset_pin: GPIO18
rotation: 0
lambda: |-
float brightness=0.5;
// Splash display
it.printf(67, 5, id(testfont), TextAlign::TOP_CENTER, "%.1f%%", id(m5stick_battery).state);
// Update display brightness
id(pmu).set_brightness(brightness);
id(pmu).update();
font:
- file: "gfonts://Roboto"
id: testfont
size: 20
This is not an "error", this is a "warning". 😉
I have the following sensors which are giving the warning.
DHT20
i2c:
sda: 6
scl: 7
sensor:
- platform: aht10
temperature:
name: "Temperature"
humidity:
name: "Humidity"
[10:27:16][W][component:214]: Component aht10.sensor took a long time for an operation (0.07 s).
[10:27:16][W][component:215]: Components should block for at most 20-30ms.
SPG41
i2c:
sda: 6
scl: 7
sensor:
- platform: sgp4x
voc:
id: "voc_index"
name: "VOC Index"
nox:
id: "nox_index"
name: "NOx Index"
update_interval: 30s
text_sensor:
- platform: template
name: "VOC Classification"
icon: "mdi:checkbox-marked-circle-outline"
lambda: |-
if (int(id(voc_index).state) <= 50) {
return {"Good"};
}
else if (int(id(voc_index).state) <= 100) {
return {"Moderate"};
}
else if (int(id(voc_index).state) <= 150) {
return {"High"};
}
else if (int(id(voc_index).state) <= 500) {
return {"Very high"};
}
else {
return {"unknown"};
}
- platform: template
name: "NOx Classification"
icon: "mdi:checkbox-marked-circle-outline"
lambda: |-
if (int(id(nox_index).state) == 1) {
return {"None"};
}
else if (int(id(nox_index).state) <= 80) {
return {"Low"};
}
else if (int(id(nox_index).state) <= 168) {
return {"Moderate"};
}
else if (int(id(nox_index).state) <= 270) {
return {"High"};
}
else if (int(id(nox_index).state) <= 500) {
return {"Very high"};
}
else {
return {"unknown"};
}
[10:21:37][W][component:214]: Component sgp4x.sensor took a long time for an operation (0.06 s).
[10:21:37][W][component:215]: Components should block for at most 20-30ms.
All my devices are affected by this "warning" :( Is there a way to solve this? Without changing the logging level?
Hm... changing the logging level is like you'd wipe water on the floor continously instead of closing the valve and stop it from flowing... It's not tons of messages problem, the problem is that because of a bug (or something...) most things (if not all) takes too long to execute, thus slowing down whole ESP module. It's a global problem, so i guess that developers should dig into it.
I have same issue here with INA3321. I have tried adding frequency: 400kHz but the issue persists:
Dont think it makes any difference but I'm using ESP32-C6 with dev firmware.
esp32:
board: "esp32-c6-devkitc-1"
variant: "ESP32C6"
framework:
platform_version: https://github.com/stintel/platform-espressif32#esp32-c6-test
#platform_version: https://github.com/platformio/platform-espressif32.git
type: esp-idf
version: 5.1.0
i2c:
# i2c internal bus for INA3221 and other optional devices
- id: i2c_internal
sda: 2
scl: 3
scan: true
frequency: 400kHz
sensor:
# Internal INA3221 Power Monitoring
- platform: ina3221
i2c_id: i2c_internal
address: 0x40
# CH1 Power Monitoring
channel_1:
shunt_resistance: 0.015 ohm
current:
name: ${friendly_name} CH1 Current
id: current1
power:
name: ${friendly_name} CH1 Power
id: power1
bus_voltage:
name: ${friendly_name} CH1 Bus Voltage
id: voltage1
shunt_voltage:
name: ${friendly_name} CH1 Shunt Voltage
id: shunt_voltage1
unit_of_measurement: "mV"
# Core Power Monitoring
channel_2:
shunt_resistance: 0.15 ohm
current:
name: ${friendly_name} Core Current
id: current
power:
name: ${friendly_name} Core Power
id: power
bus_voltage:
name: ${friendly_name} Core Bus Voltage
id: voltage
shunt_voltage:
name: ${friendly_name} Core Shunt Voltage
id: shunt_voltage
unit_of_measurement: "mV"
Is there any guidance for developers on how to make things go fast enough to avoid these messages? I want my code to run as fast as possible of course, but I'm not sure how certain chips can be made to go faster than they already are. For example reading registers takes a certain amount of time defined by the chip's datasheet. There's nothing I can do from a software standpoint to make it speed up. The chip has to have time to pull data pins high and low as necessary after receiving a clock pulse. Then the data line must be read, and the cycle repeats until all bits are read. The chip just runs at the speed it was designed to run and it's literally an "it takes as long as it takes" kind of situation. If you try to read the output too fast, then you get bad data. Isn't that worse than waiting for the good data to arrive? I suppose we could store partial results in a variable somewhere, then let the main loop continue to run and get the rest of the data on the next cycle, but that seems like it would take more memory due to increased code complexity, more processing power, and more time than simply waiting for the chip to do its thing before moving on. If I am missing something, please feel free to provide correction. I am genuinely curious as to how we should proceed.
Hm... changing the logging level is like you'd wipe water on the floor continuously instead of closing the valve and stop it from flowing... It's not tons of messages problem, the problem is that because of a bug (or something...) most things (if not all) takes too long to execute, thus slowing down whole ESP module. It's a global problem, so i guess that developers should dig into it.
So if this is indeed the case. Is anybody picking this up? It's here since 2023.7 and we're on 2023.10 now. I'm pretty sure I'm impacted by it as well with the ventilation custom component I use, see here https://github.com/esphome/issues/issues/4715
What I don't understand from your post, is a generic ESPHome bug assumed causing the delay and triggering the warnings? Or is this all in each component's individual's code?
@spudje you're misunderstanding this. Nothing has changed in the components or esphome other than the log level of the message. These delays were already there, but you would only see the message if you used verbose logging level. This didn't change anything to do with the components themselves.
Hm... that's interesting.. when i was testing PN532 RFID card reader it was quite obvious that these messages are causing a delay in reading, because card was read instantly sometimes when readout was done between two warnings, but with delay when these messages appear during readout process. On the other hand RC522 reads fine no matter what. But, since i'd like to read special info from card also i need PN532, RC522 only reads serial number. (But, since the flood in my workshop my plans are somewhat on a stale anyway...)
Do not report new issues related to this message, instead please comment on this issue with the logs that you see and the config for that component.
The problem
These 2 log lines may show up in the most recent version of ESPHome due to the log level being changed from
verbose
towarning
. I made this change because changing the device log level to verbose just to see if these lines show up significantly slowed down the device due to all the extra logging it had to do.Which version of ESPHome has the issue?
2023.7.0
Can I hide this message?
Yes you can hide the message, but it wont change the fact that the component is taking a long time.
Is it expected?
For some components this is actually expected like displays which have a lot of drawing and pixel/data moving. For the majority of sensors, it means that they are doing too much processing or waiting for responses instead of letting ESPHome get on with business until the data is ready.