# Integration externe - Unify network

**URL:** <https://community.gladysassistant.com/t/integration-externe-unify-network/10426>\
**Category:** Développement\
**Tags:** integration-externe\
**Created:** [Août 1, 2026, 4:21 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426 "2026-08-01T16:21:58Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Août 2, 2026, 7:55 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/41 "2026-08-02T07:55:51Z")

</div>

> [@Terdious](#):
>
> 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

Sauf que c’est déjà le principe de la page «&nbsp;Découverte&nbsp;» ça !

Donc pourquoi ne pas juste augmenter la limite ?

---

<div class="post-metadata">

**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\
**Post date:** [Août 2, 2026, 8:04 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/42 "2026-08-02T08:04:39Z")

</div>

Parce que déjà à 100 appareils … c’est illisible ^^ Alors 950 … je te laisse imaginer

Et sans champs de recherche … humhum ^^ apres c’est possible hein (le CTRL+F du navigateur fonctionne) mais côté user friendly … ^^

Si tu as une autre propo, avec plaisir 😅

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Août 2, 2026, 8:12 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/43 "2026-08-02T08:12:24Z")

</div>

J’augmente la limite, et je rajoute un filtre de recherche !

---

<div class="post-metadata">

**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\
**Post date:** [Août 2, 2026, 8:12 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/44 "2026-08-02T08:12:59Z")

</div>

Parfait ^^ Merci beaucoup ^^

---

<div class="post-metadata">

**Author:** ![guim31](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/guim31/32/4840_2.png) [@guim31](https://community.gladysassistant.com/u/guim31)\
**Post date:** [Août 2, 2026, 8:31 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/45 "2026-08-02T08:31:17Z")

</div>

Du coup @Terdious il faut qu’on se mette d’accord sur notre manière de fonctionner. Moi je n’ai absolument rien contre le fait que tu fasses des PR, mais je n’ai pas créé cette intégration pour te filer du travail en plus !

Je te laisse me dire, moi je suis ouvert à tout !!

---

<div class="post-metadata">

**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\
**Post date:** [Août 2, 2026, 8:35 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/46 "2026-08-02T08:35:37Z")

</div>

Ouioui !! aucune inquietude (et le boulot ne m’embête jamais, ça nous apporte à tous ^^

Je met juste beaucoup de temps a te rédiger le message de réponse, pour qu’il soit au mieux ficeler et compréhensible en le faisant avec l’IA (présentation bien meilleur). Bon du coup il est long, mais je relis tout/corrige, normalement tout est clair, et au final tu verras pas si compliqué ^^

Chaque petite Intégration Externe devient un micro projet Gladys indépendant ^^

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Août 2, 2026, 8:49 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/47 "2026-08-02T08:49:47Z")

</div>

Hop :

> <https://github.com/GladysAssistant/Gladys/pull/2748>
>
> \### Description
> 
> This PR increases the maximum number of devices that can be dis…covered in a single request from 200 to 2000, along with corresponding increases to the HTTP body size limits to accommodate this change.
> 
> \*\*Rationale\*\*: Network-based integrations (UniFi, router-based presence detection, etc.) publish one discovered device per client on the network. Large home or small business setups can easily reach ~1000 devices, which was previously hitting the 200-device limit. The discovery list is memory-only and cheap to maintain.
> 
> \*\*Changes\*\*:
> \- \`MAX\_DISCOVERED\_DEVICES\`: 200 → 2000 in \`server/lib/external-integration/constants.js\`
> \- \`HOST\_API\_JSON\_BODY\_LIMIT\`: 5 MB → 20 MB in \`server/api/middlewares/jsonBodyMiddleware.js\`
> \- Updated documentation in \`docs/specs/external-integrations.md\` to reflect the new limits and explain the rationale
> \- Updated test expectations to match the new limits
> 
> The 20 MB body limit is sized so that device count (not byte count) remains the binding limit: 2000 devices at ~8 kB worst case (feature-heavy devices like Shelly Pro 3EM with 24 features) fit comfortably under 20 MB. The limit is only mounted behind integration authentication, so unauthenticated callers never trigger large buffer allocations.
> 
> \### Checklist
> 
> \- \[x\] Tests pass: Updated unit tests in \`externalIntegration.setDiscoveredDevices.test.js\`, \`jsonBodyMiddleware.test.js\`, and \`integrationHost.controller.test.js\` to reflect new limits
> \- \[x\] No breaking changes: This is a backwards-compatible increase in limits
> \- \[x\] Documentation updated: Specs and comments clarify the new limits and reasoning
> 
> https://claude.ai/code/session\_01SQLxdwQpF7eft2W51rmcx9
> 
> 
> \## Summary by CodeRabbit
> 
> \* \*\*New Features\*\*
> \* Increased the maximum number of discovered devices per publication from 200 to 2,000.
> \* Increased the host API JSON payload limit from 5 MB to 20 MB.
> \* Added search for discovered devices by name or external ID, with localized empty-state messages.
> 
> \* \*\*Bug Fixes\*\*
> \* Improved device creation reliability when filtering discovery results.
> 
> \* \*\*Documentation\*\*
> \* Updated integration API and SDK documentation for the expanded limits.
> 
> \* \*\*Tests\*\*
> \* Updated validation and payload-size coverage for the new limits.

---

<div class="post-metadata">

**Author:** ![guim31](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/guim31/32/4840_2.png) [@guim31](https://community.gladysassistant.com/u/guim31)\
**Post date:** [Août 2, 2026, 8:50 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/48 "2026-08-02T08:50:13Z")

</div>

Damn… ça laqisse de la marge ça ^^

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Août 2, 2026, 8:53 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/49 "2026-08-02T08:53:49Z")

</div>

J’ai testé, le search marche bien !

C’est mergé, ça partira dans la prochaine release de Gladys (aujourd’hui)

---

<div class="post-metadata">

**Author:** ![guim31](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/guim31/32/4840_2.png) [@guim31](https://community.gladysassistant.com/u/guim31)\
**Post date:** [Août 2, 2026, 11:55 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/50 "2026-08-02T11:55:11Z")

</div>

Je suis tellement faible …

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/4/6/4634e00210b5d162750cca3bc7e52628b185f447.png)

😇

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Août 2, 2026, 11:55 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/51 "2026-08-02T11:55:41Z")

</div>

Yeees bienvenue !!

---

<div class="post-metadata">

**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\
**Post date:** [Août 2, 2026, 2:14 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/52 "2026-08-02T14:14:16Z")

</div>

> [@guim31](#):
>
> 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 😛

🫣 😉 😂 Normal, c’est les débuts, on est tous passés par là !

Mais oui, à éviter absolument : `main` c’est la branche que **tout le monde** utilise. Une modif qui casse, et c’est tes utilisateurs qui la prennent en pleine figure.

* * *

## La règle simple

Chaque modification (sauf assurance totale sur un truc ultra sommaire) **doit** se faire sur une branche à part, que tu montes en image taguée `:dev`, ou `:dev-tartempion` pour un test spécifique avec quelqu’un.

Concrètement, ton cycle devient :

```auto
main ──► branche de travail ──► (test image :dev) ──► retour dans main

```

Et pas grand-chose de plus. En ligne de commande c’est littéralement :

```bash
git checkout main
git pull
git checkout -b fix-ip-gateway # ta branche de travail
# ... tu bosses, tu commits ...
git push -u origin fix-ip-gateway

```

Deux avantages immédiats :

- si ça casse chez quelqu’un, tu reviens en arrière en supprimant/annulant **une** branche, pas en démêlant 15 commits mélangés dans `main` ;
- tu peux avoir plusieurs chantiers en parallèle sans qu’ils se marchent dessus.

## Les PR : pas obligatoires, mais très pratiques

À noter : **les PR ne sont pas obligatoires**. Tu peux très bien faire `main` → branche de travail → `main` tout seul, sans jamais ouvrir de PR.

C’est surtout utile :

- quand quelqu’un de l’extérieur veut te proposer quelque chose (mon cas) ;
- quand tu veux partager une avancée / une préparation avant de la sortir.

Perso je bosse beaucoup en PR **même sur mes propres repos** , parce que :

- tu as un vrai historique, lisible, avec le _pourquoi_ de chaque changement ;
- tu peux commenter directement dans le code ;
- tu peux avoir des sujets au long cours sans avoir à te souvenir de quelle branche il s’agissait — tout le contexte est dans la PR.

* * *

## Ce que tu vas concrètement devoir faire d’une PR

> [@guim31](#):
>
> 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).

Alors bonne nouvelle : **tu as déjà tout ce qu’il faut dans ton repo** 😅

**D’abord, le plus important : une PR ne change RIEN chez toi tant que tu ne cliques pas.**  
Tant que tu n’as pas appuyé sur le bouton vert, ton `main` est intact, ton image `:latest` est intacte, tes utilisateurs ne voient rien. Zéro risque. Et tu peux fermer une PR sans la merger, sans aucune justification. Même si c’est mieux avec je ne te le cache pas ^^

### Ensuite, dans l’ordre :

**1. Le CI vérifie le code à ta place — c’est déjà en place**  
Ton `.github/workflows/ci.yml` se déclenche déjà `on: pull_request`. À chaque PR il lance automatiquement :

- `npm run format:check` (Prettier)
- `npm run lint` (ESLint)
- `npm test`

Tu n’as donc _rien_ à relire pour savoir si c’est cassé : tu regardes en bas de la PR, coche verte = ça passe, croix rouge = ça passe pas. C’est tout.

**2. Tu peux demander la review à ton IA**  
Tu lui donnes le lien de la PR et tu lui demandes de la relire et de commenter directement dedans. Moi je verrai ses commentaires et je corrigerai. C’est là que les allers-retours se font, sans que tu aies à écrire une ligne.

**3. Tu construis une image de test — là aussi c’est déjà en place**  
Ton `.github/workflows/build.yml` a déjà un `workflow_dispatch` avec un champ `image-tag` **qui prend par défaut le nom de la branche** , et surtout il **ne touche pas à `:latest`**. Donc :

> Onglet **Actions** → workflow **Build** → bouton **Run workflow** → tu choisis la branche → **Run**

et tu récupères `ghcr.io/guim31/gladys-integration-unifi:<nom-de-la-branche>` que tu tires dans ton Docker pour tester en vrai. Tes utilisateurs sur `:latest` ne voient rien passer.

(Petit détail : ton `build.yml` ne se déclenche automatiquement que sur les tags `v*`, c’est-à-dire tes releases. Le déclenchement manuel ci-dessus est donc bien le bon chemin pour tester une branche.)

**4. Tu merges (ou pas)**  
Si tes tests sont OK : gros bouton vert **« Merge pull request »** en bas de la PR, puis **« Confirm merge »**. Deux clics. Tu peux aussi demander à ton IA de le faire.  
Si ça ne te convient pas : tu commentes, ou tu fermes. Aucun souci.

En résumé, tu n’as **jamais** à lire mon code si tu ne veux pas. Tu regardes la coche verte, tu testes l’image, tu cliques.

* * *

## Un point sur le fork =\> Et donc les PR qui apparaissent chez toi

## Comment on s’organise concrètement (et tu gardes TOUS les droits)

Je précise, parce que c’est important : je ne te demande **aucun droit** sur ton repo. Je fais exactement ce que je fais sur le repo de Gladys — je forke, je bosse sur mon fork, je te propose une PR. Je ne peux ni pousser chez toi, ni merger. **Tu es le seul à pouvoir appuyer sur le bouton.** C’est le fonctionnement standard de l’open source, et c’est très bien comme ça.

Et pour les tests, pas besoin que tu builds quoi que ce soit : **je te livre l’image en même temps que la PR.**

### Le déroulé

1. Je bosse sur une branche de mon fork.
2. Je lance le build **chez moi** — ton `build.yml` marche tel quel dans un fork, il calcule l’image avec `ghcr.io/${GITHUB_REPOSITORY,,}` et n’écrase jamais `latest`. Ça me sort par exemple `ghcr.io/terdious/gladys-integration-unifi:fix-ip-gateway`.
3. Je rends ce package public chez moi.
4. J’ouvre la PR chez toi, et **je mets l’adresse de l’image directement dans la description** , avec le manifeste à copier-coller.
5. Toi tu installes cette image dans ton Gladys, tu testes, et tu me dis.
6. Si c’est bon : bouton vert. Sinon : tu commentes, ou tu fermes.

Tu n’as donc **rien** à builder, **rien** à configurer, et **rien** à désinstaller.

### Comment tu installes mon image (2 champs à remplir)

Dans Gladys : **Intégrations → Installer depuis GitHub → « Mode développeur : installer depuis une image Docker »**

- champ **Image Docker** → tu colles l’adresse que je te donne dans la PR ;
- champ **Manifeste (JSON, optionnel)** → tu colles le JSON que je te donne juste en dessous.

Et c’est tout. Deux copier-coller.

### Deux ou trois choses à savoir

**Ça s’installe À CÔTÉ de ta version actuelle, tu ne casses rien.**  
Gladys construit le selector différemment selon le mode d’install : `ext-guim31-gladys-integration-unifi` pour ton install normale, `ext-dev-unifi-network` pour une install par image. Deux selectors différents = les deux intégrations cohabitent tranquillement. Tu gardes ta prod qui tourne, tu testes à côté, et quand tu as fini tu désinstalles juste celle de test.

**Pourquoi je dois te donner le manifeste à coller ?**  
Normalement Gladys sait le lire tout seul dans les _labels_ de l’image (le label `io.gladysassistant.manifest`). Mais ton `Dockerfile` n’en pose aucun et ton `build.yml` n’en passe pas non plus, donc l’install échouerait sur un `MANIFEST_NOT_FOUND`. D’où le copier-coller manuel — sans gravité, c’est exactement à ça que sert le champ optionnel.

**Du coup, je te propose ça comme toute première PR** : ajouter ce label à l’image. C’est 2 lignes, ça ne touche **aucun code fonctionnel** , et après ça n’importe qui (toi le premier) pourra installer une image de test en collant _juste_ son nom, sans manifeste. Ça t’améliore ton propre confort de dev pour toutes les fois suivantes — et ça te fait voir le mécanisme d’une PR de bout en bout sans le moindre risque. Idéal pour se faire la main 🙂

**Un point d’attention pour les tests**  
Comme les deux intégrations tournent en parallèle, elles découvrent les mêmes équipements. Or dans Gladys le `selector` d’un appareil est unique au niveau global. Donc :

- pour **vérifier** ce qu’une PR change (les paramètres IP, les features de ports qui apparaissent ou non, les noms) → l’écran de découverte de l’instance de test suffit largement, tu n’ajoutes rien, aucun risque ;
- pour **piloter réellement** un port PoE depuis l’instance de test → il faut d’abord supprimer les appareils concernés côté prod, sinon tu auras une erreur au moment de les ajouter. Rien de cassé, juste un message d’erreur dans la carte, mais autant le savoir.

### Et à terme

Quand tu seras à l’aise, le confort en plus c’est de te créer une branche `dev` chez toi :

```bash
git checkout main
git checkout -b dev
git push -u origin dev

```

Tu y merges les PR au fil de l’eau (ça ne publie toujours rien, `latest` ne bouge pas), tu builds ton image `:dev` depuis **Actions → Build → Run workflow → branche `dev`** , tu testes plusieurs changements d’un coup, et tu ne merges vers `main` que quand tu es content. Mais ce n’est pas nécessaire pour démarrer.

* * *

## Sur les équipements dédoublés

> [@guim31](#):
>
> 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 : […] Avec l’impossibilité de savoir distinguer les commutateurs entre eux.

Alors là je vais te rassurer : **ce n’est pas la faute de Gemini, et ton code était probablement bon.** 😅

Ce que tu as vu n’est pas un problème de nommage de tes features, c’est le comportement de **l’écran de découverte de Gladys** : sur ces petites cartes, Gladys affiche la **catégorie** de la feature, pas son nom.

La preuve est dans mes propres captures du post précédent :

- sur la carte **Dream Machine Pro** , on lit `Présence` / `Débit` / `Débit` — alors que dans ton `gateway.js` ces features s’appellent en réalité `Status`, `WAN Upload Speed` et `WAN Download Speed`. Deux `Débit` identiques à l’écran, deux noms bien distincts dans le code ;
- et surtout, sur la carte **« Switch PoE : SW-CAMPING-02 »** , on lit quand même 4 × `Commutateur`. Autrement dit : **le dédoublement n’a pas résolu le problème que tu cherchais à résoudre** — les ports restent indistinguables sur cet écran, séparés ou pas 😅

Alors que dans le JSON des devices découverts (ma première capture), tes noms sont parfaits : `Port 1 (SW-MAISON-01 / Port 19)`. Ils sont bien là, ils sont bien construits.

Test de 30 secondes si tu veux vérifier : ajoute un switch à Gladys, puis va ajouter les ports sur le dashboard, tu auras les bons noms. Tu verras les vrais noms (`Port 1 (…)`, `Port 3 (…)`, etc.), et tu les retrouveras aussi dans les sélecteurs de features quand tu construis une scène.

Donc si tu es d’accord, on peut fusionner sans crainte : un switch = un équipement, présence + ports ensemble, tout reste identifiable. Le vrai gain c’est le nombre de devices et la cohérence 😉

* * *

Voilà, dis-moi ce que tu préfères sur le fork vs collaborateur, et par quel point tu veux qu’on commence. Je te propose de démarrer par l’IP locale / IP publiques de la gateway : c’est le plus autonome, ça touche un seul fichier, et ça te fera une première PR « pour la route » histoire de voir le mécanisme en vrai sans risque 🙂

---

<div class="post-metadata">

**Author:** ![guim31](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/guim31/32/4840_2.png) [@guim31](https://community.gladysassistant.com/u/guim31)\
**Post date:** [Août 3, 2026, 9:18 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/53 "2026-08-03T21:18:14Z")

</div>

Merci beaucoup pour ce message TRÈS complet ! 🙂

Comme je l’ai déjà expliqué : je ne suis pas développeur, je n’ai aucune formation là-dedans. Ce projet existe parce que l’IA me permet aujourd’hui de construire des choses que je n’aurais jamais pu écrire moi-même. Donc quand tu dis que je n’ai jamais à lire ton code si je ne veux pas… ça tombe bien ^^ je ne saurais pas le juger de toute façon. Et c’est très bien comme ça : je préfère largement te faire confiance sur le fond et me concentrer sur ce que je sais faire, tester chez moi pour de vrai.

Donc le système fork + PR me va parfaitement. Comme ça je vais voir passer chaque  
changement un par un, avec le pourquoi écrit à côté.

Ce que tu m’expliques sur «&nbsp;tant que tu ne cliques pas, rien ne bouge&nbsp;» me rassure. J’avais l’impression qu’une PR c’était déjà un pied dans la porte. Là je comprends que je garde la main du début à la fin, et ça change tout dans ma façon d’aborder le truc.

Pour l’ordre, je te suis à 100% :

1. la PR du label dans le Dockerfile, pour que je voie le mécanisme en entier  
sur un truc à risque zéro ;
2. puis l’IP locale / les IPs publiques de la gateway.

Sur les équipements dédoublés : merci pour les détails et surtout de m’avoir dit que ce n’était pas forcément une erreur de ma part. Je n’avais pas du tout compris que l’écran de découverte affichait la catégorie et pas le nom de la feature — du coup j’avais «&nbsp;réparé&nbsp;» quelque chose qui n’était pas cassé. Je pars du principe que tu as raison : on fusionne, un switch = un équipement. Je peux essayer de faire cette partie dans une PR de mon coté pour me faire la main !

Et je note la règle «&nbsp;une modif = une branche&nbsp;», je m’y mets aussi pour mes  
propres modifs, Claude est quand même un super pote pour ces choses là 😛

Je vais avoir des questions bêtes en cours de route, je préfère te prévenir 🙂

Merci de prendre tout ce temps !!!

---

<div class="post-metadata">

**Author:** ![guim31](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/guim31/32/4840_2.png) [@guim31](https://community.gladysassistant.com/u/guim31)\
**Post date:** [Août 4, 2026, 7:01 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/54 "2026-08-04T07:01:52Z")

</div>

Petite avancée de mon côté : j’ai fait la fusion des switches et  
fait ma première PR ! J’emploi le «&nbsp;je&nbsp;» mais on aura tous compris qui se cache derrière 😉

> <https://github.com/guim31/gladys-integration-unifi/pull/1>
>
> \## Pourquoi
> 
> Le device dédié « Switch PoE : \`\<nom\>\` » avait été introduit pour d…istinguer les ports les uns des autres sur l'écran de découverte de Gladys.
> 
> Il ne remplit pas cet objectif : \*\*l'écran de découverte affiche la \_catégorie\_ d'une feature, pas son nom\*\*. Les ports y apparaissent donc comme plusieurs \`Commutateur\` identiques, qu'ils soient sur leur propre équipement ou non. Le dédoublement n'a rien résolu — il a seulement doublé le nombre d'équipements découverts.
> 
> Les vrais noms (\`Port 3 (Camera Entrance)\`) étaient déjà corrects, et déjà visibles là où ça compte : sur le dashboard et dans le sélecteur de features quand on construit une scène.
> 
> Merci à @Terdious pour le diagnostic sur le forum Gladys.
> 
> \## Ce que ça change
> 
> Un matériel UniFi = un équipement Gladys. Statut, débits WAN et interrupteurs de ports PoE sont désormais des features du \*\*même\*\* équipement.
> 
> | | Avant | Après |
> |---|---|---|
> | Équipements pour 1 switch PoE | 2 | 1 |
> | Nom des ports | \`Port 3 (Camera Entrance)\` | inchangé |
> | Pilotage PoE | OK | OK |
> 
> \## Compatibilité
> 
> L'\`external\_id\` des features de port est \*\*inchangé\*\* :
> 
> \`\`\`
> unifi:poe:MAC:PORT\_IDX:power
> \`\`\`
> 
> C'est l'identifiant utilisé par le polling d'état (\`pollAllStates\`) et par \`onSetValue\`. Ces deux chemins ne sont pas modifiés : le pilotage PoE fonctionne exactement comme avant.
> 
> Seul le \`selector\` des features change, puisqu'elles changent d'équipement parent :
> 
> \`\`\`
> unifi-poe-switch-MAC-port-N -\> unifi-gateway-MAC-port-N
> \`\`\`
> 
> \## ⚠️ Précaution avant de tester le pilotage
> 
> Un \`external\_id\` de feature est unique au niveau global dans Gladys. Si les équipements « Switch PoE : … » sont \*\*déjà ajoutés\*\* dans une instance, l'ajout de l'équipement fusionné entrera en conflit avec eux.
> 
> \- pour \*\*vérifier visuellement\*\* qu'il n'y a plus qu'un équipement par switch → l'écran de découverte suffit, rien à supprimer ;
> \- pour \*\*piloter réellement\*\* un port depuis cette version → supprimer d'abord les anciens équipements « Switch PoE : … ».
> 
> \## Détail technique
> 
> \`src/devices/poePort.js\` n'exporte plus un blueprint autonome, mais deux fonctions consommées par \`gateway.js\` :
> 
> \- \`hasPoePorts(unifiDevice)\`
> \- \`buildPoePortFeatures(gladys, unifiDevice, deviceSelector)\`
> 
> \## Tests
> 
> Les trois portes du CI passent :
> 
> \- \`npm run format:check\` ✅
> \- \`npm run lint\` ✅
> \- \`npm test\` ✅ (16 tests)
> 
> Tests mis à jour / ajoutés dans \`test/devices.test.js\` :
> 
> \- les ports PoE sont bien attachés à l'équipement matériel, et l'\`external\_id\` conserve exactement sa forme (le test échouera si quelqu'un le modifie par inadvertance) ;
> \- un port sans capacité PoE ne génère aucune feature ;
> \- un matériel sans port PoE (point d'accès) ne gagne aucune feature ;
> \- le compte d'équipements découverts passe de 6 à 5 dans le scénario de découverte complet.

Un matériel = un équipement maintenant.

C’est mergé dans main mais je n’ai pas fait de release.

Bref, je suis prêt pour tes PR quand tu veux 🙂

---

<div class="post-metadata">

**Author:** ![prohand](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/prohand/32/15713_2.png) [@prohand](https://community.gladysassistant.com/u/prohand)\
**Post date:** [Août 4, 2026, 9:54 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/55 "2026-08-04T21:54:27Z")

</div>

Pour apporter ma petite pierre à l’édifice, j’ai testé de mon côté la version 1.5.2 et la récupération des éléments fonctionnent sans problème 🙂

---

<div class="post-metadata">

**Author:** ![guim31](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/guim31/32/4840_2.png) [@guim31](https://community.gladysassistant.com/u/guim31)\
**Post date:** [Octobre 6, 2026, 6:59 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/56 "2026-10-06T06:59:27Z")

</div>

🌐 **UniFi Network 1.6.0 est disponible** , avec trois **widgets de tableau de bord** : **Réseau** (débit WAN en direct, clients connectés, équipements en ligne, état d’Internet et courbe de trafic), **Présence** (vos appareils présents ou absents) et **Wi-Fi** (un réseau au choix, avec deux boutons Activer / Désactiver : parfait pour le Wi-Fi invités).

⚠ Cette version demande **Gladys 5.1 minimum** : mettez d’abord Gladys à jour, sinon la mise à jour de l’intégration ne vous sera pas proposée.

La mise à jour se fait dans **Intégrations** ; vos appareils et vos scènes ne changent pas. Vos retours sont les bienvenus 🙂

---

<div class="post-metadata">

**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\
**Post date:** [Octobre 17, 2026, 4:32 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/57 "2026-10-17T16:32:56Z")

</div>

Bonjour @guim31, merci pour la 1.6.0 et ses trois widgets !

Une idée pour une prochaine version : un widget **VPN WireGuard** pour le serveur VPN de la passerelle UniFi (UCG / UDM). Il afficherait :

- l’état du serveur WireGuard (actif ou non) ;
- les clients VPN connectés, avec pour chacun le nom, l’heure de dernière connexion et, si l’API le donne, le trafic ;
- en option, un bouton Activer / Désactiver, comme pour le widget Wi-Fi, désactivé par défaut.

Ce serait pratique pour voir d’un coup d’œil qui est connecté à distance, et pour s’en servir en présence ou en déclencheur de scène (« un client VPN se connecte »).

Je n’ai trouvé ni widget ni équipement VPN dans l’intégration actuelle ; dis-moi si je suis passé à côté.

---

<div class="post-metadata">

**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\
**Post date:** [Octobre 17, 2026, 6:43 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/58 "2026-10-17T18:43:29Z")

</div>

Nickel, je vais tester car j’ai 2 sites en VPN ☺

---

<div class="post-metadata">

**Author:** ![guim31](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/guim31/32/4840_2.png) [@guim31](https://community.gladysassistant.com/u/guim31)\
**Post date:** [Octobre 17, 2026, 7:13 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/59 "2026-10-17T19:13:17Z")

</div>

Bonne idée @lmilcent, c’est en ligne avec la **1.8.0** 🙂

- un appareil **VPN WireGuard** par serveur de la passerelle, avec son état et le nombre de clients connectés ;
- un widget **VPN WireGuard** : l’état du serveur, puis une ligne par client connecté, avec son nom et les données échangées quand la console les donne ;
- deux déclencheurs de scène, **Client VPN connecté** et **Client VPN déconnecté** , pour la présence à distance ;
- le bouton Activer / Désactiver n’apparaît que si tu coches **Autoriser la commande du serveur VPN** dans la configuration. Pense ensuite à mettre l’appareil à jour depuis l’onglet Découverte.

Je l’ai fait sans passerelle WireGuard sous la main. Le serveur est lu dans la configuration réseau de la console, et un client VPN est reconnu à son adresse dans le sous-réseau du VPN, parmi les clients que montre la console. Si le compteur reste à 0 alors que quelqu’un est connecté, dis-le-moi : ce sera que ta console les range ailleurs. Et @mutmut, avec tes 2 sites en VPN, ton retour m’intéresse aussi !

Mettez à jour depuis Gladys.

---

<div class="post-metadata">

**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\
**Post date:** [Octobre 18, 2026, 9:04 UTC](https://community.gladysassistant.com/t/integration-externe-unify-network/10426/60 "2026-10-18T09:04:20Z")

</div>

Merci @guim31 pour la mise à jour.  
Alors voici ce que j’obtiens sur le dashboard :

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/5/1/51623cdd2ace61723db7a2a17a4a8b20c11773c2.jpeg)  
La légende :

- udr7 : serveur wireguard (actif)
- ux : client nantes (actif)
- udr : client liège (éteint)

Donc avec tout ça, je ne comprends pas tout.  
Pour info j’ai bien les clients dans Découverte.  
Pour le premier widget, j’ai choisi l’udr7 comme serveur mais il semble me donner le client nantes comme serveur.  
Pour les 2 autres widgets, j’ai pris les 2 clients pour voir.

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/c/a/ca5ce388f53ce10e41eade52fb5a6cac30a1130e.jpeg)

A quoi correspondent ou plutôt qui doivent être les clients connectés ? les clients wireguard ou les clients wifi/ethernet de la borne ?

[Page précédente](https://community.gladysassistant.com/t/integration-externe-unify-network/10426.md?page=2)

[Page suivante](https://community.gladysassistant.com/t/integration-externe-unify-network/10426.md?page=4)
