Notification Classes¶

Set media and action_groups from scenario if defined, first come first applied

ArchiveableObject implementation

ArchiveableObject implementation

Short circuit supernotify notify entities so they're handled directly so not going round in circles via calls to notify.send_message. A genuine other-integration notify entity is left alone for NotifyEntityTransport to handle normally.

Defined here rather than in models/Target since requires access to registries.

supernotify.notify's target: field also accepts the dict shape Home Assistant's own target selector produces, e.g. {"entity_id": ["person.jey", "notify.recipient_alice"]} - unlike this integration's other dict-shaped targets (recipient/delivery config), that entity_id list is Home Assistant's raw picker output, not pre-sorted by category: a person entity picked that way still needs to end up as a person_id, same as if it had been typed directly into notify.supernotify's flat target list, or it would otherwise be silently dropped by Target() (whose entity_id category explicitly excludes the person domain - see Target.is_entity_id/is_person_id in model.py).

Why a selected delivery won't be attempted at all, checked before any targets are worked out

A notification sent with debug: true asked for its trace, so it is archived with the full diagnostic content whatever the configured diagnostics outcomes

Async post-construction initialization

If no media defined, look for iOS / Android actions that have media defined

Example is the Frigate blueprint, which generates image, video etc in the data section, that can also be used for email attachments

Work out which deliveries would send, and to whom, without sending anything.

Makes the same checks as deliver(), except the dupe check, since the dupe checker remembers what it's asked about.

Debugging (and unit test) support for notifications that failed or were skipped

Specialized equality check for subset of attributes

Return a concise string representation of the Envelope.

The returned string includes the envelope's message, title, and delivery name in the form: Envelope(message={message},title={title},delivery={delivery_name}).

Primarily intended for debugging and logging; note that attribute values are inserted directly and may not be quoted or escaped.

Build the core set of service_data dict to pass to underlying notify service

Return data filtered by delivery data_keys_select option, pruning empty maps by default.

Grab an image from a camera, snapshot URL, MQTT Image etc

Alpha hash to reduce noise from messages with timestamps or incrementing counts

Update every involved recipient's notify.recipient_ entity (if it has one), so its state (or, on HA < 2026.3, its last_notified attribute - see RecipientNotifyEntity.record_notification()) reflects delivery regardless of which target form the caller used - a plain person_id, an email/phone/mobile override, notify.recipient_ itself, or anything else Recipient.initialize() folds into the same Target. Delivery target selection keeps person_ids, and generate_targets() narrows them to the recipients each envelope actually reaches (see _attach_person_ids()), so that's the one reliable link back from an arbitrary envelope to the Recipient objects it reached - see RecipientNotifyEntity.record_notification() for why this call is needed at all rather than leaving it to HA's own NotifyEntity state tracking.

recorded_person_ids are the recipients already recorded by the notification's other envelopes, which this adds to, so a recipient reached by several deliveries is only recorded once - each is a state write, and would otherwise show up in the logbook as several identical entries at the same moment.

Create a new target by adding another to this one

Compare two targets

How many targets, whether direct or indirect

Create a new target by removing another from this one, ignoring target_data

True for a real Person entity_id, or a Recipient's synthetic user.<name> id - used to identify a recipient with no Person record (see people.Recipient.entity_id). Both are person_id-category target values, resolved the same way downstream.

Replace area_id/floor_id/label_id targets with the entities they reference

Resolution goes through the same core helper as a Home Assistant entity action, so groups are expanded and an entity inherits the area of its device. An entity in more than one of them - the kitchen, the first floor and the voice label - is kept once, and data attached to a selector is inherited by each of its entities, the same way as for a group member. Transports therefore never see a selector, and only the exception of an action that genuinely knows about areas needs extra_data.

Returns this target untouched when there is no selector to resolve.

Narrow this target to what a delivery can use, leaving this one untouched

categories are the delivery's declared target categories, and own_names its own name and its transport's. A target category named after either is always destined for that delivery. The two serve different purposes and both stay available: - the TRANSPORT name (sms:value) reaches every delivery of that transport, so scenario/time/occupancy selection logic can still decide which one actually fires - the same as it would for a plain, auto-matched value - a specific DELIVERY name (shortcode_sms:value) pins the target to just that one delivery, for when two deliveries of the same transport must stay distinct (e.g. email vs html_email)

person_ids are always kept, whatever the delivery declares, since they aren't delivered to but are the link back to the recipients a delivery reaches (see Notification.generate_targets(), which narrows them to those actually in each envelope). They are kept out of the target_selector too, as it's for choosing between values a transport can address.

Check if two snoozes for the same thing

Return a string representation of the object.

Full-fidelity serialization for persistence (unlike export(), which is a display summary that loses the date part of timestamps).