> 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/running-device-commands.md).

# Ejecución de comandos en dispositivos

Haz que una regla de Kilo actúe por sí sola — el nodo Ejecutar comando envía un comando al dispositivo cuando se cumplen las condiciones.

Este es el cambio que convierte al Motor de reglas de un sistema que *observa* en un sistema que *actúa*. Hasta ahora, cuando una regla detectaba un problema, lo máximo que podía hacer era lanzar una alarma y poner a una persona en el circuito — alguien tenía que leer la alerta y accionar el interruptor. El **nodo Ejecutar comando** cierra esa brecha. Ahora una regla puede enviar un comando directamente a un dispositivo en el momento en que se cumplen sus condiciones, sin ninguna persona en medio.

Considera lo que eso significa en la práctica. Un sensor de fugas se activa en una sala de planta. Antes, la regla disparaba una alarma y un operario corría a cerrar la válvula principal — minutos de daños por agua en cualquier caso. Ahora la misma regla cierra la válvula por sí misma en la misma evaluación que detectó la fuga, y *luego* lanza la alarma para que el equipo sepa que ocurrió. El almacenamiento en frío se sale del rango, y la regla envía un punto de consigna más bajo al controlador antes de que el producto corra riesgo. Un tanque alcanza una marca de nivel alto, y la regla cierra la entrada. Esto es automatización de lazo cerrado: detectar, decidir y actuar de principio a fin, en una sola regla.

La acción se ejecuta en el mismo [Comandos del dispositivo](/kilo-docs-es/kilo-iot-server/devices/commands.md) motor que usas manualmente — la regla simplemente envía un comando que ya has definido en el dispositivo. Así que todo lo que hace seguros los comandos manuales (parámetros tipados, verificación opcional, un registro completo de ejecución) se aplica automáticamente cuando una regla lanza uno.

## Antes de empezar

El nodo Ejecutar comando envía uno de los **existentes** comandos del dispositivo. No define nuevos. Así que antes de que una regla pueda actuar sobre un dispositivo:

1. **El dispositivo debe ser controlable** — conectado por MQTT, o un dispositivo LoRaWAN de Clase C (los dispositivos de Clase C escuchan continuamente, así que pueden recibir un enlace descendente en cualquier momento).
2. **El dispositivo debe tener al menos un comando definido** — configúralo primero en la **pestaña Comandos y estados** del dispositivo. Consulta [Creación de comandos](/kilo-docs-es/kilo-iot-server/devices/commands/creating-commands.md).
3. **Tienes permiso para administrar la regla y los comandos del dispositivo** — ambos están regidos por la política de acceso de tu organización.

Si un dispositivo todavía no tiene comandos, no ofrecerá nada para ejecutar — define primero el comando y luego vuelve a la regla.

## Añadir un nodo Ejecutar comando

1. Abre la regla en el [Editor visual](/kilo-docs-es/kilo-iot-server/rules-engine/visual-editor.md) y cambia a **modo de edición** .
2. Arrastra **nodo Ejecutar comando** desde la paleta al lienzo. Está en el mismo grupo que Set Alarm y Enrichment — es una acción que la regla realiza cuando la ejecución llega a ella.
3. Conéctalo a tu flujo. Normalmente sigue una rama de Compuerta exclusiva — la regla evalúa una condición, y la rama que significa "actuar ahora" conduce al nodo Ejecutar comando.
4. Haz clic en el nodo para abrir su panel de propiedades y completa los campos de abajo.
5. Haz clic en **Guardar**, luego **Compilar** y despliega la regla como de costumbre. El comando solo se ejecuta una vez que la regla está compilada y en ejecución.

## Panel de propiedades

| Campo                  | Descripción                                                                                                                                                                                                                                                      |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Nombre**             | Una etiqueta para el nodo en el lienzo. Si lo dejas en blanco y eliges un comando, se completa con el nombre del comando. Ejemplo: "Cerrar válvula de entrada".                                                                                                  |
| **Dispositivo**        | Un menú desplegable con búsqueda de los dispositivos de tu organización. Elige el dispositivo al que se debe enviar el comando.                                                                                                                                  |
| **Comando**            | Un menú desplegable de los comandos definidos de ese dispositivo. Está deshabilitado hasta que se selecciona un dispositivo; después muestra todos los comandos disponibles en el dispositivo elegido.                                                           |
| **Parámetros**         | Aparece una vez elegido un comando, con una fila por cada parámetro que el comando espera (un nivel de brillo, un punto de consigna, un indicador de abrir/cerrar). Cada parámetro se proporciona como un literal **Valor** o una **Expresión CEL** — ver abajo. |
| **Entradas / Salidas** | Opcional. Expresiones CEL con nombre para modelado avanzado de datos, el mismo patrón usado en otros nodos. Usa Entradas para preparar valores auxiliares y Salidas para publicar resultados para nodos posteriores.                                             |

**Guardar / Cancelar** están al final del panel.

### Establecer parámetros del comando: Valor o Expresión

Cada parámetro que define el comando obtiene su propia fila, y para cada uno eliges cómo se suministra el valor:

