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?
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?
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.
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:
Here's what it looks like in the controller's event feed:
(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!
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?
Most helpful comment
@Kane610, the beta fix is working beautifully so far!