Device tracker stuck in home (Unifi and Ping)

[danodemano]

Home Assistant release (hass --version):
0.61.1

Python release (python3 --version):
3.5.3

Component/platform:
Device tracker - Unifi and Ping

Description of problem:
Devices stuck in "home"

Expected:
Devices that aren't home should not show as home.

Problem-relevant configuration.yaml entries and steps to reproduce:

- platform: ping
  consider_home: 600
  hosts:
    shelley_ping: 192.168.9.68
    dan_ping: 192.168.9.69
    dan2_ping: 192.68.9.70
- platform: owntracks_http
- platform: unifi
  username: !secret unifi_user
  password: !secret unifi_pass
  host: 192.168.9.47
  port: 8443
  site_id: ihj7qv3c
  verify_ssl: false

Additional info:

Not sure if I should split this into 2 seperate bug reports. Here you can see the issue. The OwnTracks component is reporting correctly while both ping and Unifi are not:

The device does not ping:

And it's not connected in Unifi:

[Webserve]

#11835

Is it working after a restart of hass ?

[danodemano]

It wasn't, no. I restarted it numerous times. However it appears to have randomly started working again sometime yesterday.

[Webserve]

My command wasn't right. That problem is about the unifi_direct component and you are using the unifi controller component.

[tomas-l]

I'm seeing a similar problem in 0.62.1 with python 3.6.3 from RedHat SCL. I have two device trackers in my setup - Owntracks via MQTT and UniFi. In my case, UniFi tracker behaved correctly as long as it was the only device tracker used. Once I've added a second one, the problem emerged.
The difference in my case is that the problem is only visible on the History page (all UniFi users that have been present at midnight are shown as present for the whole day - except for those who also use owntracks) - the users state is displayed correctly on the States page.

[darkps10n]

Same issue with unifi, devices show home when all devices are away. Only using unifi no other trackers.

[jstys]

Same issue with asuswrt tracker. For me, it looks like the problem is if home assistant starts with the device in the "Home" state. If the device is not actually attached to the router when HASS starts in this state, then the asuswrt component will likely not update the "last_seen" timestamp for this device so the consider_home value won't even be checked for the device because it was not seen since HASS started up.

You can test this situation with other trackers by manually setting the state of the device_tracker to "not_home" and verifying that it doesn't revert back to "home" if the device is not reachable. If you manually set the state back to "home" again, it will still not properly revert back to "not_home" after the consider_home interval because the component never reported the device as seen.

[danodemano]

@jstys - you seem to be correct. I bounced HASS remotely and now my device is stuck at home:

When I opened the ticket my wife was at work and I had bounced HASS for another change. It was then I noticed that her device was stuck at "home" also.

[jstys]

I just had it happen to me today without restarting HASS... I have a feeling it is something related to the base device_tracker component because the asuswrt tracker is pretty simple in that it only runs a couple of command to determine which devices are connected to the router. I run the same commands manually while connected to my router and find that my devices are NOT attached yet the device_tracker will still not mark them as away.

[danodemano]

That would make sense as I'm seeing the issue with this on Unifi and Ping so it's a core problem and not something with the individual devices trackers. What that problem is however I haven't a clue.

[UglyBob79]

I have the same problem with asuswrt since like two weeks. Upgraded to latest a few days ago, still the same problem. It shows my phone as home for the last 40 hours, even though I have been out at least once a day all week. I could debug the router/hass if anyone hints me what commands to run.

[jstys]

@UglyBob79 I haven't had the problem recently (on 0.63.2) but the asuswrt component runs 3 commands:

• ip neigh
• for dev in nvram get wl_ifnames; do wl -i $dev assoclist; done
• cat /var/lib/misc/dnsmasq.leases
  For me, the last command was causing issues because devices had long lease times so i disabled the asuswrt from checking the active leases. These commands should each return mac addresses that may or may not match the tracked device you are looking for. If your tracked device is in any of the results of the 3 commands then it will be considered home.

[UglyBob79]

I tried now (my phone is 192.168.0.14 Mattias-Pixel2), but ofc I am home right now so the result should show I'm home. I could run it later without the phone on the network.

