Google_maps last_seen attribute goes backwards

Has anyone else noticed that the google_maps device_tracker integration sometimes gets updates out of order? I.e., it seems sometimes the last_seen attribute for an update is older than the last_seen attribute from the previous update. I’ve also looked at the latitude and longitude attributes when this happens and it seems sometimes an older update happens a second time (after some other updates with newer last_seen timestamps.)

I have a fix for this that I’m considering submitting as a PR, but I wanted to see if it was happening to anyone else before doing so. I came up with the following as a way to track this happening:

  - name: google
    platform: file
    filename: google.log
    timestamp: true
- trigger:
    platform: event
    event_type: state_changed
    condition: template
    value_template: >
         and is not none
         and is not none
         and is defined
         and is defined
         and <
      message: >
        old: {{

        }} new: {{

        }} {{ }}

This will write entries to a file named google.log in your config directory whenever this happens.

I’d be interested to hear if anyone else has noticed this, or if you give the logging technique a try and what your results are.

FWIW, sometimes this doesn’t happen for hours, maybe days, but generally it seems to happen several times a day.

Yes I have but I’ve asked a few dumb questions in the past about location and device tracking so I decided to just wait a bit and see what happened.

I’ve been tracking down other small things in my setup recently so have been looking in the logs a lot and I have seen the ‘going backwards’ error many times.


Anyone else out there using google_maps device tracker and notice that updates come out of order?

I suppose it’s not easy to notice, which might explain why it’s behaved this way. So…

Anyone else out there using google_maps device tracker that would be willing to log these “going backwards” events using the automation I provide above, and then let me know your results?

I’d really like to get some more feedback before officially submitting a fix. THANKS!!

1 Like

Do you need the logs or just confirmation that it happens?
It happened again a couple of days ago but as you say it is irregular.

I’m happy to log this if it will help…

I’m really just looking for confirmation that it happens. I have logs showing it happening for my account. I’m assuming you know it happens because of the warning from my composite tracker, yes?

So I have confirmation for two people, which is probably enough (i.e., it’s not “just me”), but I’d like to get confirmation from a few others before submitting a PR.

Created PR #30178.

1 Like

please let me add to this, cause it is the only thread also seeing the Backwards error. I noticed this today, and don’t know what it means or why this is caused:

device_tracker.life360_name last_seen went backwards


11:56 AM custom_components/composite/ (WARNING)

but since you asked :wink:

That’s a warning generated by my composite device tracker integration. For each “input” tracker it keeps track of its last_seen attribute. If, when a new update comes in, the new last_seen value is less than the previous last_seen value, it will ignore the new update and print that warning.

This is how I discovered that this seems to happen fairly often with the google_maps tracker and decided to fix it “at the source.”

I can’t say that I’ve ever seen it happen with Life360, though.

EDIT: In fact, it shouldn’t be possible with Life360. It has code to skip updates where the new last_seen is <= the previous last_seen:


ok thanks, I did understand it was your composite integration, but thought it to be of added value because of the Life360 issue this time.

Must say I laughed at first, imagining the person walking backwards…

But, other than that, should we undertake anything? Would this be useful posting as a life360 issue?

Well, as I said, it shouldn’t be possible. But obviously it does seem to have happened. Could you send me all the related lines from your log file (via PM if you like)?

EDIT: Never mind. I think I just figured out how it could happen. I’ll fix it and submit a PR. Thanks for letting me know!

PR was approved and merged. The fix will be released in 0.104.x.

Running 105.4 and getting these errors with Google maps device tracker.

Can you be more specific? Can you post the errors?


not sure if this was the exact same issue as I have (still) with Google Device tracker.
I get these kind of meesages:

Ignoring Martina update because timestamp is older than last timestamp
Ignoring Emilio update because timestamp is older than last timestamp

Those are from the changes I made in PR 30178. Note that they are not errors, they are just warnings. If you don’t want to see them then you can add:

    homeassistant.components.google_maps: error

At some point it might make sense to change the integration so those messages are logged at the INFO level instead of WARNING.

1 Like

Hello Phil!
Thanks - I double checked the spelling and could not find an issue.
I pasted your section in my configuration.yaml

  default: warn
    homeassistant.components.google_maps: error

However the messages still appears

Is there anything else I need to do? (I restarted of course ;-))

Hmm, you’re right. Now that you mention it, I do recall seeing a discussion among the developers where warnings in the UI log cannot be suppressed. Apparently that will only keep the warnings out of the “more detailed” home-assistant.log file (which seems, to me at least, backwards.) But that’s the way it is. :man_shrugging:

I guess that’s another argument for making these INFO messages. I made them WARNING messages, though, on purpose. Even though the change (to ignore these updates) had to be reviewed and accepted, and even though it would have been in the release notes, doesn’t mean that everyone (that uses google_maps) would be aware of it. I wanted to make sure people were aware, but more importantly, get feedback in case there was a problem with it.

So, at some point before too long I’ll submit another PR to change them to INFO messages. Those can be suppressed from the UI log (and typically are.)

1 Like