Hey guys,
I’m having troubles with my presence detection. I have somewhat periodic reports of wrong locations from two different android phones. However, the location reports are not random, but instead show allways the same wrong locations. And the report is also claming that the location is accurate to less then 100m, but its oviously many km away.
The picture shows presence for the last 24 h. We have been at home the complete time. However there are two obvious outliers (and they are not noise).
In fact these two outliers are actually much more then two but about 5 or so, and its allways pointing at the same location. Where I never was.
Here you see, that its actually more then one event
And here you see its allways pointing to the same location
In fact there is a second such point as you can see from the first screenshot, but it shows basically the same behavior. As this happens about 3- 5 times a day, presence detection is rendered useless by this.
Have you ever looked which GPS coordinates were written down in your recorder?
The location transmission on my mobile phone sometimes fluctuates within a very short time, often in terms of accuracy and even with Google Maps.
Maybe your cell phone network in Saulheim is so bad or the GPS determination is so unstable that it uses the cell phone masts in Mainz for triangulation??
Greetings to Rhineland-Palatinate, from a former resident
I started to think around this was well. However I currently fail in extracting the gps attributes from the recorder. I think the only way is bare sql and reading it of. A bit annoying but maybe the only way of getting the information. Or is there any easy way of getting historic data from sensor attributes?
Okay, I managed to scrape the data with the rest api. I filtered for one of the phones and can look at all the location reports. However, they are all source_type: "gps" so I guess its not based on cellular triangulation. Also from the raw data, i can see, that the not_home events are not perfectly the same ones, just so much, that it looks the same on the map. Here are two exampes:
If you look in the companion site we have instructions to look up the Android crash logs. In those logs we have some debug statements that cover the decision making process for sending location data back home. You can look at those logs and determine what’s going on as well. After you follow the steps to get it setup you need to filter by the tag for LocBroadcast and you can then see how it works. The docs sure has other tips as well.
thx for the suggestion. However I rather fix the problem at its root. I already have to many of these quick-fixes at play, and they always cause more work along the road.
If nothing helps, my quick fix solution would be to filter by time. As these wrong position updates are short single points, they are always below 10m and that is a delay, I could live with in not_home presence detection.
Okay, I managed to catch an event. This time it was pointing to the second fix point, I mentioned in my OP, but didn’t show to you yet. The event shows:
01-26 12:39:01.262 8100 8100 D LocBroadcastReceiver: Got single accurate location update: Location[fused 50,888392,6,841048 hAcc=32 et=+10d0h43m25s556ms alt=119.20000457763672 vAcc=1 sAcc=??? bAcc=??? {Bundle[mParcelledData.dataSize=52]}]
01-26 12:39:01.262 8100 8100 D LocBroadcastReceiver: Location accurate enough, all done with high accuracy.
01-26 12:39:01.262 8100 8100 D LocBroadcastReceiver: Last Location:
01-26 12:39:01.262 8100 8100 D LocBroadcastReceiver: Coords:(50.8883917, 6.8410481)
01-26 12:39:01.262 8100 8100 D LocBroadcastReceiver: Accuracy: 32.099
01-26 12:39:01.262 8100 8100 D LocBroadcastReceiver: Bearing: 0.0
01-26 12:39:01.263 8100 8100 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
01-26 12:39:01.263 8100 8100 D LocBroadcastReceiver: Received location that is 2317 milliseconds old, 1611661138946 compared to 1611661141263 with source fused
01-26 12:39:01.306 8100 9139 D LocBroadcastReceiver: Location update sent successfully
01-26 12:39:01.629 8100 8100 D LocBroadcastReceiver: Not requesting accurate location, last accurate location was too recent
01-26 12:39:02.117 8100 8100 D LocBroadcastReceiver: Not requesting accurate location, last accurate location was too recent
01-26 12:39:09.336 8100 8100 D LocBroadcastReceiver: Got single accurate location update: Location[fused 49,874706,8,150048 hAcc=29 et=+10d0h43m34s610ms alt=119.20000457763672 vel=0.76 bear=60.0 vAcc=1 sAcc=2 bAcc=82 {Bundle[mParcelledData.dataSize=52]}]
01-26 12:39:09.336 8100 8100 D LocBroadcastReceiver: Location accurate enough, all done with high accuracy.
01-26 12:39:09.337 8100 8100 D LocBroadcastReceiver: Last Location:
01-26 12:39:09.337 8100 8100 D LocBroadcastReceiver: Coords:(49.874706, 8.1500481)
01-26 12:39:09.337 8100 8100 D LocBroadcastReceiver: Accuracy: 28.944
01-26 12:39:09.337 8100 8100 D LocBroadcastReceiver: Bearing: 60.0
01-26 12:39:09.337 8100 8100 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
01-26 12:39:09.337 8100 8100 D LocBroadcastReceiver: Received location that is 1337 milliseconds old, 1611661148000 compared to 1611661149337 with source fused
01-26 12:39:09.364 8100 9140 D LocBroadcastReceiver: Location update sent successfully
2021.1.1-full is written in the config pannel of the app
I don’t understand the question. I have just configured the app and use the build in device tracker. I can not remember setting any special settings concerning requesting location updates. How would I do that?
ah, okay, I remember activating this, because I had the situation that presence was not detected for hours at some point and I was hoping this might improve it. However maybe this setting is the root of my issues.
no issue since implementing @dshokouhi suggestion. In any case could you try to explain the problem to me. why does “include in sensor updates” cause this kind of behavior? Given the option description I don’t think this is intended behavior.
So with that setting, anytime any sensor that you have enabled has an update it will make a location request for 5 attempts. This is how sensor updates work, we don’t just update one we check all of them for changes. Now if you do multiple they will be back to back, they do not get replaced here as a new request gets made with each update regardless if the current request is completed. This wasn’t an issue before but as we added more and more sensors it became to be more widespread and actually resulted in bad battery drain and a constant GPS signal.
The app already has logic that handles the received location events and we evaluate how “new” the request is and as long as its within a few minutes we accept it and send it. We only look at the data that google sends to us. For whatever reason google were sending valid data with incorrect location, it may have been caused by backed up location requests?
okay, I must double down on this. The same Problem still exists, it just happens more rarely. So we have mitigated the issue by reporting the location less often, but the issue still exists. By now the only thing I could think of is what @CM000n mentioned, that it is some issue with the “improved” Location service from Google taking other sources than GPS like Wifi into account. In any case, I don’t understand how the accuracy information is determined in these cases, as it is reporting an accuracy of <100m but in reality the location information is off by more then >20km.
I will disable the service that is called “Google-Location-accuracy” (my translation from the German “Google-Standortgenauigkeit”) and see if that changes anything. Are there any other suggestions @dshokouhi?
in the cases that you do see it, how do the logs look around that time? have you adjusted any other sensor settings in the app? like minimum accuracy for example?
The app relies on google sending us valid data and we make a best effort to put things through its paces which is why you see the logging the way you do. If we can find a pattern then that might help track down the issue.
You mean the logs from the phone I assume. I’m working on it, but given that the incidence happens rarely now, getting the logs will take more time. You would want logs of multiple events, so we can look for a pattern? Also currently I’m only getting logs from one phone, would the logs from both phones help?
Indeed I have. I have set the Minimum Accuracy to 100m for the two location sensors and I have slightly shrank the home-zone to 150m, as it was (for debugging) set to gigantic 350m covering half my village ^^
Did you ever figure this out? Would love to know how to fix, since I’m having the same issue with an Android phone. We have two devices hooked into presence notifications - the iOS one works fine, never reports incorrect position. The Android one will report a location outside our house range 4-5 times a day.
