Intégrations externes dans Gladys Assistant

Ok j’ai mis à jour la PR Gladys avec 3 changements :

1. Bandeau « Votre appareil n’est pas dans la liste ? » — il met désormais en avant Matter et les intégrations externes de la communauté : « chacun peut en créer une et la publier dans le store, elle apparaît alors dans cette liste »,

2. Dépréciation annoncée de Tuya, MELCloud, Telegram et Netatmo — j’ai fait les deux pour que ce soit sans ambiguïté :

  • un badge rouge « Bientôt dépréciée » sur leur carte du catalogue (flag deprecated dans les JSON d’intégrations, rendu dans IntegrationTags) ;
  • une alerte en haut de la page de chacune des quatre intégrations (composant partagé DeprecationWarning) : « sera bientôt dépréciée au profit d’une intégration externe équivalente… les deux versions vont co-exister dans le catalogue pendant la transition — vous pouvez continuer à utiliser celle-ci pour le moment ».

3. Erreurs d’authentification au redémarrage (close code 4000) — diagnostic confirmé, et c’était même pire que ça : sans variable d’env JWT_SECRET, le secret est régénéré à chaque boot de Gladys, et comme start() redémarrait le conteneur existant avec le token JWT figé dans son env (signé avec l’ancien secret), l’intégration bouclait sur le refus sans jamais se réparer. Deux corrections :

  • le superviseur signe désormais les JWT d’intégration avec son propre secret, généré une fois et persisté en variable (EXTERNAL_INTEGRATION_JWT_SECRET) — il survit aux redémarrages et aux restaurations de sauvegarde, en cohérence avec les conteneurs qu’il valide ;
  • auto-réparation dans start() : avant de redémarrer un conteneur existant, verifyContainerToken inspecte le token de son env (signature avec le secret courant + bon service + bonne token_version) ; s’il est périmé, le conteneur est recréé avec un token frais au lieu d’être redémarré pour rien. Ça répare aussi, dès le prochain boot, les conteneurs créés avant ce correctif.