search

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.

ellepdesk commented 1 year ago

For VL53l0x as well, but only after about 20 min uptime, with readings every 10s

Component vl53l0x.sensor took a long time for an operation (0.26 s)

lajuffermans commented 1 year ago

Also having a:

Component esphome.coroutine took a long time for an operation

Maybe good to know, it started when I update from 2023.6.x to 2023.7.x

hellcry37 commented 1 year ago

At this point I think it does not help anymore to say, this has the issue also. It's clear this affects everything or almost and solutions would be better.

boussouira commented 1 year ago

This happening with Athom Mini Switch using MQTT only

athom.mini-switch/debug [W][component:205]: Components should block for at most 20-30ms.

It doesn't have any sensors, just a relay and switch

Maybe good to know, it started when I update from 2023.6.x to 2023.7.x

It did happen probably before that, but this recent PR https://github.com/esphome/esphome/pull/5048 changed the log from Verbose to Warning, which made it more noticeable

descipher commented 1 year ago

@jesserockz I am observing api caused delays due to json resourse constraits that seem to be related to this issue.

From the api logging on HA of the control panel.:

[10:22:12][D][sensor:093]: 'PM1 CT1 Amps': Sending state 3.04900 A with 2 decimals of accuracy
[10:22:12][E][json:039]: Could not allocate memory for JSON document! Requested 504 bytes, largest free heap block: 504 bytes
[10:22:12][D][sensor:093]: 'PM1 CT2 Amps': Sending state 5.20600 A with 2 decimals of accuracy
[10:22:12][D][sensor:093]: 'PM1 CT1 Watts': Sending state 318.95551 W with 2 decimals of accuracy
[10:22:12][D][sensor:093]: 'PM1 CT2 Watts': Sending state 565.98108 W with 2 decimals of accuracy
[10:22:12][D][sensor:093]: 'PM1 Freq': Sending state 59.98000 Hz with 1 decimals of accuracy
[10:22:12][D][sensor:093]: 'PM1 IC Temperature': Sending state 50.00000 °C with 1 decimals of accuracy
[10:22:12][W][component:204]: Component atm90e32.sensor took a long time for an operation (0.06 s).
[10:22:12][W][component:205]: Components should block for at most 20-30ms.
[10:22:12][D][sensor:093]: 'PM1 Total Amps': Sending state 8.25500 A with 2 decimals of accuracy
[10:22:14][D][sensor:093]: 'PM1 Total Watts': Sending state 884.93658 W with 0 decimals of accuracy
[10:22:14][D][sensor:093]: 'PM1 Total kWh': Sending state 378.03922 kWh with 2 decimals of accuracy
[10:22:28][D][sensor:093]: 'PM1 Volts': Sending state 120.89000 V with 3 decimals of accuracy
[10:22:28][D][sensor:093]: 'PM1 Volts': Sending state 120.65000 V with 3 decimals of accuracy
[10:22:28][D][sensor:093]: 'PM1 CT1 Amps': Sending state 3.06700 A with 2 decimals of accuracy
[10:22:28][D][sensor:093]: 'PM1 CT2 Amps': Sending state 5.02300 A with 2 decimals of accuracy
[10:22:28][D][sensor:093]: 'PM1 CT2 Watts': Sending state 550.56226 W with 2 decimals of accuracy
[10:22:28][D][sensor:093]: 'PM1 Freq': Sending state 59.99000 Hz with 1 decimals of accuracy
[10:22:28][D][sensor:093]: 'PM1 IC Temperature': Sending state 50.00000 °C with 1 decimals of accuracy
[10:22:28][W][component:204]: Component atm90e32.sensor took a long time for an operation (0.07 s).
[10:22:28][W][component:205]: Components should block for at most 20-30ms.
[10:22:28][D][sensor:093]: 'PM1 Total Amps': Sending state 8.09000 A with 2 decimals of accuracy
[10:22:30][D][sensor:093]: 'PM1 Total Watts': Sending state 870.80286 W with 0 decimals of accuracy
[10:22:30][D][sensor:093]: 'PM1 Total kWh': Sending state 378.04282 kWh with 2 decimals of accuracy
[10:22:42][D][sensor:093]: 'PM1 Volts': Sending state 120.99000 V with 3 decimals of accuracy
[10:22:42][D][sensor:093]: 'PM1 Volts': Sending state 120.75000 V with 3 decimals of accuracy
[10:22:42][E][json:039]: Could not allocate memory for JSON document! Requested 344 bytes, largest free heap block: 344 bytes
[10:22:42][D][sensor:093]: 'PM1 CT1 Amps': Sending state 3.04000 A with 2 decimals of accuracy
[10:22:42][E][json:039]: Could not allocate memory for JSON document! Requested 344 bytes, largest free heap block: 344 bytes
[10:22:42][D][sensor:093]: 'PM1 CT2 Amps': Sending state 5.14200 A with 2 decimals of accuracy
[10:22:42][D][sensor:093]: 'PM1 Freq': Sending state 60.02000 Hz with 1 decimals of accuracy
[10:22:42][E][json:039]: Could not allocate memory for JSON document! Requested 344 bytes, largest free heap block: 344 bytes
[10:22:42][D][sensor:093]: 'PM1 IC Temperature': Sending state 50.00000 °C with 1 decimals of accuracy
[10:22:42][E][json:039]: Could not allocate memory for JSON document! Requested 344 bytes, largest free heap block: 344 bytes
[10:22:42][W][component:204]: Component atm90e32.sensor took a long time for an operation (0.06 s).
[10:22:42][W][component:205]: Components should block for at most 20-30ms.
[10:22:42][D][sensor:093]: 'PM1 Total Amps': Sending state 8.18200 A with 2 decimals of accuracy
[10:22:44][D][sensor:093]: 'PM1 Total Watts': Sending state 881.45886 W with 0 decimals of accuracy
[10:22:44][D][sensor:093]: 'PM1 Total kWh': Sending state 378.04651 kWh with 2 decimals of accuracy
[10:22:44][E][json:039]: Could not allocate memory for JSON document! Requested 344 bytes, largest free heap block: 344 bytes

These json heap errors are not present initially. Aftert a long period of logging they trigger pressure in HA and are continuous after that. These jason errors occur in both 2023.6.5 and 2023.7.0 but are much more frequent after 2023.7.0.

With a WEB server log from the device it never occurs in any version even with the . The delays are not present.

