Post edited above (hit replybefore other information added)
Have you tried adding these, because they work already for me - I only have wireless devices now using 0.97.1
The PR’s with these functions were merged but the docs didn’t get updated in line with the PR’s
Having all the clients that are connected to my network show up in HA when I will never ever need to track them is frustrating to say the least!
I don’t understand the train of thought behind it
Especially when there’s no way to easily delete entities from the UI and I I have to search through core.entity_registry file to locate each and every entity.
It would’ve been great to include a filter to which clients we wish to include/exclude
4 Likes
That looks like only a partial resolution to the problem.
The way I read that is it’s an “all or nothing” thing.
It seems that you can select to not track any clients or devices or wired clients at all or you can track all clients or devices or wired clients. But you can’t only track some of those things.
I can see how eliminating the wired clients will help somewhat but in many networks the wired devices aren’t the major number of devices. It’s the wireless stuff that is the largest (and, as pointed out above, most fluid) part of a users home network.
Can anyone explain the difference between “clients” & “devices”? It’s not obvious to me. Maybe that’s because I don’t (yet…) use the ubiquiti gear.
No. that’s the problem.
I believe ‘clients’ are as you’d probably expect, i.e. devices connected to the network e.g. phones, PCs etc.
Devices are I think, network devices e.g. APs, Switches, Routers etc.
But I’m not the expert, I’m in the situation where I don’t want to upgrade to 97 because this situation seems ridiculous to me, I have only recently moved to Unifi and only a couple of weeks ago implemented the HA integration so am not sure I fully understand what will happen when I ‘upgrade’ (which in this case won’t seem like one).
4 Likes
Yes, that’s a correct interpretation of the terminology that the UniFi platform provides. This new integration directly exposes those concepts into the Home Assistant world (e.g., the difference between wired and wireless clients, etc.)
I am just saddened by this turn of events. The UniFi-based presence mechanism is a core part of my Home Assistant usage, and was working really well as a reliable and inexpensive (in terms of battery life for the two phones that I track) solution. I really don’t want to shift to some other way to detect devices (like the nmap-based solution) because this is going to cause needless additional activity for the radio in the phones, impacting battery life.
I don’t know if its possible to maintain the older UniFi component as a custom component or if the infrastructure it depends upon is also going away. Maybe just a script to bang against the UniFi API, looking for the two mac addresses I’m interesting in, and invoking the device_tracker.see service?
I understand the architectural approach to expose all of the attributes associated with some external entity, and allowing a choice to be made… if that’s a bounded and static set. When it’s completely unbounded and dynamic, that’s another matter and it seems necessary to have a filtering mechanism available.
What gives you reason to say that?
The phone’s going to have to turn on the transmitter in the Wi-Fi radio to respond to the ICMP echo or whatever nmap scanning traffic that is going on.
The phone is always going to have to maintain its registration with the Wi-Fi access point, so watching that is “free”.
2 Likes
Yeah sorry that was my bad comprehension skills. I though you meant the unifi tracker method had changed, when you were actually referring to dropping unifi and using another method.
I believe there might be something wrong with the 0.97 release. I was using 0.97.1 for a few days, installed it on Friday at 7pm (from 0.96.5). It was good all Saturday and this morning (Sunday) the web UI was down, appeared to be down since 4:30am. After a shotgun approach, I’ve found that downgrading to 0.96.5 solved the issue. I first tried downgrading to 0.97.0 and it was still busted.
core-ssh:~# hassio homeassistant update --version=0.97.0
Error: Unknown Error, see logs
core-ssh:~# hassio
To my dismay, the logs don’t show anything of value from what I can tell.
Here’s the thread I started regarding the issue:
I gotta agree with folks about the Unifi platform changes. I keep a segregated main network so I don’t have hundreds of devices that may end up in HASS, but i have a bunch that are unnecessary. The platform is for device tracking. Why do I need to track/know about the status of things like my Amazon Echos that never leave the house? There’s no need for them to be tracked/added. They’re just going to clutter up the dev-tools states page, the recorder, and databases without adding anything meaningful/useful.
4 Likes
Until a better solution is in place I’ve downgraded to 0.96.5
You can still limit the tracked devices to certain ssid’s, so if you have your network divided up it works great still.
I have all my IOT devices on one VLAN with their own SSID. My personal devices on another and guests on a third and so fourth.
That works to cut out a number of devices, but what about all of the wired ones? I need to track two cell phones. That’s it. I don’t want to track or monitor other network devices. There are other integrations for if I do.
Wired devices can be excluded. It seems the current doco is out of sync with options available.
In my case I have EdgeRouter and UniFi APs, so only my wireless devices are seen.
Can see how this would be an issue if you have a pure UniFi setup.
Perhaps detecting all your devices is a good theft detection system?
1 Like
dont_track_wired_clients: 'true' seems to work
I always create a snapshot before upgrading and luckily I did so just before this upgrade, will revert back until hopefully the devs hear our cries and fix the unifi component…
Here’s a use-case I was planning to deploy in a new Home Assistant installation… I do volunteer work at a community library (they used to be part of the county library system until they got jettisoned/closed due to budget shortfalls 5 or 6 years ago.) A couple of use volunteers updated their internal network and library patron workstations. We put in a UniFi-based Wi-Fi network that’s an open Wi-Fi network for the library patrons to use.
I would like to have a handful fo device trackers for the library volunteers that staff the desk and assist with the patrons. While the library’s workstations are on a non-public network, the volunteers phones are not – the volunteers are older, retired people and not very tech savvy – they just use the public network along with hundreds of library users that come and go. I would like to note when they show up and when they leave as part of automations for lighting and other stuff – if there’s still someone around, then don’t turn things off.
So it’s really great that I can exclude wired devices and specific SSID’s, but that’s not a adequate filtering mechanism.
My situation at home also has way more wifi devices than necessary that don’t need to be tracked.
Imagine what a bluetooth-based tracker using this same policy is going to do if the device scanning is in a populated area and people are wandering by with their phones. That’s going to be a nightmare. I’ve read that architectural decision reference earlier in the thread, and I think the scenario they had in mind was some sort of API, like to a weather prediction service that returns back a whole collection of different types of information. That’s a bound set of alternatives that you can consider once; not an every growing number of alternatives.