Component xxxxxx took a long time for an operation

jesserockz commented 11 months 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.

nwf commented 11 months ago

Sorry, didn't see this one before filing #4716.

Another one for the pile is dallas.

jesserockz commented 11 months ago

@nwf thats alright as I posted this issue afterwards to stop future ones =)

Sebmaster commented 11 months ago

scd30 also causes this warning. This is the config I'm using:

  - platform: scd30
    co2:
      name: "CO2"
      accuracy_decimals: 0
    temperature:
      name: "Temperature"
      accuracy_decimals: 1
    humidity:
      name: "Humidity"
      accuracy_decimals: 1

BenCos17 commented 11 months ago

Ssd1306 causes it also

  - platform: ssd1306_i2c
    contrast: 0%
    model: "SH1106 128x64"
    reset_pin: D0
    address: 0x3C
    lambda: |-
      // Print "Bens' desk" in top center.
      it.printf(64, 0, id(font1), TextAlign::TOP_CENTER, "Bens' desk");

      // Print time in HH:MM format
      it.strftime(0, 60, id(font2), TextAlign::BASELINE_LEFT, "%H:%M", id(esptime).now());

      // Print inside temperature (from homeassistant sensor)
      if (id(bedroom_temp).has_state()) {
        it.printf(127, 23, id(font3), TextAlign::TOP_RIGHT , "%.1f°", id(bedroom_temp).state);
      }

      // Print bedroom co2 level (from homeassistant sensor)
      if (id(co2_bedroom).has_state()) {
        it.printf(127, 60, id(font3), TextAlign::BASELINE_RIGHT , "%.1f°", id(co2_bedroom).state);
      }

ntwb commented 11 months ago

Getting this on a BT proxy:

[14:12:10][W][component:204]: Component esp32_ble_tracker took a long time for an operation (0.06 s).
[14:12:10][W][component:205]: Components should block for at most 20-30ms.

FYI: The config below is based on the original implementation, I've not updated it since the BT Proxy launch, so it may be out of date and I need to update it...


esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true

button:
- platform: safe_mode
  name: Safe Mode Boot
  entity_category: diagnostic

sensor:
  - platform: ble_rssi
    mac_address: xx:yy:zz:11:22:33
    name: "BT Proxy RSSI"

billmaterial commented 11 months ago

A simple workaround for the ssd1306 128x64 display is to increase the i2c frequency to 400kHz. This fixed the warning for me. @BenCos17

i2c: sda: GPIO21 scl: GPIO22 scan: True id: bus_a frequency: 400kHz

jov58 commented 11 months ago

I also got these messages:

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

In the default situation, a device updates every second so these messages appear every second, They clutter up the log very rapidly, making it a lot harder to follow other log messages.

I also wonder if it is useful to show these messages when the device is working properly and its functionality isn't slowed down. I guess a long-time-blocking display can be a problem in some scenarios but not in others. I don't know if it's possible with the architecture of ESPHome/ESP8266/ESP32, but wouldn't it be possible to shown these warnings only when functionality is effected, for instance when a certain heartbeat can't be maintained?

Or perhaps show the warnings once a minute?

[18:18:12][W][component:204]: Component ssd1306_base took a long time for an operation (0.28 s), showed up 60 times.
[18:18:12][W][component:205]: Components should block for at most 20-30ms.

A simple workaround for the ssd1306 128x64 display is to increase the i2c frequency to 400kHz.

Didn't thought of that but it also worked on my SH1106 128*64, so thanks @billmaterial. At 200 kHz still warnings, at 400 kHz not anymore.

BenCos17 commented 11 months ago

frequency: 400kHz

thanks

JanSchnacki commented 11 months ago

I just upgraded to 2023.7.0 and recompiled my three NodeMCU stacks. After uploading I got this:

[15:05:53][C][htu21d:028]: HTU21D:
[15:05:53][C][htu21d:029]:   Address: 0x40
[15:05:53][C][htu21d:033]:   Update Interval: 60.0s
[15:05:53][C][htu21d:034]:   Temperature 'NodeMCUGaszaehler Temperature'
[15:05:53][C][htu21d:034]:     Device Class: 'temperature'
[15:05:53][C][htu21d:034]:     State Class: 'measurement'
[15:05:53][C][htu21d:034]:     Unit of Measurement: '°C'
[15:05:53][C][htu21d:034]:     Accuracy Decimals: 1
[15:05:53][C][htu21d:035]:   Humidity 'NodeMCUGaszaehler Humidity'
[15:05:53][C][htu21d:035]:     Device Class: 'humidity'
[15:05:53][C][htu21d:035]:     State Class: 'measurement'
[15:05:53][C][htu21d:035]:     Unit of Measurement: '%'
[15:05:53][C][htu21d:035]:     Accuracy Decimals: 1
[...]
[15:06:11][D][htu21d:065]: Got Temperature=22.2°C Humidity=67.1%
[15:06:11][W][component:204]: Component htu21d.sensor took a long time for an operation (0.11 s).
[15:06:11][W][component:205]: Components should block for at most 20-30ms.

The configuration is simply

# I2C Bus
i2c:
  sda: D2
  scl: D1
  scan: True
  id: bus_a

sensor:
  - platform: htu21d
    temperature:
      name: ${upper_devicename} Temperature
      unit_of_measurement: "°C"
      filters:
        - offset: -2.0
        - median:
    humidity:
      name: ${upper_devicename} Humidity
      unit_of_measurement: "%"
      filters:
        - median:
    update_interval: 60s

philpem commented 11 months ago

I'm seeing this, but with esphome.coroutine as the component name:

[15:58:58][W][component:204]: Component esphome.coroutine took a long time for an operation (0.05 s).
[15:58:58][W][component:205]: Components should block for at most 20-30ms.
[15:59:04][W][component:204]: Component esphome.coroutine took a long time for an operation (0.06 s).
[15:59:04][W][component:205]: Components should block for at most 20-30ms.
[15:59:10][W][component:204]: Component esphome.coroutine took a long time for an operation (0.06 s).
[15:59:10][W][component:205]: Components should block for at most 20-30ms.
[15:59:13][W][component:204]: Component esphome.coroutine took a long time for an operation (0.06 s).
[15:59:13][W][component:205]: Components should block for at most 20-30ms.
[15:59:25][W][component:204]: Component esphome.coroutine took a long time for an operation (0.05 s).
[15:59:25][W][component:205]: Components should block for at most 20-30ms.
[15:59:26][D][victron_ble:247]: [DE:54:84:5C:9D:4E] Recieved BATTERY_MONITOR message.
[15:59:27][D][victron_ble:247]: [DE:54:84:5C:9D:4E] Recieved BATTERY_MONITOR message.
[15:59:28][W][component:204]: Component esphome.coroutine took a long time for an operation (0.06 s).
[15:59:28][W][component:205]: Components should block for at most 20-30ms.
[15:59:31][W][component:204]: Component esphome.coroutine took a long time for an operation (0.05 s).
[15:59:31][W][component:205]: Components should block for at most 20-30ms.
[15:59:34][W][component:204]: Component esphome.coroutine took a long time for an operation (0.06 s).
[15:59:34][W][component:205]: Components should block for at most 20-30ms.
[15:59:37][D][victron_ble:242]: [E8:33:10:70:76:16] Recieved SOLAR_CHARGER message.
[15:59:37][W][component:204]: Component esphome.coroutine took a long time for an operation (0.07 s).
[15:59:37][W][component:205]: Components should block for at most 20-30ms.
[15:59:38][D][victron_ble:242]: [E8:33:10:70:76:16] Recieved SOLAR_CHARGER message.
[15:59:40][W][component:204]: Component esphome.coroutine took a long time for an operation (0.05 s).
[15:59:40][W][component:205]: Components should block for at most 20-30ms.
[15:59:41][D][victron_ble:247]: [DE:54:84:5C:9D:4E] Recieved BATTERY_MONITOR message.
[15:59:42][D][victron_ble:247]: [DE:54:84:5C:9D:4E] Recieved BATTERY_MONITOR message.
[15:59:51][D][victron_ble:247]: [DE:54:84:5C:9D:4E] Recieved BATTERY_MONITOR message.
[15:59:52][D][victron_ble:247]: [DE:54:84:5C:9D:4E] Recieved BATTERY_MONITOR message.
[15:59:53][D][victron_ble:247]: [DE:54:84:5C:9D:4E] Recieved BATTERY_MONITOR message.
[15:59:55][W][component:204]: Component esphome.coroutine took a long time for an operation (0.05 s).
[15:59:55][W][component:205]: Components should block for at most 20-30ms.
[16:00:07][D][victron_ble:242]: [E8:33:10:70:76:16] Recieved SOLAR_CHARGER message.
[16:00:07][D][api:102]: Accepted 192.168.100.2
[16:00:07][D][api.connection:1031]: Home Assistant 2023.7.2 (192.168.100.2): Connected successfully
[16:00:08][D][victron_ble:242]: [E8:33:10:70:76:16] Recieved SOLAR_CHARGER message.

