A device registry entry describes a physical device, it can be linked to multiple entities and multiple integrations.
Device tracker entities will only be created if another entity has already registered a device registry entry, be it from a different entity from UniFi platform or from another integration.
If no entry exist then no device tracker entity gets created.
Heads up! Release 2.4.27 is now available as a stable release. I haven’t heard anyone running it with the integration but I run only the stable release so I have not verified any functionality.
Note: Any 3rd party modifications made to the OS of the console will be lost after the upgrade, proceed with caution if you modified your console’s OS.
IMPORTANT: Any 3rd party modifications or integrations (Home Assistant/“Poller”) can cause unexpected issues during or after the upgrade process. We recommend to completely remove/disable these integrations when performing the upgrade.
A device tracker entity gets created no matter what but it will only get automatically enabled if the client MAC address is associated with another integration.
for example, if the MAC address is associated with the ESPHome integration the device tracker entity gets created and automatically enabled but for a phone that has no other related integration the device tracker entity gets created but it stays disabled until the user enables it.
On another note has anything been looked at about the automatic removal of clients which have been removed (forgotten) from the Unifi controller?
That is still an issue for my integration. I had brought it up before but you had mentioned that some refactoring was going on so I was just wondering if that was on the timeline.
But in my case it’s not only device_tracker entities that get created, I get entire devices listed under the Unifi integration just like the access points (see picture above). This surely isn’t expected.
Also, it only happens with ESPHome devices and, after disabling the creation of new devices in the Unifi integration, only with those that were already there. I suppose this must be some short-circuit during the creation of the device_trackers.
That would be some kind of service to clean up old entities perhaps. Nothing planned right now.
Yes the refactoring is not done yet, from a platform perspective the network client device trackers are left and then how to handle updated options. So not much left before the refactoring is done unless Ive forgotten any details
Device entries represent a physical device can be referred to by entities from multiple integrations at the same time. The Device entry does not become a “UniFi device”.
Well, this is the situation whether you believe it or not and it does not make any sense. No other integration lists among its devices also the devices of other integrations just because they both record an IP address.
What is the point, other than bloating the interface with useless (and plain wrong) information, to show a device twice? If I see that the esphome integration has 38 devices and the Unifi integration has 42 devices, I’d think I have 80 devices when there’s really only 42 (38 Esphome and 4 APs).
Furthermore, only ESPhome devices get picked up, no Toon, no Wallbox, no IP cameras… they all have an IP and are visible by Unifi…
It’s not about mapping devices that report the same IP adress. The mapping is done when they both report matching serial numbers (MAC).
This is how it is supposed to work. Entities are unique resources whereas devices are a shared resource.
Unifi and esphome integrations are doing it properly. I looked at the toon integration and it doesn’t seem to declare the serial number of the device and can thus not be mapped to the same entry as unifi. I can’t say for your other integrations as I don’t know which they are.
I disagree this is as it should be, for 2 reasons. First, ESPhome does not list its devices as being also Unifi. Therefore only the Unifi integration shows this behaviour.
Secondly if I disable the “enable new entities” from the unifi menu, it will stop listing further devices found. Therefore this behaviour, as proper as it can be, can be disabled and it’s not mandatory. In fact, I only have 14 ESPhome devices (out of 20) showing up also in Unifi, because they were already there when I installed the Unifi integration. The others were not added as Unifi devices precisely because I disabled the option before adding them too.
For as much as I can think, I cannot find an use for having the same device show up in 2 different places.
All I am asking is that either the option is disabled by default at installation, leaving the decision to bloat one’s interface to the user, or that previously found devices can be removed from the Unifi integration.
Here comes a release note for Home Assistant 2023.3.0.
Nearly no action from me at all on the Home Assistant front, new role at work has left me brain drained in the evening , hoping to be back doing stuff shortly as I get more into it.
I’ve gotten requests to buy me a coffee, I’m on Github Sponsors if you appreciate my work.
Cheers!
/Robban
For feature requests of the integration post an issue at aiounifi github
Here comes a release note for Home Assistant 2023.4.0.
I’m happy to say that the refactoring is finally completed. There are a couple of small improvements needed to resolve a couple of old bugs, but after a lot of work since June 2022 the integration is finally reworked and strictly typed. This marks the point in time it is now possible to start adding more functionality moving forward.
As part of the final pieces of rework also means new issues might arise so if you have the possibility to run the dev track or beta and try the client device tracker I’d appreciate it.
Is there a minimum Unifi Controller software version requirement for Home Assistant 2023.4.0? I’m running 5.9.29 and upgraded my Home Assistant from 2023.3.6 to 2023.4.6. Once I did that, all my wifi connected devices would briefly show that they were home but then change to not_home. I then downgraded Home Assistant back to 2023.3.6 and my wifi devices worked as expected and showed that they were home.