> 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/devices/commands/creating-commands.md).
# Crear comandos
Define un comando de dispositivo en Kilo IoT Server — enrutamiento MQTT o LoRaWAN, parámetros tipados, codificación de la carga útil y una prueba.
Un comando es una acción reutilizable y con nombre, con entradas tipadas. Lo construyes una vez en el editor de comandos; después, los operadores lo ejecutan desde la **pestaña Estados** pestaña o un panel sin tocar temas, diseños de bytes ni plantillas de carga útil.
Para empezar, abre la **pestaña Comandos y estados** pestaña del dispositivo, permanece en la **Comandos** subpestaña y haz clic en **Añadir nuevo comando**. El editor se abre en cuatro secciones numeradas.
## 1. Identidad
Dale al comando un nombre claro y orientado a la acción; esto es lo que ven los operadores cuando lo ejecutan.
* **Nombre del comando** — Obligatorio. Usa una etiqueta imperativa como `Reiniciar controlador`, `Establecer brillo`, o `Abrir válvula`. Los nombres deben ser únicos en el dispositivo; reutilizar uno genera *"Ya existe un comando con este nombre en este dispositivo."*
* **Descripción** — Opcional, pero recomendable. Una línea sobre lo que hace el comando y cuándo usarlo.
## 2. Enrutamiento
El enrutamiento le indica a la plataforma *dónde* y *cómo* se dirige el mensaje. Los campos difieren según el protocolo.
### Dispositivos MQTT
* **Tema MQTT** — Dónde se publica el mensaje en el broker. Obligatorio.
* Para una conexión Cloud MQTT, se muestra el **prefijo del tema** y tú proporcionas el resto (por ejemplo `mqtt-test-01/set`). El dispositivo debe suscribirse al tema completo — prefijo más tu valor.
* Para una conexión MQTT externa, introduce el tema completo exactamente tal como se publica en tu broker (por ejemplo `devices/light-01/cmd`).
* Un tema debe tener menos de 500 caracteres, no debe contener los comodines `#` o `+`, no debe tener segmentos vacíos (`a//b`), y no debe empezar con `iot/`, `external/`, o `external-downlink/` — esos prefijos están reservados para el tráfico propio de la plataforma.
* Si otro comando en la misma conexión ya publica en el tema que introduces, el editor marca la superposición para que evites que dos acciones choquen accidentalmente en un mismo tema.
* fPort y el downlink confirmado no se aplican a MQTT — esas son configuraciones de LoRaWAN.
### Dispositivos LoRaWAN
* **fPort** — Obligatorio. El puerto LoRaWAN al que se dirige el downlink, un entero entre **1 y 223**.
* **Downlink confirmado** — Un interruptor:
* **Activado — esperar ACK de MAC:** la red espera a que el dispositivo confirme la recepción en la capa de radio.
* **Desactivado — envío y olvido en la capa MAC:** el downlink se envía sin esperar una confirmación.
* Activa esto **on** si piensas verificar el comando con *Consultar después del acuse* en la sección 4 — esa estrategia espera la confirmación, así que no puede guardarse con un downlink no confirmado.
* Los downlinks de LoRaWAN son bytes en bruto, así que la carga útil siempre pasa por un codificador — el modo de enviar tal cual que se ofrece para MQTT no está disponible aquí.
### Dispositivos mioty
Se aplica el downlink confirmado; fPort y el tema MQTT no. Como en LoRaWAN, la carga útil la construye un codificador.
### Dispositivos que no pueden recibir comandos
Los dispositivos conectados a Tracker son solo de recepción en la plataforma: envían informes y no hay una ruta de downlink de vuelta hacia ellos. No ofrecen una pestaña de Comandos.
## 3. Carga útil
Esta sección define el cuerpo del mensaje y las entradas que lo conforman.
### Parámetros
Los parámetros son las entradas tipadas que un operador completa en tiempo de ejecución: un porcentaje de brillo, un punto de ajuste, un modo. Haz clic en **Añadir parámetro** para cada uno. Por parámetro:
* **Nombre** y **Descripción** — la descripción se muestra a los operadores en el diálogo de ejecución, así que hazla útil.
* **Tipo** — uno de:
* **Entero** / **Float** — numérico, con un **Mín.**, **Máximo**, y **Valor predeterminado**. Se rechaza un valor predeterminado fuera del rango, y **Máximo** debe ser mayor que **Mín.**.
* **String** — con **Longitud mínima**, **Longitud máxima**, una **Enum** (por ejemplo `auto, manual, desactivado`), y una **Valor predeterminado**.
* **Booleano** — con un **Valor predeterminado** de `Sin valor predeterminado`, `verdadero`, o `falso`.
Los parámetros tipados son lo que hace que los comandos sean seguros para entregarlos a un operador: un punto de ajuste no puede enviarse fuera de rango, y un modo solo puede ser uno de los valores permitidos.
### Construcción del cuerpo del mensaje
**MQTT** ofrece dos modos:
* **Enviar tal cual** — Publica directamente el cuerpo JSON. Es lo mejor cuando el dispositivo o un consumidor intermedio acepta JSON.
* **Procesar con codificador** — Ejecuta el cuerpo a través de una función codificadora antes de publicarlo.
En modo codificador (y siempre para LoRaWAN, donde los downlinks deben ser bytes en bruto), defines una **Plantilla de entrada del codificador** — el objeto JSON que se pasa al códec, usando marcadores de posición `{{ parameterName }}` para sustituir las entradas del operador. Cada marcador de posición debe coincidir con un parámetro definido arriba. Para LoRaWAN, la plataforma señala que los downlinks son bytes, por lo que siempre se requiere un codificador; puedes usar el codificador definido en el conector o activar **Usar JS de codificador personalizado** para reemplazarlo con una función por comando.
Para los comandos MQTT que envían una carga útil literalmente (modo directo), en su lugar proporcionas la **Tema MQTT** y la **carga útil directa**, que se envía tal como está escrita — `{{ parameterName }}` la sustitución sigue aplicándose a los valores tipados.
## Probar codificador
Cada vez que un comando usa un codificador, el editor incluye una **Probar codificador** herramienta (llamada **Función de código** para LoRaWAN, **Codificador personalizado** para MQTT). Introduce valores de prueba y ejecútala para ver exactamente qué se transmitirá antes de guardar:
* la salida **codificada**, o un **Error** error si la función falló
* el resultado como **Hex** y **Base64**, además de la carga útil **Tamaño** en bytes
* cualquier **salida de registro de consola** y el tiempo de ejecución
Esto convierte la codificación de la carga útil de un juego de adivinanzas en un paso verificable: confirmas que los bytes son correctos antes de que un solo comando llegue a un dispositivo.
## 4. Verificación
La cuarta sección decide cómo confirma la plataforma que el comando realmente surtió efecto: enviar y olvidar, esperar la siguiente subida del dispositivo o sondear el dispositivo después de que lo confirme. Es donde declaras qué sensor debería cambiar y qué debería leer.
Esta sección tiene su propia página: consulta [Confirmación de comandos](/kilo-docs-es/kilo-iot-server/devices/commands/verification.md). Para saber qué valores reporta el dispositivo y en qué forma, consulta [Decodificación de la carga útil y claves del conector](/kilo-docs-es/kilo-iot-server/devices/payload-decoding.md).
## Guardado
Haz clic en **Guardar** para añadir el comando al dispositivo. Aparece inmediatamente en la **Comandos** lista y en la **pestaña Estados** pestaña, listo para ejecutarse. Para cambiarlo más tarde, vuelve a abrirlo desde la lista de Comandos con **Edición**; para eliminarlo, usa **Eliminar** (la plataforma te advierte si otros comandos lo referencian como comando de consulta).
## Siguiente
* Decide cómo confirma la plataforma que un comando funcionó — consulta [Confirmación de comandos](/kilo-docs-es/kilo-iot-server/devices/commands/verification.md).
* Ejecuta un comando y sigue su ciclo de vida — consulta [Ejecución de comandos](/kilo-docs-es/kilo-iot-server/devices/commands/executing-commands.md).
---
# 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/devices/commands/creating-commands.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.
