We should still plan for large installations, because in any case, there are more « risks » that a user using the Unifi integration will have a large network installation behind it.
Yes!!
I’m looking in HA how it’s presented 
I don’t remember anymore ^^
Here you go to get started!^^
One option per type, which already allows you to see the first base of devices!
And then, as I thought, a selector (which will need to be innovated, that’s for you @pierre-gilles ^^, because we can do better, that’s for sure, like for example a selector with a search field)
Could we even have a « Connected Clients » selector and a « Disconnected Clients » one?
(In my logs, there are about 400 connected, for example)
1 pre-checked box for « Infrastructure(s) »,
1 pre-checked box for wlan(s)
1 pre-checked box for Connected Clients with selector
1 pre-checked box for Disconnected Clients with selector
I don’t know what you think about it?
In itself, even without development, it’s possible to have the beginning by replacing the selector with a text field where you enter your client IPs separated by « , » or « ; »
I think we’re heading in the same direction. On my end, my brainstorming with the AI suggested this:
To meet user needs (ranging from someone who just wants to detect presence for their family to someone who wants to monitor their entire network bay), we can organize filtering into 4 main categories:
A. Filtering by Equipment Type
- Ubiquiti Infrastructure Equipment (
discover_infrastructure) (Boolean)- Active by default: Detects the console (UDM/UCG), switches, Wi-Fi access points, and UniFi smart outlets.
- Allows measuring the status/throughput/uptime of the network equipment itself.
- Network Clients (
discover_clients) (Boolean)- Active by default: Enables detection of phones, computers, IoT devices, etc.
B. Filtering Clients by Status and Connection Mode
- Only Active/Connected Clients (
only_active_clients) (Boolean)- Disabled by default: If enabled, the integration only imports the 127 currently connected clients, ignoring the 462 historical clients recorded in the UniFi controller (
getKnownClients). - Immediate benefit: Reduces by 4 the number of devices reported in Gladys!
- Disabled by default: If enabled, the integration only imports the 127 currently connected clients, ignoring the 462 historical clients recorded in the UniFi controller (
- Client Connection Mode (
client_connection_type) (Selection)- Options:
All(default),Wi-Fi only,Wired only. - Use case: Presence detection for people (smartphones/watches) usually only requires Wi-Fi, with fixed computers or wired televisions being useless for knowing if someone is at home.
- Options:
C. Filtering by Network / SSID / VLAN
- Wi-Fi SSID Filtering (
allowed_ssids) (List / Comma-separated text)- Example:
Home, IoT - Use case: Automatically exclude all phones/tablets connecting to the
GuestsorTestWi-Fi network.
- Example:
- Network/VLAN Filtering (
allowed_networks) (List / Comma-separated text)- Example:
Main_VLAN, Home_Automation_VLAN - Use case: Ignore an entire subnetwork (e.g., Security Camera VLAN or Guest VLAN).
- Example:
With all this, I think it would make things clearer.
There we agree!! It’s a really good continuity plan 
I’m diving into a new version
It’s up to date if you want to test
« In his bed … he’s going to use his phone to test quickly »…
Who would have thought that possible just one month ago …
Thanks @guim31, I’m on it right away
Et paf!! We’re good for the infra!! And for the networks!! But it even goes to the port, but it makes a device per switch port… 
It’s a total mess here ^^
A switch feature per device port would be awesome!!!
But otherwise, it’s great.
Well, but the clients don’t work
Displaying the IP address parameters in the device cards would be a plus!
Dashboard status return /cmd:
I don’t understand… Are you talking about the « No recent value » status returns?
New version 1.5.2:
- A 24-port PoE switch now generates 1 single Gladys device (containing 25 features: Status + 24 PoE ports) instead of 25 separate device cards.
- The local IP address and MAC address appear in the Settings tab of each device card in the Gladys interface.
- If the equipment (e.g., UCG fiber or Dream Machine) has PoE ports, a single dedicated device named
PoE Switch: Cloud Gateway Fiber(the device’s defined name) is generated. It groups all PoE ports with their explicit names:Port 1 (Entrance Camera),Port 2 (Living Room AP), etc.
Sorry, this test location is boring, we’re falling asleep 
No no, I was talking about the list of 400 connected clients on the network in the discovery ^^
After retesting, I understand your question, you’ve chunked the discoveries, but it doesn’t work, that’s what I told you before ^^ In fact, if you chunk, your container returns the request discovered_device three times
But then, for each one on Gladys’ side, it replaces the previous list. So by doing that, you only get the last chunk:
In short, now I only see the last 99 devices from the complete list. But you can’t do anything about that on your side
The only possible solution right now, as I told you, is:
Awesome!! I’ll test that ^^
The magic of blind videcoding… I had mentioned the issue with the large number of devices, and he coded the chunk, that rascal, and I didn’t check anything (what a noob ).
Thanks for this 1.5.2 
I restarted a complete discovery on my infrastructure (UDM Pro, several 8 and 24 port switches, several SSIDs). Here are my feedbacks, I went to look a bit into your code to help you with the localization of the points.
1. 8 Port Switches: Duplicated Equipment, and 4 Ports Out of 8
The network presence of the equipment and the PoE ports arrive as two distinct Gladys devices (unifi-gateway-<mac> and unifi-poe-switch-<mac>, same MAC):
I see in src/devices/index.js that this is intentional: for each infrastructure device you push gatewayBlueprint.buildDevice(), then poeSwitchBlueprint.buildDevice() if hasPoePorts. Is this an intentional choice?
From my user perspective, a switch = one piece of equipment in Gladys, with the presence + the ports as features. Two cards for the same hardware, it clutters the list (and at my place it quickly doubles the number of devices, a subject we had already encountered in post 20 with the 200 device limit). If you want to keep the separation for those who prefer it, a config option merge_switch_devices (default: merged) would do the job. Be careful though: merging changes the external_id, you will need to plan a migration for those who have already named/sorted their devices.
For the 4 ports out of 8: after reading src/devices/poePort.js, it makes sense, you filter on
if (port.poe_caps && port.poe_caps > 0 && port.port_idx).
My USL8LP8 (UniFi Switch Lite 8 PoE) indeed has 8 ports of which only 4 are PoE — so the behavior is correct if the goal is PoE control only. This is therefore not a bug, but two remarks:
- it’s not obvious for the user: a small note in the README (« only PoE ports are exposed ») would avoid doubt;
- it would be great to expose all ports with what makes sense per port: link state (up/down), negotiated speed, and port activation/deactivation if the API allows it — PoE control remaining reserved for PoE ports. There we would have a real switch vision.
2. 24 Port Switches: No Ports Reported
No port feature, not even the associated « PoE Switch » device. From the code, this means that hasPoePorts is false. Two hypotheses:
- my 24 ports are non-PoE models → expected behavior (but then this reinforces point 1: without the non-PoE ports, these switches have strictly nothing to display);
- some firmwares report the PoE info via
port_poe: truerather than viapoe_caps. A more permissive filter of the type
const isPoe = Boolean(p.port_poe) || Number(p.poe_caps) > 0;
would secure the case.
Tell me what you need as a trace (a logger.debug of the port_table on a given device?) and I’ll dump my 24 port models, I’ll confirm which of the two cases it is.
3. Dream Machine Pro: Public IP Instead of Management IP + Multi-WAN
This is the point that bothers me the most. In src/devices/gateway.js:
const deviceIp = typeof unifiDevice.ip === 'string' ? unifiDevice.ip.trim() : '';
const params = [{ name: 'MAC_ADDRESS', value: mac.toUpperCase() }];
if (deviceIp) {
params.push({ name: 'IP_ADDRESS', value: deviceIp });
}
On a gateway, unifiDevice.ip corresponds to the WAN IP (public), not the local IP. Result: IP_ADDRESS contains my public IP. My proposal:
IP_ADDRESS→ Local management IP of the gateway (the one you enter in the integration config, or the IP of the LAN interface reported by the controller);IP_ADDRESS_PUBLIC_1→ Public IP of the main WAN;IP_ADDRESS_PUBLIC_2→ Public IP of the secondary/backup WAN.
At my place both WANs are permanently active: WAN1 on the main path and WAN2 on the backup path, which actually serves my PRO LAN / PRO WiFi at all times + backup for my personal / camping local networks. So both public IPs are useful simultaneously, it’s not just failover, they do both. The wan1 / wan2 objects of the UniFi device should give you what you need.
Corollary: there is currently only one pair of features WAN Upload Speed / WAN Download Speed. In dual-WAN, one would need one per link (WAN1 Up/Down, WAN2 Up/Down), otherwise we don’t know what we are measuring. And the up/down state of each WAN would be very practical to trigger failover scenes.
Finally, like the switches, the DMP (Dream Machine) does not report any ports (normal, no PoE on it) — but the state of the LAN ports would be a real plus.
4. Wi-Fi Networks
RAS, it works well: each SSID arrives with a switch, and it cuts/activates the complete network as expected. A few ideas if you are looking for material:
- the number of connected clients per SSID (numeric feature, great for scenes and history);
- exposure of the guest network / the possibility to regenerate a guest password;
- possibly activation per access point rather than globally.
Proposal
Rather than giving you a list of complaints, I propose to fork the repository and make PRs on these points, in the order you want. I was thinking of breaking it down like this:
- merge switch presence + ports into a single Gladys device, with config option and migration of
external_id. - more permissive PoE detection (
port_poein addition topoe_caps) to unlock cases of switches that don’t report anything; - exposure of all ports (link / speed), not just PoE;
- local IP vs public IPs on the gateway (
IP_ADDRESS,IP_ADDRESS_PUBLIC_1/2) — the simplest and most useful right away; - dual-WAN: throughput and state features per link;
Just tell me:
- if you agree with the PR principle;
- if you have conventions to respect (tests, commit format, target branch);
- and which point(s) interest you in priority, so that I don’t start on a project you already have in progress.
In the meantime, I continue testing and I’ll report everything I find. Thanks again for the work, the integration is already well advanced 
First of all, a BIG thank you!
It’s complicated to give such a complete review!
I’ll take note of all this, I think I’ve understood everything 
But I have to tell you that even though I know what a PR is, I have ABSOLUTELY NO IDEA what I’m supposed to do with it. In my mind, when there’s a PR, you have to check the code (I can’t do that) and merge if everything is okay (I don’t know how to do that either).
So I’m not sure how to respond… Sorry!
Oh no worries at all ^^
Don’t worry ^^!!
First of all:
It will be proposed in your repo. If you work directly with the AI, you can ask it to review and then trigger a « :dev » image for you (I think that’s already what you’re doing for this version, right?)
You can ask it to comment directly in the PR (so I can fix anything I might have missed)
And if everything is okay in your tests, you can directly ask it to merge (and if not, it’s just one click at the bottom ^^)
But no worries, we can go over it together!!
Otherwise, you can share the post with it and do the first draft on your side => But avoid working directly on master if that’s what you’re already doing? Or do you just work with branches and merge into master?
Is there something to fix?
Right now I only have a main branch, and nothing else, no :dev or anything.
We’re at the top of best practices 
I’d still like to answer you on one point (in case you ever want to make PRs), that of duplicated equipment. Actually, it’s intentional, but it’s because in my first attempts, if I didn’t duplicate the devices, I ended up with something like this:
- DEVICE 1
- Presence
- Upload speed
- Download speed
- Switch
- Switch
- Switch
- etc…
With the impossibility of distinguishing the switches from each other.
After that, maybe it’s because Gemini is less skilled than Claude, and it couldn’t come up with something functional at this level!
It’s no longer a weight limit, but a number limit!!
But I think this number limit is not stupid => more than 200 devices in the discovery page, without a search field!! Humhum
@guim31 has already added a pre-sort for all devices that are on an SSID.
The complementary proposal would be to have a parameter in the list of configurations that brings up the devices, allowing you to select those you want to « Discover » only in the way that HA does, practical for these cases:
This field, unlike HA, would be ideal with a search field to directly find the devices you want
=> This allows, for example, to monitor your smartphone, the shutdown/disconnection of a monitored device, etc!