Mobile app update breaking changes?

Mobile Apps
35

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
36

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
37

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.

38

Agree with Rob, don’t use auto updates.
Most people wouldn’t have it on HA releases so why have it the app?

39

This isn’t always possible. While I can on my personal phone, my work MDM requires all updates for security reasons

It’s also closing the gate after the horse has bolted in this case, as others have also pointed out!

1 Like
40

I typically am adamant about never updating things related to HA. I never really thought about the mobile app auto updating and especially about it auto-updating with intentional breaking changes.

I’ll definitely have to re-think that (non-)strategy now.

I wonder if it’s possible to turn off auto-updates on a per app basis? I’ve never worried about other phone apps auto updating but then again they don’t typically intentionally break functionality or have that big of an impact on my day to day life as HA does.

41

It is possible, bute that I’ve ever given it any concern before…
I’m still not really sure why the old way of handling the notification couldn’t remain viable for a period… When we launch breaking changes (which is very rare) at work this is a necessity (for a long period as well, but that’s enterprise software for you), and we give much warning, and many details on the fixes

Ultimately, whatever the reason or intention this has been handled badly. As pointed out above, it’s a terrible experience for a new and existing user and counter to what HA is trying to do. I came over from a commercial system because I wanted to build stability… That’s already been scuppered and I’m less than a month into my HA journey
Thankfully for the most part I’m a competent coder, am beginning to understand YAML (despite accusations to the contrary above) and am genuinely spending time learning - I’ll get it fixed when I’m back from my holiday, but it’s a week without things I wanted to know while away

But the biggest problem for me is that knowing how things work and being confident in how I set things up now only seems to be half the battle … all of this only helps if we’re WARNED of breaking changes and ADVISED clearly of what they are and HOW to fix them . Otherwise things break through no fault of my own

1 Like
42

Yes that is possible. At least on my phone and all androids I have owned. Perhaps it has changed but I don’t believe so.

1 Like
43

It has remained for a long period in my opinion.

I like this change, I really do. The old way was very confusing when you make complex notifications.
(using command or intents)
Why was title, message and tag part of the intent notifications.
Which makes more sense “channel” or “intent_package_name” when you are trying to send an intent?

Back when notifications started it was just notifications. Then came the command notifications, and I can’t blame the developers because I know I have done the same, and probably many of you too, you use what you already have and try to adapt the code.
And then when you add more and more features and all of the sudden you realize that you have crammed too much in to what was not really meant for it in the beginning and you get a breaking change because you need to rename and reorganize.

44

It wasn’t the breaking change that was the issue. I get why the change was made.

It was the lack of prior communication that the breaking change was coming on an app that the typical user auto-updates.

And I believe what @vaderag was saying is that it may have been possible (and seems as it was from the posts above) to maintain both ways of configuration for a while before removing the older way. This is done for pretty much every other aspect of HA and why it wasn’t done here is a mystery.

Thanks I’ll have to look into how to do that.

45

There are a lot of changes that happen over night in HA.
But the communication is better for those changes, agree on that.

I don’t see where it was mentioned to keep both formats. I see this though:

46

Oops.

I was obviously wrong about that.

47

Another breaking change I literally just found is that the way that bluetooth devices are reported has changed.

They used to say just the MAC address. Now they report the MAC address along with the connection name in parenthesis.

I couldn’t figure out why my garage door automations weren’t working and it was because this condition check was failing.

48

I can understand some of the frustrations. I had the same!
Friday I had the idea to make some TTS notifications for some of my reminders/system. I spent a lot of time fiddling around with it in Node Red. I’m no experienced user and especially not a coder but am willing to learn it if that improves my personal skills.

But only to find out the next day everything is broken again while it worked was a bit of annoyance. And the funny thing is I wasn’t aware that the companion app received an update. By coincidence when I opened it I saw it.

Maybe it’s an idea, especially with breaking changes, to also receive a notification in Home Assistant itself?

I thought I would be done quickly by changing the parameters (see above) with the new parameters name but also that didn’t worked. Apparently the order was also incorrect. But it didn’t caught my attention because it used to work (but maybe that is just my lack of coding skills).

49

You could do something like this:

alias: Notify new app version
description: ""
mode: single
trigger:
  - platform: state
    entity_id:
      - sensor.andreas_current_version
condition: []
action:
  - service: notify.notify
    data:
      message: New mobile app version is installed on phone
      title: New Home Assistant app version
2 Likes
50

That’s a really good idea.

I didn’t even realize that sensor existed.

Thanks for the solution.

51

I can’t find a working automation example script. Who can put a working HA automation script in this post to only send a TTS text notification to an android phone?

52

In my eyes it’s ridiculous to change this TTS behavior just with an Home assistant app update. It’s quite normal to updates phone apps. Now all my TTS Command won’t work. My complete alarm system is working with command from out of node-red. I’m on vacation and I can’t even repair it now. Downgrading my app is also not an option because I tuned a lot of notification channels on the phone which a gone after downgrading. I think is really a bad action, just change TTS thing and not keeping it downwards compatible. I am mad about this.

53

I cannot find a Home assistant automation TTS script. Just to send a TTS to a smartphone. Please put a yaml example for HA in this post.

54

I think this portion of the docs is what you need?

automation:
  - alias: "Notify of Motion TTS alarm"
    trigger:
      ...
    action:
      - service: notify.mobile_app_<your_device_id_here>
        data:
          message: TTS
          data:
            tts_text: "Motion has been detected"
            media_stream: "alarm_stream"
1 Like