I’ve recently come to identify the following situation - not sure if I’ve got it straight or not.
I have a person (lets call him Brody) who has the HA companion app on his phone (reporting his location - geo-coded etc). In addition, my wifi router knows about him (so it can tell me if he is away or home) .
Originally Brody was just a guest so I only had the router/cell device tracker to identify if he was in my house or not. All was good.
Recently he started house sitting in my absence so I gave him the app. I added this tracker to his profile. All continued to work.
I decided to create a new zone around my home called “near_home” so I could do fancy things like turn the heat on in advance of him arriving home. Here is where I started to notice the problem. Using a zone trigger, i could see person.name entities for everyone who has the app - except for Brody.
Everything looked fine for Brody otherwise - and person.Brody existed in the entity table - but it wasn’t geo-located. Clicking on him did show his location on a map, so I knew the geo-location from the app was working - but I couldn’t access it in an automation. According to the state table the geo-location information was not an attribute for him.
The only difference between Brody and other app users was that the other app users had the app as the first location entity and their cell phone (wifi router) entity second. I removed both trackers from Brody and re-entered them putting the app first - and everything works fine!
So - it appears that home assistant puts a lot more emphasis on the first listed (or entered) tracking entity. I couldn’t find any references to this in the documentation (but then the documentation is so vast it’s pretty easy to miss parts of it
Do I have this right? Any other implications that I am missing?
I did read this - however it doesn’t (to my limited way of thinking) seem to explain why the order does seem to matter though. As per my original post, when I changed the order of the trackers, then person.brody shows up as an entity in my automations. Just to make sure it wasn’t a fluke - I just changed it back, putting the cell/wifi tracker first, and once again person.brody has disappeared as a choice in the entity lookup. Changed the order again - putting the app first and cell/wifi second and person.brody shows up once again in the entity dropdown lookup.
I configured Brody using the visual interface. I’ve never been able to find the yaml file that contained the person entities (I thought it was config.yaml but apparently not) - can you point me to the right file please?
I’ve been continuing to experiment with this more as well. What I find is that I only see the order having an impact when I try to select people.brody from a drop down in the visual editor when I’m using a zone trigger (where it either is or is not an available choice).
However, regardless of the order, I can only get lat/long attributes in the state table (which I assume is necessary for determining what zone a person is in) if the cell/wifi tracker is removed from the person profile completely - which I think is what the “Person” documentation alludes to - and I assume the lat long becomes an available attribute once brody leaves the stationary tracker of my router. However, I can’t configure person.brody in my automation unless the app tracker is first. I could do it in yaml though so perhaps this is something in the visual editor (hate to use the word ‘bug’ when it’s probably an error caused between the keyboard and the chair)
I almost never use the UI for most things so I won’t really be of any help much more than this.
But yes if the device_tracker that the person is based on is local (local router presence will take first priority unless it’s not_home) then the person shouldn’t have any lat & long info.
