Due to the nature of htis change it was not feasible to support both formats so it was decided to make it a one time breaking change to keep the parameter names in line with everything else. We did have a discussion on this as normally we would support it just like when sensors were split up from their attributes a while back.
1 Like
This example appears wrong?
automation:
- alias: Command volume level
trigger:
...
action:
- service: notify.mobile_app_<your_device_id_here>
data:
message: "command_volume_level"
title: 20
data:
media_stream: "music_stream"
command: 20
It still uses title?
for others this is correct:
automation:
- alias: Command volume level
trigger:
...
action:
- service: notify.mobile_app_<your_device_id_here>
data:
message: "command_volume_level"
data:
media_stream: "music_stream"
command: 20
oops looks like we missed one, even when you have reviewers things may slip. Thanks for reporting 
Update PR is here: https://github.com/home-assistant/companion.home-assistant/pull/800
1 Like
I’m also having a little bit of a hard time understanding when to use channel and when to use media_stream. Like I see that media_stream is used when using ‘command_**’. Makes sense. But then if I want to do the following as part of a regular alert against a channel I created or a inbuilt one, do I use channel or media_stream. THis is old code and now I wonder if its wrong in the first place.
Since I am sending an alert specifically on the alarm_stream, do I use channel?
- service_template: '{{device}}'
data:
title: Find My Phone!
message: You found your phone!
data:
channel: alarm_stream
priority: high
ttl: 0
tag: General
group: General
timeout: 300
notification_icon: mdi:cellphone-sound
vs
I have a channel doorbell with its own notification. Do I use channel or media_stream?
- service: notify.phone_notifications
data:
title: Doorbell Ring
message: Someones at the door.
data:
tag: Doorbell-general
group: Doorbell
channel: Doorbell
timeout: 180
ttl: 0
priority: high
notification_icon: mdi:doorbell-video
actions:
- action: URI
title: Live
uri: '{{ linkurl }}'
- action: URI
title: All Cameras
uri: /my-home/cams
- action: front-door-unlock
title: Unlock
so this is a normal notification and it is not impacted by the change. Only TTS and the commands were changed, everything else remains the same. Anything that is meant to post as a normal notification is unchanged.
1 Like
Also I think for commands… The location of the ‘command’ is changed. Not just the wording. That makes the note misleading…
" If you have updated the Android app to 2022.8 you must use command in place of title ."
I am not being picky. I promise. I just know others are going to run into this so the wording of hte note may want to be updated?
pre:
- service_template: '{{device}}'
data:
message: command_dnd
title: 'off'
data:
priority: high
ttl: 0
2022.8
- service_template: '{{device}}'
data:
message: command_dnd
data:
command: 'off'
priority: high
ttl: 0
Yup the examples are already updated to reflect that change. Please feel free to submit a PR to make it more clear.
1 Like
@dshokouhi I’m just mentioning it so others will notice. Appreciate all the work on this app. It is pretty great tbh.
1 Like
Also for others… The actual PR summary highlights a very good summary of the changes in one location. This is what I used to find what needed to be addressed and then used the docs for the examples and more info… Of course it may not be complete as the summary was done a long time ago so dont completely rely on that. Rely on the docs.
Thanks again devs…
1 Like
I’m using Node Red and I changed the old parameter to the new parameter voor my TTS notifications but it doesn’t work (used to work before).
| Old Parameter | New Parameter |
|---|---|
| channel | media_stream |
| title | tts_text |
Could it be that these changes are not implemented into Node Red yet? (or is that a stupid question lol).
no idea about node red. But I assume it just calls the HA services. Did you change hte payload and move the values under ‘data’?
" all additional command data will need to be in the data element underneath message"
Look at the examples above.
This is my old config (which used to work)
When sent notification I hear a TTS msg “Please set a title for text to speech to process”
After changing the old parameters for the new parameters (mentioned in that article)
| Old Parameter | New Parameter |
|---|---|
| channel | media_stream |
| title | tts_text |
And now I get this error in NR itself and nothing on my phone obviously.
““Call-service error. extra keys not allowed @ data[‘tts_text’]””
because tts_text doesn’t belong there. Again look at the examples. It belongs under data.
2 Likes
Yes, thanks you are right.
I just assumed replacing the parameters was enough. Because it used to work before.
Anyway thanks for the swift assistance, appreciate it! Time to fix all other TTS notifications 
This is the EXACT kind of response that gives HA a bad name when its talked about on any other home automation forum. HA is putting a focus on simplifying things, moving this to the UI, etc… to help attract new users. But when these users have questions, the answer from a dev is “Check the GitHub PR”?? Like, come on! Not everybody is going to even know what Github is, what PR stands for, or what the hell they’re looking at in the thousands of lines of code that may be in a PR. This is the exact opposite of what HA is trying to accomplish.
As for me, I’m far from being new at this. I saw the note about the breaking change as well. Was kind of shocked it didn’t say what the breaking change was. So I hit the notification section in the companion docs. No note there about what the breaking change was either. Weird… figured it would have been on top since a breaking change to notifications is a pretty big one for almost everybody. Now I see here the examples in the docs were updated. That’s great, but it still doesn’t tell me what the breaking change is without pulling up my code and comparing it all line for line until I find it. That’s a major pain in the ass, so I hit up GitHub. Well there were 10 separate PR’s in this release related to notifications. So which one caused the breaking change, and which one relates to my setup? (FYI, not every one of those 10 have notes added)
This is how I found this post. Doing a search to find something that tells me exactly what the breaking changes for notifications are before I spend the next hour comparing code to examples that may be completely irrelevant.
Documentation for the breaking change could certainly be better. I don’t use TTS so after browsing this thread I assume this breaking change doesn’t relate to me? But I can’t say that with 100% certainty. So I guess I’m going to start reviewing my code and comparing it to examples which may or may not have been changed while I sit here hundred of miles away from my HA because I can’t afford to miss a critical notification.
Sorry to call you out like this. I can appreciate the time and effort you put into making these changes (I see you were the one who did the PR). But in the future please document it better in the release notes as well, and help the ones who have questions instead of treating them like they’re devs themselves and should know as much as you do.
3 Likes
Wasn’t there supposed to be a blog post about these kinds of changes before the update went into affect?
I woke up yesterday to none of my intents working But I didn’t have the time to try to dig in and figure out why. Luckily I already had my alarm set so I didn’t need to rely on an automatically updated and broken system to not make me late for work.
Later on I just happened to see this forum post asking for info on the same topic. Then I opened up the mobile app and saw the update notification.
I very rarely open my mobile app so it would have been nice to have an update notification before things broke.
1 Like
I can understand not having advanced warning of the changes. A community post could have been made, but not everybody would have seen it. And play store auto updates installed apps on the majority of phones, and it’s not a process like on the server side where you can get a popup to read the changes before confirming the update.
But at least put in the notes what the actual changes were, or a link in the popup to separate breaking changes page in the docs if it was too long for the popup. Anything so we don’t all have to go play Where’s Waldo in the docs LOL
1 Like
I can’t.
maybe not everyone would have seen it but there should have been at least some attempt at letting people know things were about to break.
We see forum posts all the time about new releases and updates and/or at least linking to a blog post about it. Why not the same for this?
1 Like
Turn off your play store automatic updates. Then it won’t auto break when releases are made. Then you can selectively upgrade when you review the release notes/changes.
Agree with Rob, don’t use auto updates.
Most people wouldn’t have it on HA releases so why have it the app?