Registry Classes¶
Info
See the Class Diagram for how these relate to each other.
custom_components.supernotify.people.PeopleRegistry ¶
| METHOD | DESCRIPTION |
|---|---|
async_refresh_entity | Re-publish one recipient's binary_sensor now |
mobile_devices_for_person | Auto detect mobile_app targets for a person. |
mobile_devices_for_user | Auto detect mobile_app targets for a HA user, with no Person entity required. |
occupancy_permits_delivery | Whether a delivery should be attempted at all under the given occupancy, as opposed |
people_named | The recipients called this, by alias or name, ignoring case and underscores - or failing |
person_id_for_name | The one recipient called this, by full name, alias or unique first name |
recipient_entities | Every registered recipient binary_sensor - used by supernotify.refresh_entities. |
register_entity | Called by SupernotifyRecipientBinarySensor.async_added_to_hass(). |
unregister_entity | Called by SupernotifyRecipientBinarySensor.async_will_remove_from_hass(). |
async_refresh_entity(name) ¶
Re-publish one recipient's binary_sensor now
mobile_devices_for_person(person_entity_id) ¶
Auto detect mobile_app targets for a person.
Targets not currently validated as async registration may not be complete at this stage
person_entity_id (str): _description_
list: mobile target actions for this person
mobile_devices_for_user(user_id) ¶
Auto detect mobile_app targets for a HA user, with no Person entity required.
occupancy_permits_delivery(delivery_occupancy, occupancy) ¶
Whether a delivery should be attempted at all under the given occupancy, as opposed to filter_recipients_by_occupancy() below, which narrows which recipients within an already-selected delivery get targeted. only_in/only_out collapse to any_in/ any_out here: they narrow which recipients to target, but don't change whether the delivery itself is relevant, which is all a gate can meaningfully decide.
people_named(name) ¶
The recipients called this, by alias or name, ignoring case and underscores - or failing that, those with it as their first name, so 'jey' finds 'Jey Burrows'
person_id_for_name(name) ¶
The one recipient called this, by full name, alias or unique first name
recipient_entities() ¶
Every registered recipient binary_sensor - used by supernotify.refresh_entities.
register_entity(name, entity) ¶
Called by SupernotifyRecipientBinarySensor.async_added_to_hass().
unregister_entity(name) ¶
Called by SupernotifyRecipientBinarySensor.async_will_remove_from_hass().
custom_components.supernotify.delivery.DeliveryRegistry ¶
| METHOD | DESCRIPTION |
|---|---|
apply_delivery_control | Give a transport's deliveries the Delivery Control defaults, where the transport's own |
async_refresh_entity | Re-publish one delivery or transport binary_sensor now, by its unique_id |
initialize_transport_deliveries | Validate and initialize deliveries at startup for this transport |
legacy_entities | Every registered delivery and transport binary_sensor - used by supernotify.refresh_entities. |
register_entity | Called by a delivery or transport binary_sensor's async_added_to_hass(). |
resolve_name | Backward compatibility for the original 'DEFAULT_x' auto-configured naming, |
unload_unused_transports | Drop any transport that ended up with no delivery at all - explicit or auto-generated. |
unregister_entity | Called by a delivery or transport binary_sensor's async_will_remove_from_hass(). |
| ATTRIBUTE | DESCRIPTION |
|---|---|
choosable_deliveries | Deliveries a notification can ask for - not ones only a scenario turns on, or only a fallback. TYPE: |
implicit_deliveries | Deliveries actually capable of implicit inclusion - for an auto-generated standard TYPE: |
choosable_deliveries property ¶
Deliveries a notification can ask for - not ones only a scenario turns on, or only a fallback. What the action editor's Delivery list and the LLM tools offer.
implicit_deliveries property ¶
Deliveries actually capable of implicit inclusion - for an auto-generated standard delivery, default inclusion alone isn't enough any more, its transport also has to declare a unique_target_categories or fallback_target_categories for Notification.select_deliveries() to ever actually match against; without one, a nominally default standard delivery (most transports that don't say otherwise) structurally can never be auto-selected, the same as an explicit-only one. A delivery whose own config explicitly declared inclusion: default (Delivery.explicit_ inclusion) is exempt from that check - that's already a deliberate, explicit choice, not something merely inherited from the transport's now-universal bare default (TransportConfig()'s own constructor, model.py - Transport.inclusion_mode used to override this down to explicit for most transports; now that it's gone, every transport that doesn't declare categories or set its own delivery_defaults.inclusion nominally inherits default too, without it being a deliberate choice by anyone), so it's trusted at face value exactly as before this mechanism existed (e.g. a fixed-action generic delivery with no target concept at all, meant to fire on every notification). A delivery that leaves inclusion: unset entirely still goes through the category check, even though it inherits the same nominal default value - inheriting isn't choosing. This is the single source of truth for "implicit-capable" - both the actual selection logic and this reporting property (the action editor's implied default list, enquire_implicit_deliveries, diagnostics) read it.
apply_delivery_control(transport, transport_config) ¶
Give a transport's deliveries the Delivery Control defaults, where the transport's own YAML delivery_defaults doesn't set them. A delivery's own YAML still wins over both.
async_refresh_entity(unique_id) ¶
Re-publish one delivery or transport binary_sensor now, by its unique_id
initialize_transport_deliveries(context, transport) async ¶
Validate and initialize deliveries at startup for this transport
legacy_entities() ¶
Every registered delivery and transport binary_sensor - used by supernotify.refresh_entities.
register_entity(unique_id, entity) ¶
Called by a delivery or transport binary_sensor's async_added_to_hass().
resolve_name(name) ¶
Backward compatibility for the original 'DEFAULT_x' auto-configured naming, long since replaced by plain transport names: a reference to the old 'DEFAULT_x' form resolves to the current 'x' delivery, if that's what actually exists now.
unload_unused_transports() ¶
Drop any transport that ended up with no delivery at all - explicit or auto-generated.
Deliberately deferred until both initialize_transport_deliveries() (explicit) and build_standard_deliveries() (implicit) have run, rather than decided per-transport up front: whether a transport is worth having can only be known once the full, resolved set of deliveries exists - for a transport like generic (bring-your-own-action, entirely delivery-driven), there's no transport-level state to check in advance at all.
unregister_entity(unique_id) ¶
Called by a delivery or transport binary_sensor's async_will_remove_from_hass().
custom_components.supernotify.scenario.ScenarioRegistry ¶
| METHOD | DESCRIPTION |
|---|---|
async_refresh_entity | Re-publish one scenario's binary_sensor now, whether or not periodic refresh is on, |
async_refresh_scenario_states | Ask each affected scenario's binary_sensor entity to re-read and re-publish its state. |
register_entity | Called by SupernotifyScenarioBinarySensor.async_added_to_hass(). |
scenario_has_state | Whether a scenario has any state to report - anything that hasn't opted out with |
scenario_is_on |
|
unregister_entity | Called by SupernotifyScenarioBinarySensor.async_will_remove_from_hass(). |
async_refresh_entity(name, context=None) ¶
Re-publish one scenario's binary_sensor now, whether or not periodic refresh is on, attributing any change of state to context if given
async_refresh_scenario_states(*args) ¶
Ask each affected scenario's binary_sensor entity to re-read and re-publish its state.
Triggered by the 1-minute timer (time/date scenarios and any dependency not captured by entity extraction) and by state changes of the scenarios' condition entities (immediate reactivity). The entity's own is_on property (via scenario_is_on() above) does the actual (pure, in-memory) evaluation on read; this only decides which entities need to refresh, and is a no-op for a scenario with no entity registered yet (e.g. before the binary_sensor platform has finished loading).
register_entity(name, entity) ¶
Called by SupernotifyScenarioBinarySensor.async_added_to_hass().
scenario_has_state(scenario) ¶
Whether a scenario has any state to report - anything that hasn't opted out with expose_state. That is the evaluated state of its conditions if it has any, otherwise a manual state that something outside Supernotify sets, see Scenario.manual_active.
scenario_is_on(scenario) ¶
is_on for SupernotifyScenarioBinarySensor - None maps to STATE_UNKNOWN.
unregister_entity(name) ¶
Called by SupernotifyScenarioBinarySensor.async_will_remove_from_hass().