Pre-packaged notifications

[jeyrb]

Some ideas that have been brewing for a while, to make getting notifications about things so much simpler, and have something fancy (like live activities for dishwasher) easier than a very basic standard notification

https://supernotify.rhizomatics.org.uk/dev/developer/design/packages

[jeyrb]

@lollox80

[lollox80]

Sorry for the slow reply - I like this a lot, it's where the "zero YAML" direction pays off for non-technical users. Some thoughts on the open questions, HA-native first:

Detection - match on the entity registry rather than entity_ids: integration platform + entity translation_key (Home Connect exposes stable ones like program_progress, operation_state, remaining_program_time) and device_class for motion etc. Users rename entity_ids, but those stay stable across languages and renames.

UI - the closest existing HA concept seems to be config subentries ("Add …" under the integration, as MQTT and the AI integrations do): one subentry per package instance (per appliance/camera), with its own small flow. Unlike the earlier idea of mirroring YAML into subentries, there's no YAML side here, so no two sources of truth. For "ignore and don't ask again", HA's discovery/ignore model is the pattern users already know.

Code vs generated automations - I'd go for code: fixes ship with the integration instead of being frozen in a copied blueprint, and it's testable. The thing we'd lose is the automation trace, which is where the archive/delivery explanations (#175, and "Delivery Explanations" on the roadmap) could fill the gap: "package X fired because Y, deliveries A/B selected, C suppressed by scenario Z".

Frigate - one instance per camera, and GenAI as a separate package since it's a different topic and different tuning.

Name - what about "Recipes"? It's already Supernotify vocabulary (the recipes docs, including the dishwasher one), doesn't clash with anything in HA, and a package is really a recipe you can switch on.

Appliances beyond "connected" ones - one data point from my own install: most appliances here aren't "connected" in the Home Connect sense. Dishwasher and washing machine are on power-monitoring smart plugs, and the dryer is SmartThings but stops reporting when off, so today each one is ~1,200 lines of YAML (power threshold + delay_on/delay_off state machine, cycle counters, maintenance reminders) plus an FSM blueprint. I suspect that's the majority case, so I'd suggest the appliance package supports two detection sources from the start: native state where the integration has one (Home Connect operation_state, SmartThings *_machine_state), and a power sensor on the appliance's plug with threshold/delay options. Without remaining time, the live notification can show elapsed time via chronometer, and later estimate the end from the average of recent cycles.

Happy to take the appliance one end-to-end once the design settles - I can test it on real hardware (power-plug and SmartThings appliances).

[jeyrb]

thanks for that, merged it into the doc
Leaning towards having separate plugins for these, will need to test if HACS/HA will install supernotify automatically if someone asks for Frigate package plugin without already having it. People rightfully don't care about custom component name/brands and will focus on something that does specific thing for them

[jeyrb]

Some more changes now, and a set of what's needed in base package to support it at https://supernotify.rhizomatics.org.uk/dev/developer/rfcs/package_support/

New concept of source in there, which works round the gaps of context and trigger in Home Assistant, and some examples of how it could be used in scenarios.