The official integration, and most of the github adaptations, only allow you to set the number of gates (the maximum distance, where each ‘gate’ is 1m firther from the sensor) or no settings at all.
Most people have resorted to connecting the phone app to do the config.
This exposes all the same settings that exist in the bluetooth android/ios app. You must set each sensitivity for each distance (gate) manually and on a per-room basis to achieve best results. If you want reliable presence (actual mmwave benefits) then this is the way. Nope. He changed his code. Now it’s just a couple parameters. Lame.
My method is to just put the sensor in its final resting place, load up this code on the esp, and then, using known distances and in a different room (because mmwave will penetrate many surfaces) I will watch what type of motion and what distance is observed with nothing there, and then tweak the sensor.
Finally, just ignore the sensor and keep track of when and where you are. Does the output look accurate? Cool, you’re done. It’s not a fast process, but nothing will truly replicate your individual sensor location settings quite like the actual location itself.
I had problems with LD2410 (Not the C model) and D1 Mini because the 5V level was too low for the sensor. With D1 Mini the VCC level was something like 4,6V
Are you really feeding 3,3V for the VCC. I think the C model also wants to have 5-12V for VCC
I have it working and see the same. But in my opinion it is logical. If there is something moving , “moving target” is ON ,and when you are sitting still “Still Target” is ON (and Moving target is OFF). Presence is on is both instances for the timeout period set in the ESPHOME yml file for this sensor. I have it set to 30 seconds.
This problem occurs when the ESP32 firmware is uploaded with the LD2410C connected to it. The sensor was fine, working perfectly for weeks, and after I modified something (anything) on ESPHome and upload the new firmware, after that one of the Still and Moving entity is allways Detected, and 0% energy and 0cm for the Still entity. I have no ideea why yet, I’m trying to sort it out, and also a way to repair the LD2410C modules…
Dude I just saw this and it’s amazing! I’ve been busy and not putting too much attention into HA lately and I missed your comment and the chance to buy the product.
SOOOOO I managed to sort it out. Kudos to @Arh, @ryny24 and @deadwood83 for pointing me in the right direction.
The sensor is now working properly and it was indeed a sensor’s software issue.
The problem? The detect thresholds
On @Arh’s comment about using the TX and RX, I am not using the hardware UART pins, but custom ones, so indeed this cause a problem as per ESPHome’s docs:
Use of hardware UART pins is highly recommended, in order to support the out-of-the-box 256000 baud rate of the LD2410 sensor.
I did try using the ESPHome’s component but still had the same issues, and I didn’t want to use the hardware UART pins, so I went back to the original repo.
I ended up using the HiLink Android app, connecting through Bluetooth to the sensor and changing the configuration variables following the values described in the ESPHome’s ld2410 component: LD2410 Sensor — ESPHome
Gate
Default Move threshold
Default Still threshold
0
50
0
1
50
0
2
40
40
3
40
40
4
40
40
5
40
40
6
30
15
7
30
15
8
30
15
It was a process since the app is in Chinese and had to screen capture and use Google Lens to translate it, but eventually managed to set up all the values and the sensor is not jumping around anymore. Then it should be fine tuned as @deadwood83 suggested for each position.
Next step is trying both, the repo shared by @deadwood83 and the ESPHome’s ld2410 component this time more in-depth.
Will post updates if I get any more info.
Thank you all guys and let me know if you have any further questions.
So easy. Then for configuring the distances one can use the configuration variables as explained in the docs:
gX_move_threshold (Optional, int): Threshold for the Xth gate for motion detection (X => 0 to 8). Above this level for the considered gate (distance), movement detection will be triggered. Defaults to see table below.
gX _still_threshold (Optional, int): Threshold for the Xth gate for still detection. (X => 0 to 8). Above this level for the considered gate (distance), still detection will be triggered. Defaults to see table below.
One question, I see in the website the screen capture with the exposed entities, and the temperature is 44.5°C which I guess it’s closer to the board temperature than to the ambient one. It’s because the sensor is too close to the board? Do you think it can be programatically proportionally adjusted to match room temperature?
Already taken care of That screenshot is very old and showed the raw value, but I like to keep it up to give you an idea of the entities and how they appear in Home Assistant.
The code that is shipped with the Unity sensors applies what you have suggested. It uses readings from the MCU onboard internal temperature and calculates a more accurate room temperature.
I have some posts with more details on it here and here.
Here are some comparison graphs showing the Unity sensor against another off-the-shelf sensor:
Yes, of course! The STL file will be made available for free. I can’t offer all the colours in the world but the least I can do is allow you to print your own.
One word of caution, the STL file is designed for resin printing with very tight tolerances (manufacturing level tolerances). You may need to tinker with the scaling to get it working for you.
Just wondering if you ever found a way to restore the LD2410 to functioning after this happened? Your comment hit me like a brick. I have been playing with these sensors for a year now and intermittently running into this unreliability and never connected it to the firmware updates on the ESP32, but this must be it.