Main

Why Your Smart Thermostat’s ‘Away’ Mode Fails When the House Has a Cat: A Motion Sensor Placement Study

November 1, 2026

If your away routine keeps collapsing while the house is empty, the cat is a reasonable first suspect and a poor final answer. A motion sensor reports motion. It does not report occupancy, and no mounting height turns it into an occupancy sensor. The cat matters because it shows you the category error: a single motion event is being treated as proof that a person is home.

This is a placement study in the sense that placement is worth doing — and a logic study in the sense that placement alone will not fix it. The reliable fix lives in the automation layer: group the sensors, count a burst of events once, require sustained motion before acting, and decide deliberately what happens when a sensor goes quiet.

Start with the symptom, not the cat

“Away mode fails” usually means one of three things, and they have different causes:

  • Away never arms. The routine waits for a clear-house condition that a sensor keeps interrupting.
  • Away arms, then flips back to home. A motion event fires during or after the away sequence and a condition or trigger reverses it.
  • Away arms and the thermostat ignores it. The climate side never received or never accepted the setpoint change.

Before touching placement, find out which one you have. Home Assistant automation traces show which trigger fired, which entity fired it, and which conditions passed or failed. If the automation didn’t run at all, there may be no trace — but some triggers record a “Did not trigger” entry, which is itself useful. The Motion detected trigger documentation points to traces as the first place to look when a trigger doesn’t react as expected.

Then open the sensor’s history. You want the timestamps of motion events correlated against the timestamps of thermostat mode changes. If the away routine flipped at 14:07 and the hallway sensor reported motion at 14:06, you have a candidate. If the sensor reported nothing and the mode still changed, the motion sensor is not your problem and you should stop reading placement advice.

Motion is not occupancy

The Motion detected trigger fires when one or more motion sensors start detecting motion. That is the whole contract. A cat crossing a room is motion. A curtain moving in front of a PIR element is motion. A person walking to the kitchen is motion. The sensor cannot tell you which, and it was never designed to.

This is why placement advice tends to disappoint. Moving a sensor out of a cat’s path reduces how often the sensor fires when nobody is home. It does not change what the sensor means. If your away logic treats “motion detected” as “someone is here,” every remaining false trigger still breaks it. Placement lowers the frequency of the problem; it does not change its class.

I haven’t seen a placement scheme that makes a PIR sensor cat-proof, and I’d be skeptical of one that claims to. Treat placement as mitigation and put the real work into the logic.

Placement: what it can and cannot do

Placement is still worth an afternoon. The goal is not to eliminate cat-triggered events but to reduce them and to make the remaining ones easier to reason about.

  • Keep sensors out of traffic paths. Doorways, hallways, and the route between the food bowl and the favorite chair are where a cat will cross most often. A sensor aimed across a hallway sees every crossing; one aimed along a wall sees fewer.
  • Get sensors off surfaces cats use. A sensor sitting on a shelf, a side table, or the top of a bookcase is a sensor a cat can walk past, jump onto, or knock. Fixed mounting at height, angled down, is more predictable than a loose unit.
  • Watch for heat sources and moving air. PIR elements respond to changes in infrared energy. Radiators, heating vents, and sunlit windows that shift through the day can produce events that look like motion in the log. This is a general property of passive infrared sensing, not a claim about any specific model.
  • Prefer more sensors with narrower views over one sensor with a wide view. The Home Assistant documentation recommends a single motion sensor for specific spots and a group of sensors for larger areas. A wide-angle sensor covering a whole floor will see more of everything, including the cat.

None of this is a cure. It is a reduction in noise, and it makes the next step — grouping and hold times — behave better because the events you are filtering are fewer and more meaningful.

The automation-layer fix

The core change is to stop letting one sensor event count as one occupancy decision. Home Assistant’s motion trigger gives you two levers for this, and both are documented on the Motion detected trigger page.

Lever one: behavior

When a trigger targets multiple motion sensors, the behavior option controls how they combine:

  • each (the default) fires every time any targeted sensor starts detecting motion.
  • first fires only on the first transition in the targeted group, then waits until none of the targeted entities is in that state before it fires again.
  • all fires only after every targeted sensor in the group is detecting motion.

