rhizomatics/supernotify v2.8.0-beta2 on GitHub

Each loaded delivery and transport now has a switch, switch.supernotify_delivery_<name> or switch.supernotify_transport_<name>, named Delivery <name> Enabled and Transport <name> Enabled, on the SuperNotify device. Switching a transport off suppresses all of its deliveries, without changing their own switches
Delivery and transport binary_sensors behave the same way as the recipients since v2.7.0
Only mirror the new switches, so are deprecated and will be removed in a future version. They are read-only real entities on the SuperNotify device, only kept for an install that already has them, for a delivery or transport that is loaded. A repair is raised once if you have one enabled
Delivery switches and binary_sensors have a transport_enabled attribute, updated as the transport is switched on or off, since a delivery is only used while its transport is enabled too

Switching a scenario, recipient, delivery or transport on or off now survives a Home Assistant restart and a reload, for as long as its configured enabled value - its own, or for a delivery without one, its transport's - is unchanged. Changing that value in the config takes back control. An override belongs to its switch: while the switch entity is disabled in Home Assistant, its override is not applied, and it comes back when the switch is enabled again
New supernotify.reset_overrides action puts everything switched on or off back to its configured state, for every kind or only for one kind, optionally returning the names reset
New Reset overrides button, button.supernotify_reset_overrides, on the SuperNotify device - the same as calling supernotify.reset_overrides for every kind

Writing the state of a delivery or transport binary_sensor no longer enables or disables it, use its switch instead

The debug trace records which source switched each delivery on or off, as delivery_provenance - default, call, scenario:<name> or recipient:<name> under enabled_by / disabled_by - where delivery_selection only has the combined list for each stage, so a trace shows which scenario turned a channel off, not just that one did
A notification sent with debug: true is archived with its full diagnostic content, debug_trace included, whatever outcomes the archive diagnostics option selects. Before, the trace was only kept for the selected outcomes, ERROR by default, so a successful debug: true notification lost it
Debug recipe corrected - it is debug: true on the notification, not on the delivery, that records the trace

Email and phone numbers redacted where identified in Diagnostics bundle, and when debug logging recipients

What's Changed

feat: record which source switched each delivery on or off in the debug trace by @lollox80 in #208
feat: delivery and transport switches, persistent overrides, reset_overrides by @lollox80 in #207

Full Changelog: v2.7.0...v2.8.0-beta2