Component xxxxxx took a long time for an operation #4717
Comments
|
Sorry, didn't see this one before filing #4716. Another one for the pile is |
|
@nwf thats alright as I posted this issue afterwards to stop future ones =) |
|
- platform: scd30
co2:
name: "CO2"
accuracy_decimals: 0
temperature:
name: "Temperature"
accuracy_decimals: 1
humidity:
name: "Humidity"
accuracy_decimals: 1 |
|
Ssd1306 causes it also |
|
Getting this on a BT proxy: 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" |
|
A simple workaround for the ssd1306 128x64 display is to increase the i2c frequency to 400kHz. This fixed the warning for me. @BenCos17 i2c: |
|
I also got these messages: 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?
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. |
thanks |
|
I just upgraded to 2023.7.0 and recompiled my three NodeMCU stacks. After uploading I got this: 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 |
|
I'm seeing this, but with Components in use are: I do have a Lambda set up to run when the Victron BLE picks up a charger status update. |
|
I see this for my waveshare epaper display:
Config: |
|
Look at my workaround esphome/feature-requests#2301 for fix audio interrupt. |
|
I'm now seeing this reported for dsmr 0.8 as well: 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. |
|
I'm seeing this: When using the component: |
Thanks, (that below) fixed the error on the SH1106 here. Didn't fix the Dallas one though. i2c: |
|
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). I am using the code: https://github.com/adonno/tagreader/blob/master/tagreader.yaml |
|
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 #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 [repeats every 10 seconds] If someone needs more info let me know. |
|
With ssd1306 I got the same errors Fixed by adding |
|
I have a ESP32 running an IR LED remote and a DHT11.
|
|
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 |
|
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" |
|
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 |
|
Tack on atm90e32 23:00:40 | [W] | [component:204] | Component atm90e32.sensor took a long time for an operation (0.05 s). |
|
@LelandSindt any custom/external component issues should be reported to the relevant repositories/owners and not here. |
|
Apologies, I misunderstood. (thought you were looking for general instances of the message) I will follow up with @ssieb |
|
|
Lcd `esp32: pcf8574:
i2c: display:
` |
Hello, I have a same issue. Config esp32:
board: nodemcu-32s
i2c:
sda: 16
scl: 17
scan: true
display:
- platform: lcd_pcf8574
id: lcd_settings
dimensions: 20x4
address: 0x27
update_interval: 2s
lambda: |-
it.print("Hello World!");Logs |
|
Got the problem since some last updates i think?
config:
interval:
|
|
I have the error with the Display Component Can someone say somethink here?
|
|
I also have the problem with a display component [14:46:39][W][component:232]: Component display took a long time for an operation (128 ms). |
|
Just chiming in, I see this as well for my epaper display. Config |
Same here on 2024.3.2. |
1) Set the update interval for sensors only needing occassional updates (i.e. WiFi Signal dB, WiFi Signal %, Last Restart & Device Uptime) 2) Loggers adds ' logs: component: ERROR'. This is a fix for issue esphome/issues#4717 "Component xxxxxx took a long time for an operation" 3) Added "sntp_update_interval: 6h" to allow setting of sntp update interval from substitutions section.
1) Set the update interval for sensors only needing occassional updates (i.e. WiFi Signal dB, WiFi Signal %, Last Restart & Device Uptime) 2) Loggers adds ' logs: component: ERROR'. This is a fix for issue esphome/issues#4717 "Component xxxxxx took a long time for an operation" 3) Added "sntp_update_interval: 6h" to allow setting of sntp update interval from substitutions section.
|
@jesserockz : this is one of these times, where the creator of the change had good things in mind, but didnt think about full consequences for a lot of users and therefore making life harder for many. From my POV: PS: You state yourself, that lots of users do not necessarily know about the consequences regarding timings, when they change certain settings.. But - do you really think, implementing workarounds is the better solution than providing that knowledge to those people? |
|
@p1ngb4ck, I will respectfully disagree here if you are talking about revert the change which started with the What I thing we should do is to promote people to improve their code to prevent this, perhaps with some guidance/best practices to make their job a bit easier. So, basically, what I'm saying is that instead of reverting this change, we should promote the improvement on the different components as that will improve ESPHome in overall. |
|
Just looking back to the messages here and I can easily find some examples like this one where the display component is taking almost 500ms to display a "Hello world" message. It's good to highlight that the component deserves some love. 😉 |
|
@edwardtfn and I respectfully disagree with you here anyhow, because I think you are mixing up twi different things here: Fron the very abstract pov: this is a knowledge issue of those users that run devices with wrong settings. Do I want to create a workaround that affects previously unaffected users, or do I pass the knowledge required, that those users will need anyhow, If they want to succeed with their projects? |
|
You have a good point... 😉 |
| [W] | [component:237] | Component hdc1080.sensor took a long time for an operation (56 ms). -- | -- | -- 17:48:53 | [W] | [component:238] | Components should block for at most 30 ms. |
|
The clocking on the spi bus is running at 40MHz so I can't think that is the cause, maybe the lambda is too slow? I'm not sure how to make it execute faster. Shouldn't this warning be adjustable per component so that someone can silence it for one but not for all? The log context is component 'component' so you can't actually filter it out for display only. |
I get the same warning with my m5stack. The display does work if you add the following block. |
|
|
Hi! I getting a lot of messages for display model ST7789 (ILI9xxx component)
I got as fast as possible SPI speed, but the more complex is frame, the bigger chance this messages will appear. With just one text string all right. I think will be great to be able to set the operation duration for each component, so display component can have for example 100ms instead of 30ms right now. |
|
Happens on 2024.2 for the sen5x component. The config is based on the example on the docs. sensor:
- platform: sen5x
id: sen55
pm_1_0:
name: "${macsuffix} PM <1µm Weight concentration"
id: pm_1_0
accuracy_decimals: 1
pm_2_5:
name: "${macsuffix} PM <2.5µm Weight concentration"
id: pm_2_5
accuracy_decimals: 1
pm_4_0:
name: "${macsuffix} PM <4µm Weight concentration"
id: pm_4_0
accuracy_decimals: 1
pm_10_0:
name: "${macsuffix} PM <10µm Weight concentration"
id: pm_10_0
accuracy_decimals: 1
temperature:
name: "${macsuffix} Temperature"
accuracy_decimals: 1
humidity:
name: "${macsuffix} Humidity"
accuracy_decimals: 0
voc:
name: "${macsuffix} VOC"
algorithm_tuning:
index_offset: 100
learning_time_offset_hours: 12
learning_time_gain_hours: 12
gating_max_duration_minutes: 180
std_initial: 50
gain_factor: 230
nox:
name: "${macsuffix} NOx"
algorithm_tuning:
index_offset: 100
learning_time_offset_hours: 12
learning_time_gain_hours: 12
gating_max_duration_minutes: 180
std_initial: 50
gain_factor: 230
temperature_compensation:
offset: 0
normalized_offset_slope: 0
time_constant: 0
acceleration_mode: low
store_baseline: true
address: 0x69
update_interval: 10s |
|
[17:05:28][W][component:237]: Component modbus_controller took a long time for an operation (207 ms). I have the same issue with a ESP32 board, this log is from the ESP32-S2. ESPhome Version: 2024.5.0 |
|
Same for component sml: [19:46:08][W][component:237]: Component sml took a long time for an operation (57 ms). |
|
same with ld2410 in engineering mode. |
and others
Do not report new issues related to this message, instead please comment on this issue with the logs that you see and the config for that component.
The problem
These 2 log lines may show up in the most recent version of ESPHome due to the log level being changed from
verbosetowarning.I made this change because changing the device log level to verbose just to see if these lines show up significantly slowed down the device due to all the extra logging it had to do.
Which version of ESPHome has the issue?
2023.7.0
Can I hide this message?
Yes you can hide the message, but it wont change the fact that the component is taking a long time.
Is it expected?
For some components this is actually expected like displays which have a lot of drawing and pixel/data moving.
For the majority of sensors, it means that they are doing too much processing or waiting for responses instead of letting ESPHome get on with business until the data is ready.
The text was updated successfully, but these errors were encountered: