Supervisión de las integraciones externas

Solicitud de función
1

Hola,

¿Sería posible implementar una especie de supervisión con una alerta en el medio de comunicación de su elección cuando una integración externa pase del estado « Conectado » a desconectado (debe haber pasado al menos una vez al estado conectado, de lo contrario recibiremos alertas desde la instalación de la integración externa)?

De hecho, el objetivo es poder ser alertado, por ejemplo, por Daikin si el token de conexión expira para reiniciar la conexión o cualquier otro problema que pase el estado a desconectado.

Quizás la misma alerta también para el estado « En ejecución ».

Gracias

2

Para la integración de la TV es imposible hacer eso. Cuando la TV está encendida, tendremos la información de que estamos conectados. Pero una vez apagada, corremos el riesgo de tener notificaciones falsas.

3

Hablo de esto:

image
image1062×333 17.7 KB

¿Cuando la tele está apagada, « Conexión » se pone en desconectado en tu casa?

4

Sí :slight_smile: porque el websocket está cerrado

5

A ver si podemos poner exclusiones :wink:

6

Pero ¿por qué no es el servicio el que gestiona el renovación del token?
En mi caso, cuando enciendo la TV, tengo un WOL para encender físicamente la TV y una reconexión del socket.

¿Tú, cuando el token expira, no debería renovarlo automáticamente?
A menos que tengas que hacer una acción manual, claro. :thinking:

7

No he encontrado el caso para Daikin porque me parece que el token expira en 1 año
Por lo tanto, veré dentro de un año si se renueva automáticamente o no :sweat_smile:

Pero solo daba esto como ejemplo, puede estar en estado desconectado porque Daikin tiene un problema, por ejemplo, o bien la integración ha encontrado un error no gestionado y se ha bloqueado y se encuentra en un estado desconectado

8

¿Qué tipos de estados de conexión hay? ¿Conectado, desconectado? ¿Quizás debería haber un estado degradado?

9

Ni idea :sweat_smile:
Sí, tal vez un estado degradado estaría bien

10

¡Hola @prohand, hola @spenceur!

Gracias por este tema, la necesidad es muy real: una integración que falla silenciosamente (típicamente un token que expira), es la peor falla posible en domótica. Nada se rompe visiblemente, y te das cuenta 3 semanas después :sweat_smile:

Buena noticia: para las integraciones externas, gran parte de la supervisión ya existe en el servidor. Cada integración envía un heartbeat a Gladys, una verificación de salud se ejecuta permanentemente, y la integración pasa al estado degradado cuando pierde su conexión al servicio externo o deja de dar señales de vida, con reinicio automático y backoff detrás.

El estado « degradado » que propones @spenceur ya existe internamente :+1: Lo que falta es la parte visible para el usuario: ser notificado.

Sobre la alerta « Conectado → Desconectado »: el ejemplo de la TV muestra bien la trampa. « Desconectado » puede significar dos cosas que no tienen nada que ver:

  • un caso normal: dispositivo apagado, WebSocket cerrado, comportamiento esperado;
  • un caso anormal: token expirado, acceso revocado, API en error.

La distinción ya existe en parte en el modelo (la integración funciona pero su conexión a la nube ha caído, por lo tanto degradado), solo hay que asegurarse de que cada integración envíe la señal correcta, en lugar de alertar tontamente sobre cualquier desconexión.

Sobre las exclusiones: prefiero evitar hacerlas el mecanismo principal. Obliga a cada uno a descubrir empíricamente qué integraciones son « ruidosas », después de haber recibido falsas alertas. Si se necesitan desde el principio, es que la señal enviada no es la correcta.

Concretamente, vería:

  1. Hacer el estado visible: el estado de cada integración + la fecha del último intercambio exitoso, directamente en la interfaz. Cero notificaciones, pero ya una gran parte del valor.
  2. Una configuración global en los parámetros de Gladys: « Notificarme cuando una integración esté en error ». Un simple interruptor, sin configuración por integración ni escena que crear. Y esto cubre naturalmente tu solicitud @prohand de « solo si ya ha estado conectado »: degradado significa por construcción « funcionaba, ya no funciona ».
  3. Anti-flapping integrado en la configuración: un retraso mínimo en degradado antes de alertar (para dejar que el reinicio automático haga su trabajo), sin duplicados, y una notificación de retorno a la normalidad. Sin esto, este tipo de funcionalidad termina desactivada por todos en una semana.

Sobre el renovación automática de los tokens: 100% de acuerdo en el fondo, pero esto debe tratarse integración por integración, y aunque haya un refresh perfecto, seguirán habiendo casos en los que el acceso caiga (revocación por parte del fabricante, cambio de API…). La supervisión debe existir de todos modos.

En resumen: las bases ya están ahí, el grueso del trabajo es exponer todo esto al usuario :slightly_smiling_face: