mmWave Wars: one sensor (module) to rule them all

Are you using the HiLink integration? I have this issue too. I need to delete the device, restart home assistant and then it finds it again.

Exactly, I just need to restart home assistant. The ld2410 fallback to pairing mode but home assistant doesnt reconmect. A restart helps. Maybe theres is a bug with this new integration. I will check github issue tracker later.

There it is: LD2410 BLE recognized but fails to connect · Issue #88120 · home-assistant/core · GitHub

What I intend to do is to use the LD2420B to turn lights off. I have a PIR to turn them on. What I am afraid is that they are gonna stay on all night with the cat in the room.

I ordered them yesterday and I am expecting them on March 20 so I have plenty of time to think about it. I saw in some screenshots above that it exposes various entities one of them being standing energy.

Does anyone know what is this? What is the value when the room is occupied and what when not? Can it be used as a numeric trigger instead of the standard “occupancy”?

Thanks

CEM5825F = LD1125H
CEM5855H = LD1115H

So no need to implement these, since they already are :slight_smile:

I found that the Hi-Link sensors are on par for motion detection with wireless Xiaomi PIR sensors. Wired might be quicker I don’t know, but to me it seems perfectly OK just to use the mmwave sensor

I have a dog and the occupancy does go on and off with him in the room. The energy value is 100 when human in present, and hovers around 10-20 when dog is present and 0 when dog is absent so might be able to use that instead of the occupancy binary sensor.

Would any of you have a recommendation of which sensor to use if I want to place this behind a 2 way mirror? Or would non work?

My LD2410B arrived yesterday so I’ve not had much time to experiment but here’s my thoughts compared to the DFRobot one that I’ve had running reliably 24/7 for a couple of months now. Sorry for the wall of text but it might be handy to someone. This is my experience and your mileage may vary depending on room size, placement, environment, furniture etc

Differences:

  • It’s absolutely tiny. I would 100% recommend buying the board with the pins pre-soldered, even if they’re non standard pin sizes.
  • The bluetooth range is pretty poor, HA didn’t even detect it upstairs. If you’re hoping to directly power the board and use the onboard bluetooth for connectivity you might find you need some bluetooth proxies close by or will need to connect via something like a D1 mini for WiFi. Given the size is one of the selling points it’s a shame to need another board alongside it as even the D1 mini is several times bigger but if using as part of bigger sensor or close to your bluetooth device this would be fine.
  • The board doesn’t expose options to modify detection distance, sensitivity or “latency to clear” which I get with the DFRobot via a D1 mini. I’m not sure if connecting it up to one would allow setting these.
  • Once in bluetooth range it was pretty cool to just have the sensor picked up and auto configured. I’ve power cycled a few times and it’s turned on and connected fine each time. Once connected I’m not getting any drop outs but it is very close to the bluetooth device at the moment.

Performance:

  • I set the DFRobot “latency to clear” to 1 second to match the LD2410B and put them side by side. My desk is about 3m away and I was working all day. Unsurprisingly the bigger DFRobot came out top with accuracy here but the LD wasn’t too far behind. Both had blips of “Clear” over the course of the hour even if I hadn’t left the desk. The DFRobot had less of these and they were quite a bit shorter before triggering back to “Detected”. That means I can have a shorter “latency to clear” on the DF and in turn a quicker accurate “cleared” status.
  • Both seem to detect “cleared” equally as well and stay “Clear” when I leave the room and quickly detect when entering - although not quite as quick as a PIR as you’d expect.
  • Based on the above I set a latency of 20 seconds on the DF and 45 seconds on the LD and left it another couple of hours. I had to create a sensor in HA for the LD since I can’t set that latency option on the board itself (yaml below). This is when I started to get more accurate readings, I’m not using them for lighting so the longer cooldown works well and reduces any false positives. I’ve put the sensors opposite ends of the room and combined both sensors into a “Living room” sensor which now can be accurately used to know if someone is sitting still in the room. The LD itself does still sometimes throw a “clear” when it shouldn’t but combined with 2 sensors that doesn’t cause me an issue. If I just had the one I suspect I’d have to put the latency up to 60s + to avoid these.
  - platform: template
    sensors:
      living_room_hlk_sensor_cooldown:
        friendly_name: Living Room HLK sensor cooldown
        delay_off: "00:00:40"
        value_template: "{{ is_state('binary_sensor.hlk_ld2410b_0539_occupancy', 'on') }}"