# ip neigh
192.168.0.107 dev br0 lladdr 60:38:e0:1b:73:a1 STALE
85.224.240.1 dev eth0 lladdr c4:71:fe:02:2d:80 REACHABLE
192.168.0.13 dev br0 lladdr 00:05:cd:e5:4e:d8 REACHABLE
192.168.0.56 dev br0 lladdr 30:85:a9:b2:0f:95 REACHABLE
192.168.0.14 dev br0 lladdr 40:4e:36:85:de:a1 REACHABLE
192.168.0.101 dev br0 lladdr 94:10:3e:3e:8d:11 STALE
192.168.0.110 dev br0 lladdr 04:18:d6:02:63:d5 STALE
192.168.0.7 dev br0 lladdr 00:04:4b:71:41:e8 REACHABLE
192.168.0.100 dev br0 lladdr 60:38:e0:1b:6f:69 REACHABLE
192.168.0.104 dev br0 lladdr ec:1a:59:79:ad:b1 STALE
192.168.0.108 dev br0  FAILED
192.168.0.6 dev br0 lladdr 74:d4:35:60:cc:16 REACHABLE
192.168.0.11 dev br0 lladdr 00:08:9b:f6:74:eb REACHABLE
192.168.0.250 dev br0 lladdr 34:ce:00:8c:1c:a1 REACHABLE
192.168.0.8 dev br0 lladdr 90:56:82:9f:06:81 REACHABLE
192.168.0.102 dev br0 lladdr 60:38:e0:1b:70:b9 REACHABLE
192.168.0.61 dev br0 lladdr 30:cd:a7:19:ff:34 STALE
192.168.0.105 dev br0 lladdr 94:10:3e:3e:29:01 DELAY
192.168.0.103 dev br0 lladdr 94:10:3e:3e:29:ed REACHABLE

# cat /var/lib/misc/dnsmasq.leases
86400 30:85:a9:b2:0f:95 192.168.0.56 hellbob *
48552 a0:6f:aa:33:ac:68 192.168.0.5 LGwebOSTV *
86227 40:4e:36:85:de:a1 192.168.0.14 Mattias-Pixel2 *
73864 90:56:82:3f:40:08 192.168.0.9 NODELivingRoom *
52935 00:05:cd:e5:4e:d8 192.168.0.13 Marantz-SR5012 *
45652 04:18:d6:02:63:d5 192.168.0.110 uglybob 01:04:18:d6:02:63:d5
59144 74:d4:35:60:cc:16 192.168.0.6 spongebob *
73678 00:04:4b:71:41:e8 192.168.0.7 NVIDIA *
73918 90:56:82:9f:06:81 192.168.0.8 NODEKitchen *
62268 34:ce:00:8c:1c:a1 192.168.0.250 lumi-gateway-v3_miio57544788 *
50677 94:10:3e:3e:29:ed 192.168.0.103 WeMo3 *
60054 00:08:9b:f6:74:eb 192.168.0.11 databob *
56719 94:10:3e:3e:8d:11 192.168.0.101 WeeMo1 *
46428 94:10:3e:3e:29:01 192.168.0.105 WeMo5 *
42080 ec:1a:59:79:ad:b1 192.168.0.104 WeMo4 *
72085 60:38:e0:1b:73:a1 192.168.0.107 WeMo7 *
84509 60:38:e0:1b:6f:69 192.168.0.100 WeMo0 *
55376 60:38:e0:1b:70:b9 192.168.0.102 WeMo2 *

# for dev in `nvram get wl_ifnames`; do wl -i $dev assoclist; done

[UglyBob79]

Hmm...you're saying the leases were too long, isn't the leases just to make sure the device gets the same IP again if requesting? It shouldn't keep it as online just because of a long lease?

[jstys]

You can just turn off the WiFi on your phone for a quick test. The leases file indicates the current state of which DHCP ip addresses are mapped to which devices. You can make the leases last as long as you want, even forever I think so it doesn't make much sense to me to use them in the device trackers because it doesn't necessarily reflect the current state of the device.

[UglyBob79]

So you mean that right now my router will keep my phone (Mattias-Pixel2) in state "online" for 86227 seconds? But isn't it almost a bug to use this information in that way in hass then? It will never be very correct

[jstys]

I'm still seeing the original problem where my device is stuck at home (with asuswrt) even though my phone is not on the WiFi. I noticed in the logs that during the night I received a warning log "Updating device list from asuswrt took longer than the scheduled scan interval '0:00:12'". Not sure if this is related but I know for certain that neither the ip neigh command or arp command contain my device.

[UglyBob79]

OK, I tested restarting HASS yesterday and I see now that my phone has been home since then even though I worked all day. This is completely useless right now. I'm not sure I really want to lower the lease time as it will affect other stuff (like changing IP all the time), is it really used for this? Is there any better way to do this presence detection with the router? I saw some thread about running a script on the router that notifies HASS about devices appearing/disappearing. Would that work better or will I get the same issue?

[darkps10n]

Seems to be an issue for me when the device tracker, in my case unifi, gets upgraded or restarted. Homeassistant fails the connection to the tracker and then doesn't re-establish the connection, when homeassistant is restarted it works again. Surely this should be something that would be retried till a successful connection is made? As it stands now I need to manually restart homeassistant or else my automations fail to run due to home or away states incorrectly toggled.

