Thanks John!! I m glad you have It working!!!
Now that I have it running a few days, I do see some strange behaviour. For my usecase its not a major issue, but wondering if you also see this happening. Most of the locations are very accurate, but every now and then I will see a device in another city. It will then show for example “The Hague, ZH, Netherlands” as location, while the device is in Almere.
Is this something you also experience? And is this then due to geoapify, or something with HA? (from this picture, it becomes clear, I have not left Almere in the past 3 days)
I think I have found the answer myself by looking at the logs…
When it was returning The Hague, the query string was STREETNAMEAlmere The Netherlands. So the streetname was merged with Almere.
So i changed this:
{% set fix = address + "Almere The Netherlands" %}
Changed to :
{% set fix = address + " Almere, The Netherlands" %}
I think this will fix this issue
1 Like
That’s because there are some flaws in this implementation. The main reason is that the device information obtained through the ios OCR is not complete (usually it does not contain the country/province),
However, there is a scenario, for example, in a country there are likely to be more than one address street will be called “Washington Street”, when we initiate api request to get geo lat_lon information, the same address may appear in a country in more than one place.
So this is the case.
2 Likes
I noticed that. I guess this is the best we can do for now. Until Apple actually adds the airtags to the browser version of Find My. With the Apple Icloud integration, I do see the iPhone, but not the airtags.
I do realize why I really dislike Apple devices :). I just bought this iPhone because the coverage of the airtags is far superior to any Android solution. But the ecosystem of Apple is so locked down.
There is actually a more optimized solution that I’ve been trying successfully and running for 2 months. It is realized as follows.
1> When OCR extracts the address of the target device, in the text content of the entity airtag_input, there may be many addresses, for example, addr.1,addr.2,addr.3… .addr.N
2> We can first parse out the middle 3 addresses by python script.
3> launch api geo request to these 3 addresses separately, then get their city/province/country addresses, if two of them have the same city/province/country, such as [city1][province1][country1], then I can assume that the address of my target device should also be within this general range.
4>Then, we again use python code to string splice the [city1][province1][country1] address with the address of the target device to get an up-to-date and complete address. It should be in the following format, [your_target_device_street_no.xx][city1][province1][country1]
5> Finally, based on this spliced address, launch another API geo request to get the most accurate lat_lon coordinate information.
However, this solution consumes more api tokens, and is currently the better solution in my 5 devices.
1 Like
Hi everyone,
First of all: I am using an iphone set to German.
Even though I had it working a while ago, it does not reliably work.
Yesterday I started from scratch and used the latest version (from post #1).
What I found was, that the adress is found in geoapify correctly (correct lat / lon in the json response) when I run geoapify with my home address in the url. Furthermore the postcode, housenumber and street fit perfectly.
However, my ITEM_geo entity just shows lat / lon with xx.xx - so just two decimal places.
This geo location is quite a bit south obviously (checking on google maps).
Additionally the other entity showing the adress is then also off, but not in the spot like the coordinates, but a street close by (going east).
I am still investigating, but wonder how to avoid low accuracy with rounded lat / lon values.
Interesting approach! I just wonder, how would you manage It for example if your are travelling and one of your airtags is in your luggage and the others are at home? Would It give you false matches? Thanks!
I ll keep It in mind for next version!
Thank you!
Does this mean the lat / lon are rounded?
Not by me, this is how we get It by default. But maybe we can get more decimals some how
1 Like
I did a bit of a fix that works well for me. For the devices that are normally with me (car and keys) I use the following line in the sensor configuration.
{% set fix = address + " " + states.sensor.pocof3miui14_geocoded_location.attributes.locality + " " + states.sensor.pocof3miui14_geocoded_location.attributes.country %}
What this does is that it takes the City (locality) and the Country of my phone in the call to Geoapify. This works quite nice as the city and country are more often correct now as my keys and car are mostly in the same city as I am.
The device that is normally around home I just use the original line.
1 Like
Hi, TitoTB,
Your question is a very good one, in fact, this solution I provided is still not perfect and can’t fully cover all the usage scenarios.
Since I don’t have frequent business trips or overseas travel plans these days, I haven’t done a more comprehensive test yet.
But I still think there are a lot of optimizations to be made, such as
1> You can group multiple devices, for example, which devices are often left at home, which devices are often active and mobile. Then based on the grouping, make some logical conditional restrictions in the python code.
2> There is another possibility to do some optimization for iOS automation process. For example, do a focus action on each device before OCR recognition on iOS devices, and do OCR text extraction for each device individually, but this automated action may be more complicated. I’m still trying to do this for now.
If you have a better solution, feel free to discuss it together, in short. I think this is a good project.
1 Like
Means, in HA the REST implementation cuts off the other decimal values after 2 digits?
That does make sense for temperatures, but not for GPS cooordinates.
Is this something we could change / define in the REST entity definition?
EDIT:
Sorry - my bad:
I did not recognize, that the real number of digits after the decimal point is correct in developer tools
1 Like
The rest implementation uses the full coords. I have 7 decimals in both sensor.airtag_backpack and sensor.airtag_backpack_geo
I think the issue of 2 decimals is unrelated to this solution, perhaps this is somthing:
Latitude and longitude have 2 decimal signs precision - Configuration - Home Assistant Community (home-assistant.io)
1 Like
This is really interesting, can you share the code? I would like to see if I can then combine it with the other solution i added ( AirTag "integration" (user friendly + device tracker) - #126 by john2014 )
Another issue I have is, that I have 6 Airtags and just see three in the object screens.
If you follow the tipp in the documention and swipe the list upwards, the shortcut will capture all 6 Airtags in a screenshot, but the OCR fails.
Means, the input_test.airtag is Unknown
Anyone successfully uses the swiped up view?
I had an issue with OCR and added a CROP step to only get the part of the screenshot with the items. This might also work for your usecase. It is a bit of trial and error to do, but if you crop the screenshot to just the text with the items, it works very well.
The way I did it:
- Create a screenshot and download it to a pc
- With a graphics program, see the starting coordinate and width and height of the image you want.
- Add this CROP step to the shortcut (make sure it is taking the screenshot as input)
In HA I would then check the value of input_test.airtag to see if it was working. Afaik you can not see what is actually cropped.
Update: After the CROP you can also use Save to recents to store the cropped image in Recents. That way you can see what is cropped.
2 Likes
Yep, i agree with you. I think this is the base, but it could/should be modified with your personal circumstances.
I have been also playing triying to focus on every device with gestures, but i didn’t find the right way to do it. How are you triying to achieve this?
Thanks!
As i said, the coordinates are not rounded int the code. It is just the way we get the information 
Can we get more information? Maybe, it is something to dig in