Components in use are:

external_components:
  - source: github://Fabian-Schmidt/esphome-victron_ble

esp32:
  board: esp32dev
  framework:
    type: arduino

# BLE tracker, required for Victron BLE
esp32_ble_tracker:

# Victron BLE
victron_ble:

# Pipsolar - Easun (Voltronic) solar charger/inverter
uart:
  - id: uart_bus
    tx_pin: GPIO26
    rx_pin: GPIO27
    # most devices use 2400 as baud_rate
    baud_rate: 2400

pipsolar:
  - uart_id: uart_bus
    id: inverter0

I do have a Lambda set up to run when the Victron BLE picks up a charger status update.

wtremmel commented 11 months ago

I see this for my waveshare epaper display:

[20:31:59][W][component:204]: Component waveshare_epaper.display took a long time for an operation (0.98 s).

Config:

display:
  - platform: waveshare_epaper
    id: epaper
    cs_pin: GPIO17
    dc_pin: GPIO16
    reset_pin: GPIO15
    busy_pin: GPIO18
    reset_duration: 2ms
    model: 7.50inv2
    update_interval: 60s
    rotation: 0
    lambda: |-

snechiporenko commented 11 months ago

Look at my workaround https://github.com/esphome/feature-requests/issues/2301 for fix audio interrupt.

tiwu commented 11 months ago

I'm now seeing this reported for dsmr 0.8 as well:

[02:06:46][W][component:204]: Component dsmr took a long time for an operation (0.12 s).
[02:06:46][W][component:205]: Components should block for at most 20-30ms.

With the config as per https://github.com/mhendriks/esphome-p1/blob/main/p1-dongle-pro.yaml

Tagging @glmnet @zuidwijk for visibility, as they are codeowners for the DSMR component.

brettmiller commented 11 months ago

I'm seeing this:

[23:36:21][W][component:204]: Component esphome.coroutine took a long time for an operation (0.10 s).
[23:36:21][W][component:205]: Components should block for at most 20-30ms.
[23:36:23][W][component:204]: Component esphome.coroutine took a long time for an operation (0.10 s).
[23:36:23][W][component:205]: Components should block for at most 20-30ms.

When using the component:

external_components:
  - source: github://geoffdavis/esphome-mitsubishiheatpump@develop

climate:
  - platform: mitsubishi_heatpump
    name: "${name}"
    id: ${device_id}_climate
    hardware_uart: UART1
    tx_pin: 12
    rx_pin: 13
    visual:
      temperature_step: 1.0

Sausages69 commented 11 months ago

A simple workaround for the ssd1306 128x64 display is to increase the i2c frequency to 400kHz. This fixed the warning for me. @BenCos17

i2c: sda: GPIO21 scl: GPIO22 scan: True id: bus_a frequency: 400kHz

Thanks, (that below) fixed the error on the SH1106 here. Didn't fix the Dallas one though.

i2c:
frequency: 400kHz

pery777 commented 11 months ago

I'm seeing this, but with pn532 as the component name:

[07:58:54][W][component:204]: Component pn532 took a long time for an operation (0.10 s). [07:58:54][W][component:205]: Components should block for at most 20-30ms. [07:58:55][W][component:204]: Component pn532 took a long time for an operation (0.10 s). [07:58:55][W][component:205]: Components should block for at most 20-30ms. [07:58:56][W][component:204]: Component pn532 took a long time for an operation (0.10 s). [07:58:56][W][component:205]: Components should block for at most 20-30ms.

I am using the code:

https://github.com/adonno/tagreader/blob/master/tagreader.yaml

Rwin1234 commented 11 months ago

The dsmr component that reads out smart meters via a serial P1 connector shows this message every time the serial port receives data. My issue https://github.com/esphome/issues/issues/4731 was closed, but there could still be a dsmr component issue because the device frequently shows up in home assistant as available / unavailable via the Nmap Tracker integration. Taking a time-slice of 0.6 seconds is a lot and might interfere with the wifi / network stack.

INFO ESPHome 2023.7.0 INFO Reading configuration /config/esphome/p1-dongle-pro.yaml... INFO Starting log output from p1-dongle-pro.local using esphome API INFO Successfully connected to p1-dongle-pro.local [00:25:44][I][app:102]: ESPHome version 2023.7.0 compiled on Jul 22 2023, 00:14:13 [00:25:44][I][app:104]: Project smartstuff.p1_dongle_pro version v23.02.1 [00:25:45][W][component:204]: Component dsmr took a long time for an operation (0.61 s). [00:25:45][W][component:205]: Components should block for at most 20-30ms. [00:25:55][W][component:204]: Component dsmr took a long time for an operation (0.60 s). [00:25:55][W][component:205]: Components should block for at most 20-30ms. [00:26:05][W][component:204]: Component dsmr took a long time for an operation (0.61 s). [00:26:05][W][component:205]: Components should block for at most 20-30ms.

[repeats every 10 seconds]

If someone needs more info let me know.

andypnz commented 11 months ago

With ssd1306 I got the same errors

[12:49:47][W][component:204]: Component interval took a long time for an operation (0.27 s).
[12:49:47][W][component:205]: Components should block for at most 20-30ms.
[12:49:47][W][component:204]: Component ssd1306_base took a long time for an operation (0.27 s).
[12:49:47][W][component:205]: Components should block for at most 20-30ms.

Fixed by adding

frequency: 400kHz

Sparenzi commented 11 months ago

I have a ESP32 running an IR LED remote and a DHT11. I get the error message only when the climatecomponent is added to the code.

[17:43:29][D][dht:048]: Got Temperature=28.3°C Humidity=54.0% [17:43:29][D][sensor:094]: 'Temperature': Sending state 28.30000 °C with 1 decimals of accuracy [17:43:29][D][climate:378]: 'AC' - Sending state: [17:43:29][D][climate:381]: Mode: OFF [17:43:29][D][climate:386]: Fan Mode: LOW [17:43:29][D][climate:398]: Swing Mode: VERTICAL [17:43:29][D][climate:401]: Current Temperature: 28.30°C [17:43:29][D][climate:407]: Target Temperature: 25.00°C [17:43:29][D][sensor:094]: 'AC Remote Humidity': Sending state 54.00000 % with 0 decimals of accuracy [17:43:29][W][component:204]: Component dht.sensor took a long time for an operation (0.07 s). [17:43:29][W][component:205]: Components should block for at most 20-30ms.

ftw64 commented 11 months ago

I get this warning now with pzemac and modbus (on ESP8266):

uart:
  rx_pin: GPIO4
  tx_pin: GPIO5
  baud_rate: 9600

modbus:

sensor:
  - platform: pzemac
    address: 1
    current:
      name: "${name}: Current"
    voltage:
      name: "${name}: Voltage"
    energy:
      name: "${name}: Energy"
    power:
      name: "${name}: Power"
    frequency:
      name: "${name}: Frequency"
    power_factor:
      name: "${name}: Power Factor"
    update_interval: 2s

[19:26:56][D][pzemac:049]: PZEM AC: V=230.5 V, I=0.045 A, P=5.8 W, E=10155.0 Wh, F=50.0 Hz, PF=0.56
[19:26:56][D][sensor:093]: 'PZEM-Meter-01: Voltage': Sending state 230.50000 V with 1 decimals of accuracy
[19:26:56][D][sensor:093]: 'PZEM-Meter-01: Current': Sending state 0.04500 A with 3 decimals of accuracy
[19:26:56][D][sensor:093]: 'PZEM-Meter-01: Power': Sending state 5.80000 W with 2 decimals of accuracy
[19:26:56][D][sensor:093]: 'PZEM-Meter-01: Energy': Sending state 10155.00000 Wh with 0 decimals of accuracy
[19:26:56][D][sensor:093]: 'PZEM-Meter-01: Frequency': Sending state 50.00000 Hz with 1 decimals of accuracy
[19:26:56][D][sensor:093]: 'PZEM-Meter-01: Power Factor': Sending state 0.56000  with 2 decimals of accuracy
[19:26:56][W][component:204]: Component modbus took a long time for an operation (0.07 s).
[19:26:56][W][component:205]: Components should block for at most 20-30ms.

