Supervision des intégrations externes

Demande de fonctionnalités
1

Hello,

Est-ce qu’il serait possible d’implémenter une sorte de supervision avec une alerte sur le moyen de communication de son choix lorsqu’une intégration extene passe l’état « Connexion » en déconnecté (Il faut que son état soit passé au moins une fois connecté, sinon on recevra des alertes dès l’installation de l’integration externe)

En effet le but est de pouvoir être alerté par exemple pour Daikin si le token de connexion expire pour relancer la connexion ou tout autres problèmes qui passerai l’état en déconnecté

Peut-être la même alerte aussi pour le statut « En cours d’execution »

Merci

2

Pour l’intégration tv impossible de faire ça. Lorsque la tv est allumée on aura linfo qu’on est connecté. Mais une fois éteintes on risque davoir des fausse notifications

3

Je parles de ceci :

image
image1062×333 17.7 KB

Quand la télé est éteinte « Connexion » passe en déconnecté chez toi ?

4

Oui :slight_smile: car le websocket est fermé

5

Ah voir si on peut mettre des exclusions :wink:

6

Mais pk cest pas le service qui gere son renouvellement de token ?
Dans mon cas quand je rallume la tv, jai un wol pour allumée physiquement la tv et une reconnexion du socket.

Toi quant le token est expiré il devrait le renouveler automatiquement non ?
A moins que tu es une action manuelle a faire bien sur ? :thinking:

7

Je n’ai pas rencontré le cas pour Daikin car il me semble que le token expire dans 1 an
Donc je verrai dans un 1 an s’il est renouvellé automatiquement ou pas :sweat_smile:

Mais je donnais juste ceci à titre d’exemple, il peu être en état déconnecté car Daikin rencontre un problème par exemple, ou bien l’intégration à rencontrée une erreur non géré et il a planté et se retrouve dans un état déconnecté

8

On a quoi comme statuts a connexion ? Connecté déconnecté ? Il faudrait peut etre un état dégradé ?

9

Aucune idée :sweat_smile:
Oui peut être un état dégradé serait pas mal

10

Salut @prohand, salut @spenceur !

Merci pour ce sujet, le besoin est bien réel : une intégration qui tombe silencieusement (typiquement un token qui expire), c’est la pire panne possible en domotique. Rien ne casse visiblement, et on s’en rend compte 3 semaines plus tard :sweat_smile:

Bonne nouvelle : pour les intégrations externes, une bonne partie de la supervision existe déjà côté serveur. Chaque intégration envoie un heartbeat à Gladys, une vérification de santé tourne en permanence, et l’intégration passe en état dégradé quand elle perd sa connexion au service tiers ou ne donne plus signe de vie, avec redémarrage automatique et backoff derrière.

L’état « dégradé » que tu proposes @spenceur existe donc déjà en interne :+1: Ce qui manque, c’est la partie visible pour l’utilisateur : être prévenu.

Sur l’alerte « Connecté → Déconnecté » : l’exemple de la TV montre bien le piège. « Déconnecté » peut vouloir dire deux choses qui n’ont rien à voir :

  • un cas normal : appareil éteint, WebSocket fermée, comportement attendu ;
  • un cas anormal : token expiré, accès révoqué, API en erreur.

La distinction existe déjà en partie dans le modèle (l’intégration tourne mais sa connexion au cloud est tombée, donc dégradé), il faut juste s’assurer que chaque intégration remonte le bon signal, plutôt que d’alerter bêtement sur toute déconnexion.

Sur les exclusions : je préfère éviter d’en faire le mécanisme principal. Ça oblige chacun à découvrir empiriquement quelles intégrations sont « bruyantes », après avoir reçu des fausses alertes. Si on en a besoin dès le départ, c’est que le signal remonté n’est pas le bon.

Concrètement, je verrais donc :

  1. Rendre l’état visible : l’état de chaque intégration + la date du dernier échange réussi, directement dans l’interface. Zéro notification, mais déjà une grosse partie de la valeur.
  2. Un réglage global dans les paramètres de Gladys : « M’alerter quand une intégration est en erreur ». Un simple interrupteur, pas de configuration par intégration ni de scène à créer. Et ça couvre naturellement ta demande @prohand du « seulement si ça a déjà été connecté » : dégradé signifie par construction « ça marchait, ça ne marche plus ».
  3. De l’anti-flapping intégré au réglage : un délai minimum en dégradé avant d’alerter (pour laisser le redémarrage automatique faire son travail), pas de doublons, et une notification de retour à la normale. Sans ça, ce genre de fonctionnalité finit désactivée par tout le monde en une semaine.

Sur le renouvellement automatique des tokens : 100 % d’accord sur le fond, mais c’est à traiter intégration par intégration, et même avec un refresh parfait il restera des cas où l’accès tombe (révocation côté constructeur, changement d’API…). La supervision doit donc exister quand même.

Bref : les fondations sont déjà là, le gros du travail est d’exposer tout ça à l’utilisateur :slightly_smiling_face: