Guías de ThinkLink / Alarmas y automatización

Alarmas en ThinkLink: verificar activación, avisos y recuperación

Defina activación, recuperación, recordatorios y responsables, y distinga ejecución del modelo, registro de alarma y recepción real.

ThinkLinkPublicado el 4 min de lectura
Punto de partida

Antes de configurar modelos y grupos, defina qué requiere atención, cuándo se considera resuelto y quién recibe el aviso. Crear la alarma, enviar el mensaje y recibirlo son resultados distintos que deben probarse antes de publicar.

De una anomalía a una acción trazable
De una anomalía a una acción trazable Ver imagen completa ↗

Defina el evento antes del umbral

Enviar un mensaje si la temperatura es alta no es una regla completa. Indique zona, equipo, unidad, duración y acción posterior. El operador necesita ubicación y hora para saber qué revisar, no solo un número.

Redacte cada regla como una condición verificable: dentro de un ámbito concreto, una condición genera la alarma, otra la resuelve y un responsable la recibe. Duraciones, umbrales y frecuencia de recordatorios dependen del sitio; no copie parámetros de ejemplos sin validarlos.

Vincule el activador a un objeto que reciba los datos

Los modelos de activación de ThinkLink se ejecutan después de recibir y procesar un mensaje ascendente en su objeto asociado. Guardar el modelo no lo vincula al dispositivo. Compruebe asociación, campos de entrada y capacidades del RPC invocado.

Si medición y actuación proceden de equipos distintos, utilice el mecanismo documentado de dispositivo virtual o activo para agregar datos. Un activador asociado a un actuador no obtiene automáticamente la medición de otro sensor. Valide relaciones e identidades de destino por separado.

Separe aparición, persistencia y recuperación

Un único límite de activación y recuperación puede causar oscilaciones cuando la lectura fluctúa. Defina umbrales diferentes y una política de repetición cuando corresponda. Las ventanas temporales y el estado histórico requieren scripts y mecanismos de estado; no basta con cambiar el mensaje.

La desconexión necesita lógica propia. Un activador ejecutado solo con nuevos envíos no se ejecuta porque estos cesen. Use una comprobación de estado o programada adecuada al intervalo normal del dispositivo.

Cada alarma necesita condiciones de aparición y recuperación, política de persistencia y destinatario definido.
Cada alarma necesita condiciones de aparición y recuperación, política de persistencia y destinatario definido. Ver imagen completa ↗

Compruebe la recepción después de guardar el grupo

La documentación de grupos enumera email y WeCom WebHook como opciones integradas. El correo requiere SMTP; el grupo debe estar habilitado y tener contactos. Otros servicios necesitan su RPC personalizado o integración documentada. El nombre de un canal no demuestra que esté instalado y operativo.

Use un canal de prueba e incluya alias del equipo, ubicación, hora, estado y acción sugerida. Revise ejecución, registro y recepción por separado. Guardar el grupo es solo un paso de configuración.

Interfaz oficial de demostración en chino: el registro muestra el estado del evento; confirme la entrega en el receptor.
Interfaz oficial de demostración en chino: el registro muestra el estado del evento; confirme la entrega en el receptor. Ver imagen completa ↗

Realice cuatro pruebas antes de la puesta en marcha

Pruebe datos normales, aparición de alarma, anomalía persistente y recuperación. Anote cuántas alarmas y notificaciones se esperan y quién las ve en cada fase. Así detectará duplicados, recuperaciones ausentes y destinatarios erróneos.

Documente cómo deshabilitar temporalmente una regla, quién mantiene los umbrales y cómo investigar eventos. Si la alarma acciona un equipo, añada lectura del estado físico. Enviar un mensaje no prueba que el actuador haya completado la acción.

  1. Los datos normales no deben generar alarmas inesperadas.
  2. Los datos anómalos deben crear el evento y aviso de prueba previstos.
  3. La anomalía persistente debe respetar la política de recordatorios.
  4. La recuperación debe resolver el estado y notificar según lo acordado.

Preguntas frecuentes

¿Por qué no hay alarmas después de guardar el modelo?

Revise asociación, campos y ejecución; después RPC, habilitación del grupo y receptor. Guardar correctamente no demuestra una ejecución correcta.

¿Un activador por umbral detecta que un equipo deja de enviar?

No si depende únicamente de nuevos mensajes. Use comprobaciones de estado o programadas acordes con su intervalo normal.

Referencias y lecturas adicionales

Esta guía se basa en las fuentes oficiales siguientes. Los diagramas explican el método; consulte la documentación de su versión para menús, campos y funciones exactos. Las fuentes enlazadas están en chino.