Presence detection monitoring pause after device is away

Hi all,

I’m struggling with the following situation.
A phone had 2 types of presence detection, 1 Router based (unifi controller) and 2 GPS based (life360)

When going away from home, the GPS triggers the device to “not_home”. But because the device is still available in the router, the router set it back to “home”. This process continues till it is finaly removed from the router. This will be in about 3 á 4 minutes.
Because I also have triggers when someone comes home, in this period this device is coming home several times :frowning:

So I wonder. Is there an option to pause the monitoring for all detections (for this device) for some time after the first “not_home” detection?

This is my configuration for presence detection:

  - platform: unifi
    host: >>hidden<<
    username: !secret unifi_username
    password: !secret unifi_password
    site_id: >>hidden<<
    verify_ssl: false
    detection_time: 300
      track_new_devices: false
  - platform: life360
    username: !secret life360_username
    password: !secret life360_password
    interval_seconds: 10
    filename: life360.conf
    show_as_state: places, driving, moving
      minutes: 30
    consider_home: 300

I tried this option:


(integer)(Optional)How long since the last seen time before the device is marked away, specified in seconds.

Default value: 300

But it does not seem to do anything.

This is how it looks like in the log:

You might want to try out my Composite Tracker.

BTW, consider_home does nothing for GPS-based trackers.

I believe you are having the same issue I had with Ubiquiti Unifi controller. After the WiFi device has been disconnected briefly, it shows back in the controller as LAN connected for a few more minutes.
This is an old documented issue with Unifi.
In my case, I use the Unifi controller plus Google maps to detect presence.
After several weeks of tinkering, I now have rock solid presence detection.

I created a binary sensor for each of my “humans” that works 100% of the time after a brief delay.
I test four conditions:

  1. GPS location (Google Home) is HOME
  2. Phone on WiFi (Unifi Controller) is HOME
  3. Phone on WiFi (Unifi Controller) was Last_seen < 300
  4. Phone on WiFi (Unifi Controller) is NOT wired (to get around above mentioned bug)

I also change the entity picture in Lovelace. Here is an example:

- platform: template
        friendly_name: 'Valerie'
        device_class: presence
          minutes: 1
        value_template: >-
          {{ (is_state('device_tracker.google_maps_11481718230455488', 'home')) or 
             (is_state('device_tracker.cell_phone_valerie_pixel', 'home') and 
             (as_timestamp(now()) - (states.device_tracker.cell_phone_valerie_pixel.attributes.last_seen < 300))
             and (states.device_tracker.cell_phone_valerie.attributes.is_wired == false)) }}
        entity_picture_template: >-
          {% if (is_state('device_tracker.google_maps_11481718230455488', 'home')) or 
            (is_state('device_tracker.cell_phone_valerie_pixel', 'home') and 
            (as_timestamp(now()) - (states.device_tracker.cell_phone_valerie_pixel.attributes.last_seen < 300))
            and (states.device_tracker.cell_phone_valerie.attributes.is_wired == false)) %}
          {% else %}
          {% endif %}


Thank you for understanding and letting me know how you solved it.

I was thinking… when the developer of the Unifi Presense Detection can build in that someone is not_home when the signal is 0% (what it is when someone is out of range), Then I think it will solve this without making any extra checks. When this is no option, than I gladly will be using your solution :slight_smile:

Below image is when my wifes phone was away several seconds from home.

What do you think? Will this work?

Edit: I have no idea this value can be read from from the API, but when it could…

Ok, thought about this some more. I would suggest this:

Set detection_time to 1.
Set consider_home to 1. (BTW, move the consider_home setting under the unifi config. This is a device_tracker “global” setting and must be in the first device_tracker platform config to take effect.)
Use my Composite Tracker (mentioned above) to combine your unifi and life360 trackers.

The theory goes like this. When the Unifi first sees the device on the LAN, it will mark it home. One second after it is last_seen it will try to set the entity to not_home because detection_time is set to one second. But the component level code will keep it home for one more second due to consider_home being one second. Then it will go to not_home. However, since the life360 tracker should be home, the composite will stay home. (The composite tracker by design only uses transitions to home for non-GPS trackers when there are also GPS trackers. To put that another way, when there are GPS trackers the composite will ignore not_home states of non-GPS trackers.)

Then when the device leaves, and the life360 tracker goes out of the home zone, the composite will do likewise.