10:34:20 | [D] | [sensor:093] | 'PM1 WiFi Signal': Sending state -63.00000 dBm with 0 decimals of accuracy
10:34:21 | [D] | [sensor:093] | 'PM1 Total Amps': Sending state 9.92300 A with 2 decimals of accuracy
10:34:21 | [D] | [sensor:093] | 'PM1 Volts': Sending state 120.79000 V with 3 decimals of accuracy
10:34:21 | [D] | [sensor:093] | 'PM1 Volts': Sending state 120.54000 V with 3 decimals of accuracy
10:34:21 | [D] | [sensor:093] | 'PM1 CT1 Amps': Sending state 4.01800 A with 2 decimals of accuracy
10:34:21 | [D] | [sensor:093] | 'PM1 CT2 Amps': Sending state 5.69500 A with 2 decimals of accuracy
10:34:21 | [D] | [sensor:093] | 'PM1 CT1 Watts': Sending state 448.98462 W with 2 decimals of accuracy
10:34:21 | [D] | [sensor:093] | 'PM1 CT2 Watts': Sending state 642.62909 W with 2 decimals of accuracy
10:34:22 | [D] | [sensor:093] | 'PM1 Freq': Sending state 59.98000 Hz with 1 decimals of accuracy
10:34:22 | [D] | [sensor:093] | 'PM1 IC Temperature': Sending state 50.00000 °C with 1 decimals of accuracy
10:34:24 | [D] | [sensor:093] | 'PM1 Total Watts': Sending state 1091.61377 W with 0 decimals of accuracy
10:34:24 | [D] | [sensor:093] | 'PM1 Total kWh': Sending state 378.24594 kWh with 2 decimals of accuracy
10:34:36 | [D] | [sensor:093] | 'PM1 Total Amps': Sending state 9.71300 A with 2 decimals of accuracy
10:34:36 | [D] | [sensor:093] | 'PM1 Volts': Sending state 120.92000 V with 3 decimals of accuracy
10:34:36 | [D] | [sensor:093] | 'PM1 Volts': Sending state 120.68000 V with 3 decimals of accuracy
10:34:36 | [D] | [sensor:093] | 'PM1 CT1 Amps': Sending state 4.03000 A with 2 decimals of accuracy
10:34:36 | [D] | [sensor:093] | 'PM1 CT2 Amps': Sending state 5.93500 A with 2 decimals of accuracy
10:34:36 | [D] | [sensor:093] | 'PM1 CT1 Watts': Sending state 450.45984 W with 2 decimals of accuracy
10:34:36 | [D] | [sensor:093] | 'PM1 CT2 Watts': Sending state 672.38239 W with 2 decimals of accuracy
10:34:37 | [D] | [sensor:093] | 'PM1 Freq': Sending state 59.98000 Hz with 1 decimals of accuracy
10:34:37 | [D] | [sensor:093] | 'PM1 IC Temperature': Sending state 50.00000 °C with 1 decimals of accuracy
10:34:39 | [D] | [sensor:093] | 'PM1 Total Watts': Sending state 1122.84229 W with 0 decimals of accuracy
10:34:39 | [D] | [sensor:093] | 'PM1 Total kWh': Sending state 378.25064 kWh with 2 decimals of accuracy
10:34:51 | [D] | [sensor:093] | 'PM1 Total Amps': Sending state 9.96500 A with 2 decimals of accuracy
10:34:51 | [D] | [sensor:093] | 'PM1 Volts': Sending state 120.78000 V with 3 decimals of accuracy
10:34:51 | [D] | [sensor:093] | 'PM1 Volts': Sending state 120.54000 V with 3 decimals of accuracy
10:34:51 | [D] | [sensor:093] | 'PM1 CT1 Amps': Sending state 4.01400 A with 2 decimals of accuracy
10:34:51 | [D] | [sensor:093] | 'PM1 CT2 Amps': Sending state 4.92200 A with 2 decimals of accuracy
10:34:51 | [D] | [sensor:093] | 'PM1 CT1 Watts': Sending state 448.43774 W with 2 decimals of accuracy
10:34:51 | [D] | [sensor:093] | 'PM1 CT2 Watts': Sending state 539.46082 W with 2 decimals of accuracy
10:34:52 | [D] | [sensor:093] | 'PM1 Freq': Sending state 59.96000 Hz with 1 decimals of accuracy
10:34:52 | [D] | [sensor:093] | 'PM1 IC Temperature': Sending state 50.00000 °C with 1 decimals of accuracy
10:34:54 | [D] | [sensor:093] | 'PM1 Total Watts': Sending state 987.89856 W with 0 decimals of accuracy
10:34:54 | [D] | [sensor:093] | 'PM1 Total kWh': Sending state 378.25476 kWh with 2 decimals of accuracy
10:35:06 | [D] | [sensor:093] | 'PM1 Total Amps': Sending state 8.93600 A with 2 decimals of accuracy
10:35:06 | [D] | [sensor:093] | 'PM1 Volts': Sending state 120.82000 V with 3 decimals of accuracy
10:35:06 | [D] | [sensor:093] | 'PM1 Volts': Sending state 120.58000 V with 3 decimals of accuracy
10:35:06 | [D] | [sensor:093] | 'PM1 CT1 Amps': Sending state 4.02100 A with 2 decimals of accuracy
10:35:06 | [D] | [sensor:093] | 'PM1 CT2 Amps': Sending state 5.01900 A with 2 decimals of accuracy
10:35:06 | [D] | [sensor:093] | 'PM1 CT1 Watts': Sending state 448.50528 W with 2 decimals of accuracy
10:35:06 | [D] | [sensor:093] | 'PM1 CT2 Watts': Sending state 545.75232 W with 2 decimals of accuracy
10:35:07 | [D] | [sensor:093] | 'PM1 Freq': Sending state 59.96000 Hz with 1 decimals of accuracy
Yamaha0014 commented 1 year ago 

[12:59:24][C][logger:302]:   Level: DEBUG
[12:59:24][C][logger:303]:   Log Baud Rate: 115200
[12:59:24][C][logger:305]:   Hardware UART: UART0
[12:59:24][C][uart.arduino_esp8266:102]: UART Bus:
[12:59:24][C][uart.arduino_esp8266:103]:   TX Pin: GPIO14
[12:59:24][C][uart.arduino_esp8266:104]:   RX Pin: GPIO12
[12:59:24][C][uart.arduino_esp8266:106]:   RX Buffer Size: 256
[12:59:24][C][uart.arduino_esp8266:108]:   Baud Rate: 9600 baud
[12:59:24][C][uart.arduino_esp8266:109]:   Data Bits: 8
[12:59:24][C][uart.arduino_esp8266:110]:   Parity: NONE
[12:59:24][C][uart.arduino_esp8266:111]:   Stop bits: 1
[12:59:24][C][uart.arduino_esp8266:115]:   Using software serial
[12:59:24][C][modbus:143]: Modbus:
[12:59:24][C][modbus:145]:   Send Wait Time: 250 ms
[12:59:24][C][modbus:146]:   CRC Disabled: NO
[12:59:24][C][uptime.sensor:031]: Uptime Sensor 'Energy Meter-H1 Uptime'
[12:59:25][C][uptime.sensor:031]:   Device Class: 'duration'
[12:59:25][C][uptime.sensor:031]:   State Class: 'total_increasing'
[12:59:25][C][uptime.sensor:031]:   Unit of Measurement: 's'
[12:59:25][C][uptime.sensor:031]:   Accuracy Decimals: 0
[12:59:25][C][uptime.sensor:031]:   Icon: 'mdi:timer-outline'
[12:59:25][D][pzemac:049]: PZEM AC: V=233.2 V, I=0.204 A, P=5.4 W, E=696488.0 Wh, F=50.0 Hz, PF=0.11
[12:59:25][D][sensor:093]: 'Energy Meter-H1 Voltage': Sending state 233.20000 V with 1 decimals of accuracy
[12:59:25][D][sensor:093]: 'Energy Meter-H1 Current': Sending state 0.20400 A with 3 decimals of accuracy
[12:59:25][D][sensor:093]: 'Energy Meter-H1 Power': Sending state 5.40000 W with 2 decimals of accuracy
[12:59:25][D][sensor:093]: 'Energy Meter-H1 Energy': Sending state 696.48804 kWh with 3 decimals of accuracy
[12:59:25][D][sensor:093]: 'Energy Meter-H1 Frequency': Sending state 50.00000 Hz with 1 decimals of accuracy
[12:59:25][D][sensor:093]: 'Energy Meter-H1 Power Factor': Sending state 0.11000  with 2 decimals of accuracy
[12:59:25][W][component:204]: Component modbus took a long time for an operation (0.07 s).
[12:59:25][W][component:205]: Components should block for at most 20-30ms.
[12:59:25][C][template.text_sensor:020]: Template Sensor 'Energy Meter-H1 Uptime (formatted)'
[12:59:25][C][template.text_sensor:020]:   Icon: 'mdi:clock-start'
[12:59:25][C][status:034]: Status Binary Sensor 'Energy Meter-H1 Status'
[12:59:25][C][status:034]:   Device Class: 'connectivity'
[12:59:25][C][dallas.sensor:075]: DallasComponent:
[12:59:25][C][dallas.sensor:076]:   Pin: GPIO13
[12:59:25][C][dallas.sensor:077]:   Update Interval: 60.0s
[12:59:25][D][dallas.sensor:082]:   Found sensors:
[12:59:25][D][dallas.sensor:084]:     0xd73c01e0768d4f28
[12:59:25][C][dallas.sensor:089]:   Device 'H1 Temperatura'
[12:59:25][C][dallas.sensor:089]:     Device Class: 'temperature'
[12:59:25][C][dallas.sensor:089]:     State Class: 'measurement'
[12:59:25][C][dallas.sensor:089]:     Unit of Measurement: '°C'
[12:59:25][C][dallas.sensor:089]:     Accuracy Decimals: 1
[12:59:25][C][dallas.sensor:097]:     Address: xxxxxxxxxxxxxxxxx
[12:59:25][C][dallas.sensor:098]:     Resolution: 12
[12:59:25][C][pzemac:067]: PZEMAC:
[12:59:25][C][pzemac:068]:   Address: 0x01
[12:59:25][C][pzemac:069]: Voltage 'Energy Meter-H1 Voltage'
[12:59:25][C][pzemac:069]:   Device Class: 'voltage'
[12:59:25][C][pzemac:069]:   State Class: 'measurement'
[12:59:25][C][pzemac:069]:   Unit of Measurement: 'V'
[12:59:25][C][pzemac:069]:   Accuracy Decimals: 1
[12:59:25][C][pzemac:070]: Current 'Energy Meter-H1 Current'
[12:59:25][C][pzemac:070]:   Device Class: 'current'
[12:59:25][C][pzemac:070]:   State Class: 'measurement'
[12:59:25][C][pzemac:070]:   Unit of Measurement: 'A'
[12:59:25][C][pzemac:070]:   Accuracy Decimals: 3
[12:59:25][C][pzemac:071]: Power 'Energy Meter-H1 Power'
[12:59:25][C][pzemac:071]:   Device Class: 'power'
[12:59:25][C][pzemac:071]:   State Class: 'measurement'
[12:59:25][C][pzemac:071]:   Unit of Measurement: 'W'
[12:59:25][C][pzemac:071]:   Accuracy Decimals: 2
[12:59:25][C][pzemac:072]: Energy 'Energy Meter-H1 Energy'
[12:59:25][C][pzemac:072]:   Device Class: 'energy'
[12:59:25][C][pzemac:072]:   State Class: 'total_increasing'
[12:59:25][C][pzemac:072]:   Unit of Measurement: 'kWh'
[12:59:25][C][pzemac:072]:   Accuracy Decimals: 3
[12:59:25][C][pzemac:073]: Frequency 'Energy Meter-H1 Frequency'
[12:59:25][C][pzemac:073]:   State Class: 'measurement'
[12:59:25][C][pzemac:073]:   Unit of Measurement: 'Hz'
[12:59:25][C][pzemac:073]:   Accuracy Decimals: 1
[12:59:25][C][pzemac:073]:   Icon: 'mdi:current-ac'
[12:59:25][C][pzemac:074]: Power Factor 'Energy Meter-H1 Power Factor'
[12:59:25][C][pzemac:074]:   Device Class: 'power_factor'
[12:59:25][C][pzemac:074]:   State Class: 'measurement'
[12:59:25][C][pzemac:074]:   Unit of Measurement: ''
[12:59:25][C][pzemac:074]:   Accuracy Decimals: 2
[12:59:25][C][adc:094]: ADC Sensor 'Energy Meter-H1 VCC'
[12:59:25][C][adc:094]:   Device Class: 'voltage'
[12:59:25][C][adc:094]:   State Class: 'measurement'
[12:59:25][C][adc:094]:   Unit of Measurement: 'V'

