Nadie discute si una plataforma IoT necesita buena visualización. Los datos de sensores que nadie mira son una factura de almacenamiento. Todos los compradores con los que hablamos ponen “dashboards personalizados” entre los primeros requisitos de la lista, y todos los proveedores, nosotros incluidos, responden con una demo: un gauge, un gráfico de líneas, un mapa con pines, unos cuantos widgets en una cuadrícula. ThingsBoard y Grafana aparecen en la misma conversación, y cada uno produce una demo igual de convincente.
La demo es el problema. Un dashboard para un solo dispositivo en una pantalla grande no dice nada de lo que pasa cuando la flota tiene 400 dispositivos, el cliente quiere un tipo de gráfico que el producto no incluye y las personas que necesitan los datos son técnicos que nunca van a abrir una laptop. Esas tres cosas deciden si la visualización escala, y ninguna aparece en una demo.
Este artículo explica cómo estructuramos la visualización en TagoIO para una flota, y dónde todavía hay que escribir código.
Un dashboard para cientos de dispositivos
Lo primero que se rompe después de la demo es la cantidad de dashboards. Si cada dispositivo tiene el suyo, el dispositivo 400 significa el dashboard 400, y un cambio de layout significa 400 ediciones. Clonar parece razonable con diez dispositivos y es inmanejable con cincuenta.
Un Blueprint Dashboard, en cambio, vincula los widgets a los dispositivos en tiempo de ejecución. Construyes un solo layout. Cada widget apunta a un slot del blueprint en lugar de a un dispositivo fijo, y cada slot tiene un filtro por tag (type=pump, por ejemplo) que decide qué dispositivos aparecen en su lista desplegable. El usuario elige un dispositivo en la parte superior del dashboard, todos los widgets asociados a ese slot se recargan, y el mismo dashboard sirve para todas las bombas que hayas etiquetado. Un dashboard admite hasta 20 slots, así que una sola vista muestra una bomba y un tanque lado a lado, y las condiciones de filtro pueden encadenar slots para que al elegir un cliente la lista de dispositivos se reduzca a los sensores de ese cliente.
Lo difícil es la disciplina, no las funcionalidades. Blueprint solo funciona si los dispositivos que comparten un slot usan los mismos nombres de variables. Un widget que lee pressure queda en blanco en el dispositivo que envía pump_pressure. Define los nombres de variables y el esquema de tags en el Payload Parser o el Connector antes de que exista el primer dashboard, porque renombrar variables en 400 dispositivos después es una semana que nadie presupuesta. Blueprint tampoco controla quién ve qué; eso lo hacen las políticas de Access Management, que asocian usuarios de TagoRUN a dispositivos por tag.
Cuando el widget que necesitas no existe
Los widgets nativos cubren los casos habituales: gráficos, gauges, mapas, tablas, listas de dispositivos y de usuarios, formularios para enviar datos de vuelta. Tarde o temprano un cliente pide algo que el producto no incluye: un mapa de calor hexbin del piso de un almacén, un gauge circular con los colores de su manual de marca, una forma de gráfico que solo existe en una librería.
El Custom Widget es la vía de escape. Es una celda en un dashboard Normal o Blueprint que carga tu propio HTML, CSS y JavaScript desde una URL que alojas tú (TagoIO Files funciona). Cualquier librería web de gráficos encaja, y el tutorial de ECharts es la forma más rápida de ver cómo se conectan las piezas: incluir la librería custom-widget de TagoIO, recibir las variables del dispositivo configurado, dibujar. Los Custom Widgets acceden al modelo de datos completo, incluidas las actualizaciones en tiempo real, el envío de datos de vuelta y la ejecución de un Analysis, y funcionan dentro de TagoRUN como cualquier otro widget.
Nota honesta: esto es código. Alguien de tu equipo escribe y aloja JavaScript. Es un precio justo por un gráfico que la plataforma no tiene y un mal negocio cuando un widget nativo hace casi todo el trabajo.
También existe el Custom Dashboard experimental, donde la página entera es tu archivo HTML, alojado y versionado por TagoIO, y los datos llegan por consultas TagoSQL guardadas. Se ejecuta en Admin y no está disponible en TagoRUN, ni en public share, ni en distribute, así que trátalo como una herramienta interna de reportes. El AI Dashboard experimental construye un layout de página completa en Admin a partir de un prompt en lenguaje natural y lo refina por chat; útil para prototipar una vista antes de comprometerte con una cuadrícula de widgets, y tampoco está disponible en TagoRUN.
Las mismas vistas en el teléfono, con tu marca
Lo tercero que la demo esconde es la audiencia. Las personas que más necesitan la visualización no están en la oficina: responsables de instalaciones, técnicos de campo, el jefe de operaciones del cliente. No van a iniciar sesión en una consola de Admin ni van a tolerar un dashboard ilegible en el teléfono.
TagoRUN es donde los usuarios finales ven los dashboards que construiste: un portal web bajo tu dominio y tu marca, con su propia gestión de usuarios y políticas de acceso por usuario. El mismo Blueprint Dashboard se renderiza ahí dentro, resuelto a los dispositivos que cada usuario puede ver. La app móvil de TagoRUN les da esos mismos dashboards en iOS y Android sin trabajo de desarrollo adicional.
Las notificaciones push son la parte que la gente olvida revisar en una demo, y son la mitad del valor del móvil. Una Action que vigila un umbral, o un Analysis que ejecuta una verificación más elaborada, envía una notificación directamente al teléfono de los usuarios de TagoRUN registrados. Las notificaciones enviadas desde un Analysis pueden llevar botones, así que un técnico confirma una alerta sin abrir un dashboard.
Si la ficha de la tienda tiene que llevar tu nombre y no el nuestro, el add-on Custom Mobile App publica una versión white-label de la app en el App Store y en Google Play con tu marca. Hay una tarifa única por empaquetado y publicación; el precio está en la página del Profile en Admin.
El límite que va a alcanzar un dashboard muy cargado
Cada carga de dashboard consume data output. Cada vez que alguien abre un dashboard en Admin o en TagoRUN, TagoIO cuenta una salida por registro mostrado, así que un dashboard que renderiza 3.000 puntos de datos cuenta 3.000. El contador es independiente del Data Output Service y no se factura, pero tiene un techo mensual rígido por plan que no puedes subir por tu cuenta:
| Plan | Registros de dashboard por mes |
|---|---|
| Free | 3.000.000 |
| Starter | 15.000.000 |
| Scale | 50.000.000 |
Llegar al techo significa que los dashboards fallan hasta que el mes se reinicia.
Diseña pensando en eso. Un gráfico que traza un mes de lecturas de un minuto carga unos 43.000 registros cada vez que un técnico le echa un vistazo. Haz la agregación en un Analysis, guarda el resumen en una variable y grafica eso. Configura rangos de tiempo cortos por defecto. Revisa la fila “Dashboard Output” en Hard Limits dentro de Admin antes de que lo haga un cliente, y consulta los techos actuales en salida de datos para dashboards.
Una lista de verificación antes de comprometerte
- ¿Puede un solo dashboard servir a todos los dispositivos de un tipo, elegidos en tiempo de ejecución, sin clonar?
- ¿Están definidos los nombres de variables y el esquema de tags antes de que exista el primer dashboard?
- Cuando un cliente pide un gráfico que el producto no tiene, ¿puedes agregarlo con una librería web y sigue funcionando en el portal del usuario final?
- ¿Reciben los usuarios finales los mismos dashboards en la web y en el teléfono con tu marca, y notificaciones push desde las mismas reglas?
- ¿Sabes cuánto cuesta en data output un dashboard muy cargado, y dónde está el techo?
Una demo no responde ninguna de estas preguntas. Una semana con una flota etiquetada, un Blueprint Dashboard, un Custom Widget y la app móvil en el teléfono de un técnico responde todas.
