I upgraded to 0.94.3 this morning. When I go to integrations and click on OwnTracks, it says “This integration has no devices.” Prior to 0.94.3 I could see everyone in “States”. Now there is no one listed in “States”. (I’m no longer using “known_devices.yaml” as per the previous instructions.)
Also: When I updated to 0.94, all the OwnTrack devices showed “Away” and their status’ did not update. Hence the reason I started following this post.
When did you delete known_devices.yaml (or at least remove the owntracks devices from it)?
If you upgraded to 0.94, but left known_devices.yaml as it was (i.e., the owntracks devices still in there), then the corresponding device_tracker entities would still show on the States page, and you’d still see them in the UI, even if the owntracks configuration was incorrect (and, hence, not working anymore.) That would explain why you still saw them, but they were always “Away.”
FWIW, the change in 0.94.3 would have nothing to do with what you’re seeing. It was literally a one line change that just made sure the source_type was always ‘gps’ when it should be.
It sounds to me like your owntracks configuration got lost or not updated correctly when you first upgraded to 0.94.x. Sounds like you just need to go to the Integrations page and add it again (and update the urls in your phones accordingly.)
Sorry, I’m not an owntracks “expert.” I just got involved fixing the issue mentioned in this topic (and similar ones.) I have no idea why your owntracks configuration might have gotten lost/corrupted.
The 0.94 release stated, " These integrations will no longer use
known_devices.yaml but instead use entities, like all other integrations in Home Assistant." So I removed it (after backing it up first) with the 0.94.2 release.
As I pointed out, you can’t do anything with the integrations because Owntracks says, “This integration has no devices.” . . . .
Deleting known_devices.yaml should not be a problem (assuming, of course, you’re not using any other “legacy” device_tracker platforms that do still use known_devices.yaml.)
Do you have devices (phones) configured with the correct Host URL (i.e., the webhook you would have originally been given when you first set up owntracks)? If so, what happens if you open Owntracks on one of those devices and click the manual update button (then refresh the OwnTracks integration page in HA)? Does the device appear?
I just tried an experiment where I stopped HA, removed my device from
<config>/.storage, then restarted HA. When I went to the OwnTracks integration page in HA, it said no devices. But then I clicked the manual update button on my phone, then refreshed the OwnTracks integration page in HA, and the device appeared.
If you can’t get that to work, then you may just need to delete the OwnTracks integration from HA, add it again, and update the Host URL setting in your phones with the new webhook URL.
I tried to go with the last option - delete the integration from HA. I emphasize that “I tried” because after deleting the configuration.yaml references including the zone information, and restarting HA - is still says the same thing!
There won’t be any devices listed until one of the devices, using the corresponding webhook, actually sends an update. Did you change the Host URL in one of your devices and force it to send an update?
One device I did, the others I didn’t. The ones that didn’t change - I clicked “Update” but there was no change in state in HA.
None of the devices are listed anymore in States or anywhere else in HA.
So every time you add the OwnTracks integration (e.g., after deleting it) it will generate a new webhook. You have to make sure all the devices have their Host URL updated with this new webhook. And then once they send an update (either manually or automatically) the device should be listed on the Integration page, and the device_tracker entities should be created (and visible in HA, e.g., on the States page.)
So, it’s not unexpected that the devices for which you did not update the Host URL were ignored by HA, even when you manually forced an update.
One other point. If you have
owntracks: in your configuration file(s), that will add the OwnTracks integration (if it didn’t already exist.) So, in that case, you’d want to go to the OwnTracks integration page, delete it, and then re-add it. This will then show the new webhook to enter into your devices. (Note that the integration created from the
owntracks: configuration entry also created a webhook, but it’s not visible anywhere. That’s why you’d want to delete it and then add a new one via the UI.)
I’m not arguing this is the way it should work. I’m just trying to explain how it does work to help you get it working again. (I didn’t create this integration, I just fixed a bug recently in it. But in the process I learned a little about it. )
Your advice worked and we’re back in business. (I didn’t think to click on the trashcan icon in the integration to delete it.)
I’ve been seeing the same issue and instead of person am now using device tracker from owntracks integration page.
So the picture file that used to be referenced in knowndevices.yaml is gone.
Now all I have is the first initial again.
Where do we re-add the picture of the person being tracked?
You need to add it to the customize: section under the homeassistant: section. It’s the same way you’d do it for all other entities now.
You can also do it via the UI. Go go Configuration -> Customization, select the owntracks entity you want to set a picture for, click “Pick an attribute to override” at the bottom, pick Other, enter
entity_picture for Attribute name, and fill in the Attribute value, then click SAVE.
I used the mqtt owntracks with a script to request the device locations (background), so it was not necessary to have the owntracks application open. After updating Home Assistant to version 0.94, I can only update the device locations when the owntracks application is running. How do I keep updating locations even when the owntrack application is not running?
Is it also possible to re-add the picture using gravatar reference like used to in know_devices.yaml? Is there a special syntax to it?
If you follow the instructions I provided a few posts up, you can enter what you want for the picture. I’ve had success with
/local/me.jpg as well as an URL to a picture, e.g., on Life360. Not sure what “gravatar” you had before, but whatever you had after
known_devices.yaml (I would think) should work for the value of the
I did follow the instructions and I too have had success with local pictures, just double checked now and realized that
gravatar: actually had its own reference in
known_devices.yaml and was not used after
picture:, sorry about that, maybe that’s the reason
edit: and I just have found out that using
entity_picture and full path (link) to gravatar works,
known_devices.yaml uses short syntax
gravatar: email.address only
Ah, I see. I never used gravatar, but now that you point it out, I do recall it was an option. I just looked at the device_tracker component code, and I only see gravatar used for “legacy” trackers. I guess it’s not an option anymore for entity based trackers. (I don’t see it mentioned here.) Unless it’s something you can do in lovelace???
EDIT: Or, I suppose, you could use this code to get the URL:
And then use that for
EDIT 2: I just tried it and it seems to work.
Thats exactly what I did
entity_picture with URL reference. I found that it was used in the former device tracker entity so I just gave it a try and it worked
Phil (@pnbruckner) , wanted to say thanks for your post on Jun 13 – it was the first time I’d seen any specific info on getting the OwnTracks integration working from the configuration menu (honestly I would not have thought of deleting it).
FWIW, I’ll take a moment to share two OwnTracks-related thoughts here as I start to work with it:
I’m intrigued that the Android app reports address location, but the HTTP API only provides lat/long. Not sure where the constraint is that prevents sending reverse-geocoded location back to the HA server. Also curious why no timestamp data are sent either – but then at least the last_updated and last_changed entity fields are proxies.
In looking for a way to handle geocoding lookup, I landed on Mapquest’s developer API, which offers 15,000 free lookups per month, which in my case works out to queries for 3 devices about every 10 minutes. It took 5 minutes to get working, including signing up.