So unfortunately that is actually quite difficult. There’s a couple reasons for this:
1 - There is no way to make a selector for a notification service. The only two options are to use a generic action selector or a generic text selector. Both work very poorly though.
With the action selector you’re literally just asking the user to fill in all the details. You can’t even be sure the action they’re giving you is going to send a notification, you don’t know what its going to do. And there’s no way for the blueprint author to make the messages or the actions or all the stuff this blueprint is doing. It would basically become a blueprint to “do a thing when an update is available” with you (the user) deciding what thing to do. Except without being able to use information like which thing has an update? What version is available? At what URL can I view info about this new version? Essentially all the stuff you’d want out of this blueprint.
And a text selector basically is no selector. You’d be asking users to copy and paste a string like notify.my_notification_service
and just kind of hoping they get it. You can use a regex to validate that it looks right but you can’t actually guarantee that the notification service exists because there’s no help for the user.
2 - When it comes to notification services there is exactly one field you can count on - message
. That’s it. Some notification services support title
, some don’t. Even fewer have options besides title
and message
. And I can’t just create a notification that works for the companion app and send it to any random notification service, it won’t work. To see what I mean, try making a notify group like this:
notify:
- name: Test group
platform: group
services:
- persistent_notification
- mobile_app_my_phone
And then call it with something simple like this:
title: Test
message: Test
data:
notification_icon: mdi:alert
What you’d probably expect is for the phone to receive a notification with that title, message and icon. And for a persistent notification to be created that has just the title and message (since persistent notifications don’t support icons). What actually happens is the call fails. The persistent notification service only supports title and message so it won’t accept data
and throws an exception. The call fails, an error is logged and no notification is sent anywhere.
For this reason accepting a notification group or any random notification service is impossible. Unless I want to remove everything from the notifications besides message
. That means no actions to install or skip, no url to the configuration panel, no action/link to open the changelog, not even a title. Everything besides the message has to go. That drops a ton of the value of this blueprint. I know I would personally never use it if I did that, I doubt many others would either.
3 - HTML5 notifications specifically are supportable but it’s a lot of work. These 3 problems come up:
- There’s no selector for HTML5 notifications. With the mobile app I can cheat by asking for a mobile app device knowing that the Send Notification device action exists. I have no option like that for HTML5 notifications. So I’m stuck with the two options above - Action selector or Text Selector.
- I need to add new inputs specifically for HTML5 notification services. And since I have no selectors for it that doesn’t seem appetizing.
- There was an effort to normalize the schema for notifications for Android and IOS notifications here. HTML5 notifications were left out of this. Their schema and featureset doesn’t match the other two at all so I would have to do a lot of resarch and add a lot of code to handle normalizing to that notification service. There would have to be a lot of demand for me to consider that.
I know that’s a long response and I’m sorry. The TL;DR is that it’s really far more work then it sounds. I would maybe be willing to handle HTML5 notifications if there was a lot of demand for it. Although really if there is a lot of demand for it those that use it should push up a feature request to get it better supported and caught up with notifications on the companion apps as it appears to have been left behind. And perhaps consider turning on analytics so the HA team knows it is more used, right now analytics says that its only used in 1.3% of installations. Compare that with the 99.3% of installations that use mobile_app.
It is not possible to do notification groups or any random notifier at this time for the reasons above.