@CentralCommand Thank you for this awsome blueprint, just picked up a bug or at lease I think it might be, I tried to update from my ios device, but the trigger event was not ‘install_ios’ but instead ‘install’ and then it failed setting the update entityId.
Oh, huh. So to my knowledge any time an action was clicked in ios which the action identifier came back in trigger.event.data.actionName. But in android it would come back in trigger.event.data.action. This was happening as recently as a week ago for me, I actually commented on an old discussion with all the inconsistencies I found between ios and android here and that was one of them.
But now today I’m testing and suddenly ios is stuffing the selected action in trigger.event.data.action as well. Which honestly is great, I’m glad there’s consistency in this. But leaves me a bit confused as to what happened. I don’t see a PR about this in the past week…
Anyway thanks for bringing it to my attention. I will fix it. I might leave the code in there to handle action or actionName since I’m still still a bit skeptical how this changed. But I’ll make sure it works for the event data ios appears to be returning now.
@DickSwart@erik7 updated with fixes for both of these issues, sorry about that.
Unfortunately no. There’s no notifications and you need to reimport after. It’s a bit frustrating I know, we had a bit of a discussion on it here. There’s an FR to improve this, please vote for it!
I was wondering if you are experiencing the same, or if what I am seeing is an isolated case, or maybe installation type dependant.
My Supervisor Update entity shows as Unavailable. And I don’t mean with a state of “Unavailable” (red colour in history) but a status of “Unavailable” (grey colour - like when a device is disconnected and the entities are unavailable). Here are some screenshots to compare - notice the red exclamation mark too
I have not seen that myself but it looks like you’re hitting this issue. Fortunately this PR went in to fix it about 10 hours ago. Unfortunately that was too late for 2022.4.3 so I would look for a 2022.4.4 to fix it most likely. It doesn’t say so on the PR right now but my guess is that will get cherry-picked for the next patch.
Oh i checked for issues yesterday and nothing was raised, and now i was paranoid but didn’t check again. Thanks for the investigation.
Another suggestion Mike, not a deal breaker, just not great UX i feel.
The icon used for the notification package-up, i would personally suggest to either revert to default, the HA icon, or provide an icon picker field (not sure if it was made available in such use case) or an input field.
My reasoning behind this is that the user loses the app author that sent notifications, especially when in the top bar only. See some screenshots, alongside your old package for comparison.
Don’t get me wrong, i fully understand what you have tried to achieve, but i just feel it distances the notification from the authoring app. Maybe the user input is the best of all worlds, leaves the choice to thr user.
I find the icon change really handy personally since I usually have a bunch of HA notifications in my bar and can tell without expanding the bar whether its something I should look at immediately or not. That was actually my most missed feature when I switched from html5 notifications to the android companion app ones a long time ago. Well besides actions but I just refused to switch until those were added. So I guess you could say its my most missed feature that I was willing to live without
It was only added (relatively) recently which is why it was missing from the update notifications package.
To give back, i’ve had a look into the 2nd desired Improvement, and i think i might have a solution. Though i have not tested it and today has been a long day. Happy to have a go at it tomorrow if you don’t make it work by then
Use an input for mobile_app_devices that supports multiple: true, like the entity one.
Change your &send-to-mobile-devices sequence to a repeat along these lines (over simplified and not accounting for the Apple check):
- &send-to-mobile-devices
repeat:
# Get total number of devices in list and repeat that many times
count: '{{ !input mobile_app_devices | count }}'
sequence:
# Get device in loop number - 1 (as arrays start at position 0)
device_id: '{{ !input mobile_app_devices[repeat.index - 1] }}'
domain: mobile_app
type: notify
title: "{{ title | default('') }}"
This might not be a plug and play answer, and again, forgive me for not testing something for you, but today’s day already melted my brain. I do however thing that this is on the right track, and should get what you want
Hope this helps, at least slightly (from an inspiration perspective if not much else)
This won’t work because the device_id field does not accept templates. Give it a shot, just make a quick script. Try this below and you’ll see what happens (replace device_tracker.my_phone with whatever you call your phone’s device tracker):
- variables:
id: "{{ device_id('device_tracker.my_phone') }}"
- device_id: '{{ id }}'
domain: mobile_app
type: notify
title: Hi
message: Hi
You get this:
It doesn’t say it there but what’s actually happening is its trying to literally use the text {{ id }} as the ID. It’s not processing it as a template.
The other option I tried was just to provide a list of device IDs for device_id. That works for entity_id so seemed like you should be able to just do this for device_id:
- device_id: !input mobile_app_devices
...
Where mobile_app_devices has multiple: true. That doesn’t work either though, lists aren’t accepted.
That’s where I ran out of ideas. I looked around and it seemed like other blueprints are doing a fixed amount of mobile_device_# inputs so I did that too. But it definitely bugs me.
Hm… i see. Thanks for your well documented answer.
Am i right in assuming that the same sort of problems are to be expected if we change the notify sequence for a notify service call? e.g. service: notify.rob where the notify services are pre-defined in the config? And instead of the user choosing mobile app devices, they choose from a list of previously defined notification services?
In my case:
configuration.yaml
notify: !include includes/notify.yaml
notify.yaml
- name: rob
platform: group
services:
- service: mobile_app_rob_s_phone
- name: steph
platform: group
services:
- service: mobile_app_steph_s_phone
- name: both
platform: group
services:
- service: mobile_app_rob_s_phone
- service: mobile_app_steph_s_phone
That is… not how I thought default worked. Really thought it shortcircuited, apparently not. Just switched it up to use a proper if statement there, sorry about that.
right, I disabled all the other entities besides the update one there on my system. Obviously not everyone does that.
