Alarmo: a browser-configured alarm panel for Home Assistant

Three pieces: component, panel and card

Alarmo is a Home Assistant custom integration for the `alarm_control_panel` domain, and it is built from three separate parts that are worth naming because they answer different needs. The Alarmo component is the backend that controls the state of the alarm panel entities. The Alarmo panel is a graphical configuration interface for sensors, delays and actions. The Alarmo card is a Lovelace card for arming and disarming.

GitHub reports Python as the language, an Apache-2.0 license, 2,301 stars, 163 forks and 27 open issues, with the last push on 2026-09-14. The repository is a conventional Home Assistant custom component layout: `custom_components/` at the root, `hacs.json` for HACS metadata, `tests/`, `pytest.ini`, a `uv.lock` alongside `pyproject.toml`, and a `DEVELOPMENT.md` for contributors.

The README positions the project against Home Assistant's own Manual Alarm integration, calling it comparable but noting the additional features that make it easier to use. The specific claim to test is the one about configuration: the panel allows complete management through the UI with no YAML required, and changes take effect without restarting Home Assistant.

Four arm modes with per-mode delays and perimeters

The feature list names four arm modes explicitly: `armed_away`, `armed_home`, `armed_night` and `armed_custom_bypass`. Each can have its own delays and its own security perimeter, which is the design decision that makes this more than a wrapper. A home mode that covers only interior sensors and an away mode that covers the whole envelope are the normal case, and being able to set the delay separately per mode is what a real alarm panel does.

Sensors come from entities you already have. The README states that existing Home Assistant entities can be configured as security sensors and will be watched automatically. The documentation structure in the README's table of contents shows the granularity involved: a sensor configuration section with sensor types, configuration options and sensor groups, plus a separate section on areas.

Areas are the other half. The README lists splitting a house security system into multiple areas that can be armed independently, and adds an Alarm Master concept with its own states and commands. That is the feature to look at first if you have a house with a detached garage or a home office you arm separately, because it is the part a single alarm entity cannot express.

Users, codes and permission levels

Alarmo supports multiple users with individual pincodes and permission levels. The documentation has a dedicated section for codes and users, and the service list covers five calls: arming, disarming, skipping a delay, and enabling or disabling a user. The service names follow the `alarmo.` prefix, so `alarmo.arm` and `alarmo.disarm` are the obvious two and the other three are named for what they do to the delay timer and to user accounts.

Skipping a delay is the service that tells you this is a real alarm panel rather than a boolean. It lets an automation or a notification action cut short a delay countdown, which is what you want when you are home and tripped the alarm by accident. The same mechanism is what a code-triggered entry delay would otherwise cost you.

The service list is also the best summary of the scripting surface. Everything else in the project is expressed as entities and events rather than additional service calls, so if you are writing automations you should work from the entity's states, attributes and commands, and from the event list.

The documented events are `alarmo_failed_to_arm`, `alarmo_command_success` and `alarmo_ready_to_arm_modes_updated`, and that last one has its own subsection on creating readiness indicator entities. That last event is the useful one for dashboards: it tells you which arm modes are currently possible given the state of your sensors, so a Lovelace dashboard can grey out the modes that would fail.

Installation through HACS and the two-version check

Installation has two paths and HACS is the one the README leads with. In the HACS panel you open integrations, search for Alarmo and install the repository, then restart Home Assistant and add the integration from the integrations page. The manual path is to download the latest release as a zip and extract it into the `custom_components` folder of your Home Assistant installation.

Updating is the same two paths, and the manual path expects you to overwrite the previous installation rather than merge into it. The verification step is the part that trips people up. The backend version appears as the firmware version in the device info for the Alarmo device, while the frontend version appears in the top right of the Alarmo configuration panel. If those two numbers disagree, the README says the cause is an outdated cached frontend, and the fix is a force refresh of the browser.

That two-part versioning is worth internalising before you file a bug, because a mismatched frontend is the most likely explanation for a setting you changed that appears not to have taken effect.

MQTT bridging and the documented third-party panels

The README documents an MQTT integration with a state topic, an event topic and a command topic, plus a subsection on multiple area usage. That combination is what makes Alarmo usable from a device that is not a browser: a physical alarm panel subscribes to the state topic, publishes commands to the command topic, and events flow out on the event topic.

A third-party platforms section names at least one concrete panel, the Android MQTT Alarm Panel, and lists Apple HomeKit and Google Home. The HomeKit and Google Home entries are worth reading closely before assuming they are full integrations, because Home Assistant's handling of `alarm_control_panel` entities through those platforms is constrained by what each platform supports, and a project README listing a platform does not guarantee parity of features.

The automation section adds push notifications with wildcards and actionable notifications, an actions subsection for switching a device and for advanced actions, and automatic arming. Actionable notifications are the feature that changes daily use: the notification itself becomes the keypad, so you can disarm from a phone lock screen.

Python and Home Assistant version requirements, and one oddity

The `pyproject.toml` in the repository root states `requires-python = "==3.13.2"`, which is an exact pin rather than a lower bound, and depends on `homeassistant~=2025.10.0`. That Home Assistant floor is worth comparing against the release notes, which tell a different story about the versions in use. Version 1.10.18 contains a fix for compatibility issues with toggle switches in Home Assistant 2026.5, and 1.10.17 contains updates to text fields for the same 2026.5 release. So the dependency floor in `pyproject.toml` points at the 2025.10 series while recent releases are explicitly fixing behaviour in 2026.5.

Both facts are in the repository. The practical reading is that the pinned lower bound is a floor, not a ceiling, and that the 2026.5 compatibility work is real rather than aspirational. Check what Home Assistant version you actually run before installing, and if you are on a 2026.5 install, read the 1.10.17 and 1.10.18 notes.

There is a second oddity in the same file: it declares `version = "1.10.12"` while the newest published release is v1.10.19, dated 2026-08-09. The project may well generate the version at build time, but taken at face value the file lags the tags by seven patch releases, so do not use it to determine what you have installed. Use the firmware version in the device info instead, which is what the README tells you to do.

Editorial conclusion

Alarmo fills a gap that Home Assistant's built-in Manual Alarm integration leaves open, and its two selling points are concrete: no YAML for the common cases, and no restart when you change the configuration. The surface is wide enough to cover real houses, with areas, an Alarm Master concept, MQTT bridging and documented third-party panels, but that width comes with a UI-centric design that automation authors should read the services and event list for before committing. Check the Python requirement first, since the project pins an exact interpreter version. Then install through HACS rather than by hand, because the updating instructions expect a clean overwrite of custom_components each time.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nielsfaber/alarmo on GitHub
4. README
5. Releases