Trigger an HA automation on alarm activation

The integration’s event entity (one per panel) emits HA event-bus events for every typed SystemEvent the panel pushes. Filter on the event type to react to alarms specifically.

Recipe — notify on any alarm

configuration.yaml or as an automation

automation:
  - alias: "Notify on Omni alarm"
    trigger:
      - platform: state
        entity_id: event.omni_pro_ii_panel_events
        attributes:
          event_type: alarm_activated
    action:
      - service: notify.mobile_app_my_phone
        data:
          title: "ALARM"
          message: >
            Area {{ trigger.to_state.attributes.event_data.area_index }}
            type {{ trigger.to_state.attributes.event_data.alarm_type }}

The event entity’s state is the timestamp of the most recent event; its event_type and event_data attributes carry the typed payload. Trigger on a state change with attributes.event_type == alarm_activated.

React only to specific alarm types

alarm_type is an integer matching omni_pca.events.AlarmKind:

alarm_type	Meaning
1	Burglary
2	Fire
3	Auxiliary / Police
4	Duress
5	Tamper
6	Trouble
7	Freeze
8	Water

Add a condition to filter:

automation:
  - alias: "Smoke alarm only"
    trigger:
      - platform: state
        entity_id: event.omni_pro_ii_panel_events
        attributes:
          event_type: alarm_activated
    condition:
      - condition: template
        value_template: "{{ trigger.to_state.attributes.event_data.alarm_type == 2 }}"
    action:
      - service: light.turn_on
        target:
          entity_id: light.all_house_lights
        data:
          brightness: 255
      - service: notify.mobile_app_my_phone
        data:
          title: "FIRE ALARM"
          message: "Smoke detector tripped — area {{ trigger.to_state.attributes.event_data.area_index }}"

All event types you can filter on

Subset most automations want:

event_type	Fired when
alarm_activated	Any alarm starts
alarm_cleared	Alarm acknowledged / system disarmed
arming_changed	Area arm state changes (event_data.new_mode is the new SecurityMode)
zone_state_changed	Zone opens / closes / is bypassed
unit_state_changed	Light or output toggles
ac_lost / ac_restored	Mains power loss / restore
battery_low / battery_restored	Backup battery thresholds
phone_line_dead / phone_line_restored	DSL/POTS supervision

The full list (26 typed subclasses + unknown catch-all) is in the library API reference.

Test it without an alarm

Use the dev stack — the mock panel will let you push synthetic events through the same machinery:

# in a Python script against the mock
await panel.execute_security_command(area=1, mode=SecurityMode.AWAY, code=1234)

That triggers arming_changed. For real alarm activation against the mock, you’d need to extend MockPanel to push an AlarmActivated event on a synthesized zone trip — left as an exercise, but the pattern is identical to how ArmingChanged is pushed in _handle_execute_security_command.

Caveats

• The event entity is a single entity per panel, not one per alarm. You filter inside automations, not via separate entities.
• alarm_cleared doesn’t always fire — older firmware (pre-3.0) only emits the activation; you’ll need to listen for arming_changed → disarmed instead.
• The event_data dict is JSON-serialised, which means enum values appear as their integer values, not names. The AlarmKind table above maps them.