Guías de ThinkLink / Operación en campo
¿En línea significa sano en ThinkLink? Latidos y fuentes de estado
Distinga online de API, _online del detector y eventos MQTT, incluyendo latidos vacíos y detección deshabilitada.
Explique fuente y configuración de cada indicador. Recibir algo recientemente no prueba una medición nueva; un latido vacío puede significar en línea solo por configuración.
Definir el significado operativo
Sensores periódicos, interruptores por evento y equipos alimentados continuamente no informan igual. Registre su comportamiento antes de configurar latidos. Verifique la versión instalada, especialmente la semántica de valor vacío documentada para 2.00.099. Conexión del gateway, comunicación del terminal y datos válidos son hechos distintos. Un gateway sano puede tener sensores silenciosos, y un mensaje puede omitir la medición requerida. Muestre fuente del estado y tiempos de actividad y medición.
Conservar vacío y deshabilitado
La documentación actual considera en línea heart_period vacío y no programa vencimiento. No lo sustituya por un intervalo arbitrario. Los valores válidos no vacíos participan en detección temporal. notify_offline usa cadenas TRUE y FALSE y está desactivado por defecto. Desactivarlo conserva el último _online, que deja de ser prueba continua. Ausente, deshabilitado, no cargado y consulta fallida también son estados distintos. Una lectura incompleta no debe convertirse en falso o cero guardado durante otra edición. Relea ambos ajustes.
Interpretar cada campo por separado
API online, server_attrs._online y MQTT data.online difieren en fuente, tipo y momento. También hay diferencias en el instante límite; no espere igualdad instantánea absoluta. El detector usa números y la notificación booleanos. El evento representa una transición, no una instantánea completa ni una alarma de negocio. Recibir históricos puede actualizar actividad sin demostrar una nueva medición. Indique qué fuente alimenta los totales y no cuente un valor retenido tras deshabilitar como evidencia actual.
Probar silencio, recuperación y reconexión
En un equipo de prueba autorizado, registre ajustes y observe envío, silencio, vencimiento y recuperación. Con latido no vacío, el detector declara desconexión estrictamente después de actividad más dos latidos; la entrega asíncrona puede añadir demora. Una captura justo en el límite no basta para demostrar un fallo. Tras reconectar MQTT, consulte estado actual mediante interfaces existentes y coordine eventos posteriores; no suponga que se repetirán todas las transiciones perdidas. Registre horas y resultados, no solo colores.
- Verificar versión, latido e interruptor.
- Identificar fuente y tipo de cada estado.
- Probar silencio, vencimiento, recuperación y reconexión.
- Aceptar por separado estado y alarmas.
Separar estado y alarmas
Un evento de estado no es un flujo de alarma aceptado. Creación de alarmas, destinatarios y escalado requieren configuración y pruebas propias. Presente comunicación, frescura y fallos de negocio por separado, conservando desconocidos y errores de consulta. Historial de eventos o reenvío fiable exige un diseño explícito; el tema MQTT no implica una cola fiable. La entrega debe explicar fuentes, latido, valores vacíos, desactivación y pruebas.
Preguntas frecuentes
¿Se puede sustituir un latido vacío por quince minutos?
No. Tiene un significado propio en la documentación actual; consérvelo y confirme versión.
¿_online = 1 prueba conexión con detección deshabilitada?
No. Puede ser un valor antiguo. Consulte actividad actual o la interfaz de estado elegida.
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.