Should be fixed now 
2 Likes
Is there a way to use this for notifications of core updates on a Container install? HA Container doesn’t provide any update entities by default.
I’ve installed the Version integration (I already use it for a basic update notification automation I wrote myself), but it also doesn’t provide an update entity. Instead, it provides a binary_sensor and a sensor. Is it possible to use one of those with this blueprint, or is there a better solution?
[rant] It still astounds me how complex HA manages to make something as simple as getting an update notification… In any other software it would be built in, yet HA decided to strip out what basic update notification functionality they use to have instead of improving it. [/rant]
1 Like
Unfortunately this blueprint can’t help you as it only works on update entities.
Your rant is fair IMO. As a supervisor user I was pretty happy about these new update entities and really didn’t care that updater was tossed. But container and core users only lost something in that exchange, they didn’t gain anything. Well at least not for core, can still make use of the HACS update entities.
The counter point though is that update entities are more then just notifiers. Like if you look at the update platform it’s more then just informational, each update entity also comes with an update.install service to actually execute the update. That’s the reason an update entity can’t be provided currently for core in core/container builds, there is no way for core to execute that update. The system administrator has to make the change to the docker compose file or the venv to make that hapen.
I don’t think I can easily update this blueprint to support something besides update entities as it would require a lot of changes. I think you’ll have to have your own automation for that. Although if you do have a way to execute a core update from within HA on your system you might want to consider making a feature request for a template update entity. That way you can make your two sensors and whatever service does the update into an update entity and use it as one.
Thanks for the reply @CentralCommand. Looks like I’ll have to stick with my own automation for now. Not a big deal now I have it set up, though it’s not nearly as full-featured as your blueprint.
Of course, as you say, updates are easy for Home Assistant OS users – clearly the team’s main focus. It’s just a pity Container users like me lost out in the process. Ideally HA would provide a built-in update entity for core, even if the install service doesn’t work on Container and Core installs. The rest of the functionality would still be useful. (I guess I should open a feature request for that if there isn’t one already.)
1 Like
Hi,
first I have to say, great work, works flawlessly!
However, one thing I noticed in the log and today I have only noticed that it is related to the blueprint.
The following error is displayed:
2022-05-05 12:09:25 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute 'icon_url' when rendering '{{ data if not (
device_attr(mobile_app_device, 'manufacturer') == 'Apple' and data.icon_url
) else dict(data, image=data.icon_url) }}'
Apparently something with “apple” and the “icon_url” if I get it right. Unfortunately, I am not so experienced to be able to correct this myself.
Let’s say everyone had an Apple device. What should I remove from the script?
Or do you have another way to get rid of the warning?
I thank you
2 Likes
Fixed.
TBH I still have mixed feelings about Warn on undefined variables in templates by emontnemery · Pull Request #48140 · home-assistant/core · GitHub . I get why it was done and it has helped me locate issues in some of my own templates with unexpected undefined variables so that’s good. But I really wish it hadn’t removed the ability to do a simple “does it exist” check in an if statement like 'thing exists' if thing_that_may_not_exist else 'thing does not exist'. Now you always have to remember to add a test of some kind like 'thing exists' if thing_that_may_not_exist is string else 'thing does not exist'. Oh well.
2 Likes
Hi Mike @CentralCommand
Just a tiny contribution, just in case you want to compile a library of “changelog urls” in your original post, so that users can quickly copy and paste what they need.
Here is my collection based on my addons.
update.appdaemon_update: https://github.com/hassio-addons/addon-appdaemon/releases
update.home_assistant_google_drive_backup_update: https://github.com/sabeechen/hassio-google-drive-backup/releases
update.influxdb_update: https://github.com/hassio-addons/addon-influxdb/releases
update.log_viewer_update: https://github.com/hassio-addons/addon-log-viewer/releases
update.mariadb_update: https://github.com/home-assistant/addons/blob/4ea140e5a707ac7d9abe9b5e7a78c4ecb66ac9ae/mariadb/CHANGELOG.md
update.mosquitto_broker_update: https://github.com/home-assistant/addons/blob/4ea140e5a707ac7d9abe9b5e7a78c4ecb66ac9ae/mosquitto/CHANGELOG.md
update.node_red_update: https://github.com/hassio-addons/addon-node-red/releases
update.ring_mqtt_with_video_streaming_update: https://github.com/tsightler/ring-mqtt-ha-addon/blob/906ecbadb241ab81e7acdc63910bae05a341dc07/CHANGELOG.md
update.studio_code_server_update: https://github.com/hassio-addons/addon-vscode/releases
update.tasmoadmin_update: https://github.com/hassio-addons/addon-tasmoadmin/releases
update.zigbee2mqtt_update: https://github.com/zigbee2mqtt/hassio-zigbee2mqtt/blob/85a19bbc57f37b6bbd19d02ff6a5692b795f38fd/zigbee2mqtt/CHANGELOG.md
Hope this helps someone
3 Likes
This is a great blueprint and was working flawlessly, but every time i reboot HA, I see this in the logs. Unsure how to go about troubleshooting it:
Logger: homeassistant.components.mobile_app.notify
Source: components/mobile_app/notify.py:195
Integration: Mobile App (documentation, issues)
First occurred: 4:00:10 AM (1 occurrences)
Last logged: 4:00:10 AM
Timeout sending notification to https://mobile-apps.home-assistant.io/api/sendPushNotification
EDIT: originally i thought i was not getting notifications, but i realized i had muted them.
What of this should I be worried about?
— 1 —
Logger: homeassistant.components.automation.notify_diverse_updates
Source: helpers/script.py:1718
Integration: Automatisierung (documentation, issues)
First occurred: 19:38:33 (10 occurrences)
Last logged: 19:42:06
Notify_Diverse_Updates: Error executing script. Error for choose at pos 1: Device not connected to local push notifications
Notify_Diverse_Updates: Choose at step 1: Update started: Choose at step 4: Only send to mobile devices if within provided time range: Choose at step 1: default: Choose at step 3: Send to second mobile device if specified: Error executing script. Error for device at pos 1: Device not connected to local push notifications
Notify_Diverse_Updates: Choose at step 1: Update started: Choose at step 4: Only send to mobile devices if within provided time range: Choose at step 1: default: Error executing script. Error for choose at pos 3: Device not connected to local push notifications
Notify_Diverse_Updates: Choose at step 1: Update started: Choose at step 4: Only send to mobile devices if within provided time range: Error executing script. Error for choose at pos 1: Device not connected to local push notifications
Notify_Diverse_Updates: Choose at step 1: Update started: Error executing script. Error for choose at pos 4: Device not connected to local push notifications
— 2 —
Logger: homeassistant.components.automation.notify_diverse_updates
Source: components/automation/__init__.py:525
Integration: Automatisierung (documentation, issues)
First occurred: 19:38:36 (2 occurrences)
Last logged: 19:42:06
Error while executing automation automation.notify_diverse_updates: Device not connected to local push notifications
It sounds like you’re using the minimal HA app or otherwise have it set to only use websockets when talking to your phone. And since your phone wasnt connected to HA at that moment when the automation tried to send it a notification and using the Google queue service wasn’t an option then the service call failed. If you have the Google queue fallback turned off entirely then I imagine you’re going to see failed to send notification errors periodically when sending a notification happens to line up with a time when your phone lost service or power.
Not really anything this automation can do about that. I guess I could set it to continue_on_error if that helps for some reason. But there’s no way for the automation to actually respond to an error with some kind of try-catch construct.
continue_on_error sounds good. I have two devices set up as notification targets.
- one is only using Firebase messaging, no local
- one is always using websocket (local), no Firebase messaging
Frequently both of them are not online so yes, this happens (and does for other notification automations as well, where the error message is a more preciseError executing service: <ServiceCall notify.mobile_app_[...] homeassistant.exceptions.HomeAssistantError: Device not connected to local push notifications).
I think until the HA companion app finally has an event for a successfully sent notification, those errors will stay. See Basic notifications via HA Companion app issue: not received if devices not online - #9 by zacwest where I need to follow up and the creation of a feature request (sth. like “event for received notification”) is needed.
By the way: I use notification groups, which your blueprint currently does not allow/offer. In those I group certain HA companion app notification targets. Using two single devices might be sufficient for most, but not all cases (as written above: my two are offline from time to time, e. g. flight mode during the night etc.) and if I swap or add devices next to updating my central notification group I need to recall “oh yes, there’s another automation I need to update”. Maybe you can change the blueprint to allow such targets and more than two entries (I’d go for 5 ;-)).
I can’t do notification groups or random notification services. See here for why (was asked above):
Basically there is no selector for a notification service. I’m only able to “cheat” that restriction with mobile notifications thanks to device actions.
I guess I can do 5 mobile devices to send notifications to. I was really hoping device actions would take a list of device IDs though so I didn’t have to hardcoded in a specific number of devices…
OK I got you. Well there always are some limitations, aren’t they 
Good if you could at least enhance the number of devices/recipients.
BTW: do you know when HACS update entities will come to stable? Don’t want to enable experimental features but miss those notifications somehow 
Possible to not show update button for integrations not supporting the update service? I get this on my Synology NAS:
Error for choose at pos 1: Entity update.nas_dsm_update does not support this service.
@CentralCommand OK I want/need to understand what is different in this blueprint versus any other default usage of notify.mobile_app_* service.
Updates popped up (addons). Old notification (Supervisor command_line sensor, you know it because it’s from you 
) automation worked perfectly. Received it on my iPhone via usual push over mobile network.
Few minutes later once the update entities were switched on, your blueprint based automation got triggered - but didn’t fire any notification:
Yes, one of my two configured notification targets/devices is switched off (Android via Websocket). But what about my iPhone which sits patient in silence. 
Do you either only use Websocket for push notifications or does the automation fail if one device could not be supplied (where the other could be)?
In short:
- old automation: fine
- blueprint notification: none
And yes, of course the listed addons are selected to be monitored in the automation config (at least one of them).
UPDATE - Strange thing: next update notification was delivered successfully.
I wasn’t aware that was possible. What is creating that update entity if it has no update service?
This looks like the commit that created the update entity for that integration: Add update entity to Synology DSM (#68664) · home-assistant/core@61f8af8 · GitHub
So the package relies on polling of the supervisor API that returns info on what updates are available. I actually didn’t set a scan_interval on the sensor in that package by default so that means every minute it was asking supervisor what updates are available. If supervisor returns any then the sensor turns on and the alert sends out a notification immediately saying “there are updates available”.
This new one no longer polls the supervisor API. Instead it relies on the update entities that the supervisor integration makes and manages. This is great and much more efficient with resources. However there’s an issue. It is not possible for me to make a trigger like this:
trigger:
platform: state
domain: update
to: 'on'
In order to trigger the automation any time any update entity turns on that’s what I need. It’s not an option. The best I can do is this:
trigger:
- platform: state
entity_id: !input update_entities
to: 'on'
- platform: time_pattern
hours: !input reminder_hours
This way it will notify you immediately when any of the entities you list in update_entities turn on. But listing out all the entities manually sucks and you have to update that list every time you install a new addon or HACS component. So it has a polling loop every few hours where it collects all the update entities and notifies you about any that are on.
I almost didn’t make the blueprint because I was frustrated by this gap in functionality but was convinced the polling loop is good enough for most people. You can see the note about it at the top:
I’m guessing you have the update_entities input either left blank or with very few update entities in it right? Unfortunately you will have to list out every update entity that you want immediate notifications about it. For others that you don’t list, you’ll get a notification every x hours (whatever you put in reminder_hours). It’s the best I can do at this time. I will fix it if a future enhancement allows, it bugs me too.
No I listed 90 % of my addons cause those are the ones I care/use productively. I tested the reminder_hours and found it pretty annoying, I’m totally fine with a single/one-time notification.
By the way: the permanent notification “open” link defaults to the default page - I would have expected the /config/dashboard or /config/updates or /hassio/dashboard instead.
Update: it always directs to the current page (here a custom dashboard of mine), not the default one.
1 Like