FWIW, the person component hasn’t changed since late February.
Sounds like maybe the person entity isn’t actually configured to take input from the owntracks tracker. You might want to check your person configuration(s.)
Both of my persons are showing their respective bt tracker entities and owntracks entities. (1 of each for each person.)
Is there something else I should check? Somewhere else I should be looking?
When a person is in one of the zones (other than Home), what do the owntracks’ and BT tracker’s states look like, and what does the person’s state look like (e.g., from the States page)?
And actually, it looks like the last_updated field is what’s really important. So it might be good to look at the following in the Template editor at that time:
{{ states.device_tracker.OWNTRACKS }}
{{ states.device_tracker.BT }}
{{ states.person.PERSON }}
Of course change the capitalized parts to the appropriate values. Feel free to share the info here (redact any sensitive data.)
So right now… my wife is at work and the states are as follows:
device_tracker.[wife.owntracks] - Work
device_tracker.[wife.bt] - not_home
person.[wife] - not_home
In the person.[wife] attributes… it shows that the person.[wife] “source” is her BT tracker. (I guess whatever was last updated… which doesn’t make sense because the BT tracker should last update when she left home, and Owntracks updated approximately 30 minutes later when she got to work (and the Owntracks entity is showing the correct zone name and all.)
Edit: Something else to note. I just removed the BT tracker from her “person” and left owntracks there and updated her person. Now… the state of her person is showing as “unknown” even though the OwnTracks entity still shows “Work”.
When I asked for the “states”, I meant the whole state, including the attributes.
Yes, the person component uses last_updated, but it prioritizes. If a non-GPS tracker is home, that takes precedence over other trackers. If no non-GPS tracker is home, then GPS trackers are supposed to take precedence over non-GPS trackers (regardless of their last_update values.) At least that’s roughly how I read the code.
It would be very helpful to see the data I asked for from the Template editor. (You can PM me the data if you prefer not to post it publicly, or just redact/delete the sensitive data.)
What exactly do you mean by that? With the BT tracker removed, I’d wait and see what happens when you know the Owntracks tracker updated.
updated the person by Configuration -> Person then removed her bt tracker and clicked “update”. Restarted HA and then checked the states again. (Will the template stuff later tonight. I’ll let her drive home and let the trackers, update etc.) Thanks for your help!
Ah, ok, gotcha. I thought maybe you tried to use the homeassistant.update_entity service or something. 
Yeah, seems like it’s not seeing the owntracks entity correctly. Data from the template editor will hopefully help.
1 Like
BTW, you don’t seem to be alone in experiencing this issue…
I saw that this morning and I don’t feel nearly so alone. LOL
Odd thing is… it looks like mine is working as it should this morning. (And I’m still on 0.94.1.)
As a test I reinstalled Owntracks on my phone and configured HA to use it, and created a Person entity that references it. Seems to work for me for now. (I’m on 0.94.2 in this test setup.)
So I think I understand how the Person entity’s state can be unknown when one of its “input” trackers (or its only input tracker) is owntracks. I just did a test and discovered Person changing temporarily to unknown. In this particular test I didn’t see it in the UI because it was only in that state for less than 0.2 sec. I did however see it in the logs.
I made it happen by forcing an update from the Owntracks app. There were actually two updates in HA, where the first had the owntracks device_tracker entity’s source_type attribute set to None, followed almost immediately (less than 0.2 sec later) by another update where source_type was set to gps.
I then looked at the debug messages from homeassistant.components.owntracks.messages and found this:
$ grep -F homeassistant.components.owntracks.messages home-assistant.log
2019-06-12 09:10:40 DEBUG (MainThread) [homeassistant.components.owntracks.messages] Received {'_type': 'location', 'acc': 14, 'alt': 149, 'batt': 97, 'conn': 'w', 'lat': xxx, 'lon': xxx, 'tid': 'pb', 'tst': 1560348597, 'vac': 2, 'vel': 0, 'topic': 'owntracks/xxx/xxx'}
2019-06-12 09:10:40 DEBUG (MainThread) [homeassistant.components.owntracks.messages] Received {'_type': 'location', 'acc': 14, 'alt': 149, 'batt': 97, 'conn': 'w', 'lat': xxx, 'lon': xxx, 't': 'u', 'tid': 'pb', 'tst': 1560348597, 'vac': 2, 'vel': 0, 'topic': 'owntracks/xxx/xxx'}
They look almost identical, but if you look closely you’ll see the second has 't': 'u' whereas the first does not. Turns out, this 't' value is used to determine the source_type. If the value is 'c' or 'u', then it sets source_type to gps, but if it’s missing (like it is in the first message) then source_type is set to None.
It seems that sometimes owntracks is not setting the source_type correctly. (In this case it wasn’t noticeable, but apparently there are plenty of cases where it is noticeable.)
So that probably needs to be looked into on its own. But, this is how it affects the person component…
The logic in the person component, when looking at all its “input” trackers seems to have a flaw. If the source_type is gps, then that takes precedence. But if the source_type is not gps, then its only used if the state is home or not_home – i.e., it’s not in a zone. To be clear, if the source_type is not gps and the state is the name of a zone (i.e., not home or not_home), then the state is ignored!
I would classify this as a bug. I think I’ll open a pull request to fix this…
1 Like
The devil seems to be in the details!
Great detective work! Thanks!
Looks like an issue has already been opened for owntracks reporting the wrong source_type. See Issue #24496.
Regarding the logic in the person component, now I’m not actually sure what should be done, if anything. Seems the bottom line is it’s counting on GPS-based trackers to properly set their source_type to gps. Hmm…
1 Like
When relying on outside forces… there’s always going to be that weak link… so I’m not exactly sure what should be done, if anything, in that case…
Personally I don’t use the person component. I think the logic is wrong. I have a custom component I wrote (before the person component was a twinkling in someone’s eye 
) that I (and many others) use to combine multiple trackers per person. It’s my composite tracker. You might want to give it a look-see.
EDIT: Of course, it’s probably vulnerable to the same issue – i.e., a GPS-based tracker that does not correctly set its source_type attribute. GIGO! 
That’s great, thanks! It might just be the thing I’m looking for!
Just chiming in that I’m seeing the same thing right now.
I believe I have fixed the problem. See PR #24503.
PR was approved & merged, and looks like it’s targeted to be in the 0.94.3 release.
Just installed 0.94.3 and I think you nailed it!
It’s been 30-ish minutes and usually by now the wife’s person drops the zone name and goes either to away or unknown… but so far it’s holding steady at “Work” at the moment. I’ll keep an eye on it throughout the day to confirm.
1 Like