Cómo diseñar dashboards de ThingsBoard para tomar decisiones

El tablero que obliga a revisar todo

Una pantalla muestra temperatura, humedad, presión, corriente, potencia, disponibilidad, nivel de señal y ocho estados. Todos los valores están actualizados, pero el supervisor todavía debe recorrer cada tarjeta para descubrir qué cambió. El tablero informa; no orienta.

ThingsBoard ofrece gráficos, tablas, mapas, valores actuales, widgets de alarmas y controles. También permite configurar ventanas de tiempo, aliases que resuelven dispositivos o activos, filtros y estados para navegar desde una vista general hasta un detalle. La selección y jerarquía siguen siendo una decisión de diseño operativo.

Empezar por la pregunta

Antes de elegir un widget conviene escribir qué debe poder responder la persona que usa la vista. Por ejemplo:

• ¿qué equipos requieren atención ahora?;
• ¿la desviación es puntual o viene creciendo?;
• ¿afecta a un activo o a todo un sector?;
• ¿el dato está actualizado?;
• ¿quién tomó el evento y cuál es el siguiente paso?

Una vista general puede mostrar estado, severidad y antigüedad de la última comunicación. Al seleccionar un equipo, un segundo estado puede abrir tendencia, variables relacionadas y alarmas recientes. La documentación oficial denomina *states* a esas vistas navegables y *entity aliases* al mecanismo que vincula widgets con el contexto de entidades.

La navegación ayuda a evitar dos extremos: una pantalla saturada con todos los detalles o una colección de dashboards aislados que obliga a buscar el activo varias veces.

El paquete de Nodira para monitorear el vuelco de efluentes combina visualización local con un dashboard en ThingsBoard. El tablero publica por MQTT a través de conectividad celular; el dashboard permite consultar estado actual e historial y separar las funciones de calidad del efluente de la condición hidráulica.

Esa jerarquía evita presentar todas las claves como equivalentes. Una vista puede resumir disponibilidad y actualización; otra puede reunir tendencias por función de medición. Un dato sin unidad, timestamp o calidad visible no debería adquirir autoridad sólo por aparecer en una gráfica.

La vista también debe revelar si muestra una señal cruda, un valor escalado o una variable calculada. Cuando un indicador depende de compensaciones o tablas de conversión, el usuario necesita saberlo y poder consultar el estado de esa transformación. Mostrar un número razonable sin identificar su origen dificulta detectar una parametrización equivocada.

Sobre esa base pueden diseñarse reportes periódicos y avisos ante eventos, siempre que se definan condiciones, destinatarios y responsabilidades. La disponibilidad de la función no determina por sí sola qué debe reportarse ni cuándo corresponde avisar.

El tiempo también forma parte del dato

Un número actual puede ser insuficiente. Corriente de 18 A puede ser normal en carga y anormal en vacío. Una tendencia puede mostrar si el valor subió gradualmente o cambió después de una intervención. El rango temporal y la agregación deben corresponder a la dinámica del proceso.

Hay tres marcas que conviene distinguir visualmente:

1. 01
   momento de medición;
2. 02
   momento de recepción;
3. 03
   última actualización visible.

Si una conexión se recupera y envía datos atrasados, la gráfica puede completar el historial mientras el valor “actual” requiere otra interpretación. La convención temporal y las pruebas con datos fuera de orden o intervalos sin muestras forman parte del diseño de Nodira.

Contexto antes que decoración

Color y animación deben reservarse para estados que importan. Una alarma crítica, un dato vencido y un equipo detenido por programa no deberían verse igual. Tampoco conviene utilizar verde para indicar “conectado” si el proceso está fuera de condición.

Los elementos mínimos de una vista operativa suelen ser:

• identidad inequívoca del activo;
• estado y tiempo desde la última actualización;
• variable principal con unidad;
• referencia o banda esperada cuando está validada;
• acceso a tendencia y alarmas;
• indicación de responsable o estado de atención cuando corresponda.

El dashboard no debe inferir límites que no fueron aprobados. Si no existe umbral técnico, puede mostrar una tendencia o comparación sin colorear una condición como falla.

Acceso y exposición

ThingsBoard permite asignar dashboards a clientes y también hacerlos públicos. La documentación advierte que un dashboard público puede verse sin autenticación y que las entidades asociadas deben exponerse para mostrar sus datos. En un entorno industrial, publicar una vista no debe ser el camino por defecto.

Nodira revisa quién necesita cada vista, qué entidades puede consultar y si los controles interactivos son apropiados para ese rol. La posibilidad técnica de incluir acciones o comandos en un widget no autoriza a operar un equipo desde esa pantalla. Los permisos, confirmaciones y consecuencias deben diseñarse por separado.

Las funciones de mantenimiento y calibración merecen una vista y permisos distintos de la consulta operativa. Allí puede ser necesario mostrar estados de calibración, habilitar una función después de confirmar que el instrumento está conectado o activar una simulación de prueba. Esas acciones deben quedar restringidas y registradas; no deberían aparecer como controles ordinarios en el dashboard de supervisión.

Validar la vista con quien decide

ThingsBoard ofrece widgets, estados, aliases, filtros y control de acceso. Nodira traduce las tareas a una jerarquía visual y configura navegación y permisos. Operación y mantenimiento validan que la vista permita reconocer la condición y decidir sin reconstruir el contexto en otra pantalla.