Smart Home

Home Assistant presence detection is flaky

Fix unreliable presence in Home Assistant by solving the right layer — home/away (device_tracker) vs room occupancy (mmWave) vs which-room (BLE) are different problems with different tools.

Problem summary

Most 'presence is unreliable' pain is solving the wrong layer. Home/away is device_tracker (phone GPS/router/BLE) and is where the 'vanishing person' flapping comes from. Room occupancy needs mmWave, because PIR misses a still person (lights off while you sit). Per-person room location is BLE trilateration (Bermuda via ESPHome proxies, or ESPresense). Pick the layer you actually need and de-flap with timeouts; don't expect one sensor to do all three.

Operator snapshotEvidence first

First proof

Name the layer you're actually trying to solve.

Screen to open

Developer Tools > States (device_tracker / binary_sensor) + History

Expected signal

You know whether it's home/away, room occupancy, or which-room.

Stop boundary

Using PIR for occupancy (misses still people) or expecting one sensor/device_tracker to deliver room-level 'who is where'.

Layer path

1Presence problems are usually a layer mismatch: home/away, room occupancy, and which-room are three different problems needing three different tools.

2Home/away is device_tracker (phone GPS, router, BLE) — and the source of the 'vanishing person' flapping when a phone's Wi-Fi sleeps or roams.

3Room occupancy needs mmWave: PIR only sees motion, so a still person reads as empty (lights off while you sit); mmWave detects a stationary present person.

4Per-person room location is BLE trilateration — Bermuda (a HACS custom integration) via ESPHome Bluetooth proxies, or ESPresense on dedicated ESP32 nodes.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Pick the layer

Check: Decide if you need home/away, room occupancy, or which-room.

Expected result: You know which tool class applies.

If not: Don't try to solve all three with one sensor.

Stabilize home/away

Check: Use a reliable device_tracker source, combine signals, add `for:`.

Expected result: Presence stops flapping to away when you're home.

If not: If you need room-level, that's a different layer.

Use mmWave for occupancy

Check: Drive room occupancy from mmWave, not PIR.

Expected result: Lights stay on while you're present but still.

If not: Tune placement to avoid fan/pet false triggers.

Add BLE for which-room

Check: Deploy ESPHome BT proxies + Bermuda (HACS) or ESPresense.

Expected result: You get per-person room location.

If not: Bermuda is custom/HACS — verify it stays maintained.

Combine and de-flap

Check: Layer the signals and add timeouts so brief gaps don't fire.

Expected result: Presence-driven automations behave reliably.

If not: Re-check after any sensor model/firmware change.

Decision tree

If: Marked away while actually home.

Then: Home/away (device_tracker) flapping.

Action: Use a reliable source, combine signals, add a `for:` timeout.

If: Lights cut off while sitting still.

Then: Using PIR for occupancy.

Action: Use mmWave for occupancy; PIR can stay for fast motion.

If: Can't tell which room someone is in.

Then: Missing the per-person room layer.

Action: Add Bermuda (HACS, via ESPHome BT proxies) or ESPresense.

If: mmWave triggers with nobody there.

Then: Placement/tuning (fan, vent, pet).

Action: Reposition and tune; combine with another signal to confirm.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Presence flaps to away at night.	device_tracker source; phone Wi-Fi/GPS behavior; any `for:` timeout.	Home/away (device_tracker)	Reliable source + combined signals + `for:` debounce.
Lights off while stationary.	Sensor type (PIR vs mmWave) on that trigger.	Occupancy sensor type	Use mmWave for stationary presence.
Need room-level 'who is where'.	Whether BLE trilateration (Bermuda/ESPresense) exists.	Per-person room layer	Deploy Bermuda via ESPHome BT proxies or ESPresense.
Occupancy false-positives.	mmWave aim and nearby fans/vents/pets.	mmWave placement/tuning	Reposition/tune; confirm with a second signal.

Reference

Commands and settings paths

Inspect the presence entity history

Developer Tools > States (device_tracker / binary_sensor) + History

Where: In the Home Assistant UI.

Expected: You can see the flapping pattern and which entity flips.

Failure means: Frequent away/home flips point at the device_tracker layer.

