The weirdest thing prevents notifications from notify.notify

Mobile Apps Home Assistant Companion for Android
1

I’ve been having issues with receiving notifications from the notify.notify service on my phone. The weirdest thing seems to cause it…

TL;DR: If you have a device that has the Home Assistant Mobile/Companion app installed but the device is inactive/disconnected - it can cause the notify.notify service to stop and not send notifications to other active devices that have the Companion app installed. Finding any devices that are inactive/no longer in use and removing them from HA can fix the issue.

I have a Quest 3 VR Headset with Home Assistant Companion App sideloaded so I can see and use the VR headset sensors as triggers and conditions in automations and scripts (notify when the battery is low, turn the lights on/off when the headset is put on/taken off, etc.)

Next, I also have two phones that have the Companion App installed. My wife’s and my own. Three total devices with the Companion App installed.

The skinny: If the VR headset is INACTIVE (sleeping) - I will not receive notifications from the notify.notify service on my phone, but my wife still receives them on her phone, and I get an error in HA:
Logger: homeassistant.helpers.script.websocket_api_script
Source: helpers/script.py:1792
First occurred: 10:32:57 AM (1 occurrences)
Last logged: 10:32:57 AM

websocket_api script: Error executing script. Error for call_service at pos 1: Device not connected to local push notifications

If the VR headset is ACTIVE (connected) then all three devices will receive the notifications from the notify.notify service.

Now, I’m not sure the order of operation here or why my wife consistently receives notifications when the VR headset is inactive but I do not, but I suspect it could be the order the devices were connected, or alphabetically, or something… but it’s consistent and repeatable.

Are notifications sent sequentially? Maybe HA is throwing an error because the headset is disconnected, and then it stops sending notifications to any devices that would follow in the series. So, the headset doesn’t receive the notification (obviously, it’s not active) and my phone also does not receive the notification because it comes AFTER the point of failure. If I plug the VR headset in or wake it up. My phone starts receiving any new notifications sent via notify.notify, but it doesn’t receive any past/missed notifications retroactively (expected).

The logs are not helpful in identifying the device that failed to receive the notification or that caused the stop/error.

This is just a theory, but it would be great if folks smarter than me could do some testing and validation and confirm/correct the issue so that the notification doesn’t stop on error and continues to send notifications to active devices. Is this even something that HA can fix? I have to believe yes, because almost all other notification services from any provider do not behave this way.

In the meantime, I’ve updated some automations to send notifications to specific devices (via a notifications group), which does work but it’s spotty and sometimes the notifications are very delayed or not received until the phone screen is activated or HA is opened (not sure what the pattern is here, I’ve verified correct persistence settings on both phones). However, I would much prefer to be able to use notify.notify for simplicity and accuracy, plus it can be done from the UI whereas using a notification group has to be done from configuration.yaml (one time setup but requires maintenance when new devices are added or old ones removed).

Unrelated suggestion: Add notification group as a group type in the Helpers → Group UI in HA.

Thoughts? Am I crazy?

2

That’s in fact weird. Maybe it’s limited to notify.notify. I’ve never used that service directly, rather my goto is notify.mobile_app_....

What happens if you disable the companion integration for the headset?

I don’t see notification listed in the Add Group wizard under Helpers.

3

I just uninstalled the Companion App from the headset and the notifications were still failing. The device in HA was still active. So I disabled the device in HA and the notifications to my phone were then successful. So it’s definitely related to the Companion App being installed on a device when the device isn’t active (as detected by HA).

Regarding the Add Group wizard under Helpers, you can’t create notification groups there, that’s why I was suggesting to create this feature in the UI. Right now you have to create notification groups in the configuration.yaml file

Like so:

notify:
  - platform: group
    name: "Notification Group"
    services:
      - service: mobile_app_my_phone
      - service: mobile_app_deb_s_phone
      - service: mobile_app_my_quest
4

Do you see the same behavior is you use notify.mobile_app_...?

5

Beware that a service call that fails will stop an automation, unless you specify:

    continue_on_error: true

This might be what stops other notifications if you have multiple consecutive ones and one is not working. This applies to all actions. One service call to multiple targets will try all targets in parallel, so won’t be affected the same way.

6

You probably have service called notify.notification_group or something similar as this is the name you gave to your notification group. You should call this service.
I’m using this notification and it is working fine. I’m just using service call notify.my_group_name.

7

I don’t think that means what you think it means…

image
image717×121 14.5 KB

So, you really shouldn’t use notify.notify if you want reliable notifications.

Notification Integration

2 Likes
8

But I’m only calling one service, using the Developer Tools, Services, notify.notify, message= Test. This throws an error if the VR headset is inactive. If the VR headset is active, or disabled in HA, the service test passes and all devices get the notification. This isn’t about a failed automation, it’s a single native service and how it behaves.

9

I really hate this copout - if it’s not trustworthy, the code should be removed…

10

As I mentioned in my last paragraph, I’m already doing this as a workaround.

11

most users follow the recommendations in the docs to create a notify group and keep that one up to date and only use it, i find it makes life easier and makes notifications more precise.

12

I’m already using a manually created group, it’s in the last paragraph of my first post (I even posted my group code from my config file in a reply)… I posted this hoping that it would guide the devs to a potential solution since there are people here, on github, and reddit, and likely other places, that post about the notify service not always working. I’m really not looking for help or guidance or recommendations. Though I do appreciate the comments.

I do still struggle to understand this behavior, though… “Here’s some code in a production application available to the public, but you shouldn’t use it because it doesn’t work properly”. If it’s really that problematic, either remove the code, or put hovers/info within the application that calls it out and offers alternatives,. Otherwise people are going to use it, it’s not going to work properly, AND THEN they go hunting for why. Save people some time and trouble…It would also be nice if we could use the Helpers → Groups UI to build notification groups rather than the config file.