It looks like updating to the latest version at least solved #1 above. I’ve restarted a few times now and the away devices aren’t showing at home anymore. Thanks for that!
Now to see why my phone won’t ever show as home…
This whole thread is an interesting read. I’d be willing to bet that your issues stem from the non-unifi WAPs because that seems to be the only difference between your setup and mine. Are your old ASUS routers possibly attempting to handle the routing?
Also, I have a co-worker who frequents the ubiquiti forums and he warned me to not update to v5.12 for reasons I cant remember. I’ll shoot him a text, but I seem to remember it having to do with dropping clients or creating fake clients in one of the virtual networks.
I don’t think so. I’ve verified that they are both in AP mode.
I could try disconnecting them later and see if anything changes.
Cool! That would be very appreciated.
This.
The controller will only be able to report devices that connect TO the unifi gear. If you’re roaming between WAPs you are “falling off the network” because unifi controller isn’t looking at what’s connected to your router, but what’s connected to Unifi stuff.
That makes a lot of sense. I’d be interested to see what would happen if he got a ubiquiti lite AP
I could almost say that is correct but the controller knows my phone is connected to it. It is connected to an AP (the ASUS) that is connected to the Unifi switch. And that’s how it’s shown in the client list of the controller.
these two screen shots are at the same time
So I’m not completely convinced that’s the issue…yet…
there’s still more testing to be done.
EDIT to add:
all of those “home” states were all caused by the bug that I fixed when I updated to v103.6 a few hours ago. They weren’t real. But I’ve been home since 10am (over 3 hours ago)
@finity only just got to catch up on this thread. I completely failed to register that you were using non-Unifi kit with the controller although you stated it quite clearly; my apologies (my wife always tells me I can’t multiask).
What @flamingm0e and @petro say seems to make sense to me (although both my sites are pure Unifi networks).
I wonder whether devices are (still) seen as wired as this old reddit thread suggests.
Unfortunately I have no way of testing this as a theory either at home or work.
The phone shows as wired in the client list (since it’s shown as connected to the unifi switch) but in HA it shows as wireless so I’m not sure where that is getting reported.
That sounds awfully similar to this current issue in GitHub which itself is tied to a workaround for Unifi wireless devices showing as wired after disconnecting (affecting home → not_home times and mentioned by one of the participants in the linked thread).
Might be worth looking in the unifi_data file mentioned to see if the relevant MACs are listed?
My (shaky) theory being:
- phone shows home when connected to Unifi AP
- phone roams to Asus AP
- Unifi sees phone as wired
- MAC written to unifi_data
- phone no longer tracked.
2 Likes
Holy Cow! I think you found it! And I’m pretty sure your “shaky theory” was correct - only backwards. The bug was that when the device connects to a Unifi AP it’s MAC gets written to the data file as “wireless”. As soon as the device roams off the Unifi AP and connects to the ASUS router it is then reported as wired so it stops being tracked and is always “not_home”.
I removed the MAC for my phone from the data file and as soon as I restarted HA it picked my phone up immediately as home - even with the phone connected via the ASUS router.
Interestingly, in the interim from my last post I had turned off my two ASUS routers forcing my phone to connect directly to my Unifi AP and it immediately went to “home”. And as soon as I turned them back on and my phone connected to the ASUS router it immediately went to “not_home” again.
So i almost posted that @flamingm0e and @petro were correct. But, it just didn’t make sense since the controller still knew my phone was connected to the USG but the only thing had changed was that it was now reported as “wired” instead of “wireless” in the data for the integration from Unifi.
So I started looking thru the debug logs I’ve been amassing since early this morning and I saw that the phone was being reported as wired when connected to the ASUS and when it connected to the Unifi it was reported as wireless. But if you recall in my screenshot above that HA always showed it as wireless no matter what Unifi reported (and hence my question about where it got that information). I’m assuming that the “report” comes from the entry in the data file that at some point in time the device was reported by unifi as wireless so that status was made very sticky.
That was around the time you popped back in with your post about the bug so it was perfect coincidence. I don’t think I would have easily (if ever) put those two things together since there was no easy way to know that the unifi integration had it’s own separate data file in .storage just for reporting that devices are wireless or not. I’m not sure what benefit that information serves for HA and why it’s needed.
Even tho that bug was just recently reported in v103.0 I know for a fact that I’ve been experiencing this same behavior ever since I switched to the Unifi equipment (with a bit of ASUS thrown in) in August.
That also explains why my phone would always be tracked correctly for a couple of days or so after I switched to a different controller host machine. That data file gets regenerated/updated every time you connect a new host to HA. Right now it has data from all three of the IP addresses of the host machines I tried to make it work - my original docker host, the Pi I ran hassio on for the add-on and my cloudkey. Apparently my phone really liked to connect to my ASUS routers instead of the Unifi AP until it had no choice. Then when it finally did connect to the Unifi AP it stopped working again.
Hopefully they’ll come up with a fix for that bug soon. But I’m glad you pointed that out to me. I really wasn’t looking forward to buying more (expensive) Unifi gear to replace my problematic ASUS stuff. It already sucks I bought a $170 cloudkey for literally no reason at all. 
Thanks you guys!
Especially TazUK! 
That was some awesome sleuthing.
It seems you have helped me figure out both of my major issues. It’s too bad I can only give you one solution mark. 
Hopefully after these bugs get resolved it’ll be smooth sailing again.
Glad to hear you’ve nailed down the root cause - I hate the unknown / intermittent bugs myself, but tend not to worry once there’s an issue I can track on GitHub . Kudos to you for sticking with it.
The unifi component code-owner seems pretty active and it is a popular component, so hopefully you’ll be bug-free soon.
If I were you I’d track the issue on Github and go have a beer and do something not at all technical for a while 
1 Like
I like the way you think. 
Not to be naggy but did you happen to see my last question I posted to you above:
the reason I’m asking again is that you said that you were also having issues with your unifi device trackers until you went to node-red.
After interacting with the dev on the issue thread posted by TazUK I’m now wondering if node-red is also affected by the “wired bug” described there. Or maybe your issues weren’t caused by the same bug but some other thing. In that case i’m not sure if switching to node-red would help me.
However…I have now installed Node-red and installed the home assistant palette (node-red-contrib-home-assistant-websocket) and the unifi palette (node-red-contrib-unifi) and would like to take you up on your offer to guide me on how you got your unifi working between node-red and HA.
Since I’m brand-stinkin’-new to Node-red I’m not sure what the correct lingo is to ask what needs to be done. Is it just a flow that I can copy from you and make work for me too just by changing my details?
Do you have any good links to any Node-red tutorials for people like me?
Sorry… Been offline for a few days. I didn’t even see that you had the Asus routers in play. No, my system is purely Unifi (well, there is one Netgear Proview switch, but that’s getting switched out within the next month or so).
Sure! If you wouldn’t mind giving me a couple of hours, I’ll send you my flow (I’m not at home atm).
Man, maybe I just need to bite the bullet and spend the couple of hundred bucks and update all of my stuff to Unifi. But I’ve already spent quite a bit already. 
especially on that completely unnecessary cloudkey. 
and then all of my ASUS stuff would just be sitting around collecting dust.
I guess there is always Ebay…
Thanks for helping out on the node-red unifi config.
That’s what I ended up doing. I had 3 Nighthawk R7000s running along with a few Proview switches (I guess that I easily had spent close to $600-$700 on my networking gear) and it is all (sans one switch) sitting in a box now. I thought about eBay’ing some stuff, but I never got around to it.
THIS 100%. I got so pissed off at Unifi pushing the CK when you can run the controller on damn near anything. I have mine running on a rPi4 with a small battery backup. Cost me all of $35 (versus their what, $149?).
So, here is my flow. I use the Call Service node to update 3 device trackers (exposed in known_devices.yaml). You should be able to import it easily.
[{"id":"a51638c2.321cb","type":"tab","label":"Unifi Phone Presence","disabled":false,"info":""},{"id":"fbe0ddc5.2b347","type":"inject","z":"a51638c2.321cb","name":"5 minute interval","topic":"","payload":"","payloadType":"date","repeat":"300","crontab":"","once":true,"onceDelay":0.1,"x":130,"y":120,"wires":[["105bb72a.074db1"]]},{"id":"105bb72a.074db1","type":"Unifi","z":"a51638c2.321cb","name":"Client Devices","ip":"","port":8443,"site":"","command":"20","x":340,"y":120,"wires":[["c1643e33.6db3c"]]},{"id":"a0c7d12f.43af1","type":"debug","z":"a51638c2.321cb","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":770,"y":180,"wires":[]},{"id":"c1643e33.6db3c","type":"splitter","z":"a51638c2.321cb","name":"Split Clients","property":"payload","x":530,"y":120,"wires":[["bae46339.98dbc"]]},{"id":"bae46339.98dbc","type":"splitter","z":"a51638c2.321cb","name":"Split Again","property":"payload","x":790,"y":120,"wires":[["e00ed43e.641518"]]},{"id":"e00ed43e.641518","type":"function","z":"a51638c2.321cb","name":"Format Item","func":"//don't care about other entities\nmsg.payload_unsplit = {};\n\n//I only care about 3 entities, my phone, my wife's and my son's. Any others, don't care.\nvar ip = msg.payload.fixed_ip;\n\nif(ip == \"192.168.1.200\" || ip == \"192.168.1.201\" || ip == \"192.168.1.202\") {\n var tracker;\n //Unifi sets a wireless client as \"wired: true\" when it drops off WiFi and then it disappears.\n var is_away = msg.payload.is_wired;\n \n msg.original = msg.payload;\n \n switch(ip) {\n case '192.168.1.200':\n tracker = 'bill_phone';\n break;\n case '192.168.1.201':\n tracker = 'lyn_phone';\n break;\n case '192.168.1.202':\n tracker = 'ryan_phone';\n break;\n }\n \n msg.payload = {\n domain: 'device_tracker',\n service: 'see',\n data: {\n dev_id: tracker,\n location_name: is_away ? 'not_home' : 'home'\n }\n };\n return msg;\n }\n\n\n\n","outputs":1,"noerr":0,"x":330,"y":180,"wires":[["d591b492.ec2578"]]},{"id":"d591b492.ec2578","type":"api-call-service","z":"a51638c2.321cb","name":"Update Device Tracker","server":"df8e6220.fa7b2","version":1,"debugenabled":false,"service_domain":"","service":"","entityId":"","data":"","dataType":"json","mergecontext":"","output_location":"output","output_location_type":"msg","mustacheAltTags":false,"x":570,"y":180,"wires":[["a0c7d12f.43af1"]]},{"id":"df8e6220.fa7b2","type":"server","z":"","name":"Home Assistant","legacy":false,"hassio":false,"rejectUnauthorizedCerts":false,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":false}]
In a nutshell, every 5 minutes, the inject node gets the client devices from my controller. It then splits it (and splits again, because Unifi’s output). Then, in my function node, I do a check for 3 IP address (all our phone have static addresses for ease of use). When one device goes offline (aka leaves), Unifi first sets it to be “wired” (Why???) before it drops off completely. So, the is_away in my function node checks that property and then calls the device_tracker.see service with location_name: home/not_home.
As for tutorials for NodeRed, their website (and cookbook) are actually very well written. The NR subreddit is a good source of info as well. Beyond that, play around with it! There are literally as many integrations for NodeRed as there for HA. For instance, I don’t have my Harmony hubs exposed to HA at all. I use NodeRed for all my entertainment/media automations.
1 Like
Thanks for the code.
I copied it over and it seems to be working.
From my limited knowledge of the bug it sounds like that’s the same issue that the Unifi integration is running into.
Hopefully your code does a better job of handling the bug than the integration does.
I’ll keep an eye on it & let you know how it’s working.
Thanks again.
Yeah, that’s actually coming from Unifi’s API. It returns is_wired: true whenever a wireless client drops. Then, after an unspecified amount of time (usually between 3 and 5 minutes), it drops that record completely. It’s a very weird design decision.
I get that but I guess I’m not sure why that is an issue for the Unifi device tracker in HA?
I chimed in on the bug report thread and suggested that a “fix” could be to always regard a client as “wireless” after it has been reported as such for the first time by the controller. After that it really doesn’t matter if it’s reported as wired or wireless by the controller anymore since the user probably already assumes that the device is actually wireless and should always be tracked no matter how the controller reports it from then on.
And in the off-chance that the user really doesn’t want to still track it because it is all of a sudden wired then they could just disable the entity in the registry.
Started having issues recently with the integration also, constantly causing my input_select to change non-stop. Your solution works great, cheers.
1 Like