Alarmo

Alarm logic runs inside Home Assistant

Alarmo is a custom integration running on my Home Assistant host. It maintains an alarm control panel entity and provides its own configuration panel for sensors, modes, users and actions. It is not a separate radio controller: Home Assistant must first receive the underlying sensor states through the integrations that own them.

Sensor integration → Home Assistant state → Alarmo rules → alarm state → configured responses

My Alarmo configuration includes inputs classified as door and motion sensors. Those inputs come from more than one integration. Their classifications describe how Alarmo interprets them; they do not turn every source into the same kind of physical sensor or give every source the same availability.

Alarmo's optional MQTT interface is disabled in my configuration. The keypad and response paths described here use Home Assistant entities, events and actions directly. My wider build uses MQTT elsewhere, but this alarm workflow does not need an extra MQTT translation between the keypad automation and Alarmo.

The connections behind the alarm workflow

Scroll the table horizontally to compare all four columns.

A physical keypad with a separate feedback path

My CentraLite keypad is joined to ZHA. An automation listens for its events and calls Alarmo's arming or disarming actions. That translation is the connection between the physical control and the software alarm. Joining a keypad to Zigbee alone would not define that behavior.

The return path is separate. Another automation watches Alarmo and sends the corresponding state to the keypad's alarm panel entity. This lets a change made elsewhere in Home Assistant feed back to the physical control instead of assuming the last button press still represents the current alarm state.

The keypad handler has a specific role

This keypad uses a local ZHA quirk in my build. Its interaction indications, estimated battery reporting and timed tamper indication have limitations documented in the ZHA keypad section. Those indications should not be mistaken for independent confirmation that Alarmo accepted a command.

For that confirmation, I check the resulting Alarmo state. An incoming event, an accepted alarm action and a successful feedback update are three different observations. This distinction matters when the keypad appears responsive but the requested mode does not take effect.

Using the alarm state beyond the alarm panel

Notifications and coordinated responses

My configuration includes Alarmo notification actions and Home Assistant routines that react to its state. A shared response script combines lighting changes with media and notification actions. It also contains temporary lighting snapshots and restoration steps.

That script coordinates separate systems. Hue lighting goes through the Hue bridge, other lights keep their own integration paths, and Alexa Media Player provides a cloud-dependent announcement output. A successful lighting action does not establish that a spoken notification was heard.

The Hue guide explains the difference between a bridge scene and a Home Assistant snapshot. A snapshot in a response script records selected states; it is not a guarantee that cleanup completes after an interruption.

Alarm context in ordinary routines

Other lighting routines check the alarm state as a condition. This lets Home Assistant decide whether a routine should proceed in its current context. Reading the state does not arm the alarm, and using a sensor in an unrelated lighting routine does not automatically enroll it in Alarmo.

Local alarm logic, mixed dependencies

Alarmo's logic runs locally, but the workflow inherits the dependencies of its inputs and outputs, so I don't describe the whole chain as offline-capable. This article describes how the parts connect. It is not guidance on building a certified or monitored alarm system.

Modes, entry and exit delays, sensor eligibility and code requirements belong to Alarmo's configuration. The upstream project documents those controls. My public article explains the architecture without publishing the household's sensor placement, codes, timing or security rules.

Check the request, state and response separately

When something disagrees, I start with the stage that should have produced the next observation. For a sensor issue, that means checking its Home Assistant state before changing Alarmo. For a keypad issue, it means checking the received ZHA event and automation trace before treating the keypad display as the alarm's source of truth.

Next I inspect Alarmo's result: whether the requested transition was accepted, whether a sensor blocks arming, and whether the configured delay or mode explains the current state. Only then do I follow the feedback automation and response actions.

A notification failure belongs to its output path, while a rejected arming request belongs earlier in the chain. Keeping those checks separate makes troubleshooting more precise and avoids changing working sensor rules to compensate for a delivery problem.

The Alarmo documentation is the reference for its modes, sensor settings and action behavior. The Alexa Media Player guide covers the announcement side of my build.