Component xxxxxx took a long time for an operation

esphome / issues

Issue Tracker for ESPHome

https://esphome.io/

290 stars 34 forks source link

Component xxxxxx took a long time for an operation #4717

Open jesserockz opened 1 year ago

jesserockz commented 1 year ago

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

[00:00:00][W][component:204]: Component xxxxxx took a long time for an operation (x.xx s).
[00:00:00][W][component:205]: Components should block for at most 20-30ms.

These 2 log lines may show up in the most recent version of ESPHome due to the log level being changed from verbose to warning. 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.

logger:
  logs:
    component: ERROR

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.

aeonsablaze commented 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

Eric64124 commented 1 year ago

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]: 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:

platform: dsmr energy_delivered_tariff1: name: "Energy Consumed Tariff 1" state_class: total_increasing energy_delivered_tariff2: name: "Energy Consumed Tariff 2" state_class: total_increasing energy_returned_tariff1: name: "Energy Produced Tariff 1" state_class: total_increasing energy_returned_tariff2: name: "Energy Produced Tariff 2" state_class: total_increasing power_delivered: name: "Power Consumed" unit_of_measurement: "W" state_class: "measurement" accuracy_decimals: 0 filters:
- multiply: 1000 power_returned: name: "Power Produced" unit_of_measurement: "W" state_class: "measurement" accuracy_decimals: 0 filters:
- multiply: 1000 electricity_failures: name: "Electricity Failures" icon: mdi:alert electricity_long_failures: name: "Long Electricity Failures" icon: mdi:alert voltage_l1: name: "Voltage Phase 1" voltage_l2: name: "Voltage Phase 2" voltage_l3: name: "Voltage Phase 3" current_l1: name: "Current Phase 1" current_l2: name: "Current Phase 2" current_l3: name: "Current Phase 3" power_delivered_l1: name: "Power Consumed Phase 1" unit_of_measurement: "W" state_class: "measurement" accuracy_decimals: 0 filters:
- multiply: 1000 power_delivered_l2: name: "Power Consumed Phase 2" unit_of_measurement: "W" state_class: "measurement" accuracy_decimals: 0 filters:
- multiply: 1000 power_delivered_l3: name: "Power Consumed Phase 3" unit_of_measurement: "W" state_class: "measurement" accuracy_decimals: 0 filters:
- multiply: 1000 power_returned_l1: name: "Power Produced Phase 1" unit_of_measurement: "W" state_class: "measurement" accuracy_decimals: 0 filters:
- multiply: 1000 power_returned_l2: name: "Power Produced Phase 2" unit_of_measurement: "W" state_class: "measurement" accuracy_decimals: 0
  filters:
- multiply: 1000 power_returned_l3: name: "Power Produced Phase 3" unit_of_measurement: "W" state_class: "measurement" accuracy_decimals: 0 filters:
- multiply: 1000 gas_delivered: name: "Gas Consumed" state_class: total_increasing
platform: uptime name: "Uptime"
platform: wifi_signal name: "Wi-Fi Signal" update_interval: 60s

text_sensor:

platform: dsmr identification: name: "DSMR Identification" p1_version: name: "DSMR Version"
platform: wifi_info ip_address: name: "IP Address" ssid: name: "Wi-Fi SSID" bssid: name: "Wi-Fi BSSID"
platform: version name: "ESPHome Version" hide_timestamp: true

smarthomedesign commented 1 year ago

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.

Robifz commented 1 year ago

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", "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"); `

andilge commented 1 year ago

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

Patrick010 commented 1 year ago

[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

m0jek commented 1 year ago

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.

Himura56 commented 1 year ago

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 2Mbit baud_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.

mathgaming commented 1 year ago

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

andilge commented 1 year ago

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 :-)

paulsteigel commented 12 months ago

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!

MallocArray commented 12 months ago

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).

jjnj023 commented 12 months ago

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.

ZinnerC commented 12 months ago

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

andilge commented 12 months ago

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

mr2web commented 11 months ago

Screen seem to work just fine, but the logs are invaded by this "Component ssd1306_base took a long time for an operation" message.

config:

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:

file: "fonts/ComicSansMS3.ttf" id: my_font size: 30

display:

platform: ssd1306_spi model: "SSD1306 128x64" dc_pin: 0 cs_pin: 15 #empty pin as my display do not have the CS pin exposed, it is hard coupled to GND. reset_pin: 2 lambda: |- it.print(0, 0, id(my_font), "Hello World!");

Log:

[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.

Spirch commented 11 months ago

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.

HLFCode commented 11 months ago

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.

Joshfindit commented 11 months ago

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.)

Robifz commented 11 months ago

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.

Colorado4Wheeler commented 11 months ago

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

HLFCode commented 11 months ago

@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?

xdecock commented 11 months ago

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:

The sensor requires a nudge to send back the value over the bus:
- in update() we write the "update_me" command, we return
- in loop() we read the response and publish the requested sensors as we receive them, if the sensor requires more command for the other server, we send the command after each read(). We need a local buffer to cover those responses. And state tracking
The sensor streams value:
- in loop(): we read values and update local variables
- in update(): we publish the values we have available.

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.

TheAznShumai commented 11 months ago

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.

hamster65 commented 11 months ago

I get this for pulse_counter and sml. It also reboots randomly, reset cause 4 (hw watchdog).

tekgeek1205 commented 11 months ago

I get this using a ADS1115

fasavard commented 11 months ago

I also have the same issue with the sm300d2 sensor

M4Marc commented 11 months ago

Same here with an esp32 d1 mini and Infrared transmitter

Chriss312 commented 11 months ago

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)

TheDK commented 11 months ago

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);

Patrick010 commented 11 months ago

I wonder if this issue is being monitored by a developer. There has been no comment or update from anybody else than victims.

tekgeek1205 commented 11 months ago

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

Patrick010 commented 11 months ago

I dont think suppressing an error by setting a different log level is the proper way of handling bugs ;)

tekgeek1205 commented 11 months ago

I agree 100%, but it is what it is.

tekgeek1205 commented 11 months ago

Add to the bug repot, hide the error, and stop chasing your tail. I threw 2 days at it.

Chriss312 commented 11 months ago

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] |

sanderlv commented 11 months ago

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

NickWilton commented 11 months ago

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.

galley-dev commented 11 months ago

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

Patrick010 commented 11 months ago

You might want to try English if you want your issue to be solved 😏

WizBangCrash commented 10 months ago

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

edwardtfn commented 10 months ago

This is not an "error", this is a "warning". 😉

stevearmitage commented 10 months ago

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.

Flamingo-tech commented 10 months ago

All my devices are affected by this "warning" :( Is there a way to solve this? Without changing the logging level?

Protoncek commented 10 months ago

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.

hirsts commented 10 months ago

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"

skykingjwc commented 10 months ago

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.

spudje commented 10 months ago

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?

ssieb commented 10 months ago

@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.

Protoncek commented 10 months ago

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...)

Previous Next