0.97: Apache Kafka, Fortigate, Twente Milieu

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.

Can “y’all” grab the old version of the Unifi component and install it as a custom component until the official one gets fixed?

Great progress of the system, congrats!
Any plans to have user permissions before 1.0? Still my wife and kids don’t like having so many things, so they dont have the app, and I want to get rid of owntracks too

Have you checked out Compact Custom Header? Can customize what parts of the UI individual users have access to.

1 Like

Just upgraded hass.io based install to to 0.97.2 and now nuheat is broken: components and platforms could not set up: nuheat. Please check your config. I have looked at changelog, and did not find anything about what need to be changed.

Error during setup of component nuheat
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/urllib3/contrib/pyopenssl.py", line 472, in wrap_socket
    cnx.do_handshake()
  File "/usr/local/lib/python3.7/site-packages/OpenSSL/SSL.py", line 1915, in do_handshake
    self._raise_ssl_error(self._ssl, result)
  File "/usr/local/lib/python3.7/site-packages/OpenSSL/SSL.py", line 1640, in _raise_ssl_error
    raise SysCallError(-1, "Unexpected EOF")
OpenSSL.SSL.SysCallError: (-1, 'Unexpected EOF')

For unifi device tracking: I added a new device and put in an alias in the USG for it. However, it doesn’t show up with that alias under device trackers. It shows up with original hostname. Any thoughts on this? Does something need to be rebooted for it to pick up the alias? I have restarted HA a couple of times with no joy.