core: LD2410 BLE recognized but fails to connect

I have the same issue. I find that I need 1 Bluetooth proxy for each LD2410B. The sensor has to be closed to the BT Proxy and I must limit it to 2 active sensors. (Motion and Occupancy). Enabling more sensors will cause disconnects. It seems that BT Proxy got flooded and crashed which requires restart of HA and power cycling BT Proxy and sensor. I am using Home Bluetooth Proxy which specifically says 3 simultaneous active connections. I wonder if non BT sensor + ESP32 may have less disconnect.

Just want to update on this since the thread is going side way. The original issue was the LD2410B with BT proxy. All wireless and no coding and no soldering.

I think the reliability issue reported is much improved now. With latest Home Assistant 2023.6.3 and BT Proxy Firmware: 2023.5.5 (Jun 19 2023, 04:15:49), I am now seeing stable and reliable LD2410B Occupancy sensors in HA. I have two LD2410B with 2 BT Proxies. The sensor and the proxy is about 12-20 inches apart and 16 ft apart from the other set.

The two sensors and BT proxy have lasted over 3 days without issues. The Occupancy sensor (only one enabled by default in HA) seem to work reliably. Previously, my sensor went offline within hours and the only fix was to restart HA.

I noticed when BT proxy was unplugged, the sensor was often lost and a reload of the sensor was needed to reconnect. If they were powered on together, the sensor seems to be very stable. I also noticed that BT Proxy need be closed to the sensor.

I have an automation now that runs where the device goes unavailable, and reloads the integration. Seems to work well. According to my traces, it runs roughly once or twice a day.

I don’t claim to be the best automation writer, but some may find it useful

alias: Reload LD
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.hlk_ld2410b_6ae9_occupancy
    to: unavailable
condition: []
action:
  - service: homeassistant.reload_config_entry
    data: {}
    target:
      device_id: 786aed8ccd5ca100afe17ceb49018866
mode: single

I have 3 LD2410B. I initially tried with Bluetooth. I have one that works flawlessly. It is in the same room as my HA NUC and is connected to its onboard Bluetooth receiver. I tried the other 2 using ESP32 Proxy and they are very unreliable. I suspect it is the Proxy or the communication between the LD2410B and the Proxy that is causing the issue.

So, I gave up on Bluetooth for the other 2 and hard wired them to ESP32 DEVKITVI. This works brilliantly. Remember to connect TX to RX and RX to TX between the board and the sensor. To avoid soldering, I bought the 5 pin version of these and attached them to Dupont wires for connection to the ESP32:

https://shorturl.at/pqDO2

I also have 4 SEN0395 from DFRobot, 1 Aqara FP1 and 1 ZigBee Wifi MmWave Human Presence Motion Sensor (which is the worst of the lot).

For the price and the size, the LD2410B is amazing. Reliable and accurate. It works so well, that I don’t need a PIR to initially trigger my room light. The LD2410B Occupancy is so fast it can be used to trigger lights to turn on and off with no false results. I can’t say that with any of the other mmWave sensors.

After scouring the internet, I finally found YAML code that works for me. Here it is:

esphome:
  name: "esphome-web-?????"
  friendly_name: Spare 2410 radar sensor
  platform: ESP32
  board: esp32dev
 
external_components:
  - source: github://esphome/esphome@dev
    components: [ ld2410 ]
 
# Enable logging
logger:
  level: WARN
  baud_rate: 0
 
# Enable Home Assistant API
api:
  encryption:
    key: "YOUR KEY"
 
ota:
  
 
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
 
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Web-?????"
    password: "YOUR PASSWORD"
 
uart:
  id: uart01
  tx_pin: GPIO17
  rx_pin: GPIO16
  baud_rate: 256000
  parity: NONE
  stop_bits: 1
 
ld2410:
  timeout: 10s
  max_move_distance : 6m
  max_still_distance: 6m
  g0_move_threshold: 50
  g0_still_threshold: 20
  g1_move_threshold: 50
  g1_still_threshold: 20
  g2_move_threshold: 40
  g2_still_threshold: 20
  g3_move_threshold: 30
  g3_still_threshold: 20
  g4_move_threshold: 30
  g4_still_threshold: 20
  g5_move_threshold: 20
  g5_still_threshold: 20
  g6_move_threshold: 20
  g6_still_threshold: 20
  g7_move_threshold: 40
  g7_still_threshold: 30
  g8_move_threshold: 40
  g8_still_threshold: 30
 
