I try to get some simple automations with notifications working on Android. I noticed, unfortunately, that handling of notifications seems to be rather unreliable using the companion app (PlayStore version): My use case are notifications concerning open doors or windows, which should, however, be discarded without user interaction on the mobile device es soon as this condition is no longer met.
The notifications will be displayed on the device in any case, but changing the content and especially clearing the notification (using the same tag) works only sometimes. Not never, but often enough to make the automations useless. I have that problem on four different devices (from LineageOS to Samsung stock ROM), so it’s probably not device specific. I also excluded the app from battery optimization, to no avail.
According to my HA instance, the automation runs correctly. And the companion app also receives the notifiction:
However, e.g. in this case the “clear_notification” command was not executed and the last notification text remains displayed. Often I can “fix” this by manually running the very same automation again, sometimes I have t re-run it several times.
Is it possible that the Android app does not handle the notifications in the order they are received and/or discards some notifications?! Without having a concrete proof, it also seemed that notification groups are even more unreliable than notifications to single devices. I found several posts here with the same problem, but they either seem to be solved or peter out without clear solution.
Thanks for the quick reaction.
That would mean that I have to change the notification channel priority to “high”, or do I have a wrong understanding? My notifications are supposed to be simple and non-priority. Is it possible to give the clear command a different priority?
Moreover, the problem is not the clear command not arriving fast enough, but not being processed at all. As seen in the screenshot, the clear command arrives - in this case even at the same time as the previous notifications with the same tag. It does not work, however.
This is meant purely to speed up the delivery of the notification to the device and does not impact the appearance or sound/vibration of the notification
you’ll need to look at hte logs to determine what is happening. System > Companion App > Show and share logs
...
09-06 15:55:36.256 13685 13685 D UrlRepository: localUrl is: false and usesInternalSsid is: false
09-06 15:55:36.256 13685 13685 D UrlRepository: Using external URL
09-06 15:55:36.271 13685 16560 D UrlRepository: localUrl is: false and usesInternalSsid is: false
09-06 15:55:36.272 13685 16560 D UrlRepository: Using external URL
09-06 15:55:36.285 13685 18432 D FCMService: From: xxx
09-06 15:55:36.307 13685 13685 D UrlRepository: localUrl is: false and usesInternalSsid is: false
09-06 15:55:36.309 13685 13685 D MessagingService: Creating notification with following data: {sticky=true, tag=skylights, group=Türen und Fenster, title=Dachfenster, channel=Infos, message=Eines oder mehrere Dachfenster sind manuell geöffnet, importance=low}
09-06 15:55:36.314 13685 13685 D MessagingService: Show notification with tag "skylights" and id "-990835074"
09-06 15:55:36.321 13685 13685 D MessagingService: Show group notification with tag "group_Türen und Fenster" and id "738886299"
...
09-06 15:57:05.699 13685 19394 D FCMService: From: xxx
09-06 15:57:05.702 13685 19394 D MessagingService: Clearing notification with tag: skylights
09-06 15:57:05.702 13685 19394 D NotifManagerCompat: Cancel notification with tag "skylights" and id "-990835074"
09-06 15:57:05.705 13685 13685 D UrlRepository: localUrl is: false and usesInternalSsid is: false
09-06 15:57:05.721 13685 19394 D NotifManagerCompat: Check if the notification is in a group...
09-06 15:57:05.721 13685 19394 D NotifManagerCompat: Notification is in a group (0|io.homeassistant.companion.android|g:group_Türen und Fenster). Get all notifications for this group...
09-06 15:57:05.721 13685 19394 D NotifManagerCompat: Notification is NOT the group summary.
09-06 15:57:05.721 13685 19394 D NotifManagerCompat: Notification is in a group, but the group has more/less than 2 notifications inside (4). Cancel notification
...
According to the logs, the notification should be cleared. But it isn’t. (In this case the message is part of a group which still had another notification with another tag open. The problem also happens without groups, too, however.)
I don’t know why the notifications gets a negative id??
09-06 15:57:05.721 13685 19394 D NotifManagerCompat: Notification is in a group, but the group has more/less than 2 notifications inside (4). Cancel notification
This is the last log line which indicates there are 4 notifications in the group when it attempts to cancel one of them.
It might be helpful to see an example of exactly what notifications are being sent. Have you also tried maybe adding a delay since they seem to be back to back?
thats just an android thing, nothing to worry about
That is strange, as at the moment of this notification there was only one other notification in this group (and there are only three possible at all). Maybe I will remove the groups?
The automation looks like this:
...
choose:
- conditions:
- condition: state
entity_id: binary_sensor.aperture_skylights_man
state: "on"
sequence:
- service: notify.mobile_app_handy
data:
title: Dachfenster
message: Eines oder mehrere Dachfenster sind manuell geöffnet
data:
tag: skylights
group: Türen und Fenster
channel: Infos
importance: low
persistent: false
sticky: true
- service: notify.kodi
data:
message: Dachfenster manuell geöffnet.
title: Dachfenster
default:
- service: notify.mobile_app_handy
data:
message: clear_notification
data:
tag: skylights
channel: Infos
#I have removed the priority and ttl-lines here, as that didn't help
I will try with delays, however thie problem occurs also when there are hours between.
Generally it looks to me as if the notifications arrive at the mobile app in the correct order, but somehow in the process of being displayed by Android they might get displayed in the wrong order. E.g. when the phone has received a notification and a consecutive clear_notification while being off all the time it might happen that the clear command is processed before the notification command. Is this possible?
My current workaround is:
Displaying notifications only after the relevant sensor has been turned on after some delay
Clearing notifications at once when the relevant sensor has been turned off again
Using priority: high and ttl: 0 options in all cases
This seems to make the notification system more reliable.
Are there any disadvantages of using the priority: and ttl: options? What exactly does ttl: do, this option is not really explained in the docs?
As you depend on the notifications showing up timely this is not a workaround but exactly what you should be doing. It’s even outlined in the docs that you need to do this if you experience delays. A lot of users add this to all notifications.
Google may rate limit you if they feel it’s abused, no real way to tell when that happens. I haven’t heard of it happening to any user either.
It stands for time to live meaning when the notification should be delivered. In order for a notification to show up immediately regardless of doze status it needs to be 0. The only time it will be an issue is if the device is offline because if the message cannot be delivered immediately, then it won’t be. You can use the notification received event to check if it was received. If you wish to learn more about TTL the firebase docs cover it extensively.
The priority setting is also a firebase setting and has a different meaning than what the companion app docs describe.
Thanks for the feedback. I guess I will also use this options for all notifications. Without them, at least on my phone notifications are only handled when unlocked, which makes them useless/misleading on lockscreen.
However: For me, ttl: 0 and priority: high seem to have the same result and I wonder why these different options are available and are to be used in conjunction.
Sorry I don’t follow and you sound like you are contradicting yourself. You say without these options the notifications are delayed but they also have the same result?
These are firebase options, you should only be concerned with needing to use them to speed up the delivery of the notifications as mentioned in the critical notification docs.
Everything works with both options enabled.
However I do not understand what priority: 0 and ttl: 0 achieve (the description looks as if they both do the same) and why they seem to be used in conjunction.
That’s out of pure curiosity, as long as it works it’s ok for me, but I just was interested why I have to select two options which seemingly have the same result.
Thanks for the links, that clarified the situation for me.
What I do not understand is the FCM design that “ttl: 0” messages are given highest priority AND at the same time will be discarded at once if the phone is not available. (To be sure, this is an Android question and has nothing to do with HA.)
But I had this situation today because of bad coverage. I will try without the ttl: 0 line…
if you keep running into issues like that then you might want to consider leveraging local push notifications, some users notice more drain than others who don’t notice any difference in daily drain.
you won’t need to mess with ttl and priority here as the app checks its connection to the server every 30 seconds and the server will confirm if a message is delivered otherwise it will keep it available to send.
