Durante los apagones de 2024, la Cámara Nacional de Acuicultura estimó pérdidas de hasta 75 millones de dólares mensuales para el sector camaronero, con cortes de red que llegaron a durar 10 horas diarias en algunas zonas. En ese contexto, muchas camaroneras terminaron con el teléfono del técnico de turno sonando cada vez que la red eléctrica caía, así el generador de respaldo tomara la carga sin problema en segundos. El resultado, documentado también en salas de monitoreo hospitalarias mucho antes de que existiera el IoT agrícola, tiene nombre: fatiga de alarma. Cuando la mayoría de los avisos no exige ninguna acción, el equipo deja de reaccionar con la misma urgencia a todos —incluido el que sí la necesitaba.
El problema no es tener pocas alarmas, es tener las alarmas equivocadas
La tentación natural al instrumentar una piscina es configurar una alarma por cada variable que se sale de rango: oxígeno, pH, temperatura, nivel de combustible, estado de la red eléctrica. Parece prudencia, pero en la práctica hace lo contrario a proteger la operación.
La evidencia de otros entornos de monitoreo intensivo es contundente: en unidades de cuidado intensivo, donde el problema se ha estudiado durante décadas, entre el 80% y el 99% de las alarmas de un monitor cardíaco resultan falsas o clínicamente irrelevantes, y solo entre el 5% y el 13% de las alarmas totales son realmente accionables. El Emergency Care Research Institute ha señalado la fatiga de alarma como el riesgo tecnológico número uno en salud durante más de una década consecutiva, precisamente porque un exceso de avisos sin jerarquía termina en el mismo desenlace: el personal empieza a silenciar notificaciones, a responder con retraso o a dejar de distinguir cuál alarma sí importaba.
Una camaronera con sensores de oxígeno, energía, combustible y aireadores conectados enfrenta el mismo riesgo si cada lectura fuera de rango dispara el mismo tipo de aviso. La pregunta correcta no es “¿cuántas alarmas configuro?”, sino “¿cuáles de estas alarmas justifican sacar a alguien de la cama a las 3 de la mañana, y cuáles pueden esperar a que el equipo revise el dashboard con café en mano?”.
Tres preguntas para decidir si un evento despierta al equipo
Antes de asignar el canal de una alarma (dashboard silencioso, mensaje al chat, llamada que no se puede ignorar), conviene pasar el evento por tres filtros:
- ¿Cuánto tiempo hay para actuar antes de que el daño sea irreversible? Si el margen se cuenta en minutos u horas, la alarma es candidata a despertar a alguien. Si se cuenta en días —una tendencia de crecimiento más lento, una desviación leve de salinidad—, puede esperar.
- ¿Ya existe una respuesta automática en marcha, o el evento depende de una decisión humana? Un generador que toma la carga en segundos tras un corte de red no necesita despertar a nadie: el sistema ya resolvió el problema. Un generador que no toma la carga sí lo necesita, porque ahí el problema sigue sin resolver.
- ¿Es un evento aislado y redundante, o parte de una falla compuesta? Una piscina con oxígeno bajando de forma normal a las 11 pm, dentro de su patrón histórico, no es urgente. La misma caída, combinada con un aireador que no arrancó, sí lo es: la falla compuesta es la que de verdad se come el margen de reacción.
Estos tres filtros son también la razón por la que correlacionar variables entre sí produce alarmas mucho más útiles que evaluar cada sensor de forma aislada. “Red eléctrica caída” es un dato; “red eléctrica caída Y el generador no reporta arranque Y el aireador dejó de transmitir consumo” es una alarma.
Eventos que sí justifican una llamada a las 3 am
En una operación acuícola típica, la lista de eventos que ameritan despertar al equipo es más corta de lo que la mayoría de sistemas configura por defecto:
- Oxígeno en zona crítica con la aireación ya al máximo. Como hemos explicado al anticipar una caída de oxígeno, por debajo de 2 mg/L el margen de reacción del camarón blanco se cuenta en 1 o 2 horas. Si además todos los aireadores disponibles ya están encendidos y el oxígeno sigue cayendo, no queda ningún recurso automático por activar: se necesita una decisión humana —encender un aireador de respaldo, reducir densidad de alimento— de inmediato.
- Corte de red eléctrica sin transferencia exitosa al generador. La diferencia entre un evento rutinario y una emergencia real está exactamente en esa palabra: “exitosa”. Durante los apagones de 2024, camaroneras en las zonas altas de El Oro dependían de generadores para mantener la aireación funcionando; el problema nunca fue el corte en sí —eso ya era previsible y frecuente— sino los casos en que el generador de respaldo no arrancaba o no tomaba la carga completa, dejando a los aireadores sin energía real aunque el sistema mostrara “generador activo”.
- Caída de nivel de combustible con el motor apagado. Como detallamos al auditar combustible sin bitácora manual, un motor detenido tiene un consumo esperado de cero; una pendiente de caída sostenida en esa ventana es, con altísima probabilidad, una fuga o una sustracción activa, no ruido de sensor. Es una de las pocas alarmas donde el patrón es tan simple —binario, sin zonas grises— que casi no genera falsos positivos, y por eso vale la pena que suene fuerte cuando aparece.
- Aireador crítico detenido en una piscina de biomasa alta. No es lo mismo que un aireador de una piscina recién sembrada se detenga (biomasa baja, consumo de oxígeno bajo, margen de horas) a que se detenga el aireador principal de una piscina cerca de cosecha con alta densidad. El mismo evento —“aireador sin consumo eléctrico reportado”— necesita un umbral de urgencia distinto según la biomasa de la piscina en ese momento del ciclo.
Eventos que pueden esperar hasta la mañana
La otra cara de la moneda es igual de importante, porque es la que le da credibilidad a las alarmas de arriba. Estos eventos merecen quedar registrados en el dashboard, no una llamada nocturna:
- Oscilaciones de pH o salinidad dentro del rango histórico normal de la piscina, aunque se acerquen a un límite genérico de “manual”.
- Un pico de oxígeno de la tarde levemente más bajo que el promedio reciente, sin que la pendiente nocturna se acelere por encima de lo calibrado.
- Corte de red eléctrica con transferencia exitosa y confirmada al generador (o, de día, con los aireadores operando con normalidad bajo energía solar/red).
- Turbidez que sube o baja dentro del rango esperado para la fase del ciclo de cultivo, sin que coincida con otra señal de alerta.
Tratar estos eventos como “informativos” en vez de “urgentes” no es bajar la guardia: es lo que evita que la alarma de las 3 am dejar de significar algo. Un sistema que despierta al equipo cinco veces por semana por eventos que se resolvieron solos entrena al operador a ignorar la sexta llamada, que puede ser la que sí importaba.
Diseñar el protocolo: tres niveles, no un interruptor binario
La forma más efectiva de aplicar esta lógica en la práctica —extendiendo el mismo protocolo escalonado que ya usamos para oxígeno disuelto a las demás variables de la finca— es definir tres niveles de severidad, cada uno con su canal y su destinatario:
- Informativo (dashboard). El evento queda registrado y visible para revisión en la próxima ronda de turno, sin generar ninguna notificación push. Ejemplos: las oscilaciones normales listadas arriba.
- Alerta (mensaje al chat del equipo). El evento no exige una respuesta inmediata a las 3 am, pero sí antes de que empiece el turno del día: un aireador secundario detenido en piscina de biomasa media, un pico de la tarde débil, una pendiente de oxígeno algo más pronunciada de lo habitual.
- Crítico (llamada o notificación que no se puede silenciar). Reservado exclusivamente para los eventos de la lista de arriba: oxígeno crítico sin recursos de aireación disponibles, generador que no tomó la carga, fuga o sustracción de combustible en curso, aireador principal caído en piscina de alta biomasa.
Calibrar qué entra en cada nivel no sale de una tabla genérica de industria, sino del histórico propio de cada piscina y de cada finca: una operación con generadores nuevos y probados puede tratar un corte de red como nivel 1 casi siempre, mientras que una con generadores viejos —el caso de muchas camaroneras ecuatorianas tras los apagones de 2024, donde justamente las fallas del equipo de respaldo (no el corte en sí) causaron la mortalidad— debe tratar cada corte de red como candidato a nivel 3 hasta confirmar la transferencia.
De sensores aislados a un sistema que correlaciona
Todo lo anterior depende de una condición técnica: que las variables —oxígeno, estado del generador, consumo del aireador, nivel de combustible— lleguen a un mismo lugar donde puedan cruzarse entre sí, en vez de vivir cada una en su propio sensor con su propia alarma desconectada de las demás. Es la diferencia entre un sistema que reporta “la red cayó” y uno que reporta “la red cayó y el aireador dejó de consumir energía hace 4 minutos”: el segundo dato es el que realmente amerita una llamada, y solo existe si ambas señales conviven en el mismo dashboard de Yubox Cloud, junto con el control de aireadores y el monitoreo de energía de la finca.
En resumen
Más alarmas no es más seguridad: es, pasado cierto punto, menos seguridad, porque entrena al equipo a ignorar el teléfono. Un evento merece despertar a alguien cuando el margen de reacción se mide en minutos u horas, cuando no existe ya una respuesta automática resolviéndolo, y cuando forma parte de una falla compuesta y no de una variación aislada dentro de lo normal. Diseñar tres niveles de severidad —informativo, alerta y crítico— con destinatarios y canales distintos, calibrados contra el histórico propio de cada piscina y no contra una tabla genérica, es lo que convierte un sistema de sensores en un sistema de alarmas en el que el equipo realmente confía.
¿Quiere revisar cómo escalonar las alarmas de su operación entre oxígeno, energía, combustible y aireación? Escríbanos y evaluamos su configuración actual.