> 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/debugging-rules.md).

# Depuración de reglas

Depura una regla de automatización de Kilo IoT antes de desplegarla — nodos de paso, variables de observación, comprueba expresiones frente al contexto de prueba.

Una regla que parece correcta en el lienzo puede seguir comportándose de formas que no esperabas: una compuerta envía el flujo por la rama equivocada, una expresión se evalúa sobre una forma de datos que no anticipaste, una variable contiene algo distinto de lo que asumiste. El modo de depuración te permite descubrirlo *antes* de que la regla se implemente en producción, ejecutando la regla paso a paso e inspeccionando exactamente lo que sucede en cada nodo.

El modo de depuración es un depurador interactivo integrado en el editor visual. Le suministras a la regla una carga útil de prueba y luego recorres su ejecución un nodo a la vez, deteniéndote donde quieras, observando cómo cambian las variables, comprobando expresiones y decidiendo cómo se maneja cada efecto secundario. Es la diferencia entre desplegar una regla y *esperar*, y desplegar una regla que realmente has visto ejecutarse.

## Iniciar una sesión de depuración

1. Abre la regla en el [editor visual](/kilo-docs-es/kilo-iot-server/rules-engine/visual-editor.md).
2. En la barra superior del editor de reglas, haz clic en **Establecer contexto** para abrir el panel **Iniciar sesión de depuración** . (La barra superior también incluye un **Iniciar depuración** botón, atajo **F12**.)
3. El panel te pide **proporcionar variables de contexto iniciales** — la entrada con la que se ejecutará la regla. Se abre con una fila ya añadida, llamada `valor`, y cada fila es una **Nombre** y un **Valor**:
   * **Nombre** es el nombre de la variable que espera tu regla (por ejemplo `valor`, `temperature`, `status`).
   * **Valor** es la lectura de prueba. Puede ser un número, `verdadero` / `falso`, `null`, texto o JSON; el panel lo interpreta por ti.
4. Haz clic **Añadir métrica** para añadir más variables de contexto; elimina cualquier fila adicional que no necesites.
5. Haz clic **Cargar e iniciar**. La regla se carga y se pausa, lista para el primer paso.

El contexto inicial representa lo que enviaría un dispositivo en producción. Establécelo con los valores que quieras probar: el caso límite, el umbral, la lectura que sospechas que está causando problemas.

<figure><img src="https://3373664356-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-da92f454dade56fdc0971a0f07c682e1794c2ab5%2Frules-debug-start-panel.jpg?alt=media" alt="The Start Debug Session panel with a named context variable and the Load and Start button"><figcaption></figcaption></figure>

### Nombra cada variable exactamente como tu regla se refiere a ella

Las reglas leen el contexto a través de `vars`, así que nombra cada fila para que coincida con las expresiones de tu regla. Una condición de compuerta escrita como `vars.RH > 70` necesita una fila llamada **`RH`** — `humedad` o `valor` no servirá. Si una condición hace referencia a un nombre que el contexto no contiene, la regla se detiene en ese elemento cuando llega a él.

Copia los nombres de tus condiciones de compuerta en lugar de escribirlos de memoria y comprueba la ortografía antes de empezar.

Dos filas que no necesitas añadir:

* El panel se abre con una fila llamada `valor`valor **Lectura del sensor**. Una regla de producción iniciada por **Condición de activación** no recibe `vars.value`, así que elimina o renombra este valor de prueba para que coincida con el contexto de activación.
* El depurador proporciona `sensor_id` automáticamente. En producción, proviene del sensor seleccionado o de la señal de activación, según el origen de inicio.

## La sesión comienza en pausa

Cargar una sesión no ejecuta la regla. Abre el diagrama, coloca la ejecución en el evento de inicio y te espera — **nada se ejecuta hasta que presionas Ejecutar o uno de los controles de paso**.

Cuando se carga la sesión verás que el lienzo se vuelve de solo lectura, que la barra de depuración aparece en la parte inferior del editor, que el panel de depuración se abre a la derecha con tus variables iniciales y que aparece un contorno azul en el evento de inicio. El contorno azul indica que la sesión está activa y esperando.

<figure><img src="https://3373664356-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-b5e794aa7536c00977b3695c155702528458fd3f%2Frules-debug-session-paused.jpg?alt=media" alt="A loaded debug session paused on the Start Event, with the debug toolbar and the Variables tab"><figcaption></figcaption></figure>

Si el diagrama parece quedarse quieto, pulsa **Ejecutar (F10)** para continuar hasta el primer punto de interrupción o hasta el final, o **Paso sobre (F9)** para avanzar un elemento a la vez.

## Los controles de depuración

Una vez que se carga una sesión, una barra de herramientas de depuración flota sobre la parte inferior del lienzo con cinco controles. No está en la barra de encabezado junto a Guardar y Compilar: mira la parte inferior del diagrama.

* **Ejecutar (F10)** — ejecuta la regla hasta que llegue a un punto de interrupción o termine.
* **Paso sobre (F9)** — ejecuta el siguiente nodo y se detiene, mostrando su resultado.
* **Paso dentro (F8)** — entra en el siguiente nodo e inspecciona sus internas — sus entradas, scripts y salidas — en lugar de solo su resultado.
* **Ejecutar ignorando puntos de interrupción (F11)** — ejecuta hasta el final sin pausar. Desactiva todos los puntos de interrupción y los deja desactivados durante el resto de la sesión; vuélvelos a activar desde la pestaña Puntos de interrupción cuando los necesites de nuevo.
* **Detener (F12)** — finaliza la sesión de depuración.

**F12 funciona en ambos extremos de una sesión:** púlsalo mientras editas para iniciar la depuración, y de nuevo mientras depuras para detenerla.

Los controles de paso están disponibles mientras la sesión está en pausa. Se muestran atenuados mientras la regla se está ejecutando, mientras un diálogo de efecto secundario está esperando una respuesta y después de que una regla no se haya podido cargar. Detener sigue disponible en todo momento.

## Qué significan los marcadores en el lienzo

Los elementos pueden llevar tres marcas distintas durante una sesión:

| Marcador                                   | Significado                                                                                             |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------- |
| **Contorno azul**                          | Dónde está ahora la ejecución. El siguiente paso se ejecuta aquí.                                       |
| **Pequeño punto rojo** encima del elemento | Un punto de interrupción. Un punto relleno está habilitado; un anillo hueco es uno que has desactivado. |
| **Contorno rojo**                          | El elemento que generó el error más reciente. Se borra en el siguiente paso exitoso.                    |

Un contorno rojo no es ni un punto de interrupción ni la posición actual — marca el elemento que falló, y la expresión de ese elemento es donde debes mirar. Consulta [Cuando falla un nodo](#when-a-node-fails).

<figure><img src="https://3373664356-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-79f2075e33388687f438a37c053d9e2cb05baa38%2Frules-debug-error-marker.jpg?alt=media" alt="A rule paused with a blue outline on the Start Event and a red outline on the element that raised an error"><figcaption></figcaption></figure>

## Puntos de interrupción

Un punto de interrupción pausa la ejecución en un nodo específico, para que puedas inspeccionar el estado exactamente en el punto que te interesa.

* **Establecer un punto de interrupción** — haz clic en un nodo del lienzo para alternar un punto de interrupción en él. Abre la **Puntos de interrupción** pestaña en el panel de depuración para verlos todos; el encabezado de la pestaña muestra un conteo. Durante una sesión, cada clic en el lienzo añade o quita un punto de interrupción, así que vuelve a hacer clic en un elemento para quitar uno que no querías.
* **Habilitar o deshabilitar** — cada punto de interrupción tiene un indicador rojo. Haz clic en él para desactivar el punto de interrupción sin eliminarlo, y volver a activarlo más tarde.
* **Puntos de interrupción condicionales** — crea primero un punto de interrupción normal, luego haz clic en **Establecer condición** en él e introduce una expresión CEL. Entonces el punto de interrupción pausa la ejecución *solo* cuando esa expresión es verdadera — por ejemplo, solo cuando `vars.value > 30`. Un punto de interrupción condicional se marca con una insignia **Condicional** . Consulta [Referencia CEL](/kilo-docs-es/kilo-iot-server/rules-engine/cel-reference.md) para la sintaxis de expresiones.

Los puntos de interrupción condicionales son la forma de depurar un problema intermitente: deja que la regla se ejecute normalmente y deténla solo en la lectura que desencadena el comportamiento incorrecto.

## Inspección de variables

La **Variable** pestaña del panel de depuración muestra el estado de la regla en el paso actual, en dos secciones:

* **Cambios** — las variables que se añadieron o cambiaron desde el paso anterior, resaltadas para que puedas ver de un vistazo lo que realmente hizo el nodo que acabas de ejecutar. Las variables eliminadas se muestran tachadas.
* **Todas las variables** — el conjunto completo actual de variables con sus valores.

Mientras está en pausa, también puedes **editar** el estado directamente: cambiar el valor de una variable, añadir una nueva o eliminar una. Esto te permite llevar la regla por una rama que quieres probar sin tener que reiniciar la sesión con otra entrada.

Cuando usas **Paso dentro** en un nodo, la pestaña Variable también muestra una tarjeta de detalle del elemento con los **Entradas**, **Scripts**, y **Salidas** — el funcionamiento interno del paso, no solo su resultado final.

## Expresiones de vigilancia y Evaluar

La **Vigilancia** pestaña mantiene un ojo en las expresiones mientras se ejecuta la regla:

* **Añadir vigilancia** — introduce una expresión CEL y se vuelve a evaluar automáticamente en cada paso, para que puedas seguir un valor derivado (por ejemplo, `vars.value - vars.threshold`) sin buscar en la lista de variables.
* **Evaluar** — introduce una expresión CEL puntual y evalúala inmediatamente contra el estado actual. Útil para comprobar una parte de la lógica — «¿qué devolvería ahora mismo esta condición de compuerta?» — sin añadirla a la regla.

Ambas usan el mismo [CEL](/kilo-docs-es/kilo-iot-server/rules-engine/cel-reference.md) que escribes en otras partes de la regla, y ambas leen el estado de la regla a través de `vars` — una vigilancia sobre una variable llamada `RH` se escribe `vars.RH`. Una expresión que no compila se rechaza en cuanto la añades, así que usa la pestaña Vigilancia para probar una condición antes de pegarla en una compuerta.

## Efectos secundarios

Algunos nodos hacen más que transformar datos: envían notificaciones, generan alarmas o llaman a otros sistemas. Cuando la ejecución de depuración llega a un nodo con un efecto secundario, aparece un diálogo de **Efecto secundario** y te pregunta cómo manejarlo. Tres opciones:

<figure><img src="https://3373664356-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtNQh1wBSHSaknslMdOXm%2Fuploads%2Fgit-blob-23a76ec8501f4e1c77df4138bb3b2c78b0b406e6%2Frules-debug-side-effect.jpg?alt=media" alt="The Side Effect dialog offering Execute, Skip and Mock"><figcaption></figcaption></figure>

* **Ejecutar — ejecutar el controlador real.** El efecto secundario ocurre de verdad, exactamente igual que en una regla desplegada: se genera una alarma y se notifica a sus destinatarios, y se envía un comando al dispositivo físico.
* **Omitir — variables sin cambios.** El efecto secundario se omite y las variables de la regla quedan tal como están.
* **Simular — proporcionar una respuesta simulada.** Proporcionas una respuesta de sustitución en JSON y la regla continúa como si el controlador la hubiera devuelto. La respuesta debe ser JSON válido; si no lo es, la simulación simplemente no se aplica.

**Ejecutar está seleccionado cuando se abre el diálogo**, así que cambia la selección antes de hacer clic en Aplicar si no quieres que la acción ocurra de verdad. Esto es lo que te permite depurar una regla que envía alertas sin realmente llamar a un ingeniero de guardia: elige **Omitir** o **Simular** mientras pruebas la lógica, y **Ejecutar** solo cuando quieras verificar la entrega real.

Dos cosas que esperar una vez que hayas respondido:

* **Tu respuesta se reutiliza para ese nodo.** Si la ejecución vuelve a llegar al mismo nodo más adelante en la sesión, el diálogo no vuelve a aparecer y se aplica tu elección anterior. Elegir **Ejecutar** por lo tanto envía de verdad en cada paso posterior también. Inicia una nueva sesión para que te lo vuelvan a preguntar.
* **Cancelar devuelve la ejecución.** Cerrar el diálogo sin elegir devuelve justo antes del nodo y lo deja sin ejecutar. Vuelve a hacer un paso y el diálogo reaparece.

## Cuando falla un nodo

Si un nodo da error durante la ejecución, el nodo que falla se resalta en rojo en el lienzo, para que puedas ver exactamente qué nodo salió mal sin buscar en una regla grande. Un error **recuperable** mantiene la sesión de depuración en pausa y cargada — puedes inspeccionar las variables, ajustar el estado y continuar — mientras que un error **irrecuperable** finaliza la sesión.

La mayoría de los errores provienen de una expresión en el nodo que falla. Abre sus propiedades y comprueba tres cosas:

1. **Cada nombre que usa existe en la pestaña Variables.** `vars.RH > 70` falla si nada llamado `RH` se estableció como contexto inicial o fue producido por un nodo anterior. En una compuerta esto detiene la regla en la compuerta — no la envía por la rama predeterminada.
2. **La `vars.` el prefijo está ahí.** `RH > 70` no es lo mismo que `vars.RH > 70`.
3. **La expresión devuelve el tipo correcto.** Una condición de compuerta debe producir `verdadero` o `falso`.

Pega la expresión en **Evaluar** en la pestaña Vigilancia para probarla contra el estado actual.

## Ciclo de vida de la sesión

Una sesión de depuración dura **30 minutos**, medidos desde que comienza — recorrer la regla paso a paso no lo prolonga. Verás una advertencia poco antes de que caduque y una notificación si vence, se cierra (con el motivo) o pierde la conexión. Inicia una nueva sesión para seguir depurando.

Los puntos de interrupción están vinculados a los elementos del diagrama que cargaste, así que volver a cargar el editor puede eliminarlos. Una notificación te indica cuántos hay, para que puedas volver a añadirlos.

Si iniciar una sesión falla, la plataforma está ejecutando en ese momento su número máximo de sesiones de depuración. Inténtalo de nuevo dentro de poco.

## Consejos

* Depura los casos límite, no el camino feliz: establece el contexto inicial con el valor del umbral, el campo que falta, la lectura fuera de rango.
* Copia los nombres de las variables de tus condiciones de compuerta al rellenar el contexto inicial en lugar de escribirlos de memoria.
* Usa un punto de interrupción condicional para atrapar un problema intermitente: ejecuta la regla normalmente y deténla solo en la lectura que lo desencadena.
* Edita una variable a mitad de sesión para forzar que la regla tome una rama específica en lugar de reiniciar con una entrada nueva.
* Mantén los efectos secundarios activados **Omitir** o **Simular** mientras iteras sobre la lógica; cambia a **Ejecutar** solo para una comprobación intencionada de extremo a extremo.
* Una vez que una regla se depura sin problemas, compílala e impleméntala — consulta [Compilaciones e implementación](/kilo-docs-es/kilo-iot-server/rules-engine/builds-artifacts-and-deployment.md).

## Ver también

* [Editor visual](/kilo-docs-es/kilo-iot-server/rules-engine/visual-editor.md) — el modo de depuración del lienzo se ejecuta en
* [Referencia CEL](/kilo-docs-es/kilo-iot-server/rules-engine/cel-reference.md) — sintaxis de expresiones para puntos de interrupción condicionales y vigilancias
* [Compilaciones e implementación](/kilo-docs-es/kilo-iot-server/rules-engine/builds-artifacts-and-deployment.md) — publica una regla una vez que se depura sin problemas
* [Solución de problemas](/kilo-docs-es/kilo-iot-server/rules-engine/troubleshooting.md) — errores de compilación y problemas en tiempo de ejecució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/debugging-rules.md?ask=<question>&goal=<endgoal>
```

`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.