[12:59:27][D][pzemac:049]: PZEM AC: V=233.7 V, I=0.204 A, P=5.4 W, E=696488.0 Wh, F=49.9 Hz, PF=0.11
[12:59:27][D][sensor:093]: 'Energy Meter-H1 Voltage': Sending state 233.70000 V with 1 decimals of accuracy
[12:59:27][D][sensor:093]: 'Energy Meter-H1 Current': Sending state 0.20400 A with 3 decimals of accuracy
[12:59:27][D][sensor:093]: 'Energy Meter-H1 Power': Sending state 5.40000 W with 2 decimals of accuracy
[12:59:27][D][sensor:093]: 'Energy Meter-H1 Energy': Sending state 696.48804 kWh with 3 decimals of accuracy
[12:59:27][D][sensor:093]: 'Energy Meter-H1 Frequency': Sending state 49.90000 Hz with 1 decimals of accuracy
[12:59:27][D][sensor:093]: 'Energy Meter-H1 Power Factor': Sending state 0.11000  with 2 decimals of accuracy
[12:59:27][W][component:204]: Component modbus took a long time for an operation (0.06 s).
[12:59:27][W][component:205]: Components should block for at most 20-30ms.
[12:59:29][D][pzemac:049]: PZEM AC: V=233.8 V, I=0.204 A, P=5.4 W, E=696488.0 Wh, F=50.0 Hz, PF=0.11
[12:59:29][D][sensor:093]: 'Energy Meter-H1 Voltage': Sending state 233.80000 V with 1 decimals of accuracy
[12:59:29][D][sensor:093]: 'Energy Meter-H1 Current': Sending state 0.20400 A with 3 decimals of accuracy
[12:59:29][D][sensor:093]: 'Energy Meter-H1 Power': Sending state 5.40000 W with 2 decimals of accuracy
[12:59:29][D][sensor:093]: 'Energy Meter-H1 Energy': Sending state 696.48804 kWh with 3 decimals of accuracy
[12:59:29][D][sensor:093]: 'Energy Meter-H1 Frequency': Sending state 50.00000 Hz with 1 decimals of accuracy
[12:59:29][D][sensor:093]: 'Energy Meter-H1 Power Factor': Sending state 0.11000  with 2 decimals of accuracy
[12:59:29][W][component:204]: Component modbus took a long time for an operation (0.06 s).
[12:59:29][W][component:205]: Components should block for at most 20-30ms.
[12:59:31][D][pzemac:049]: PZEM AC: V=233.9 V, I=0.204 A, P=5.4 W, E=696488.0 Wh, F=50.0 Hz, PF=0.11
[12:59:31][D][sensor:093]: 'Energy Meter-H1 Voltage': Sending state 233.89999 V with 1 decimals of accuracy
[12:59:31][D][sensor:093]: 'Energy Meter-H1 Current': Sending state 0.20400 A with 3 decimals of accuracy
[12:59:31][D][sensor:093]: 'Energy Meter-H1 Power': Sending state 5.40000 W with 2 decimals of accuracy
[12:59:31][D][sensor:093]: 'Energy Meter-H1 Energy': Sending state 696.48804 kWh with 3 decimals of accuracy
[12:59:31][D][sensor:093]: 'Energy Meter-H1 Frequency': Sending state 50.00000 Hz with 1 decimals of accuracy
[12:59:31][D][sensor:093]: 'Energy Meter-H1 Power Factor': Sending state 0.11000  with 2 decimals of accuracy
[12:59:31][W][component:204]: Component modbus took a long time for an operation (0.06 s).
[12:59:31][W][component:205]: Components should block for at most 20-30ms.
allbeq commented 1 year ago

daly_bms component occurs the same, stopped working ;/

log:

[12:38:30][W][component:204]: Component daly_bms took a long time for an operation (0.09 s).
[12:38:30][W][component:205]: Components should block for at most 20-30ms.`

config:

`
logger:

uart:
  - id: uartBMS
    tx_pin: GPIO17
    rx_pin: GPIO5
    baud_rate: 9600
    rx_buffer_size: 512

  - platform: template
    name: "Daly 105v2 Charging MOS"
    lambda: |-
      if (id(bin_daly_chg_mos).state) {
        return true;
      } else {
        return false;
      }
    turn_on_action:
      - uart.write:
          data: [0xA5, 0x40, 0xDA, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC8]
      - logger.log:
          format: "Send cmd to Daly: Set charge MOS on"
    turn_off_action:
      - uart.write:
          data: [0xA5, 0x40, 0xDA, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC7]
      - logger.log:
          format: "Send cmd to Daly: Set charge MOS off"

  - platform: template
    name: "Daly 105v2 Discharging MOS"
    lambda: |-
      if (id(bin_daly_dischg_mos).state) {
        return true;
      } else {
        return false;
      }
    turn_on_action:
      - uart.write:
          data: [0xA5, 0x40, 0xD9, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC7]
      - logger.log:
          format: "Send cmd to Daly: Set discharge MOS on"
    turn_off_action:
      - uart.write:
          data: [0xA5, 0x40, 0xD9, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC6]
      - logger.log:
          format: "Send cmd to Daly: Set discharge MOS off"

daly_bms:
  uart_id: uartBMS
  update_interval: 10s

sensor:
  - platform: daly_bms
    voltage:
      name: "105_v2_Battery Voltage"
    current:
      name: "105_v2_Battery Current"
      filters:
      - throttle: 1s
      - sliding_window_moving_average:
          window_size: 5
          send_every: 2
    battery_level:
      name: "105_v2_Battery Level"
    max_cell_voltage:
      name: "105_v2_Max Cell Voltage"
    max_cell_voltage_number:
      name: "105_v2_Max Cell Voltage Number"
    min_cell_voltage:
      name: "105_v2_Min Cell Voltage"
    min_cell_voltage_number:
      name: "105_v2_Min Cell Voltage Number"
    max_temperature:
      name: "105_v2_Max Temperature"
    max_temperature_probe_number:
      name: "105_v2_Max Temperature Probe Number"
    min_temperature:
      name: "105_v2_Min Temperature"
    min_temperature_probe_number:
      name: "105_v2_Min Temperature Probe Number"
    remaining_capacity:
      name: "105_v2_Remaining Capacity"
    cells_number:
      name: "105_v2_Cells Number"
    temperature_1:
      name: "105_v2_Temperature 1"
    cell_1_voltage:
      name: "105_v2_Cell 1 Voltage"
      accuracy_decimals: 2
    cell_2_voltage:
      name: "105_v2_Cell 2 Voltage"
      accuracy_decimals: 2
    cell_3_voltage:
      name: "105_v2_Cell 3 Voltage"
      accuracy_decimals: 2
    cell_4_voltage:
      name: "105_v2_Cell 4 Voltage"
      accuracy_decimals: 2
    cell_5_voltage:
      name: "105_v2_Cell 5 Voltage"
      accuracy_decimals: 2
    cell_6_voltage:
      name: "105_v2_Cell 6 Voltage"
      accuracy_decimals: 2
    cell_7_voltage:
      name: "105_v2_Cell 7 Voltage"
      accuracy_decimals: 2
    cell_8_voltage:
      name: "105_v2_Cell 8 Voltage"
      accuracy_decimals: 2
    cell_9_voltage:
      name: "105_v2_Cell 9 Voltage"
      accuracy_decimals: 2
    cell_10_voltage:
      name: "105_v2_Cell 10 Voltage"
      accuracy_decimals: 2
    cell_11_voltage:
      name: "105_v2_Cell 11 Voltage"
      accuracy_decimals: 2
    cell_12_voltage:
      name: "105_v2_Cell 12 Voltage"
      accuracy_decimals: 2
    cell_13_voltage:
      name: "105_v2_Cell 13 Voltage"
      accuracy_decimals: 2
    cell_14_voltage:
      name: "105_v2_Cell 14 Voltage"
      accuracy_decimals: 2
    cell_15_voltage:
      name: "105_v2_Cell 15 Voltage"
      accuracy_decimals: 2
    cell_16_voltage:
      name: "105_v2_Cell 16 Voltage"
      accuracy_decimals: 2

text_sensor:
  - platform: daly_bms
    status:
      name: "105_v2_BMS Status"

binary_sensor:
  - platform: daly_bms
    charging_mos_enabled:
      name: "105_v2_Charging MOS"
      id: bin_daly_chg_mos 
      internal: True
    discharging_mos_enabled:
      name: "105_v2_Discharging MOS"
      id: bin_daly_dischg_mos
      internal: True
rarroyo6 commented 1 year ago

I'm using an lcd_pcf8574 with a 4 line LCD panel. I tried several i2c frequency settings. The errors remained.

[08:52:36][D][status_led:049]: 'led_status_light': Setting state ON [08:52:36][D][status_led:049]: 'led_status_light': Setting state OFF > [08:52:37][W][component:204]: Component lcd_base took a long time for an operation (0.06 s). [08:52:37][W][component:205]: Components should block for at most 20-30ms. [08:52:38][W][component:204]: Component lcd_base took a long time for an operation (0.06 s). [08:52:38][W][component:205]: Components should block for at most 20-30ms. [08:52:38][D][status_led:049]: 'led_status_light': Setting state ON [08:52:38][D][status_led:049]: 'led_status_light': Setting state OFF > [08:52:39][W][component:204]: Component lcd_base took a long time for an operation (0.06 s). [08:52:39][W][component:205]: Components should block for at most 20-30ms. [08:52:40][W][component:204]: Component lcd_base took a long time for an operation (0.06 s). [08:52:40][W][component:205]: Components should block for at most 20-30ms. [08:52:40][D][status_led:049]: 'led_status_light': Setting state ON [08:52:40][D][status_led:049]: 'led_status_light': Setting state OFF [08:52:41][D][sensor:094]: 'WiFi RSSI dBm': Sending state -59.00000 dBm with 0 decimals of accuracy > [08:52:41][W][component:204]: Component lcd_base took a long time for an operation (0.06 s). [08:52:41][W][component:205]: Components should block for at most 20-30ms. [08:52:42][W][component:204]: Component lcd_base took a long time for an operation (0.06 s). [08:52:42][W][component:205]: Components should block for at most 20-30ms.

Same issue here with a 20X4 display.

PcOnline2004 commented 1 year ago

Same warning with pzemdc sensor. The value do not change any more!

[13:46:20][W][component:204]: Component modbus took a long time for an operation (0.09 s).
[13:46:20][W][component:205]: Components should block for at most 20-30ms.
[13:46:20][D][uart_debug:114]: <<< 01:04:10:04:B8:02:54:02:CF:00:00:16:74:00:00:00:00:00:00:A2:7A
[13:47:20][D][uart_debug:114]: >>> 01:04:00:00:00:08:F1:CC
[13:47:20][V][modbus:042]: Modbus received Byte  1 (0X1)
[13:47:20][V][modbus:042]: Modbus received Byte  4 (0X4)
[13:47:20][V][modbus:042]: Modbus received Byte  16 (0X10)
[13:47:20][V][modbus:042]: Modbus received Byte  4 (0X4)
[13:47:20][V][modbus:042]: Modbus received Byte  184 (0Xb8)
[13:47:20][V][modbus:042]: Modbus received Byte  2 (0X2)
[13:47:20][V][modbus:042]: Modbus received Byte  84 (0X54)
[13:47:20][V][modbus:042]: Modbus received Byte  2 (0X2)
[13:47:20][V][modbus:042]: Modbus received Byte  207 (0Xcf)
[13:47:20][V][modbus:042]: Modbus received Byte  0 (0X0)
[13:47:20][V][modbus:042]: Modbus received Byte  0 (0X0)
[13:47:20][V][modbus:042]: Modbus received Byte  22 (0X16)
[13:47:20][V][modbus:042]: Modbus received Byte  117 (0X75)
[13:47:20][V][modbus:042]: Modbus received Byte  0 (0X0)
[13:47:20][V][modbus:042]: Modbus received Byte  0 (0X0)
[13:47:20][V][modbus:042]: Modbus received Byte  0 (0X0)
[13:47:20][V][modbus:042]: Modbus received Byte  0 (0X0)
[13:47:20][V][modbus:042]: Modbus received Byte  0 (0X0)
[13:47:20][V][modbus:042]: Modbus received Byte  0 (0X0)
[13:47:20][V][modbus:042]: Modbus received Byte  178 (0Xb2)
[13:47:20][V][modbus:042]: Modbus received Byte  186 (0Xba)
[13:47:20][D][pzemdc:044]: PZEM DC: V=12.1 V, I=5.960 A, P=71.9 W
NickWilton commented 1 year ago

Downgrading to 2023.4.4 solved all three issues.

Looking through the changes since this release, this PR stands out as possibly being most relevant to the problem. https://github.com/esphome/esphome/pull/4774

As it is I can't upgrade until this issue is sorted. I suspect many others can't as well.

jklap commented 1 year ago

Emporia_vue https://github.com/emporia-vue-local/esphome

[11:52:34][W][component:204]: Component emporia_vue.sensor took a long time for an operation (0.17 s). [11:52:34][W][component:205]: Components should block for at most 20-30ms.

vinceg0267 commented 1 year ago

With Esp32 [18:39:24][W][component:204]: Component modbus_controller took a long time for an operation (0.12 s). [18:39:24][W][component:205]: Components should block for at most 20-30ms.

descipher commented 1 year ago

Looking through the changes since this release, this PR stands out as possibly being most relevant to the problem. esphome/esphome#4774

4774 simply reverts to return if there is no sensor value assigned it would be more impact if left as is. This is not likely to create delays. Most of these delay reports are based on the fact that you can see a WARN message and thats been in the background for a very long time. Each component and it's configuration should be regarded individually. I reverted to examine some random json memory errors and they are in previous releases as well. It's not even a component issue it's an api issue that shows up when you log from HA directly for a long period of time. I have also observed that the browser client and it network transports can invoke a WARN by simply delaying responses. There are some elements of the blocking measurement time function that may need to be tuned to account for non-local blocking factors such as a network retry or back-end api handshake issues. When I have time I will do a packet trace to see what the overall backend context effects are to the measurements of local elasped time.

smartroad commented 1 year ago