In summary, the non-GPS (i.e., unifi in your case) tracker will only be used to transition the composite tracker to home. It will never cause the composite to change to not_home - only GPS trackers can do that.

Isn’t that just the problem?
When the GPS tracker sets the device to not_home, the nog-GPS tracker sets it to home because it is still in the Unifi device list.

The non-GPS tracker should wait to do another ‘home’ setting when another tracker has set it to not_home.

It is posible to read the Signal strength of the devices Wifi. When zero (0) it may be asumed the device is not_home. So I’m searching for a solution that the non-GPS tracker set the device only to home when it is in the Unifi device list AND the signal strength is not 0.

Made a new topic here: Fine tuning home not_home by device condition

I’m not sure how to accomplish this in Hass.

Have you at least tried setting detection_time and consider_home to 1? I guess I don’t know exactly how the unifi router and HA platform behave, but it’s at least worth I try I would think.

And, yes, I saw the other thread which made me think about this some more and come back to this one. My suggestion may not work. Don’t really know.

You could monitor for “signal” to determine presence. Here is my configuration.yaml entry:

  - platform: unifi
    port: 8443
    username: !secret UnifiUser
    password: !secret UnifiPW
    site_id: bexw39rm
    verify_ssl: false
    detection_time: 120
    consider_home: 120
      track_new_devices: false
    hide_if_away: true
      - name
      - is_wired
      - last_seen
      - signal

Oke, will try this. Let you know the results.

I added the “signal” option to the monitoring and can read it from Hass. But how to add this as extra trigger for home or not_home by the Unifi Device Tracker?

Device is listed in Unifi Controller = Home
Device is not listed in Unifi Controller = Not_Home

Device is listedin Unifi Controller = Home
Device is not listed in Unifi Controller OR signal=0 = Not_Home

Any idea’s?

I don’t know why, but your settings seems to work. I also switched the platform tracker order (life360 first, than unifi) also, don’t know if that had any positive results.

I still don’t understand what decides the actual status the device gets when using multiple trackers and one thinks your home and the other does not…

  • For the Life360 Tracker, the device tells Hass it is away (or home). That should be always correct.
  • For the Unifi Tracker, Hass asks the Unifi Controller every (12?) seconds if the device is home or not. The delay in the Unifi Controller is/was causing trouble.

There’s a big difference.

It looks like a good idea to use your Composite Tracker also. If I understand correctly it sits on top of the other platform trackers and is actually responsible for the home not_home behavior. Mayby you can build in the extra signal attribute when it is available and sets the device to not_home when this is 0. (just an idea if my understanding is correctly)

Thank you.

The Life360 platform periodically polls the Life360 server (based on interval_seconds.) When it sees a new “last_seen” value for a member it will update the corresponding HA device_tracker entity. home/not_home/zone is strictly determined by the GPS coordinates.

From what I’ve seen briefly browsing the unifi platform code, I believe it also periodically polls the router. And I think it also gets some sort of “last_seen” time for each “client” device from the router. As long as that last_seen time is less than detection_time seconds ago, it considers that device home. The component-level device_tracker code “on top of it” then takes that determination and applies the consider_home time to it. So, I think the bottom line is, when the router sees the device, and the unifi platform polls, the corresponding HA device_tracker component will be set to home, and will stay that way as long as it’s seen on the network. When it is no longer seen, then once the detection_time interval is up, the platform level code decides it’s no longer present. But then the component level consider_home time has to expire, too. Once both have expired (since the last time the device was seen on the network), the corresponding HA device_tracker entity will be set to not_home.

For the unifi platform, by setting detection_time and consider_home each to one second, then the device_tracker will change to not_home only two seconds after it is no longer seen on the network. (Of course, you have to figure interval_seconds into the equation, too, I believe, so it might be a few seconds longer.)

That depends on how you combine them. I can think of a few ways, all which work differently. First, you can combine them in known_devices.yaml by adding the MAC address from the router entity to the GPS-based entity. Second, you can combine them with a group. Third, you can create specific automations and other entities to combine them. Fourth, you can use my composite tracker.

Regarding my composite tracker, it doesn’t poll, but rather watches its “input” device_tracker entities, and will try to update when any of them change. Whether or not it actually updates depends on how the input entity changed - i.e., what its state, and the state of all the other input entities, are.

I hope this helps.