Hi, thanks for the reply, i also try changing to lowercase but still not able to get that sensor into HA, also using notepad++ to format the code but still can’t seem to get it into HA.
This is the error message in the system logs:
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:356
integration: Sensor (documentation, issues)
First occurred: 2:27:39 PM (1 occurrences)
Last logged: 2:27:39 PM
I just realized that you are using the older version of the code, is that right? Have you tried the new guide?
Hi, thanks for the update, can you post the link to the new code please?
i found the new version but still having issues in getting HA to see the sensor, when i add the code in the sensor,yaml & configuration.yaml restart HA, the sensor does not exist.
I am not sure what to tell you 
Did you just create sensors.yaml? Or was It already working?
I have the same problem, the airtag sensor does not exist.
I can’t get it to work.
Having the same issue with the new code also, not sure why HA is not seeing the new Sensor, but i follow the instructions and also test the code for errors, but still not able to get this sensor expose.
- Did you have sensors.yaml file already working? or did you just create it? If this is your case check you did it right
- Have you ever use rest platform to make new sensors? If this is your first time you have to restart Home Assistant completely. Also, you can try to go into Developers tools > YAML and click on “Rest entities”
- I am sorry, but if you dont share your code i can’t help any further
I try adding the code in sensor.yaml & try the configuration.yaml no difference in the results.
I am seeing the text.airtag helper data from the shortcut but just can link this to the sensor because the sensor is not expose in HA
Hi Tito,
Yes i have alot of code in my configuration.yaml file which are all working, when i add the code into configuration.yaml i dont get any synax error from the code so i know it is compile property, this is the first time that i am using a rest sensor.
- platform: rest
name: airtag_backpack
value_template: "{{ value_json.results[0].formatted }}"
json_attributes_path: "$.results[0]"
json_attributes:
- lon
- lat
verify_ssl: true
scan_interval: 900 # every 15 min
force_update: true
resource_template: >
{% set address = states('input_text.airtag').split('backpack')[1].split('•')[0] %}
{% if address == "Home" %}
{% set home = "Ingham Close, Turks & Caicos Islands" %}
{{
"https://api.geoapify.com/v1/geocode/search?text="
+ home | urlencode
+ "&apiKey=aaf82a47336a41a0bb93a2c6ae372c56&format=json"
}}
{% else %}
{% set fix = address + "Providenciales, Turks & Caicos Islands" %}
{{
"https://api.geoapify.com/v1/geocode/search?text="
+ fix | urlencode
+ "&apiKey=aaf82a47336a41a0bb93a2c6ae372c56&format=json"
}}
{% endif %}
- platform: template
sensors:
airtag_backpack:
friendly_name: "backpack"
value_template: >
{% set home = "Ingham Close, Turks & Caicos Islands" %}
{% if ":" in states('input_text.airtag').split('backpack')[1].split('•')[0] %}
{{ states('input_text.airtag').split('backpack')[1].split('•')[0].split(',')[0] }}
{% elif home in states('input_text.airtag').split('backpack')[1].split('•')[0] %}Home
{% else %}
{{ states('sensor.airtag_backpack') }}
{% endif %}
attribute_templates:
latitude: >
{% if ":" in states('input_text.airtag').split('backpack')[1].split('•')[0] %}null
{% else %}{{ state_attr('sensor.airtag_backpack','lat') }}
{% endif %}
longitude: >
{% if ":" in states('input_text.airtag').split('backpack')[1].split('•')[0] %}null
{% else %}{{ state_attr('sensor.airtag_backpack','lon') }}
{% endif %}
status: >
{% if ":" in states('input_text.airtag').split('backpack')[1].split('•')[0] %}unavailable
{% else %}available
{% endif %}
last_update: "{{ as_timestamp(states.input_text.airtag.last_updated)|timestamp_custom ('%d/%m/%Y %H:%Mh') }}"
icon_template: mdi:bag-personal
You are giving the same name to both sensors. Try using my suggestions in the guide.
Thanks for this great solution!
I followed your guide and it was pretty straight forward. The only thing is that your guide mentions sensors.yaml. But I didn’t have that, so just added it to configuration.yaml. For some reason, the geo sensors were not being created at first, but after a while it all started working.
I have an iPhone with iOS17 just for this purpose. I have the shortcut run every 6 minutes by looking if a new mail has arrived. I send a mail to a dedicated email address that i use on the iPhone from Home Assistant every 6 minutes. Works like a charm.
2 Likes
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.