They did not appear as icons on the map. The map was empty, besides the map itself.
Which map? The default one in the sidebar automatically hides icons of entities that are home. Were all the people home when you looked?
You can use a map card to specify what entities (device_tracker
, person
, zone
) will be shown, and I’m pretty sure that does not hide entities that are in the home zone like the other map does.
Did you check if the device_tracker
entities existed, by looking on the STATES page? What did it show for the Google Maps integration? I.e., did it show any devices & entities?
It’s a basic map with two device_trackers, both from the same “Alt acct only” as described above. They weren’t ‘hidden’, they weren’t showing. I did check on Google Maps directly to see where the persons are, and they were reporting.
I didn’t check on the states, as I somehow expected the cookie to be invalid, which it obviously wasn’t. Instead I did a reboot, after which the two entities showed again.
Next time I’ll check wether the device_tracker entitities exist and if there’s anything with the integration before I’ll do anything else.
I am still am having problems with the cookies expiring even after applying the latest version on the integration. I have set up a specific homeassistant map login and then attached my wife’s and my account google accounts to the new login. After about an hour I am asked to reauthenticate the credentials. I believe that my setup meets Alt acct only definition. I have tried the Pers acct only but have the same issue. Any assistance would be appreciated as I want to use this as a replacement for Life360.
Thanks.
Is anyone using that ‘Alt acct only’ for anything?
Do you mean 1.1.1?
Can you share the exact ERROR messages?
Also, have you enabled debug? If not, please do and try again. If so, please search the full log for DEBUG messages that contain the word “cookies”. There should be one when the integration is set up (either when first added, reloaded, reconfigured, or when HA restarts) that lists the cookies from the cookies file and each one’s expiration timestamp. Then every 15 minutes, and at shutdown/restart, if any new cookies have been received from the server, there should be another DEBUG message listing the names of the cookies that have changed and are being written to the cookies file. Please share these messages, and any other related DEBUG or other messages from the log, either here, or you can open an issue on the custom integration’s github repo.
Appreciate your followup. Details as requested below:
“version”: “1.1.1”
Debug cookie messages:
2024-02-23 09:01:01.094 DEBUG (SyncWorker_61) [custom_components.google_maps] [email protected]: cookies: TAID: 2024-03-07 12:40:05+10:30, 1P_JAR: 2024-03-24 09:00:29+10:30, _gcl_au: 2024-04-24 10:27:22+09:30, AEC: 2024-06-20 10:43:12+09:30, SEARCH_SAMESITE: 2024-08-20 07:38:33+09:30, NID: 2024-08-24 07:20:29+09:30, SNID: 2024-08-24 07:20:29+09:30, AID: 2025-02-06 18:30:00+10:30, __Secure-1PSIDTS: 2025-02-22 09:00:36+10:30, __Secure-3PSIDTS: 2025-02-22 09:00:36+10:30, SIDCC: 2025-02-22 09:01:01+10:30, __Secure-1PSIDCC: 2025-02-22 09:01:01+10:30, __Secure-3PSIDCC: 2025-02-22 09:01:01+10:30, ANID: 2025-12-22 11:43:16+10:30, _ga: 2026-01-24 11:34:03+10:30, _ga: 2026-01-24 11:34:03+10:30, _ga_B7W0ZKZYDK: 2026-01-24 14:37:27+10:30, APISID: 2026-02-21 12:41:13+10:30, HSID: 2026-02-21 12:41:13+10:30, SAPISID: 2026-02-21 12:41:13+10:30, SID: 2026-02-21 12:41:13+10:30, SSID: 2026-02-21 12:41:13+10:30, __Secure-1PAPISID: 2026-02-21 12:41:13+10:30, __Secure-1PSID: 2026-02-21 12:41:13+10:30, __Secure-3PAPISID: 2026-02-21 12:41:13+10:30, __Secure-3PSID: 2026-02-21 12:41:13+10:30
2024-02-23 09:01:03.737 DEBUG (SyncWorker_51) [custom_components.google_maps] [email protected]: cookies: TAID: 2024-03-07 12:40:05+10:30, 1P_JAR: 2024-03-24 09:00:29+10:30, _gcl_au: 2024-04-24 10:27:22+09:30, AEC: 2024-06-20 10:43:12+09:30, SEARCH_SAMESITE: 2024-08-20 07:38:33+09:30, NID: 2024-08-24 07:20:29+09:30, SNID: 2024-08-24 07:20:29+09:30, AID: 2025-02-06 18:30:00+10:30, __Secure-1PSIDTS: 2025-02-22 09:00:36+10:30, __Secure-3PSIDTS: 2025-02-22 09:00:36+10:30, SIDCC: 2025-02-22 09:01:03+10:30, __Secure-1PSIDCC: 2025-02-22 09:01:03+10:30, __Secure-3PSIDCC: 2025-02-22 09:01:03+10:30, ANID: 2025-12-22 11:43:16+10:30, _ga: 2026-01-24 11:34:03+10:30, _ga: 2026-01-24 11:34:03+10:30, _ga_B7W0ZKZYDK: 2026-01-24 14:37:27+10:30, APISID: 2026-02-21 12:41:13+10:30, HSID: 2026-02-21 12:41:13+10:30, SAPISID: 2026-02-21 12:41:13+10:30, SID: 2026-02-21 12:41:13+10:30, SSID: 2026-02-21 12:41:13+10:30, __Secure-1PAPISID: 2026-02-21 12:41:13+10:30, __Secure-1PSID: 2026-02-21 12:41:13+10:30, __Secure-3PAPISID: 2026-02-21 12:41:13+10:30, __Secure-3PSID: 2026-02-21 12:41:13+10:30
2024-02-23 09:16:10.414 DEBUG (MainThread) [custom_components.google_maps] [email protected]: Saving cookies, changes: updated: __Secure-1PSIDCC, SIDCC, __Secure-3PSIDCC
2024-02-23 09:21:11.183 DEBUG (SyncWorker_60) [custom_components.google_maps] [email protected]: cookies: TAID: 2024-03-07 12:40:05+10:30, 1P_JAR: 2024-03-24 09:00:29+10:30, _gcl_au: 2024-04-24 10:27:22+09:30, AEC: 2024-06-20 10:43:12+09:30, SEARCH_SAMESITE: 2024-08-20 07:38:33+09:30, NID: 2024-08-24 07:20:29+09:30, SNID: 2024-08-24 07:20:29+09:30, AID: 2025-02-06 18:30:00+10:30, __Secure-1PSIDTS: 2025-02-22 09:00:36+10:30, __Secure-3PSIDTS: 2025-02-22 09:00:36+10:30, SIDCC: 2025-02-22 09:20:56+10:30, __Secure-1PSIDCC: 2025-02-22 09:20:56+10:30, __Secure-3PSIDCC: 2025-02-22 09:20:56+10:30, ANID: 2025-12-22 11:43:16+10:30, _ga: 2026-01-24 11:34:03+10:30, _ga: 2026-01-24 11:34:03+10:30, _ga_B7W0ZKZYDK: 2026-01-24 14:37:27+10:30, APISID: 2026-02-21 12:41:13+10:30, HSID: 2026-02-21 12:41:13+10:30, SAPISID: 2026-02-21 12:41:13+10:30, SID: 2026-02-21 12:41:13+10:30, SSID: 2026-02-21 12:41:13+10:30, __Secure-1PAPISID: 2026-02-21 12:41:13+10:30, __Secure-1PSID: 2026-02-21 12:41:13+10:30, __Secure-3PAPISID: 2026-02-21 12:41:13+10:30, __Secure-3PSID: 2026-02-21 12:41:13+10:30
2024-02-23 09:21:11.185 ERROR (MainThread) [custom_components.google_maps] Authentication failed while fetching Google Maps ([email protected]) data: InvalidCookies: Invalid session indicated
Thanks, and sorry for taking so long to get back to you.
The cookie dump is sorted by expiration timestamp, the first being the earliest, and the last being the latest. From this information, it looks like none of the cookies have expired. And the ones that are thought to be most important don’t expire for almost two years!
Yet, the server response at 09:21:11 seems to indicate the session has been invalidated.
Did you also enable debug for locationsharinglib? (If you enabled debug via the GUI Integrations page, then this package should have also been automatically enabled for debug.)
If so, there should have been a DEBUG message from locationsharinglib right before the error that contains the raw data from the server. Can you share that with me? You might want to send it via a private message in case it contains any sensitive data. If you no longer have the log containing this info, can you try the process again, and then share the cookie messages and the locationsharinglib messages?
I believe you said you created this account just for HA. How exactly did you create it? Did you do that in the same private browser window you then used to grab the cookies file? If not, then did you make sure to log out of that account on whatever system you created it before doing the procedure for grabbing the cookies file?
Also, what part of the world are you in? There is some indication that Google behaves differently in different places.
I am currently using two accounts with the integration – my personal account (which sees all the people who have shared their location with my account), and a “HA only” account (which only has my personal account shared with it.)
I compared the cookies that those two accounts have vs the cookies yours has. Before I talk about the similarities and differences, I’ll first say that I also see exactly the following for both of my accounts:
Saving cookies, changes: updated: __Secure-1PSIDCC, SIDCC, __Secure-3PSIDCC
All three accounts have these cookies in common:
APISID, HSID, NID, SAPISID, SEARCH_SAMESITE, SID, SIDCC, SSID, __Secure-1PAPISID, __Secure-1PSID, __Secure-1PSIDCC, __Secure-3PAPISID, __Secure-3PSID, __Secure-3PSIDCC
FWIW, __Secure-1PSID & __Secure-3PSID have been considered the important ones.
My two accounts each have a few cookies the other doesn’t. E.g., in addition to the common set, one has:
1P_JAR
whereas the other has:
__Secure-1PSIDTS, __Secure-3PSIDTS
Then I checked which cookies yours has that neither of mine has, which are:
AEC, AID, ANID, SNID, TAID, _ga, _ga_B7W0ZKZYDK, _gcl_au
EDIT: I should also say, my accounts do not have any cookies that yours doesn’t.
I’m not exactly sure what all this means, but it’s at least interesting.
Did you use, and exactly follow, one of the procedures my integration provides for obtaining the cookies file, or did you use some other method? And if the latter, can you explain what you did?
Thank you for this custom integration. The UI helped me configure my account. The problem I am facing is the dummy account I set up (lets call it Account B) shows up with a state UNKNOWN. I followed the steps outlined in the HA version: I created Account B and shared my personal account (lets call it Account A) location. I was under the impression Account A would be tracked via the integration but it doesn’t seem to be the case. Its worth noting, I do not have location tracking set up for Account B. Any idea what I am doing wrong? Thanks!
Edit: while I was successful at first, it appears the integration now keeps failing (after about 20 minutes or so), requiring reconfiguration via Cookies file. Not sure if this is related to my original issue or separate entirely.
So in your configuration, you should disable the “Account Tracker Entity” so that it does not try to create a device_tracker
entity for Account B since it is not associated with a device that reports location. It should still, however, create a device_tracker
entity for Account A, which has its location shared with Account B. (As you thought, it should get A’s location via B.) Do you see a tracker entity for Account A?
If you don’t see an entity for Account A, check in Google Maps for Account A and make sure it is sharing its location with Account B.
That sounds like the experience some people have. (E.g., see the posts just above with @dormani.) No-one quite seems to know why this happens. It certainly doesn’t seem to happen for most people, at least, not that I’m aware of.
I’ll ask you the same questions.
- What version of my google_maps custom integration are you using?
- Do you have debug enabled? If not, could you please enable debug?
- Can you share the exact ERROR message(s) from the log?
- Can you share the DEBUG messages about cookies?
- Can you share (privately if necessary), the
locationsharinglib
DEBUG message that immediately preceded the ERROR? - If you no longer have access to those messages, can you start over (i.e., grab a new cookies file) and capture them?
- What part of the world are you in?
- Exactly how did you create Account B? Did you log out of Account B, and close the browser you used, after creating it and before grabbing the cookies file?
- Exactly how did you grab the cookies file? Did you follow closely one of the procedures my integration describes?
Thanks! I didn’t see Account B at first but realized that my initial location share link was only for an hour. After updating it now appears.
My second problem appears to have been sorted. I followed your steps closely for cookies download and missed a few key steps (e.g. using private browser) on my first few passes.
Released 1.2.0b0 (beta)
Replace locationsharinglib, reorg code & other misc improvements
- Create replacement for locationsharinglib which more directly implements capabilities needed/used by integration.
- Migrate configuration entry from version 1 to 2.
- Add note to README.md about purging history of legacy trackers.
- Remove support for initial beta versions when it comes to how entities are restored.
- Write cookies & parsed data to log when invalid session indicated.
- When loading new cookies file, store in newly named file in
.storage/google_maps
instead of overwriting existing file. This makes code much cleaner. Existing file will be deleted when config is reloaded. - Reorganize code to simplify, creating new helpers & coordinator modules.
I’ve released this as a beta because it was quite a substantial change. Nevertheless, I’d really appreciate some usage & feedback so I can feel more confident in fully releasing the changes.
A quick word of warning: If you do upgrade, the configuration entries will be updated from version 1 to 2. This means you will not be able to “downgrade” back to 1.1.1 or earlier without first deleting the entries, and then adding them back after downgrading. Hopefully this should not be necessary.
If you’ve ever experienced the integration throwing the ERROR about invalid cookies or an invalid session, or with the built-in integration where it seems to just stop updating (until you restart, at which time you more than likely get the invalid cookies error), then this might interest you…
There still seems to be a bit of a mystery why this happens to some but not to others, which is not totally surprising because, like many HA integrations, it’s using an undocumented & unsupported API. But given some recent data, I might have an idea why, or at least when, it happens.
The basic approach of this integration is to re-use a “session” from a browser that has logged into Google by dumping its cookies. The HA integration then uses those cookies, effectively pretending to be the original browser session.
It seems for many (including myself), it doesn’t really matter which Google account or accounts is/are used with the HA integration, how it was, or they were, created, and exactly how the cookies (in one or more files) were obtained. It just seems to work (for at least a year or two before those cookies eventually expire, or with the recent changes to save updated cookies, maybe forever.)
For others, either the cookies never work, or more likely, they work for a while (maybe 20 minutes, maybe a few hours, maybe a few days), but eventually they just stop working.
The problem seems to start, at least for some, when the original browser session used to obtain the cookies continues to interact with Google, either relatively immediately, or maybe at a later time/date. The Google server will send updated cookies to both “copies” of the session, and those sessions will resend them back to the Google server with each requested update.
This doesn’t seem to be a problem for many but is for some.
I think the underlying problem is that the Google server sees two different responses (one from the browser, and the other from HA) to what it sees as, or should be, a unique login session. Maybe it sees this as some sort of “man in the middle” attack, and maybe it has different rules in different parts of the world. Whatever the reason, it seems to respond by “invalidating” the session, at least for the HA integration.
With this in mind, I wrote the procedures for obtaining the cookies purposely to use a “private” browser window. Private browser windows (I think) typically don’t save cookies after the window is closed. Therefore, the browser shouldn’t continue to attempt to use that same login session (which will now be used by HA), even if the browser is reopened afterwards.
To expand on those procedures, if you’re experiencing this problem, my recommendation is to make sure ALL sessions for the account or accounts used with HA are closed / signed-out, and all associated browsers are closed, BEFORE following the procedure for grabbing the cookies file in a private window. This probably means the only practical “account strategy” (for people experiencing this problem) is the one I called “Alt acct only”. Also, it may or may not be important to never relog into that account in a browser or other device (except if the cookies ever expire, I guess.)
Before continuing, you should probably delete the current Google Maps integration entries in HA.
To make sure all sessions are closed / signed-out, do the following:
- Go to Google Account in a private browser window.
- Log into the account used by HA.
- Go to Security → “Manage all device” (under “Your devices”). All currently signed in sessions (including the one you just started) should be listed. Click on, and sign-out of, all of those sessions. You won’t, of course, be able to sign-out of the current session (probably listed at the top) this way.
- Now sign-out of the current session (via the icon in the top-right part of the window), and close this private browser window.)
Now go ahead and grab a new cookies file and add the Google Maps integration entry to HA.
I’d appreciate any thoughts on this theory, and if anyone who has been experiencing the problem tries the above, please let me know how it works for you, good or bad. I could, of course, be totally wrong here, but
Released 1.2.0b1
Fixes a bug that causes entire server update to fail if one or more people are not currently sharing location data, or that location data is missing for some other reason.
Previously this just caused the associated tracker entity to not update, but all the remaining ones would update. The fix makes it work the way it did before in this case, including writing a DEBUG message to the log when it happens.
Released 1.2.0 per above
Released 1.3.0
Attributes address
& nickname
were already not recorded in the database. entity_picture
has a relatively large value and will almost never change, so add it to the list of attributes to not record.
I have just installed this integration.
I first used my google email address, did the cookie thing, and finished the process.
I went to the integrations page and my account was set up/
I then tried the same exact process for my wife’s phone using her gmail address.
In the integartion hers shows as unknown.
Does something need to be turned on from her phone. Or have I messed up a step in the process.
Thank you
Can you elaborate by what you mean by “in the integration”?
Normally, most people will try to use only one Google account with this integration.
E.g., you might use just your own Google account, and then have your wife share her location with you (which is done within the Google Maps app, not HA.) In this scenario, a device_tracker
entity will be created for your wife. And, if you checked the box to create a tracker for the “account holder”, then an entity will be created for you as well.
What is often better, though, is to create a new Google account that you add to this integration. Then both you and your wife would share your locations with that account. In this scenario tracker entities will be created for both of you (and you would not check the box to create a tracker for the “account holder.”)
Thank you for the quick response.
If I create another gmail account that both my wife and I can share, I will use that new gmail account in the integration using it’s cookies.txt file.
Then I need to share the new gmail account.
Is that basically it?
Thank you