Alarm handler created as AI trial project

Share your Projects!
, ,
1

Inspired by another project about AI in HA, I decided to take a shot at it myself to create something I’ve been missing and had drafted in a previous post here. Mainly due to curiosity in how AI performs nowadays. Or rather to see how I perform with AI. Tool used is ChatGPT with Plus plan.

Below you can find how my ChatGPT session begun, defining my target, and what kind of specification was produced in couple of hours of directing ChatGPT to refine it’s first proposal. Next step would be to actually start developing.

In the meantime I’d like to ask the community of any ideas to append to the specification below. And your best guess, will this actually work once I get to the code part? Regarding this specification, I was quite pleased by the result. And one quick win of AI right away: without AI, I never would have taken the time to write any spec :grinning:.

Tag along, should you be interested. What will come out of this?

Me:

In industrial automation systems there is a alarm handler or a mechanism to create alarms. When programming, you can set an alarm limit to some process value and alarm class. The alarm handler then either logs the value, displays as info or as an alarm and sounds defined alerts. The alarm handler then handles acknowledgement of alarms and re-alerts, if the alarming value has not reached acceptable limits.

In Home assistant, then again, there is not such an alarm handler. Instead, all alarming needs to be coded into individual automations. Who to alarm, what alarm media and so on. No snooze functionality built in.

What I’d like to have is a way to, in an automation such as “Dishwasher monitoring” set an alarm like

ALARM, “Dishwasher finished”, [optional alarm message], [optional alarm method], [optional alarm class].

I would also have an alarm handler, table-like dashboard. Every time an ALARM is added to any automation, this dashboard would get a new row, where alarm properties could be set. The line would be something like

Alarm source; Alarm description; Alarm class; Phone Jack; Phone Jill; Flash home lights; Set alarm indicator lamp to on
Dishwasher monitoring; "Dishwasher finished; C; Yes; No; Yes; No

Would you be able to help create such an alarm handler? If yes, lets first create a definition and plan and only then go to code. I’m not a coder but have very basic programming skills specifically in industrial automation. Keep in mind, I’d like to share this to the community, so an end result should be something structured to share. Maybe as a blueprint or such, I have no clue how to make an integration.

ChatGPT:

This is a very solid and very “industrial” problem statement, and you’re absolutely right: Home Assistant lacks a first-class alarm/event handling layer comparable to PLC/SCADA alarm management. What you’re describing maps extremely well to ISA-18.2 / IEC-62682 style alarm handling, just applied to a smart home.

Yes — this is possible in Home Assistant without writing a custom integration, and in a way that can be shared with the community. The right mental model is:

Build a generic Alarm Handler subsystem on top of HA primitives
(helpers, scripts, events, dashboards, and blueprints)

Below is a definition + architecture plan, deliberately written in industrial-automation terms, before we touch any code…

This is what came up.

Home Assistant Alarm Handler

Specification v1.0 (Draft)

Created by vesar (Vesa Ruohomäki)
with the assistance of ChatGPT

==================================================

1. Purpose

This specification defines a class-based alarm handling subsystem for Home Assistant,
inspired by industrial alarm management practices.

The key goal is to separate alarm detection from alarm handling, enabling:

  • trivial alarm creation in automations
  • consistent, centralized alarm behavior
  • alarm acknowledgment and snoozing
  • safe commissioning of critical alarms
  • reusable, shareable alarm logic

2. Scope

This specification covers:

  • alarm raising from automations
  • alarm classes and default policies
  • alarm lifecycle and state handling
  • acknowledgment and snoozing
  • commissioning mode
  • alarm summary and configuration dashboards

Out of scope (v1.0):

  • custom Python integrations
  • advanced alarm analytics
  • dependency suppression / parent-child alarms

3. Definitions

Alarm:
A system-generated event representing a condition requiring awareness or action.

Alarm Source:
The logical origin of an alarm (automation, subsystem, or device grouping).

Alarm Class:
A policy selector defining default alarm behavior.

4. Alarm Data Model

Required fields:

  • class
  • description

Optional fields:

  • alarm_id
  • source
  • message
  • context_entity
  • context_value_at_raise
  • context_unit
  • methods

5. Alarm Classes and Default Policies (v1.0)

Supported classes: A, B, C, D, E, F, G

A — Critical / Safety

  • Notify all users
  • Flash lights
  • Indicator lamp
  • Optional siren / TTS
  • Re-alert until acknowledged
  • Snoozing typically disallowed

B — Urgent / Household Attention

  • Notify users present at home
  • Indicator lamp
  • Optional flashing
  • Periodic re-alert

C — Normal / Convenience

  • Brief flashing
  • Optional push
  • No re-alert by default

D — Log / Dashboard Only

  • Dashboard + logs only

E — Maintenance / Reminder

  • Notify maintainer group
  • Optional slow re-alert

F — Fault / Device Trouble

  • Notify maintainers/admins
  • Optional indicator lamp
  • Moderate re-alert

G — Debug / Trace

  • Dashboard + logs only

6. Policy Resolution Order

  1. Explicit methods at raise time
  2. Per-alarm configuration overrides
  3. Class default policy

7. Alarm Lifecycle

States:

  • INACTIVE
  • ACTIVE_UNACK
  • ACTIVE_ACK
  • SNOOZED
  • CLEARED

Transitions:

INACTIVE
 -> ACTIVE_UNACK
 -> ACTIVE_ACK
 -> CLEARED

ACTIVE_UNACK
 -> SNOOZED
 -> CLEARED

SNOOZED
 -> ACTIVE_UNACK
 -> CLEARED

8. Alarm Raising Interface

Minimal:

RAISE_ALARM(
  class,
  description
)

Example:

RAISE_ALARM(
  C,
  "Dishwasher finished"
)

Extended:

RAISE_ALARM(
  class,
  description,
  alarm_id?,
  source?,
  message?,
  context_entity?,
  methods?
)

9. Acknowledgment

Acknowledgment suppresses notifications but does not clear the alarm.
Acknowledgment is reversible and global.

Interfaces:

  • dashboard
  • button/service
  • push notification action

10. Snoozing

Snoozing is configurable per alarm.

When allowed:

  • suppresses notifications until timestamp
  • does not clear alarm
  • returns to ACTIVE_UNACK

When disallowed:

  • snooze controls hidden
  • snooze attempts rejected

11. Alarm Clearing

Clearing transitions alarm to CLEARED and resets ack/snooze.

12. Dashboards

Alarm Summary Dashboard:

  • Time
  • Source
  • Description
  • Class
  • Entity
  • State
  • Ack
  • Snooze

Alarm Configuration Dashboard:

  • enabled
  • class override
  • targets override
  • methods override
  • re-alert override
  • snooze allowed override

13. Global Commissioning Mode

Temporary system-wide mode for safe testing.

Requirements:

  • explicit duration
  • auto-revert
  • visible remaining time
  • manual early exit

Appendix A — Example Rows (Illustrative)

Alarm Summary:

Time  | Source | Description | Class | Entity | State | Ack | Snooze

Alarm Configuration:

Alarm ID | Class | Targets | Methods | Re-alert | Snooze | Enabled