Core: Unifi: offline device shown as "home"

Created on 13 Aug 2019  Â·  46Comments  Â·  Source: home-assistant/core

Home Assistant release with the issue:
0.97.2

Last working Home Assistant release (if known):
0.96.x

Operating environment (Hass.io/Docker/Windows/etc.):
Hassio on docker

Component/platform:
Unifi

Description of problem:
Multiple clients which are offline in the Unifi Controller shown as "home" in HA.

Unifi Controller 5.10.26 (via Hassio)

I've used the dev tools to manually set these devices to not_home, however they are promptly changed back to home by the Unifi integration.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

<config added through integrations>

Traceback (if applicable):
Log line from when Unifi integration is added. This iPhone had been off wifi for >30mins when the integration was added to HA

2019-08-13 12:07:58 DEBUG (MainThread) [aiounifi.api] [ {'_id': '5bd48655ddb88d01ef574448',
  '_is_guest_by_ugw': False,
  '_last_seen_by_ugw': 1565694473,
  '_uptime_by_ugw': 7887,
  'assoc_time': 1565679375,
  'authorized': True,
  'bytes-r': 0,
  'first_seen': 1540654677,
  'gw_mac': 'redacted',
  'hostname': 'redactediPhone',
  'ip': 'redacted',
  'is_guest': False,
  'is_wired': True,
  'last_seen': 1565694473,
  'latest_assoc_time': 1565686586,
  'mac': 'redacted',
  'network': 'HOME',
  'network_id': '5b639e8d4c80068775855ae8',
  'oui': 'Apple',
  'qos_policy_applied': True,
  'rx_bytes': 16766995,
  'rx_bytes-r': 0,
  'rx_packets': 15715,
  'site_id': '5b638cf84c800687758559a7',
  'tx_bytes': 2163798,
  'tx_bytes-r': 0,
  'tx_packets': 13958,
  'tx_retries': 0,
  'uptime': 15098,
  'user_id': '5bd48655ddb88d01ef574448',
  'wifi_tx_attempts': 0},

Additional information:
Maybe related to #25876?

unifi

Most helpful comment

@Kane610, the beta fix is working beautifully so far!

Screen Shot 2019-10-05 at 1 11 25 PM

All 46 comments

Got the same issue.

Hey there @kane610, mind taking a look at this issue as its been labeled with a integration (unifi) you are listed as a codeowner for? Thanks!

A couple of further observations. Note, the referenced iphone was _not_ connected to wifi at all during these tests.

1) When adding a Unifi integration, the last_seen attribute reported by aiounifi.api changes dramatically (1565700473 > 1565694331).

  2019-08-13 13:48:06 DEBUG (MainThread) [aiounifi.api] [{'_id': '5b64c2d15ab20c063cc27ab5',
  '_is_guest_by_ugw': True,
  '_last_seen_by_ugw': 1565700473,
  '_uptime_by_ugw': 1273,
  'assoc_time': 1565693391,
  'authorized': True,
  'bytes-r': 0,
  'first_seen': 1533330125,
  'gw_mac': 'redacted',
  'hostname': 'redacted-iPhone',
  'ip': 'redacted',
  'is_guest': True,
  'is_wired': True,
  'last_seen': 1565700473,
  'latest_assoc_time': 1565699200,
  'mac': 'redacted',
  'network': 'GUEST',
  'network_id': '5b64aa654c80068775855b33',
  'oui': 'Apple',
  'qos_policy_applied': True,
  'rx_bytes': 64084,
  'rx_bytes-r': 0,
  'rx_packets': 0,
  'site_id': '5b638cf84c800687758559a7',
  'tx_bytes': 11768,
  'tx_bytes-r': 0,
  'tx_packets': 83,
  'tx_retries': 0,
  'uptime': 7082,
  'user_id': '5b64c2d15ab20c063cc27ab5',
  'wifi_tx_attempts': 0},


2019-08-13 13:48:08 DEBUG (MainThread) [aiounifi.api] [{'_id': '5b64c2d15ab20c063cc27ab5',
  'first_seen': 1533330125,
  'hostname': 'redacted-iPhone',
  'is_guest': True,
  'is_wired': True,
  'last_seen': 1565694331,
  'mac': 'redacted',
  'oui': 'Apple',
  'site_id': '5b638cf84c800687758559a7'},

2) Sometimes after adding the Unifi integration, the entity state flaps from home > not_home > `home.

2019-08-13 14:07:19 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=device_tracker.redacted_iphone, old_state=<state device_tracker.redacted_iphone=home; (SNIP) @ 2019-08-13T14:07:03.574839+01:00>, new_state=<state device_tracker.redacted_iphone=not_home; (SNIP) @ 2019-08-13T14:07:19.418263+01:00>>
2019-08-13 14:07:19 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=device_tracker.redacted_iphone, old_state=<state device_tracker.redacted_iphone=not_home; (SNIP) @ 2019-08-13T14:07:19.418263+01:00>, new_state=<state device_tracker.redacted_iphone=home; (SNIP) @ 2019-08-13T14:07:19.541697+01:00>>

I had this happen once for a device in my testing for my reported unifi issue where devices are being reported as invalid entity at times. Curious if these status pulls are related at all from pulling from the entity domain. https://github.com/home-assistant/home-assistant/issues/25885

I've also got a repro; homeassistant docker, controller on a cloud-key.

I'm testing with specifically reverting lines 297 and 342 from this commit.

https://github.com/home-assistant/home-assistant/commit/f03538f8666b021818b771ae950f08c849156460#diff-324cad01d3995e0340760ccf1892aaab

Had to do it real quick over ssh at lunch -- will see if that shakes out and stabilizes my device states over the day.

That change is for devices e.g. Network infrastructure. Clients are for all normal network devices

I'd need to go read through the code (and I do know you're the owner here, so I appreciate it), but it does appear to have stabilized my flapping state behavior on my client devices.

Been stable for 8 hours after that revert. I don't really have a solid integration environment for this, but I can work my way through the code, specifically the state property to better understand why.

I too am seeing this issue on .97.2. Strangely, it seems to have worked ok for close to a week before it started the "flapping" behavior.

@swestcott your iPhone is reported as being wired, that's a bit troublesome in it self.

@jeremydk still working for you?

@mkmer can you share logs?

Stable for me. I've also seen the phantom wireless device being reported as wired when disconnected in the past. I'm wondering if there's a certain amount of slop in the return from the unifi API causing wireless clients to erroneously report as devices and hit the new state code.

Fairly long log with debug turned on. I am exclusively seeing my devices momentarily go "Not_home" then returning "home" whenever a device goes off WiFi. Almost looks like the app is reading the "restore" function after they leave the network?

home-assistant.zip

If I need to provide more or turn on additional logging, I will!

Ok, just upgraded to .98 and it now appears to be working. I have tested several devices disconnecting from wifi and they are staying "not_home" where previously the would go "not_home" for ~1 minute then switch back to "home" (aka flap as described above).

I'll update if it stops working.

well... I take that back. One of my 4 device trackers was working for ~1 day, the other 3 continued to work in the "flap" mode where they go "not_home" for ~1 minute then return to the "home" state indefinitely.

Following up on this issue further: I'm currently on Unifi Controller 5.10.26. Noticed that the "last seen" times under "insights" continues to show current time even when devices are disconnected (and not showing on the clients list. I suspect this is the root cause of the devices reappearing as "home". Anyone else seeing this?

Wifi devices reporting as LAN is a long-standing bug in Unifis software

https://community.ui.com/questions/Wifi-devices-showing-as-LAN/0771fb9f-84f0-4111-a417-3eada0d88c9d
https://community.ui.com/questions/Wireless-clients-shown-as-wired-clients/49d49818-4dab-473a-ba7f-d51bc4c067d1

Since this issue has persisted for 3 years(!) in Unifi is there anything we can do to fix it inside hass?

This unfortunate bug makes device_tracker useless, as I run into this bug all of the time, and none of my automations trigger

I had hoped dont_track_wired_clients: true would solve the issue, but as far as I can tell that option is non-functioning in both the yaml config and the UI config, as setting it doesn't prevent wired clients from appearing.

You all are likely hitting this bug in Unifi, which causes the state tracker to consider the device home.

image

I wonder if a fix could be if dont_track_wired_clients is true and a device becomes wired, that device would be considered away, then it would be considered home once it is not wired again. Perhaps that is too hacky of a workaround

Thanks! I have been thinking about how to properly identify a device that goes between wired and wireless in a deterministic way

@mkmer - yes, I'm experiencing the same issue. It's caused by a longstanding bug in Unifi's controller software. There are a number of threads on their forum describing the issue, like this one or this this one.

The pattern is consistent for me:

  1. a wireless client disconnects from the wifi network
  2. the controller correctly reports the client has disconnected
  3. about a minute later the controller incorrectly reports the client has re-connected, this time as a wired device
  4. about 10–15 minutes later, the controller reports the phantom wired device has disconnected

Here's what it looks like in the controller's event feed:

Screen Shot 2019-09-07 at 12 52 35 PM

(It doesn't show when the iPhone's connected to LAN as wired devices but does indicate when the phantom wired devices disconnected.)

I contacted Unifi about this but was told they couldn't help because my controller is running in docker on a Synology NAS, rather than a supported device from Ubiquiti.

It's a frustrating problem since it causes false positives with presence detection in HASS. Previously, I was able to workaround the issue by enabling the Unifi's components SSID filtering which would ignore updates from devices with a matching essid attribute. This worked perfectly because when the controller erroneously reports a wireless client is connected as a wired device, it no longer contains the essid or ap_mac attributes (as seen in the logs posted by @swestcott).

Unfortunately, with the recent overhaul of the Unifi integration, this workaround no longer works. I had hopes that enabling the new dont_track_wired_clients option might be the answer but no luck there either. This is as of v0.98.4.

BTW, No complaints here—@Kane610's updates have been fantastic and are much appreciated. The ability to configure integration options directly in the frontend is awesome.

EDIT BTW, started this yesterday and got interrupted before finishing. Submitted today without refreshing and never saw @chrishoage's helpful post—apologies for some redundant information.

As I have basically the same problem, let me purpose an Idea:
We have an ssid_filter but don't use it IMHO.
So: Why don't we use this? If a disconnected client gets assigned to LAN, it is obviously NOT in this SSID, so not_home

The only successful workaround I've found is to switch to the Direct AP component. Definitely not ideal, it lacks many of the niceties provided by the main Unifi integration. However, presence detection has been rock solid since I made the switch.

I have exactly the same issue. @aaronwolen, the problem with that solution is that most people will probably have multiple APs.

The ssid_filter is working for me, but since this new integration form I can no longer whitelist devices. homeassistant.components.unifi.device_tracker will happily report every client's state.

@ruimarinho, the direct AP component can be used with multiple APs.

When you say the ssid_filter option is working for you, do you mean it prevents recently disconnected wireless clients from spuriously reporting they're connected to the LAN as a wired device?

@aaronwolen that's news to me. I might give it a shot then! No, sorry for the confusion - I meant it filters out the correct entities from the provided ssid but I still experience the wired device issue. I was referring to @LukasQ's comment.

So, @ruimarinho you're saying that the ssid_filter filters out clients, once they switch from e.g. "SuperSSID" WiFi to "WLAN"?
Because my disconnected clients get dumped into "WLAN" Network and I wonder why HA still "sees" them, even if the ssid_filter for "SuperSSID" is active.

Hey! It would be great if one of you who has got this problem could try out my PR to verify if it solves this issue

Are there docker containers built from PR branches that can be used to more easily test?

@chrishoage don't think so. If you fork the gitrepo you can start it through dev container with visual studio code

Bummer, I'm not sure I'll have time to set up a new environment to test this change.

Hopefully someone else in this thread will be able to!

I'm testing this out already so will post my updates as soon as I have enough data.

@ruimarinho how's the evaluation going?

If someone could point me to a documentation how to setup the build pipeline, I'd test it on my hypervisor as well

Do a fork of my home-assistant GitHub project check out this PRs branch and then follow dev instructions on how to set it up. You can run it on whatever machine you want

So far, so good! No false positives yet. :)

Great! Working on tests right now. Will get it merged in time for 0.100 beta

So far, so good! No false positives yet. :)

Can you confirm that the Unifi controller is showing the device as wired? I'll note that this issue doesn't _always_ happen, so it might be a good idea to ensure that the unifi controller shows the wireless device as wired and hass shows the device as away.

I've gotten one situation (verifying) like that with one of our iPads, in that case I had a extra print tell me when the expected wired state diverged from what Unifi reported

Mine are shown as "WLAN", not wired aka "LAN"

See my screenshot here: https://github.com/home-assistant/home-assistant/issues/25915#issuecomment-529047903

When the issue with devices showing as "home" in hass when in fact they are "away" the device will show in the state shown in the screenshot in the unifi controller.

Note a wireless device like a cellphone is shown connected to the wired network, not an access point (or disconnected, as it should show)

I haven’t been able to check if the is wired property is being properly set because every time I remember to check away from home it’s already past a few hours in 😅

For example, almost two hours in and the property is set to false. However, the false positives are gone since I applied the patch. My wife’s going to be very happy 😃

Thanks a lot for your work on this @Kane610!

@Kane610, the beta fix is working beautifully so far!

Screen Shot 2019-10-05 at 1 11 25 PM

Awesome! Thanks for the feedback @aaronwolen

@Kane610 Thanks a bunch for the great work!

Thanks!

Could it be the case we have the same problem again?
I face after the recent update to 0.13.2 more or less the same problems. Clients tend to "flicker" in their home state.

No the specific issue of wireless devices becoming wired shouldn't come back. What is 0.13.2?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sh0rez picture sh0rez  Â·  3Comments

MartinHjelmare picture MartinHjelmare  Â·  3Comments

neonandu picture neonandu  Â·  3Comments

i-am-shodan picture i-am-shodan  Â·  3Comments

arangates picture arangates  Â·  3Comments