Getting with i2s_audio

[D][media_player:059]: 'ESPHome I2S Media Player' - Setting
[D][media_player:063]:   Command: PLAY
[D][media_player:059]: 'ESPHome I2S Media Player' - Setting
[D][media_player:066]:   Media URL: http://192.168.0.101:8123/media/local/31%20-%20Game%20Over_1112f71f-b161-4582-801d-92303fc5ee1a.mp3?authSig=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJiMjA1MTBhZDlmNDc0MzdjOThiYzZmNWUwZTRhN2UzZiIsInBhdGgiOiIvbWVkaWEvbG9jYWwvMzEgLSBHYW1lIE92ZXJfMTExMmY3MWYtYjE2MS00NTgyLTgwMWQtOTIzMDNmYzVlZTFhLm1wMyIsInBhcmFtcyI6W10sImlhdCI6MTY5MjQ0MTI5OSwiZXhwIjoxNjkyNTI3Njk5fQ.ItJ0ytZllNNJuC_vSRa2zHJIQEoVvvJK1oVIi1Ng9lI
[W][component:204]: Component i2s_audio.media_player took a long time for an operation (0.53 s).
[W][component:205]: Components should block for at most 20-30ms.
[W][component:204]: Component i2s_audio.media_player took a long time for an operation (0.19 s).
[W][component:205]: Components should block for at most 20-30ms.
[W][component:204]: Component i2s_audio.media_player took a long time for an operation (0.18 s).
[W][component:205]: Components should block for at most 20-30ms.
esphome:
  name: espmedia

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "REDACTED"

ota:
  password: "REDACTED"

wifi:
  ssid: "REDACTED"
  password: "REDACTED"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Espmedia Fallback Hotspot"
    password: "REDACTED"

captive_portal:

i2s_audio:
  i2s_lrclk_pin: GPIO33
  i2s_bclk_pin: GPIO19

media_player:
  - platform: i2s_audio
    name: ESPHome I2S Media Player
    dac_type: external
#    i2s_lrclk_pin: GPIO33
    i2s_dout_pin: GPIO22
#    i2s_bclk_pin: GPIO19
    mode: mono
TheWanderingTurkey commented 1 year ago

Getting this with LD2410 and API.

Logs:

[09:58:53][W][component:204]: Component api took a long time for an operation (0.10 s).
[09:58:53][W][component:205]: Components should block for at most 20-30ms.
[09:58:55][W][component:204]: Component ld2410 took a long time for an operation (0.35 s).
[09:58:55][W][component:205]: Components should block for at most 20-30ms.
[09:59:03][D][text_sensor:064]: 'Uptime': Sending state '7m 40s'
[09:59:03][D][sensor:094]: 'Uptime': Sending state 460.18701 s with 0 decimals of accuracy
[09:59:08][D][sensor:094]: 'Moving Distance': Sending state 55.00000 cm with 0 decimals of accuracy
[09:59:08][D][sensor:094]: 'Move Energy': Sending state 72.00000 % with 0 decimals of accuracy
[09:59:08][D][button:010]: 'mmWave Query Params' Pressed.
[09:59:08][W][component:204]: Component api took a long time for an operation (0.35 s).
[09:59:08][W][component:205]: Components should block for at most 20-30ms.
[09:59:17][D][sensor:094]: 'WiFi Signal dB': Sending state -54.40000 dBm with 0 decimals of accuracy
[09:59:17][D][sensor:094]: 'WiFi Signal dB': Sending state -54.40000 dBm with 0 decimals of accuracy
[09:59:26][D][sensor:094]: 'Moving Distance': Sending state 60.00000 cm with 0 decimals of accuracy
[09:59:26][D][sensor:094]: 'Move Energy': Sending state 59.00000 % with 0 decimals of accuracy
[09:59:29][D][switch:012]: 'mmWave Engineering Mode' Turning ON.
[09:59:29][D][switch:055]: 'mmWave Engineering Mode': Sending state ON
[09:59:29][W][component:204]: Component api took a long time for an operation (0.16 s).
[09:59:29][W][component:205]: Components should block for at most 20-30ms.
[09:59:39][D][switch:055]: 'mmWave Engineering Mode': Sending state OFF

YAML:

  name: radar-office
  friendly_name: Radar (Office)

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:
  baud_rate: 0

# Enable Home Assistant API
api:
  encryption:
    key: REDACTED

ota:
  password: REDACTED

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Radar-Office Fallback Hotspot"
    password: REDACTED

uart:
  tx_pin: TX
  rx_pin: RX
  baud_rate: 256000
  parity: NONE
  stop_bits: 1
  data_bits: 8

binary_sensor:
  - platform: ld2410
    has_target:
      name: Presence
    has_moving_target:
      name: Moving Target
    has_still_target:
      name: Still Target
    out_pin_presence_status:
      name: mmWave Out Pin Presence Status

  - platform: gpio
    pin: GPIO14
    name: GPIO Out Pin Presence
    device_class: presence

ld2410:

sensor:
  - platform: ld2410
    light:
      name: mmWave Light
    moving_distance:
      name: Moving Distance
    still_distance:
      name: Still Distance
    moving_energy:
      name: Move Energy
    still_energy:
      name: Still Energy
    detection_distance:
      name: Detection Distance
    g0:
      move_energy:
        name: G0 Move energy
      still_energy:
        name: G0 Still energy
    g1:
      move_energy:
        name: G1 Move energy
      still_energy:
        name: G1 Still energy
    g2:
      move_energy:
        name: G2 Move energy
      still_energy:
        name: G2 Still energy
    g3:
      move_energy:
        name: G3 Move energy
      still_energy:
        name: G3 Still energy
    g4:
      move_energy:
        name: G4 Move energy
      still_energy:
        name: G4 Still energy
    g5:
      move_energy:
        name: G5 Move energy
      still_energy:
        name: G5 Still energy
    g6:
      move_energy:
        name: G6 Move energy
      still_energy:
        name: G6 Still energy
    g7:
      move_energy:
        name: G7 Move energy
      still_energy:
        name: G7 Still energy
    g8:
      move_energy:
        name: G8 Move energy
      still_energy:
        name: G8 Still energy

  # - platform: bh1750
  #   name: Illuminance
  #   id: illuminance
  #   address: 0x23
  #   filters:
  #     - sliding_window_moving_average:
  #         window_size: 5
  #         send_every: 1
  #     - or:
  #       - delta: 1.0
  #       - throttle: 30s

  - platform: wifi_signal
    name: WiFi Signal dB
    id: wifi_signal_db
    filters:
      - sliding_window_moving_average:
          window_size: 5
          send_every: 1
      - or:
        - delta: 1.0
        - throttle: 30s
    entity_category: "diagnostic"

  - platform: uptime
    name: Uptime
    id: uptime_sensor
    update_interval: 60s
    on_raw_value:
      then:
        - text_sensor.template.publish:
            id: uptime_human
            # Custom C++ code to generate the result
            state: !lambda |-
              int seconds = round(id(uptime_sensor).raw_state);
              int days = seconds / (24 * 3600);
              seconds = seconds % (24 * 3600);
              int hours = seconds / 3600;
              seconds = seconds % 3600;
              int minutes = seconds /  60;
              seconds = seconds % 60;
              return (
                (days ? to_string(days) + "d " : "") +
                (hours ? to_string(hours) + "h " : "") +
                (minutes ? to_string(minutes) + "m " : "") +
                (to_string(seconds) + "s")
              ).c_str();

button:
  - platform: restart
    name: Restart

  - platform: ld2410
    factory_reset:
      name: mmWave Factory Reset
    restart:
      name: mmWave Restart
    query_params:
      name: mmWave Query Params

text_sensor:
  - platform: wifi_info
    ip_address:
      name: IP Address
    ssid:
      name: Connected SSID
    bssid:
      name: Connected BSSID
    mac_address:
      name: Mac Wifi Address

  # Send Uptime in raw seconds
  - platform: template
    name: Uptime
    id: uptime_human
    icon: mdi:clock-start

  - platform: ld2410
    version:
      name: mmWave Firmware Version
    mac_address:
      name: mmWave Mac Address

select:
  - platform: ld2410
    distance_resolution:
      name: mmWave Distance Resolution
    baud_rate:
      name: mmWave Baud Rate
    light_function:
      name: mmWave Light Function
    out_pin_level:
      name: mmWave Out Pin Level

