Device not marked as away based on iOS HA outdated GPS position

I have a problem with mobile devices, the ones running the iOS HA app, latest version.

The setup is a bit custom.

They run the app with background app refresh and location always enabled. So that’s good. But there is not always a connection with the server. This depends on whether or not the user has the VPN enabled. Inside home there always is connection with the server. I have the device_tracker entry for the HA app binded to the person.

For stationary detection of these (and other WiFi) devices I use https://github.com/mueslo/openwrt_hass_devicetracker which uses entries from known_devices.yaml

The person entries look like this:

person:
  - name: Somename
    id: someid
    device_trackers:
    - device_tracker.mobile_app
    - device_tracker.stationary_device

What happens

When VPN is not enabled and he/she leaves home, the ‘openwrt_hass_devicetracker’ tells HA the device is disconnected from the network. Yet, HA refuses to mark the PERSON as away. Apparently it gives priority to the mobile_device component’s latest yet totally outdated GPS position, which is the house.

Is there a fix for this?

Did I forget to configure something?

@pnbruckner made some custom device tracker component that has a little more intelligence to it. I haven’t used it and I don’t know the name (That’s why I tagged you pnbruckner). It may be what you’re looking for instead of person. So you’d use this combined device tracker as a layer between person and your device trackers.

The custom integration that @petro is referring to is my Composite Tracker. Unfortunately I don’t think it will help in this scenario. If a GPS based tracker has been seen, and even if it’s not been seen for a long time, it will only use "to home" updates from non-GPS based trackers. So, in this case, when device_tracker.stationary_device changes to not_home, that update will be ignored.

The scenario described above is basically a lack of information. There are no updates from the GPS based tracker. And, for the router based tracker, it is simply guessing that the device must no longer be present. I’m pretty sure there is no positive “disconnected” event.

But, you could always write an automation that would create your own “composite” device_tracker using the device_tracker.see service that behaves the way you want.

When the device_tracker.mobile_app was not used yet, the device_tracker.stationary_device when disconnected would cause an away state for the person.
Therefore my conclusion is that outdated mobile app location data is used in higher priority than newer stationary tracker data. Sounds wrong to me?

It’s most likely the order in which you have the devices configured in your person. There is no ‘weight’ option for device trackers, so your logic is wrong in that regard. You’re over thinking how this works. It’s a simple algorithm and it doesn’t look at time. If you want something more complex, you gotta do it yourself.

Actually, that’s not true. If there is any GPS based tracker that has updated at least once, no matter how long ago that update was, it will take precedence over a non-GPS tracker that is not home. The precedence order is:

  • last non-GPS tracker that has updated to home, if any
  • last GPS tracker that has updated, if any
  • last non-GPS tracker that has updated to not home, if any

You can see the code here.

Again, your problem is a lack of information: The GPS tracker has not updated, and the non-GPS tracker has not positively indicated it is on the network (and as I said before, I doubt it positively indicates it’s no longer on the network. That is just being guessed at.)

Good to know, I’ll take a look into the code.

How does your composite device tracker handle this logic?

Once it sees a GPS based tracker it will ignore state changes of non-GPS based trackers unless they are “to home.” Which is why I said:

FWIW, I’ve had this argument many times. People see a non-GPS based tracker change to 'not_home', and they think, that’s new data, why isn’t it used? But it’s not new data. It’s a guess based on the lack of new data.

I.e., the device effectively stops saying “I’m on the network.” There’s no positive way to know if that is because it really has left, or it’s just stopped responding for one of many other reasons. So the implementation contains a “consider_home” feature that guesses the device probably has left if it’s stopped responding after the configured interval. This is why both the person component and my custom composite integration tend to ignore state transitions of non-GPS based trackers that aren’t “to home” unless there’s no other alternative.

Okay clear. Is it possible to workaround this behaviour with your https://github.com/pnbruckner/ha-composite-tracker @pnbruckner?
Some kind of AND operator on the mobile app and https://github.com/mueslo/openwrt_hass_devicetracker, so that both have to be true before someone is marked as home.

I guess another workaround might be to make ‘away’ an actual valid state and then push that from HASS device tracker instead of the not_home. But then you end up with two states that mean the same thing to a human but something different to the tech behind it.

It’s open source. You can modify it as much as you like to suit your needs.

not_home basically means “away”, and (at least when English is selected) is shown that way in the frontend.

You’re asking for functionality that is not very generic. It is specific to your scenario because you know how your devices behave, given they way they are used. I repeat my earlier suggestion:

I started a Java course a few weeks ago. Just modifying it is not gonna happen soon. :stuck_out_tongue:

Yeah that is what I meant. If I introduce a real away state then there will be not_home and away which are meant from the human perspective to mean the same thing, but in the computer code do not.

Missed/forgot your earlier recommendation, thanks. Using device_tracker.see to force the mobile_app device tracker entry to be ‘away’ when the Hass tracker reports away might work.
Btw, unluckily that Hass device tracker component does not work well with a multi router setup. As the router has a bit of a delay in reporting a (raw?) device disconnect, it will report a disconnect to HA while the phone in fact is connected to the other router. Wrong info. A well, maybe device_tracker.see can help with that too. Time for some thinking.

That’s not what I meant. I meant create a new device_tracker entity that is updated via an automation based on how you want it to work.

Why not manipulate the existing one?

Well, I suppose you could, as long as you understand it might update itself afterwords, maybe even if it’s still “stale.” I don’t use that particular tracker, so I don’t know how it behaves.

Seems like this is changed recently.

Now when HA app reports home, and then some other platform reports not_home the person will be shown as ‘away’… … …sometimes. Not sure what the decider is. Probably has to do with last updated of the platforms.

Have you read the doc page for person?

It has a fairly extensive explanation of how it decides.

Sorry for reopening this old thread and thanks for pointing to the Persons doc which explains the logic.

I am honestly struggeling quite a bit with the built-in heuristic of determining if someone is at home. At least in my case, it doesn’t work right:

image

I use two device trackers

  • the Android mobile app (which is using gps) and
  • the FritzBox Tools integration.

In reality, I’ve been at home for all the time shown until 30 mins ago, when I switched my mobile device off. The FritzBox device tracker picked-up correctly what I was doing:

It shows me home the whole time, lost me for a few seconds in the morning and then registered me switching-off the device at 09:10.54 now showing me being Away.

Looking at the other device tracker from the Android mobile app, it is on Unknown for a long time (probably because there is no gps reception in the house) and then goes to Home at 08:12:23 probably getting a signal.

image

According to the heuristic, I understand why I’m still Home. The latest gps signal still shows Home and never expires even though the stationary trackers have seen me leaving, so I never go away until I get a gps fix.

This is problematic in a number of cases, e.g. when leaving the house by going to the underground parking, driving out by car and the mobile app never gets a gps fix until much later when I get out of the car somewhere.

So question: is there a way to configure / automate HA so that it is the stationary trackers that determine if I’m at home or not and only if they figure I’m not at home, the mobile gps is used to figure if I’m possibly entering other zones?