I have created a script that sends notification once a minute for 20 minutes until the receiving device confirms receipt of the notification.
If receipt is not confirmed within this timeframe, a persistent notification is issued with details (number of tries, etc.) of the delivery-attempt.
Most notifications are delivered, but sometimes delivery fails.
The receiving device is external and has local push enabled. Battery optimization is disabled for HA. It might be stationary for quite a while though. I suspect it is in doze-mode when delivery fails.
This is the definition of the notification group:
- platform: group
name: alert_heidi
services:
- service: mobile_app_heidiphone
data:
data:
group: hassio
channel: Alert
color: "red"
importance: high
sticky: true
persistent: true
alert_once: false
priority: high
ttl: 0
Is there any way, to make the delivery of notifications more reliable, for instance by switching to firebase or increase the number/time of retries to overcome the wakeup interval of doze-mode?
are you sure the format is correct there? is the notification actually persistent? are tehre any failures in HA core when sending the notification in HA core?
please keep in mind firebase will throttle you if you are found to be using ttl and priority too often. There is no saying what will trigger the throttle but at the frequency you mentioned that coudl do it.
With the term “persistent notification” in my initial post I meant the HA core internal notifications created with “persistent_notification.create”. It wouldn’t make any sense to inform about a communication-failure on the same communication-channel 
The format seems to be correct. I use this configuration and the underlying script for more then a year now.
I append the number of retries to the title of each notifications. Most notifications are delivered at the first try, some need more then one try, and very few fail completely (mostly those to my 80 year old mothers Pixel 6a, which is stationary in the evenings).
There are no errors in the HA Core logs. The trace shows a successful completion. I do get the final “persistent notification” informing me about the failure.
I re-red some community posts and the documentation on this subject before posting. I then added the priority-attribute. So this attribute was not present in the past.
To exclude this possible cause, I now removed the priority and ttl attributes from my configuration. By the way I could not find any documentation about the ttl attribute, what values it could have and what they mean (unit, etc.).
The documentation mentions, that notifications might not show/chime, if the device was stationary for some time. In my case they are not received at all, or at least, they do not create the event “mobile_app_notification_received”.
So the question remains: Does it make a difference to use “local push” vs. firebase?
I would assume, that android will wake up from doze once in a while to check if anything is going on. If I knew the this interval, I could make sure my retries would extend beyond this interval.
Given the frequency you mention once a minute for 20 minutes you could be hitting some limit with this frequency.
since you do not see an error in HA core then I will assume you have been rate limited
local push will keep sending a message until the device confirms the message, firebase messages are sent off to a firebase server and then delivered to the device. Local push will cause more battery drain. More on local push here:
as long as you granted the app access to run in the background, and assuming your device did not add any additional settings to change to allow full background access then you dont need to worry about doze unless you are sending a notification without ttl and priority set.
Thank you for your detailed answer!
So, if I understand you correctly, my attempt to ensure delivery through repetition was unnecessary.
I changed my script to send the notification only once and wait for confirmation for 5min. I readded priority and TTL:0 to the notification-group.
I read the documentation you linked several times before. The TTL parameter is not explained anywhere. It just mentions to use it with priority and set it to 0.
Does 0 mean it does not expire? Is it relevant if you don’t combine it with priority? Can it be greater then 0? If it can, what unit does it have (min, sec)?
The missing of the parameter priority might have been the reason for the unreliable delivery before.
As the doze mode is hard to simulate I just have to wait and see, if these changes solve the problem.
its a firebase setting that should really not be changed unless to 0 to speed up delivery
https://firebase.google.com/docs/cloud-messaging/concept-options#ttl
0 means deliver immediately or not at all, it is the absolute fastest option.
you want both if the goal is to break through doze and that is really the only reason why we change these values. Otherwise the default will deliver the notification next time the device is awake or online if it is within the default range
This is what I want, so this is how I will do it. However, does this
mean, if the device is offline at the time, the notification will not be delivered at all? If that is true, my previously mentioned retries would come into play again.
All this is about firebase, but how do I circumvent doze with local push, if that is even possible?
It sounds like I have to choose between either “circumvent doze” with firebase or “repeat until delivered” with local push.
you grant the app background access, and depending on manufacturer (like Samsung) may have more settings to change as well.
1 Like
So, was my assumption correct, that, if I choose to go with firebase, I would have to take care of the retries myself, as firebase will discard the notification if it cannot be delivered immediately?
only if you set ttl to 0 will it attempt to deliver immediately or not at all, default behavior will show the notification next time the screen comes on. But keep in mind you will get rate limited by the system and there is no way to tell when the limit happens and for how long you are limited.
I think you will need to play and tweak things until it fits your needs.
I will keep that in mind.
Thank you for your patience!