RFC 0003a: Auto Notifier Packages¶

2026-10-07 · Jey Burrows · Status: In Progress

Appendix - Anticipated Changes¶

Changes anticipated in Supernotify before any production Auto Notifier is released, collected from the proposed packages: Frigate, appliance Live Activities (smart and power monitored), and motion sensors.

Packages are built as separate HACS components that work much better with Supernotify but have some basic functionality without. These can then be attractive to people with a specific requirement to integrate Frigate or want to their phone have a progress bar for the dishwasher.

Needs by Package¶

● needed, ○ useful

Fixes¶

1. Snooze enforcement¶

SUPERNOTIFY_SNOOZE_EVERYONE_CAMERA_* snoozes, from the button mobile push adds to every camera notification, were recorded but not applied, along with everyone-scoped delivery, transport, priority and mobile snoozes; a user-scoped snooze everything silenced everyone; targets containing underscores registered nothing; and the snooze button's typed minutes were ignored.

Fixed, with regression tests in test_snooze_enforcement.py. Camera snoozes currently compare with the notification's camera_entity_id; once there's a notification source, they could match its subject instead, so snoozing a Frigate camera also covers notifications about it that carry only a snapshot URL.

Notification Model¶

2. Notification source¶

Where a notification came from, so users can write scenarios for all Frigate events, all Frigate motion, or everything on the driveway without matching message text, and so cooldown, snoozing and lifecycle have something to key on.

A single path like frigate.driveway isn't enough: Frigate alone has separate review, motion, ANPR and GenAI flows, and a scenario may want to group by any of those, or by camera, or by place. So the source is a set of named parts, and a match can use any subset of them:

Because subject is a real entity, matching can also use its area, floor or label, so a driveway PIR, a gate sensor and the Frigate camera can all count as "driveway" without listing them - reusing the area, floor and label resolution added in v2.9.0.

Event detail is kept separate from the source, in an event block: object labels and sub-labels, zones, severity, plate, threat level, progress. These change per event, so scenarios test them in conditions rather than group by them.

How the source is set:

• Packages set it explicitly, and run with their own Home Assistant Context
• Automations and scripts get it derived automatically. Home Assistant fires automation_triggered and script_started with the context their run then uses, so Supernotify can keep a short-lived map from context to origin, and fill in origin, instance and, from the trigger, flow and subject for each supernotify.notify call. Existing automations then get source-aware scenarios, cooldown and snoozing without changes. This is best effort: calls from Developer Tools have no origin, and trigger descriptions are text
• An explicit source on supernotify.notify overrides any part, for example to group several automations under one name

Review, 2026-10-13: the parts need renaming to match Home Assistant before any of this is built. origin is really the platform, and should be the actual Home Assistant one, such as autoarm, automation or frigate; subject and instance are both an entity_id; and flow is a new word that sits too close to config flow. Finding the automation or script from the context of its state is also doubtful, being slow and fragile, and Home Assistant has no native way to get the original cause of a context. A component that passes its own context on the call, as Auto Arm does, may make much of an explicit source redundant.

As purpose-specific Home Assistant triggers reach more device types, such as appliances finishing, they fill in flow and subject for automation-derived sources more usefully, and let appliance packages use them instead of watching integration-specific states. They say when something happened; the lifecycle below still says how a notification relates to the ones before it.

Scenarios can match on source in two ways:

• Templates in any condition, using a notification_source condition variable, for example {{ notification_source.origin == 'frigate' and notification_source.flow == 'motion' }}
• A declarative sources matcher on the scenario - a list of part and value maps, any of which may match, with subject also accepting area_id, floor_id and label_id. Package config flows can offer this as dropdowns, since package users won't write templates

scenarios:
  quiet_frigate_motion:
    sources:
      - origin: frigate
        flow: motion
    delivery:
      .*:
        enabled: false
  driveway_loud:
    sources:
      - subject:
          area_id: driveway
    priority: high

flow values must be a documented list for each origin, not free text, or scenarios end up coupled to whatever each package happens to call its events.

4. Cooldown per source¶

Minimum time between new notifications from the same source, as the Frigate blueprint's cooldown, keyed on origin, flow and subject by default, so driveway motion doesn't hold back driveway ANPR. Updates and ends of a tag already sent aren't limited. A first step toward the Rate Limiting roadmap item.

5. Scenario priority¶

Let a scenario set the notification's priority, not just a delivery's data.priority, so a motion package can have "armed and night" raise to high and "occupied and not dangerous" drop to low. The priority then has to be settled before delivery selection, while scenario conditions can themselves use priority - so a scenario's priority applies after scenarios are chosen and doesn't re-trigger selection. Relates to Per-delivery Priority on the Roadmap.

Mobile Push¶

6. Media precedence¶

With both camera_entity_id and snapshot_url, the camera grab used to win. Frigate needs the snapshot URL for the image, with the camera entity used only for live view, grouping and snoozing.

Fixed: snap_notification_image in media_grab.py uses snapshot_url for the image when given, and only grabs from the camera without one, with regression tests in test_media_grab.py and test_transport_mobile_push.py.

7. iOS video attachment¶

clip_url already becomes video for both platforms (mobile_push.py), so iOS gets the clip without any attachment-specific work. Still missing: a content-type derived from the URL (application/vnd.apple.mpegurl for .m3u8), in case iOS needs that to treat a Frigate HLS stream as a stream rather than a plain file download.