For an away routine, each is the wrong default. A cat moving through three rooms can produce three separate trigger events, and each one is a chance for your logic to reverse course. first collapses a burst of individual events into one, and then stays quiet until the group clears. That is much closer to what you actually want: “something moved, once, and then things settled.”

all is the wrong tool here. Requiring every sensor in the house to detect motion at the same moment is a high bar that a person walking through one room will never meet.

Lever two: hold time

The for option — “For at least” in the UI — sets how long the sensor or sensors must remain detecting motion before the trigger fires. The default is zero, which fires immediately. A cat crossing a room produces a brief event; a person settling into a room produces a sustained one. A hold time of a few seconds to a minute filters the first without blocking the second, depending on your sensors’ re-trigger behavior.

Be aware that hold time is not free. It delays the trigger by design, so an away routine that relies on motion to confirm the house is empty will take that much longer to arm. Choose the hold time against your sensors’ actual reporting cadence, not against a number you read somewhere.

Put them together

A grouped motion target with behavior: first and a non-zero for is the shape of the fix. In YAML it looks roughly like this:

trigger:
  - trigger: motion.detected
    target:
      entity_id:
        - binary_sensor.hallway_motion
        - binary_sensor.living_room_motion
        - binary_sensor.kitchen_motion
    options:
      behavior: first
      for:
        minutes: 1

This fires once when the first sensor in the group detects motion, provided motion persists for a minute, and then does not fire again until the whole group has cleared. A cat crossing the hallway produces one brief event that never reaches the hold time. A person walking in and staying produces a sustained event that does.

Automation mode is part of the fix

Even with grouping and hold times, an away routine can be re-triggered while it is mid-sequence. What happens next depends on the automation’s mode, and the automation modes documentation is explicit about the differences:

  • Single (the default) does not start a new run while the automation is running, and logs a warning.
  • Restart stops the current run, including a running delay or wait, and starts a new run.
  • Queued starts the new run after previous runs finish.
  • Parallel starts a new, independent run alongside the existing one.

This matters because away routines often contain a delay — a grace period before the thermostat setpoint changes, or a wait to confirm the house is really empty. If a sensor re-triggers during that delay:

  • In Single mode, the new start is ignored and the original sequence continues. That is usually what you want for an away routine: a stray event does not abort the arming.
  • In Restart mode, the delay is cancelled and the sequence starts over. A cat that triggers the sensor every few minutes can keep the routine from ever completing.
  • In Queued mode, the new run waits, which can produce a pile-up of away sequences.
  • In Parallel mode, you get multiple concurrent away sequences, which is rarely what you want.

For most away routines, Single is the right choice, and the warning it logs is a feature: it tells you a re-trigger happened. If the warning is noisy because of a chatty sensor, that is a signal to fix the sensor or the grouping, not to switch modes.

Graceful degradation: when the sensor goes quiet

Away logic that depends on motion has a failure mode that has nothing to do with cats: the sensor stops reporting. A battery-powered motion sensor that has gone offline is not evidence that the house is empty. It is evidence that you don’t know.

How quickly you find out depends on the integration. Zigbee2MQTT’s availability feature is disabled by default, and when enabled it treats active and passive devices differently because passive devices cannot be pinged. Battery-powered devices must check in every 25 hours by default or they are marked offline, per the Zigbee2MQTT device availability documentation. ZHA has a comparable setting — “Consider battery-powered devices unavailable after” — which defaults to 6 hours, per the ZHA integration documentation.

Those defaults are conservative, and for good reason: a sleepy sensor that only reports when triggered can look offline if you set the timeout too short. But they also mean that a dead sensor can go unnoticed for most of a day. For an away routine, that is a long time to be making decisions on stale data.

The practical move is to make the away routine treat “sensor unavailable” as a distinct state from “no motion.” If the sensor is unavailable, the routine should either hold its last known state or fall back to a non-motion condition — a schedule, a door sensor, a manual confirmation — rather than silently assuming the house is empty. The exact fallback depends on what else you have; the point is that the fallback should be chosen, not inherited from a default.

