Aireadores, oxígeno y combustible en un solo dashboard

Es común que una camaronera termine con tres pantallas —o tres pestañas del mismo sistema— para ver lo que en realidad es un solo problema: el oxígeno de la piscina, el estado de los aireadores que lo sostienen y el combustible que alimenta al generador que mueve todo lo anterior. Cada gráfica por separado se ve correcta. El problema aparece cuando algo falla, porque nadie tiene tiempo, a las 3 de la mañana, de abrir tres pantallas y cruzar mentalmente tres líneas de tiempo distintas. Un dashboard que integra estas tres variables no es una preferencia estética: es la diferencia entre ver un dato y ver una causa.

Por qué juntarlas no es solo “ponerlas una al lado de otra”

El error más común al integrar variables distintas en un mismo dashboard es tratarlas como si fueran del mismo tipo de dato. No lo son, y esa diferencia importa para el diseño:

Oxígeno disuelto es una curva continua: un valor en mg/L que sube y baja de forma suave a lo largo del día, con un pico hacia la tarde y un mínimo antes del amanecer.
Estado del aireador es una serie de eventos binarios: encendido/apagado, más el consumo eléctrico asociado mientras está encendido. No tiene sentido graficarlo como una curva continua; se representa mejor como una franja de tiempo (timeline) que marca cuándo estuvo activo cada equipo.
Combustible combina dos naturalezas distintas: el nivel del tanque es una curva que baja de forma escalonada, y el flujo hacia el motor es una tasa (litros/hora) que solo tiene sentido mientras el generador está encendido.

Superponer estas tres representaciones —curva, franja de eventos y nivel— en el mismo eje de tiempo, no en tres gráficas independientes con sus propios ejes, es lo que convierte “tres sensores” en “una historia”. El objetivo del dashboard no es mostrar más datos: es hacer visible, de un vistazo, la secuencia causa-efecto que ya existe físicamente en la piscina pero que normalmente vive repartida en tres sistemas.

Para que la superposición funcione, cada variable necesita el tipo de visualización que corresponde a su naturaleza, no un mismo tipo de gráfica genérica forzada sobre las tres:

Curva de oxígeno disuelto, con banda de referencia (zona segura, zona de alerta, zona crítica) coloreada de fondo, para que el ojo detecte de inmediato si la lectura actual está entrando en territorio peligroso sin tener que leer el valor numérico.
Timeline de estado de aireadores, una franja por equipo, con el color indicando encendido/apagado y el ancho de cada bloque representando cuánto tiempo estuvo en ese estado. Superpuesta sobre la misma línea de tiempo que el oxígeno, esta franja responde de inmediato la pregunta “¿la aireación estaba funcionando cuando el oxígeno empezó a caer?”.
Nivel de combustible como curva escalonada, con marcadores en los recambios (subidas abruptas = recarga) y una franja de fondo que indique cuándo el generador estuvo encendido, para distinguir consumo esperado de una caída con el motor apagado.
KPIs numéricos en la parte superior del dashboard —oxígeno actual, horas de aireación del día, litros de combustible restantes— para la lectura rápida sin necesidad de interpretar ninguna gráfica, pensada para quien abre el dashboard en el celular durante quince segundos.

Este es exactamente el principio detrás de la arquitectura de Yubox Cloud: no una plantilla única de gráfica para cualquier variable, sino un tipo de widget por naturaleza del dato, todos anclados al mismo eje de tiempo.

Tres correlaciones que solo se ven cuando las variables comparten pantalla

Cruzar aireadores, oxígeno y combustible en la misma vista no es solo prolijo: revela patrones que cada gráfica por separado esconde.

1. Retraso entre encendido de aireador y respuesta de oxígeno. Los estudios de campo sobre aireadores de paletas muestran que la mejora medible en oxígeno disuelto tras encender el equipo aparece entre 30 minutos y dos horas después, no de forma instantánea. Si el dashboard solo muestra la curva de oxígeno sin la franja de estado del aireador superpuesta, una caída que en realidad ya está siendo corregida —el aireador encendió hace 20 minutos y el efecto todavía no se nota— se ve indistinguible de una caída sin respuesta. Con ambas señales en la misma vista, el operador sabe si debe esperar el efecto natural del aireador o si necesita escalar la respuesta.