Safe next step: Add a `for:` timeout and a more reliable source.

Watch the mmWave occupancy sensor

Developer Tools > States (the mmWave occupancy entity)

Where: In the HA UI while you sit still in the room.

Expected: Occupancy stays 'on' while you're present but motionless.

Failure means: If it drops while you're still, it's PIR, not mmWave.

Safe next step: Move the occupancy trigger to an mmWave sensor.

Check BLE room data (if used)

Bermuda/ESPresense area entities + ESPHome Bluetooth proxy logs

Where: In HA and the ESPHome dashboard.

Expected: Per-person room/area updates as you move between proxies.

Failure means: No room data means BLE trilateration isn't set up.

Safe next step: Add ESPHome BT proxies + Bermuda (HACS) or ESPresense nodes.

Hardware boundary

Hardware and platform boundary

Change only when

Add an mmWave sensor for true room occupancy, and ESPHome Bluetooth proxies (reused as Bermuda receivers) for per-person room location — buy by the layer you need.

Evidence that matters

mmWave for stationary occupancy, ESPHome BT proxies for BLE room presence, and a reliable device_tracker source for home/away.

Evidence that does not matter

Headline sensor 'range' specs — placement, the right layer, and de-flapping timeouts matter more than raw range.

Avoid

Using PIR for occupancy (misses still people) or expecting one sensor/device_tracker to deliver room-level 'who is where'.

Related tool

Use the linked tool to turn this runbook into a guided check for your exact setup.

Device setup troubleshooter

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from 2026-06 research verified against Home Assistant community/docs (Bermuda BLE presence, automation troubleshooting); the operator differentiator is framing presence as three distinct layers (device_tracker vs mmWave vs BLE) and naming the 'vanishing person' anti-pattern. Bermuda is HACS/custom; sensor models drift — verify per device.

Sources/assumptions

Assumes Home Assistant with some mix of phone device_tracker, PIR/mmWave sensors, and optionally BLE room presence (Bermuda/ESPresense).
Bermuda is a HACS/custom integration (not core) and consumes BLE from ESPHome Bluetooth proxies; specific sensor models (FP2/FP300/LD2410) and their support drift — verify per device.
mmWave detects stationary presence (unlike PIR) but can false-trigger on fans/pets — placement and tuning matter; no fake per-model compatibility is claimed.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Home Assistant community: Bermuda BLE room presence integrationUsed for the room-level presence layer (BLE trilateration via ESPHome Bluetooth proxies) vs device_tracker home/away vs mmWave occupancy — and that Bermuda is a HACS/custom integration, not core.Home Assistant: Automation triggers & troubleshootingUsed for numeric_state firing on threshold crossing, state triggers without from/to over-firing on attribute changes, trigger-vs-condition, and using the trace timeline to debug.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Confirm the layer (radio, IP, app) before deep config.
4. Stop when the evidence says the risk moved.

FAQ

Why does Home Assistant say I'm away when I'm home?

That's the 'vanishing person' failure, and it's a home/away (device_tracker) problem — usually the phone's Wi-Fi sleeping, roaming between APs, or GPS jitter flipping you to away. Use the Companion app with a reliable source, add a `for:` timeout so a brief drop doesn't mark you away, and combine signals (router presence + GPS) rather than trusting one. This is separate from room-level occupancy.

Why do my lights turn off while I'm sitting still?

Because you're using motion (PIR), which only sees movement — sit still and it reports no motion. For occupancy you want an mmWave sensor, which detects a stationary present person. Use mmWave for 'is someone in this room', keep PIR for fast motion triggers if you like, and add a timeout so brief gaps don't cut the lights. mmWave can false-trigger on fans/pets, so place and tune it.

How do I know which room a person is in?

That's a third layer: per-person room location via BLE trilateration. Bermuda (a HACS custom integration) consumes BLE advertisements from ESPHome Bluetooth proxies you already have — no dedicated hardware — while ESPresense uses dedicated ESP32 nodes. Don't try to get room-level 'who' from a device_tracker or a single mmWave sensor; layer device_tracker (home/away) + mmWave (occupancy) + BLE (which room).