binary_sensor:
  - platform: ld2410
    has_target:
      name: Presence
    has_moving_target:
      name: Moving Target
    has_still_target:
      name: Still Target
 
sensor:
  - platform: ld2410
    moving_distance:
      name : Moving Distance
    still_distance:
      name: Still Distance
    moving_energy:
      name: Move Energy
    still_energy:
      name: Still Energy
    detection_distance:
      name: Detection Distance

From my observations, the issue is not 1 BT proxy to 1 LD2410B or any combinations. I have tried combinations of 3 of BT proxy and 3 LD2410B. One LD2410, 2 proxy etc. I have narrow it down to just one pair where I see it working most and observe a pattern of behavior.

My 1 BT Proxy and 1 LD2410B is about 12 inches from one another. HA loses the LD2410B randomly. it could be working now and minutes/hours later, it stops working. If I leave it alone until the next day, it could be working again without any reboots of HA or powering off any things.

The disconnect issue is either with the BT Proxy or/and with HA code handling the data passed thru BT Proxy. When it works, there is definitely a constant flood of data passing thru the BT proxy from LD2410B to HA and this could cause the problem.

I dont think the issue is with LD2410B hardware. To see if your LD2410B is a dud, use the dev KIT, you could see the green light turn on when it detects a presence and goes off when no presence. This always works for me even if HA is not seeing the LD2410B.

My conclusion at this time: I am not convinced using BT is the way to do it. It is just unreliable. I dont use my BT proxy for anything else so I dont know if the issue is with BT proxy of HA or both. I really wanted it to work with BT Proxy but after so many months, I think best to not use a Bluetooth solution.

Alternative solution that will work reliably is to use WiFi If you want just presence detection. That means using ESP2866 and watch when the pin for Green light in on/off. All without BT. Not plug/play, a bit complicated but reliable.

For me it looks like there’s no benefit for using the Bluetooth integration over the ESPHome integration. I’ve sourced a BT Proxy and yes I get a better connection in the same room but that means I’ll need a proxy per room and my use case is one LD2410 per room. Therefore I feel it’s better for me to use ESPHome, and if in the future I add more LD2410s per room I “might” be able to use the ESPHome ESP32 as a BT proxy (yes I know it’s not that simple, WiFi and BT are not good bedfellows on one ESP32).

My conclusion so far is that the Raspberry Pi Bluetooth doesn’t have a good range and nether does the LD2410B or LD2410C. Adding a “better” Bluetooth dongle to the Pi helps and adding Bluetooth proxies helps. So for me adding LD2410 to an ESP board is the way forward.

Interesting commentary here. I am thinking if I have to put a BT proxy that close to the sensor I may as well just connect the sensor directly to the ESP?

I hardwired it to my esp32. Works flawless. Had some issues with Bluetooth mainly because of esp32

Yes it is the sensor’s device_id. I made the automation via the HA UI, so I didn’t need to know, it was inserted by the UI editor on choosing “device” as the target and then choosing the correct device 😃

I also use a M5-Stack Atom Lite as Proxy.

As workaround I try to reload the occupancy sensor in case if it is unavailable after 30 seconds. I do not need the motion sensor, so I deactivated it in HA. Lets see if it helps temporarily:

alias: ld2410b sensor reload if unavailable
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.hlk_ld2410b_occupancy
    to: unavailable
    for:
      hours: 0
      minutes: 0
      seconds: 30
condition: []
action:
  - service: homeassistant.reload_config_entry
    target:
      entity_id: binary_sensor.hlk_ld2410b_occupancy
mode: single

I have the same issue. I find that I need 1 Bluetooth proxy for each LD2410B. The sensor has to be closed to the BT Proxy and I must limit it to 2 active sensors. (Motion and Occupancy). Enabling more sensors will cause disconnects. It seems that BT Proxy got flooded and crashed which requires restart of HA and power cycling BT Proxy and sensor. I am using I use ESP Home Bluetooth Proxy which specifically says 3 simultaneous active connections. I wonder if non BT sensor + ESP32 may have less disconnect.

I’ve tried with an M5-Stack Atom Lite which is ESP32-based and had the sensor plugged in (powered) directly from the controller and it still disconnected.

I think you may be onto something with the data flooding issue, these sensors seem excessively “chatty” in terms of how much traffic they generate, hundreds of messages per minute seems the norm - I wonder if they can be quietened down a bit! 😄

@nununo This is expected, because the Shelly v2 is a passive Bluetooth Proxy. To use the full capabilities of the HLK-LD2410B you need an active ESPHome Bluetooth Proxy.