Bluetooth/Multi-Target switch unreliable

[wittimagic]

Nice work ! I really like the clean design and area definitions.
I am using new sensors with latest build fw in combination with a ESP32C3 board.

I have following problems:
I noticed in the log, that the data is not continously flowing.
I can switch the buttons multitarget or BT to off, but not back on. The logs show the error, that the sensor can't be switched into config mode. I than reduced the yaml to only those buttons to recover the seonsor, but it still didn't work.

After that I used the project https://github.com/uncle-yura/esphome-ld2450 and was able to recover the sensor.

Any idea ?

[TillFleisch]

From what I can the tell, some LD2450s stop responding to configuration messages, seemingly at random. Sometimes they recover. Removing power and re-powering them is a valid workaround. #6 fixes a possible situation in this component, in which the ESP does not read UART properly. This does not guarantee to solve this issue, it might.

From what I've heard from other users the LD2450 sensor freezing or not being able to configure it, is a sensor related issue which might be fixed in a firmware update.

[wittimagic]

I gave it a try :-)
Unfortunately the data flow still gets stuck every couple of seconds.

When this happens, the log is repeating the identical output line and all values in home assistant change to unknown state. When the sensor recovers, the log continues normal and the values in home assistant return.

I also tried the not yet official release you can find here: esphome/esphome#5674
The data doesn't get stuck with that release. Hope that info helps.

:-)

[TillFleisch]

I also tried the not yet official release you can find here:

I am aware the open PR in the ESPHome repository. I did not have the time look at it/review it/play around with the provided solution.

If I recall correctly, the repeating messages can also be caused by targets which are near the end of the visible range of the sensor. Once the sensor looses a target (goes outside of it's visible range). It will still send the last seen position until it eventually times out. The fast_off_detection option can be used to force this component to circumvent this behavior by ignoring such duplicate messages and assuming the target has been lost.

Obstructing the sensor (hidden behind something) might also cause similar symptoms.

[wittimagic]

Ok, I will play with the fast_off_detection and monitor the behavior.
The open PR looks very similar to your approach, it is worth taking a look.
Thank you for the hints and details :-)