Commanding high accuracy mode stops after a few seconds

Mobile Apps Home Assistant Companion for Android
1

In the past this command has been successfully been used to command a phone in to high accuracy mode:

service: notify.mobile_app_andreas
data:
  message: "command_high_accuracy_mode"
  title: "turn_on"

I can see that the phone receives the message and the high accuracy notification is pinned in the… Ehmmm menu?
Anyways it seems to work as before, but after 2-3 seconds the high accuracy mode is disabled again.

The sensor confirms this behavior, although it seems it has missed a few times the accuracy mode was on.

Screenshot_20220317-201925-991
Screenshot_20220317-201925-991720×1600 73.8 KB

I don’t know when this behavior started but can anyone confirm this to make sure it’s not just our two phones here?

I found something interesting in the logs:

03-17 20:20:00.161 18158 18158 D ForegrndServiceLauncher: Check if service HighAccuracyLocationService is running. Service running = false
03-17 20:20:00.185 18158 19924 D LightSensor: Light sensor listener registered
03-17 20:20:00.191 18158 18158 D LightSensor: Light sensor listener unregistered
03-17 20:20:00.233 18158 24096 D LocBroadcastReceiver: High accuracy mode disabled, because bluetooth device(s) (false) not connected
03-17 20:20:00.324 18158 19924 D NextAlarm: Next alarm is scheduled by com.google.android.deskclock with trigger time 1647576000000

It seems that it disables the high accuracy because I’m not connected to the Bluetooth that is specified in the app settings.
So that is kind of true.
But when you command on, is this the expected behavior?

2

In the companion app, under location settings, the last setting high accuracy only when connected to BT. Is anything set there?

image
image1080×2160 182 KB

3

This is what I have:

Screenshot_20220317-211201
Screenshot_20220317-211201720×1600 70.2 KB

So yes.
But in the past commanding high accuracy has trumped over this setting.
If this has changed then it’s no big deal.
I just remove the setting and command high accuracy instead of using the setting.

4

Is it possible you had a zone set for high accuracy? BT is defined as a constraint, as is zone and one needs to be true if they are both set.

5

sounds like you are hitting this issue https://github.com/home-assistant/android/issues/2102 although it talks about zones behavior sounds similar if not identical

6

It looks very identical yes.

I just tried to remove the Bluetooth part of my settings and tried it again and it works as it did before.
I can command on and off as it was before.

Screenshot_20220318-042755
Screenshot_20220318-042755720×1600 73.3 KB

That means I could use the Bluetooth sensor and look for connection with HW-BT and then command on with notification to create a manual function.
This would then make it function at all times.

But as I understand from this issue, this is not the expected behavior?

7

yea basically if you turn on high accuracy mode, then the automation should assume its on until the constraints evaluate to false same thing if you turn it off it shouldnt kick in until the next time it becomes true. It should behave more like an override, but you are also correct you can handle the functionality in an automation as well. There is so much logic in this one feature that making changes can become difficult to not introduce a new issue.

8

I’m having this same issue, and it just seems to have started recently.

The Bluetooth setting does appear to (now?) override high accuracy mode no matter what.

This is an issue, as high-accuracy mode now seems to be the only way I can get on-demand accuracy updates, as my “request accurate location” command no longer seems to be doing the trick in situations where it is important to get a devices location on command.

Not sure I really understood @dshokouhi 's last response entirely… this is not expected behavior correct?

Thanks all!

9

As I understand it, this is a bug.
It should function as it did in the past but there is so many conditions to this function that it will be like cleaning a house with dirty shoes.
You clean one spot and turn around and it’s dirty again.

That is a common issue when you get to nested in the code.
There is so many conditions and triggers that any changes will break something else.

What I’m planning on doing is to remove the BT part of the app settings.
That way I can use a trigger in an automation to say if connected to device turn on high accuracy with a command message, and turn of when not connected.

That way you move the decision making from the app to HA server.
Not an ideal solution but if you need the ability to command on then this will have to do for now.

10

There is a PR to solve this problem https://github.com/home-assistant/android/pull/2383. Hopefully it will solve my problem and yours as well. As soon it is merged i will do a test and report.

11

You don’t have to wait for it to be merged to provide feedback. Go to the actions tab on GitHub and select the PR. Then download the debug APK and it will install side by side the production version. From there enable persistent connection to always and then test it out. Firebase messaging doesn’t work in the debug builds but local notifications will work for testing.

12

A legend. I will attempt to take @dshokouhi 's advice when I have some time tomorrow and test to see if this resolves the issue for me as well.

1 Like
13

Thank you, i realize that i really don’t know much about github :roll_eyes:

Just made a debug walk and it solves my and this problem. High Accuracy turns on (and stays on) even if you are not in the zone or the bt device is not connected. When entering the zone or the bt device connects it will stay on and follow its normal logic from this point.
The only thing (since i do not work with the bt devices for high accuracy mode) i noticed, when leaving my car (which is the bt device connected for my test) the high accuracy mode stays on as well. I do not know how it was before the change, i would have guessed it should have turned off.
Since i am working only with the zones it’s not a big deal for me.

14

If you notice any bugs after that PR was merged please file them on GitHub