Simplifying transports and deliveries

[jeyrb]

The change (in v2.5.0 beta) to autoconfigure more transports is well motivated but adds complication onto existing complication, and the 1:M delivery:transport relationship which is very flexible but a barrier for newcomers or less technical, especially when there's no ConfigFlow for Delivery yet.

instead, the autoconfigure could be applied to the transport itself. transports that have no known verifiable configuration (auto_configure() is None) and no Delivery objects get disabled, ones that can be verified get the delivery defaults of the transport updated with the action etc.

Then users can simply give the name of the transport itself when building a notification, and if there's a transport matching the name and no delivery overriding it, the transport's delivery defaults used.
that doesn't quite solve the default delivery transports, unless that applies to all transports that aren't disabled and have selection == default.

People would start out with delivery mobile_push,email etc and if they need to tweak those they'd create a Delivery object also called email so automations don't have to change, or a Delivery however they like to name it.

For people with automations using 'DEFAULT_xxxx' style would need a dynamic migration that auto changes that to xxxx if the DEFAULT_ version is not present.

Most of the transports would be usable with zero YAML, albeit there might be some more repetitive data elements, like telegram/slack IDs that could be simplified into a Delivery object, though for some people repetition simpler than abstract concepts, YAML and Studio Code Server

[lollox80]

I like this direction - DEFAULT_xxx has always been the thing people trip over, and "reference the transport by name, get its defaults" is how most users already think about it.

Three things from the switch work I have queued behind #180 (issue #175 Part B, second half: real switch entities for deliveries and transports, RestoreEntity, repair for the id change) that I think fit this design and may be worth settling here before either of us writes more code:

"Disable transports lacking verifiable configuration" already has a home in that branch: Transport.config_enabled (from YAML or, with this proposal, from auto-configuration) versus the runtime enabled flag that the switch toggles. The stored override survives restarts only while the configured value is unchanged, so an auto-disabled transport that later gains configuration comes back on its own, and a user who turned one off on purpose keeps it off. For the "zero YAML" audience the switch would be the only control they have over a transport, so exposing why it is off as an attribute (e.g. auto_disabled_reason: no_verifiable_config) seems worth adding in the same pass.
Naming: with auto-configured deliveries taking the transport's bare name, a delivery and a transport sharing a name becomes the normal case. The switch branch already forces switch.supernotify_delivery_ / switch.supernotify_transport_ (rather than letting HA derive the object id), precisely so the two never collide - I mention it because it would be easy to lose that distinction if entity naming gets revisited alongside this change.
DEFAULT_xxxx migration: your dynamic rename is about the delivery name in the notification call, which is separate from entity ids - but the two meet on the old binary_sensor.supernotify_delivery_default_ entities. The deprecation shim in that branch resolves legacy ids through one registry-backed map (real rows plus slugified synthetic ids, with collision detection), so if DEFAULT_telegram becomes telegram the old entity id can be carried as an alias there for the same deprecation window, rather than each migration needing its own shim.

Happy to rebase the switch branch onto whatever shape this lands in - I'd rather adapt it to the new transport model than land it first and make you carry the migration. Is the plan to ship #190 in the 2.5.0 betas, and would you prefer the switches in the same release or the one after?

[jeyrb]

The binary sensor usage of DEFAULT_xx etc is possible but seems unlikely, and could put a note to rename rather than complicate the code for maybe nobody.
I'll go back to this tomorrow, started with adding more auto_configure, but realised wrong answer to problem, and also trying to apply a general principle of making the integration as useful as possible without any YAML, so even when some of the YAML gets migrated, there's less need to do UI config either

[lollox80]

Agreed on the entity ids - a rename note is enough, I'll drop the alias idea.

One small ask on §2 of your plan, before you write it: "only ever touches the runtime Transport.enabled flag" is exactly the case the switch branch can't tell apart from a user turning the transport off. Its restore keeps a user's override only while the configured value is unchanged, so an auto-disable that looks like a manual "off" would either be resurrected or would mask a real config change. If the auto-disable is expressed at the configured level (e.g. config_enabled = False, or a reason such as auto_disabled: no_verifiable_config next to the flag), both the switch and a future attribute on the entity get it for free, and a restart still re-attempts discovery exactly as you intend. Happy to make that adjustment myself in the switch rebase if you'd rather not carry it - just say which you prefer.

[jeyrb]

I've updated this now to a couple of docs, one more general, on the site

https://supernotify.rhizomatics.org.uk/dev/roadmap/principles/
https://supernotify.rhizomatics.org.uk/dev/roadmap/deliveries_and_transports/

[jeyrb]

Working version of this now at https://github.com/rhizomatics/supernotify/releases/tag/v2.5.0-beta1

[jeyrb]

2.5.0-beta5 now. Turns out more to clean up than I thought, the target selection had got quite complicated per transport, and now it's more straightforward.

Aside from the more toolbox-type generic and chime, everything maps to a target category, and for entities to both a specific domain and platform. This means for instance that Alexa Media Player transport will no longer try to send things to other media_player entities, like ChromeCast devices.

Also, the ability to add category as a prefix, means its easier now to more with the UI without trying to mess with data: sections, like discord_channel: 102929121 in the list along with email addresses and notify entities.