Hop :
ghcr.io/gladysassistant/gladys-preview:claude-magical-turing-qhh7q2-arm64
@Will_71 Est-ce que l’intégration Free Mobile ne deviendrait pas une intégration externe ? 
Oui tout à fait. Après il faut que je regarde comment tout cela fonctionne. Je me suis fait la réflexion dans le week-end mais pas eu le temps de regarder d’avantage.
Lance Claude sur le sujet c’est vraiment l’histoire de 5 minutes à mon avis 
Intégration externe TP Link en cours de dev/test (il faut que je me penche sur la partie découverte réseau)
Pour le scan réseau, c’est dans le SDK ! C’est Gladys qui fait le scan et qui fourni les résultats à l’intégration.
Donne juste le SDK à Claude et il fera le travail 
Ce côté là est trop facile pour le coup avec Claude ^^
Salut @pierre-gilles,
Retour d’expérience UX après avoir mis en service le modèle transports +
actions sur gladys-tuya (au passage : les macarons local/cloud, le toggle
GLADYS_PREFER_LOCAL, l’upsert des params et l’action detect_protocol
fonctionnent nickel en réel — bravo, ça change tout).
Le point dur restant est la LISIBILITÉ CÔTÉ APPAREIL. Scénario vécu par un
utilisateur lambda : deux appareils affichent un macaron « Cloud » alors que le
mode local est activé. Pourquoi ? L’un n’a pas été trouvé par le scan UDP
(pas d’IP), l’autre refuse les sessions locales. Impossible de le savoir
depuis la fiche appareil : elle n’affiche que Nom / Pièce / Fonctionnalités
(DeviceBox.jsx ne rend aucun param en dehors du badge GLADYS_TRANSPORT).
Trois demandes, par ordre de priorité :
-
Afficher des params « utiles » sur la fiche appareil d’une intégration externe — a minima en lecture (IP_ADDRESS, PROTOCOL_VERSION), idéalement avec l’IP éditable. Sans ça, l’utilisateur ne peut ni diagnostiquer ni agir. Piste : une liste de clés de params à exposer, déclarée dans le manifest (ex. « device_params_display »: [« IP_ADDRESS », « PROTOCOL_VERSION »]), avec un flag « editable » par clé — l’édition repasse par l’upsert de params existant.
-
Actions PAR APPAREIL : aujourd’hui les actions du manifest ne sont rendues que dans l’écran Configuration (ActionsCard.jsx), au niveau intégration.
Pour « détecter le protocole local », le bon endroit est la fiche de l’appareil concerné : un flag « scope »: « device » sur l’action, rendue en bouton sur chaque carte, avec l’external_id de l’appareil injecté dans les fields transmis à l’intégration. Ça éviterait de demander à l’utilisateur de recopier un identifiant. -
À défaut (ou en complément), une SOURCE DYNAMIQUE pour les champs select des actions : aujourd’hui ConfigSchemaForm.jsx ne rend que des options statiques du manifest. Un champ
{ "type": "select", "source": "devices" }listant les appareils créés de l’intégration (label = nom, value = external_id) résoudrait 90 % du besoin avec un changement front minime.
En attendant, on a mis un palliatif côté intégration : le champ de l’action accepte le NOM de l’appareil tel qu’affiché dans Gladys (ou l’ID Tuya). Ça dépanne, mais ça reste de la saisie libre avec les risques d’homonymes.
Complément sur les macarons de transport — un état « dégradé » (orange)
En utilisant les macarons local/cloud en réel, on tombe sur un cas que les trois états actuels (local / cloud / unreachable) ne savent pas exprimer : l’appareil FONCTIONNE, mais pas comme il devrait.
Cas concret vécu : un appareil est bien repéré par le scan UDP local (IP et version de protocole connues, mode local activé), mais il renvoie des erreurs ou des timeouts sur les lectures locales. Notre intégration bascule alors en fallback cloud : l’utilisateur voit un macaron « Cloud » bleu, parfaitement normal en apparence… alors qu’en réalité quelque chose cloche (appareil qui refuse les sessions locales, clé locale rotée, autre client local qui tient la connexion, etc.). Rien ne l’invite à investiguer.
La demande : un état « degraded » (macaron ORANGE), orthogonal au transport effectif. Deux pistes de modélisation, à ta préférence :
- Un champ santé séparé dans publishTransports, pour ne pas polluer la sémantique du transport :
[{ "external_id": "...",
"transport": "cloud",
"health": "degraded",
"reason": {
"en": "LAN found but local polls fail — using cloud",
"fr": "Vu en LAN mais échecs de lecture locale — bascule cloud",
"de": "Im LAN beobachtet, aber lokale Lesefehler – Cloud-Umschaltung"
}
}]
→ le macaron affiche le transport, l’orange signale la dégradation, le
reason s’affiche en tooltip / au clic. C’est ma préférée : « degraded »
reste vrai quel que soit le transport (un cloud qui rame ou un local qui
perd des trames sont aussi des dégradés).
- A minima, une valeur « degraded » ajoutée à l’enum du transport — moins riche (on perd l’info du transport réellement utilisé), mais trivial à ajouter.
Côté intégration, on a déjà tout pour le remonter proprement : notre circuit-breaker local sait exactement quand un appareil LAN-capable est parqué sur le cloud après N échecs, avec la raison. Il ne nous manque que le canal pour l’exprimer à l’utilisateur.
Et au-delà de ce cas précis, ça donne un vocabulaire générique pour tous les « ça marche mais mal » : token cloud qui expire bientôt, appareil qui répond une fois sur deux, sous-container en crash-loop mais fallback actif, etc.
Merci !
Incroyable, merci pour tes retours et ces 2 intégrations ! Pour implémenter tes retours ça sera sûrement jeudi (je suis free-lance aujourd’hui et demain 
)
Oui oui je sais bien, c’est pour ça qu’on a palier autrement en attendant, ça reste fonctionnel malgré tout 
!!
Merci pour tout 
, cette évolution majeure est un tournant pour Gladys je pense. Même si, mais je ne me fait pas trop d’illusion te connaissant maintenant sur la qualité, comme le mentionnait très bien @cicoub13 , la suite ne sera pas forcément non plus de tout repos pour conserver une qualité et une image haute de Gladys !!
Allez !! Go boulot moi aussi ^^
Oui, c’est ce que j’ai fait, mais la proposition est à revoir (IP à entrer par l’utilisateur et fallback sur scan réseau). J’aimerais que ce soit plus simple et donc comprendre ce qui est vraiment possible avec le scan (je vais relire la doc).
Est-ce que la partie Supervision ne gagnerait pas à être dans une partie à part (en dehors de configuration) ?
Si tu génères un exemple avec Fable je pourrais le relire.
Je t’avais exposé l’idée d’un serveur de validation du SDK. Tu n’auras pas besoin de valider si le SDK passe tous les tests du serveur de validation. Le développeur peut le faire en local en plus. Ca va permettre aussi de multiplier les SDK externes. Je pense que JS et Python supportés officiellement permettent de couvrir 90% des besoins et des développeurs. De plus, Python est utilisé par HA et par extension on a plein d’intégration que l’on peut plus facilement porter. Par contre il faut attendre la version stable de la version JS avant. N’allons pas trop vite
Pourquoi pas, bonne idée !
Yes, je suis d’accord. J’aimerais déjà avoir une première release en production en full JS, ainsi qu’un SDK JS suffisamment mature, avant de proposer un SDK Python.
En revanche, une fois que le SDK JS sera stabilisé et qu’il demandera moins d’évolution et de maintenance de ma part, je serais carrément partant pour le porter en Python.
Et bien écoute ça semble bien fonctionner tout ça ^^ OAuth nickel du 1er coup.
Image et flux vidéo nickel !
Par contre je n’ai pas le son sur les flux vidéo et flux retardé de 10/15s => Recherche demain
Et bien on va pouvoir y passer prochainement je pense ^^ Chantier du week-end sûrement !!^^
Incroyable, c’est vraiment le feu ces intégrations externes
Ok tiens moi au courant pour l’histoire de la latence !
Après discussion avec Fable :
Les trois retours touchent des vrais besoins, mais je ne les prendrais pas tous tels quels. Mon avis point par point :
1. Actions par appareil (scope: "device") — je le reporterais. Le besoin est légitime (ne pas faire recopier un external_id à l’utilisateur), mais la solution proposée ouvre une boîte de Pandore UI : des boutons déclarés par le manifest qui s’injectent sur les cartes d’appareils, c’est exactement le genre de surface qu’on a voulu éviter (exigence n°3 du cadrage : UI cohérente, pas de rendu piloté par les intégrations au-delà de formulaires générés). Et ça pose des questions sans bonne réponse en v1 : sur quelle carte ? L’écran Appareils de l’intégration seulement, ou le dashboard ? Que faire quand une intégration déclare 5 actions device × 40 appareils ? Le développeur le dit lui-même : la source dynamique couvre 90 % du besoin. Les 10 % restants (un clic économisé par rapport à un select) ne justifient pas cette complexité maintenant. Candidat phase 2 si l’usage le réclame, pas v1.
2. Source dynamique pour les selects ("source": "devices") — oui, franchement. C’est la bonne solution au même problème : petite, générique, cohérente avec le config_schema existant, et le rendu reste 100 % contrôlé par le core (label = nom de l’appareil, value = external_id, filtré au service_id de l’intégration — zéro fuite entre tenants). Deux garde-fous à mettre dans la spec : source est un enum réservé défini par le core (v1 : uniquement devices), pas une URL ni une expression — on n’ouvre pas un mécanisme d’injection de données arbitraires ; et source est exclusif avec options statiques. Ça marche pour les champs des actions[] et, gratuitement, pour le config_schema d’installation aussi.
3. État « dégradé » — le besoin est réel, mais pas comme 4e valeur de l’enum. Le cas décrit (l’appareil marche en cloud alors qu’il devrait être en local) est générique, pas tuyaesque, et le macaron bleu « tout va bien » qui masque un problème est un vrai trou d’observabilité. Par contre, ajouter degraded à GLADYS_TRANSPORT mélange deux axes orthogonaux : quel transport est utilisé et est-ce l’état nominal. Avec un enum à 4 valeurs, l’utilisateur qui voit « Dégradé » perd l’info « il est en cloud en ce moment » — qui est justement ce qui lui permet de comprendre. Ma proposition : garder local|cloud|unreachable comme valeur du transport, et enrichir le même endpoint POST /device/transport avec deux champs optionnels par entrée : degraded: true et un message multi-langue (ex. « Local détecté mais sessions refusées, bascule cloud »). Rendu : le macaron garde sa couleur/label de transport avec un liseré ou point orange, tooltip = le message ; le compteur global de l’écran Appareils gagne une ligne « n dégradé(s) ». On garde les deux informations au lieu d’en écraser une.
En résumé : je prends le 2 tel quel (avec enum réservé), le 3 remodelé en flag orthogonal degraded + message plutôt qu’en 4e état, et je reporte le 1 en phase 2 puisque le 2 couvre l’essentiel du besoin. Si ça te va, j’écris ces deux ajouts dans la spec.
Je suis plutôt d’accord avec lui !
Je suis totalement d’accord avec ça, et comme précisé pour le point 1, ça fonctionne sans, c’est « seulement » de l’amélioratif possible, à concerter et prendre le temps 
C’est beaucoup mieux 
Nouvelle version du SDK, la v0.7.0 avec des nouvelles fonctionnalités pour @Terdious et @cicoub13 :
- feat: degraded transport state and dynamic select source « devices » (spec update) by @Pierre-Gilles in #11
- feat: active broadcast network scan
udp-active-broadcast(spec B.16 update) by @Pierre-Gilles in #12