{"id":13035,"date":"2026-09-15T07:35:00","date_gmt":"2026-09-15T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13035"},"modified":"2026-09-09T13:24:55","modified_gmt":"2026-09-09T11:24:55","slug":"tutorial-setting-up-ld2450-radar-zones-in-esphome-and-home-assistant","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/smart-home\/tutorials-en-smart-home\/tutorial-setting-up-ld2450-radar-zones-in-esphome-and-home-assistant\/","title":{"rendered":"Tutorial: Setting Up LD2450 Radar Zones in ESPHome and Home Assistant"},"content":{"rendered":"

A presence radar of the LD2450 kind does something a motion detector never could: it says where. Up to three targets, each with an x and a y coordinate in millimetres, updated several times a second.<\/p>\n

That turns the interesting question into a geometric one. A zone is four numbers – two on each axis – and everything that makes such a setup useful or maddening happens in how those four numbers are arrived at.<\/p>\n

\n\"A
The origin sits at the sensor, y runs forward, x runs sideways and is negative on the left. A zone is a rectangle in that frame – not in the room.<\/figcaption><\/figure>\n

What the Sensor Actually Reports<\/h2>\n

The LD2450 is a 24 GHz radar that tracks up to three targets at once. Per target it delivers three numbers: an x coordinate, a y coordinate and a speed – the first two in millimetres, the last in centimetres per second, with a negative sign meaning movement towards the sensor.<\/p>\n

This is where it differs from its smaller sibling. The LD2410 answers only whether something is there and roughly how far away, split into distance gates. It cannot separate a desk from a doorway, because it has no idea in which direction either lies.<\/p>\n

Two properties are worth knowing before any mounting happens. The detection area is a wedge of about 120 degrees, so 60 degrees to each side of the front direction – anything outside it is invisible regardless of distance. And the useful range indoors is around six metres, with the accuracy of the coordinates falling off well before that.<\/p>\n

Fixing the Origin Before Anything Else<\/h2>\n

Every zone number refers to a coordinate frame whose origin is the sensor itself. The y axis points in the direction the board faces; the x axis runs across it, negative to the left, positive to the right, seen from behind the sensor.<\/p>\n

Three consequences follow, and all three are cheaper to handle before the module is glued to a wall.<\/p>\n

A sensor mounted rotated by ninety degrees swaps the axes, and every zone drawn on a floor plan has to be transposed. A sensor mounted upside down mirrors the x axis, so left and right change places and the zone lands on the other side of the room. And a sensor moved twenty centimetres to a nicer spot invalidates every zone at once, because all of them were measured from where it used to be.<\/p>\n

The practical mounting position for an LD2450 is on a wall at roughly 1.2 to 1.5 metres – about waist height. Higher up, the radar looks down onto people rather than across at them, and the y coordinate then measures a diagonal rather than a distance along the floor. A ceiling position is a job for a different sensor.<\/p>\n

The Configuration, and Where the Zone Lives<\/h2>\n

The ESPHome side is short. The radar speaks over a serial connection at 256 000 baud, and the component turns that into entities.<\/p>\n

uart:\n  id: uart_radar\n  tx_pin: GPIO17\n  rx_pin: GPIO16\n  baud_rate: 256000\n  parity: NONE\n  stop_bits: 1\n\nld2450:\n  id: radar\n  uart_id: uart_radar\n  throttle: 1000ms\n\nbinary_sensor:\n  - platform: ld2450\n    ld2450_id: radar\n    has_target:\n      name: \"Presence\"\n    zone_1:\n      occupancy:\n        name: \"Desk occupied\"\n    zone_2:\n      occupancy:\n        name: \"Doorway occupied\"\n\nsensor:\n  - platform: ld2450\n    ld2450_id: radar\n    target_1:\n      x:\n        name: \"Target 1 X\"\n      y:\n        name: \"Target 1 Y\"\n      speed:\n        name: \"Target 1 speed\"\n    zone_1:\n      target_count:\n        name: \"Targets at the desk\"\n\nnumber:\n  - platform: ld2450\n    ld2450_id: radar\n    presence_timeout:\n      name: \"Presence timeout\"\n    zone_1:\n      x_begin:\n        name: \"Zone 1 X begin\"\n      y_begin:\n        name: \"Zone 1 Y begin\"\n      x_end:\n        name: \"Zone 1 X end\"\n      y_end:\n        name: \"Zone 1 Y end\"<\/code><\/pre>\n
The throttle<\/code> is the setting most worth having. Without it the radar reports several times a second, and every one of those reports becomes a state change in Home Assistant. One second is plenty for lighting and keeps the database from growing by a megabyte a day per sensor.<\/p>\n
Where the zone bounds live is the detail that surprises people. They are not values in the YAML – they are numbers stored in the radar module’s own flash, and ESPHome exposes them as number entities so they can be set once. That is convenient, because a zone can then be corrected from a phone while standing in the room. It is also a trap, because a replaced module comes back with the factory zones and nothing in the configuration says what they used to be. The four numbers per zone belong in a comment in the YAML, if only as documentation.<\/p>\n
Measuring the Zone Instead of Guessing It<\/h2>\n
Zone bounds taken from a floor plan are wrong often enough that measuring is faster. The measurement needs one person, five minutes and the two coordinate sensors from the configuration above.<\/p>\n
Standing at each corner of the intended zone and reading the x and y values gives the rectangle directly. Four corners, eight numbers, and the extremes of those are the bounds. A tolerance of about twenty centimetres on each side is worth adding, because a person is not a point: the radar reports the centre of the reflection, and that wanders across the body with every turn.<\/p>\n
Corner measurements at the desk (x \/ y in mm)\n\n  front left     380 \/  840\n  front right   1760 \/  810\n  back left      420 \/ 2310\n  back right    1780 \/ 2360\n\nZone 1 with tolerance:  x  300 \u2026 1800     y  800 \u2026 2400<\/code><\/pre>\n
Two checks belong to the same session. Walking through the zone and out again should switch the occupancy sensor cleanly in both directions. And standing just outside the boundary should not – if it does, the zone is bigger than intended, or the reflection is coming from somewhere other than the person.<\/p>\n
The second check is the one that finds the mounting mistakes. A metal cabinet, a radiator or a large mirror reflects the radar signal and produces a target that stands where nobody is. Such a phantom is recognisable by being perfectly still and never leaving; the fix is a different sensor angle, not a smaller zone.<\/p>\n
The Automation, and the Part That Makes It Flicker<\/h2>\n
With a working zone, the automation itself is unremarkable – and would flicker without one line.<\/p>\n
binary_sensor:\n  - platform: ld2450\n    ld2450_id: radar\n    zone_1:\n      occupancy:\n        name: \"Desk occupied\"\n        filters:\n          - delayed_off: 20s<\/code><\/pre>\n
The delayed_off<\/code> is the difference between a lamp that stays on while somebody works and one that switches off whenever the person leans back. A radar loses a still target more easily than a moving one, and twenty seconds of hold costs nothing while it removes the entire class of complaint.<\/p>\n
Its counterpart is the presence timeout in the module itself, which decides how long the radar keeps reporting a target after the last detection. Both delays add up, so a five-second timeout plus a twenty-second filter means the light goes out twenty-five seconds after the desk is empty. Worth setting on purpose rather than by accident.<\/p>\n
On the Home Assistant side, one rule saves a lot of debugging: an automation should react to the zone sensor, never to the raw coordinates. A trigger on a numeric x value fires on every jitter of the reported centre, and the same person sitting still can cross such a threshold dozens of times an hour.<\/p>\n
What Still Goes Wrong Afterwards<\/h2>\n
Three effects account for most of the remaining trouble, and each has a different fix.<\/p>\n
The first is movement that is not a person. A fan, a curtain in a draught, a hanging plant – all of them move, all of them reflect, and to the radar they look like a slow target. A zone that excludes them is the cleanest answer; where that is not possible, a minimum speed condition helps, because the artefacts rarely produce a consistent direction.<\/p>\n
The second is the neighbouring room. Twenty-four gigahertz passes through plasterboard with little loss, and a zone laid against a wall therefore also covers the sofa behind it. The coordinates say nothing about walls, because the radar knows nothing about them. Only measuring finds this, and it is worth doing deliberately: someone walks around in the next room while the target count is watched.<\/p>\n
The third is that a second radar in the same room disturbs the first. Two LD2450 modules on the same frequency and pointing at each other produce targets in both that belong to neither. Where two are needed, they should face away from each other, and the overlap of their wedges should stay small.<\/p>\n
\n
Sources<\/h2>\n