After the ESPhome 2023.2.0 update, I tried the compilation on the D1 mini and it passed without errors.
I will try everything when I connect the sensor.
can you provide your code please?
Here is. Change the sensor names to your native language.
It will take some fiddling with the zone settings, but it works for now.
esphome:
name: radar-ld2410-1
friendly_name: radar-ld2410-1
esp8266:
board: esp01_1m
# Enable logging
logger:
baud_rate: 0
# Enable Home Assistant API
api:
ota:
password: "f1fc1dd8782116f1fd13d8c5f3092c"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Radar-Ld2410-1 Fallback Hotspot"
password: "lQGe1BWnVOcs"
captive_portal:
uart:
id: uart1
tx_pin: 1
rx_pin: 3
baud_rate: 256000
parity: NONE
stop_bits: 1
ld2410:
timeout: 5s
max_move_distance : 6m
max_still_distance: 0.75m
g0_move_threshold: 50
g0_still_threshold: 0
g1_move_threshold: 50
g1_still_threshold: 0
g2_move_threshold: 40
g2_still_threshold: 40
g3_move_threshold: 40
g3_still_threshold: 40
g4_move_threshold: 40
g4_still_threshold: 40
g5_move_threshold: 40
g5_still_threshold: 40
g6_move_threshold: 30
g6_still_threshold: 15
g7_move_threshold: 30
g7_still_threshold: 15
g8_move_threshold: 30
g8_still_threshold: 15
sensor:
- platform: ld2410
moving_distance:
name : Pohyb cíl vzdálenost
still_distance:
name: Statický cíl vzdálenost
moving_energy:
name: Pohyb cíl energie
still_energy:
name: Statický cíl energie
detection_distance:
name: Detekční vzdálenost
binary_sensor:
- platform: ld2410
has_target:
name: Přítomnost
has_moving_target:
name: Pohybující se cíl
has_still_target:
name: Statický cíl
i dont see any difference with my code…
Nope doesnt compile…same error : complaining about ld2410 component not found…
i think there is something missing in my EspHome update…i delete addon and reinstall…same problem…
ld2410: [source /config/esphome/capteur-presence-sejournew.yaml:41]
Component ld2410 cannot be loaded via YAML (no CONFIG_SCHEMA).
Platform not found: 'binary_sensor.ld2410'
Platform not found: 'sensor.ld2410'.
I found a solution: for those having problems with ld2410 component in EspHome 2023.2.1, add this to your node did the trick :
external_components:
- source: github://esphome/esphome@dev
components: [ ld2410 ]
i dont understand why i am the only one who having trouble with LD2410 component in the last EspHome 2023.2.1 or 2023.2.2 of today, same problem…
I use the “standard” AddOn : EspHome, not “Beta” or “Dev” version, and it seems that LD2410 is, for the moment, only on the Dev version of the EspHome AddOn, that why the component LD2410 is not found on the basic version of EspHome 
Did anyone ever get to the bottom of the “unknown” sensors, glad to see others have the same issue at least? I’m using the minimal examples from the esphome documentation and it’s still giving me unknown for the sensors. I know the device is working as I can see it in the bluetooth app. I’ve tried the custom yaml in here (same problem) but I’d prefer to stay as simple as possible ideally. TX on the board is wired to RX on the d1 mini and RX is wired to TX on the v3 d1_mini as per the above examples.
esphome:
name: living_room_ld2410
# Enable Home Assistant API
api:
esp8266:
board: d1_mini
logger:
baud_rate: 0
ota:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "LD2410 Fallback Hotspot"
captive_portal:
uart:
id: uart1
tx_pin: 3
rx_pin: 1
baud_rate: 256000
parity: NONE
stop_bits: 1
ld2410:
timeout: 150s
max_move_distance : 6m
max_still_distance: 0.75m
g0_move_threshold: 10
g0_still_threshold: 20
g1_move_threshold: 10
g1_still_threshold: 20
g2_move_threshold: 20
g2_still_threshold: 21
g3_move_threshold: 30
g3_still_threshold: 31
g4_move_threshold: 40
g4_still_threshold: 41
g5_move_threshold: 50
g5_still_threshold: 51
g6_move_threshold: 60
g6_still_threshold: 61
g7_move_threshold: 70
g7_still_threshold: 71
g8_move_threshold: 80
g8_still_threshold: 81
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
binary_sensor:
- platform: ld2410
has_target:
name: Presence
has_moving_target:
name: Moving Target
has_still_target:
name: Still Target
I already had a problem with cables several times. I do not recommend soldering directly to the pins. Use a plug. Replace the cables.
Check this:
TX Pin: GPIO1
RX Pin: GPIO3
uart:
id: uart1
tx_pin: TX
rx_pin: RX
Alas I’m almost certain I have a bad board, I’ve tried everything I can think of now. I’ve not had a problem with any of my other esphome projects.
- 5 different sets of micro JST connectors
- Connected to TX and RX pins on the D1 and also to D7, D8.
- Two D1 minis of different versions
- Multiple different versions of esphome config.
I’ve resorted to putting a ESP32 bluetooth beacon nearby which seems to be working okay. Although not an ideal setup.
Same here. Will also debug this weekend. I’m not sure the board is broken. Maybe we can create a normal arduino script for the sensor and see by logging to the serial port if the measurements are stable and keep coming. Because in my case I fully loose connection to the espboard and therefore have no logs anymore
Yeah perhaps not fully broken as it does still work in bluetooth mode which is how I’m now using it but perhaps some bad UART connections soldered onto the board. I don’t have too much time to look into it at the moment so I’m hoping in a few weeks time someone has wrote up a definitive tutorial on getting these working with a D1 mini with troubleshooting tips! If more people report the same issue I suspect there might be some quality control issues with the boards mind.
I will try to investigate, reason I want to check it this way is that if I keep receiving messages over UART when it’s a simple (non-esphome) sketch the issue might be in the esphome. Maybe the large amount of messages/updates is crashing the ESP/D1 in combination with Wifi/ethernet
The problem with that theory is there are plenty of people in here using the D1 mini successfully. I’d point the finger more towards the LD than the D1 personally.
A recent firmware update to the LD2410C board enables a light sensor. Has anyone worked out how to get that sensor into HA yet?
I installed LD2410 BLE and it works great.
LD2410 BLE
What firmware update will allow the on board LED to function? I updated the firmware from V1.07.22091516 to V2.04.23022511 using the Iphone HiLink app but LED still not functioning.
For anyone that purchased the LD2410 Kit board (comes with a LD2410B and the correct header for it to plug in to the board) there are other through holes wired on the board with the correct spacing for the LD2410C. But you will need to use jumpers to reverse the TX and RX lines to get it to work.
I have one question, mine seemed to work pretty good during testing but lately always is detecting occupied (the numbers keep varying so it is reading the data). I ready the very limited PDF and it states the voltage should be 3.6-5V. I am running from 3.3V could that be an issue and should I switch to 5V? That may also remove some of the power draw from the ESP32S2 Mini regulator as it seemed to get warm.
It should look like the above, no space for the variable ‘number’.
yes you should use 5v
Doh, this is why you should read the entire thread. I was trying to use the ld1115h yaml on the ld2410B all day and obviously it didn’t work. I am also using a Seeed XIAO ESP32-C3 due to their super small size so the ld2410 yaml should work but I am just to lazy to go back and fix it at the moment. I did get it working but just as a basic “detection” sensor with no controls. I’m sure it will work with the correct TX and RX pins and additional *.h file. I will try later.
I personally found the BT integration to be “flaky” but that is probably my terrible soldiering job as I cut a power only USB cable and soldiered the 5V power and ground cables but it’s a lot of fun with the 1.25mm spacing on the ld2410, with or without headers so I am suspecting that is more then likely the issue. Need to hook one up with headers to a spare USB cable that has a 5V and ground output among other outputs for flashing stuff for ESPHome to verify.
For the price, I wouldn’t be surprised if it was damaged in shipping but still, you can’t beat the price. The DFRobot is great but you can get 7 to 10 of these for the price of one of the DFRobot’s. I also own one of the Seeed 60Mhz fall detectors but it is WAY to sensitive but would probably be great under a bed for sleep detection. They have another 60Mhz model that can read your heart rate so they are obviously very, very sensitive to any movement at all. Fans and pets are not good for mmwave sensors, that is for sure. I have posted what I ended up (hope it truncates) with for the day but going to go back and use the other yaml code for the ld2410 as it has way more controls and options at some point but just in case it helps anyone as I had some “fun” today getting it to work just to find out there was different yaml code for the ld2410 as I thought it was the C3 that was just a few posts down. Yay me. If you ever have to use the output pin for an input from either model it will always hook to the MISO pin on whatever flavor ESP32 you are working with, had fun figuring that out (still learning).
substitutions:
devicename: "esp-radar" #Rename the device what you want.
upper_devicename: ESP Radar #Rename the device what you want.
esphome:
name: $devicename
esp32:
board: esp32-c3-devkitm-1
variant: esp32c3
framework:
type: esp-idf
version: recommended
# Enable logging
logger:
# level: DEBUG
# baud_rate: 0
# Enable Home Assistant API
api:
encryption:
key: "durrrrrrr"
ota:
password: "blahhh"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
use_address: xxx.xxx.x.x
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "esp-radar fallback hotspot"
password: "zzzzzzzz"
uart:
id: LD1115H_UART_BUS
rx_pin: GPIO7 #Using SDA and SCL pins, RX and TX should work fine (GPIO20 and 21 on seeed esp32-c3) but was to lazy to switch back as this works
tx_pin: GPIO6 #
baud_rate: 460800
#debug:
# direction: BOTH
# dummy_receiver: true
# after:
# delimiter: "\n"
# sequence:
# - lambda: UARTDebug::log_string(direction, bytes);
binary_sensor:
- platform: status
name: ${upper_devicename} Status
- platform: gpio
name: ${upper_devicename} LD1115H Occupancy or Movement
id: LD1115H_MovOcc_Binary
device_class: occupancy
pin:
number: GPIO9
mode:
input: true
pulldown: true
sensor:
- platform: wifi_signal
name: ${upper_devicename} WiFi Signal
update_interval: 60s
- platform: uptime
name: ${upper_devicename} Uptime
text_sensor:
- platform: wifi_info
ip_address:
name: ${upper_devicename} IP Address
ssid:
name: ${upper_devicename} SSID
bssid:
name: ${upper_devicename} BSSID
mac_address:
name: ${upper_devicename} Mac Address
Excellent discovery! Thanks for your post, it solves my same issue too. Was struggling 1 day to make it work and your post saved me. On top of the settings with using the other UART I’ve disabled also logging to finally be able to see values comming:
# Enable logging
logger:
level: none
baud_rate: 0