Magic Areas makes Home Assistant rooms know whether anyone is in them

The problem: presence detection scattered across a dozen automations

Magic Areas is a Home Assistant custom integration, and the README describes it in one line as making your smart home think for itself through rock-solid presence tracking, described as the foundation for a truly smart home.

The mechanism it centralises is ordinary Home Assistant knowledge: knowing whether a room is occupied, and reacting to it. Home Assistant already has Areas, which are groups of devices, and device trackers, which report presence. What it does not have out of the box is a per-area occupancy state that is stable enough to hang automations on. So people write them: a motion sensor turns the light on, a timer turns it off, another automation handles the fan, and the timer has no idea someone is still sitting on the sofa.

The README's framing is that instead of building dozens of manual automations, Magic Areas controls lights, climate and other devices so they do the right thing at the right time. Concretely, the feature list describes presence detected in each area from multiple sources, including motion sensors, media players, device trackers and BLE beacons, and the creation of smart groups for lights, fans, climate and media players that respond to the area's state.

The target user is therefore an existing Home Assistant installer with a house or flat full of areas and a set of automations that keep getting the presence question wrong. The project is MIT licensed and is published through the Home Assistant Community Store, HACS, which is the standard distribution channel for custom integrations.

The name is the giveaway about the ambition. Magic Areas is not a new concept in Home Assistant; it is a package of opinions about how areas should behave, and the opinions are numerous.

Presence timeouts and presence hold: the two settings that decide everything

Two features sit underneath every other behaviour, and understanding them prevents most of the disappointment people have with presence systems.

Smart presence timeouts are per area. Each area has a configurable timeout for clearing presence after the last motion, and if motion is detected again within the timeout, the timer resets. The README describes the result as no abrupt shutoffs, and that is the whole point: a single timeout in the configuration replaces the per-automation timers that cause the light to go out while you are still in the room.

Presence hold is the manual escape hatch. It creates a switch that overrides presence in an area. The README suggests it for when sensors are not fully reliable yet, and for guests. That is a well-judged feature, because presence detection is only ever as good as the sensors feeding it, and a system with no override forces you to disable the automation instead.

The two settings interact with the rest of the features. Secondary states such as dark, bright, sleep, extended and accented are all defined relative to the area's presence state, so a timeout that is too aggressive does not only turn a light off early, it also prevents the area from ever reaching the extended state that the light groups use to decide when a room has been occupied for a while.

If you configure one thing carefully when you start, make it the timeout. The documentation linked from the README, the concepts page on magicareas.io, is where the semantics are spelled out.

Secondary states: dark, sleep, extended, accented

Presence alone is a coarse signal. A room can be occupied in daylight, occupied at bedtime, or occupied for hours while a meeting runs, and each of those deserves different light and climate behaviour. Magic Areas expresses that with secondary states.

`dark` and `bright` are derived from light sensors or the sun. `sleep` is tracked by any entity, which is a broad definition and gives you a flag you can wire into a climate preset. `extended` applies when a room has been occupied beyond a set time, and `accented` tracks presence based on entertainment, that is, media players.

The value of these states is that they make intent expressible. A light that only turns on in the dark, or a heater that drops to `eco` when a room is empty and returns to `comfort` when someone is in sleep mode, are policies about the space rather than about a sensor. The README gives the climate example directly: map area states to climate device presets.

`extended` deserves a note because it interacts with the light groups. Smart light groups are created automatically and grouped by purpose, namely overhead, task, accent and sleep, and they can be set to trigger only in the dark or after extended occupancy. So a task light can stay off while someone is present but only briefly present, and an overhead light can wait for the dark state.

The trade-off is a combinatorial one. Every secondary state is another dimension that your automations can be conditioned on, and the number of valid combinations grows faster than the number of states. A home that behaves well with dark and extended configured can behave badly once sleep is also wired into the climate presets.

Meta-areas for floors, and inheritance of presence logic

A house is not a set of independent rooms. The interesting question is often about a level or a category rather than a single space, and Magic Areas handles that with meta-areas.

The README describes setting areas as interior or exterior, assigning them to floors, and having Magic Areas create meta-areas to track grouped presence, with the example of upstairs being occupied. Presence logic and secondary states are inherited and calculated automatically for these groupings.

The mechanism has a plausible design: an area joins a meta-area, the meta-area's occupancy is derived from its members, and the secondary states roll up the same way. That is what makes an upstairs-versus-downstairs automation possible without writing a template that enumerates rooms.

The fan groups feature follows the same aggregation logic for climate rather than presence. A `fan` group entity is created for each area and can be controlled using an aggregated value like temperature, humidity or CO₂, which the README suggests is good for exhaust fans, ceiling fans and air quality fans. Sensor aggregates do the same for `sensor` and `binary_sensor` entities, grouped by `device_class` and `unit_of_measurement`, and a separate health sensor feature auto-aggregates binary sensors for safety-related device classes: gas, smoke, moisture for leaks, problem and safety.

That health sensor aggregation is quietly the feature with the highest operational value and the lowest profile. It gives you a per-area leak, smoke and gas state without writing a template per device class per area, which is exactly the sort of duplication that makes Home Assistant installations rot.

