I just wanted to say why I don’t use the HA notifications. I am happy with my Pushover integration. I have duplicated the notifies with different sounds, priorities and persons.
I do not use your blueprint. Not necessary to adjust your code (for me). BTW: I like your idea!
I am using an iPhone. No history in the companion app there.
i was playing aroung with this script, and almost everyting is working, except the send to multipe mobile phons.
To get this working i tried to solve this using a group made in the config.yaml:
When i test this by calling the servive from the developrs tools, its working fine, but when i tried to use this in the "Service to notify " like : notify.mobile_app_alle_mobieltjes it tells me that it failed to call the service unable to find service.
So what did i do wrong
Unfortunately, the script really isn’t intended for sending to more than one device as that would interrupt with the timeout functionality (which is a core feature).
However, if you still do want to proceed, you can refer to this post where Joseph has kindly shared his modifications based off an earlier version of the script.
I think that his modification is very elegant and would work well with the latest version of the script to send to multiple devices.
Hey thanks so much for creating this! I tried it out and it works great!
One issue I was facing is that an attachment seems to be added even when the “Attachment Type” is set to None, at least on iOS. This results in a failure message in the notification:
Hey @CurryBay, firstly, welcome to the community and thank you for reporting the issue!
I wasn’t able to reproduce the issue when Attachment Type: None.
When set to None, notifications do not include image thumbnails as expected on macOS and iOS.
Do try to set it to None again, save the script and do let me know how that goes for you.
I can however reproduce the Failed to load attachment issue, it has got to do with an Android vs iOS compatibility thing. Might have to add an option to attachment type for restricting options being sent to iOS devices…
Will look into different strategies to workaround this issue over the next few weeks.
I’ve come up with a solution that should not break anything and don’t require any additional input from your end. These are experimental right now so it’s understandable if you’d prefer to avoid it.
@samuelthng Thanks so much for putting this together. This is insanely useful for making my notifications easier to manage!
I might have missed it, but I’m looking for a way to pass variables/arguments from my automation into the script.
For example, I’d like to set up a single script for garage door notifications, with my message being something like '{{garage_door_name}} is now {{garage_door_state}}.', of which I can pass both of these in from the automation, so I don’t need to author multiple separate scripts for each state change.
Is this possible and am I just overlooking something that has already been documented? Thanks!
service: script.my_test_notifications
data:
field_title: >-
{{ state_attr("sun.sun", "friendly_name") }}
field_message: >-
{% if is_state("sun.sun", "above_horizon") -%}
The sun rose {{ relative_time(states.sun.sun.last_changed) }} ago.
{%- else -%}
The sun will rise at {{ as_timestamp(state_attr("sun.sun", "next_rising")) | timestamp_local }}.
{%- endif %}
Added: ⌛️ Enable Timeout Action(s) option and field.
Notes:
When enabling boolean fields with value of false, be sure to toggle them to true once, and then to false.
There seems to be a bug where the boolean value is not passed if it’s enabled and value is false without the toggle.
If you rely on 📲 Service to notify, do not upgrade, Version 1.6.1 will be the last version supporting that feature.
Cheers for the update! This is exactly what I was looking for!
Works like a charm.
The automation visual editor doesn’t support templates, so it’s not as “prettty”, but that’s no fault of yours.
For anyone else that comes in here and wants their message to be dynamic per automation trigger entity and state, here’s my snippet: {{trigger.to_state.attributes.friendly_name}} is now {{trigger.to_state.state}}.