"command_high_accuracy_mode" notification not working correctly in 2022.8.0-full

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.

2 Likes

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

Comments

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. :blush:
How does this automation look like?

That is the solution.

This is taken directly from those docs:

automation:
  - alias: Turn off high accuracy mode
    trigger:
      ...
    action:
      - service: notify.mobile_app_<your_device_id_here>
        data:
          message: "command_high_accuracy_mode"
          data:
            command: "turn_off"
automation:
  - alias: Set high accuracy update interval
    trigger:
      ...
    action:
      - service: notify.mobile_app_<your_device_id_here>
        data:
          message: "command_high_accuracy_mode"
          data:
            high_accuracy_update_interval: 60
            command: "high_accuracy_set_update_interval"
1 Like

i agree with all you guys, but, keep in mind, we can demand many things and they (dev team) can do prioritize internally, but we can’t attack them if they don’t agree on our prioritization. Doesn’t matter if it is free or paid;

  • either we use it as it is and give continuous feedback,
  • or, if we have skills we step up and do it,
  • or, we stop using it
3 Likes

Now that I think about it, I think the blog posts has been when there is a new major feature.
I don’t think I have seen a blog post for the app that has been “we just fixed some bugs and changed some minor things”.
But I could be mistaking

Yes.

but you have to:

  1. know a release is coming.
  2. know where to go to find the release notes

Literally no one knows when 1 is going to happen except the developers.

Most people have no idea github even exists let alone how to find the release notes.

Well except for the silly claim that I swear there is never any breaking changes in HA I do unintentionally blindly update in this one instance. I’ll solve that issue so I don’t get caught again.

I do put some trust in the devs to just at least post a “heads up breaking changes care coming” thread but my trust is apparently misplaced.

most of the developers in HACS post the breaking changes in the release notes in the pop up window in HACS that you have to click on BEFORE you can update the integration/plugin.

I do pretty much the same thing on my own integrations/plugins (at least on the very rare occasion there are unavoidable breaking changes - I try to avoid them like the covid virus :wink:).

I’ve even gone so far as to ask users what they want me to do before I even create those possible changes that might affect them.

I do. I just read the release notes. The ones that pop up in the HACS window where you have the button to update.

Nothing I use related to HA except the mobile app auto-updates and I’m a staunch proponent of never auto-updating anything related to it.

This one caught me out by surprise. It won’t happen again.

1 Like

Please do not devolve into personal attacks or abuse.

1 Like

On every development team I’ve ever been part of, that would indicate that we (read: our PMs) were doing something wrong with our communication. It is not up for debate that ramming breaking changes out the door with the only advanced notice being “Get burned from the last update so you know to turn auto-updates off, then read an unorganized list of patch notes before you allow any update to happen” is bad practice.

That alone wouldn’t have. That doesn’t mean it shouldn’t be done.

Where these issues would - and should - have been prevented is with more care being put into the change. I looked at the code. It could easily have been written to be backwards compatible. It could have been deployed supporting both new and old formats, with a prominent notification that the old format would be deprecated in a future release. That is not possible for all breaking change, but it was for this one.

This isn’t a matter of “different people prioritize different things”. This is a fundamental failure of good software development/deployment procedure.

2 Likes

Hi Rob, I’am also curious about the solution, the proposed solution you took from the docs is it working for you?

Yes it works fine for me.

Hey guys,

I’m trying to get this to work on a pixel device as well and having the same problem as the OP.
I’m trying to call it through dev tools in services and it’s still calling a regular notification with my command in it and not changing the setting. Did they change the syntax again? It does the same thing with every command.

No the syntax didn’t change. Your screenshot does not match the code you quoted and the spacing in the quote looks off too.