If you are running ESPHome-based sensors, the binary sensor documentation describes a delayed_on_off filter that only sends an ON or OFF value if the sensor has stayed in the same state for at least the specified time period. That is a debounce at the device level, which is a useful complement to the hold time at the automation level — but it does not solve the offline problem, and it should not be confused with it.

A repeatable procedure

Run this in order. Each step produces something you can check before moving on.

  1. Reproduce the failure with a timestamp. Note when away mode flipped or failed to arm. This is your anchor for everything that follows.
  2. Open the automation trace. Identify which trigger fired, which entity fired it, and which conditions passed or failed. If the automation didn’t run, check for a “Did not trigger” trace entry.
  3. Pull the sensor history for the same window. Correlate motion events against the mode change. If no motion event lines up, the motion sensor is not the cause and you should look elsewhere — the climate entity, the network, or the automation’s conditions.
  4. Check the sensor’s availability state. An unavailable sensor is not a quiet sensor. Confirm the integration’s availability timeout and whether the sensor has been reporting on schedule.
  5. Regroup the motion sensors. Replace individual sensor triggers with a grouped target covering the areas that matter for the away decision. Leave out sensors in rooms the cat uses most if you can afford to.
  6. Set behavior to first and add a hold time. Choose the hold time against your sensors’ reporting cadence, not a round number.
  7. Set the automation mode deliberately. For most away routines, single is correct. Read the warning it logs as diagnostic information.
  8. Test by triggering the sensor while the house is empty. Confirm the away routine does not reverse. Then test with a sustained trigger to confirm it still responds when it should.

If you maintain a broader inventory of the small systems that run your week, this procedure fits naturally into a periodic audit rather than a one-time fix. The audit guide for small systems covers the wider maintenance rhythm; this article is the motion-and-away slice of it.

When a mechanical timer is the better answer

There is a version of this problem where the right move is to stop using motion for away mode at all. If your household schedule is regular, a schedule-based away routine — arm at a fixed time, disarm at a fixed time, with a manual override — is simpler, has no false triggers, and fails in ways you can predict. A motion-based away routine is worth the complexity when your schedule is irregular and you want the house to arm itself when it is actually empty. If it isn’t, a timer or a plain switch is the smarter choice, and no amount of sensor placement changes that.

What this does and does not fix

Grouping, first behavior, and a hold time reduce the number of false away-mode exits caused by brief motion events. They do not make a motion sensor into an occupancy sensor, and they do not guarantee that a cat will never trigger your away routine. A cat that sits in front of a sensor for longer than your hold time will still produce a sustained event. A sensor that goes offline will still need a fallback. The goal is a routine that degrades predictably — one that treats a single event as a single event, treats an unavailable sensor as unknown rather than empty, and logs enough for you to diagnose the next failure without starting from scratch.

FAQ

Will moving the sensor higher stop the cat from triggering it?

It can reduce how often the cat crosses the sensor’s field of view, but it does not change what the sensor reports. A PIR sensor responds to changes in infrared energy within its field of view; a cat that enters that field at any height is still motion. Treat mounting height as one variable among several, not as a fix.

Should I use all behavior instead of first?

No, for an away routine. all fires only after every targeted sensor is detecting motion, which a person walking through one room will never satisfy. first is the behavior that matches “something moved, once, and then settled.”

Why does my away routine log “Already running” warnings?

That is the Single mode warning described in the automation modes documentation. It means a new run was attempted while the previous one was still in progress. If it happens often, the cause is usually a chatty sensor or a missing hold time, not the mode itself.

How long should the hold time be?

Long enough to outlast a cat crossing a room, short enough that a person settling in still triggers the routine. That depends on your sensors’ reporting cadence and re-trigger behavior, which you can read from the sensor history. There is no universal number, and a value that works for one sensor model may be wrong for another.

What should the away routine do when the motion sensor is unavailable?

Treat it as unknown, not as empty. Hold the last known state or fall back to a non-motion condition — a schedule, a door sensor, a manual confirmation — rather than letting the routine assume the house is empty because the sensor stopped reporting. The right fallback depends on what else you have installed.