I have automations set up that enable High Accuracy Mode on my phone when I leave the Home zone, and disable it when I re-enter. Since updating to 2022.8.0-full yesterday, this doesn’t work properly. Now, instead, I am getting notifications like this:
And it’s not enabling/disabling High Accuracy Mode. This only occurs on my phone, which has the latest app version, and not on my wife’s, which does not.
There was a breaking change in the recent version. You’ll need to update the automation to the new format.
Now that I know what I’m looking for, I see it in the patch notes… buried 33 lines down among a bunch of "bump"s, and phrased so vaguely that I don’t think I would have known I needed it even if it were the first line. This change was not called out nearly prominently enough.
Breaking changes are a big deal. Since it’s not really feasible with HA to give advanced notice, at the very least they need to be put front and center with the impact and resolution steps communicated clearly.
Yeah, it is.
We get advance notice all the time for breaking changes in the forum and blog post for new releases.
Forums and blog posts are inadequate communication channels for breaking changes. It is poor practice to expect users to take action to be aware of breaking changes in advance. Breaking changes should be communicated in a way that reaches passive users. Since use of HA does not require giving any contact information to HA, that is not feasible.
Edit: Btw, no mention of this breaking change was made anywhere on either the blog or the forum.
That screen has poor readability, does not appear until you actually open the app, and is easy to blow past if you’re opening it because you’re trying to troubleshoot a problem. Meanwhile, that line is about as clear as mud about what has actually changed, why, what updates need to be made, and where the documentation actually is. Like I said originally, it is entirely too vague.
And even if you intend to dismiss those problems, the change itself was still fundamentally deployed poorly. The PR was created a year ago - Clearly it wasn’t urgent. Why wasn’t more time and care taken to make it backwards compatible? I read the note in the PR, it’s not valid. And there’s nothing in the code update that mandated this be a breaking change. The proper way to have done this was with backwards compatibility, and if the old format needs to be phased out, then do so in a future release after giving users who don’t engage with blogs/forums the time to make the necessary changes - before their automations are broken. The time you find out that an update has broken something should not be after you have already installed the update.
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.
