custom-components / places

Component to integrate with OpenStreetMap Reverse Geocode (places)
GNU General Public License v3.0
114 stars 22 forks source link

State & formatted_address may point to different locations #241

Closed ildar170975 closed 10 months ago

ildar170975 commented 1 year ago

Here are settings for some "places" sensor:

      {
        "entry_id": "e2c9b70ee52b16e75ebac62b9610ab81",
        "version": 1,
        "domain": "places",
        "title": "place_redmi_7a",
        "data": {
          "name": "place_redmi_7a",
          "devicetracker_id": "sensor.tracker_common_redmi_7a",
          "options": "formatted_place",
          "home_zone": "zone.*************",
          "map_provider": "google",
          "map_zoom": 19.0,
          "extended_attr": false,
          "show_time": false,
          "date_format": "mm/dd",
          "use_gps_accuracy": true,
          "api_key": "************"
        },
        "options": {},
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "user",
        "unique_id": null,
        "disabled_by": null
      },

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 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:

zone:
  - name: izmailovskii
    latitude: 55.77531186548292
    longitude: 37.81940460205079
    radius: 50
    passive: false
    icon: mdi:pine-tree

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):

image

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).

github-actions[bot] commented 10 months ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

ildar170975 commented 10 months ago

Cannot reproduce it. Will reopen if observed again.