ftw64 commented 11 months ago

Another ESP8266 reporting these warnings:

uart:
  id: uart_bus
  tx_pin: TX
  rx_pin: RX
  baud_rate: 115200
  rx_buffer_size: 1500

dsmr:
  max_telegram_length: 1500

text_sensor:
  - platform: dsmr
    identification:
      name: "${name}: DSMR Identification"
    p1_version:
      name: "${name}: DSMR Version"

sensor:
  - platform: dsmr
    energy_delivered_tariff1:
      name: "${name}: Energy Consumed Tariff 1"
    energy_delivered_tariff2:
      name: "${name}: Energy Consumed Tariff 2"
    energy_returned_tariff1:
      name: "${name}: Energy Returned Tariff 1"
    energy_returned_tariff2:
      name: "${name}: Energy Returned Tariff 2"
    power_delivered:
      name: "${name}: Power Consumed"
    power_returned:
      name: "${name}: Power Returned"
    gas_delivered:
      name: "${name}: Gas Consumed"
    electricity_failures:
      name: "${name}: Electricity Failures"
    electricity_long_failures:
      name: "${name}: Long Electricity Failures"
    voltage_l1:
      name: "${name}: Voltage Phase 1"

[19:51:25][D][sensor:093]: 'P1-DSMR-01: Uptime': Sending state 161.98500 s with 0 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Energy Consumed Tariff 1': Sending state 13168.29590 kWh with 3 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Energy Consumed Tariff 2': Sending state 12658.14258 kWh with 3 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Energy Returned Tariff 1': Sending state 5330.78613 kWh with 3 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Energy Returned Tariff 2': Sending state 12150.04785 kWh with 3 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Power Consumed': Sending state 0.00000 kW with 3 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Power Returned': Sending state 0.09200 kW with 3 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Gas Consumed': Sending state 10522.21777 m³ with 3 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Electricity Failures': Sending state 4.00000  with 0 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Long Electricity Failures': Sending state 8.00000  with 0 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Power Consumed Phase 1': Sending state 0.00000 kW with 3 decimals of accuracy
[19:51:30][D][sensor:093]: 'P1-DSMR-01: Power Produced Phase 1': Sending state 0.09300 kW with 3 decimals of accuracy
[19:51:30][D][text_sensor:064]: 'P1-DSMR-01: DSMR Identification': Sending state 'KFM5KAIFA-METER'
[19:51:30][D][text_sensor:064]: 'P1-DSMR-01: DSMR Version': Sending state '42'
[19:51:30][W][component:204]: Component dsmr took a long time for an operation (0.07 s).
[19:51:30][W][component:205]: Components should block for at most 20-30ms.

ftw64 commented 11 months ago

And another one (ESP32):

uart:
  - id: uart_2
    rx_pin: GPIO16
    tx_pin: GPIO17
    baud_rate: 9600

# A number of One-Wire sensors can be added to the ESP32.
dallas:
  - pin: GPIO27
    update_interval: 2s

output:
  - platform: ledc
    id: onboard_led
    pin:
      number: GPIO25

text_sensor:
  - platform: template
    name: "${name}: Monitor Status"
    id: monitor_status
    icon: "mdi:text-box"

  - platform: template
    # Response of "REV": ROM 1 CRC
    name: "${name}: Heater ROM 1 Checksum"
    id: rom_test_1_checksum
    icon: "mdi:text-box"

  - platform: template
    # Response of "REV": ROM 2 CRC
    name: "${name}: Heater ROM 2 Checksum"
    id: rom_test_2_checksum
    icon: "mdi:text-box"

  - platform: template
    # Response of "REV": Software release (i.e., "v2.71")
    name: "${name}: Heater Software release"
    id: software_release
    icon: "mdi:text-box"

  - platform: template
    # Response of "REV": Hardware release (i.e., "ic2kknl01*P080925*")
    name: "${name}: Heater Hardware release"
    id: hardware_release
    icon: "mdi:text-box"

# NOT SUPPORTED ON HRE 36/30 (2009, v2.71 software): "REW"
# - platform: template
#   name: "${name}: Heater DSP ROM 1 Checksum"
#   id: dsp_rom_test_1_checksum
#   icon: "mdi:text-box"
#
# - platform: template
#   name: "${name}: Heater DSP ROM 2 Checksum"
#   id: dsp_rom_test_2_checksum
#   icon: "mdi:text-box"
#
# - platform: template
#   name: "${name}: Heater DSP Hardware release"
#   id: dsp_hardware_release
#   icon: "mdi:text-box"
#
# - platform: template
#   name: "${name}: Heater DSP Software release"
#   id: dsp_software_release
#   icon: "mdi:text-box"

  - platform: template
    # Response of "S?\r": Current fault code
    name: "${name}: Fault Code"
    id: heater_fault_code
    icon: "mdi:text-box"

  - platform: template
    # Response of "S?\r": Last fault code
    name: "${name}: Last Fault code"
    id: heater_last_fault_code
    icon: "mdi:text-box"

  - platform: template
    # Response of "S?\r": Heater status:
    #  "Hot water delivery"
    #  "Central Heating active"
    #  "Central Heating idle"
    #  "Hot water ramp down"
    #  "Central Heating ramp down"
    #  "Code: " 
    name: "${name}: Heater Status code"
    id: heater_status_code
    icon: "mdi:text-box"

  - platform: template
    # Response of "S?\r": LT/HT zone valve
    name: "${name}: LT/HT Zone valve"
    id: heater_dwk
    icon: "mdi:valve"

  - platform: template
    # Response of "B?\r": Unknown
    name: "${name}: Production Code"
    id: production_code
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r": heater on
    name: "${name}: Param 01 Heater On"
    id: param_heater_on
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 02 Comfort Mode"
    id: param_comfort_mode
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 03 CV Max Temp"
    id: param_CV_max_temp
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 04 DHW Max Temp"
    id: param_DHW_max_temp
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 05 ECO Days"
    id: param_eco_days
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 06 Comfort Set"
    id: param_comfort_set
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 07 DHW Max Temp at Night"
    id: dhw_at_night
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 08 CV Max Temp at Night"
    id: ch_at_night
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 11 1"
    id: param_1
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 12 2"
    id: param_2
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 13 3"
    id: param_3
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 14 4"
    id: param_4
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 15 5"
    id: param_5
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 16 6"
    id: param_6
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 17 7"
    id: param_7
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 18 8"
    id: param_8
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 19 9"
    id: param_9
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 20 A"
    id: param_A
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 21 b"
    id: param_b
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 22 C"
    id: param_C
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 23 c"
    id: param_c
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 24 d"
    id: param_d
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 25 E"
    id: param_E
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 26 E."
    id: param_Ed
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 27 F"
    id: param_F
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 28 H"
    id: param_H
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 29 n"
    id: param_n
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 30 o"
    id: param_o
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 31 P"
    id: param_P
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 32 r"
    id: param_r
    icon: "mdi:text-box"

  - platform: template
    # Reponse of "V?\r":
    name: "${name}: Param 33 F."
    id: param_Fd
    icon: "mdi:text-box"

