If so those are called persistent notifications. You can add one by calling persistent_notification.create. Or notify.persistent_notification if you don’t care what the id of it is (generally you don’t unless you plan to use persistent_notification.dismiss to clear it via an automation).
I have no idea what notify.notify does. Or if it even does anything at all, might just be the stub service made my the base notification platform that all others inherit from. I never noticed it before lol
notify.notify isn’t actually anything. It’s just the base example for the notify engine which you need to use with one of the compatible notification services from this list.
The final config (for the automation action) would actually be something like notify.email or notify.mobile_app
Be aware that you might want to change the actual service to whatever service you are actually using since notify.notify is shorthand for the first notify service the system can find and might therefore not be working as intended.
The notify platform is a little different — and indeed a bit confusing. Most services will take a target which is an entity ID. In this case a device will expose a service to the notify platform. Command line calls and script calls (in one way) work like this too. So it would be notify.something as mentioned above.
My project will be notifying through the multitude of Alexa devices around my home, but I didn’t want my testing to disturb everyone else in the house. (Look at my timestamp- I usually don’t go to bed before 2AM).
Thanks again…
Also notify.alexa_media_stephen works, too…