switch:
  - platform: ld2410
    engineering_mode:
      name: mmWave Engineering Mode
    bluetooth:
      name: mmWave Control Bluetooth

number:
  - platform: ld2410
    timeout:
      name: Timeout
    light_threshold:
      name: Light Threshold
    max_move_distance_gate:
      name: Max Move Distance Gate
    max_still_distance_gate:
      name: Max Still Distance Gate
    g0:
      move_threshold:
        name: G0 Move Threshold
      still_threshold:
        name: G0 Still Threshold
    g1:
      move_threshold:
        name: G1 Move Threshold
      still_threshold:
        name: G1 Still Threshold
    g2:
      move_threshold:
        name: G2 Move Threshold
      still_threshold:
        name: G2 Still Threshold
    g3:
      move_threshold:
        name: G3 Move Threshold
      still_threshold:
        name: G3 Still Threshold
    g4:
      move_threshold:
        name: G4 Move Threshold
      still_threshold:
        name: G4 Still Threshold
    g5:
      move_threshold:
        name: G5 Move Threshold
      still_threshold:
        name: G5 Still Threshold
    g6:
      move_threshold:
        name: G6 Move Threshold
      still_threshold:
        name: G6 Still Threshold
    g7:
      move_threshold:
        name: G7 Move Threshold
      still_threshold:
        name: G7 Still Threshold
    g8:
      move_threshold:
        name: G8 Move Threshold
      still_threshold:
        name: G8 Still Threshold
Patrick010 commented 12 months ago

Got it with Modbus

Home Assistant 2023.8.3
Supervisor 2023.08.1
Frontend 20230802.1 - latest
ESPHome: 2023.8.1

substitutions:
  name: modbus-test
  friendly_name: VFD

esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: esp-idf

button:
  - platform: restart
    name: "Restart"

api:

ota:
  password: !secret ota_password

logger:
  level: VERY_VERBOSE

#esp32_ble_tracker:
#    scan_parameters:
#      active: False

#bluetooth_proxy:
#  active: False

wifi:
  ssid: !secret ding_wifi_ssid
  password: !secret ding_wifi_password

#i2c:
#  sda: 21
#  scl: 22
#  scan: true
#  id: bus_a

modbus:
  id: modbus1
  uart_id: modbus_serial
  flow_control_pin: GPIO5

modbus_controller:
  - id: vfd
    address: 0x1
    modbus_id: modbus1
    # command_throttle: 250ms
    setup_priority: -10
    update_interval: 1s

uart:
  id: modbus_serial
  tx_pin: GPIO1 
  rx_pin: GPIO3  
  baud_rate: 115200
  stop_bits: 1
  data_bits: 8
  parity: NONE  
  debug:
    direction: BOTH
    dummy_receiver: false
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

sensor:
  - platform: modbus_controller
    modbus_controller_id: vfd
    id: setup_value
    name: "0x1000"
    address: 0x1000
    unit_of_measurement: "V"
    register_type: holding
    value_type: U_WORD
    accuracy_decimals: 0

  - platform: modbus_controller
    modbus_controller_id: vfd
    id: running_frequency
    name: "0x1001"
    address: 0x1001
    unit_of_measurement: "V"
    register_type: holding
    value_type: U_WORD
    accuracy_decimals: 1

  - platform: modbus_controller
    modbus_controller_id: vfd
    id: bus_voltage
    name: "0x1002"
    address: 0x1002
    unit_of_measurement: "V"
    register_type: holding
    value_type: U_WORD
    accuracy_decimals: 1

  - platform: modbus_controller
    modbus_controller_id: vfd
    id: Output_voltage_1
    name: "0x1003"
    address: 0x1003
    unit_of_measurement: "V"
    register_type: holding
    value_type: U_WORD
    accuracy_decimals: 1

  - platform: modbus_controller
    modbus_controller_id: vfd
    id: Output_voltage_2
    name: "0x1004"
    address: 0x1004
    unit_of_measurement: "V"
    register_type: holding
    value_type: U_WORD
    accuracy_decimals: 1

  - platform: modbus_controller
    modbus_controller_id: vfd
    id: output_power
    name: "0x1005"
    address: 0x1005
    unit_of_measurement: "V"
    register_type: holding
    value_type: U_WORD
    accuracy_decimals: 1

  - platform: modbus_controller
    modbus_controller_id: vfd
    id: Output_torque
    name: "0x1006"
    address: 0x1006
    unit_of_measurement: "V"
    register_type: holding
    value_type: U_WORD
    accuracy_decimals: 1

  - platform: modbus_controller
    modbus_controller_id: vfd
    id: Running_speed
    name: "0x1007"
    address: 0x1007
    unit_of_measurement: "V"
    register_type: holding
    value_type: U_WORD
    accuracy_decimals: 1
[17:52:35][W][component:204]: Component modbus_controller took a long time for an operation (0.27 s).
[17:52:35][W][component:205]: Components should block for at most 20-30ms.
[17:52:35][D][uart_debug:158]: <<< "\x01\x03\x10\x00\x00\x00\x00\fN\x00\x17\x00\x00\x00\x00\x00\x00\x00\x00~\x90"
[17:52:35][VV][scheduler:226]: Running interval 'update' with interval=1000 last_execution=1516631 (now=1517631)
[17:52:35][V][modbus_controller:158]: Updating modbus component
[17:52:35][VV][modbus_controller:162]: Updating range 0x1000
[17:52:35][V][modbus_controller:125]: Range : 1000 Size: 8 (3) skip: 0
[17:52:35][V][modbus_controller:036]: Sending next modbus command to device 1 register 0x1000 count 8
[17:52:35][VV][uart.idf:201]:     Flushing...
[17:52:35][V][modbus:199]: Modbus write: 01.03.10.00.00.08.40.CC (8)
[17:52:35][V][modbus_controller:486]: Command sent 3 0x1000 8
[17:52:36][D][uart_debug:158]: >>> "\x01\x03\x10\x00\x00\b@\xCC"
[17:52:36][V][modbus:042]: Modbus received Byte  1 (0X1)
[17:52:36][V][modbus:042]: Modbus received Byte  3 (0X3)
[17:52:36][V][modbus:042]: Modbus received Byte  16 (0X10)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  12 (0Xc)
[17:52:36][V][modbus:042]: Modbus received Byte  77 (0X4d)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  23 (0X17)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  0 (0X0)
[17:52:36][V][modbus:042]: Modbus received Byte  113 (0X71)
[17:52:36][V][modbus:042]: Modbus received Byte  212 (0Xd4)
tramperb commented 12 months ago

This warning has started with 2023.8.2 update. [22:06:07][W][component:204]: Component aht10.sensor took a long time for an operation (0.08 s). [22:06:07][W][component:205]: Components should block for at most 20-30ms.

frequency: 400kHz was added but didn't eliminate the warning

Config:

esphome:
  name: redacted
  friendly_name: redacted

esp32:
  board: esp32dev
  framework:
    type: arduino

logger:

api:
  encryption:
    key: redacted 
ota:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  ap:
    ssid: redacted
    password: redacted

captive_portal:

i2c:
  sda: 21
  scl: 22
  scan: true
  frequency: 400kHz

