> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-es/kilo-iot-server/rules-engine/automation-patterns.md). # Patrones de automatización Patrones de automatización para Kilo IoT — alarmas por umbral, enriquecimiento de múltiples sensores, escalado, CEL dinámico. Esta página presenta patrones de automatización probados para implementaciones de IoT empresariales. Cada patrón describe un escenario operativo real, la estructura del diagrama BPMN, las expresiones CEL involucradas y cuándo usar el patrón. La mayoría de estos patrones se construyen visualmente colocando nodos en el lienzo BPMN. CEL aparece en los puntos específicos donde la regla necesita lógica exacta, clasificación o mensajería dinámica. Como CEL admite condiciones anidadas, valores calculados, comparaciones entre sensores y generación dinámica de texto, la gama de automatizaciones que puedes modelar es amplia: desde una sola comprobación de umbral hasta flujos de trabajo de varios pasos y varios sensores con rutas de respaldo y escalamiento gradual. Estos patrones se basan en los tipos de nodo y las herramientas del lienzo cubiertos en [Referencia de nodos](/kilo-docs-es/kilo-iot-server/rules-engine/node-reference.md) y [Editor visual](/kilo-docs-es/kilo-iot-server/rules-engine/visual-editor.md). Si eres nuevo en el Motor de reglas, empieza con [Crear reglas](/kilo-docs-es/kilo-iot-server/rules-engine/creating-rules.md) para entender lo básico. *** ## Patrón 1: alarma simple por umbral El patrón de automatización más común. Un sensor informa un valor, la regla comprueba si supera un límite y genera una alarma si es así. ### Estructura del diagrama ``` Evento de inicio → Tarea de script → Compuerta exclusiva → Establecer alarma → Evento de fin ↓ (predeterminado) Evento de fin ``` ### Configuración **Evento de inicio:** Vinculado al dispositivo y al sensor de destino; por ejemplo, una sonda de temperatura de almacenamiento en frío que informa en grados Celsius. **Tarea de script** — "Comprobar umbral": ``` {"above_threshold": vars.value > 30.0} ``` Esta expresión crea una marca booleana. La compuerta usa esta marca para decidir si debe generar una alarma. **Compuerta exclusiva** — Dos ramas: * **Rama de alarma:** Condición `vars.above_threshold == true` — enruta al nodo Establecer alarma * **Rama predeterminada:** Enruta a un Evento de fin (no se requiere ninguna acción cuando la lectura está dentro del rango) **Establecer alarma:** Configurado con una [Definición de alarma](/kilo-docs-es/kilo-iot-server/alarm.md) existente y un mensaje de motivo como `"La lectura de temperatura superó los 30 °C"`. El nodo Establecer alarma activa la definición: la severidad, los canales y el escalamiento se configuran en la página de Alarmas, no en la propia regla. ### Cuándo usar este patrón * Monitoreo de temperatura en almacenamiento en frío: alerta cuando la temperatura supera el umbral seguro * Monitoreo ambiental de salas de servidores: alerta cuando la temperatura ambiente o la humedad superan los límites operativos * Monitoreo de vibración de equipos: alerta cuando la magnitud de la vibración supera la línea base * Cualquier escenario de un solo sensor y un solo umbral en el que una lectura fuera de rango requiera atención inmediata *** ## Patrón 2: escalamiento multinivel Cuando un solo umbral no es suficiente, este patrón clasifica la lectura en niveles de severidad y enruta cada nivel a una definición de alarma distinta, lo que permite diferentes canales de notificación, cadenas de escalamiento y procedimientos de respuesta para cada severidad. ### Estructura del diagrama ``` Evento de inicio → Tarea de script → Compuerta exclusiva → Establecer alarma (Crítica) → Evento de fin ↓ (advertencia) Establecer alarma (Advertencia) → Evento de fin ↓ (predeterminado) Evento de fin ``` ### Configuración **Tarea de script** — "Clasificar severidad": ``` {"level": vars.value > 80 ? "critical" : vars.value > 50 ? "warning" : "normal"} ``` Esta expresión evalúa la lectura y asigna un nivel de severidad como una cadena. **Compuerta exclusiva** — Tres ramas: * **Rama crítica:** Condición `vars.level == "critical"` — enruta a la definición de alarma Crítica (SMS al ingeniero de guardia, correo electrónico al gerente de instalaciones) * **Rama de advertencia:** Condición `vars.level == "warning"` — enruta a la definición de alarma de Advertencia (correo electrónico al equipo de operaciones) * **Rama predeterminada:** Enruta a un Evento de fin (las lecturas normales no requieren acción) ### Cuándo usar este patrón * Monitoreo de HVAC con respuesta gradual: advertencia cuando una zona se desvía del rango de confort, crítica cuando alcanza niveles inseguros * Cumplimiento ambiental: advertencia cuando una lectura se acerca a un límite normativo, crítica cuando lo supera * Monitoreo de baterías: advertencia al 20 %, crítica al 10 %, con distinta urgencia de notificación para cada una * Cualquier escenario en el que distintos niveles de severidad requieran diferentes velocidades de respuesta, canales o equipos *** ## Patrón 3: comparación entre múltiples sensores Algunos casos de decisión requieren datos de más de un sensor. Este patrón obtiene una segunda lectura mediante un nodo de Enriquecimiento, calcula la relación entre los dos valores y decide según el resultado. ### Estructura del diagrama ``` Evento de inicio → Enriquecimiento → Tarea de script → Compuerta exclusiva → Establecer alarma → Evento de fin ↓ (predeterminado) Evento de fin ``` ### Configuración **Evento de inicio:** Vinculado a un sensor de temperatura interior. **Enriquecimiento** — "Obtener temperatura exterior": configurado para recuperar la lectura más reciente de un sensor de temperatura exterior en el mismo sitio. El valor enriquecido queda disponible como variable en los nodos posteriores. **Tarea de script** — "Calcular diferencial": ``` {"delta": vars.value - vars.outdoor_temp.value, "needs_alarm": vars.value - vars.outdoor_temp.value > 10} ``` Esta expresión calcula la diferencia de temperatura entre los sensores interior y exterior y marca si la brecha supera el umbral. **Compuerta exclusiva** — Dos ramas: * **Rama de alarma:** Condición `vars.needs_alarm == true` — enruta a Establecer alarma * **Rama predeterminada:** Enruta a Evento de fin **Establecer alarma:** Configurado con un mensaje de motivo como `"La diferencia de temperatura interior/exterior supera los 10 grados"`. ### Importante: añade manejo de errores Los nodos de Enriquecimiento dependen de datos externos: el sensor de destino puede estar fuera de línea, no ser accesible o devolver datos obsoletos. Adjunta siempre un **Evento de error de borde** al nodo de Enriquecimiento. Consulta [el Patrón 4](#pattern-4-error-safe-enrichment) para ver el enfoque completo de manejo de errores. ### Cuándo usar este patrón * Monitoreo de eficiencia de HVAC: alerta cuando la brecha de temperatura interior/exterior indica un fallo del aislamiento o un mal funcionamiento del HVAC * Monitoreo de presión diferencial: compara sensores de presión en distintas zonas de la sala limpia * Validación de sensores redundantes: compara lecturas de dos sensores que miden la misma métrica y alerta si divergen significativamente * Cualquier escenario en el que una decisión dependa de la relación entre dos puntos de datos en lugar de un umbral absoluto *** ## Patrón 4: enriquecimiento a prueba de errores Cualquier regla que use un nodo de Enriquecimiento debe manejar la posibilidad de que el enriquecimiento falle. Este patrón envuelve el nodo de Enriquecimiento con un Evento de error de borde que enruta a una alarma de respaldo, garantizando que la regla nunca falle en silencio cuando un sensor de referencia no esté disponible. ### Estructura del diagrama ``` Evento de inicio → Enriquecimiento → Tarea de script → Compuerta exclusiva → Establecer alarma → Evento de fin | ↓ (predeterminado) [Error de borde] Evento de fin ↓ Establecer alarma (respaldo) → Evento de fin ``` ### Configuración **Enriquecimiento:** La misma configuración que en el Patrón 3: obtiene una lectura de un sensor secundario. **Evento de error de borde:** Adjunto al nodo de Enriquecimiento. Si el enriquecimiento falla por cualquier motivo (sensor fuera de línea, tiempo de espera agotado, datos faltantes), el evento de error captura el fallo y enruta al camino de respaldo. **Establecer alarma (respaldo):** Configurado con una definición de alarma diferente y un mensaje de motivo como `"Sensor de referencia fuera de línea — no es posible calcular el diferencial. Se requiere comprobación manual."` Esto asegura que tu equipo de operaciones sepa que la comprobación automatizada no pudo completarse. ### Cuándo usar este patrón * Cualquier regla que use Enriquecimiento y no pueda permitirse fallar en silencio * Escenarios de monitoreo críticos en los que una lectura de comparación faltante es en sí misma una condición que merece alerta * Flujos de trabajo de cumplimiento en los que cada brecha de monitoreo debe documentarse * Como práctica recomendada estándar: adjunta un Evento de error de borde a cada nodo de Enriquecimiento en cada regla *** ## Patrón 5: canalización de transformación de datos Algunos datos de sensores requieren preprocesamiento antes de poder evaluarse de forma significativa. Este patrón encadena múltiples Tareas de script para transformar las lecturas sin procesar mediante pasos de conversión de unidades, calibración o normalización antes de la compuerta de decisión. ### Estructura del diagrama ``` Evento de inicio → Tarea de script (Convertir) → Tarea de script (Calibrar) → Compuerta exclusiva → Establecer alarma → Evento de fin ↓ (predeterminado) Evento de fin ``` ### Configuración **Tarea de script** — "Convertir unidades": ``` {"celsius": (vars.value - 32) * 5.0 / 9.0} ``` Convierte una lectura en Fahrenheit a Celsius. Ajusta la fórmula según tus necesidades específicas de conversión. **Tarea de script** — "Aplicar compensación de calibración": ``` {"calibrated": vars.celsius - 1.5, "above_threshold": vars.celsius - 1.5 > 25.0} ``` Aplica una compensación de calibración conocida (en este ejemplo, el sensor marca 1,5 grados de más) y comprueba el valor corregido frente al umbral. **Compuerta exclusiva** — Dos ramas: * **Rama de alarma:** Condición `vars.above_threshold == true` * **Rama predeterminada:** Enruta a Evento de fin ### Cuándo usar este patrón * Sensores que informan en unidades no estándar y que necesitan conversión antes de comparar con el umbral * Sensores con compensaciones de calibración conocidas que deben corregirse antes de la evaluación * Normalización de datos para sensores de distintos fabricantes que informan la misma métrica en diferentes escalas * Cualquier escenario en el que los datos brutos de un sensor requieran uno o más pasos de transformación antes de que sean significativos para la toma de decisiones *** ## Patrón 6: enriquecimiento condicional con lógica de respaldo Un patrón más avanzado que combina enriquecimiento, transformación, manejo de errores y decisiones de múltiples ramas en una sola regla robusta. Este patrón representa un flujo de trabajo de automatización de grado de producción. ### Estructura del diagrama ``` Evento de inicio → Enriquecimiento → Tarea de script (Analizar) → Compuerta exclusiva → Establecer alarma (Crítica) → Evento de fin | ↓ (advertencia) [Error de borde] Establecer alarma (Advertencia) → Evento de fin ↓ ↓ (predeterminado) Tarea de script (Respaldo) → Establecer alarma (Sin conexión) → Evento de fin ``` ### Configuración **Enriquecimiento:** Obtiene una lectura de referencia (por ejemplo, la humedad exterior de un almacén). **Evento de error de borde:** Captura fallos de enriquecimiento y enruta a una Tarea de script de respaldo dedicada. **Tarea de script (Respaldo):** ``` {"level": "offline"} ``` Establece el nivel en "sin conexión" para que se active la alarma de respaldo. **Tarea de script (Analizar):** ``` {"delta": vars.value - vars.reference.value, "level": vars.value - vars.reference.value > 20 ? "critical" : vars.value - vars.reference.value > 10 ? "warning" : "normal"} ``` **Compuerta exclusiva** — Tres ramas: * **Crítica:** `vars.level == "critical"` * **Advertencia:** `vars.level == "warning"` * **Predeterminada:** Evento de fin Este patrón maneja la ruta feliz (el enriquecimiento tiene éxito, los datos se analizan y se activa la alarma adecuada), la ruta de advertencia y la ruta de fallo (el enriquecimiento falla y se alerta al equipo de operaciones sobre el problema del sensor): todo en una sola regla. *** ## Prácticas recomendadas para crear reglas de automatización ### Empieza simple, añade complejidad cuando sea necesario Empieza con el Patrón 1 (umbral simple) y solo añade enriquecimiento, clasificación multinivel o pasos de transformación cuando el escenario operativo realmente los requiera. Una regla simple que funciona de forma fiable es mejor que una compleja que sea difícil de depurar. ### Pon nombres descriptivos a tus nodos Los nombres de nodo predeterminados, como "Tarea de script 1", no significan nada durante la depuración. Nombra los nodos según lo que hacen: "Comprobar umbral de temperatura", "Clasificar severidad", "Obtener lectura exterior". Tu yo del futuro —y tus colegas— lo agradecerán al revisar la regla a las 3 de la mañana. ### Añade siempre una rama predeterminada en las compuertas Toda Compuerta exclusiva debe tener una rama predeterminada que enrute a un Evento de fin. Esto garantiza que la regla se complete correctamente incluso si ninguna de las condiciones explícitas coincide. Sin una rama predeterminada, la regla no tiene un camino adelante para valores inesperados. ### Adjunta siempre Eventos de error de borde a los nodos de Enriquecimiento El Enriquecimiento depende de datos externos. Si el sensor de destino está fuera de línea, eliminado o temporalmente inaccesible, el enriquecimiento fallará. Un Evento de error de borde proporciona una ruta de respaldo elegante: enrutar a una alarma de "sensor fuera de línea" o saltarse por completo la lógica dependiente del enriquecimiento. ### Usa ventanas de supresión de alarmas para evitar inundaciones de notificaciones Cuando un umbral se supera de forma continua, la supresión y la repetición de la definición de alarma evitan que los operadores se vean inundados con notificaciones duplicadas. Configura estos ajustes en tu [Definiciones de alarmas](/kilo-docs-es/kilo-iot-server/alarm.md) en lugar de intentar incorporar la lógica de supresión en la propia regla. ### Mantén las expresiones simples Las expresiones CEL deben ser fáciles de leer y entender. Si una expresión crece más allá de una sola línea, divide la lógica en varias Tareas de script. Cada tarea se encarga de un cálculo y los resultados pasan al siguiente paso como variables. ### Una regla por asunto Resiste la tentación de crear una sola regla que supervise temperatura, humedad, CO2 y vibración simultáneamente. Las reglas separadas son más fáciles de versionar, probar, desplegar y depurar de forma independiente. Si una regla necesita actualizarse o revertirse, las demás siguen ejecutándose sin verse afectadas. ### Construye e implementa deliberadamente Después de hacer cambios, compila la regla para validarla. Revisa el nombre y el comentario del artefacto de compilación. Implementa solo cuando estés seguro de que la regla es correcta. El flujo explícito de compilar y luego implementar existe para evitar que cambios no probados lleguen a producción. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kiloiot.io/kilo-docs-es/kilo-iot-server/rules-engine/automation-patterns.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.