I don’t really disagree with you except the part about prior warning being infeasible.
It is feasible. I didn’t say that it was great but at least we could have been told in some way prior to breaking things. Again, not a perfect system but it’s better than nothing.
It caught me off-guard exactly the same way it did you. I woke up to a bunch of strange “command_activity” messages from HA.
I think we actually agree completely, I just didn’t get it across with how I worded it. To expand my original wording: It’s not really feasible with HA to give advanced notice in a way that reaches passive users, since there is not necessarily a way to contact them.
Yep. Auto-update installed the update, but nothing happened to actually trigger the breakage until today because I work from home and am also generally a hermit.
You can’t blame the developers for auto updates on your phone. Disable it. This goes for every single app. There’s plenty of apps I’ve disabled auto updates for this very reason. HA is one of them. That particular issue is on the user.
This is your advanced notice:
Yes we can. We can blame them for a pipeline that doesn’t recognize the reality that auto-update is the default, and it should therefore be the expected experience of end users. It is known in software development that most users can be expected to leave settings at defaults. This is why, for example, predatory cookie consent implementations are so widespread - these sites have to comply with law but they don’t want to, so they make it opt out rather than opt in because it snags as many people as possible.
Development and release should be done with that in mind, especially with breaking changes. They need to be communicated in advance of causing breakage. A vague link to patch notes on the app page that users with auto-update enabled will not see before updating absolutely does not count. It especially doesn’t count when that link isn’t even clickable and - as I already pointed out earlier in the thread - the note about the breaking change is vaguely worded and buried 33 lines deep in a large, coma inducing bullet list. "It’s your fault you got caught off guard by a breaking change because you didn’t turn off auto-updates, manually browse to a github release page, and read through dense bullet points" is not a rebuttal, it’s a sweatlordism.
Perhaps your argument is that we shouldn’t expect professional standards from work that is done for free by volunteers, but the only people that position actually insults are the HA developers, so maybe you want to rethink that.
Are you putting words in my mouth? 
Maybe you should rethink that. 
This issue of auto-updating is a plague on all apps. Kodi, Plex, HA, automate for android, tasker, blah blah blah. If you have any experience, you should know to disable this. If you don’t then you’ll have to live with the breaking changes unless you think the developers should call you before they deploy breaking change. Do they have your number?
Take ownership for what YOU can control. You can control auto-updates. If your app didn’t auto-update, you wouldn’t even be here whining about this right now.
The only piece I agree with on this ENTIRE topic is a more concise view of ‘what’ to change. That could use improvement. I had to search a bit like where’s waldo. But they do their best…
Really? that’s the road we are going to go down? 
Does anyone at all think really that it’s unreasonable for at least a blog post and a note in the forum pointing to it that there are breaking changes coming?
We get a blog post about Leviton joining “works with Home Assistant” but not a word about breaking changes that have the potential to affect every mobile app user?
I don’t. I blame them for not telling us that there were pretty big breaking changes coming that could have been at least a bit mitigated by a blog/forum post.
as for auto updates here’s my thoughts on that from another thread about the exact same thing:
not having thought the auto-update thing on mobile all the way thru is entirely on me.
pretty crappy advanced notice.
We went thru this same pain many years ago when the main app devs put little to no info in the release blog post (at least there was one tho) about breaking changes until users complained enough that they finally started making those posts more informative. I’m sure this was (hopefully) in this case just a one time snafu.
The silence is deafening with any contrition tho (just like before). A simple “oops, we messed up and should have done it” would go a long way.
yes, its 867-https://community.home-assistant.io/
Guys - let’s stay on the topic. I’m sure there are better thread to discuss breaking changes and updates and mechanisms…
@RockDuster -
Do you have what you are looking for? If yes, could you help share what kind of automation code you have in the end?
I am asking because I’m interested in how well this high accuracy mode work. Do you actually get good location reports? How frequent? Any impact on battery drain?
High accuracy mode uses GPS so it’s very accurate. Default time is every 5 seconds but also user configurable. It will have an impact on battery life. More on how it works here:
Depends on the phone but works well with a pixel. I only trigger it when entering a zone so I can get better location reporting on entering to my house. But works fine. It will sure drain a battery if you keep that on.
Essentially this:
I’ve played this game before. Don’t pretend that the very next place you were geared up to go wasn’t the standard troll response of telling me I don’t get to complain about software I’m not paying for.
If you had any experience, you know how ridiculous you sound blaming problems stemming from a deployment pipeline with poor communication on end users not turning off auto-update. Meanwhile, it’s because I have experience that I know better than to rely on constant manual work to make sure I have regular updates - you know, those silly little things that include security patches - to software that runs on devices which hold my personal information.
But I guess I’m the asshole for not assuming that the HA dev → deploy pipeline would involve poor/no communication of breaking changes or any advanced notice that they’re coming, right? Please.
I think what I’ll do instead is continue to point out when basic software development/deployment concepts aren’t being followed to the detriment of users. That’s what happened here. A breaking change that didn’t even need to be a breaking change to begin with was deployed to the app with no advanced notification of any kind, and your trolling and insults do not make that stop being bad practice.
I’d certainly be a lot more charitable if any acknowledgement at all of the failure to communicate this change properly could be found in this thread.
Breaking changes and the communication thereof are something I have dealt with regularly for over a decade. The only time I’ve got legitimate bad will from it is when there was no advanced notice. People accept that software updates that cause breakage are sometimes unavoidable. What they do not accept - rightfully - is not finding out about the breakage until it’s too late for it not to cause problems.
It’s also pretty shameful for one of the developers to Like a comment from a hostile troll calling users whiners because they got blind sided by a breaking change that was communicated to… checks list… nobody.
It’s very straightforward. I have automations that trigger when my phone changes state with my Home zone. They use the method described here to enable High Accuracy when leaving, and disable it when entering. This was done as a workaround for repeated issues with High Accuracy mode crashing if left on all the time. @dshokouhi covered the rest.
The arrow is clickable.
This is what happens.
A clickable link.
But sure the breaking changes could have been more visible.
Cool, I didn’t even know this existed 
And that’s exactly what’s wrong: when working with software on docker containers or Pi’s, I know I can expect breaking changes. With Android apps I can’t remember ever having an app with breaking changes… ? This is a first for me, and I think not only for me… All my apps are on auto-update for years, never had any problem…
I always read the release notes on HA, the complete blog and listing. It would have been nice to at least have a blog post on this Android-release with breaking changes? Even better if every release note of the Companion app could be posted online
There has been a few breaking changes in the past. Not that many but each release of the companion app has had something that I felt the need to do.
It could be a new feature, setting or sensor.
I try to stay on top of things with the app since I use it quite advanced i believe.
I also didn’t know this existed.
This exactly. No other app I use, or have used in the last 11 years of being on Android, has caused breakage because I had the audacity () to leave auto-update turned on. I have had no reason to turn it off, and every reason to leave it on. But even if it was turned off, that’s just a band-aid. It doesn’t solve the problem, it just kicks the can down the road, and dumping the responsibility of not getting blindsided by breaking changes onto end users is, to put it mildly, bush league.
Looking at the releases page
On the first page a CTRL +F on breaking change gave me 20 hits.
Going to page 2, doing the same gave me another 20 hits.
And on page 3 there was 20 more.
I believe all these was on the same thing to be honest, I didn’t look very closely.
But I scrolled back a few more pages to June releases and we get 17 hits
The same discussions are on the forum more or less every release of HA and most people agree that it’s each person’s responsibility to read the release notes.
I don’t see the difference here.
You are completely 100% missing the point.
There is a blog/forum post for every HA release. (THAT is the major point right there).
And the main HA releases happen literally every month on the same schedule month so they are completely expected. After scrolling thru all of the releases (almost all beta releases) it looks like the last full release was released in June 9th. Definitely not on a known fixed schedule. So we literally have no idea when to expect the next update.
And the main HA release notifications include an easily readable post noting all the breaking changes in one place. Not buried on a Github releases page. That you need to scroll thru the entire list of changes that few people really care about to pick out the words “breaking change” on various dispersed lines.
Again AT A MINIMUM there should be a blog/forum post on what to expect before you update just like the main HA releases.
If there would have been ADVANCED WARNING of the upcoming release I would have gladly read the release notes just like I do on every HA release just as I have for literally every release since I’ve started with HA.
This HA mobile is no different…oh…well…except…I didn’t get the warning.
I’ll quote this one more time for emphasis.
That would be nice. I do agree it would be nice to have summarized/highlighted change included in blog updates for what’s in an update.
That being said, how would that have prevented anyone in this thread from auto-updating their app and thus breaking their notifications? Turning off Auto-update is the key.
There’s no advance warning for Home Assistant updates either. Blog posts are pushed out when the update goes live. The difference here though is home assistant doesn’t automatically update (yet?). I suppose advance warning would be nice but if you put that in the ‘current release’ blog post, it’s no longer advance warning as the blogs are for the current ‘active’ release.
Here’s a perfect example of how that should work:
Home Assistant Companion Android App Release 3.0.0
November 6, 2020 Daniel Shokouhi
Hey everyone it’s been a little while since we last spoke. We have a brand new Home Assistant Companion for Android release that we are excited to get into your hands and will roll out over the next day or so in the Google Play store.
The latest release forum notification post I can find was from 2022.2. I don’t know if that post was made before or after the app update was released since it doesn’t say.
So it’s not as if the attempts haven’t been made in the past so it’s not unreasonable for people to have expected the same this time. Tho those posts have been pretty hit and miss (I didn’t see one for 2022.6 either).
You did see the release page where you can search for “breaking change”?
I’m fairly sure each mention of it is a real breaking change.
A few people blindly update HA each month and have no issues, and apparently swear by breaking changes has never existed on HA.
You kind of do the same here, there is real evidence there have been breaking changes, some of them have been up for discussion on the forum in the past.
How many of your HACS/custom components post blog posts with all their breaking changes on each release?
Or perhaps you never update those integrations?
Lot’s of replies….
I’m more interested inthe solution. 
How does this automation look like?
