j’ai eu des problèmes de connexion free aujourd’hui.
Gladys est accessible en local quand même pas de problème, cependant à chaque fois que j’ai voulu me reconnecter avec Gladys plus (sur téléphone ou pc) j’avais ce message :
Ça n’a peut etre rien à voir, mais lorsque j’ai été confronté à un problème similaire, c’est parce que j’avais gardé (par mégarde) une image de test de Gladys tourner sur mon NAS.
Donc j’aivais 2 instances de GLadys qui essayaient de se connecter en même temps.
J’ai effectivement fait des changements liés à Gladys Plus dans la 4.56 et donc c’est possible qu’il y ait un souci.
J’investigue !
Côté serveur, je remarque que certains clients se reconnectent énormément à Gladys et ça créé des problèmes de charges côté serveur donc il y a l’air d’avoir un vrai souci (ou alors c’est quelqu’un qui DOS le serveur, mais ça m’étonnerait, ça coincide avec la sortie de la 4.56)
Ok il y a un vrai souci sur la reconnexion, j’ai relancé l’archi Gladys Plus, et ça a déconnecté mon instance perso qui n’arrive plus à se reconnecter ! Je pense que je vais tout simplement rollback les changements Gladys Plus que j’avais fais en attendant de trouver la source du bug !
Dans Gladys Assistant 4.56, j’ai introduit une nouvelle logique d’authentification sur les Websockets, permettant une connexion plus rapide: idéal pour un accès instantané au tableau de bord sur mobile.
Le problème ? Si l’instance perd la connexion, elle tente de se reconnecter avec le même access_token utilisé lors de la première connexion. Sauf que cet access_token a expiré entre-temps et n’est pas renouvelé. J’utilise une nouvelle logique présente dans la librairie socket-io et je n’avais pas compris son fonctionnement en cas de déconnexion.
Résultat : le backend Gladys Plus rejette la connexion (JWT expiré), et l’instance entre dans une boucle infinie de reconnexion.
C’est une bonne leçon, et quelques pistes d’améliorations :
Renouveler l’access_token en cas de perte de connexion pour repartir sur un jeton valide.
Ajouter un délai avant la reconnexion, afin d’éviter de surcharger le serveur en cas de boucle infinie.
Renforcer les tests unitaires pour mieux couvrir les scénarios de perte de connexion et éviter que ce bug ne se reproduise.
Désolé pour le dérangement !
Je vous tiens informés dès que la version 4.56.1 est disponible
J’étais absent de chez moi, et même souci de mon côté… J’ai cru que mon serveur domotique avec Gladys était tombe en panne. Et je viens de rentrer et de constater qu’en local tout marchait bien.
J’ai déjà pas mal de monitoring, c’est ça qui m’a mis la puce à l’oreille sur le fait qu’il y ait un souci généralisé
Progressivement, plus les instances passaient à Gladys Assistant 4.56, et plus le cas d’une instance qui perd temporairement la connexion arrivait, et ces instances rentraient dans une boucle infinie agressive de reconnexion.
Je recevais de plus en plus d’emails, et j’ai compris qu’il y avait un souci !
Bonjour @pierre-gilles ,
désolé de ne pas avoir répondu mais je n’étais pas dispo ce we. J’ai été déco plusieurs fois ce we de Gladys Plus.
Je viens de MAJ avec la 4.56.1 et la reconnexion à Gladys Plus s’est faite automatiquement.
Merci beaucoup pour la MAJ
Bonjour,
j’ai eu aussi deux fois la non reconnexion avec Gladys plus. Samedi, suite à une mise à jour de ma box et dimanche sans raison apparente.
Merci @pierre-gilles pour la prise en compte rapide et pendant un week-end. A cette heure la version en cours est toujours 4.56.0.
Pour des raisons autres que le problème résolu, quelles sont les solutions pour accéder de nouveau à Gladys plus lorsque l’on est pas sur place pour redémarrer le miniPC ?
Chez moi mon routeur ( TP-Link Archer AX58 Routeur WiFi 6 AX 3000 Mbps bi-bande) offre un VPN pour accéder à mon réseau local à distance. En cas de soucis, je peux intervenir et me connecter en SSH à distance à mon mini-PC et voir ce qui ne va pas, éventuellement redémarrer le mini-PC