2. Aireador encendido sin el consumo eléctrico esperado. Un aireador puede reportarse “encendido” en el sistema de control y, aun así, no estar aireando de verdad —una correa rota, una hélice trabada—. La señal que delata esto no es el estado binario, sino el consumo eléctrico real del equipo comparado contra su consumo nominal de placa. Superpuesto con la curva de oxígeno, un consumo eléctrico anómalo (muy por debajo de lo esperado) que coincide con una caída de oxígeno que no responde es una alerta mecánica, no solo hidrológica: apunta a revisar el equipo físico, no a encender un aireador adicional que tampoco va a resolver nada si el problema es mecánico.

3. Consumo de combustible fuera de la curva esperada del generador. Como ya explicamos al auditar combustible sin bitácora manual, un generador tiene una curva de consumo conocida según su carga: más aireadores encendidos simultáneamente implica más litros por hora consumidos. Con el estado de los aireadores y el flujo de combustible en la misma vista, un consumo que se dispara sin que haya más equipos encendidos —o que se mantiene alto con menos aireadores activos— es una señal de ineficiencia del generador (filtros sucios, inyectores desajustados) mucho antes de que aparezca como una falla mayor.

Cómo se ve en la práctica: un caso compuesto

Tomemos una madrugada típica: a la 1:40 am el oxígeno de una piscina empieza a bajar de su rango normal. El dashboard integrado muestra, en la misma franja de tiempo, que el aireador principal se apagó a la 1:15 am —25 minutos antes— y que el consumo de combustible del generador cayó a cero en ese mismo instante, mientras que el resto de aireadores de la finca siguen activos con consumo normal. La secuencia completa —aireador apagado, sin consumo de combustible asociado, oxígeno cayendo 25 minutos después— cuenta una historia clara: no es una falla de red eléctrica (los demás equipos siguen operando), es ese aireador específico el que se detuvo, y el operador puede ir directo a revisarlo en vez de recorrer la finca preguntándose qué pasó. Sin las tres señales en la misma vista, esa misma secuencia habría llegado como tres alarmas separadas —oxígeno bajo, aireador inactivo, nada del combustible— que alguien tendría que reconstruir manualmente bajo presión.

Esta es la misma lógica de correlación que ya aplicamos al diseñar qué eventos justifican despertar al equipo a las 3 am: una alarma compuesta —que cruza variables— vale más que tres alarmas aisladas, y un dashboard bien diseñado es lo que hace posible esa composición sin depender de que un humano la arme mentalmente en tiempo real.

Qué se necesita del lado de los datos para que esto funcione

Ningún diseño de dashboard compensa datos que no llegan sincronizados. Para que la superposición de las tres variables sea confiable hacen falta tres condiciones técnicas:

Marca de tiempo consistente en todos los nodos —oxígeno, aireadores, combustible—, típicamente sincronizada vía el propio network server LoRaWAN, para que “25 minutos antes” sea un dato real y no un desfase de reloj entre equipos.
Frecuencia de muestreo suficiente en cada variable, no necesariamente la misma: el oxígeno necesita lecturas cada pocos minutos para capturar su curva, mientras que el estado del aireador puede reportarse por cambio de evento (encendido/apagado) en lugar de polling constante, sin perder precisión temporal.
Todos los datos en la misma plataforma, como ya explicamos al describir el camino completo de un dato desde el sensor hasta el dashboard: si el combustible vive en un sistema y el oxígeno en otro, ninguna superposición visual es posible sin exportar e importar datos a mano, lo que en la práctica significa que nunca se hace.

Conclusión

Un dashboard que integra aireadores, oxígeno y combustible no es tres gráficas más grandes en la misma pantalla: es elegir el tipo de visualización correcto para cada naturaleza de dato —curva, franja de eventos, nivel escalonado— y anclarlas al mismo eje de tiempo para que las correlaciones que ya existen físicamente en la piscina se vean sin que nadie tenga que reconstruirlas mentalmente. Esa es la diferencia entre revisar tres pantallas a las 3 am y entender, en cinco segundos, qué pasó y por dónde empezar a resolverlo.

¿Quiere ver cómo se vería este cruce de variables con los datos reales de su operación? Conversemos o revise el ecosistema de acuicultura de Yubox.