[UglyBob79]

Can't really figure out what's wrong, I'm on 76 hours of being "home" now. All my automations are useless when this part isn't working. Tried to get debug now but realize that the plugin has only one debug line: "Checking Devices". Now when my phone hasn't had any wifi for a while, it is not in ip neigh list, it is not in the arp list, only where it is is in the leases list. And still it is home in home assistant. :/

[UglyBob79]

It's so weird though, .now when I try manually to turn off and on the wifi, I get updates in the log like:

2018-02-22 20:15:55 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=device_tracker.mattiaspixel2, old_state=<state device_tracker.mattiaspixel2=home; source_type=router, latitude=65.35, longitude=21.4, gps_accuracy=0, friendly_name=Mattias-Pixel2 @ 2018-02-22T20:10:57.938015+01:00>, new_state=<state device_tracker.mattiaspixel2=not_home; source_type=router, friendly_name=Mattias-Pixel2 @ 2018-02-22T20:15:55.476825+01:00>>
2018-02-22 20:20:26 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=device_tracker.mattiaspixel2, old_state=<state device_tracker.mattiaspixel2=not_home; source_type=router, friendly_name=Mattias-Pixel2 @ 2018-02-22T20:15:55.476825+01:00>, new_state=<state device_tracker.mattiaspixel2=home; source_type=router, latitude=65.35, longitude=21.4, gps_accuracy=0, friendly_name=Mattias-Pixel2 @ 2018-02-22T20:20:26.939340+01:00>>

But I can bet a lot that when I leave home tomorrow morning, nothing will happen AGAIN. But I will check the logs again then.

[darkps10n]

Seems like even though the devices gets registered properly as home or away now the automations trigger as if we are home. Quite the energy wasting...

[tsrubar]

I have exactly same problem. Some devices get stuck in state home every few days, till I manually remove them from known_devices.yaml Afaik this problem started after upgrading unifi controller package to its latest version. In logs i see how hassbians connection gets refused because of too many attempts. Both run on same pi

[fanaticDavid]

I replaced my Asus RT-AC87U with Ubiquiti Unifi network gear just a few days ago. So now I'm using the Unifi device tracker and I'm seeing this behaviour for my laptop's wifi connection, which is stuck in the home state. Previously, I was using Asuswrt and nmap_tracker for device tracking, and I did not have this issue then.

I've searched /var/log/messages for state changes triggered by my laptop. I can see state_changed events for my laptop's ethernet connection, but none for the wifi connection. I am, however, seeing those state changes for the wifi connection of my SO's laptop.
I don't keep history in Home Assistant for these seperate connections (entities) as I combine their states using a binary sensor (which I do track the history of).

Home Assistant 0.65.3
Unifi Controller 5.6.36 running inside a Docker container on my NAS

My Unifi config (note that I override consider_home: 600 for my laptop's wifi connection with consider_home: 120 in my known_devices.yaml file):

- platform: unifi
  host: !secret TRACKER_UNIFI_HOST
  username: !secret TRACKER_UNIFI_USERNAME
  password: !secret TRACKER_UNIFI_PASSWORD
  verify_ssl: False
  interval_seconds: 30
  consider_home: 600
  new_device_defaults:
    track_new_devices: False
    hide_if_away: False

The last time I restarted Home Assistant was about 2 days and 8 hours ago. The only Unifi-related error in my home-assistant.log file is the following:

2018-04-05 02:21:23 WARNING (SyncWorker_14) [pyunifi.controller] Failed to perform <function Controller._read at 0x66e3f978> due to ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))

[kmlucy]

I only use the Unifi controller component for device tracking, and my devices are currently all stuck at home as well. There are no relevant log entries.

[tsrubar]

have you tried to delete them from known_devices.yaml and restart home assistant? fow me it works for some time, but sooner or later this issue will return

[kmlucy]

I haven't tried that yet, but if it is only temporary, there doesn't seem much point.

[fanaticDavid]

It seems I only have this issue with my MacBook Pro. Last night, I realised the last time I rebooted my MBP was just before I installed all my Ubiquiti UniFi hardware. So I rebooted my MBP and it seems to have improved the situation, at least for now.

I'm also not sure that this is a bug within the UniFi device tracker, at least for me: whenever Home Assistant would think my MBP was home, my MBP was also listed as being connected in the UniFi controller. The uptime would often exceed 1 day, which is absolutely incorrect: I put my MBP to sleep several times every day (to sleep, if nothing else).

And on a positive note, tracking my Android phone seems to be more reliable than it was when I was using Asuswrt and nmap_tracker. Back then, my phone would sometimes be marked as not_home eventhough I was. Now, with the UniFi device tracker, I actually have to leave the house 🙂