binary_sensor:

  - platform: template
    # Response of "S?\r": Ground pin status?
    name: "${name}: GP Switch"
    id: heater_gp_switch
    icon: "mdi:switch"

  - platform: template
    # Response of "S?\r": Tap switch status
    name: "${name}: Tap Switch"
    id: heater_tap_switch
    icon: "mdi:switch"
    device_class: opening

  - platform: template
    # Response of "S?\r": Room thermostat status
    name: "${name}: Room Thermostat"
    id: heater_roomtherm
    icon: "mdi:switch"
    device_class: connectivity

  - platform: template
    # Response of "S?\r": CV pump status
    name: "${name}: Heater Pump"
    id: heater_pump_running
    icon: "mdi:pump"
    device_class: running

  - platform: template
    # Response of "S?\r": Heater alarm status
    name: "${name}: Alarm status"
    id: heater_alarm_status
    icon: "mdi:alarm-light"
    device_class: problem

  - platform: template
    # Response of "S?\r": Unknown
    name: "${name}: Cascade Relay"
    id: heater_cascade_relay
    icon: "mdi:switch"
    device_class: connectivity

  - platform: template
    # Response of "S?\r": Open-Therm status
    name: "${name}: Heater Open-Therm"
    id: heater_open_therm
    icon: "mdi:current-ac"
    device_class: connectivity

  - platform: template
    # Response of "S?\r": Gas valve status
    name: "${name}: Gas valve"
    id: heater_gas_valve
    icon: "mdi:valve"
    device_class: opening

  - platform: template
    # Response of "S?\r": Spark active status
    name: "${name}: Spark active"
    id: heater_spark
    icon: "mdi:lightning-bolt"

  - platform: template
    # Response of "S?\r": Heater ionisation status
    name: "${name}: Ionisation signal"
    id: heater_ionisation_signal
    icon: "mdi:lightning-bolt"

  - platform: template
    # Response of "S?\r": Open Therm status
    name: "${name}: Open Therm disabled"
    id: heater_ot_disabled
    icon: "mdi:switch"

  - platform: template
    # Response of "S?\r": Low water pressure status
    name: "${name}: Low water pressure"
    id: heater_has_low_water_pressure
    icon: "mdi:gauge"

  - platform: template
    # Response of "S?\r": Burner block status
    name: "${name}: Burner block"
    id: heater_burner_block
    icon: "mdi:fire"

  - platform: template
    # Response of "S?\r": Heater gradient flag status
    name: "${name}: Gradient flag"
    id: heater_gradient_flag
    icon: "mdi:switch"

sensor:
  - platform: dallas
    # Please modify the address to that of a connected DS18B20 sensor.
    address: 0x1b031674f1eeff28
    name: "${name}: T-CV warm water temperature"
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: dallas
    # Please modify the address to that of a connected DS18B20 sensor.
    address: 0xf00516738e81ff28
    name: "${name}: T-CV cold water temperature"
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: dallas
    # Please modify the address to that of a connected DS18B20 sensor.
    address: 0x55031674d2cdff28
    name: "${name}: T-CV exhaust fume temperature"
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": temperature of the heat exchanger
    name: "${name}: Heat Exchanger Temperature (S0)"
    id: temperature_heat_exchanger
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": CV water outgoing temperature
    name: "${name}: Delivery Temperature (S1)"
    id: temperature_flow
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": Hot water outgoing temperature
    name: "${name}: Hot water Temperature (S3)"
    id: temperature_hot_water
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": Cold water temperature (appears to be stuck to -32 C)
    name: "${name}: Cold Water Temperature (S7)"
    id: temperature_cold_water
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": Not sure what this would be (appears to be stuck to -32 C)
    name: "${name}: Flue gas Temperature (S5)"
    id: temperature_flue_gas
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": Temperature setpoint (requested CV water outgoing temperature)
    name: "${name}: Setpoint"
    id: temperature_setpoint
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": Unknown (appears to be stuck at 15.75 C)
    name: "${name}: Outside Temperature (S6)"
    id: temperature_outside
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": Unknown (appears to be stuck at 15.75 C)
    name: "${name}: Solar Boiler Outflow temperature"
    id: temperature_boiler_to_heater
    unit_of_measurement: °C
    accuracy_decimals: 0
    device_class: temperature

  - platform: template
    # Response of "S?\r": Pressure in heater
    name: "${name}: Heater Pressure"
    id: pressure
    icon: "mdi:gauge-full"
    unit_of_measurement: BAR
    accuracy_decimals: 1

  - platform: template
    # Response of "S?\r": Unknown
    name: "${name}: Heater IO Current"
    id: heater_io_current
    icon: "mdi:current-dc"
    accuracy_decimals: 2
    unit_of_measurement: µA

#  - platform: template
#    # Response of "S?\r": CV return water temperature (not available on HRE)
#    name: "${name}: Return Temperature"
#    id: temperature_return
#    unit_of_measurement: °C
#    accuracy_decimals: 0
#    device_class: temperature

# NOT SUPPORTED ON HRE 36/30 (2009, v2.71 software): "H0\r"
# - platform: template
#   name: "${name}: Line power connected time"
#   id: line_power_connected_hours
#   icon: "mdi:clock-start"
#   unit_of_measurement: Hours
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Line power connected"
#   id: line_power_connected_count
#   icon: "mdi:counter"
#   unit_of_measurement: Count
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Central Heating Usage"
#   id: ch_function_hours
#   icon: "mdi:clock-start"
#   unit_of_measurement: Hours
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Domestic Hot Water Usage"
#   id: dhw_function_hours
#   icon: "mdi:clock-start"
#   unit_of_measurement: Hours
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Burner start count"
#   id: burner_start_count
#   icon: "mdi:counter"
#   unit_of_measurement: Starts
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Ignition failed"
#   id: ignition_failed
#   icon: "mdi:counter"
#   unit_of_measurement: Failures
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Flame lost"
#   id: flame_lost
#   icon: "mdi:counter"
#   unit_of_measurement: Losses
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Reset"
#   id: reset_count
#   icon: "mdi:counter"
#   unit_of_measurement: Resets
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Gas meter Central Heating"
#   id: gas_meter_ch
#   icon: "mdi:meter-gas"
#   unit_of_measurement: m3
#   accuracy_decimals: 4
#
# - platform: template
#   name: "${name}: Gas meter Domestic Hot Water"
#   id: gas_meter_dhw
#   icon: "mdi:meter-gas"
#   unit_of_measurement: m3
#   accuracy_decimals: 4
#
# - platform: template
#   name: "${name}: Water meter"
#   id: water_meter
#   icon: "mdi:gauge"
#   unit_of_measurement: m3
#   accuracy_decimals: 4
#
# - platform: template
#   name: "${name}: Burner starts Domestic Hot Water count"
#   id: burner_starts_dhw_count
#   icon: "mdi:counter"
#   unit_of_measurement: Starts
#   accuracy_decimals: 0
#

# NOT SUPPORTED ON HRE 36/30 (2009, v2.71 software): "D2\r"
# - platform: template
#   name: "${name}: Fan setpoint"
#   id: fanspeed_set
#   icon: "mdi:fan"
#   unit_of_measurement: RPM
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Fan Current speed"
#   id: fanspeed
#   icon: "mdi:fan"
#   unit_of_measurement: RPM
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Pump setpoint"
#   id: pumpspeed_set
#   icon: "mdi:pump"
#   unit_of_measurement: RPM
#   accuracy_decimals: 0
#
# - platform: template
#   name: "${name}: Pump Current speed"
#   id: pumpspeed
#   icon: "mdi:pump"
#   unit_of_measurement: RPM
#   accuracy_decimals: 0
#
#  - platform: template
#    name: "${name}: Heat Exchanger 2 Temperature"
#    id: temperature_heat_exchanger_2
#    unit_of_measurement: °C
#    accuracy_decimals: 2
#    device_class: temperature
#
#  - platform: template
#    name: "${name}: Valve Position setpoint"
#    id: valve_pos_set
#    icon: "mdi:valve"
#    accuracy_decimals: 0
#
#  - platform: template
#    name: "${name}: Valve Position"
#    id: valve_pos
#    icon: "mdi:valve"
#    accuracy_decimals: 0
#

# NOT SUPPORTED ON HRE 36/30 (2009, v2.71 software): "S2\r"
# - platform: template
#   name: "${name}: Zone 1 room override"
#   id: zone1_room_override
#   unit_of_measurement: °C
#   accuracy_decimals: 2
#   device_class: temperature
#
# - platform: template
#   name: "${name}: Zone 1 room setpoint"
#   id: zone1_room_setpoint
#   unit_of_measurement: °C
#   accuracy_decimals: 2
#   device_class: temperature
#
# - platform: template
#   name: "${name}: Zone 1 room Temperature"
#   id: zone1_room_temperature
#   unit_of_measurement: °C
#   accuracy_decimals: 2
#   device_class: temperature
#
# - platform: template
#   name: "${name}: Zone 2 room override"
#   id: zone2_room_override
#   unit_of_measurement: °C
#   accuracy_decimals: 2
#   device_class: temperature
#
# - platform: template
#   name: "${name}: Zone 2 room setpoint"
#   id: zone2_room_setpoint
#   unit_of_measurement: °C
#   accuracy_decimals: 2
#   device_class: temperature
#
# - platform: template
#   name: "${name}: Zone 2 room Temperature"
#   id: zone2_room_temperature
#   unit_of_measurement: °C
#   accuracy_decimals: 2
#   device_class: temperature
#
# - platform: template
#   name: "${name}: Outside override Temperature"
#   id: override_outside_temp
#   unit_of_measurement: °C
#   accuracy_decimals: 2
#   device_class: temperature
#
# - platform: template
#   name: "${name}: Tap flow"
#   id: tapflow
#   icon: "mdi:water-pump"
#   unit_of_measurement: '%'
#   accuracy_decimals: 0
#

