In the last day or two I have noticed that my notification automations stopped working. I went through the traces and see that the original notify.mobile_app.iphone service has silently changed to notify.mobile_app_MYPHONENAME_phone
The only thing that could’ve caused this is the upgrade to iOS 15.3. I did not change/readd the HA app integration, reinstalled the app nor tinkered with anything. If it indeed did somehow change silently, that’s really bad because even the critical notifications stopped working without me being aware.
This change happened a while ago as well. I believe when the andriod app was released, the mobile_app integration changed the default entity_id. I don’t remember what version but it feels like over a year ago.
Well for me it changed in the last few days. I don’t know what to say. It was working with the original service name a couple of days ago (for almost two years), today it’s changed.
I was asking literally yesterday about audio-only notifications, with the original service name. I was getting the notification all right, clearing it didn’t work. Up until yesterday.
Today, none of my phone notifications work and the service name is changed.
The only match for searching “notif” in current and last log is
2022-01-29 14:01:08 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [2939690216] Received invalid command: mobile_app/push_notification_channel
The notifications work fine after searching and replacing the old service name with the new one in automations.yaml and scripts.yaml. That’s not the point. My point is, how did this change silently by itself when there was no HA update?
Something errored on startup with the notification platform, a new entity registry was created, and the mobile app must have assigned your new entity to the new registry.
From that point forward, it’ll use the new entity registry. You can create a notify group with your new entity_id pointing at your old entity_id without adjusting anything
Find the error, it’s not dangerous. Something broke. You fix that and it may go back to normal. This is why you always want to fix errors when you get them in your logs regardless of the platform the error is created in because it can lead to other issues, like this.
I think the Lovelace notifications need some rethinking as to what info is surfaced where.
On one hand, I’m getting bogus " login attempt failed" for whatever reason (same password since day one in 2019) - which should be in log but it’s a Lovelace badge for some reason, on the other hand potentially dangerous thing like failing notifications because something somewhere happened is not surfaced at all. How is the end user supposed to know something’s wrong? The normal assumption here would be “there’s no notification, therefore nothing happened”.
This could be solved with “Beware, notification entities have changed because of error”.
I’ll post a feature request on Github, rant over.
Yes I do that but I don’t check logs unless I think something’s wrong. When you don’t get a notification, you typically don’t assume the notification system is borked. You assume there’s nothing to be notified about. That’s my point.
then make an automation that notifies you when errors are ijn the logs. I understand your frustration, but you have the tools in front of you to get what you want.
