Component lock time too long

[Fabian-Schmidt]

Look into lowering component lock time.

[yoannchaudet]

Is this related to this warning in the logs?

...
[11:09:26][W][component:214]: Component victron_ble took a long time for an operation (0.06 s).
[11:09:26][W][component:215]: Components should block for at most 20-30ms.
...

It started to appear on my side after I started to emit more than just a couple things.

[HBK1]

With EspHome 2024.6.1 I do not get those warnings anymore even if the logging is set to Debug.
I am also running syssi/esphome-jk-bms on the same esp32-s3-devkitc-1 (T-Dongle-S3) without problem.

[MUYUM]

I'm also getting this warrning message:
Component victron_ble took a long time for an operation (61 ms).

Times are between 40 and 65 ms.

I have 4 Victron devices on one ESP32 DEV KIT V1, where I request all avaliable params (voltage, current, power,...):

• 1x SmartCharger 100/30
• 2x SmartCharger 100/20
• 1x SmartShunt IP65

Beside Victron I'm also have some analog sensors, but the warrning message is only shown on Victron BLE.

I have the latest version on ESPHome (2024.8.3) installed on HA.

Hope it helps.

[tingles2233]

I am getting quite a few of these alerts on pulling our environment via a single ESP32.

all between 35-65ms when I see them show up.

Not sure if this is a problem, but it seems that some devices are not being updated in Home Assistant timely, where as others are.

6x Smart Lithium Batteries
3xMPPT controllers
1x DC DC Charger

Thoughts?

[Fabian-Schmidt]

Which configuration for logging are you using?
The time it takes to log messages also counts as component operation time.
So if many messages or a slow logging speed (UART or slow Network) is used it will also produce this warning.
I have seen improvements by minimizing the logging level to WARN and either disabling or speeding up UART log (baud_rate of 0 or 1500000). See Logger Component for details.

I adjusted my Bluetooth scan parameter to receive more Bluetooth packages and therefore more Victron device messages.
Especially if many Bluetooth devices are around this can improve the situation a lot. Unfortunately the spread of ESP device antennas is quite large. So some devices have just very poor antenna and receive very few Bluetooth packages. Also as Wifi and BT share the RF component using Wifi might also impact the performance.

Here is my Bluetooth settings which works for me. See ESP32 Bluetooth Low Energy Tracker Hub for details. You might have to tweak these values.

esp32_ble_tracker:
  scan_parameters:
    interval: 10ms
    window: 10ms
    active: false

[tingles2233]

Hi Fabian,

Using the following for logging;

Enable logging

logger:
level: DEBUG

I`ll try your settings and see how it works out over the next 24 hours.

Also noticed some sensors seem to be going into HASS with 3 decimal points? When it looks like the source in ESPHOME logs from the BLE show only 2 decimal points. Data shows with multiple decimal points even outside of that graph created on the dashboard.

Any thoughts on why some of the batteries would seem to have 3 decimal points and others only have 2?

Here is the ESPhome code for the below sensors

• platform: victron_ble
  victron_ble_id: eudorabattery2
  name: "Eudora Battery 2 - Cell 1"
  type: CELL1
• platform: victron_ble
  victron_ble_id: eudorabattery2
  name: "Eudora Battery 2 - Cell 2"
  type: CELL2
• platform: victron_ble
  victron_ble_id: eudorabattery2
  name: "Eudora Battery 2 - Cell 3"
  type: CELL3
• platform: victron_ble
  victron_ble_id: eudorabattery2
  name: "Eudora Battery 2 - Cell 4"
  type: CELL4

ESP LOG:

[11:14:49][D][sensor:094]: 'Eudora Battery 2 - Battery Voltage': Sending state 13.08000 V with 2 decimals of accuracy
[11:14:49][D][sensor:094]: 'Eudora Battery 2 - Error': Sending state 0.00000 with 0 decimals of accuracy
[11:14:49][D][sensor:094]: 'Eudora Battery 2 - Temperature': Sending state 21.00000 °C with 2 decimals of accuracy
[11:14:49][D][sensor:094]: 'Eudora Battery 2 - Balance Status': Sending state 0.00000 with 0 decimals of accuracy
[11:14:49][D][sensor:094]: 'Eudora Battery 2 - BMS Flags': Sending state 100663296.00000 with 0 decimals of accuracy
[11:14:49][D][sensor:094]: 'Eudora Battery 2 - Cell 1': Sending state 3.28000 V with 2 decimals of accuracy
[11:14:49][D][sensor:094]: 'Eudora Battery 2 - Cell 2': Sending state 3.26000 V with 2 decimals of accuracy
[11:14:49][D][sensor:094]: 'Eudora Battery 2 - Cell 3': Sending state 3.27000 V with 2 decimals of accuracy
[11:14:49][D][sensor:094]: 'Eudora Battery 2 - Cell 4': Sending state 3.27000 V with 2 decimals of accuracy

Screenshots below.

[Fabian-Schmidt]

I don't use HASS (Home Assistant). I run the ESPHome standalone with display. So I have very little knowledge of Home Assistant and its graphs and data.

Looking at the graph there is a difference in when data is received The second graph is only displaying a single value for the full time. While the other has many data points.

The graph appear to have an additional digit, but I believe this is due to rounding. As the battery is transmitting every few seconds a value and the graph is calculating an average of all values for a time period. This can cause this artefact.