[HELP] ESPHome mmWave sensor acting weirdly

ESPHome
, ,
#1

Hi all,

I have a problem with a sensor acting weirdly and not reporting data correctly.

Scenario

It’s a Hi Link sensor, the LD2410C mmWave presence. This is the sensor:

image

I have it soldered to a Wemos D1 Mini ESP32 board and is reporting data that I can integrate into HA. This is the board:

image
image696×479 102 KB

I’m using this software to get the sensor’s data: GitHub - rain931215/ESPHome-LD2410: ESPHome LD2410 mmWave Radar Sensor Custom Component
Note that I have tried others but the problem is the same, so it’s not a problem with the software.

Connections

Sensor       Board
VCC          3V3
GND          GND
TX           RX (GPIO21)
RX           TX (GPIO17)
OUT          GPIO16 (It is soldered to that pin but I think it's unused by the software)

Here is the YAML config:

uart:
  id: uart1
  tx_pin: GPIO17
  rx_pin: GPIO21
  parity: NONE
  baud_rate: 256000
  stop_bits: 1
  debug:
    direction: BOTH
    dummy_receiver: false
    after:
      delimiter: [0xF8,0xF7,0xF6,0xF5]

The sensor configuration is as described in the project’s config: ESPHome-LD2410/ld2410.yaml at c71e43a39dc851c0b651816739cbbbfb41beeaab · rain931215/ESPHome-LD2410 · GitHub

The problem

So the problem is that this sensor exposes 3 binary states:

  1. Has Still target
  2. Has Moving target
  3. Has target

But there is always one ON. See this GIF as explanation. For this test I’m not even in the same room as the sensor.

screen-capture-1

It looks like one is the opposite of the other. It never reports all of them as OFF. If the first one is ON, the other will be OFF and vice-versa.

Thoughts

I think the problem must be either one of:

  1. The sensor is broken
  2. Soldering the OUT pin of the sensor is making it act

I have been going through the code and saw where it is getting the values. Here: ESPHome-LD2410/ld2410_uart.h at c71e43a39dc851c0b651816739cbbbfb41beeaab · rain931215/ESPHome-LD2410 · GitHub

#define CHECK_BIT(var, pos) (((var) >> (pos)) & 1)

/*
  Target states: 9th byte
  0x00 = No target
  0x01 = Moving targets
  0x02 = Still targets
  0x03 = Moving+Still targets
*/
char stateByte = buffer[8];

hasTarget->publish_state(stateByte != 0x00);
hasMovingTarget->publish_state(CHECK_BIT(stateByte, 0));
hasStillTarget->publish_state(CHECK_BIT(stateByte, 1));

Is it possible that somehow the bits sent by the sensor are off?

I have to mention that I tested this sensor with another ESP32 board a few weeks ago and it was working properly. So if the sensor is broken it must have been me who broke it.

Thanks for your time, if you can point me to any resource or similar issues I would appreciate it. I’m at a loss.

#2

I not using the same sensor but a very similar one LD2410 the original one not the “c” version. And really have no idea if this will help or not.

My Uart is configured as below.

uart:
  id: uart_bus
  tx_pin:
    number: GPIO1
  rx_pin: 
    number: GPIO3
  baud_rate: 256000
  parity: NONE
  stop_bits: 1

the first time I set it up on different pins and it did not work. I can only suggest move it to the RX and TX pins.

The config i use came for here

Mine has been working for a few months now, but did take some setting up, to get reliable readings from it.

#3

Hi,
I put together some config on git that you can test out: LoopOnCode · GitHub

It will be used for this: Unity Sensor – LoopOn

If your sensor is using the same protocol as the LD2410 (without the c) then it should work.

Ps: remove the additional sensors from the config.

#4

I know you are using this with an ESP32 device, but have you tried the device using the HI-Link integration?

At least just to see if it’s working ok. I just ordered some and will test the integration when they arrive.

#5

This is likely a software issue.

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.

However, there is a repo that exposes all the gates together with still AND moving energy thresholds which are remotely configurable. Aha! I found it. GitHub - kippesikgithub/esp_motion_mmwave: LD2410 mmwave Motion detection in ESPHome for Home Assistant . Can be combined with temperature, humidity and lux sensor

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.

#6

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

#7

Thank you guys for your responses.

I’ve been out of town for the last month and couldn’t play with ESP32 :frowning: Will come back next week and try your suggestions!