If you bought one of our 60GHz mmWave radars — fall detection, presence, or sleep monitoring — and configured it for MQTT, the next natural step is to get that data into a dashboard you can actually see. Home Assistant (HA) is the obvious choice: it speaks MQTT natively, runs locally (your data never leaves your home), and is free and open source.
This guide is different from most tutorials. Every step below was run on a real Windows 11 machine with WSL2 and Home Assistant Core 2025.1.4, against a live radar talking to an Apache Artemis broker. No “should work in theory” — it is verified.
60GHz Radar --MQTT--> Broker (Artemis / Mosquitto) --MQTT--> Home Assistant
Three actors:
If you have not set up the broker + radar MQTT side yet, do that first (see our MQTT architecture article and the product setup guide). This article starts from “I already have a working broker and my radar is publishing data.”
You need:
192.168.1.2:1883) with a username and password.The topics look like this (replace {DeviceID} with the number on the device back):
/Radar60FL/{DeviceID}/sys/property/post/Radar60FL/{DeviceID}/sys/property/setRadar60FL is the prefix for the 60GHz fall radar. Sleep = Radar60SP, presence = RadarHP, and so on.
HA is an open-source home automation hub. You run it on a box at home (Raspberry Pi, mini-PC, or even a Windows laptop via WSL2). It pulls data from hundreds of device types and shows everything in one dashboard. Because it is local-first, nothing is sent to the cloud.
Three ways to install it:
WSL2 (Windows Subsystem for Linux) lets you run a real Linux on Windows — and HA Core is happiest on Linux.
If WSL2 is not enabled yet, in an administrator PowerShell:
wsl --install
Reboot when prompted. Ubuntu will set itself up and ask you for a Linux username and password.
Then, inside the Ubuntu terminal:
sudo apt update && sudo apt upgrade -y
sudo apt install -y python3-venv python3-dev build-essential libssl-dev libffi-dev libjpeg-dev zlib1g-dev pkg-config
python3 -m venv ~/hassenv
source ~/hassenv/bin/activate
pip install --upgrade pip
pip install homeassistant
The last step downloads a lot of packages — give it a few minutes. When it finishes, start HA:
hass
First launch initializes the config and database and takes several minutes. You’ll know it is up when port 8123 responds. Open http://localhost:8123 in your Windows browser and create your admin account.
We tested on Ubuntu 24.04 with Python 3.12 and Home Assistant Core 2025.1.4. HA requires Python 3.12+, so use a current Ubuntu.
To keep HA running after you close the terminal, start it detached:
setsid nohup hass > ~/hass.log 2>&1 < /dev/null &
192.168.1.2 (your broker’s IP)1883You can confirm the link from the broker side: Artemis’ console will now show a new connection from Home Assistant.
Out of the box, HA does not know what fallStatus means. We declare sensors in configuration.yaml (in your HA config folder, ~/.homeassistant/configuration.yaml on Linux).
mqtt:
sensor:
- name: "Bathroom Fall Status"
unique_id: "radar60fl_fallstatus"
state_topic: "/Radar60FL/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.fallStatus is defined %}
{{ value_json.params.fallStatus }}
{% else %}
{{ this.state }}
{% endif %}
- name: "Bathroom Presence"
unique_id: "radar60fl_presence"
state_topic: "/Radar60FL/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.someoneExists is defined %}
{{ value_json.params.someoneExists }}
{% else %}
{{ this.state }}
{% endif %}
Replace {DeviceID} with the number printed on your device.
Why the if defined … else this.state pattern is mandatory here. The radar does not send every field in every message. Sometimes it publishes {"params":{"someoneExists":"1"}}, sometimes {"params":{"fallStatus":"1"}}, and often just a couple of fields. If you wrote {{ value_json.params.fallStatus }} directly, every message that lacks fallStatus would blank the sensor out. The template above keeps the last known value when the field is absent — this is the standard, stable way to handle sparse MQTT payloads.
After editing, reload without a full restart:
mqtt.reload service).Four ways, fastest first:
bathroom in the entity filter. You’ll see sensor.bathroom_fall_status and sensor.bathroom_presence with live values and last-updated time. Walk in front of the radar and watch presence flip./Radar60FL/{DeviceID}/# → Start Listening. You’ll see the raw JSON stream — great for discovering every field your model reports.sensor.bathroom_presence, and you get a “who-was-here” square-wave over the day — great for demos.setsid nohup hass … & command above instead. (We learned this the hard way.)aiodns … getaddrinfo() and libpcap is not available. Both are environment quirks (DNS resolver / DHCP discovery) and do not affect the web UI or MQTT. Ignore them.fall_status shows unknown at first — that is normal. fallStatus is only reported on a fall event, not continuously. Query it once with a get command: publish {"version":"1.0","method":"get","params":{"fallStatus":""}} to the /set topic, and it fills in with 0.setsid nohup hass … & command. For a permanent setup, HA OS or Docker (with restart policies) is the better long-term home.That is the whole chain, verified end to end: radar → broker → Home Assistant → dashboard, with real values flowing. From here you can build dashboards, alert on falls, or trigger other smart-home devices — all locally.
For the broker + radar MQTT setup and the full list of reportable fields per model, see our MQTT architecture article and the product setup guide on the docs site.
]]>If you bought our 60GHz fall detection radar and configured it for MQTT, the next step is to get that fall alarm and presence data into a dashboard — and, more importantly, into an alert you can actually rely on. Home Assistant (HA) is the obvious choice: it speaks MQTT natively, runs locally (your data never leaves your home), and is free and open source.
This is the radar we verified end to end. Every step below was run on a real Windows 11 machine with WSL2 and Home Assistant Core 2025.1.4, against a live fall radar talking to an Apache Artemis broker. The two sensors in this guide were confirmed returning real values (fall_status = 0, presence = 1). No “should work in theory” — it is proven.
60GHz Fall Radar --MQTT--> Broker (Artemis / Mosquitto) --MQTT--> Home Assistant
Three actors: the radar publishes JSON over MQTT, the broker is the middleman (the radar does not talk to HA directly), and HA subscribes and turns the JSON into entities. If you have not set up the broker + radar MQTT side yet, do that first (see our MQTT architecture article and the fall radar setup guide).
You need:
192.168.1.2:1883) with a username and password.The fall radar uses the prefix Radar60FL:
/Radar60FL/{DeviceID}/sys/property/post/Radar60FL/{DeviceID}/sys/property/setHA is an open-source home automation hub. You run it on a box at home (Raspberry Pi, mini-PC, or even a Windows laptop via WSL2). It pulls data from hundreds of device types and shows everything in one dashboard. Because it is local-first, nothing is sent to the cloud.
Three ways to install it:
WSL2 (Windows Subsystem for Linux) lets you run a real Linux on Windows — and HA Core is happiest on Linux.
If WSL2 is not enabled yet, in an administrator PowerShell:
wsl --install
Reboot when prompted. Ubuntu will set itself up and ask you for a Linux username and password.
Then, inside the Ubuntu terminal:
sudo apt update && sudo apt upgrade -y
sudo apt install -y python3-venv python3-dev build-essential libssl-dev libffi-dev libjpeg-dev zlib1g-dev pkg-config
python3 -m venv ~/hassenv
source ~/hassenv/bin/activate
pip install --upgrade pip
pip install homeassistant
The last step downloads a lot of packages — give it a few minutes. When it finishes, start HA:
hass
First launch initializes the config and database and takes several minutes. You’ll know it is up when port 8123 responds. Open http://localhost:8123 in your Windows browser and create your admin account.
We tested on Ubuntu 24.04 with Python 3.12 and Home Assistant Core 2025.1.4. HA requires Python 3.12+, so use a current Ubuntu.
To keep HA running after you close the terminal, start it detached:
setsid nohup hass > ~/hass.log 2>&1 < /dev/null &
192.168.1.2 (your broker’s IP)1883You can confirm the link from the broker side: Artemis’ console will now show a new connection from Home Assistant.
The fall radar reports fallStatus (0 = no fall, 1 = fall — the primary alarm), someoneExists (presence), sceneMode (1 living room, 2 bedroom, 3 bathroom), motionStatus, fallPosition, residentStatus, and more. We declare the ones we want as MQTT sensors in configuration.yaml (in your HA config folder, ~/.homeassistant/configuration.yaml on Linux).
mqtt:
sensor:
- name: "Bathroom Fall Status"
unique_id: "radar60fl_fallstatus"
state_topic: "/Radar60FL/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.fallStatus is defined %}
{{ value_json.params.fallStatus }}
{% else %}
{{ this.state }}
{% endif %}
- name: "Bathroom Presence"
unique_id: "radar60fl_presence"
state_topic: "/Radar60FL/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.someoneExists is defined %}
{{ value_json.params.someoneExists }}
{% else %}
{{ this.state }}
{% endif %}
- name: "Bathroom Scene Mode"
unique_id: "radar60fl_scene"
state_topic: "/Radar60FL/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.sceneMode is defined %}
{{ value_json.params.sceneMode }}
{% else %}
{{ this.state }}
{% endif %}
Replace {DeviceID} with the number printed on your device.
Why the if defined … else this.state pattern is mandatory here. The radar does not send every field in every message. Sometimes it publishes {"params":{"someoneExists":"1"}}, sometimes {"params":{"fallStatus":"1"}}, and often just a couple of fields. If you wrote {{ value_json.params.fallStatus }} directly, every message that lacks fallStatus would blank the sensor out. The template keeps the last known value when the field is absent — the standard, stable way to handle sparse MQTT payloads.
After editing, reload without a full restart:
mqtt.reload service).Four ways, fastest first:
bathroom in the entity filter. You’ll see the three sensors above with live values and last-updated time. Walk into the room and watch Presence flip./Radar60FL/{DeviceID}/# → Start Listening. Great for discovering every field your model reports.sensor.bathroom_presence, and you get an occupancy square-wave over the day — useful for showing when a room was used.setsid nohup hass … & command above instead. (We learned this the hard way.)aiodns … getaddrinfo() and libpcap is not available. Both are environment quirks (DNS resolver / DHCP discovery) and do not affect the web UI or MQTT. Ignore them.fall_status shows unknown at first — that is normal. fallStatus is only reported on a fall event, not continuously. Query it once with a get command — publish {"version":"1.0","method":"get","params":{"fallStatus":""}} to the /set topic — and it fills in with 0.setsid nohup hass … & command. For a permanent setup, HA OS or Docker (with restart policies) is the better long-term home.That is the chain we proved end to end — radar → broker → Home Assistant → dashboard — with real fall_status and presence values flowing. From here you can push a phone notification when fall_status goes to 1, or log daily room occupancy, all locally.
For the full list of reportable fall-radar fields and the install notes, see the fall radar guide and our MQTT architecture article.
]]>If you bought our 60GHz presence (human-occupancy) radar and configured it for MQTT, the next step is to get that occupancy, movement, and scene data into a dashboard you can act on. Home Assistant (HA) is the obvious choice: it speaks MQTT natively, runs locally (your data never leaves your home), and is free and open source.
This guide uses the same, verified method as our fall-radar HA walkthrough. Every step below was run on a real Windows 11 machine with WSL2 and Home Assistant Core 2025.1.4, against a live radar talking to an Apache Artemis broker. No “should work in theory” — it is the same MQTT integration we already proved end to end. The presence radar differs from the fall and sleep radars in one important way (its reports are split across two topics), and that difference is covered below.
60GHz Presence Radar --MQTT--> Broker (Artemis / Mosquitto) --MQTT--> Home Assistant
Three actors, same as the other radars: the radar publishes JSON over MQTT, the broker is the middleman, and HA subscribes and turns the JSON into entities. If you have not set up the broker + radar MQTT side yet, do that first (see our MQTT architecture article and the presence radar setup guide).
You need:
192.168.1.2:1883) with a username and password.The presence radar uses the prefix RadarHP. Unlike the fall/sleep radars, it does not use a single /sys/property/post topic. Instead it splits its output across two report topics:
/RadarHP/{DeviceID}/sys/active/post — fast-changing values (environ, movementSigns, keepAway)/RadarHP/{DeviceID}/sys/passive/post — configuration values (sceneMode, thresholdGear, forceIntoUnmannedGear)/sys/online/post for online/offline, and /sys/property/set for your commands)So each sensor must subscribe to the topic where its field is reported.
HA is an open-source home automation hub. You run it on a box at home (Raspberry Pi, mini-PC, or even a Windows laptop via WSL2). It pulls data from hundreds of device types and shows everything in one dashboard. Because it is local-first, nothing is sent to the cloud.
Three ways to install it:
WSL2 (Windows Subsystem for Linux) lets you run a real Linux on Windows — and HA Core is happiest on Linux.
If WSL2 is not enabled yet, in an administrator PowerShell:
wsl --install
Reboot when prompted. Ubuntu will set itself up and ask you for a Linux username and password.
Then, inside the Ubuntu terminal:
sudo apt update && sudo apt upgrade -y
sudo apt install -y python3-venv python3-dev build-essential libssl-dev libffi-dev libjpeg-dev zlib1g-dev pkg-config
python3 -m venv ~/hassenv
source ~/hassenv/bin/activate
pip install --upgrade pip
pip install homeassistant
The last step downloads a lot of packages — give it a few minutes. When it finishes, start HA:
hass
First launch initializes the config and database and takes several minutes. You’ll know it is up when port 8123 responds. Open http://localhost:8123 in your Windows browser and create your admin account.
We tested on Ubuntu 24.04 with Python 3.12 and Home Assistant Core 2025.1.4. HA requires Python 3.12+, so use a current Ubuntu.
To keep HA running after you close the terminal, start it detached:
setsid nohup hass > ~/hass.log 2>&1 < /dev/null &
192.168.1.2 (your broker’s IP)1883You can confirm the link from the broker side: Artemis’ console will now show a new connection from Home Assistant.
The presence radar reports occupancy as environ (0 unoccupied, 1 occupied still, 2 occupied moving), body movement as movementSigns (0–100), and the scene mode as sceneMode. Because the reports are split across two topics, point each sensor at the right one. We declare the sensors in configuration.yaml (in your HA config folder, ~/.homeassistant/configuration.yaml on Linux).
mqtt:
sensor:
- name: "Room Occupancy"
unique_id: "radarhp_occupancy"
state_topic: "/RadarHP/{DeviceID}/sys/active/post"
value_template: >
{% if value_json.params.environ is defined %}
{{ value_json.params.environ }}
{% else %}
{{ this.state }}
{% endif %}
- name: "Body Movement"
unique_id: "radarhp_movement"
state_topic: "/RadarHP/{DeviceID}/sys/active/post"
value_template: >
{% if value_json.params.movementSigns is defined %}
{{ value_json.params.movementSigns }}
{% else %}
{{ this.state }}
{% endif %}
- name: "Scene Mode"
unique_id: "radarhp_scene"
state_topic: "/RadarHP/{DeviceID}/sys/passive/post"
value_template: >
{% if value_json.params.sceneMode is defined %}
{{ value_json.params.sceneMode }}
{% else %}
{{ this.state }}
{% endif %}
Replace {DeviceID} with the number printed on your device.
Why the if defined … else this.state pattern is mandatory here. The presence radar does not send every field in every message — environ and movementSigns change often and arrive on /sys/active/post, while sceneMode changes rarely and arrives on /sys/passive/post. If you wrote {{ value_json.params.environ }} directly, every message on the other topic (or any message without that field) would blank the sensor. The template keeps the last known value when the field is absent — the standard, stable way to handle sparse MQTT payloads across multiple topics.
After editing, reload without a full restart:
mqtt.reload service).Four ways, fastest first:
room (or radarhp) in the entity filter. You’ll see the three sensors above with live values and last-updated time. Walk into the room and watch Room Occupancy flip from 0 to 1/2./RadarHP/{DeviceID}/# → Start Listening. Great for discovering every field your model reports across both topics.sensor.room_occupancy, and you get an occupancy square-wave over the day — perfect for showing when a room was used.setsid nohup hass … & command above instead. (We learned this the hard way.)aiodns … getaddrinfo() and libpcap is not available. Both are environment quirks (DNS resolver / DHCP discovery) and do not affect the web UI or MQTT. Ignore them.control command uses the opposite convention from the 60GHz fall/sleep radars: a value of 1 allows a report, 0 forbids it. This only matters if you send commands; for receiving data, just subscribe to the topics above.setsid nohup hass … & command. For a permanent setup, HA OS or Docker (with restart policies) is the better long-term home.That is the same verified chain — radar → broker → Home Assistant → dashboard — now feeding presence and occupancy. From here you can drive occupancy-based lighting or fan control, alert when a room is occupied for too long, or log daily usage, all locally.
For the full list of reportable presence fields and the install notes, see the presence radar guide and our MQTT architecture article.
]]>If you have ever watched the raw position readout from a 60 GHz mmWave radar — for example while building an elderly-monitoring or whole-home sensing system — you may have noticed something strange. The coordinates of a person seem to “drift.” Someone standing 10 cm from the edge of the bed may appear to be lying in it. Someone standing outside a window may be reported as inside. The system toggles between “in bed” and “got up” even when the person only shifted a little.
This article explains why that happens, where the jitter comes from, and how a well-designed radar deals with it. The short version: the “point” a radar outputs is not a fixed coordinate. It is a value that trembles every second. Understanding that is the first step to using radar correctly for care.
A mmWave radar does not see a person the way a camera does. It senses distance and motion with radio waves, and it samples continuously.
So the position you see is an averaged, time-aggregated statistic — not a single clean measurement.
Two kinds of noise make each frame’s distance value inconsistent.
Power and chip noise. Battery ripple and the chip’s own noise floor mean the per-frame distance is never exactly the same twice.
Taking the maximum. To stay robust against noise, many implementations pick the peak or maximum value inside a window. The side effect is that, instead of centering on the true distance, the reported value swings back and forth by a few centimeters around it. At a true distance of 2 m, you may see it wander by several centimeters.
A good analogy is a laser toy “shooting” at a person: tut-tut-tut, you keep aiming at the same spot, but the toy itself vibrates, so each dot lands a little differently. The reflections come back scattered, and the computed position spreads into a patch instead of a single point.
It is not only distance. The left–right angle (angle of arrival) and the elevation angle are also affected by phase mismatch between the transmit and receive antennas and by vibration.
Here is the catch: the farther the person is, the more a tiny angular error is magnified into a large lateral offset. That is why someone standing 10 cm from the bed edge can appear to drift into the bed when they are a bit farther away — the angular error, multiplied by distance, lands them “inside.”
The height dimension is relatively more stable, but it still suffers from transmit/receive inconsistency.
This is not cosmetic. Wrong coordinates directly break the features people buy radar for:
The key idea is simple: a single point is unreliable, so stop trusting a single point. Add more dimensions and let them constrain each other.
The result: a good radar does not make the point “more accurate” in isolation. It uses more dimensions to constrain the trembling point. What the radar finally outputs to the outside world is still, at its core, that trembling thing — but wrapped in enough context that the application sees a stable, sensible state.
If you build on top of a radar SDK:
Position drift is an inherent phenomenon of physics plus sampling — not a bug you can fully eliminate. The right response is not to chase a perfect point, but to understand it and design around it. Once you treat the radar’s output as a trembling estimate and fuse multiple dimensions, elderly monitoring and whole-home sensing become stable and trustworthy.
]]>If you bought our 60GHz sleep monitoring radar and configured it for MQTT, the next step is to get that data — breathing rate, heart rate, sleep stage, in-bed status — into a dashboard you can actually watch. Home Assistant (HA) is the obvious choice: it speaks MQTT natively, runs locally (your data never leaves your home), and is free and open source.
This guide uses the same, verified method as our fall-radar HA walkthrough. Every step below was run on a real Windows 11 machine with WSL2 and Home Assistant Core 2025.1.4, against a live radar talking to an Apache Artemis broker. No “should work in theory” — it is the same MQTT integration we already proved end to end.
60GHz Sleep Radar --MQTT--> Broker (Artemis / Mosquitto) --MQTT--> Home Assistant
Three actors, same as the fall radar: the radar publishes JSON over MQTT, the broker is the middleman, and HA subscribes and turns the JSON into entities. If you have not set up the broker + radar MQTT side yet, do that first (see our MQTT architecture article and the sleep radar setup guide).
You need:
192.168.1.2:1883) with a username and password.The sleep radar uses the prefix Radar60SP:
/Radar60SP/{DeviceID}/sys/property/post/Radar60SP/{DeviceID}/sys/property/setHA is an open-source home automation hub. You run it on a box at home (Raspberry Pi, mini-PC, or even a Windows laptop via WSL2). It pulls data from hundreds of device types and shows everything in one dashboard. Because it is local-first, nothing is sent to the cloud.
Three ways to install it:
WSL2 (Windows Subsystem for Linux) lets you run a real Linux on Windows — and HA Core is happiest on Linux.
If WSL2 is not enabled yet, in an administrator PowerShell:
wsl --install
Reboot when prompted. Ubuntu will set itself up and ask you for a Linux username and password.
Then, inside the Ubuntu terminal:
sudo apt update && sudo apt upgrade -y
sudo apt install -y python3-venv python3-dev build-essential libssl-dev libffi-dev libjpeg-dev zlib1g-dev pkg-config
python3 -m venv ~/hassenv
source ~/hassenv/bin/activate
pip install --upgrade pip
pip install homeassistant
The last step downloads a lot of packages — give it a few minutes. When it finishes, start HA:
hass
First launch initializes the config and database and takes several minutes. You’ll know it is up when port 8123 responds. Open http://localhost:8123 in your Windows browser and create your admin account.
We tested on Ubuntu 24.04 with Python 3.12 and Home Assistant Core 2025.1.4. HA requires Python 3.12+, so use a current Ubuntu.
To keep HA running after you close the terminal, start it detached:
setsid nohup hass > ~/hass.log 2>&1 < /dev/null &
192.168.1.2 (your broker’s IP)1883You can confirm the link from the broker side: Artemis’ console will now show a new connection from Home Assistant.
The sleep radar reports a rich set of fields: getIntoBed (in/out of bed), sleepStatus (stage), heartRateValue, breathValue, sleepScore, sleepComprehensiveStatus, and more. We declare the ones we want as MQTT sensors in configuration.yaml (in your HA config folder, ~/.homeassistant/configuration.yaml on Linux).
mqtt:
sensor:
- name: "Bed In-Bed Status"
unique_id: "radar60sp_inbed"
state_topic: "/Radar60SP/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.getIntoBed is defined %}
{{ value_json.params.getIntoBed }}
{% else %}
{{ this.state }}
{% endif %}
- name: "Bed Heart Rate"
unique_id: "radar60sp_hr"
state_topic: "/Radar60SP/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.heartRateValue is defined %}
{{ value_json.params.heartRateValue }}
{% else %}
{{ this.state }}
{% endif %}
- name: "Bed Breathing Rate"
unique_id: "radar60sp_br"
state_topic: "/Radar60SP/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.breathValue is defined %}
{{ value_json.params.breathValue }}
{% else %}
{{ this.state }}
{% endif %}
- name: "Bed Sleep Score"
unique_id: "radar60sp_score"
state_topic: "/Radar60SP/{DeviceID}/sys/property/post"
value_template: >
{% if value_json.params.sleepScore is defined %}
{{ value_json.params.sleepScore }}
{% else %}
{{ this.state }}
{% endif %}
Replace {DeviceID} with the number printed on your device.
Why the if defined … else this.state pattern is mandatory here. The sleep radar does not send every field in every message. Heart rate and breathing arrive every 3 s, the sleep stage every 10 minutes, the score only when the session ends. If you wrote {{ value_json.params.heartRateValue }} directly, every message without that field would blank the sensor. The template keeps the last known value when the field is absent — the standard, stable way to handle sparse MQTT payloads.
After editing, reload without a full restart:
mqtt.reload service).Four ways, fastest first:
bed in the entity filter. You’ll see the four sensors above with live values and last-updated time. Lie down and watch In-Bed Status flip./Radar60SP/{DeviceID}/# → Start Listening. Great for discovering every field your model reports.sensor.bed_heart_rate (and breathing), and you get an overnight curve — great for demos and for checking sleep quality.setsid nohup hass … & command above instead. (We learned this the hard way.)aiodns … getaddrinfo() and libpcap is not available. Both are environment quirks (DNS resolver / DHCP discovery) and do not affect the web UI or MQTT. Ignore them.sleep_score shows unknown at first — that is normal. The score is only published when a sleep session ends (and only for sessions of 4–12 hours). It fills in after the first complete night; query it once with a get if you want to seed it.setsid nohup hass … & command. For a permanent setup, HA OS or Docker (with restart policies) is the better long-term home.That is the same verified chain — radar → broker → Home Assistant → dashboard — now feeding sleep metrics. From here you can graph heart and breathing rate across the night, alert when the bed stays empty too long, or log the nightly sleep score, all locally.
For the full list of reportable sleep fields and the install notes, see the sleep radar guide and our MQTT architecture article.
]]>Sleep tracking has quietly become a baseline feature across modern wearables. But how do these devices actually know you’re asleep — and how accurate is that claim? This article walks through the three measurement principles behind consumer sleep sensing, how the major vendors implement them, the problems that still aren’t solved, and where mmWave radar offers a fundamentally different angle.
1. Accelerometer (motion). An accelerometer measures acceleration, which in practice means it senses changes in your motion. The amplitude and duration of movement within a given time tell the device whether you’re active or still. Long stretches without movement are interpreted as sleep.
2. Heart rate / optical sensing (PPG). Most wearables shine a light into your skin. As blood flows, it changes how much light is reflected back; each pulse of blood corresponds to one heartbeat. From the heart-rate stream the device can derive heart-rate variability (HRV) and, by watching how your heart rate speeds up and slows down, estimate your breathing amplitude.
3. Acoustic sensing. A microphone can pick up snoring, steady breathing, and wheezing. Listening to sound gives clues about breathing quality and potential interruptions.
Vendors weight these signals differently:
Everyone is converging toward fusion, and devices increasingly pair with phones. A same-brand watch knows when you’re actively using your phone, so it won’t mistake that for sleep.
Even with fusion, consumer sleep tracking hits walls:
mmWave radar’s principle is similar to the accelerometer approach — it detects motion amplitude and timing (you move, it knows) — but contactlessly, without anything on your body.
Sleep is mostly about breathing — sleep well and you breathe steadily and amply. Health is mostly about heart rate. Different tools emphasize different things, and each technology has distinct strengths that suit different users.
No consumer method matches PSG. mmWave radar is best understood as a contactless, continuous complement that emphasizes respiration and daily routine — a different instrument for a different need.
]]>When most people first hear about 60 GHz mmWave radar, they picture one thing: a small module mounted on a wall, telling a smart home system whether someone is in the room.
That is a real application, but it is a narrow one. The same sensing principle — transmit a frequency-modulated chirp, measure the round-trip time for range and the Doppler shift for velocity — is also used to measure the fuel level in a storage tank, hold a drone at a fixed altitude, time a car at an intersection, and map crop types from orbit.
The physics does not change between these applications. What changes is the frequency band, the antenna design, the beamwidth, and above all what the signal processing looks for in the returned signal.
This article walks through the main application families, and ends with an honest note about the one slice we build for.
Autonomous driving and driver assistance. Radar measures the range and relative velocity of vehicles, cyclists, and pedestrians directly, rather than inferring them from pixels. This is the main reason radar stays dependable in rain, fog, glare, and darkness — conditions where a camera’s input degrades sharply. A vision system and a radar are usually fused, because they fail in different conditions.
Traffic monitoring. Roadside radar measures the speed of passing vehicles and detects which lanes are occupied. Because it measures velocity through the Doppler shift rather than by comparing frames, it does not need to track an object across images to know how fast it is moving. The output feeds signal controllers and enforcement systems.
Parking. Per-space sensors detect whether a bay is occupied. Radar suits this because it can be mounted above or beside the space, is unaffected by lighting or weather, and does not require a clear line of sight in the way a camera does.
Large storage tanks — fuel, chemicals, water — are commonly measured with radar mounted at the top of the tank. The radar measures the distance to the liquid surface, and the level follows from the known tank geometry.
The reason radar is preferred here is that it is non-contact. Nothing touches the product, which matters when the contents are corrosive, hot, pressurised, or need to stay sealed. It is also unaffected by vapour, dust, temperature gradients, or the colour and transparency of the liquid. Precision at the millimetre level is achievable, and at the scale of a large tank, a millimetre of level error translates into a meaningful volume error, so that precision is worth paying for.
Human tissue and metal return measurably different signals. Their dielectric properties and reflectivity differ, so the phase of the reflected signal changes depending on what the wave bounced off. Phase-sensitive radar exploits this difference to detect concealed items.
This is worth calling out as a separate family because it is a fundamentally different signal-processing problem from presence detection. Presence detection asks “is there a target that moves.” Screening asks “what is this target made of.” Those need different features extracted from the same returned signal.
Drones. Radar is used for altitude hold, obstacle avoidance, and — in more capable systems — imaging radar that forms a coarse representation of the surrounding environment. The advantage over optical or ultrasonic sensing is operation in dust, fog, and darkness, plus direct velocity measurement.
E-bikes and motorcycles. Rear-facing radar provides approach and blind-spot warning for two-wheeled vehicles, where the rider cannot simply glance over a shoulder the way a car driver can.
Weather. Radar measures precipitation — including rain density — by analysing the returned energy from hydrometeors across a volume.
Agriculture. The reflection signature of a dense insect swarm differs from that of bare soil or an individual plant. Radar can estimate pest density, including locust swarms, from the characteristics of the return. It is a coarse estimate, not a species-level identification, but it covers areas that are impractical to survey by hand.
Orbital radar observes surface structure and can distinguish classes of vegetation by their reflection characteristics. This is remote sensing rather than proximity sensing, but it is the same principle: transmit, receive, and interpret what came back.
This one comes up regularly, so it is worth addressing directly. The question is usually some version of: can radar detect fish, or animals, underwater?
No. Underwater detection uses sonar, which is acoustic, not electromagnetic.
Sound propagates through water; radio energy does not travel far in it. Water absorbs electromagnetic waves very rapidly, and in practical terms a radar submerged in water propagates only a very short distance before the signal is gone. If the target is underwater, the sensor is a sound-based one, and the signal processing works on acoustic echoes and their characteristics.
This is not a limitation of any particular radar — it is the medium. The moment the target is below the water surface, radar is the wrong tool.
And then there is the slice we build for: rooms.
In an indoor setting the useful questions are narrow and specific:
These are answered with the same hardware used in the applications above, but tuned completely differently: short range, wide field of view, fine velocity resolution, and signal processing built around human-scale motion rather than vehicles or liquid surfaces.
Two properties make radar the right choice indoors. It works in complete darkness, because it generates its own illumination. And it produces no image at all — no lens, no video, nothing identifiable — which is why it is acceptable in bedrooms and bathrooms where a camera would not be.
Every application above is its own engineering discipline. Automotive radar has to survive vibration, temperature extremes, and functional-safety certification. Tank-level radar has to be certified for hazardous atmospheres. Screening radar is a materials-classification problem. Drone radar is constrained by size and power in a way that wall-mounted sensors are not.
Doing all of them well is not realistic. Doing one of them properly is. We build indoor sensing modules, and we refer the other enquiries elsewhere.
| Application | What the radar measures | Why radar fits |
|---|---|---|
| Automotive / ADAS | Range and relative velocity of road users | Works in rain, fog, darkness |
| Traffic enforcement | Vehicle speed, lane occupancy | Velocity comes from Doppler, not frame tracking |
| Parking | Bay occupancy | Lighting- and weather-independent |
| Tank level | Distance to liquid surface | Non-contact, millimetre precision |
| Security screening | Material differences via phase | Metal and tissue reflect differently |
| Drones | Altitude, obstacles | Operates in dust and darkness |
| Two-wheelers | Rear approach | Direct velocity measurement |
| Weather | Rain density | Volume measurement |
| Agriculture | Pest / swarm density | Covers large areas |
| Satellite | Surface and vegetation type | Works through cloud cover |
| Underwater | Not applicable | Use sonar; radio waves do not propagate in water |
| Indoor | Presence, count, posture, breathing | Darkness-capable, no camera, no image |
The technology is one. The applications are many, and they share almost nothing beyond the basic transmit-and-receive principle. Knowing which one you need — and which one you are buying — matters more than knowing the frequency.
]]>The first question we get asked about indoor sensing is almost always the same: why not just use a camera?
It is a fair question. A camera is cheaper, familiar, and produces output a human can look at and understand immediately. But a camera and a mmWave radar do not measure the same thing, and each is clearly better at a different job.
The short version: a camera tells you roughly what a person looks like and what posture they are in. A radar measures motion far too small for a camera to register at all. Understanding that distinction is what determines which one you need.
A camera records reflected visible light. From those pixels you get shape, colour, texture, and — with modern processing — a rough skeletal pose.
The strength of this is that the output is rich and directly interpretable. If you want to know whether a person is roughly standing, sitting, or lying down, a camera gives you that more clearly and more cheaply than a radar does. You can look at the frame and confirm it yourself, which makes cameras easy to install and easy to debug.
The weakness is that everything downstream depends on light and on a clear line of sight. A camera needs illumination, or infrared in the dark. It needs a lens that stays clean. It stops working behind steam, smoke, or a blanket. And it produces identifiable video, which is exactly why installing one in a bedroom or a bathroom is a non-starter for most people.
Radar transmits radio energy and listens for what comes back. From the returned signal it extracts three things:
The third one is the one that matters for indoor sensing, and it is the one a camera cannot do.
A 60 GHz radar resolves movement down to a fraction of a millimetre. That is not a marginal improvement over a camera — it is a different regime entirely.
Breathing moves the chest wall by an amount well within that resolution, and the heartbeat moves it by less — but still by enough to be measured. A person lying still under a blanket produces no visible change whatsoever in a video frame, while a radar pointed at the same person measures the chest movement continuously, through the blanket, in complete darkness.
This is the entire reason sleep monitoring — breathing rate, heart rate, sleep staging — is a radar application and not a camera application. It is not that radar is a better camera. It is that the quantity being measured is invisible to a camera.
It is worth being blunt about this, because the marketing in this category often is not.
Radar is not a camera replacement for seeing shape. The return from a human body is a sparse set of reflection points, not a picture. If your question is “roughly what posture is this person in,” or “what is in the room,” a camera answers it more directly and more reliably.
Radar does not identify who a person is. It does not read facial expressions. It does not tell you what object someone is holding. It cannot show you the room. If any of those are requirements, you need a camera, or both sensors together.
A realistic way to think about it: radar tells you that something is moving and how it is moving at a very fine resolution. A camera tells you what it is.
| Factor | mmWave radar | Camera |
|---|---|---|
| Complete darkness | Works — generates its own signal | Needs light or infrared |
| Privacy | No image, no lens, nothing identifiable | Produces identifiable video |
| Through blankets, steam, smoke | Sees through them | Blocked |
| Identifies a person | No | Yes |
| Rough posture | Inferred, coarser | Clearer and more direct |
| Breathing / heart rate | Measurable | Not measurable |
| Output | Abstract data (range, velocity, phase) | An image a human can read |
| Typical cost | Higher per unit | Lower per unit |
| Debugging | Harder — output is not visual | Easy — look at the frame |
The decision usually comes down to two questions.
First, is privacy or darkness a requirement? If the sensor goes in a bedroom, a bathroom, or anywhere a camera would not be acceptable, the choice is made for you. Radar produces no image, which is the whole argument.
Second, what is the smallest motion you need to detect? If the answer is breathing, heartbeat, or a person lying still, only radar can measure it. If the answer is “a person walked into the room” or “someone is sitting at the table,” a camera does that job more cheaply, and radar does it without the privacy problem.
For fall detection, sleep monitoring, and presence sensing in private spaces, radar is the practical answer. For “show me what is happening in the room,” it is not.
One more thing worth stating plainly: radar does not identify individuals and does not produce images. It measures motion, distance, and presence. A consumer radar that reports breathing rate or sleep stages is a wellness device — it is not a medical instrument, and it does not diagnose anything.
Pick based on what you are measuring, not on which sensor sounds more advanced.
]]>The most common reason a radar “does not work” is not a defect. It is that the buyer followed the wrong set of instructions.
Our products come in two fundamentally different architectures, and they do not share a protocol. One joins your Wi-Fi network and speaks MQTT. The other has no network at all and speaks binary frames over a serial cable. Both are radar. Almost nothing else about them is the same.
This article explains both, tells you how to recognise which one you have, and shows what you need in order to see the first message come out of it.
| You have | How to recognise it | Interface | Protocol |
|---|---|---|---|
| Finished radar | Enclosed housing, no exposed pin header, has Wi-Fi | 2.4 GHz Wi-Fi | MQTT (JSON over IP) |
| Radar module | Bare PCB with a pin header, no Wi-Fi, no network to configure | Wired UART | Binary frames |
The fastest test: if it has a row of pins and no Wi-Fi, it is a module. If it has a case and you configure Wi-Fi, it is the finished radar.
That distinction decides which documentation applies to you:
Do not mix the two. Reading the module instructions for a finished radar (or the reverse) is where most of the confusion starts.
This is the part people miss. The radar does not send data to your phone, your laptop, or an app. It publishes to a broker. Everything else — your dashboard, your own script, any client you open — connects to the same broker and reads from there.
radar ──Wi-Fi──▶ router ──▶ MQTT broker ◀── your MQTT client
(Mosquitto / (MQTT Explorer /
Artemis) mosquitto_sub /
MQTTX)
The radar talks only to the broker.
Your client talks only to the broker.
They never talk to each other directly.
So when the radar is online but you see no data, the first question is always the same:
Are the radar and my client pointed at the same broker?
In most cases they are not. The radar was configured with one address, and the client was opened with another — often a public test broker used during a first experiment.
Any broker that accepts plain MQTT over TCP works. The radar is configured with a tcp:// address, normally port 1883.
| Broker | Good for | Notes |
|---|---|---|
| Eclipse Mosquitto | Getting started, Raspberry Pi, home servers | A few megabytes, one command to install, the most widely documented broker in the IoT world. If you just want your first message to appear, start here. |
| Apache Artemis | Larger deployments, existing Java infrastructure | A full message broker that also speaks MQTT. This is what we run and what the radar has been verified against. |
| Managed cloud broker | Production without running your own server | Confirm it offers a plain TCP endpoint (port 1883), not only WebSocket |
broker.emqx.io |
First smoke test only | Public. Anyone can read your data. Never use it for a real installation. |
Our recommendation: if you already run a broker, use it. If you are starting from nothing, install Mosquitto — it is the shortest path from “radar on the desk” to “first message on screen”.
The radar asks for four values, entered once through its built-in web page:
| Field | Limit | Note |
|---|---|---|
| Server address | Up to 64 characters | tcp://host:1883 |
| ClientID | Up to 32 characters | Must be unique per radar |
| Username | Up to 32 characters | |
| Password | Up to 32 characters |
Two radars sharing one ClientID will keep disconnecting each other. Give every unit its own.
You do not need any particular client. Any MQTT client works, so pick whichever you can install most easily.
| Client | Why you might use it |
|---|---|
| MQTT Explorer | Shows the topic tree automatically, so you can see which topics exist without typing them. The friendliest first client. |
| mosquitto_sub | Ships with Mosquitto, so if you installed Mosquitto as your broker you already have it. No extra download. |
| MQTTX | A cross-platform GUI client. |
The full report topic is:
<prefix>/<DeviceID>/sys/property/post
The prefix depends on the model:
| Model | Topic prefix |
|---|---|
| 60 GHz sleep radar | /Radar60SP/ |
| 60 GHz fall radar | /Radar60FL/ |
| 24 GHz presence radar | /RadarHP/ |
| 24 GHz sleep radar | /RadarSP/ |
| 24 GHz fall radar | /RadarFL/ |
The DeviceID is the value shown on the radar’s own configuration page. A healthy radar publishes messages like:
{"version": "1.0", "method": "post", "params": {"someoneExists": "1"}}
The method field tells you what kind of message it is: post is a report from the radar, get queries a value, and set changes one. The radar answers queries on the report topic.
RadarConfig-xxxxxxxxxxxx hotspot, and open 192.168.0.1 to enter the broker address, ClientID, username, and password.BK_BLE5.apk, hold the button for about 5 seconds until the LED flashes, and send the radar your 2.4 GHz Wi-Fi credentials over Bluetooth.mosquitto_sub:
mosquitto_sub -h <your-broker> -t "/Radar60FL/#" -v
Or open MQTT Explorer and browse the topic tree.
If you can see that first message, the entire chain works. Everything after that — dashboards, automations, your own application — is built on top of a connection you have already proven. Full click-by-click steps are in the setup guide.
The module’s UART is 3.3 V TTL logic level.
Do not connect it directly to an RS-232 port, and do not feed it 5 V logic. Either can damage the module. If your adapter has a voltage jumper, set it to 3.3 V before wiring.
| Setting | Value |
|---|---|
| Baud rate | 115200 |
| Data bits | 8 |
| Stop bits | 1 |
| Parity | None |
| Flow control | None |
That is the entire configuration. Any terminal that can be set to 115200 / 8N1 will talk to the module. There is no app, no account, and no driver beyond the one your USB-TTL adapter already needs.
radar module USB-TTL adapter computer
VCC GND TX RX ──────▶ FTDI / CH340 ──USB──▶ any serial
/ CP2102 terminal
(3.3 V TTL, 115200 bps, 8N1)
Header Control Command Length Data Checksum Tail
0x53 0x59 1 Byte 1 Byte 2 Bytes n Bytes 1 Byte 0x54 0x43
Every frame starts with 53 59 and ends with 54 43. The checksum is the low 8 bits of the sum of the header, control byte, command byte, length bytes, and data.
You send a command frame, and the module answers with a report frame. The control and command bytes differ per product — the complete tables are in each product’s guide: sleep radar, presence radar, and fall radar.
The module has no Wi-Fi radio and no network stack. It cannot reach a broker because it has no way onto an IP network at all.
If you need MQTT, you have two options: use the finished radar, or put your own microcontroller between them — read the UART frames and publish them yourself. That is exactly what the finished product does internally.
| Question | Finished radar | Radar module |
|---|---|---|
| Joins Wi-Fi | Yes | No |
| Speaks MQTT | Yes | No |
| Exposes UART | No | Yes |
| Needs a broker | Yes | No |
| Needs a USB-TTL adapter | No | Yes |
| Configured with | Web page + Android app | Serial commands |
| Data format | JSON | Binary frames |
| Power | 5 V USB | 3.3 V (logic) |
| Typical use | Finished installation, dashboards, automations | Built into your own product |
| Symptom | Likely cause | What to check |
|---|---|---|
| Radar is online but the client shows nothing | Radar and client on different brokers | Compare the address in the radar’s web page with the one your client connects to |
| Two radars keep disconnecting each other | Same ClientID | Give every radar a unique ClientID |
| Wi-Fi setup always fails | 5 GHz network | Use 2.4 GHz only, or split the bands in your router |
| Provisioning times out | Took longer than 90 seconds | Hold the button again and retry |
192.168.0.1 will not open |
Phone not connected to the RadarConfig hotspot |
Reconnect to the hotspot. It has no internet access — that is normal |
| Serial terminal shows garbage | Wrong baud rate or framing | Set 115200, 8 data bits, 1 stop bit, no parity |
| Nothing at all from the module | TX/RX crossed, or wrong voltage | Swap TX and RX. Confirm 3.3 V TTL, not 5 V or RS-232 |
| Trying to set MQTT on a module | The module has no network | Use the finished radar for MQTT |
App cannot find Radar_BLE |
Module not in provisioning mode | Hold the button for 5 seconds until the LED flashes |
Two architectures, two protocols.
The finished radar joins your 2.4 GHz Wi-Fi and publishes JSON to an MQTT broker. You read it with any MQTT client, and it never talks to your devices directly — the broker is always in the middle. If you see no data, check first that both ends use the same broker.
The radar module has no network at all. It speaks binary frames over a 3.3 V TTL UART at 115200 bps, 8N1, readable with any serial terminal and a USB-TTL adapter.
Identify which one you have first. Everything else in the documentation follows from that.
]]>Fall detection is one of the most requested features in elderly care sensing, and one of the least straightforward to deliver. The name suggests a single clear event — a person falls, an alarm fires — but the sensing problem behind it has three distinct failure modes, and each one behaves differently in a real room.
This article describes those three modes: two kinds of false alarm and one kind of missed event. It also covers a problem that sits above all of them, which is that “a fall” is not a precisely defined acceptance criterion. Understanding these four things is the difference between a fall radar that works in a deployment and one that generates complaints.
For an elderly person with reduced mobility — unsteady gait, a cane, limited strength, or partial loss of independence — a fall is not a health metric. It is an event where somebody needs to know, quickly, so that the person can be helped up.
That is a different requirement from sleep monitoring or presence detection. Nobody is harmed by a sleep score that arrives late. A person lying on a bathroom floor for forty minutes is harmed by an alarm that did not fire, and by an alarm that fired three times the previous night for no reason.
So the sensing requirements are strict in both directions at once: the false alarm rate has to be low enough that the alarm is believed, and the missed-event rate has to be low enough that the alarm is trusted. Those two requirements pull against each other, and that tension is the source of everything below.
The first failure mode is an alarm raised in an empty room.
A bathroom is full of things that move without a person present. An open window lets a curtain or a towel move in the air flow. A leaking container drips. A toilet flushes. An extractor fan vibrates. Each of these produces a radar return, and a return from a low, stationary-looking target is exactly what a fall looks like.
The sequence is:
This is the failure mode that matters most at scale. A single false alarm is an inconvenience. A deployment of hundreds of units, each producing occasional empty-room alarms, produces a continuous stream of notifications that nobody acts on — and once occupants learn that the alarm is usually wrong, they stop responding to it, including when it is right.
Reducing this mode is mostly about the room, not the algorithm. Knowing whether a person is actually present — through entry and exit tracking, or through a corroborating signal — removes most of the candidates before the posture judgement runs. That is why a single-door bathroom is a much easier sensing problem than an open room, and why the scene matters as much as the sensor.
The second failure mode is an alarm raised while a person is present and doing something entirely normal.
Three examples, all of them ordinary activities:
| Activity | What the Radar Sees | What It Concludes |
|---|---|---|
| Squatting to wash clothes | Hand and arm movement at low height, head relatively still | A person struggling on the floor |
| Mopping the floor | A moving object at floor level, low and wide | A low, moving target |
| Sitting on the toilet, swinging a leg | Foot movement at low height, torso still | Movement near the floor without a head |
The common mechanism is a mismatch between what the radar weights and where the person’s mass actually is. A radar that over-weights low-level movement and under-weights the position of the torso will read a squatting person as a collapsed one, because the hands are moving and the head is not.
This mode is harder to remove than the first one, because the person really is there. Entry and exit tracking does not help — the person never left. What helps is judging posture from the whole target rather than from a single region: height, centroid, and the ratio of movement at different heights together, rather than any one of them alone.
The third failure mode is the one nobody wants to talk about, because it is the one that matters most.
A fall detector’s most reliable trigger is a rapid descent: a tall target collapses into a wide, low one within about a second. That transition is distinctive, and it is what most detection chains are built around.
Not every fall produces it.
A person sitting on a toilet who slowly slides sideways and comes to rest on the floor has not descended in the radar’s sense. Their height changed, but gradually, and without the rapid motion the detector is looking for. The same applies to a slow slump against a wall, or a controlled lowering after dizziness.
The result is a missed event in exactly the scenario where the person is least able to get up.
This is a genuine limitation of the approach, not a tuning problem. A detector that requires a rapid descent will miss slow descents. A detector that does not require one will report every sitting-down and lying-down motion as a fall. There is no setting that gives both.
Above the three failure modes sits a problem that is easier to state than to solve: nobody agrees on what counts as a fall.
Consider the questions a real deployment has to answer:
Every one of these is a real scenario, and every one is answered differently by different vendors, different products, and different care providers. The word “fall” in a specification covers all of them and none of them.
The practical consequence is that two products with the same quoted capability can behave completely differently on site, and a buyer cannot tell which from the specification. It also means that a requirement written as “detects falls” cannot be verified on delivery, because there is no shared definition of the thing being verified.
This is why scenario-based acceptance matters more in this category than in any other sensing category. “Detects a person lying flat on the floor within 10 seconds in a 2 m × 3 m bathroom with the door closed” is testable. “Fall detection” is not.
Five checks that separate a product with real deployment experience from one with a specification sheet.
The fifth point is the one that changes outcomes. It moves the conversation from what the product claims to what the product does in your room.
Three things in this category do not have clean answers, and it is worth being explicit about them.
None of these are solved by a better algorithm alone. They are solved by matching the detection logic to the room, by writing acceptance criteria that can actually be tested, and by being explicit about which cases a given product is and is not specified for.
Fall detection has three failure modes, and they are different problems with different causes. Empty-room alarms come from interference that resembles a low, stationary person. Misread postures come from weighting low-level movement over the position of the torso. Missed events come from requiring a rapid descent that a slow collapse does not produce.
Above all three sits the definition problem: “a fall” is not a precisely defined event, so a specification that says “detects falls” cannot be verified.
Evaluate a fall radar by asking for the empty-room test, the normal-activity test, and the slow-descent test, and by writing your acceptance criteria as scenarios rather than capabilities. The products that survive those four questions are the ones that have been deployed rather than only specified.
]]>