LD2410 esphome tips

Looking at the ld2410’s firmware protocol, the settings are independent, and the engineering mode just gets more information to display (including the fact that the light is actually one for the internal linkage role, so the light must need the engineering mode).

But hard coding the values in is done when initializing the ld2410. I think this would work.

But if it’s a ld2410 with bluetooth (b or c), this will unfortunately have a little side effect: it will no longer be possible to change the parameter settings while using bluetooth, because the parameters will be defaulted every time the ld2410 is rebooted.

Since we have been using a library for our mod version of the ld2410 in the early days, we have experienced these.
I think these behaviors should probably be similar on the new version of the ld2410 library.

I don’t believe this to be correct. I believe I configured the sensor via BT and found the values had been updated in ESPHome so upon reboot they would stay as configured. I haven’t done it in a few weeks but I am quite sure it was doing it.

EDIT: I’ve been using the updated integration for months while it was getting ready to be merged so my comments were related to that version.

It only happens on top of older versions of the LD2410 library and hard-coded parameters.

esphome/esphome/components/ld2410/ld2410.cpp at 2023.7.1 · esphome/esphome (github.com)
As can be seen from, for example, the code for esphome 2023.7.1, all gate configuration data is written once during setup initialization, which can result in overwriting user-defined settings data.

This initialization occurs when esphome initializes the ld2410 library after an esphome reboot.

We diy’d this radar at a early stage, and also got some user feedback to investigate this please.

But in the new version of the ld2410 library (regverb’s pull was merged into the mainline in 2023.8.0), you can see that this problem disappeared, and there is no more problem with forcing hard configuration writes. So the problem exists in older versions of the ld2410 library (2023.7.2 and before).

esphome/esphome/components/ld2410/ld2410.cpp at 2023.8.0 · esphome/esphome (github.com)

Do you know which ip is being used for the firmware? AFAIK I have not block of Chinese IPs but I also get “Failed to obtain the firmware:-1” when open the Firmware tab.

Or maybe it means there are no firmware available? I am on 2.04

I tested what’s going on in my area and the latest version of the firmware is still V2.04.

For the error code -1, this is a really peculiar situation.
I might ask the hilink tech what that stands for.
I think it could be caused by network acquisition somehow though.

I also started getting the above error, but only after the last update to the HLKRadar app.
The sensors already have version 2.04

@pepe59
hilink is initially investigating the issue but has no leads yet, it would be great if you guys could take a screenshot or record a screen video of what’s going on.
They seem to be working very hard to optimize the experience of many apps.

the screenshot contain “Failed to obtain the firmware:-1”, seems can help them.

Here is a screen shot of the error:

1 Like

Where do you report stuff to Hi-link? I would also add a FR to get a timeout for the move sensor. The existing timeout just work for presence.

Yes, I have the same screen.

I suspect you first buy a shit-ton of gear from them :slight_smile:

2 Likes

Feedback has been given and it seems to be oh so common.

@distante

In the earliest days we had the same question, we were interested in light and asked questions in hilk’s forum and got answers. In later years when we DIY’d the ld2450, we got quite a bit of tech support since it was a new product.
We had a more private channel to do so.
In Chinese, Hi-Link has a website dedicated to more technical answers to questions, which is kind of a more efficient channel: https://ask.hlktech.com/
They also have a similar technical phone number, where you dial a certain extension, get connected to a certain engineer, and then you can get in touch with them directly.

@nickrout

The direct competition between these module and chip vendors in China is quite fierce, and most offer very user-friendly technical support, which is always on standby.
Of course to find them may need a little threshold, if too many of the kind of primary problems (in China, this is also often), then these engineers can not do anything, they will often put these primary problems to prepare a QQ group, so that users can communicate with each other, which is probably a few hundred or a few thousand people. Practical information is very little, but most of them are just looking out for each other.

2 Likes

Sounds very user unfriendly.

Guys, help me understand…
Configuration on older version of esphome - worked.
Started writing when trying to update, something like:
The ‘g0_move_threshold’ option has been moved to the ‘g0_move_threshold’ number component.

Did it like this (Without “ld2410:”: error Component sensor.ld2410 requires component ld2410.):

ld2410:
number:

  • platform: ld2410
    timeout: 10s
    max_move_distance: 1.5m
    max_still_distance: 1.5m
    g0_move_threshold: 40
    g0_still_threshold: 10

Error where ‘timeout’ : some but not all values in the same group of inclusion ‘timeout’.

Tried to do it like this:
number:

  • platform: ld2410
    timeout:
    name: Timeout

What does this miracle Yudo want from me?

Have a look at the latest ESPHome entry for the LD2410, there had to be some major format changes to the YAML to get it accepted.

I changed according to this manual, based on my old config, but I don’t understand what my problem is …
Here it works:

number:

  • platform: ld2410
    timeout:
    name: timeout
    light_threshold:
    name: light threshold
    max_move_distance_gate:
    name: max move distance gate
    max_still_distance_gate:
    name: max still distance gate
    g0:
    move_threshold:
    name: g0 move threshold
    still_threshold:
    name: g0 still threshold
    g1:
    move_threshold:
    name: g1 move threshold
    still_threshold:
    name: g1 still threshold
    g2:
    move_threshold:
    name: g2 move threshold
    still_threshold:
    name: g2 still threshold
    g3:
    move_threshold:
    name: g3 move threshold
    still_threshold:
    name: g3 still threshold
    g4:
    move_threshold:
    name: g4 move threshold
    still_threshold:
    name: g4 still threshold
    g5:
    move_threshold:
    name: g5 move threshold
    still_threshold:
    name: g5 still threshold
    g6:
    move_threshold:
    name: g6 move threshold
    still_threshold:
    name: g6 still threshold
    g7:
    move_threshold:
    name: g7 move threshold
    still_threshold:
    name: g7 still threshold
    g8:
    move_threshold:
    name: g8 move threshold
    still_threshold:
    name: g8 still threshold

But what… why can’t you specify the values manually that were before:
timeout: 10s
max_move_distance: 1.5m
max_still_distance: 1.5m
g0_move_threshold: 40 # 0m / 0’
g0_still_threshold: 10 # 0m / 0’
g1_move_threshold: 40 # 0 - 0.75m / 0 - 2.46’
g1_still_threshold: 10 # 0 - 0.75m / 0 - 2.46’
g2_move_threshold: 40 # 0.75 - 1.5m / 2.46’ - 4.92’
g2_still_threshold: 10 # 0.75 - 1.5m / 2.46’ - 4.92’
g3_move_threshold: 40 # 1.5 - 2.25m / 4.92’ - 7.38’
g3_still_threshold: 10 # 1.5 - 2.25m / 4.92’ - 7.38’
g4_move_threshold: 40 # 2.25 - 3m’ / 7.38’ - 9.84’
g4_still_threshold: 40 # 2.25 - 3m’ / 7.38’ - 9.84’
g5_move_threshold: 40 # 3 - 3.75 / 9.84’ - 12.30’
g5_still_threshold: 40 # 3 - 3.75 / 9.84’ - 12.30’
g6_move_threshold: 30 # 3.75 - 4.5m / 12.30’ - 14.76’
g6_still_threshold: 15 # 3.75 - 4.5m / 12.30’ - 14.76’
g7_move_threshold: 30 # 4.5 - 5.25m / 14.76’ - 17.22’
g7_still_threshold: 15 # 4.5 - 5.25m / 14.76’ - 17.22’
g8_move_threshold: 30 # 5.25 - 6m / 17.22’ - 19.68’
g8_still_threshold: 15 # 5.25 - 6m / 17.22’ - 19.68’

I cured that problem by adding this just after the uart entry.

ld2410:
  throttle: 1500ms
  id: ld2410_comp

I only found this as I had left it in in one of my 4 configurations which was the only one working. No idea where it came from, or what it does :slight_smile:

It can be a bit frustrating if you don’t find the right channel, initially we had a couple of modules that were so poorly packaged and broken that we wanted to seek an investigation, but the store’s customer service argued that it couldn’t possibly be a problem because tens of thousands of LD2410 radars are made every month.
But the developers immediately ruled out if the modules in the warehouse were the same after feedback.

But certain aspects, when the price/performance revolution came and hilink brought fire to the 24G radar, I think they have been there to improve improve these issues. But store customer service is probably the lowest level of tech support channel.

The reason is now the values are configured in HA and not in ESPHome.
It was done to simplify the tuning of the LD2410 so you don’t need to have to recompile and upload it with ESPHome each time you had to make a change to the threshold values.

I installed LD2410 outside (under the roof so it is secure - rain will not fall on it directly) and when it rains this sensor detects movement and triggers false positives constantly. Which sliders should I adjust to stop this?