Once you get the integration working, you should see device_tracker entities, one for you and one for your wife.
You should be able to see them by going to Settings → Devices & services → Google Maps. Under “Integration entries”, you should see the account you added, and under that it should have a link named “2 entities”. Click on that and it will list the device_tracker entities. You can click on them to see their “more info” window.
If you’re asking how to use device_tracker entities in HA, that’s kind of a HA 101 question. But basically, you’ll probably want to create Person entities for yourself and your wife. Go to Settings → People. There’s probably already an entry there for you. Click it. On the bottom of the window that pops up, you can select your tracker entity. Then click Update.
Now click the “+ ADD PERSON” button at the bottom-right of the page and create a person entity for your wife, selecting her tracker at the bottom.
Found it.
I needed to clear cache and then reboot before it saw the info.
Been using ha almost from the begining but there slight changes with every thing you do.
Again got it all working.
Thanks to you and the community for all the help.
Ok. Yeah, not sure why the integration page doesn’t always update when it should, but I’ve always found a simple refresh of the browser window solves the problem. You shouldn’t have had to clear the cache and reboot. But you got it working, so that’s what’s important.
Glad you got it working! Let me know if you need any more help with this integration or if you have any other questions about it.
Can’t we use both methods to get a tracker? I use your integration, but I also left the normal definition to have a tracker in the configuration.yaml file. I see the following message in my log.
I left in the legacy implementation so that simply installing this integration would not break a system. You’ll notice that is a warning, not an error.
However, until you change to the new configuration method, you’ll get absolutely no benefit from this custom integration. All the new features are only in the newer implementation.
I could have added newer YAML configuration support (e.g., allow it to be configured under a “google_maps” key), but that is a LOT of extra work, so I decided not to bother. I have that kind of support in most of my other custom integrations, so I know how much extra work is involved.
If you do use the new UI based config, and still leave the legacy YAML config in, that is ok. You’ll get two sets of entities. It does give you an opportunity to test out the new implementation (via the new entities), and slowly convert your system over at your leisure, should you decide to do so. If not, just delete the UI integration entries, uninstall the custom integration, and you system is just as it was before.
I’m only aware of that standard card. I’m not into the frontend that much, but I wouldn’t be surprised if there was a way to get a Google Maps window in HA. I can’t help you with that. I’d suggest searching other topics or opening a new one to ask for help.
To be clear, this topic is about a custom integration (that enhances the standard, built-in integration) that gets location information from Google and creates device_tracker entities based on that information. This is not about using Google Maps in any other way.
Ok, i understand.
So i tried to use the integration and it works for about half an hour, then the entity is not available anymore.
It has something to do with the local cookies i guess.
There is a race condition that in some instances can cause the entities for one or more of the Google accounts added to (aka, registered with) the Google Maps integration to not get created after a restart. This is due to some “temporary” code that was added to the device_tracker component level code over two years ago that was supposed to be removed after the 2022.6 release but never was.
This release attempts to work around that problematic code.
Also, when a replacement for locationsharinglib was added, that package was removed from the requirements for this integration (meaning that if it wasn’t already installed on your system, and then you tried to use the legacy part of this Google Maps integration, you’d get an error.) This release also adds that requirement back in in case the legacy implementation is used.
Note that after a restart, the Google Maps integration page might not show the devices. But a browser refresh should make them appear again. This is a frontend issue, not an integration issue.
Add an “online” binary sensor and make device_tracker entities always available, retaining their previous state, even when server dropouts occur.
This effectively moves the “server unavailable” status to an “out of band” signal. The way it was (i.e., “in band”), although the way the core team seems to think entities should work, makes the entities more difficult to use in automations, etc. Users often have to create template sensors and/or complicated conditions to ignore the “unavailable” state of these entities. This change makes them much easier to use, but still provides the server status, in case that is desired or necessary.
Also, remove previous work arounds for avoiding the race condition that caused entities to not appear. Adding the binary sensor is actually a better workaround. And the old device tracker component code has been removed, and the bug that caused the race condition has been fixed, with both of these changes being slated for the 2024.4 release. The fix for the race condition made the 2024.4 release. The other will probably hit the 2024.5 release.
Breaking Change
This is considered a breaking change since some automations, etc. may take certain steps when the Google Maps server becomes unavailable. This is still possible but will require using the new binary sensor instead.
UPDATE
Turns out, adding the binary sensor, although a good idea in itself, does not actually fix the original problem, since it’s not linked to the device(s) that get deleted. I guess I’ll put the work around back in.