custom_component:
  - lambda: |-
      return {new IntergasMonitorHRE3630()};
    components:
      - id: intergas_monitor_hre3630

[19:51:58][D][dallas.sensor:143]: 'HRE3630: T-CV warm water temperature': Got Temperature=21.8°C
[19:51:58][D][sensor:094]: 'HRE3630: T-CV warm water temperature': Sending state 21.81250 °C with 0 decimals of accuracy
[19:51:58][D][dallas.sensor:143]: 'HRE3630: T-CV cold water temperature': Got Temperature=22.1°C
[19:51:58][D][sensor:094]: 'HRE3630: T-CV cold water temperature': Sending state 22.06250 °C with 0 decimals of accuracy
[19:51:58][D][dallas.sensor:143]: 'HRE3630: T-CV exhaust fume temperature': Got Temperature=22.1°C
[19:51:58][D][sensor:094]: 'HRE3630: T-CV exhaust fume temperature': Sending state 22.12500 °C with 0 decimals of accuracy
[19:52:00][D][dallas.sensor:143]: 'HRE3630: T-CV warm water temperature': Got Temperature=21.8°C
[19:52:00][D][sensor:094]: 'HRE3630: T-CV warm water temperature': Sending state 21.81250 °C with 0 decimals of accuracy
[19:52:00][D][dallas.sensor:143]: 'HRE3630: T-CV cold water temperature': Got Temperature=22.1°C
[19:52:00][D][sensor:094]: 'HRE3630: T-CV cold water temperature': Sending state 22.06250 °C with 0 decimals of accuracy
[19:52:00][D][dallas.sensor:143]: 'HRE3630: T-CV exhaust fume temperature': Got Temperature=22.1°C
[19:52:00][D][sensor:094]: 'HRE3630: T-CV exhaust fume temperature': Sending state 22.12500 °C with 0 decimals of accuracy
[19:52:00][D][text_sensor:064]: 'HRE3630: Monitor Status': Sending state 'Fetching: S?\r'
[19:52:00][D][Intergas HRE:210]: Send command S?\r
[19:52:01][D][text_sensor:064]: 'HRE3630: Monitor Status': Sending state 'Processing...'
[19:52:01][D][sensor:094]: 'HRE3630: Heat Exchanger Temperature (S0)': Sending state 65.29000 °C with 0 decimals of accuracy
[19:52:01][D][sensor:094]: 'HRE3630: Delivery Temperature (S1)': Sending state 57.65000 °C with 0 decimals of accuracy
[19:52:01][D][sensor:094]: 'HRE3630: Hot water Temperature (S3)': Sending state 46.44000 °C with 0 decimals of accuracy
[19:52:01][D][sensor:094]: 'HRE3630: Heater Pressure': Sending state 1.75000 BAR with 1 decimals of accuracy
[19:52:01][W][component:204]: Component custom_component took a long time for an operation (0.09 s).
[19:52:01][W][component:205]: Components should block for at most 20-30ms.

[19:53:34][D][dallas.sensor:143]: 'HRE3630: T-CV warm water temperature': Got Temperature=21.8°C
[19:53:34][D][sensor:094]: 'HRE3630: T-CV warm water temperature': Sending state 21.75000 °C with 0 decimals of accuracy
[19:53:34][D][dallas.sensor:143]: 'HRE3630: T-CV cold water temperature': Got Temperature=22.1°C
[19:53:34][D][sensor:094]: 'HRE3630: T-CV cold water temperature': Sending state 22.06250 °C with 0 decimals of accuracy
[19:53:34][D][dallas.sensor:143]: 'HRE3630: T-CV exhaust fume temperature': Got Temperature=22.1°C
[19:53:34][D][sensor:094]: 'HRE3630: T-CV exhaust fume temperature': Sending state 22.12500 °C with 0 decimals of accuracy
[19:53:36][D][dallas.sensor:143]: 'HRE3630: T-CV warm water temperature': Got Temperature=21.8°C
[19:53:36][D][sensor:094]: 'HRE3630: T-CV warm water temperature': Sending state 21.81250 °C with 0 decimals of accuracy
[19:53:36][D][dallas.sensor:143]: 'HRE3630: T-CV cold water temperature': Got Temperature=22.1°C
[19:53:36][D][sensor:094]: 'HRE3630: T-CV cold water temperature': Sending state 22.06250 °C with 0 decimals of accuracy
[19:53:36][D][dallas.sensor:143]: 'HRE3630: T-CV exhaust fume temperature': Got Temperature=22.1°C
[19:53:36][D][sensor:094]: 'HRE3630: T-CV exhaust fume temperature': Sending state 22.12500 °C with 0 decimals of accuracy
[19:53:36][D][text_sensor:064]: 'HRE3630: Current time': Sending state '2023-07-23 19:53:36 CEST'
[19:53:37][D][text_sensor:064]: 'HRE3630: Monitor Status': Sending state 'Fetching: S?\r'
[19:53:37][D][Intergas HRE:210]: Send command S?\r
[19:53:37][D][text_sensor:064]: 'HRE3630: Monitor Status': Sending state 'Processing...'
[19:53:37][D][sensor:094]: 'HRE3630: Heat Exchanger Temperature (S0)': Sending state 64.58000 °C with 0 decimals of accuracy
[19:53:37][D][sensor:094]: 'HRE3630: Delivery Temperature (S1)': Sending state 57.56000 °C with 0 decimals of accuracy
[19:53:37][D][sensor:094]: 'HRE3630: Hot water Temperature (S3)': Sending state 45.98000 °C with 0 decimals of accuracy
[19:53:37][D][sensor:094]: 'HRE3630: Heater Pressure': Sending state 1.75000 BAR with 1 decimals of accuracy
[19:53:37][W][component:204]: Component custom_component took a long time for an operation (0.09 s).
[19:53:37][W][component:205]: Components should block for at most 20-30ms.

descipher commented 11 months ago

Tack on atm90e32

23:00:40 | [W] | [component:204] | Component atm90e32.sensor took a long time for an operation (0.05 s). 23:00:40 | [W] | [component:205] | Components should block for at most 20-30ms.

jeleniain commented 11 months ago

Hi guys, stumbled upon this thread trying to figure out the issue. I am also seeing the warning following warning after updating my ESPHome to 2023.7.0 and updating my two tag readers:

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

and are also using the code from: https://github.com/adonno/tagreader/blob/master/tagreader.yaml

The odd thing is that I have two of the exact same tag readers with identical code (except for a different static IP address) and only one of them is throwing the warning. I tried to re-flash the device but same behavior. Not sure what to make of it.

Edit: I increased the delay for the pn532_i2c from 0.15s to 0.3s without any impact. Also ensure the frequency is set to 400kHz as this was mentioned in the thread.

thatslolo commented 11 months ago

[esp32.preferences:143]: Saving 7 preferences to flash: 2 cached, 5 written, 0 failed
[W][component:204]: Component preferences took a long time for an operation (0.06 s).
[component:205]: Components should block for at most 20-30ms.

Don't know which integration causes this. I do have multiple integration sensors and globals with restore configured, I guess these are the culprits.

globals:
  - id: rgb_ready
    type: bool
    restore_value: false
    initial_value: 'false'
  - id: total_energy
    type: float
    restore_value: true
    # initial_value: '5.96'
  - id: energy_current_run_
    type: float
    restore_value: true
  - id: energy_last_run_
    type: float
    restore_value: true
  - id: energy_current_month_
    type: float
    restore_value: true
  - id: start_time
    type: float
    restore_value: true
  - id: duration_last_run_
    type: float
    restore_value: true

