The issue is that the current places sensor's state is a name of some zone which is NOT at same location as a displayed address.
All address' parts (city, street, code) do correspond to friendly_address - but this does not correspond to that zone.
The friendly_address is very close to the real location of the device as well as current_latitude & current_longitude (i.e. this is a correct info).
The zone is located ~3-4 km from the real location.
Note that the previous_latitude & previous_longitude (55.7677427,37.818593) also do NOT belong to that zone which is defined as:
but is rather close, check these 2 points:
Used an online calculator, it gave 844 m.
The source sensor (sensor.tracker_common_redmi_7a) "jumped" to that zone for some short period (~3 minutes), check that short "magenta" part in the timeline:
About this sensor.tracker_common_redmi_7a sensor:
it analyses data for several trackers associated with this particular "redmi_7a" device (Life360, Traccar, HA companion app, asuswrt) and gives the latest location.
Ofc some tracker may "jump" to some another place - like it did on the timeline above (could happen due to some issues with local precision of GPS/GLONASS tracking or own phone's glitches) - even with a high gps_accuracy!
So, the phone really "thinks" that it was moved to this wrong location(((.
So, the source sensor updated a location to some zone.izmailovskii ("Измайловский") - and the "places" sensor is probably updated to this zone.
But after a small period the source sensor again updated to the real location (described by friendly_address, current_latitude & current_longitude) - but the places sensor state is still the previous zone ("Измайловский").
Also, this "jump" may occur with a low gps_accuracy and probably the places could identify these coords (55.7677427,37.818593) as that zone (which has only 50 m radius and does not cover these coords).
Update: here is a log from Traccar server (used as a device_tracker integration):
The worst gps_accuracy was ~1.9 km - probably this is why that zone (located in 844 m) was selected by device_tracker as a current zone.
But still this does not explain why the zone was same after a significant change of coordinates (to the "current" coordinates) with a good gps_accuracy.
I do not think I can reproduce this glitch.
Tried to manually change a location of the source sensor to another zone, but the places sensor always shows proper data (address & zone do correspond to each other as expected).
Here are settings for some "places" sensor:
Here is a current state of this sensor:
"Uncensored" version may be provided via e-mail.
The issue is that the current
places
sensor's state is a name of some zone which is NOT at same location as a displayed address. All address' parts (city, street, code) do correspond tofriendly_address
- but this does not correspond to that zone. Thefriendly_address
is very close to the real location of the device as well ascurrent_latitude
¤t_longitude
(i.e. this is a correct info). The zone is located ~3-4 km from the real location.Note that the
previous_latitude
&previous_longitude
(55.7677427,37.818593) also do NOT belong to that zone which is defined as:but is rather close, check these 2 points: Used an online calculator, it gave 844 m.
The source sensor (
sensor.tracker_common_redmi_7a
) "jumped" to that zone for some short period (~3 minutes), check that short "magenta" part in the timeline:About this
sensor.tracker_common_redmi_7a
sensor: it analyses data for several trackers associated with this particular "redmi_7a" device (Life360, Traccar, HA companion app, asuswrt) and gives the latest location. Ofc some tracker may "jump" to some another place - like it did on the timeline above (could happen due to some issues with local precision of GPS/GLONASS tracking or own phone's glitches) - even with a highgps_accuracy
! So, the phone really "thinks" that it was moved to this wrong location(((.So, the source sensor updated a location to some
zone.izmailovskii
("Измайловский") - and the "places" sensor is probably updated to this zone. But after a small period the source sensor again updated to the real location (described byfriendly_address
,current_latitude
¤t_longitude
) - but theplaces
sensor state is still the previous zone ("Измайловский"). Also, this "jump" may occur with a lowgps_accuracy
and probably theplaces
could identify these coords (55.7677427,37.818593) as that zone (which has only 50 m radius and does not cover these coords).Update: here is a log from Traccar server (used as a
device_tracker
integration):The worst
gps_accuracy
was ~1.9 km - probably this is why that zone (located in 844 m) was selected bydevice_tracker
as a current zone. But still this does not explain why the zone was same after a significant change of coordinates (to the "current" coordinates) with a goodgps_accuracy
.I do not think I can reproduce this glitch. Tried to manually change a location of the source sensor to another zone, but the
places
sensor always shows proper data (address & zone do correspond to each other as expected).