* **Valor** — un literal fijo que escribes. Usa esto cuando la regla deba enviar siempre el mismo valor: un punto de consigna de `4`, un estado de `apagado`, un ciclo de trabajo de `100`. El campo se valida frente a la definición de parámetros del comando, así que un valor fuera de rango o de tipo incorrecto se marca antes de que puedas guardarlo.
* **Expresión** — una [CEL](/kilo-docs-es/kilo-iot-server/rules-engine/cel-reference.md) expresión evaluada cuando se ejecuta la regla. Esto es lo que hace que la acción sea *dinámica*: el contexto en vivo de la regla está disponible a través de `vars`, así que un parámetro del comando puede calcularse a partir de la misma lectura que activó la regla. Por ejemplo, establece la velocidad de un ventilador a partir de la temperatura medida, o pasa directamente el valor del sensor con `vars.value`.

La combinación es poderosa: una Compuerta exclusiva decide *si* actuar, y una expresión CEL en el nodo Ejecutar comando decide *qué valor enviar* — así, una sola regla puede tanto reaccionar a un umbral como responder proporcionalmente a cuánto lo supera la lectura.

## Qué sucede cuando se ejecuta el nodo

1. La regla llega al nodo Ejecutar comando a lo largo de su flujo.
2. Cada parámetro se resuelve — los literales tal cual, las expresiones evaluadas frente al contexto actual `vars`.
3. El comando se envía al dispositivo como un enlace descendente, por MQTT o LoRaWAN, exactamente como si se hubiera ejecutado manualmente desde la **pestaña Estados** .
4. El envío se registra en el historial de ejecución del dispositivo con su resultado (Pendiente, Confirmado, Entregado, Advertencia leve o Fallido), de modo que haya una auditoría completa de cada acción que una regla ha realizado.

Como el comando pasa por la ruta estándar de Comandos del dispositivo, cualquier verificación configurada en ese comando también se aplica aquí — la regla puede confirmar que el dispositivo realmente actuó, no solo que se envió el enlace descendente. Consulta [Confirmación de comandos](/kilo-docs-es/kilo-iot-server/devices/commands/verification.md).

## Actuar *y* alertar en una sola regla

Actuar sobre un dispositivo no reemplaza la alerta — ambas funcionan mejor juntas. Una sola regla puede cerrar la válvula **y** lanzar una alarma, de modo que la situación quede contenida automáticamente *y* se notifique a las personas adecuadas. Una forma común:

| Paso      | Nodo                                   | Qué hace                                                                                        |
| --------- | -------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Detectar  | Evento de inicio → Compuerta exclusiva | Vincularse al sensor de fugas; ramificar cuando se detecta una fuga                             |
| Actuar    | nodo Ejecutar comando                  | Enviar "cerrar válvula" a la válvula de cierre                                                  |
| Notificar | Establecer alarma                      | Lanzar una alarma de gravedad crítica para que el equipo sepa que la válvula se cerró y por qué |

Si la propia acción pudiera fallar — por ejemplo, si el dispositivo está brevemente desconectado — adjunta un [Evento de error de borde](/kilo-docs-es/kilo-iot-server/rules-engine/node-reference.md#boundary-error-event) al nodo Ejecutar comando y enruta la ruta de error a un Establecer alarma, para que un comando que no se complete todavía llegue a una persona.

## Un ejemplo práctico

Una regla de cadena de frío protege un congelador farmacéutico. El Evento de inicio se vincula a la sonda de temperatura del congelador. Una Compuerta exclusiva enruta cualquier lectura por encima de −15 °C por una rama de "deriva hacia cálido". En esa rama:

1. Un **nodo Ejecutar comando** nodo envía un `set_setpoint` comando al controlador del congelador, con el parámetro de punto de consigna establecido como una **Expresión** expresión CEL
2. Un **Establecer alarma** nodo lanza una alarma de severidad alta con un mensaje de motivación que incluye la temperatura en vivo, para que el ingeniero de guardia se entere incluso aunque la regla ya haya empezado a corregir el problema.

El producto queda protegido en el mismo momento en que se detecta la deriva, y el equipo sigue recibiendo el panorama completo. Esa es la diferencia entre una plataforma que te dice que algo salió mal y una que hace algo al respecto.

## Páginas relacionadas

* [Comandos del dispositivo](/kilo-docs-es/kilo-iot-server/devices/commands.md) — define los comandos que una regla puede ejecutar y ejecútalos manualmente
* [Referencia de nodos](/kilo-docs-es/kilo-iot-server/rules-engine/node-reference.md) — cada tipo de nodo, incluido Ejecutar comando, en detalle
* [Referencia de CEL](/kilo-docs-es/kilo-iot-server/rules-engine/cel-reference.md) — el lenguaje de expresiones para valores dinámicos de parámetros
* [Widget de control](/kilo-docs-es/kilo-iot-server/dashboards/adding-widgets/control-widget.md) — opera los mismos comandos desde un panel


---

# 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/running-device-commands.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.