CAPÍTULO 6 · Los datos empiezan a llegar
Una alarma no termina en superar un umbral
Cuando un valor cruza un límite, podemos reconocer una condición que merece atención. Pero el trabajo no termina en ese instante. La condición puede continuar, alguien puede reconocerla y finalmente puede desaparecer. Si representamos todo con un único booleano, perderemos diferencias que importan para interpretar y atender el evento.
Modelamos la alarma mediante estados y transiciones permitidas. Así podemos discutir qué significa activarla, reconocerla o resolverla y qué eventos producen cada cambio. El modelo ayuda a evitar mensajes repetidos que no representan novedades y a conservar una secuencia comprensible para quien debe responder.
La alarma ya expresa una situación del negocio. El siguiente paso parece obvio: comunicarla o ejecutar una acción asociada. Sin embargo, enviar un correo o llamar a otro servicio dentro de la misma petición introduce tiempos y fallos que nuestro servidor no controla. Necesitamos separar la decisión de negocio del efecto que ocurre fuera de él.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
La alarma cambia por eventos
Los eventos pueden activar, reconocer y resolver una alarma; el flujo concreto define retornos y transiciones adicionales. Este mapa es un modelo didáctico.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Normal. Condición dentro de umbral
- Activa. Evento activa la alarma
- Reconocida. Operador acusa recibo
- Resuelta. Condición vuelve a normalidad
01 / EL PROBLEMA
¿Para qué sirve?
Enviar un correo por cada muestra alta produce ruido. Una alarma debe distinguir entrada a condición, permanencia y recuperación.
02 / COMPRENDER
El concepto, explicado
Estados posibles: normal, alto y recuperación pendiente. Un retorno normal breve no confirma recuperación; el tiempo de rearme filtra rebotes.
Bloquea el estado por sensor cuando hay varias ingestas concurrentes. El evento de detección y el estado de entrega del correo son datos diferentes.
03 / CONSTRUIR
Implementación paso a paso
- Define estados y transiciones.
- Establece rearme y límites.
- Actualiza estado dentro de transacción.
- Emite un evento solo al cambiar condición.
04 / APLICAR
Ejemplo en SensorHub
# Ejemplo de regla pura simplificada.
def transition(state, *, value, threshold):
if value > threshold and state == "normal":
return "high", "alarm_started"
if value <= threshold and state == "high":
return "rearming", None
if value > threshold and state == "rearming":
return "high", None
return state, None
# La recuperación definitiva necesita persistir normal_since
# y comparar duración normal con el tiempo de rearme.Cómo leer el ejemplo
- La regla no envía mensajes; retorna una intención de evento.
- El servicio de estado debe agregar tiempo de rearme y persistencia.
- Puedes probar transiciones sin conectar SMTP.
Error habitual
Una transición sin bloqueo puede duplicar eventos. Una regla sin duración recupera demasiado pronto.
05 / PRACTICAR
Tu turno
Simula alto→normal breve→alto.
Ver solución orientativa
Hay una sola alarma inicial; el rebote conserva la condición y no produce otra notificación.
06 / VERIFICAR
Cómo sabes que funciona
- Una condición persistente no genera un correo por muestra.
- La recuperación se confirma solo después del tiempo acordado.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Tareas, outbox y efectos externos →Continuar en modo relato