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 !