This external ESPHome component adds support for the Hi-Link HKL-LD2450 Human presence sensor to ESPHome. In addition to a basic binary presence sensor, this component adds various different sensors for each detected target and supports custom presence detection Zones.
esphome logs
).x
and y
coordinates.This will give you binary occupancy sensors for individual zones.
Adding a small off_delay
filter is recommended for tracking stability.
Zones can overlap one another. A good use-case example for this is the following:
Consider a room in which the sensor is mounted, such that it is off-angle with a door. If the sensor can track through the door, this may be undesired behavior.
Creating a zone that outlines the room can help solve this issue.
This sketch is intended to help understand zones and margins.
The y-axis is referred to as the axis pointing straight away from the sensor. The x-axis is located perpendicularly. A Target is tracked once it enters the polygon given by the configuration (green polygon within the sketch). Once tracked, a Target is allowed to move freely within the yellow polygon. This larger area is given by the base polygon and the margin
.
If a tracked target leaves the yellow area it is not tracked anymore and the zone becomes unoccupied. Additionally, it won't be tracked immediately again since it is now outside of the green zone.
LD2450:
uart_id: uart_bus
occupancy:
name: Occupancy
This is the most basic useful
configuration. You can find this example alongside other more complex examples in the example folder of this repository. An example configuration with all possible sensors and configurations can be found here.
LD2450
.false
.false
.5°
.25cm
.id
or name
required. All options from Binary Sensor.id
or name
required. All other options from Sensor.3
Targets. Each target has its own configuration and sensors. See Target.Instead of a fixed maximum tilt angle, a user-defined number component can be defined. The values of this component will be used as the highest allowed angle.
90°
- required unit is °
or deg
. This value will be ignored if restore_value
is enabled.1°
.true
.All other options from number.
Instead of a fixed minimum tilt angle, a user-defined number component can be defined. The values of this component will be used as the highest allowed angle.
-90°
- required unit is °
or deg
. This value will be ignored if restore_value
is enabled.1°
.true
.All other options from number.
Instead of a fixed maximum distance, a user-defined number component can be defined. The values of this component will be used as the furthest allowed distance.
6m
. This value will be ignored if restore_value
is enabled.10cm
.true
.All other options from number.
The name of target sub-sensor will be prefixed with the target name. For instance, if the Target is called Target 1
and a sub-sensor of this target is named X Position
, the actual name of the Sensor will be Target 1 X Position
.
Each sensor requires at least an id
or a name
configuration.
The default polling rate is 1s
. If you end up using these sensors I would recommend excluding them from your Home Assistant Recorder.
Target x
with increasing values for x
.false
.X Position
. All other options from Sensor.Y Position
. All other options from Sensor.m/s
. The default name is Speed
. All other options from Sensor.Distance Resolution
. All other options from Sensor.°
. The default name is Angle
. All other options from Sensor.m
. The default name is Distance
. All other options from Sensor.A valid configuration may look like this or this:
targets:
- target:
debug: true
angle:
id: t1_angle
The name of zone sub-sensor will be prefixed with the zone name. For instance, if the zone is called Dining Table
and a sub-sensor of this zone is named Occupancy
, the actual name of the Sensor will be Dining Table Occupancy
.
25cm
.5s
.id
or name
required. The default name is empty, which results in the sensor being named after the zone. All options from Binary Sensor.id
or name
required. The default name is empty, which results in the sensor being named after the zone. All options from Sensor.A valid configuration may look like this or this:
zones:
- zone:
name: "Dining table"
margin: 25cm
polygon:
- point:
...
occupancy:
id: or_occupancy
target_count:
id: or_target_count
A polygon is made up of multiple points in physical space. The polygon must be a simple convex polygon.
x-axis
from the sensor.y-axis
from the sensor.A valid configuration may look like this or this:
# Polygon which covers one half of the sensor
polygon:
- point:
x: 0m
y: 0m
- point:
x: 0m
y: 6m
- point:
x: 6m
y: 6m
- point:
x: 6m
y: 0m
Alternatively, a polygon can also be defined via a template expression like this:
# Template polygon which updated every 2 seconds
polygon:
lambda: !lambda |-
return {ld2450::Point(1500,10), ld2450::Point(6000,10), ld2450::Point(6000,2600), ld2450::Point(-1500,2600)};
update_interval: 2s
return std::vector<ld2450::Point>;
): List of Points which make up a convex polygon. The expression is evaluated every update_interval
, if the provided polygon is invalid (i.e. not convex or too small) the previously used polygon is kept.0s
to disable. Defaults to 1s
.The polygon used by a zone can be updated with the zone.update_polygon
action.
The change is only effective, if the provided polygon is valid.
on_...:
- LD2450.zone.update_polygon:
id: z4
polygon: !lambda |-
return {ld2450::Point(1500,10), ld2450::Point(6000,10), ld2450::Point(6000,2600), ld2450::Point(-1500,2600)};
return std::vector<ld2450::Point>;
): List of Points which make up a convex polygon. The new polygon is only used if it's valid.With the help of this action, a user editable dynamic polygon can be defined. Note, that this allows for the definition of non-convex polygons. In the referenced example, the number components are only updated if the new polygon is valid. When using the Home Assistant front end, number sliders may not reflect this change (or rather lack thereof) properly. A partial example configuration for dynamic template polygons can be found here.
When using Dupont connectors make sure they make proper contact. The very short pins on the LD2450 Sensor can easily go loose or break.
I recommend using a 5V
power supply and the 5V
input pin whenever possible.
Using the the 3.3V
pin on the LD2450 sensor may cause instabilities during operation depending on the power supply, voltage regulator and other components used on the same power circuit.
In a test scenario using a 3.3V
voltage regulator, an ESP-01 and a DHT22 the LD2450 sensor was not able to provide measurements. Observing the LD2450's TX pin using an oscilloscope yielded no updates and noisy behavior around 3.3V
. Switching to 5V
on the LD2450 sensor resolved this issue and consistent updates from the sensor were observed.
In a different scenario, when using 3.3V
provided by an ESP32 development board, sensor updates arrived inconsistently/went missing.
In some configurations, this LD2450 component may not perform ideally. If this component is used in combination with other components on a single ESP, especially ones that require long processing times, some updates provided by the sensor may be missed. As a symptom (zone) count sensors may report as Unknown
for short periods of time and switches become unresponsive.
If this is the case try the following steps:
rx_buffer_size
5V
power source for the sensor