Il faudrait quand même prévoir les grosses installations, car de toute façon il y a plus de « risques » qu’un utilisateur utilisant l’intégration Unifi ait une grosse installation réseau derrière.
Yes !!
Je regarde dans HA comment c’est presenté 
Je ne sais plus ^^
Voilà deja pour commencer !!^^
Une option par type, ca permet déjà de voir la 1ere base d’appareils !
Et après comme je le pensais, un selecteur (qu’il faudra innover, ça c’est pour @pierre-gilles ^^, parce qu’on peut faire mieux c’est certains, comme par exemple un selecteur avec champs de recherche)
On pourrait meme avoir un selecteur « Clients connectés » et un « Clients déconnectés » ?
(Dans mes logs, c’est environ 400 connectés par exemple)
1 case à cocher précoché pour « Infrastructure(s) »,
1 case à cocher prédécochée wlan(s)
1 case à cocher prédécochée Clients connectés avec selecteur
1 case à cocher prédécochée Clients avec déconnectés avec selecteur
Je ne sais pas ce que tu en penses ?
En soit meme sans dev core pour le moment c’est possible d’avoir le debut en remplacant le selecteur par un champs texte ou tu rentres tes ip de clients séparés par des « , » ou « ; »
Je pense qu’on va vers la même chose, de mon côté mon brainstorming avec l’IA m’a proposé ça :
Pour répondre aux besoins des utilisateurs (allant de celui qui veut juste faire de la détection de présence pour la famille à celui qui veut superviser toute sa baie réseau), nous pouvons organiser le filtrage en 4 catégories principales :
A. Filtrage par type d’équipement
- Équipements d’infrastructure Ubiquiti (
discover_infrastructure) (Booléen)- Actif par défaut : Découvre la console (UDM/UCG), les switches, les points d’accès Wi-Fi et prises intelligentes UniFi.
- Permet de mesurer le status/débit/uptime des équipements réseau eux-mêmes.
- Clients du réseau (
discover_clients) (Booléen)- Actif par défaut : Active la découverte des téléphones, ordinateurs, IoT, etc.
B. Filtrage des clients par statut et mode de connexion
- Seulement les clients actifs / connectés (
only_active_clients) (Booléen)- Désactivé par défaut : Si activé, l’intégration n’importe que les 127 clients actuellement connectés, en ignorant les 462 anciens clients enregistrés historiquement dans le contrôleur UniFi (
getKnownClients). - Bénéfice immédiat : Divise par 4 le nombre d’appareils remontés dans Gladys !
- Désactivé par défaut : Si activé, l’intégration n’importe que les 127 clients actuellement connectés, en ignorant les 462 anciens clients enregistrés historiquement dans le contrôleur UniFi (
- Mode de connexion des clients (
client_connection_type) (Sélection)- Options :
Tous(par défaut),Wi-Fi uniquement,Filaire uniquement. - Cas d’usage : La détection de présence pour les personnes (smartphones/montres) ne nécessite généralement que le Wi-Fi, les ordinateurs fixes ou télévisions filaires étant inutiles pour savoir si quelqu’un est à la maison.
- Options :
C. Filtrage par Réseau / SSID / VLAN
- Filtrage par SSIDs Wi-Fi (
allowed_ssids) (Liste / Texte séparé par des virgules)- Exemple :
Maison, IoT - Cas d’usage : Exclure automatiquement tous les téléphones/tablettes se connectant sur le réseau Wi-Fi
InvitesouTest.
- Exemple :
- Filtrage par Réseaux / VLANs (
allowed_networks) (Liste / Texte séparé par des virgules)- Exemple :
VLAN_Principal, VLAN_Domotique - Cas d’usage : Ignorer un sous-réseau complet (ex: VLAN Caméras de sécurité ou VLAN Invités).
- Exemple :
Avec tout ça je pense que ça permettrait d’y voir plus clair
Voilà on est d’accord !! C’est un tres bon plan de continuité 
Je me lance dans une nouvelle version
C’est à jour si tu veux tester
« Dans son plumard … y va de son tel pour tester rapido »…
Qui aurait cru ça possible il y a 1 mois encore …
Merci @guim31 , j’y vais de ce pas
Et paf !! On est bon pour l’infra !! Et pour les reseau !! Par contre il va meme jusqu’au port, mais il fait un device part port de switch … 
c’est trop le bazard ici ^^
Une feature commutateur par port d’un device infra serait top !!!
Mais sinon trop bien.
Bon par contre les clients ca passe pas
Afficher les parametres Adresse IP dans les fiches appareil serait un plus !
Dashboard retour d’etats /cmd :
Je ne comprends pas … Tu parles des retours d’états « Pas de valeur récente » ?
Nouvelle version 1.5.2 :
- Un switch 24 ports PoE génère désormais 1 seul appareil Gladys (contenant 25 fonctionnalités : Status + 24 ports PoE) au lieu de 25 cartes d’appareils séparées.
- L’adresse IP locale et l’adresse MAC apparaissent dans l’onglet Paramètres de chaque fiche d’appareil dans l’interface de Gladys.
- Si l’équipement (exemple UCG fiber ou Dream Machine) possède des ports PoE, un seul appareil dédié nommé
Switch PoE : Cloud Gateway Fiber(le nom défini de l’appareil) est généré. Il regroupe l’ensemble des ports PoE avec leurs noms explicites :Port 1 (Camera Entrance),Port 2 (AP Salon), etc.
Désolé, défaut de cette emplacement de test, on s’endort 
Non non, je parlais de la liste des 400 clients connectés du réseau dans la découverte ^^
Après retest, je comprends ta question, tu as chunké les découvertes, mais ça ne fonctionne pas ça, c’est ce que je te disais précédemment ^^ En fait si tu chunk, ton container renvoi 3 fois la requete discovered_device
Mais du coup pour chacune côté Gladys, ça remplace la liste précédente. Donc en faisant ça tu ne récupère que le dernier chunk :
en bref, là je ne vois que les 99 derniers device de la liste complète. Mais ça tu ne peux rien y faire de ton côté
La seule solution possible actuelle comme je te le disais c’est :
Super !! Je test ça ^^
La magie du videcoding aveugle… J’avais parlé du souci avec les grands nombre d’appareils, il a codé le chunk ce coquin, et moi j’ai rien vérifié (ce noob ).
Merci pour cette 1.5.2 
J’ai relancé une découverte complète sur mon infra (UDM Pro, plusieurs switchs 8 et 24 ports, plusieurs SSID). Voilà mes retours, j’ai été fouiller un peu ton code pour te mâcher le travail sur la localisation des points.
1. Switchs 8 ports : équipement dédoublé, et 4 ports sur 8
La présence réseau de l’équipement et les ports PoE arrivent comme deux devices Gladys distincts (unifi-gateway-<mac> et unifi-poe-switch-<mac>, même MAC) :
Je vois dans src/devices/index.js que c’est volontaire : pour chaque device d’infra tu pushes gatewayBlueprint.buildDevice(), puis poeSwitchBlueprint.buildDevice() si hasPoePorts. Est-ce un choix assumé ?
De mon point de vue d’utilisateur, un switch = un équipement dans Gladys, avec la présence + les ports en features. Deux cartes pour le même matériel, ça alourdit la liste (et chez moi ça double vite le nombre de devices, sujet qu’on avait déjà croisé au post 20 avec la limite de 200). Si tu veux garder la séparation pour ceux qui préfèrent, une option de config merge_switch_devices (défaut : fusionné) ferait le job. Attention quand même : fusionner change les external_id, il faudra prévoir une migration pour ceux qui ont déjà nommé/rangé leurs devices.
Pour les 4 ports sur 8 : après lecture de src/devices/poePort.js, c’est logique, tu filtres sur
if (port.poe_caps && port.poe_caps > 0 && port.port_idx).
Mon USL8LP8 (UniFi Switch Lite 8 PoE) a bien 8 ports dont seulement 4 PoE — donc le comportement est correct si l’objectif est le pilotage PoE uniquement. Ce n’est donc pas un bug, mais deux remarques :
- ce n’est pas évident pour l’utilisateur : une petite note dans le README (« seuls les ports PoE sont exposés ») éviterait le doute ;
- ce serait top d’exposer tous les ports avec ce qui a du sens par port : état du lien (up/down), vitesse négociée, et l’activation/désactivation du port si l’API le permet — le pilotage PoE restant réservé aux ports PoE. Là on aurait une vraie vision switch.
2. Switchs 24 ports : aucun port remonté
Aucune feature port, pas même le device « Switch PoE » associé. Vu le code, ça veut dire que hasPoePorts est faux. Deux hypothèses :
- mes 24 ports sont des modèles non-PoE → comportement attendu (mais alors ça renforce le point 1 : sans les ports non-PoE, ces switchs n’ont strictement rien à afficher) ;
- certains firmwares remontent l’info PoE via
port_poe: trueplutôt que viapoe_caps. Un filtre plus permissif du type
const isPoe = Boolean(p.port_poe) || Number(p.poe_caps) > 0;
sécuriserait le cas.
Dis-moi ce dont tu as besoin comme trace (un logger.debug du port_table sur un device donné ?) et je te fais un dump de mes modèles 24 ports, je te confirme lequel des deux cas c’est.
3. Dream Machine Pro : IP publique à la place de l’IP d’administration + multi-WAN
C’est le point qui me gêne le plus. Dans 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 });
}
Sur une gateway, unifiDevice.ip correspond à l’IP WAN (publique), pas à l’IP locale. Résultat : IP_ADDRESS contient mon IP publique. Ma proposition :
IP_ADDRESS→ IP locale d’administration de la gateway (celle qu’on saisit dans la config de l’intégration, ou l’IP de l’interface LAN remontée par le contrôleur) ;IP_ADDRESS_PUBLIC_1→ IP publique du WAN principal ;IP_ADDRESS_PUBLIC_2→ IP publique du WAN secondaire / secours.
Chez moi les deux WAN sont actifs en permanence : le WAN1 sur la voie principale et le WAN2 sur la voie de secours, qui sert en réalité mon LAN PRO / WiFi PRO en tout temps + secours de mes réseau locaux Perso / Camping. Donc les deux IP publiques sont utiles simultanément, ce n’est pas juste du failover, ils font les 2. Les objets wan1 / wan2 du device UniFi devraient te donner ce qu’il faut.
Corollaire : il n’y a aujourd’hui qu’un seul couple de features WAN Upload Speed / WAN Download Speed. En dual-WAN il en faudrait un par lien (WAN1 Up/Down, WAN2 Up/Down), sinon on ne sait pas ce qu’on mesure. Et l’état up/down de chaque WAN serait très pratique pour déclencher des scènes de bascule.
Enfin, comme pour les switchs, la DMP (Dream Machine) ne remonte aucun port (normal, pas de PoE dessus) — mais l’état des ports LAN serait un vrai plus.
4. Réseaux Wi-Fi
RAS, ça fonctionne bien : chaque SSID arrive avec un commutateur, et ça coupe/active le réseau complet comme attendu. Quelques idées si tu cherches de la matière :
- le nombre de clients connectés par SSID (feature numérique, super pour les scènes et l’historique) ;
- l’exposition du réseau invité / la possibilité de régénérer un mot de passe invité ;
- éventuellement l’activation par point d’accès plutôt que globale.
Proposition
Plutôt que de te faire une liste de doléances, je te propose de forker le dépôt et de te faire des PR sur ces points, dans l’ordre que tu voudras. Je pensais découper comme ça :
- fusion switch présence + ports en un seul device Gladys, avec option de config et migration des
external_id. - détection PoE plus permissive (
port_poeen plus depoe_caps) pour débloquer les cas de switchs qui ne remontent rien ; - exposition de tous les ports (lien / vitesse), pas seulement les PoE ;
- IP locale vs IP publiques sur la gateway (
IP_ADDRESS,IP_ADDRESS_PUBLIC_1/2) — la plus simple et la plus utile tout de suite ; - dual-WAN : features de débit et d’état par lien ;
Dis-moi juste :
- si tu es d’accord sur le principe des PR ;
- si tu as des conventions à respecter (tests, format des commits, branche cible) ;
- et quel(s) point(s) t’intéressent en priorité, histoire que je ne parte pas sur un chantier que tu as déjà en cours.
En attendant je continue les tests et je te remonte tout ce que je trouve. Merci encore pour le boulot, l’intégration est déjà bien avancée 
Alors tout d’abord un GRAND merci !
C’est compliqué de faire un retour aussi complet !
Je prend note de tout ça, je pense avoir tout compris 
Par contre je dois te dire que même si je sais ce qu’est une PR, je n’ai absolument AUCUNE idée de ce que je vais devoir en faire. Dans ma tête quand il y a une PR il faut vérifier le code (j’en suis incapable) et merge si tout est ok (je ne sais pas le faire non plus).
Donc je sais pas trop quoi te répondre… Désolé !
Mais non aucun soucis ^^ T’inquiète ^^!!
Déjà :
Elle sera proposée dans ton repo, si tu travail directement avec l’IA, tu pourras lui demander la review puis de te déclencher une image de « :dev » (je pense que c’est déjà ce que tu fais pour cette version non ?)
Tu peux lui demander de commenter directement dans la PR (pour que je corrige si des choses ont échappé à la mienne)
Et si sur tes tests tout est ok, tu pourras directement lui demander de la merger (et sinon c’est juste un clic en bas ^^)
Mais sans souci, on pourra revoir ensemble !!
Sinon, tu peux lui partager le post et faire la 1ere mouture de ton coté => Mais évite de travailler directement sur master si c’est déjà ce que tu fais ? Ou tu travaille juste par branches / mergées dans master ?
Il y a un truc à corriger ?
Actuellement j’ai juste une branche main, et rien d’autre, pas de :dev ou quoi que ce soit.
On est au sommet des bonnes pratiques 
Je voudrais quand même te répondre sur un point (si jamais tu veux te lancer dans des PR), celui des équipements dédoublés. En fait c’est voulu, mais cela vient du fait que dans mes premiers essais, si je ne dédoublais pas les appareils je me retrouvais avec quelque chose du style :
- APPAREIL 1
- Presence
- Debit up
- Debit down
- Commutateur
- Commutateur
- Commutateur
- etc…
Avec l’impossibilité de savoir distinguer les commutateurs entre eux.
Après c’est peut être parce que Gemini étant moins doué que Claude, il n’a pas réussi à me pondre un truc fonctionnel à ce niveau !
Ce n’est plus une limite de poids, mais une limite de nombre !!
Mais elle est pas déconnante je pense cette limite de nombre => + de 200 appareils en liste dans la page découverte, sans champs de recherche !! Humhum
@guim31 à déjà ajouté un prétri pour tout les appareils qui sont sur un SSID.
La proposition complémentaire serait d’avoir un paramètre dans la liste des configurations qui remonte les devices permettant de sélectionner ceux qu’on souhaite « Découvrir » seulement à la facon de ce que fait HA, pratique pour ces cas là :
Ce champs à la différence de HA serait idéal avec un champs de recherche pour trouver directement les appareils qu’on souhaite
=> Ca permet par exemple de surveiller son smartphone, l’extinction/la déconnexion d’un appareil surveillé, etc !