Wasp in a Box: the door logic that stops premature shutoff

Wasp in a Box is the feature with a memorable name and a specific purpose: reliable presence sensing for rooms where doors matter. The README describes it as accounting for people entering and leaving rooms with doors, combining motion and door or garage sensors to prevent lights from turning off while you are still inside.

The problem it addresses is the classic one. A motion sensor in a hallway or a room with a door does not know whether the absence of motion means the room is empty or means the person is sitting still behind a closed door. Combine the motion reading with a door or garage sensor and the ambiguity mostly disappears: if the door is closed and motion stopped, the person is likely still in the room.

This is the kind of thing that is hard to express as a plain Home Assistant automation and easy to get wrong in a hand-written one, because the logic needs to combine a timeout with a door state and apply it to light groups, not just to one light. Doing it in the integration means the same rule applies to every area consistently.

The area-aware media player feature works the same way for a different device class. Media such as TTS alerts is played only in rooms that are currently occupied, and notifications are forwarded to the right areas rather than empty ones. On a multi-room house, that removes an entire category of annoyance, and it is another case where the integration is doing aggregation that a single automation would have to duplicate per room.

Installation through HACS, and what the repository actually contains

Installation is via HACS, the Home Assistant Community Store, and the README links the HACS repository badge for this integration. The project also hosts its documentation site at magicareas.io, with a Quick Start page carrying the installation instructions, and the README itself defers to it. There is no pip install and no configuration file to hand-edit in the documentation given here.

The repository layout shows the shape of a custom integration. The code lives in `custom_components/`, with `config/`, `tests/`, `scripts/` and `docs/` alongside it, plus `hacs.json` and `info.md` at the top level, which are the files HACS reads. The `requirements.txt` asks for `homeassistant>=2026.8.0` and `pip`.

That version floor is the one hard constraint to check before anything else, since a custom integration that calls newer core APIs will fail to load on an older install rather than degrade.

The rest of the repository is the toolchain of a maintained project: a `pyproject.toml` with Black, isort and Pylint configuration, a `tox.ini`, separate `requirements-test.txt` and `requirements-docs.txt`, a `.pre-commit-config.yaml`, a `.devcontainer.json` and a `.vscode/` directory. The Black target is py312, the isort profile is black with `homeassistant` and `tests` marked as first party and `custom_components.magic_areas` as the local folder, and Pylint runs with two jobs and a long list of disabled checks, with the reasons given in comments:

[tool.isort]
profile = "black"
known_first_party = ["homeassistant", "tests"]
known_local_folder = ["custom_components.magic_areas"]

The Pylint configuration is worth a glance if you plan to contribute, because the list of disabled checks is a map of the codebase's known rough edges: duplicate code is called unavoidable, too-many-arguments is not enforced for the sake of readability, and abstract-method is disabled because async introduced methods that are always missing.

Releases, translations and the cost of a community dependency

The release history is thin in a way that says something. The three listed versions are 4.4.2 on 2026-09-05, 4.4.1 on 2025-09-11 and 4.4.0 on 2025-08-30. The version numbers are well past 1.0, so the project has been in production use for a while, but the spacing between the two most recent releases is about a year, while the last push to the repository was on 2026-10-19. In other words, work continues on the branch without a new tagged release each time.

For a custom integration, that is normal. HACS installs from the repository rather than from a release artefact in most setups, so the running code tracks the branch, and the version number matters mostly for issue reports and for the dependency metadata Home Assistant reads.

Translations are handled through Hosted Weblate, and the README makes a point of it: the project has full translation support, meaning the entities themselves are translated, not just the interface, and the translations are listed for a long set of languages. Contributing a translation does not require pull requests or editing JSON files, which is the right way to run a translation project with more contributors than translators.

The cost side of a community dependency is the thing to plan for. A custom integration is not covered by the Home Assistant core team's compatibility guarantees, and when a core release changes an API, a custom integration is the thing that breaks first. The upstream here is a single maintainer, and the README describes the project as a passion project built with countless hours of development, testing, documentation and community support, with funding through Buy Me a Coffee. If your house depends on it, you are depending on that person, and you should know how you would replace the presence logic with plain automations if they stopped.

Editorial conclusion

Adopt Magic Areas if you already run Home Assistant and your automations are stuck in a loop of motion sensors turning lights off on people, because the presence timeouts, the Wasp in a Box door logic and the area-aware media routing are the parts that solve a problem no YAML rule handles well. Do not adopt it if you have a handful of rooms and simple automations, since the configuration surface is large enough to cost you an afternoon, and do not expect it to work on an old core, because the requirements ask for homeassistant 2026.8.0 or newer. Before you rely on it, read the concepts page on magicareas.io, set a generous presence timeout on the first area you configure, and confirm that your presence sensors are the kind it can read, including BLE trackers if you use ESPresense, Bermuda or Room Assistant.

Frequently asked questions

Official sources

1. jseidl/magic-areas on GitHub
2. License: MIT
3. Project website
4. README
5. Releases