sensor:
  - platform: total_daily_energy
    name: "${channel_1} monthly energy"
    power_id: power
    restore: true
    state_class: total_increasing
    unit_of_measurement: kWh
    filters:
      # Multiplication factor from W to kW is 0.001
      - multiply: 0.001
      - lambda: !lambda |-
          static auto last_state = x;
          if (x < last_state) { // x was reset
            id(total_energy) += last_state;
            ESP_LOGI("main", "Energy channel 1 was reset: %f", id(total_energy));
          }
          last_state = x;
          return id(total_energy) + x;

  - platform: integration
    name: "Energy Current Run"
    sensor: power
    id: energy_current_run
    time_unit: h
    unit_of_measurement: "kWh"
    restore: true
    filters:
      # Multiplication factor from W to kW is 0.001
      - multiply: 0.001
      - lambda: |-
          id(energy_current_run_) = x;
          return x;

  - platform: integration
    name: "Energy Current Month"
    sensor: power
    id: energy_current_month
    time_unit: h
    unit_of_measurement: "kWh"
    restore: true
    filters:
      # Multiplication factor from W to kW is 0.001
      - multiply: 0.001
      - lambda: |-
          id(energy_current_month_) = x;
          return x;

  - platform: template
    name: "Energy Last Run"
    icon: 'mdi:flash-outline'
    id: energy_last_run
    lambda: return id(energy_last_run_);
    accuracy_decimals: 3
    device_class: 'energy'
    state_class: 'total'
    unit_of_measurement: "kWh"
    # update_interval: 60s

  - platform: template
    name: "Duration Last Run"
    icon: 'mdi:timer'
    id: duration
    lambda: return id(duration_last_run_);
    accuracy_decimals: 0
    device_class: 'duration'
    state_class: 'total'
    unit_of_measurement: "s"
    # update_interval: 60s

shannonfritz commented 11 months ago

I just saw this after updating my Emporia Vue 2 using ESPHome 2023.7.0. This is after doing a "clean build files" before installing the updated config file.

