Recipients and Scenario Classes¶

Info

See the Class Diagram for how these relate to each other.

`custom_components.supernotify.scenario.Scenario` ¶

METHOD	DESCRIPTION
`attributes`	Return scenario attributes
`contents`	Archive friendly view of scenario
`evaluate`	Evaluate scenario conditions
`trace`	Trace scenario condition execution
`validate`	Validate Home Assistant conditiion definition at initiation

ATTRIBUTE	DESCRIPTION
`is_manual`	A scenario with no conditions, which only applies when its manual state is on TYPE: `bool`

`is_manual` `property` ¶

A scenario with no conditions, which only applies when its manual state is on

`attributes(include_condition=True, include_trace=False)` ¶

Return scenario attributes

`contents(minimal=False, **_kwargs)` ¶

Archive friendly view of scenario

`evaluate(condition_variables)` ¶

Evaluate scenario conditions

`trace(condition_variables)` `async` ¶

Trace scenario condition execution

`validate(valid_action_group_names=None)` `async` ¶

Validate Home Assistant conditiion definition at initiation

`custom_components.supernotify.people.Recipient` ¶

Recipient to distinguish from the native HA Person.

The "future native entity use" this class was once staged for (BinarySensorDeviceClass, EntityCategory, etc.) has arrived as SupernotifyRecipientBinarySensor in binary_sensor.py - a wrapper Entity holding a reference to a Recipient, the same composition already used for RecipientNotifyEntity above, rather than this plain domain object inheriting from Entity.

METHOD	DESCRIPTION
`attributes`	For exposure as entity state
`check_mobile_actions`	Raise a repair for a configured, enabled mobile device with no notify action, and clear it once that's resolved
`disabling_delivery_names`	Explicitly overriding enabled state
`enabling_delivery_names`	Explicitly overriding enabled state
`resolve_mobile_devices`	The configured mobile devices plus those discovered now - again whenever one is re-paired or renamed

`attributes()` ¶

For exposure as entity state

`check_mobile_actions(hass_api)` ¶

Raise a repair for a configured, enabled mobile device with no notify action, and clear it once that's resolved

Only for the ones listed under mobile_devices - a discovered one has nothing for the user to repair

`disabling_delivery_names()` ¶

Explicitly overriding enabled state

`enabling_delivery_names()` ¶

Explicitly overriding enabled state

`resolve_mobile_devices(people_registry)` ¶

The configured mobile devices plus those discovered now - again whenever one is re-paired or renamed

`custom_components.supernotify.people.RecipientNotifyEntity` ¶

Bases: NotifyEntity


              flowchart TD
              custom_components.supernotify.people.RecipientNotifyEntity[RecipientNotifyEntity]

              

              click custom_components.supernotify.people.RecipientNotifyEntity href "" "custom_components.supernotify.people.RecipientNotifyEntity"

Expose a single recipient as its own notify.recipient_<name> entity.

Sent as an ordinary target on the main supernotify action, just like any other entity - Notification recognizes it as one of supernotify's own published recipient notify entities and resolves it to this recipient, still going through the full default-recipient delivery pipeline (occupancy, scenarios, personal delivery overrides, dedupe, snooze) rather than a literal, unscoped target override. Per HA's notify entity service schema, only message/title are ever passed in here - no data/target.

METHOD	DESCRIPTION
`__init__`	Initialize the recipient notify entity.
`async_send_message`	Send a message to this recipient.
`record_notification`	Record that this recipient was notified via supernotify.notify's main pipeline

ATTRIBUTE	DESCRIPTION
`extra_state_attributes`	Only populated on the pre-2026.3 fallback path - see record_notification(). TYPE: `dict[str, Any] \| None`

`extra_state_attributes` `property` ¶

Only populated on the pre-2026.3 fallback path - see record_notification().

`init(unique_id, recipient, engine)` ¶

Initialize the recipient notify entity.

`async_send_message(message, title=None)` `async` ¶

Send a message to this recipient.

`record_notification(context=None)` ¶

Record that this recipient was notified via supernotify.notify's main pipeline (any target - person_id, email, mobile device...), not just via a direct call to this notify.recipient_ entity. Called from Notification.record_result().

Delegates to NotifyEntity.async_record_notification() when available - the same HA-native method html5/mobile_app call on a direct notify.recipient service call - so state reflects the most recent delivery via either path. On HA versions before 2026.3 that method doesn't exist (see the docstring on self._last_notified in init), so this falls back to the pre-refactor design: a separate extra_state_attributes attribute, restored manually in async_added_to_hass() below. Either way, a message routed through supernotify.notify's main pipeline (the common case) never invokes this entity's own async_send_message() - see convert_notify_entities() in notification.py, which short-circuits that target straight to a person_id to avoid calling back into this same entity in a loop - so without this explicit call, delivery via that pipeline would never be reflected here at all.

context is the calling HA service context, if any, so the state change is attributed to the action call (or automation, or user) that caused it, in the logbook and history, just as it would be for a direct notify.recipient_ service call.

`custom_components.supernotify.model.RecipientType` ¶

Bases: StrEnum


              flowchart TD
              custom_components.supernotify.model.RecipientType[RecipientType]

              

              click custom_components.supernotify.model.RecipientType href "" "custom_components.supernotify.model.RecipientType"

`custom_components.supernotify.model.ConditionVariables` `dataclass` ¶

Variables presented to all condition evaluations

Attributes¶

applied_scenarios (list[str]): Scenarios that have been applied
required_scenarios (list[str]): Scenarios that must be applied
constrain_scenarios (list[str]): Only scenarios in this list, or in explicit apply_scenarios, can be applied
notification_priority (str): Priority of the notification
notification_message (str): Message of the notification
notification_title (str): Title of the notification
occupancy (list[str]): List of occupancy scenarios
notification_data (dict[str,Any]): Additional data passed on notify action call
camera (dict[str,Any]): Camera of the notification, its `entity_id` and anything configured for it in `cameras`
notification_actions (list[dict[str,Any]]): Actions passed on notify action call
notification_action_groups (list[str]): Action groups passed on notify action call

`custom_components.supernotify.hass_api.TrackedDeviceDetails` `dataclass` ¶

METHOD	DESCRIPTION
`__eq__`	Test support

`eq(other)` ¶

Test support

Recipients and Scenario Classes¶

custom_components.supernotify.scenario.Scenario ¶

is_manual property ¶

attributes(include_condition=True, include_trace=False) ¶

contents(minimal=False, **_kwargs) ¶

evaluate(condition_variables) ¶

trace(condition_variables) async ¶

validate(valid_action_group_names=None) async ¶

custom_components.supernotify.people.Recipient ¶

attributes() ¶

check_mobile_actions(hass_api) ¶

disabling_delivery_names() ¶

enabling_delivery_names() ¶

resolve_mobile_devices(people_registry) ¶

custom_components.supernotify.people.RecipientNotifyEntity ¶

extra_state_attributes property ¶

__init__(unique_id, recipient, engine) ¶

async_send_message(message, title=None) async ¶

record_notification(context=None) ¶

custom_components.supernotify.model.RecipientType ¶

custom_components.supernotify.model.ConditionVariables dataclass ¶