Here’s the kicker though… I wrote all the above with the DF within a 3D printed PLA case and the LD bare… As soon as I put a small case over the LD it dramatically dropped the detection distance and whilst the waves should easily penetrate PLA (1mm thickness) I needed to be within 1 - 2m for it to detect me.

Overall I’d say it’s an okay board for the money (cost me a couple of quid, the DF is many times more costly), especially given the overall size and built in connectivity. If you’re hoping to put one in the corner of a large room to accurately cover it I think you’ll need to reconsider - it lists 5m range but I very much doubt it would keep track of me sat on the sofa which is 4m away. I can still think of a couple of cases where it might be useful for me - our kitchen, TV stand for sofa, desk etc. I’m still hoping a commercial sensor like the upcoming FP2 will be the complete package for me but these may still be handy in a couple of smaller places around the house.

6 Likes

I’m waiting for mine to be delivered but this was very helpful.
Am I right in thinking the ‘magic waves’ are emitted from the two rectangular ‘pads’?
If so couldn’t a case be designed with holes to improve the range?

My initial answer would be that it shouldn’t matter, 1mm of PLA shouldn’t cause any issues in blocking the mmwaves - as shown by the bigger DFRobot one I have which is fully encased without issue. Nearly all commercial ones, including the ones on cars are covered after all…

In reality I suspect given the size of the LD and the fact it has 4 less “pads” than the DF I’d imagine it’s a bit weaker. It did perform “better” without the case whereas the the DF didn’t make any difference. I’ll perhaps try one with a couple of holes in front of the pads but even completely bare it had it’s problems.

I will say I’m pretty rubbish at 3D design so fingers crossed someone comes along and builds a better compact case in general!

Great review!

1 Like

I’m going to end up soldering a d1 mini onto the LD I think, the bluetooth range is absolutely rubbish, around 30cm so I’m unable to use it anywhere I planned on sadly. At least that’ll mean I can build in the “latency to clear” and avoid constantly spamming wifi/bluetooth, but will add a fair bit of bulk to the device.

Really great review, thank you very much for taking the time to write it down. Do you may have any schematics on how to solder the LD2410B to D1 mini? I have purchased a couple LDs with pre-soldered pins so that’s ok. If you also have the yaml that would be great!

Thanks again!

Hi all,

I’ve been following this thread while designing a custom board for the LD2410 (non-bluetooth).
It’s ended up becoming an all-in-one board with quick Home Assistant integration. The aim is to replace all the room sensors (temperature, humidity, ambient lighting, PIR, etc…).
If you’d like to look at the ESPHome config then it’s freely available here: GitHub - LoopOnCode/UnitySensor
If you’re interested in the device itself then that’s here: Unity Sensor – LoopOn


1 Like

I am also using the LD2410B with HomeAssistant(2023.2.5) over Bluetooth.
I have tried a sensor with firmware version 1.7 that is currently behaving normal with the Android app, but with Home Assistant it has a lag.
I can see that the Output Pin is getting high state as soon as I go into the sensor range, but HomeAssistant is getting the changed state after 2-4 seconds, sensor and Bluetooth dongle are 2m apart.
I can’t say, yet if the root cause of this high delay is the Bluetooth integration or my PC or both. Maybe some one can say more from their experience.

The newer firmware version for LD2410B does not work out of the box with HA, at the moment. There is a better description of the topic here: LD2410 sensors with firmware 2.01.23020209 are not discovered · Issue #88085 · home-assistant/core (github.com)
It seems that there should be a workaround that should solve the connection to HA, but honestly I could not get how to implement it.

I also saw a lot of variants with esphome and LD2410 which I would lean onto, can someone please point us to a working yaml configuration?

I haven’t had the time to look into it yet. Oddly the built in bluetooth works fine across the room when connecting the phone app directly to the device but it’s absolutely rubbish when connecting bluetooth via HA. I’ve seen a few reports of this from others so hopefully a firmware update might solve it, I’ll probably send HI-LINK an email as they seem quite responsive.

I’d probably just solder the 5V power, GND and the sensing pin on the LD to one of the D1 pins.

I’ll probably strip some stuff out of this yaml to make it a bit might lightweight and use that as I’m to lazy to write my own : ESPHome-LD2410/ld2410.yaml at c71e43a39dc851c0b651816739cbbbfb41beeaab · rain931215/ESPHome-LD2410 · GitHub

There is a native LD2410 component in ESPhome

1 Like

Hi there,

I’m very new at this, where do i find the page which has this information formated in a table as above?

Look here

Thank you, thats very helpful :slight_smile: