> 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/node-reference.md).
# Referencia de nodos
Referencia de nodos para el motor de reglas — Inicio, Fin, Script, Pasarela, Establecer alarma, Enriquecimiento, Límite.
Cada regla de automatización se construye a partir de un conjunto de tipos de nodo que arrastras al lienzo del editor visual, conectas con flujos y configuras mediante un panel de propiedades. Esta página documenta cada tipo de nodo: qué hace, cuándo usarlo, cómo aparece en el lienzo y cada campo de su panel de propiedades.
Esta página documenta los nodos actualmente disponibles en la paleta en vivo: **Evento de inicio**, **Evento final**, **Tarea de script**, **Puerta exclusiva**, **Configurar alarma**, **Ejecutar comando**, **Enriquecimiento** y **Evento de error de borde**. Los nodos transitorios o planificados se excluyen intencionalmente hasta que formen parte de la superficie activa del editor.
Para obtener una descripción general del propio lienzo —paleta, barra de herramientas y flujo de trabajo general de edición— consulta [Editor visual](/kilo-docs-es/kilo-iot-server/rules-engine/visual-editor.md).
***
## Evento de inicio
El Evento de inicio es el punto de entrada de cada regla. Decide qué la activa: ya sea las lecturas del sensor de un dispositivo o un activador guardado [activador](/kilo-docs-es/kilo-iot-server/rules-engine/triggers.md) que evalúa una condición para uno o más dispositivos. Toda regla debe tener exactamente un Evento de inicio.
### Apariencia visual
Un círculo con un icono de sobre en su interior.
### Cuándo usarlo
Toda regla comienza aquí. No puedes construir una regla válida sin un Evento de inicio.
### Panel de propiedades
Selecciona el Evento de inicio en el lienzo: debajo aparecen un icono de lápiz y uno de papelera. Haz clic en el **lápiz** para abrir su panel de propiedades a la derecha.
**Nombre** — Un campo de texto para la etiqueta del nodo. Marcador de posición: *p. ej., Alarma de incendio*.
**Fuente de inicio** — Un selector con dos opciones que decide qué solicita el resto del panel. Un Evento de inicio nombra una fuente o la otra; se rechaza indicar ambas o ninguna.
| Opción | Desde qué inicia la regla |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Lectura del sensor** | Las lecturas de un dispositivo. La regla se activa cada vez que ese sensor informa. |
| **Condición de disparador** | Un activador guardado [activador](/kilo-docs-es/kilo-iot-server/rules-engine/triggers.md). Su condición puede actuar de inmediato o después de una duración y puede evaluar uno o más dispositivos de forma independiente. La regla se ejecuta cuando el activador la señala. |
**Filtro de eventos** — Se muestra cuando **Fuente de inicio** es **Lectura del sensor**. Una sección titulada «Define qué dispositivos pueden iniciar esta regla.» que contiene dos campos:
| Campo | Descripción |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Dispositivo** | Desplegable de autocompletado con búsqueda. Marcador de posición: *Seleccionar dispositivo*. Enumera todos los dispositivos de tu organización. |
| **Sensor** | Desplegable de autocompletado. Marcador de posición: *Seleccionar sensor*. Deshabilitado hasta que se elige un dispositivo. Muestra solo los sensores que pertenecen al dispositivo seleccionado. |
**Condición de disparador** — Se muestra en lugar del filtro de eventos cuando **Fuente de inicio** es **Condición de disparador**. Un único autocompletado, marcador de posición *Seleccionar activador*, que enumera los activadores definidos en la **Activadores** pestaña.
> Solo se carga la primera página de activadores, y el campo lo indica cuando hay más. Si el activador que necesitas no está en la lista, esa es la razón; consulta [Activadores](/kilo-docs-es/kilo-iot-server/rules-engine/triggers.md).
**Habilitar programación** — Un interruptor (desactivado por defecto). Cuando se activa, aparecen los siguientes campos:
| Campo | Descripción |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Rango de tiempo** | Aparece cuando la programación está activada, con el encabezado *«Rango de tiempo. La regla solo está activa durante este período:»*. Un **Cambiar programación** botón abre el editor, donde eliges los días de la semana en que la regla puede ejecutarse y las **Desde** y **Hasta** horas. Fuera de esa ventana, la regla no se ejecuta. Para una fuente de activador, la supervisión y las cuentas regresivas continúan; solo se omite el intento de ejecución de la regla. |
| **Zona horaria** | Un desplegable que enumera zonas horarias estándar, para que la ventana signifique lo mismo sin importar dónde esté el usuario. |
**Entradas** — Opcional. Una lista de expresiones CEL avanzadas para la preparación de datos. La mayoría de las reglas lo dejan vacío y leen directamente la lectura entrante. Cada entrada tiene:
* Un nombre de entrada (campo de texto)
* Un indicador de tipo (bloqueado en «Expression»)
* Un campo de expresión CEL
* Añade nuevas entradas con el **+ Añadir entrada** botón. Elimina una entrada con su botón de eliminación.
**Salidas** — Opcional. Misma estructura que Entradas, con su propio **+ Añadir salida** botón. Usa las salidas para publicar valores con nombre en `vars` para los nodos posteriores.
**Guardar / Cancelar** — En la parte inferior del panel. Haz clic en **Guardar** para aplicar los cambios, o en **Cancelar** para descartarlos.
### Cómo fluyen los datos desde el Evento de inicio
Las variables del proceso dependen de lo que **Fuente de inicio**.
**Lectura del sensor** proporciona:
| Variable | Contenido |
| ---------------- | --------------------------------- |
| `vars.value` | El valor informado por el sensor |
| `vars.sensor_id` | El identificador único del sensor |
| `vars.timestamp` | La marca de tiempo de la lectura |
**Condición de disparador** proporciona:
| Variable | Contenido |
| ------------------- | ----------------------------------------------------------------------------------------------------------------- |
| `vars.device_name` | El nombre del dispositivo supervisado que satisfizo el activador |
| `vars.subject_kind` | El tipo de recurso supervisado; actualmente `dispositivo` |
| `vars.subject_id` | El identificador único del dispositivo supervisado |
| `vars.sensor_id` | El identificador del sensor utilizado para asociar la ejecución y cualquier alarma con el dispositivo supervisado |
| `vars.detector_id` | El identificador único del activador |
| `vars.timestamp` | La hora de la señal del activador en segundos Unix |
Una regla iniciada por activador no recibe `vars.value`. Consulta [Datos disponibles para la regla](/kilo-docs-es/kilo-iot-server/rules-engine/triggers.md#data-available-to-the-rule) antes de convertir una regla iniciada por sensor.
El Evento de inicio también puede transformar los datos entrantes antes de que se ejecute el resto de la regla:
* **Entradas** crear variables auxiliares locales al nodo para este paso
* **Salidas** escribir valores con nombre en las variables del proceso que los nodos posteriores pueden referenciar
### Ejemplo
Una regla de cumplimiento para almacenamiento en frío para un almacén farmacéutico vincula el Evento de inicio a una sonda de temperatura dentro de la unidad de almacenamiento. La programación se deja desactivada, ya que conviene vigilar la sonda las 24 horas; si fuera una regla que solo debiera ejecutarse fuera del horario laboral, **Cambiar programación** se establecerían esos días y horas según la zona horaria local de la instalación. No se necesitan entradas: el valor bruto de la temperatura basta para que la puerta de enlace posterior lo evalúe.
***
## Evento final
El Evento final termina una ruta de flujo. Cuando la ejecución llega a un Evento final, esa rama de la regla queda completada.
### Apariencia visual
Un círculo con un borde grueso.
### Cuándo usarlo
Cada rama de tu regla debe terminar con un Evento final. Una regla con varias ramas (después de una Puerta exclusiva, por ejemplo) necesita varios Eventos finales: uno por rama.
### Panel de propiedades
| Campo | Descripción |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Nombre** | Un campo de texto para la etiqueta del nodo. Normalmente se deja como «End» o se nombra para describir el resultado de esa rama (p. ej., «Normal — sin acción», «Alarma activada»). |
No se requiere ninguna otra configuración.
### Ejemplo
Una regla que comprueba si una lectura de temperatura está por encima o por debajo de un umbral tiene dos ramas que salen de una Puerta exclusiva. Cada rama termina con su propio Evento final: una etiquetada «Dentro del rango», la otra sigue un nodo Configurar alarma.
***
## Tarea de script
La Tarea de script evalúa una [CEL](https://cel.dev) expresión. Úsala para transformar datos entrantes, calcular valores derivados, clasificar lecturas o preparar variables para decisiones posteriores.
### Apariencia visual
Un rectángulo redondeado con un icono de script (documento con líneas) en la esquina superior izquierda.
### Cuándo usarlo
* Convertir un valor bruto del sensor en una clasificación de severidad
* Calcular la diferencia entre dos valores (después del enriquecimiento)
* Preparar una cadena formateada para un mensaje de alarma
* Establecer una bandera que evalúan las puertas de enlace posteriores
### Panel de propiedades
| Campo | Descripción |
| ---------- | ------------------------------------------------------------------------------------------------------- |
| **Nombre** | Un campo de texto para la etiqueta del nodo. Predeterminado: «Script». Ejemplo: «Clasificar severidad». |
| **Script** | Un campo de expresión CEL de varias líneas (6 filas). Aquí es donde escribes la expresión a evaluar. |
**Entradas** — Una lista de parámetros de entrada evaluados antes de que se ejecute el script. Cada entrada tiene un nombre, un indicador de tipo (bloqueado en «Expression») y un campo de expresión CEL. Úsalos para crear variables auxiliares locales para la tarea. Añade entradas con **+ Añadir entrada**. Elimina con el botón de eliminar.
**Salidas** — Misma estructura que Entradas, con su propio **+ Añadir salida** botón. Úsalas para publicar valores con nombre para los nodos posteriores.
**Guardar / Cancelar** — En la parte inferior del panel.
### Cómo se almacenan los resultados
El patrón más claro es hacer que la Tarea de script devuelva un **mapa** (una estructura clave-valor). Cada clave se fusiona en las variables del proceso de forma individual. Por ejemplo, si la expresión de la Tarea de script es:
```cel
{"level": vars.value > 80 ? "critical" : "normal", "needs_action": vars.value > 80}
```
Entonces los nodos posteriores pueden referenciar `vars.level` (una cadena) y `vars.needs_action` (un booleano) de forma independiente.
También puedes usar la **Salidas** sección de la tarea para publicar valores con nombre adicionales después de que se ejecute el script. En la práctica, los mapas y las salidas explícitas son el patrón más fácil de revisar, restaurar y depurar después.
### Ejemplo
Un equipo de operaciones que supervisa sensores de vibración clasifica las lecturas antes de enroutarlas a través de una puerta de enlace:
```cel
{"severity": vars.value > 90 ? "critical" : vars.value > 70 ? "warning" : "normal"}
```
El nodo de Puerta exclusiva posterior entonces comprueba `vars.severity == "critical"` en una rama y `vars.severity == "warning"` en otra, con una rama predeterminada para lecturas «normales» que se dirige a un Evento final.
***
## Puerta exclusiva
La Puerta exclusiva es un punto de decisión. Evalúa las condiciones en sus flujos de salida y enruta la ejecución a exactamente **una** rama: la primera cuya condición sea verdadera. Esto es enrutamiento XOR: se toma una y solo una ruta.
### Apariencia visual
Una forma de rombo.
### Cuándo usarlo
* Dirigir a distintas acciones según un umbral (por encima vs. por debajo)
* Ramificar según una clasificación de severidad (crítica, advertencia, normal)
* Comprobar si los datos enriquecidos cambian la decisión
* Proporcionar una ruta de respaldo predeterminada cuando ninguna condición específica coincide
### Panel de propiedades
Haz clic en la Puerta exclusiva en el lienzo para abrir su panel de propiedades. En la parte superior, aparece un aviso: *"Las condiciones se evalúan secuencialmente (de arriba hacia abajo). La primera condición que se cumple ejecuta su flujo, y se omiten todas las condiciones restantes."*
**Nombre** — Un campo de texto para la etiqueta del nodo. Marcador de posición: *p. ej., MSG Smoke*.
**Flujos** — Una lista de todas las conexiones salientes de esta puerta de enlace. Cada elemento de flujo muestra:
| Elemento | Descripción |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Asa de arrastre** | Reordena los flujos arrastrando. El orden determina la prioridad de evaluación: gana la primera condición que coincida. |
| **Número de flujo** | "Flujo 1", "Flujo 2", etc. Si este flujo es el predeterminado, aparece una etiqueta «Flujo predeterminado». |
| **Nombre del sistema** | Un campo de texto para el identificador interno del flujo. |
| **Etiqueta** | Un campo de texto para la etiqueta visible en la flecha del lienzo. Oculto para el flujo predeterminado. |
| **Color** | Un selector de color para distinguir visualmente las ramas en el lienzo. Oculto para el flujo predeterminado. |
| **Condición (expresión)** | Una expresión CEL que debe evaluar a `verdadero` para que esta ruta se ejecute. Marcador de posición: *p. ej., vars.value > 10*. Oculto para el flujo predeterminado. |
| **Establecer como predeterminado** | Un botón que designa este flujo como la ruta de respaldo. Información sobre herramientas: *"Elige una de las condiciones para que actúe como ruta de respaldo cuando todas las demás condiciones sean falsas."* |
| **Eliminar** | Elimina el flujo. Un diálogo de confirmación advierte: *"Esto también eliminará la conexión correspondiente en el lienzo."* |
Cuando cambias qué flujo es el predeterminado, aparece una advertencia: *"Al cambiar el flujo predeterminado, el campo Condición se eliminará permanentemente del flujo establecido como predeterminado."* El flujo que antes era predeterminado recupera su campo Condición.
Si la puerta de enlace aún no tiene conexiones salientes, la sección Flujos muestra un estado vacío: *"Dibuja conexiones desde esta puerta de enlace en el lienzo para añadir flujos."* Primero debes dibujar conexiones en el lienzo: los flujos no pueden añadirse solo desde el panel de propiedades.
**Entradas** — Opcional. Misma estructura que la sección Entradas del Evento de inicio (nombre, tipo, expresión CEL, + Añadir entrada).
**Salidas** — Opcional. Misma estructura que la sección Salidas del Evento de inicio (nombre, tipo, expresión CEL, + Añadir salida).
**Guardar / Cancelar** — En la parte inferior del panel.
### ¿Necesito los parámetros de entrada y salida?
No. Ambos son opcionales, y una puerta de enlace que simplemente comprueba si un valor está por encima de un umbral no necesita ninguno: déjalos vacíos y escribe `vars.value > 70` directamente en la condición del flujo.
Úsalos cuando una condición de otro modo sería larga, o cuando repites el mismo cálculo en varios flujos.
**Una entrada** calcula un valor antes de que la puerta de enlace decida y le da un nombre corto que las propias condiciones de flujo de la puerta de enlace pueden usar. Para convertir una lectura en Celsius una vez y compararla dos veces, añade una entrada:
| Campo | Valor |
| -------------------- | ----------------------------- |
| Nombre de la entrada | `tempF` |
| Expresión | `vars.temperature * 1.8 + 32` |
Luego escribe las condiciones del flujo como `vars.tempF > 158` y `vars.tempF > 104` en lugar de repetir la conversión en cada una.
Una entrada pertenece a la puerta de enlace en la que la definiste. Los nodos posteriores no pueden leerla.
**Una salida** funciona al revés. Se evalúa después de que se elige la rama y escribe su resultado en las variables de la regla, de modo que los nodos más adelante pueden usarlo: un mensaje de alarma puede hacer referencia a `vars.tempF` aunque la conversión ocurrió en la puerta de enlace.
Lo mismo ocurre dondequiera que aparezcan Entradas y Salidas: una entrada es un auxiliar para el nodo que estás configurando, una salida es cómo ese nodo pasa algo adelante.
### Cómo funciona la evaluación de condiciones
Las condiciones se evalúan **de arriba hacia abajo** según el orden de la lista de Flujos. La primera condición que devuelve `verdadero` es la ruta que se toma. Se omiten todas las condiciones restantes, independientemente de si también serían verdaderas.
El flujo predeterminado no tiene expresión de condición. Solo se ejecuta cuando **todas las demás condiciones se evalúan como falsas**. Toda Puerta exclusiva debería tener un flujo predeterminado: sin uno, si ninguna condición coincide, la ejecución de la regla se detiene en esa rama.
El flujo predeterminado cubre el caso en que nada coincide. No cubre una condición que no logra evaluarse: si una expresión no puede evaluarse —normalmente porque referencia una variable que la regla no tiene, o devuelve algo distinto de `verdadero`/`falso` — la puerta de enlace se detiene allí y la regla no avanza más por esa ruta. En una sesión de depuración la puerta de enlace se resalta en rojo; consulta [Depurar reglas](/kilo-docs-es/kilo-iot-server/rules-engine/debugging-rules.md#what-the-markers-on-the-canvas-mean).
Una puerta de enlace también tiene que ramificar o fusionar: dale dos o más flujos salientes para tomar una decisión, o dos o más flujos entrantes para volver a unir caminos. Una puerta de enlace con un flujo de entrada y un flujo de salida se rechaza cuando construyes la regla: conecta esos dos nodos directamente en su lugar.
### Ejemplo
Una regla de humedad de almacén usa una Puerta exclusiva con tres flujos:
| Flujo | Condición | Lleva a |
| ------------------------ | ----------------- | ----------------------------------------------------- |
| Flujo 1 — Crítico | `vars.value > 85` | Configurar alarma (Incumplimiento crítico de humedad) |
| Flujo 2 — Advertencia | `vars.value > 70` | Configurar alarma (Advertencia de humedad) |
| Flujo 3 — Predeterminado | *(ninguna)* | Evento final (sin acción) |
Como las condiciones se evalúan de arriba hacia abajo, una lectura del 90 % coincide con el Flujo 1 y omite el Flujo 2. Una lectura del 75 % no cumple el Flujo 1, coincide con el Flujo 2. Una lectura del 60 % falla en ambos y pasa al predeterminado.
***
## Configurar alarma
El nodo Configurar alarma activa una alarma basada en una Definición de alarma preconfigurada. Cuando la ejecución llega a este nodo, crea un evento de alarma que inicia la política de escalamiento, envía notificaciones a través de los canales configurados y aparece en la bandeja de entrada de alarmas.
### Apariencia visual
Un rectángulo redondeado con un icono de campana en la esquina superior izquierda.
### Cuándo usarlo
* Activar una alerta crítica cuando una lectura de sensor cruza un umbral peligroso
* Generar una alarma de advertencia que notifique al equipo de operaciones por correo electrónico y SMS
* Generar alarmas con mensajes dinámicos que incluyan los valores reales del sensor
### Requisitos previos
Antes de poder usar un nodo Configurar alarma, debes tener al menos una **Definición de alarma** configurada en la sección Alertas. Las Definiciones de alarma especifican el nivel de severidad, los pasos de escalamiento, los canales de notificación y las políticas de destinatarios. El nodo Configurar alarma hace referencia a una definición existente: no crea una.
Ver [Alertamiento operacional](/kilo-docs-es/kilo-iot-server/alarm.md) sobre cómo crear y gestionar Definiciones de alarma.
### Panel de propiedades
El encabezado del panel dice **«Configurar alarma»** con el subtítulo: *«Selecciona una alarma. Se puede crear una nueva alarma en la página de Alarmas.»* La expresión «página de Alarmas» enlaza con la [sección de Alertas y notificaciones](/kilo-docs-es/kilo-iot-server/alarm.md) sección.
| Campo | Descripción |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Nombre** | Un campo de texto para la etiqueta del nodo. Ejemplo: «Activar alarma crítica». |
| **Elegir alarma** | Un desplegable de autocompletado con búsqueda. Enumera las Definiciones de alarma existentes en tu organización. Busca por nombre de alarma para encontrar la definición que necesitas. |
| **Mensaje de motivación** | Un campo de expresión CEL de varias líneas (3 filas). Marcador de posición: `"La temperatura es " + string(vars.temp) + " grados"`. La expresión debe evaluarse como una cadena: este texto se adjunta al evento de alarma y da a los respondientes contexto sobre qué activó la alarma y por qué. |
**Entradas** — Una lista de parámetros de entrada. Cada entrada tiene un nombre, un indicador de tipo (bloqueado en «Expression») y un campo de expresión CEL. Añade entradas con **+ Añadir entrada**. Elimina con el botón de eliminar.
**Salidas** — Misma estructura que Entradas, con su propio **+ Añadir salida** botón.
**Guardar / Cancelar** — En la parte inferior del panel.
### Ejemplos de mensajes de motivación
El mensaje de motivación es una expresión CEL, así que puedes incrustar valores en vivo del sensor y variables calculadas:
```cel
"La temperatura de " + string(vars.value) + " grados supera el umbral de seguridad"
```
```cel
"Lectura de humedad de " + string(vars.value) + "% en la Zona A — por encima del nivel " + string(vars.severity)
```
```cel
"Concentración de CO2 de " + string(vars.value) + " ppm, superando el límite por " + string(vars.value - 800) + " ppm"
```
### Qué ocurre cuando se ejecuta el nodo
1. Se crea un evento de alarma con la severidad y la configuración de la Definición de alarma seleccionada
2. La expresión del mensaje de motivación se evalúa y se adjunta al evento
3. Comienza la política de escalamiento de la alarma: se envían notificaciones a través de los canales y a los destinatarios definidos en la Definición de alarma
4. El evento de alarma aparece en la bandeja de entrada de alarmas para su seguimiento y resolución
El nodo Configurar alarma no **no** define por sí mismo la severidad, los canales, los horarios ni el escalamiento. Eso proviene de la Definición de alarma seleccionada. La regla decide **cuándo** activar; la Definición de alarma decide **cómo** se gestiona esa alarma.
### Ejemplo
Una regla de monitoreo ambiental de una sala de servidores llega al nodo Configurar alarma cuando la temperatura supera los 35 grados Celsius. El nodo está configurado con una Definición de alarma llamada «Sobrecalentamiento de sala de servidores» (severidad: Crítica, escalamiento: SMS al ingeniero de guardia inmediatamente, correo electrónico al gerente de instalaciones después de 5 minutos). El mensaje de motivación dice:
```cel
"La temperatura de la sala de servidores es " + string(vars.value) + " grados — se requiere atención inmediata"
```
***
## Ejecutar comando
El nodo Ejecutar comando envía un comando a un dispositivo cuando la regla llega a él: la acción que permite a una regla controlar hardware, no solo alertar sobre él. Envía uno de los [Comandos de dispositivo](/kilo-docs-es/kilo-iot-server/devices/commands.md) comandos predefinidos de un dispositivo como enlace descendente, de modo que una regla pueda cerrar una válvula, enviar un punto de ajuste o conmutar un relé automáticamente en el momento en que se cumplan sus condiciones.
Para el flujo de trabajo completo, ejemplos y el patrón actuar-y-alertar, consulta [Ejecución de comandos de dispositivo](/kilo-docs-es/kilo-iot-server/rules-engine/running-device-commands.md). Esta entrada cubre los campos del nodo.
### Apariencia visual
Un rectángulo redondeado con un icono de comando en la esquina superior izquierda. Se encuentra en el mismo grupo de actividad que Configurar alarma y Enriquecimiento.
### Cuándo usarlo
* Cerrar una válvula, conmutar un relé o detener una bomba en el instante en que se cruza un umbral
* Enviar un nuevo punto de ajuste a un controlador en respuesta a una lectura
* Establecer un valor de forma proporcional — p. ej., la velocidad del ventilador derivada de la temperatura medida
### Requisitos previos
El dispositivo de destino debe ser **controlable** (MQTT, o un dispositivo LoRaWAN de Clase C) y debe ya tener **al menos un comando definido** en su **Comandos y estados** pestaña. El nodo ejecuta comandos existentes; no los crea. Consulta [Creación de comandos](/kilo-docs-es/kilo-iot-server/devices/commands/creating-commands.md).
### Panel de propiedades
| Campo | Descripción |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Nombre** | Un campo de texto para la etiqueta del nodo. Si se deja en blanco, se rellena con el nombre del comando seleccionado. Ejemplo: «Cerrar válvula de entrada». |
| **Dispositivo** | Una lista desplegable de autocompletado con búsqueda que enumera los dispositivos de tu organización. Selecciona el dispositivo al que se envía el comando. |
| **Comando** | Una lista desplegable de autocompletado de los comandos definidos del dispositivo elegido. Deshabilitada hasta que se seleccione un dispositivo. |
| **Parámetros** | Una fila por cada parámetro que espera el comando seleccionado. Cada parámetro se proporciona como un literal **Valor** (validado frente al tipo y rango del parámetro) o una **Expresión CEL** (evaluada en tiempo de ejecución, con `vars` disponible). |
| **Entradas / Salidas** | Expresiones CEL opcionales con nombre para modelado avanzado de datos, siguiendo el mismo patrón que otros nodos. |
**Guardar / Cancelar** — En la parte inferior del panel. Guardar está deshabilitado hasta que se seleccionen un dispositivo y un comando, y todos los parámetros sean válidos.
### Qué ocurre cuando se ejecuta el nodo
1. Cada parámetro se resuelve — los literales tal cual, las expresiones evaluadas contra el actual `vars`.
2. El comando se envía al dispositivo como un downlink (MQTT o LoRaWAN), exactamente como lo sería una ejecución manual.
3. El envío se registra en el historial de ejecución del dispositivo con su resultado (Pendiente, Confirmado, Entregado, Advertencia leve o Fallido). Cualquier verificación configurada en el comando también se aplica aquí.
Empareja un nodo Ejecutar comando con un [Evento de error de borde](#boundary-error-event) cuando un envío fallido deba llegar igualmente a una persona mediante una ruta alternativa.
### Ejemplo
Una regla de detección de fugas enlaza su Evento de inicio a un sensor de fugas. Una compuerta exclusiva enruta una lectura de "fuga detectada" a un nodo Ejecutar comando que envía un `cerrar` comando a la válvula de cierre de agua, seguido de un nodo Establecer alarma que genera una alarma Crítica. El agua se detiene automáticamente y al equipo se le notifica que ocurrió.
***
## Enriquecimiento
El nodo Enriquecimiento obtiene la lectura más reciente de otro sensor. Esto te permite tomar decisiones basadas en datos de varios sensores dentro de una sola regla, sin necesidad de crear reglas separadas para cada uno.
### Apariencia visual
Un rectángulo redondeado con un icono de descarga en la esquina superior izquierda.
### Cuándo usarlo
* Compara una lectura de temperatura interior con la temperatura exterior actual
* Comprueba un sensor de humedad antes de decidir si un pico de temperatura es preocupante
* Correlaciona una lectura de CO2 con un sensor de ocupación para determinar si se esperan niveles elevados
* Verifica un sensor de referencia antes de disparar una alarma
### Panel de propiedades
El encabezado del panel dice **"Enriquecimiento de datos"** con el subtítulo: *"Adjunta metadatos relevantes a los datos entrantes del dispositivo antes de procesarlos."*
| Campo | Descripción |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Nombre** | Un campo de texto para la etiqueta del nodo. Marcador de posición: *p. ej., Adjuntar temperatura de la habitación a los datos del sensor*. |
| **Dispositivo** | Lista desplegable de autocompletado con búsqueda. Enumera todos los dispositivos de tu organización — el mismo patrón de selector que el Evento de inicio. |
| **Sensor** | Lista desplegable filtrada. Deshabilitada hasta que se seleccione un dispositivo. Muestra solo los sensores que pertenecen al dispositivo elegido. |
| **Variable de salida** | Un campo de texto para el nombre de la variable bajo la cual se almacena el dato obtenido. Marcador de posición: *Metadatos del usuario*. Tras ejecutarse el nodo, el resultado está disponible como `vars.`. |
**Entradas** — Una lista de parámetros de entrada. Cada entrada tiene un nombre, un indicador de tipo (bloqueado en «Expression») y un campo de expresión CEL. Añade entradas con **+ Añadir entrada**. Elimina con el botón de eliminar.
**Salidas** — Misma estructura que Entradas, con su propio **+ Añadir salida** botón.
**Guardar / Cancelar** — En la parte inferior del panel.
### Cómo se estructuran los datos enriquecidos
Tras ejecutarse el nodo de Enriquecimiento, la lectura obtenida está disponible como `vars.` con la siguiente estructura:
| Propiedad | Contenido |
| ----------------------------------- | --------------------------------------------- |
| `vars..sensor_id` | El identificador del sensor |
| `vars..value` | El valor de la lectura más reciente |
| `vars..type` | El tipo de dato del sensor |
| `vars..timestamp_ms` | Marca de tiempo de la lectura en milisegundos |
Por ejemplo, si el nombre de la variable es `outdoor_temp`, los nodos posteriores pueden hacer referencia a `vars.outdoor_temp.value` para obtener la lectura más reciente de la temperatura exterior.
### Manejo de errores
El nodo de Enriquecimiento puede fallar si el sensor de destino está sin conexión, nunca ha informado o no es accesible. Empareja siempre un nodo de Enriquecimiento con un **Evento de error de borde** (véase abajo) para manejar estos fallos con elegancia. Sin manejo de errores, un enriquecimiento fallido detiene esa ruta de ejecución.
### Ejemplo
Una regla de monitorización de un centro de datos compara la temperatura ambiente dentro de una sala de servidores con el sensor de temperatura exterior del edificio. El nodo de Enriquecimiento obtiene del sensor exterior en una variable llamada `external_temp`. Un Script Task posterior calcula el diferencial:
```cel
{"temp_delta": vars.value - vars.external_temp.value}
```
Entonces una Compuerta Exclusiva comprueba si `vars.temp_delta > 15` — un gran diferencial podría indicar un fallo de HVAC, ya que la temperatura interna está subiendo independientemente de las condiciones exteriores.
***
## Evento de error de borde
El Evento de error de borde es un manejador de errores que se adjunta a un nodo de tarea. Si la tarea a la que está adjunto falla durante la ejecución, el Evento de error de borde captura el fallo y enruta la ejecución a una ruta alternativa en lugar de terminar la regla.
### Apariencia visual
Un pequeño círculo con un icono de rayo, situado en el borde del nodo de tarea al que está adjunto. Se sitúa en el borde del nodo principal en lugar de como un elemento independiente en el lienzo.
### Cuándo usarlo
* Un nodo de Enriquecimiento obtiene datos de un sensor que podría estar sin conexión
* Un Script Task evalúa una expresión que depende de datos opcionales
* Un nodo Establecer alarma hace referencia a una Definición de alarma que podría haber sido desactivada
* Cualquier tarea en la que el fallo deba desencadenar una respuesta específica en lugar de silencio
### Cómo adjuntarlo
Arrastra un Evento de error de borde desde la paleta y suéltalo sobre un nodo de tarea existente (Script Task, Establecer alarma, o Enriquecimiento). Encaja en el borde de ese nodo. Luego dibuja una única conexión saliente desde el Evento de error de borde hacia la ruta alternativa — normalmente otro Establecer alarma, un Script Task que registre el contexto del fallo, o un Evento de fin.
### Reglas
* Un Evento de error de borde debe estar adjunto a un nodo de tarea. No puede existir como nodo independiente en el lienzo.
* Debe tener exactamente **una** flujo saliente.
* No puede tener flujos entrantes (además de su adjunción implícita a la tarea principal).
### Panel de propiedades
| Campo | Descripción |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Nombre** | Un campo de texto para la etiqueta del nodo. Valor predeterminado: "Error". Ejemplo: "Fallback por sensor sin conexión". |
| **Código de error** | Un campo de texto. Marcador de posición: *Especifica aquí el código de error*. Se usa para etiquetado y anotación en el editor — consulta la salvedad a continuación. |
| **Mensaje** | Un campo de texto multilínea (3 filas). Marcador de posición: *Escribe aquí el mensaje de error*. Se usa para etiquetado y anotación en el editor — consulta la salvedad a continuación. |
**Entradas / Salidas** — El panel de propiedades puede mostrar campos de Entrada y Salida en el Evento de error de borde. Sin embargo, el motor de automatización no procesa Entradas ni Salidas en este tipo de nodo. Si necesitas transformar datos o publicar valores en la ruta de error, añade Entradas y Salidas al **nodo posterior** al que la salida del evento de borde se conecta — por ejemplo, el Script Task alternativo, Establecer alarma o Evento de fin.
**Guardar / Cancelar** — En la parte inferior del panel.
**Salvedad importante:** Los campos Código de error y Mensaje son campos de etiquetado y anotación dentro del editor. No habilitan una coincidencia selectiva en tiempo de ejecución por código de error. El motor enruta **todos** los errores de la tarea adjunta a través del evento de borde independientemente del código introducido. El comportamiento principal admitido es la propia ruta alternativa: cuando la tarea adjunta falla por cualquier motivo, la ruta de error se ejecuta en lugar de detener esa rama silenciosamente.
### Ejemplo
Una regla de cumplimiento multisensor enriquece las lecturas interiores con un sensor de referencia exterior. El nodo de Enriquecimiento para el sensor exterior tiene adjunto un Evento de error de borde. Si el sensor exterior no está accesible:
1. El Evento de error de borde captura el fallo
2. Su flujo saliente conduce a un nodo Establecer alarma configurado con una definición de alarma "Sensor sin conexión"
3. El equipo de operaciones recibe una notificación de que el sensor de referencia exterior no está informando, por lo que saben que no se pudo realizar la comparación de cumplimiento
Sin el Evento de error de borde, el fallo del enriquecimiento detendría silenciosamente esa ruta de ejecución — y el equipo no sabría que el sensor estaba sin conexión.
***
## Conexiones (Flujos de secuencia)
Las conexiones son las flechas entre los nodos en el lienzo. Definen el orden de ejecución — los datos fluyen a lo largo de estas flechas de un nodo al siguiente.
### Dibujar conexiones
Usa la **Herramienta global de conexión** de la paleta, o pasa el cursor sobre un nodo de origen hasta que aparezcan los conectores de conexión y arrastra desde el origen hasta el nodo destino.
### Reglas de conexión
| Regla | Detalles |
| -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| **Eventos de inicio** | Un flujo saliente. Ningún flujo entrante. |
| **Eventos de fin** | Ningún flujo saliente. Uno o más flujos entrantes. |
| **Nodos de tarea** (Script Task, Establecer alarma, Ejecutar comando, Enriquecimiento) | Un flujo saliente. Un flujo entrante (o adjunción de Evento de error de borde). |
| **Compuertas exclusivas** | Un flujo entrante. Múltiples flujos salientes (uno por rama). |
| **Eventos de error de borde** | Exactamente un flujo saliente. Ningún flujo entrante (adjunto implícitamente al principal). |
### Condiciones en los flujos de la compuerta
Cada flujo saliente de una Compuerta Exclusiva — excepto el flujo predeterminado designado — debe tener una expresión de condición CEL. Estas condiciones deben evaluarse como booleano (`verdadero` o `falso`).
El flujo predeterminado debe **no** tener una condición. Se ejecuta solo cuando todas las demás condiciones se evalúan como falsas.
Si creas un flujo desde una compuerta sin establecer una condición, el paso de compilación lo marcará como error y la regla no se compilará correctamente.
### Etiquetas y colores de los flujos
Los flujos de las Compuertas Exclusivas pueden tener etiquetas y colores (configurados en el panel de propiedades de la compuerta). Úsalos para que los diagramas complejos se entiendan de un vistazo — por ejemplo, etiqueta una rama "Crítica" en rojo y otra "Advertencia" en ámbar, con la rama predeterminada "Normal" en verde.
---
# 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/node-reference.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.