Processing emporia1 (board: esp32dev; framework: espidf; platform: platformio/espressif32@5.3.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash

The base of the configuration came from here https://github.com/emporia-vue-local/esphome and after installing successfully, the log starts showing this warning every ~30s

[17:01:14][W][component:204]: Component emporia_vue.sensor took a long time for an operation (0.06 s).
[17:01:14][W][component:205]: Components should block for at most 20-30ms.
[17:01:45][W][component:204]: Component emporia_vue.sensor took a long time for an operation (0.06 s).
[17:01:45][W][component:205]: Components should block for at most 20-30ms.
[17:02:16][W][component:204]: Component emporia_vue.sensor took a long time for an operation (0.06 s).
[17:02:16][W][component:205]: Components should block for at most 20-30ms.

The config is quite large, so I collapsed it in a details view below...

emporia.yaml

``` # Emporia Vue 2 # 2023-Jul-24 # - Changed Source for external_components (https://github.com/emporia-vue-local/esphome) # - Added "Unaccounted Power" sensor for power not recorded on the smaller clamps # - Added buzzer and light components # - Added uptime sensor # 2022-Feb-03 # - Initial build based on https://gist.github.com/flaviut/93a1212c7b165c7674693a45ad52c512 substitutions: devicename: "Emporia1" deviceid: "emporia1" esphome: name: "${deviceid}" external_components: - source: github://emporia-vue-local/esphome@dev components: [ emporia_vue ] esp32: board: esp32dev framework: type: esp-idf version: recommended # Enable logging logger: logs: # Don't log on each sensor reading, that's way too loud. We can see them in # Home Assistant anyway, or re-enable them per-device if needed. sensor: INFO # Enable Home Assistant API api: services: - service: play_rtttl variables: song_str: string then: - rtttl.play: rtttl: !lambda 'return song_str;' ota: password: !secret ota_password wifi: ssid: !secret wifi_ssid password: !secret wifi_password domain: !secret wifi_domain fast_connect: on # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "${devicename} Fallback Hotspot" password: !secret wifi_fallbackpassword preferences: # default of 1min is far too short, flash chip is rated for ~100k writes # Slow that WAY down to preserve the hardware lifetime! flash_write_interval: "48h" output: - platform: ledc pin: GPIO12 id: buzzer - platform: gpio pin: GPIO27 id: buzzer_gnd rtttl: output: buzzer on_finished_playback: - logger.log: 'Song ended!' button: - platform: template name: "Two Beeps" on_press: - rtttl.play: "two short:d=4,o=5,b=100:16e6,16e6" light: - platform: status_led name: "D3_LED" pin: 23 restore_mode: ALWAYS_ON entity_category: config i2c: sda: 21 scl: 22 scan: false frequency: 200kHz # recommended range is 50-200kHz id: i2c_a time: - platform: sntp id: my_time servers: - mtqq.digi - pool.ntp.org # these are called references in YAML. They allow you to reuse # this configuration in each sensor, while only defining it once .defaultfilters: - &moving_avg # adjust these to fit your needs # we capture a new sample every 0.24 seconds, so the time can # be calculated from the number of samples as n * 0.24. sliding_window_moving_average: window_size: 120 # average over the past 28.8 seconds send_every: 60 # # we push a new value every 14.4 seconds - &pos # filter out any values below 0. You may want to disable # this filter while configuring your system to make sure you # don't get any consistently negative values. #lambda: 'return x;' # no-op lambda: 'return max(x, 0.0f);' - &invert # invert and filter out any values below 0. lambda: 'return max(-x, 0.0f);' - &abs # take the absolute value of the value lambda: 'return abs(x);' sensor: - platform: uptime name: "Up time" id: up_time entity_category: diagnostic icon: "mdi:timer-outline" - platform: emporia_vue i2c_id: i2c_a phases: - id: phase_a input: BLACK #calibration: 0.022 # 0.022 is used as the default as starting point but may need adjusted to ensure accuracy voltage: name: "${devicename} Phase A Voltage" filters: [*moving_avg, *pos] - id: phase_b input: RED #calibration: 0.022 # 0.022 is used as the default as starting point but may need adjusted to ensure accuracy voltage: name: "${devicename} Phase B Voltage" filters: [*moving_avg, *pos] #phase_angle: # name: "${devicename} Phase B Angle" # filters: [*moving_avg, *pos] ct_clamps: # The two bigger clamps monitoring total usage between the power company and the panel - phase_id: phase_a input: "A" power: name: "${devicename} Phase A Power" id: phase_a_power device_class: power filters: [*moving_avg, *pos] - phase_id: phase_b input: "B" power: name: "${devicename} Phase B Power" id: phase_b_power device_class: power filters: [*moving_avg, *pos] # The 16 smaller clamps between the breaker and the load - { phase_id: phase_a, input: "1", power: { name: "${devicename} Circuit 01 Power", id: cir01, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_b, input: "2", power: { name: "${devicename} Circuit 02 Power", id: cir02, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_a, input: "3", power: { name: "${devicename} Circuit 03 Power", id: cir03, filters: [ *moving_avg, *pos, multiply: 2 ] } } - { phase_id: phase_a, input: "4", power: { name: "${devicename} Circuit 04 Power", id: cir04, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_b, input: "5", power: { name: "${devicename} Circuit 05 Power", id: cir05, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_a, input: "6", power: { name: "${devicename} Circuit 06 Power", id: cir06, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_b, input: "7", power: { name: "${devicename} Circuit 07 Power", id: cir07, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_b, input: "8", power: { name: "${devicename} Circuit 08 Power", id: cir08, filters: [ *moving_avg, *pos, multiply: 2 ] } } - { phase_id: phase_a, input: "9", power: { name: "${devicename} Circuit 09 Power", id: cir09, filters: [ *moving_avg, *pos, multiply: 2 ] } } - { phase_id: phase_b, input: "10", power: { name: "${devicename} Circuit 10 Power", id: cir10, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_a, input: "11", power: { name: "${devicename} Circuit 11 Power", id: cir11, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_a, input: "12", power: { name: "${devicename} Circuit 12 Power", id: cir12, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_a, input: "13", power: { name: "${devicename} Circuit 13 Power", id: cir13, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_b, input: "14", power: { name: "${devicename} Circuit 14 Power", id: cir14, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_b, input: "15", power: { name: "${devicename} Circuit 15 Power", id: cir15, filters: [ *moving_avg, *pos ] } } - { phase_id: phase_a, input: "16", power: { name: "${devicename} Circuit 16 Power", id: cir16, filters: [ *moving_avg, *pos ] } } # Use Helper Sensors to store the values from the small clamps over time (daily) - { power_id: cir01, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 01 Daily Energy" } - { power_id: cir02, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 02 Daily Energy" } - { power_id: cir03, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 03 Daily Energy" } - { power_id: cir04, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 04 Daily Energy" } - { power_id: cir05, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 05 Daily Energy" } - { power_id: cir06, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 06 Daily Energy" } - { power_id: cir07, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 07 Daily Energy" } - { power_id: cir08, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 08 Daily Energy" } - { power_id: cir09, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 09 Daily Energy" } - { power_id: cir10, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 10 Daily Energy" } - { power_id: cir11, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 11 Daily Energy" } - { power_id: cir12, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 12 Daily Energy" } - { power_id: cir13, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 13 Daily Energy" } - { power_id: cir14, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 14 Daily Energy" } - { power_id: cir15, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 15 Daily Energy" } - { power_id: cir16, platform: total_daily_energy, accuracy_decimals: 0, name: "${devicename} Circuit 16 Daily Energy" } # Combine the readings of the two bigger clamps to get total power on both phases - platform: template name: "${devicename} Total Power" id: total_power device_class: power state_class: measurement update_interval: 10s unit_of_measurement: "W" lambda: return id(phase_a_power).state + id(phase_b_power).state; # Use a Helper Sensor to record the total power readings over time (daily) - platform: total_daily_energy name: "${devicename} Total Daily Energy" power_id: total_power accuracy_decimals: 0 # The remaining balance of power that is not accounted for by the 16 sensors (unmoniotred circuits) # ... Subtract the Power recorded on the smaller clamps from Power recorded on the two big clamps - platform: template name: "Unaccounted Power" id: unaccounted_power lambda: !lambda |- return max(0.0f, id(total_power).state - id(cir01).state - id(cir02).state - id(cir03).state - id(cir04).state - id(cir05).state - id(cir06).state - id(cir07).state - id(cir08).state - id(cir09).state - id(cir10).state - id(cir11).state - id(cir12).state - id(cir13).state - id(cir14).state - id(cir15).state - id(cir16).state); update_interval: 10s device_class: power state_class: measurement unit_of_measurement: "W" # Use a Helper Sensor to record the total power readings over time (daily) - platform: total_daily_energy name: "Unaccounted Daily Energy" power_id: unaccounted_power accuracy_decimals: 0 ```

Kyryer commented 11 months ago

mh-z19 causes this warning too. i see trouble only with mh-z19

this is the using config:

uart:
  rx_pin: GPIO12
  tx_pin: GPIO14
  baud_rate: 9600

dallas:
  - pin: GPIO2
    update_interval: 30s

sensor:
  - platform: mhz19
    co2:
      name: "MH-Z19 CO2 Value"
    temperature:
      name: "MH-Z19 Temperature"
    update_interval: 60s
    automatic_baseline_calibration: false
  - platform: dallas
    address: 0xdd0116003599ff28
    name: "D18B20 Temperature"
    resolution: 12

i try update interval for mh-z19 30s and 60s - result is not different

log:

[02:24:25][D][sensor:093]: 'MH-Z19 CO2 Value': Sending state 400.00000 ppm with 0 decimals of accuracy
[02:24:25][D][sensor:093]: 'MH-Z19 Temperature': Sending state 27.00000 °C with 0 decimals of accuracy
[02:24:25][W][component:204]: Component mhz19.sensor took a long time for an operation (0.06 s).
[02:24:25][W][component:205]: Components should block for at most 20-30ms.

descipher commented 11 months ago

@jesserockz There appears to be a large number of components which do not use callbacks. Seems to be the main reason for the blocking. I did some digging with atm90e32 and its not doing anything heavy but it still runs just under 50ms to do its fundamental outputs, we could certainly lower the amount a serial logging on some of the components. But I would assume the right path is to convert them to use callbacks where possible.

descipher commented 11 months ago

For anyone reporting here, the blocking warning message was previously exposed when enabling verbose logging. The blocking event message should be a warning and thus why it was changed. We should address them as time permits. Please keep adding them here.

cnovicktx commented 11 months ago

SSD1306 using SPI suffering from the same log entry issue

The 'frequency: 400kHz' fix only applies to i2c interface and not SPI

descipher commented 11 months ago

SSD1306 using SPI suffering from the same log entry issue

The 'frequency: 400kHz' fix only applies to i2c interface and not SPI

Probably not the same issue on the spi based code: e.g. class SPISSD1306 : public ssd1306_base::SSD1306, public spi::SPIDevice<spi::BIT_ORDER_MSB_FIRST, spi::CLOCK_POLARITY_HIGH, spi::CLOCK_PHASE_TRAILING, spi::DATA_RATE_8MHZ> { Its running at 8Mhz

descipher commented 11 months ago

@jesserockz @ssieb I did a test on the atm90e32 component used on within my energy meter product PM1.

Processing power-meter-1 (board: esp12e; framework: arduino; platform: platformio/espressif8266@3.2.0)
--------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash

The device is capable of much higher baud rates for logging.

The device serial logs the following data ever 15s:

[11:25:59][D][sensor:093]: 'PM1 Total Watts': Sending state 744.90210 W with 0 decimals of accuracy
[11:25:59][D][sensor:093]: 'PM1 Total kWh': Sending state 135.77835 kWh with 2 decimals of accuracy
[11:26:00][D][sensor:093]: 'PM1 Total Amps': Sending state 9.35700 A with 2 decimals of accuracy
[11:26:01][D][sensor:093]: 'PM1 Volts': Sending state 119.71000 V with 1 decimals of accuracy
[11:26:02][D][sensor:093]: 'PM1 CT1 Amps': Sending state 2.89700 A with 2 decimals of accuracy
[11:26:02][D][sensor:093]: 'PM1 CT2 Amps': Sending state 6.46600 A with 2 decimals of accuracy
[11:26:02][D][sensor:093]: 'PM1 CT1 Watts': Sending state 263.41248 W with 1 decimals of accuracy
[11:26:02][D][sensor:093]: 'PM1 CT2 Watts': Sending state 482.77182 W with 1 decimals of accuracy
[11:26:02][D][sensor:093]: 'PM1 Freq': Sending state 59.95000 Hz with 1 decimals of accuracy
[11:26:02][D][sensor:093]: 'PM1 IC Temperature': Sending state 50.00000 °C with 1 decimals of accuracy
[11:26:02][W][component:204]: Component atm90e32.sensor took a long time for an operation (0.05 s).
[11:26:02][W][component:205]: Components should block for at most 20-30ms.

This results in a 50ms blocking in the processing of publish_state calls. The actual data retrieval from the atm90e32 is running spi at 1Mhz (was previously 250Khz .. not sure why it was set so slow) and not a significant factor in the total blocking time.

If I increase the logging baud_rate to 256000 vs the default 115200 the blocking time is reduced below the 50ms warn threshold and thus no more warning. So generally logging is a major factor of the blocking time problem.

To validate this fact I set the logging level to VERY_VERBOSE with the same configuraton and the result is 160ms of blocking time.

oivindklausen commented 11 months ago

Also se this warning using a Custom Component for Norwegain HAN Energy Meter running UART at 2400Baud with packt length around 270Bytes. Frame sync is found and the complete packet is processed before returned. Implemented according to "Custom UART Device". Update to the Custom UART description would be appreciated to avoid possible future breaking changes.

descipher commented 11 months ago

Also se this warning using a Custom Component for Norwegain HAN Energy Meter running UART at 2400Baud with packt length around 270Bytes. Frame sync is found and the complete packet is processed before returned. Implemented according to "Custom UART Device". Update to the Custom UART description would be appreciated to avoid possible future breaking changes.

With a HAN data format @ 2400 Baud thats 3.75ms per character * 270 = 1012.5ms if it was waiting for the sync b4 returning. What is it logging for the operation time? I doubt that it's waiting that long, something else may be happening here.

z3liff commented 11 months ago

I'm seeing this, but with pn532 as the component name:

[07:58:54][W][component:204]: Component pn532 took a long time for an operation (0.10 s). [07:58:54][W][component:205]: Components should block for at most 20-30ms. [07:58:55][W][component:204]: Component pn532 took a long time for an operation (0.10 s). [07:58:55][W][component:205]: Components should block for at most 20-30ms. [07:58:56][W][component:204]: Component pn532 took a long time for an operation (0.10 s). [07:58:56][W][component:205]: Components should block for at most 20-30ms.

I am using the code:

https://github.com/adonno/tagreader/blob/master/tagreader.yaml

seeing the same thing on pn532_i2c

segator commented 11 months ago

Same bug here after upgrading, on shelly 2.5pm for ade7953 and preferences

23:47:51 | [W] | [component:204] | Component ade7953.sensor took a long time for an operation (0.06 s).
23:47:51 | [W] | [component:205] | Components should block for at most 20-30ms.
23:48:40 | [W] | [component:204] | Component preferences took a long time for an operation (0.16 s).
23:48:40 | [W] | [component:205] | Components should block for at most 20-30ms.

patfelst commented 11 months ago

[10:49:56][W][component:204]: Component st7789v.display took a long time for an operation (0.12 s).
[10:49:56][W][component:205]: Components should block for at most 20-30ms.

display:
  - platform: st7789v
    model: TTGO_TDISPLAY_135X240
    backlight_pin: GPIO4
    cs_pin: GPIO5
    dc_pin: GPIO16
    reset_pin: GPIO23
    update_interval: 1s
    rotation: 90

ESPSabre commented 11 months ago

bme680_bsec and scd4x.sensor

alexruffell commented 11 months ago

ssd1306.display frequency: 400kHz - fixed it

sht3xd.sensor frequency: 200kHz - fixed it on multiple different configs, but not all needed it Note: I am assuming sht4xd is a close relative... it did not have any warnings at the default 50kHz

htu21d.sensor frequency: 100 to 800 kHz - did not fix on multiple systems w/ different configs Default implementation

[12:56:16][W][component:204]: Component htu21d.sensor took a long time for an operation (0.12 s).
[12:56:16][W][component:205]: Components should block for at most 20-30ms.

mics_4514.sensor frequency: 100 to 800 kHz - did not fix Default implementation

[13:18:05][W][component:204]: Component mics_4514.sensor took a long time for an operation (0.06 s).
[13:18:05][W][component:205]: Components should block for at most 20-30ms.

All systems running 2023.7

pepe59 commented 11 months ago

spi:
 clk_pin: 18
 mosi_pin: 23
 miso_pin: 19

display:
  - platform: ili9xxx
    model: ILI9341
    cs_pin: 14
    dc_pin: 27
    reset_pin: 33
    rotation: 90

[23:59:42][W][component:204]: Component ili9xxx.display took a long time for an operation (0.15 s).
[23:59:42][W][component:205]: Components should block for at most 20-30ms.
[23:59:43][W][component:204]: Component ili9xxx.display took a long time for an operation (0.15 s).
[23:59:43][W][component:205]: Components should block for at most 20-30ms.

pepe59 commented 11 months ago

i2c:
  sda: D1
  scl: D2

display:
  - platform: lcd_pcf8574
    dimensions: 16x2
    address: 0x3F

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

pepe59 commented 11 months ago

[00:32:52][W][component:204]: Component htu21d.sensor took a long time for an operation (0.12 s).
[00:32:52][W][component:205]: Components should block for at most 20-30ms.

TheWanderingTurkey commented 11 months ago

[18:12:41][W][component:204]: Component api took a long time for an operation (0.28 s). [18:12:41][W][component:205]: Components should block for at most 20-30ms.

This only shows up once at the initial API connection and does not repeat.

steelsparky commented 11 months ago

Just updated and seeing on circuitsetup energy-meter.

`

20:13:11 | [W] | [component:204] | Component atm90e32.sensor took a long time for an operation (0.06 s). -- | -- | -- | -- 20:13:11 | [W] | [component:204] | Component atm90e32.sensor took a long time for an operation (0.06 s). 20:13:11 | [W] | [component:205] | Components should block for at most 20-30ms.

`

Cougar commented 11 months ago

[17:23:53][W][component:204]: Component st7789v.display took a long time for an operation (1.37 s).

I guess that this is a way too much :D I'm using this config as an example https://community.home-assistant.io/t/need-help-with-ttgo-t-display/448695/3

m0jek commented 11 months ago

I just saw this "thread" when wondering why I was see the below in the espHome logs from modbus_controller. I am using with Epever Tracer8415AN MPPT controllers. Only noticed this after the recent update update .... Here is a snippet of my logs.

17:00:53 | [W] | [component:204] | Component modbus_controller took a long time for an operation (0.05 s).
17:00:53 | [W] | [component:205] | Components should block for at most 20-30ms.
17:00:54 | [W] | [component:204] | Component modbus_controller took a long time for an operation (0.13 s).
17:00:54 | [W] | [component:205] | Components should block for at most 20-30ms.

espHome is running on a ESP32 PICO

The config I am using is based on this one, but edited for my setup, but generally the same.

https://devices.esphome.io/devices/epever_mptt_tracer_an

PaFcio commented 11 months ago

Using really rudimentary config for PN532 with ESP-12S:

esphome:
  name: nfc
  friendly_name: nfc

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "<redacted>"

ota:
  password: !secret ota_pass

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "NFC"
    password: !secret ap_pass

captive_portal:

i2c:
  sda: 4
  scl: 5
  scan: true
  frequency: 200kHz

pn532_i2c:
  address: 0x24
  update_interval: 1s

  on_tag:
    then:
      - homeassistant.tag_scanned: !lambda 'return x;'

Receive below as with others that posted before:

[20:23:54][W][component:204]: Component pn532 took a long time for an operation (0.10 s).
[20:23:54][W][component:205]: Components should block for at most 20-30ms.

Tried 400kHz to same effect as based on following quote from datasheet: The PN532 is configured with I2C address 0x48 and is able to support a clock frequency up to 400 kHz. The data order used is MSB first.

tungmeister commented 11 months ago

seeing this constantly for esp32_touch:

[07:37:01][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:01][W][component:205]: Components should block for at most 20-30ms.
[07:37:01][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:01][W][component:205]: Components should block for at most 20-30ms.
[07:37:01][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:01][W][component:205]: Components should block for at most 20-30ms.
[07:37:01][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:01][W][component:205]: Components should block for at most 20-30ms.
[07:37:01][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:01][W][component:205]: Components should block for at most 20-30ms.
[07:37:01][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:01][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:02][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:02][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.
[07:37:03][W][component:204]: Component esp32_touch took a long time for an operation (0.06 s).
[07:37:03][W][component:205]: Components should block for at most 20-30ms.

I have 8 touch sensors configured, all controlling and LED behind each "button" depending on hass states and input with delays etc, this being one of the most complex ones:

  - platform: esp32_touch
    name: "Dan Blanket Touch"
    pin: GPIO12
    threshold: 100
    on_multi_click:
    - timing:
        - ON for at most 400ms
      then:
        - if:
            condition:
              lambda: 'return id(timeractivated);'
            then:
              - globals.set:
                  id: timeractivated
                  value: 'false'             
        - homeassistant.service:
            service: homeassistant.toggle
            data:
              entity_id: switch.electric_blanket
    - timing:
        - ON for at least 410ms
      then:
        - globals.set:
            id: timeractivated
            value: 'true'
        - homeassistant.service:
            service: timer.start
            data:
              duration: "00:06:00"
              entity_id: timer.blanket_timer
        - homeassistant.service:
            service: homeassistant.turn_on
            data:
              entity_id: switch.electric_blanket
    on_press:
      then:
        - light.turn_on: 
            id: dblanketled
            brightness: 100%          
    on_release:
      then:
        - if:
            condition:
              lambda: 'return id(timeractivated);'
            then:
              - delay: 0.1s
              - light.turn_on: 
                  id: dblanketled
                  brightness: 30%
              - delay: 0.1s
              - light.turn_on: 
                  id: dblanketled
                  brightness: 100%
              - delay: 0.1s
              - light.turn_on: 
                  id: dblanketled
                  brightness: 30%
              - delay: 0.1s
              - light.turn_on: 
                  id: dblanketled
                  brightness: 100%
              - delay: 0.1s
              - light.turn_on: 
                  id: dblanketled
                  brightness: 30%
              - delay: 0.1s
            else:
              - delay: 0.1s
              - light.turn_on: 
                  id: dblanketled
                  brightness: 30%
              - delay: 0.1s
        - if:
            condition:
              - binary_sensor.is_on: blanket
            then:
              - light.turn_on:
                  id: dblanketled
                  brightness: 80%
              - light.turn_on:
                  id: lblanketled
                  brightness: 80%

would this be the reason for the long times rather than an actual issue?

Littletiger commented 11 months ago

[11:48:14][W][component:204]: Component sgp4x.sensor took a long time for an operation (0.06 s). [11:48:14][W][component:205]: Components should block for at most 20-30ms.

  - platform: sgp4x
    nox:
      id: nox
      name: ${upper_devicename} NOx
    voc:
      id: voc
      name: ${upper_devicename} VOC
    store_baseline: yes
    update_interval: 60s
    compensation:
      temperature_source: temp
      humidity_source: humidity

I also had the message for the ssd1306 and this has been fixed by setting the i2c frequency to 400kHz

pgolawsk commented 11 months ago

Although i2c frequency set to 400kHz I'm getting those for 2 sensors: [W][component:204]: Component tcs34725.sensor took a long time for an operation (0.08 s). [W][component:205]: Components should block for at most 20-30ms.

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

esphome / issues