sensor:
  - platform: bmp280
    temperature:
      name: "BMP280 Temperature"
    pressure:
      name: "BMP280 Pressure"
    address: 0x77
    update_interval: 60s

  - platform: aht10
    temperature:
      name: "AHT10 Temperature"
    humidity:
      name: "ATH10 Humidity"
    update_interval: 60s`
gednet commented 12 months ago

Hi i have the same problem different components. But... If you change arduino framework version to 2.0.9 it's work without that issues.

esp32: board: esp32dev framework: type: arduino version: 2.0.9

But i don't know witch components will have other problems in esphome with older framework.

tramperb commented 12 months ago

Thanks gednet - tried it but, at least for ATH10 component, the same warning persists.

gednet commented 12 months ago

Thanks gednet - tried it but, at least for ATH10 component, the same warning persists.

Can you try version 2.0.8 ?

tramperb commented 12 months ago

I can. I have. No change, warning persists.

tmarkson commented 12 months ago

Using https://github.com/KinDR007/VictronMPPT-ESPHOME The line mentions .coroutine; that sounds like a core esphome feature

2023-08-14_esphome_long_operation

Joshfindit commented 12 months ago

I'm seeing this on the D1 Mini (esp8266) board: d1-mini platform: sps30 ESPHome version: 2023.8.0-dev

Observations:

  1. I reduced it slightly by going from i2c: frequency: 50kHz (default) to i2c: frequency: 100kHz (The sensor does not support 400kHz or even 200)
  2. I eliminated the warning by reducing the number of sensors to 4 (I was tracking the full 10)

Personally, I re-enabled all 10 sensors and decided to ignore the warning because it's only blocking for 110ms and my check interval is 10s.

dungeon77 commented 11 months ago

I reflashed the working plug, and the energy monitoring stopped working

kernelpanic85 commented 11 months ago

I was hitting this as well for the ssd1306 and changing the frequency to 400khz fixed it too.

nrika commented 11 months ago

When receiving MQTT message in order to send IR code I keep getting error message: Component mqtt took a long time for an operation (0.06 s). [10:51:30][W][component:205]: Components should block for at most 20-30ms. Any ideas on that?

andrewbeyou88 commented 11 months ago

Thank you, this works!

i2c: frequency: 400kHz

nrika commented 11 months ago

remote_transmitter - when pressing a button in order to send IR code (remote_transmitter) I keep getting error message: Component api took a long time for an operation (0.07 s). [10:51:30][W][component:205]: Components should block for at most 20-30ms. Any ideas on that?

remote_transmitter:

button:

Patrick010 commented 11 months ago

Does anybody even know what this message means?

NickWilton commented 11 months ago

Thank you, this works!

i2c: frequency: 400kHz

Unfortunately, this doesn't work with geoffdavis/esphome-mitsubishiheatpump. This external component becomes unresponsive with this setting.

bluenazgul commented 11 months ago

i get the same with Component ssd1322_base took a long time for an operation

frequency wont work here, as it is only for I2C and ssd1322 uses SPI

Madman833 commented 11 months ago

I got issues with ADS1115. Tried to update the I2C frequency to 400kHz. Did not helped.

[19:01:42][D][sensor:093]: 'NTC Temperature A0': Sending state 16.30720 °C with 1 decimals of accuracy [19:01:42][W][component:204]: Component ads1115.sensor took a long time for an operation (0.06 s). [19:01:42][W][component:205]: Components should block for at most 20-30ms. [19:01:44][D][ads1115:186]: 'ADS A1': Got Voltage=4.095875V

Setup I am using:

esphome: name: esphome-web-9f48b3 friendly_name: Forrad

esp8266: board: esp01_1m

Enable logging

logger: level: VERBOSE

Enable Home Assistant API

api: encryption: key: "h0u0nrHKwIvoLtCGWWVe8Ix4f5PzOzc6gB5BISzuXwQ=" reboot_timeout : 0s

ota:

wifi: ssid: !secret wifi_ssid password: !secret wifi_password reboot_timeout: 0s

Enable fallback hotspot (captive portal) in case wifi connection fails

ap: ssid: "Esphome-Web-9F48B3" password: "YqRkWZoOVuS8"

captive_portal:

i2c: sda: 4 scl: 5 scan: true id: bus_a frequency: 400kHz

ads1115:

sensor:

ADS Inputs

ADS measuremetn to tempreature A0

mcp23017:

MCP Outputs

switch:

MCP Inputs

binary_sensor:

Larry0ua commented 11 months ago

Same log appears when working with ina219 i2c sensor.

My setup:

i2c:
  - frequency: 400kHz
sensor:
  - platform: ina219
    address: 0x40
    current:
      id: water_pump_current
      filters:
        max:
          window_size: 10
          send_every: 10
    max_voltage: 16.0V
    max_current: 2A
    update_interval: 0.5s

Previously without frequency set the 'took a long time for an operation' message was logged frequently with numbers 0.5-1.2s. After moving to 400kHz frequency number of messages decreased significantly, but they still appear sometimes.

therafman commented 11 months ago

This was working before the update:

[23:28:34][D][dallas.sensor:143]: 'Cooler Temp': Got Temperature=23.1°C [23:28:34][D][sensor:094]: 'Cooler Temp': Sending state 23.06250 °C with 1 decimals of accuracy [23:28:40][W][component:204]: Component st7789v.display took a long time for an operation (0.11 s). [23:28:40][W][component:205]: Components should block for at most 20-30ms.

`captive_portal:

time:

dallas:

font:

color:

spi: clk_pin: GPIO13 mosi_pin: GPIO15

i2c:

- id: bus_a

sda: GPIO0

scl: GPIO26

scan: true

text_sensor:

sensor:

display:

odya commented 11 months ago

Got flooded logs with this warning on modbus_component (ESPHome 2023.8.2):

uart:
  - id: uart_inverter
    baud_rate: 2400
    tx_pin: GPIO1
    rx_pin: GPIO3

modbus:
  - id: modbus_inverter
    uart_id: uart_inverter
    send_wait_time: 500ms

modbus_controller:
  - id: smg_inverter
    address: 0x05
    modbus_id: modbus_inverter
    command_throttle: 600ms
    update_interval: 10s
[11:36:43][W][component:204]: Component modbus_controller took a long time for an operation (0.06 s).
[11:36:43][W][component:205]: Components should block for at most 20-30ms.
jbunting commented 11 months ago

I am getting this with a ssd1351_spi display. Configuration below

esphome:
  name: display_test
  friendly_name: display test

esp32:
  board: esp32-poe-iso
  framework:
    type: arduino

logger:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

captive_portal:

# ethernet:
#   type: LAN8720
#   mdc_pin: GPIO23
#   mdio_pin: GPIO18
#   clk_mode: GPIO17_OUT
#   phy_addr: 0
#   power_pin: GPIO12

api:
  encryption:
    key: "****"

ota:
  password: "****:

spi:
  clk_pin: GPIO14
  mosi_pin: GPIO13

display:
  - platform: ssd1351_spi
    id: smdisp
    model: "SSD1351 128x128"
    reset_pin: GPIO32
    cs_pin: GPIO15
    dc_pin: GPIO16
    update_interval: 10s
    lambda: |-
      it.strftime(0, 0, id(roboto), "%Y-%m-%d %H:%M", id(theclock).now());

font:
  - file: "gfonts://Roboto"
    id: roboto
    size: 14

time:
  platform: sntp
  id: theclock

It's functional, but when I add a button, sometimes button presses don't register (I presume b/c of how long the display redraw is taking.)

Gaeldrin commented 11 months ago

Hello, brand new ESPhome user with the same error message on BME 280 sensor.