EDIT: not sure if this is relevant for anything or to anybody, but I've also added detection_time: 60 to my UniFi device tracker config. The default value for that option is 300 (seconds).

EDIT 2: okay, my MBP is once again stuck in the home state, eventhough I woke it up about 10 minutes ago (it shows as Connected because in my Home Assistant UI, I show the state of the device_tracker entity using a template binary_sensor with a device_class)...

But in my case, UniFi is the source of the bug (either that, or my MBP really doesn't like to disconnect from the wi-fi network when sleeping):

[tsrubar]

Actually situation in my home:

and how it looks according to unifi tracker:

tracker logins in controller:

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[danodemano]

Definitely still an issue in 0.74.2. Nobody is home right now so I bounced HomeAssistant remotely:

[darkps10n]

Yeah I don't think HA keeps trying to connect to unifi controller as a good TCP connection should.

[jerobins]

I'm having the issue on 0.74.2 as well, except using OwnTracks. MQTT broker has updated messages from all devices, yet one is still marked Home even when it is not. HASS has uptime of over four days with this behavior starting this morning.

[kimmeld]

Chiming in to say that I have the same issue. I’m only using the ping device_tracker.

I have a bunch of IP cameras that get powered off when I’m home (as in unplugged), so I use device_tracker to send state updates to Node-RED which then turns the cameras off in ZoneMinder. I will frequently see situations where the camera is turned off in ZoneMinder, thus indicating that Home Assistant saw it go away and triggered the state change, but the Home Assistant UI (including the state history) shows it as Home.

It’s weird - it obviously sees the state change since the automations I built around it works, but it’s like it doesn’t make it all the way through HA to the History and front-end components.

I’m having this issue on Home Assistant 0.75.1 (and have had it happen on and off for many versions).

[tjharman]

Still seeing an issue here with 0.81.2

[kmlucy]

This issue had gone away for me, but it seems to be back in 0.82. I skipped 0.81, so it could have cropped up there, but I didn't see the issue in 0.80.

[jckoester]

I've had this issue yesterday for the first time on 0.81.6, it still exists in 0.82.

[jalme]

Same here with 0.82.1 using (was working fine yesterday with 0.82.1):

  - platform: thomson
    host: 192.168.1.254
    username: !secret router_user
    password: !secret router_password
    consider_home: 180
    new_device_defaults:
      track_new_devices: False

The change that I did in my setup was upgrading Phyton... So not sure if this makes any sense....

[jalme]

Fixed it. It was IPv6 on my router acting up... Disabled IPv6 and everything started working....

[tsrubar]

Now I have unifi combined with google maps location sharing. Today my status looked like this. Just tried to completely disable ipv6 on my lan and we will see if that helps

[darkps10n]

still an issue with 0.86.4
Devices show at home but no one is home. Neither restarting unifi controller nor HA yields a change at all.

Doubt this will ever get fixed.

[jerobins]

It seems as the issue is reproducibility. The stuck tracker issue went away entirely for me when I dropped owntracks, cleared retained mqtt states, and moved to the life360 component.

[tomas-l]

I don't recall having this issue recently. Maybe it has something to do with my decision to use MySQL instead of SQLite as a backend for logging. I do still use owntracks and didn't clear any MQTT topics. On the other hand I've never had a problem with detecting home state of owntrack devices, the problem was with those relying solely on UniFi.

[mkmer]

Seeing the issue on 0.87.0 - and all versions up to this.

[Piramidowy]

The same problem here. All of my devices are stuck on "home".

[tjorim]

There were recently some fixing regarding devices stuck on 'home'. I myself don't experience it anymore. If I recall correctly the issue occured when devices left home during a HA restart. Could you guys update to the latest version (0.90) and report back?

[danodemano]

I haven't seen this issue re-surface on 0.90.1. Nobody is home right now and I just bounced HA a few times and every time it came back up with everyone still away.

[gurbina93]

+1 here
Combining trackers or separating them, the Unifi device_tracker always shows as home...

[stale]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[darkps10n]

And as luck would have it a day after this is closed the issue is back...

[Kane610]

@Awaldeck on hass 0.97?

[mkmer]

Just updated to 0.97 yesterday. So far so good - working fine.

[darkps10n]

If I revert back to 0.96.5 instantly works. Upgrade to 0.97 stuck in away. Ill clear the DB and logs to see if it makes a difference.

[Kane610]

@Awaldeck any progress?

[darkps10n]

@Kane610 Yes , the entity registry had the devices listed from the unifi integration but appending _2. I had to delete the "knowndevices.yaml" file as only then could I rename the device back to the original name. I had to change some automation's to use the new Group but it seems to be sorted out.