In my opinion, you have to consider privacy laws across international law with this topic.
Sure…
But if I can access where my earbuds are using their app then it’s a smal difference from getting the same via an API.
Because their app uses and API anyways so essentially it’s the same.
The info shared via the API is controlled all the time so it’s not actually the same.
There are different levels of access.
It would be great if something like this (FindMySync - Martin Pham) could exist for Google’s tracking network
Yeah… that is what this feature req… Oh sorry configuration post is about.
1 Like
I’m agreeing with you and showing an example of how this is achieved for Apple’s tracking network.
I’m not deeply invested how exactly it works and how precise and how far the signal carries etc but I’m wondering if it would be possible to use it as a cheap man’s semi-accurate pet GPS tracker? At least Motorola seems to even mention pet tracking as an example. Would be nice in that case to put the tracker into a map card in HA and have the ability to check whereabouts. That, if it would work (provided Google releases an API to make it possible), would be a highly worthy use case imo (cat owners cough). I already use Tractive for this purpose but as much as I enjoy having it, it can bug out sometimes with the live tracking and GPS tracking eats so much battery so constant recharging is a neccessity on top of the monthly fee, this would be a nice alternative (backup perhaps or even alternative depending how precise/reliable system you crave)
That’s not, how these things work. 
The FMDN is based on Bluetooth, so if there are no Android phones nearby, it won’t work.
The idea is as simple as genius. The BT signals from devices like headphones or tags are located by nearby phones and send to Google. If you’re missing your device, you open the FMD app on your phone and ask Google, if there are any devices/phones that right now have a BT signal from eg. your headphones. If so, the location will be shared with you.
Simple and effective, but needs to have other Android phones around. So this might work inner city, where a lot of Android devices can receive that BT signal, but if you’re out in the countryside, it might look a little different.
A GPS tracker like tractive is calculating its position by itself and sends this location data via GSM to wherever you want. With pets, chances are high, that no Android device is around, especially when they ran away.
And this is only the part, where we talk about the connection. If you go deeper into the FMDN, you’ll see, that tracking your devices (headphones, tags) is regelemented by Google in some very specific ways, which makes it nearly impossible to track a device constantly. This is because this technique is built by keeping in mind, that tracking is not part of the job description - finding something when its lost is. These are two totally different things.
Unfortunately the OP hadn’t made the effort to look up how this is working, that’s why the feature request ended up being moved to configuration…
If you’re interested in a less expenisve tracker than tractive and you’re in D/A/CH, you might want to take a look at the Fressnapf tracker. Way cheaper, but works as good as tractive. The main difference between tractive and Fressnapf is, tractive can be used around the globe (aka tracking eg. in the US) where Fressnapf can only be used in Europe.
Yes that’s precisely how I expected to work, don’t get me wrong. I wouldn’t expect it to 100% replace something like Tractive why I wrote “cheap man’s semi-accurate pet GPS tracker” in the sense you might get position updates, you might not or you might be able to get an update every once in a while about the whereabouts which is still better than not having anything at all in those cases the pet would have ventured away further than usual. This of course depends where you live obviously, rural areas you can forget about it but I live in a smaller, not so busy town in the outskirts with plenty of neighbours and houses nearby. I mean if Tractive does the job 95% (with those occasional service malfunctions) and this would only do the job like 20-30% then that’s still better than 0% not having any tracking device at all, at a fraction of the cost. Probably there’s some limits in how often you could activate/ping for location information so not sure if it would be possible to have it update location on a map card everytime the device is in close proximity to some android device (or limited to max once every hr for example) but to me if that’s possible would be very useful use case already (if only because I’m a HA geek 
).
The tracking devices are usually cheap but the monthly fee quickly adds up cost so that’s where the charm of a cheap 39€ (Motorola Moto Tag for example with UWB sensor and range up to 100m that is pretty much the same shape of Apple AirTags so instantly compatible with lots of products, collars in this case) and no monthly fees with occasional ability to recieve positional updates would seem like a fair deal to me in this case especially since the battery lasts a long time compared to using GPS tracking.
I hear you, and if you want something, where you know before, that it’s not the best solution, that’s fine! It’s more about an informed decission. If you’re good to go with that level of reliability, that’s fine!
But don’t overestimate this. Google put these restrictions in place, to avoid people tracking other people, aka stalking. And that’s why this system is not really reliable for tracking, you just won’t know, when the tracker works. If your “quota” was exceeded, you might not get an updated location for hours…
Anyway, I can see your point, but what I really don’t see for now, how this would be useful in HA. It still seems to be something, that is more useful in an app, where the receiving end can move with the device.
The thing is, to make something like this work in HA, you’d need a good use case, that fits the goals of HA, and I really doubt, that this is one of them. Only the mentioning of stalking is something, nobody wants to be associated with.
And to be fair, Google would need to play along, what I doubt as well. They will set some boundaries on how often you’re allowed to ping or search for a device, and if that’s to often, they will block further execution.
All this, and I can see why nobody wants to get their hands dirty with this. It is a lot of work, Google will likely try to limit you as developer and it is not really a function, one needs in HA. Issues and support questions will likely be a nightmare, as a lot of people will ask “why does this not work like this”, “why is my tracking off for hours” and such.
So in the end, I personally think, this FMDN is quite overrated, especially it is not sold under the correct name. It will not be a reliable tracker, it will be much more like these old keychain beepers, that reacted if you whistle…
As I said, it’s not that I would be against it, I just don’t see any real use case, that fits specifically for HA. I can see use cases, that are already well taken care of, eg. an app.
I agree that a FMDN integration wouldn’t be as strikingly useful as, say, the Google Maps integration[1] but I do think it’s within scope of HA, for example to be able to track a vehicle or child who doesn’t own a phone (within the limitations of the system - although from what I see Apple Tag users are very happy with the performance of that network).
I’m currently trying to emulate this using beacons and the HA app[2], but would happily replace that set up with an FMDN tag and native support.
[1] Google Maps - Home Assistant
[2] Device tracker for BT devices?
2 Likes
I have some Chippolo One Points so I’ve been having a look with a BLE scanner on my phone. This one is paired with Google Find My Device.
It looks like the MAC address is randomised.
The first seven bytes of the advertised packet seem to not change when the MAC does.
There’s also Service data section (I’m not sure if this is simply taken from the advertised packet - don’t know much about BLE - the [string of random hex] appears to be the eighth and above byte from the packet though) which looks like:
0000feaa-0000-1000-8000-[something which looks like a MAC address]:0x[string of random hex]
I haven’t yet checked another tag, but I’m thinking that [something which looks like a MAC address] - or maybe that entire string before the colon - is likely unique to the device. It certainly isn’t changing when the advertised MAC does.
I’ll check another tag to make sure these findings are accurate.
edit OK, it’s looks like that ID is something to do with Eddystone beacons. So I guess that’s what the platform is built on. There’s some reading here (using an API which doesn’t appear to exist any more): Introduction to Google Eddystone. Bluetooth beacons are transmitters that… | by David González | Medium
And this question has some stuff about the Eddystone format and decoding packets: android - How to identify Eddystone URL and uid? - Stack Overflow
1 Like
I’m glad there are more people interested in integrating Google’s Find My Device network with Home Assistant.
Personally I would be happy with detecting the tags’ proximity via Bluetooth, but their privacy feature that randomises their MAC address makes it a challenge: