Now that notifications from the android mobile app support actions, ttl, priority, tags and all the things I relied on heavily with HTML5 notifications I’ve begun to do some testing to move over. First thing I wanted to see is if mobile app notifications still drop queued notifications like what happens on HTML5. Unfortunately it appears they do.
The problem is this. Take an android phone running android v10 (it may happen on other versions, I just have v10) and put it into ‘do not disturb’ mode. Lock it and put it face down on the table in front of you and let it sit for a few minutes. You have to let it sit for a sec for this test, it has a lower power idle mode it has to enter into. If you try the test immediately after you put it down it won’t have fully gone idle yet and you’ll get every notification still.
Now that it is sitting in this idling state, try sending it some normal priority notifications. You won’t receive them, which is OK, you put it in do not disturb mode after all I would expect it to block out normal priority notifications in this state. But now turn the phone back on and unlock it. You’ll notice that no matter how many notifications you sent you will only receive one notification at this point, whatever the latest one you sent was. The others you sent before that are gone, you won’t receive them.
This is what always happened to me with HTML5 notifications and testing with mobile app notifications the same thing is happening. I want to be clear, I am totally fine with how the app respects my do not disturb settings, if I set normal priority I’m ok with waiting to receive the notification. But it’s important to me that I do actually receive the notification eventually (assuming my TTL has not expired but most are set to 1 day since that’s the default).
Now I’ve come up with an extremely complicated workaround to this problem for HTML5 notifications (it basically involves sending all notifications through Node RED). I would love to eliminate this complicated flow and just use direct service calls to the mobile app notification integration. Is this a known issue being worked on? Is there a standard workaround someone can direct me to? Is this an issue no one else is seeing and I have to try and track down what weird thing about my phone is doing this?
This is how FCM works, if you send a high priority notification it will drop it if it cant deliver immediately because of the time to live value that you set.
https://firebase.google.com/docs/cloud-messaging/concept-options#ttl
Keep in mind that a time_to_live value of 0 means messages that can't be delivered immediately are discarded.
This entire page I linked should provide more clarity to your issue, I am only pointing out one aspect of your issue. I think you are hitting a FCM limitation personally.
That makes sense. However when I look at HA documentaton on HTML5 Push Notifications it says that if TTL is not provided then the default used is 86400s (i.e. 1 day). I’m always either setting TTL to a value greater then 0 or letting it default to 86400, I have never even tried setting the TTL to 0 (didn’t know that was possible).
The other part that this doesn’t explain is why I only receive the last one. I did a test where I fired two notifications one after another each tagged with simple test1 and test2, all other details (including TTL) were the same. I received only the second one when my phone woke up. I’m not seeing anything in your link that explains this behavior. Is there something I’m missing?
Based on what you are saying this may be a android/firebase limitation since both HTML5 and the mobile app use Firebase to send messages. If you think this is a bug I suggest filing an issue on github detailing all the steps you took. Have you tested this theory with other apps to see if its just Home Assistant having this issue?
I haven’t seen this behavior in other applications. But I’m also not sure which of my other applications are using firebase for notifications or simply creating notifications from the mobile app itself. I can test notification creation with Tasker for instance but that’s not the same since its directly calling the Android APIs to create and interact with notifications.
i assume the HA community website uses Firebase for its HTML5 notifications though right? I can see what happens if I leave the website up on my phone and force two notifications to be sent to it I suppose, see if I get one or both.
Doing some bit of googling though I think it might have to do with the collapse_key property mentioned in the Firebase docs. I found this StackOverflow post where users were discussing it. I thought collapse_key was Firebase’s name for the tag field described in HA’s documentation. But sounds like its different and set by default to the app package name.
If that’s true then that means it will be the same for every notification sent (the package of the mobile app if sending that way or the package of the browser if using HTML5 notifications). That would completely explain the behavior then since as you can see in the firebase docs under lifetime it says this:
If the device is connected but in Doze, a low priority message is stored by FCM until the device is out of Doze. And that’s where the collapse_key flag plays a role: if there is already a message with the same collapse key (and registration token) stored and waiting for delivery, the old message is discarded and the new message takes its place (that is, the old message is collapsed by the new one). However, if the collapse key is not set, both the new and old messages are stored for future delivery.
This sounds like exactly what I’m seeing, the last one is winning and all others are being dropped. So this may just be how firebase works unfortunately 