Yesterday I installed everything (in Docker), it was working for a while but slowly built up to not being usable at all (see graph included) :( I made absolutely zero changes since getting it running yesterday around noon, here's the data:

Log with errors (this constantly repeats now):

[20:58:22][W][component:204]: Component bme280.sensor took a long time for an operation (1.00 s).
[20:58:22][W][component:205]: Components should block for at most 20-30ms.
[20:58:32][D][sensor:094]: 'Equivalent sea level pressure': Sending state 858.37946 hPa with 1 decimals of accuracy
[20:58:35][D][sensor:094]: 'Dew Point': Sending state 190.81000 °C with 1 decimals of accuracy
[20:58:35][D][sensor:094]: 'Altitude': Sending state 2288.84644 m with 1 decimals of accuracy

Graph showing the development (the temperature reading of 190°C is the effect of sensor errors, at least for present that is verifiably true): Screenshot from 2023-09-02 21-08-54

YAML with sensor settings (everything from epshome.io documentation):

esphome:
  name: "termostat"
  friendly_name: Termostat

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "***"

ota:
  password: "***"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Termostat"
    password: "***"

captive_portal:

i2c:

sensor:
  - platform: bme280
    temperature:
      name: "BME280 Temperature"
      id: bme280_temperature
    pressure:
      name: "BME280 Pressure"
      id: bme280_pressure
    humidity:
      name: "BME280 Relative Humidity"
      id: bme280_humidity
    address: 0x76
    update_interval: 15s
  - platform: template
    name: "Altitude"
    lambda: |-
      const float STANDARD_SEA_LEVEL_PRESSURE = 1013.25; //in hPa, see note
      return ((id(bme280_temperature).state + 273.15) / 0.0065) *
        (powf((STANDARD_SEA_LEVEL_PRESSURE / id(bme280_pressure).state), 0.190234) - 1); // in meter
    update_interval: 15s
    icon: 'mdi:signal'
    unit_of_measurement: 'm'
  - platform: absolute_humidity
    name: "Absolute Humidity"
    temperature: bme280_temperature
    humidity: bme280_humidity
  - platform: template
    name: "Dew Point"
    lambda: |-
      return (243.5*(log(id(bme280_humidity).state/100)+((17.67*id(bme280_temperature).state)/
      (243.5+id(bme280_temperature).state)))/(17.67-log(id(bme280_humidity).state/100)-
      ((17.67*id(bme280_temperature).state)/(243.5+id(bme280_temperature).state))));
    unit_of_measurement: °C
    icon: 'mdi:thermometer-alert'
  - platform: template
    name: "Equivalent sea level pressure"
    lambda: |-
      const float STANDARD_ALTITUDE = 0.6; // in meters, see note
      return id(bme280_pressure).state / powf(1 - ((0.0065 * STANDARD_ALTITUDE) /
        (id(bme280_temperature).state + (0.0065 * STANDARD_ALTITUDE) + 273.15)), 5.257); // in hPa
    update_interval: 15s
    unit_of_measurement: 'hPa'
Patrick010 commented 11 months ago

Asked this before, but nobody cared to answer. Probably because nobody knows 😏 What does this message mean, besides the obvious? How bad is it when one gets it? Will this affect the workings on a grand scale, or is it one of those errors you can safely ignore?

edwardtfn commented 11 months ago

The message was there before. What changed was moving to be visible with DEBUG level, which is way more visible as it is the default level. And it is a warning, not an error message, so I think most people can ignore just like they used to ignore. But something to be ignored shouldn't be shown, as it takes attention from important things. 😩

Craftingcat99 commented 11 months ago

I just updated my esphome devices and my WS2812B LED strip completely stopped working altogether. I can push new values from HA without any problems but the ESP just displays this warning message in the logs and the LED strip stays dark: [W][component:204]: Component light took a long time for an operation (0.30 s). I didn't change any code or other variables besides the update. Any help would be very much appreciated. Btw im using an ESP32.

Patrick010 commented 11 months ago

Updated to a newer Esphome version, or just pushed a new config? If Esphome, then try rolling back to an earlier version and see if it works again.

Craftingcat99 commented 11 months ago

I believe it was the config, like HA prompted me to update my specific device not the whole Esphome version. I dont know if I can roll back this config

Patrick010 commented 11 months ago

Did you have the backup box checked when updating? Then you can roll back and reinstall that on your esp

Craftingcat99 commented 11 months ago

I usually leave this box checked but I only have 1 available backup for mosquitto that I updated at the same time as my esphome devices, no esphome backups. So either i accidentaly unchecked it or smth went wrong in the update

Craftingcat99 commented 11 months ago

I also tried reuploading the yaml code and checked it for errors beforehand but that also didn't resolve the issue

Patrick010 commented 11 months ago

Then you have to manually set the ESPHome version in its config. How to do that is discussed in this topic: https://community.home-assistant.io/t/install-older-or-dev-version-of-esphome-add-on/207154/9

Craftingcat99 commented 11 months ago

I'll look into that tomorrow. Thank you for your help :)

andrewigali commented 11 months ago

I have Sonoff Dual R3 V.1.6 module and I use ESPHome 2023.8.2 on Home Assistant.

Short problem in log: 14:44:41 [W] [component:204] Component cse7761.sensor took a long time for an operation (0.11 s). 14:44:41 [W] [component:205] Components should block for at most 20-30ms.

In ESPHome web log:

Time level Tag Message 14:43:18 [D] [text_sensor:064]
'WC világítás és WC ventilátor WIFI csatorna': Sending state '6' 14:43:25 [D] [sensor:094]
'WC világítás és WC ventilátor WiFi jelerősség százalék': Sending state 100.00000 % with 0 decimals of accuracy 14:43:26 [D] [sensor:094]
'WC világítás és WC ventilátor WiFi jelerősség dBm': Sending state -46.00000 dBm with 0 decimals of accuracy 14:43:26 [D] [esp32.preferences:114] Saving 2 preferences to flash... 14:43:26 [D] [esp32.preferences:143] Saving 2 preferences to flash: 2 cached, 0 written, 0 failed 14:43:28 [D] [sntp:078]
Synchronized time: 2023-09-03 14:43:28 14:43:41 [D] [sensor:094]
'WC világítás és ventilátor feszültség': Sending state 236.79683 V with 1 decimals of accuracy 14:43:41 [D] [cse7761:224]
Channel 1 power 0.000000 W, current 0.000000 A 14:43:41 [D] [sensor:094]
'WC világítás teljesítmény': Sending state 0.00000 W with 1 decimals of accuracy 14:43:41 [D] [sensor:094]
'WC világítás fogyasztás': Sending state 0.00406 kWh with 5 decimals of accuracy 14:43:41 [D] [sensor:094]
'WC világítás áramerősség': Sending state 0.00000 A with 2 decimals of accuracy 14:43:41 [D] [cse7761:224]
Channel 2 power 0.000000 W, current 0.000000 A 14:43:41 [D] [sensor:094]
'WC ventilátor teljesítmény': Sending state 0.00000 W with 1 decimals of accuracy 14:43:41 [D] [sensor:094]
'WC ventilátor fogyasztás': Sending state 0.00730 kWh with 5 decimals of accuracy 14:43:41 [D] [sensor:094]
'WC ventilátor áramerősség': Sending state 0.00000 A with 2 decimals of accuracy 14:43:41 [W] [component:204] Component cse7761.sensor took a long time for an operation (0.12 s). 14:43:41 [W] [component:205] Components should block for at most 20-30ms. 14:44:18 [D] [text_sensor:064]
'WC világítás és WC ventilátor WIFI csatorna': Sending state '6' 14:44:26 [D] [sensor:094]
'WC világítás és WC ventilátor WiFi jelerősség százalék': Sending state 100.00000 % with 0 decimals of accuracy 14:44:26 [D] [sensor:094]
'WC világítás és WC ventilátor WiFi jelerősség dBm': Sending state -47.00000 dBm with 0 decimals of accuracy 14:44:26 [D] [esp32.preferences:114] Saving 2 preferences to flash... 14:44:26 [D] [esp32.preferences:143] Saving 2 preferences to flash: 2 cached, 0 written, 0 failed 14:44:26 [D] [esp32.preferences:143] Saving 2 preferences to flash: 2 cached, 0 written, 0 failed 14:44:41 [D] [sensor:094]
'WC világítás és ventilátor feszültség': Sending state 237.31400 V with 1 decimals of accuracy 14:44:41 [D] [cse7761:224]
Channel 1 power 0.000000 W, current 0.000000 A 14:44:41 [D] [sensor:094]
'WC világítás teljesítmény': Sending state 0.00000 W with 1 decimals of accuracy 14:44:41 [D] [sensor:094]
'WC világítás fogyasztás': Sending state 0.00406 kWh with 5 decimals of accuracy 14:44:41 [D] [sensor:094]
'WC világítás áramerősség': Sending state 0.00000 A with 2 decimals of accuracy 14:44:41 [D] [cse7761:224]
Channel 2 power 0.000000 W, current 0.000000 A 14:44:41 [D] [sensor:094]
'WC ventilátor teljesítmény': Sending state 0.00000 W with 1 decimals of accuracy 14:44:41 [D] [sensor:094]
'WC ventilátor fogyasztás': Sending state 0.00730 kWh with 5 decimals of accuracy 14:44:41 [D] [sensor:094]
'WC ventilátor áramerősség': Sending state 0.00000 A with 2 decimals of accuracy 14:44:41 [W] [component:204] Component cse7761.sensor took a long time for an operation (0.11 s). 14:44:41 [W] [component:205] Components should block for at most 20-30ms.

cse7761.sensor in ESPHome code: sensor:

What, how to modify?

andrewigali commented 11 months ago

Same problem with Sonoff Dual R3 v2.0 ESPHome 2023.8.2

21:09:02 | [W] | [component:204] | Component bl0939.sensor took a long time for an operation (0.08 s). -- | -- | -- | -- 21:09:02 | [W] | [component:205] | Components should block for at most 20-30ms. 21:09:02 | [W] | [component:205] | Components should block for at most 20-30ms.

ESPHome code:

uart: tx_pin: GPIO25 rx_pin: GPIO26 baud_rate: 4800 parity: EVEN stop_bits: 2

sensor:

These big problem! :(

Fabian-Schmidt commented 11 months 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. Or alternative if you don't care about logging to serial you can also set baud_rate: 0 to disable local logging completly.