Google_maps last_seen attribute goes backwards

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

life360_xxx: Ignoring update because timestamp is older than last timestamp

Have been receiving this error for many months for one person in circle. Guessing there was a bogus timestamp many months ago thats prevents further updates. How do I clear out the bad data?

If somehow the timestamp retrieved from the Life360 server was corrupted and was interpreted as some time in the future, it is possible to see this warning until a new timestamp comes that is after it. However, this invalid timestamp will not be retained across HA restarts. So, restarting HA should resolve the problem (unless it happens again for some reason.)

Honestly, this doesn’t happen much that I’m aware of, and when it does it seems to resolve itself in short order. And from the few times I’ve heard of it or seen it happen directly, the problem was more that an old timestamp was unexpectedly received as opposed to one in the future.

Bottom line, there isn’t a whole lot that can be done about it. The HA integration has to believe the data it is receiving from the Life360 server. If the server sends bad data sometimes, :man_shrugging:

Does the warning happen constantly for this one person? Are there good updates in between? Do the GPS coordinates in HA tend to keep up with that person’s device?

You could try adding this to your config:

  default: info
    homeassistant.components.life360: debug

Then restart HA. After a while you can check home-assistant.log and look for messages concerning life360. There might be some messages, especially DEBUG messages, that can shed light on how this person’s device is behaving.

Phil, thanks for the response, however this has been going on many months with many restarts, many updates, a couple restorations. I don’t have the knowledge or skills yet to diagnose with any validity but my guess is there is a file stored somewhere that doesn’t get overwritten with normal activities. This person’s life360 account works normally, so I assume it is somewhere in HA. I was thinking someone would tell me to go to directory xxx and eliminate file yyy and the world would be wonderful. Wish life was that simple. Any help appreciated…

oops, I just found the rest of your message, miss it in gmail. Will add debug to config for more info


Nope, there isn’t. There is a volatile variable that holds the most recently seen timestamp for each member from the Life360 server. That gets updated when a new timestamp is received which is later in time. But if the new timestamp is older than the most recently seen timestamp, then you get that message. When HA restarts this variable is effectively cleared.

So, again, this is happening because that is what the Life360 server is sending. I have no idea why it does this sometimes.

FWIW, I use both life360 and google_maps for three users/devices. I see this message all the time with google_maps (by that I mean it’s not uncommon, not that it’s constant), but I almost never see it with life360. Two of the devices are Android based, and one is an iPhone.

Unsure if this has anything to do with the Life360 issue or something else. Unsure if it was there before. Many likely related messages afterwards. How do I issue a Session.rollback()?

Source: components/recorder/
Integration: Recorder ([documentation](, [issues](
First occurred: 8:44:36 AM (17 occurrences)
Last logged: 9:20:45 AM

* Error in database connectivity during keepalive: This Session's transaction has been rolled back due to a previous exception during flush. To begin a new transaction with this Session, first issue Session.rollback(). Original exception was: (sqlite3.DatabaseError) database disk image is malformed [SQL: INSERT INTO events (event_type, event_data, origin, time_fired, created, context_id, context_user_id, context_parent_id) VALUES (?, ?, ?, ?, ?, ?, ?, ?)] [parameters: ('state_changed', '{}', 'LOCAL', '2020-07-10 16:12:14.004532', '2020-07-10 16:12:14.010703', 'bf6bf4cacbd54b99869042aef3781431', None, None)] (Background on this error at: (Background on this error at:```

to answer your questions. This persons life 360 reports have never shown up in HA life360, only this error message. They are using an android device. Can see updates fine using Life 360 app. I have been excluding this person in config to avoid errors but this was an effort to resolve it if possible. I’m not a developer, simply trying to follow instructions and very much enjoying the adventure. Using a Pi 4 HASSIO 0.112.3 (0.112.4 seemed to cause WYZE Sense issues).

No idea what that is. I doubt it’s related.

seems I some clean up to do ( perhaps db file is corrupt), before making progress. Restoring to 0.112.3 may have created some issues.

Will revisit if I learn anything that I think might be useful to you. Thanks for the assistance.

1 Like