> 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/verification.md).
# Confirmar comandos
Cómo confirma Kilo IoT Server que un comando surtió efecto — sin verificación, comprobación en el siguiente uplink o consulta después del acuse.
Enviar un comando y saber que funcionó son dos cosas distintas. Un enlace descendente puede ser aceptado para su entrega y aun así no cambiar nunca el dispositivo físico: el dispositivo puede estar dormido, fuera de alcance o simplemente ignorarlo. La **Verificación** sección del editor de comandos te permite indicar a la plataforma cómo confirmar que un comando realmente surtió efecto, de modo que una ejecución solo se marque como exitosa cuando haya pruebas reales que la respalden.
La verificación se configura por comando, en **la sección 4** del [editor de comandos](/kilo-docs-es/kilo-iot-server/devices/commands/creating-commands.md). Elige una de tres estrategias.
## Sin verificación
Enviar y olvidar. El comando se envía y la plataforma no comprueba el resultado.
Con esta estrategia, una ejecución se marca como **Entregada en cuanto el enlace descendente se acepta para su entrega, no cuando el dispositivo actúa sobre él.** (El estado verde **Entregado** significa exactamente eso: enviado, pero no verificado; distinto de **Confirmado**, que solo una estrategia de verificación puede producir). No hay garantía de que la acción haya tenido algún efecto. Esto es apropiado para acciones no críticas e idempotentes en las que un comando omitido no es un problema y se volverá a enviar de todos modos, pero nunca confíes en ello como prueba de que algo cambió físicamente.
## Esperar el siguiente enlace ascendente
Después de enviar el comando, la plataforma espera el siguiente enlace ascendente regular del dispositivo y lo compara con los **estados de sensores esperados** que defines. Cuando los valores reportados coinciden, la ejecución se confirma.
Esto encaja con dispositivos que informan según un horario y reflejan su estado en la telemetría normal; por ejemplo, un controlador que incluye su punto de ajuste actual o la posición del relé en cada enlace ascendente.
## Consulta después del acuse
La opción más exhaustiva. Después de que el dispositivo acuse recibo del comando, la plataforma envía un **comando de consulta** — una pequeña lectura que interroga al dispositivo sobre su estado actual — y compara la respuesta de ese enlace ascendente de consulta con los estados esperados.
En un dispositivo LoRaWAN, activa **enlace descendente confirmado** en la sección 2 (Enrutamiento) antes de elegir esta estrategia. La consulta se envía una vez que el dispositivo acusa recibo del comando, por lo que tiene que haber un acuse de recibo que esperar — de lo contrario, el comando no se guardará. Si prefieres no usar un enlace descendente confirmado, elige *Esperar el siguiente enlace ascendente*.
* **Comando de consulta** — Selecciona un comando de consulta existente, o **crear uno nuevo** en línea. Un comando de consulta es un tipo de comando dedicado y ligero: una **lectura de sondeo de estado sin parámetros para el operador**, así que no hay nada que completar en el momento de la ejecución. Siempre se establece él mismo en **Sin verificación** — la consulta *es* el paso de verificación, y su enlace ascendente es lo que se comprueba, por lo que no lleva su propio bloque de verificación. Cualquier comando que no acepte parámetros y use Sin verificación puede servir como comando de consulta y aparece en esta lista. Una vez guardado aparece en la lista de Comandos, marcado como apto como consulta, y puede ser reutilizado por cualquier otro comando *Consulta después del acuse*.
* En el **Nuevo comando de consulta** En el diálogo de Nuevo comando de consulta defines el payload que interroga al dispositivo. Para dispositivos MQTT, elige si **Enviar tal cual** (entregar el payload exactamente como está escrito) o **Procesar con el codificador** (ejecutarlo primero a través del codificador del dispositivo).
* La consulta se ejecuta después de que el dispositivo acusa recibo, y su respuesta se evalúa frente a los estados esperados que aparecen abajo.
Usa esto cuando un dispositivo no comunique voluntariamente su estado en los enlaces ascendentes de rutina, pero sí responda a una lectura directa.
## Estados de sensores esperados
Ambos *Esperar el siguiente enlace ascendente* y *Consulta después del acuse* comprueba la telemetría reportada por el dispositivo frente a los estados que declares aquí. Haz clic en **Agregar estado** para añadir una fila, y completa los dos campos de abajo. Añade al menos una fila: el comando no se guardará sin ella.
### Métrica
Selecciona el sensor que modifica el comando. Un comando que activa un relé se comprueba contra el sensor que informa del estado del relé, no contra el nivel de batería o la intensidad de la señal.
La lista desplegable muestra los sensores del dispositivo con los nombres que les diste al asignarlos — los mismos nombres que ves en los paneles y en las reglas. Esos nombres no son los nombres de campo dentro de tu decodificador: un decodificador que produce `socket_status` puede aparecer aquí como *Estado del socket*. Para ver qué sensor lleva qué campo decodificado, abre la sección de Asignación del dispositivo — consulta [Decodificación de carga útil y claves de conector](/kilo-docs-es/kilo-iot-server/devices/payload-decoding.md).
Elige un sensor que ya esté asignado y recibiendo lecturas. Los sensores sin asignar también aparecen en esta lista, y un comando comprobado contra uno de ellos nunca recibe un valor para comparar, así que termina como *advertencia suave* cada vez. Si el dispositivo todavía no tiene sensores asignados, el editor te enlaza a la sección de Asignación para configurarlos primero.
### Valor esperado
Introduce el valor que el sensor debería reportar una vez que el comando haya surtido efecto. Escríbelo exactamente como lo reporta el dispositivo: abre la sección de Asignación del dispositivo y lee el valor actual del sensor para ver la forma que debes copiar.
**Para un estado de texto**, escríbelo directamente. Las mayúsculas y minúsculas no importan, así que `activados` coincide con un dispositivo que reporta `ENCENDIDO`.
**Para un estado numérico o verdadero/falso**, referencia un parámetro de comando en lugar de escribir el valor: introduce `{{ parameterName }}` y declara ese parámetro como Integer, Float o Boolean en la sección de payload. Un valor que escribes siempre se trata como texto, así que un `1` escrito busca el texto `1` y no coincidirá con un dispositivo que reporta el número 1.
**Para seguir la entrada del operador**, usa la misma `{{ parameterName }}` referencia: un comando de "ajustar brillo" puede comprobar que el dispositivo ahora informa del brillo que se solicitó. El nombre debe coincidir con un parámetro definido en la sección de payload; el editor lo marca si no es así.
| El sensor reporta | Introduce |
| ----------------------------- | --------------------------------------------------- |
| `activados` o `ENCENDIDO` | `activados` |
| `abierto` | `abierto` |
| `60` (un número) | `{{ level }}`, con **nivel** declarado como Integer |
| `verdadero` (verdadero/falso) | `{{ state }}`, con **state** declarado como Boolean |
Si un comando sigue terminando como *advertencia suave* aunque el dispositivo haya respondido claramente, revisa este campo primero: compara lo que introdujiste con el valor que el sensor está reportando realmente en la sección de Asignación.
## Tiempo de espera de convergencia
El **Tiempo de espera de convergencia** es cuánto tiempo espera la plataforma a que el estado reportado coincida antes de rendirse.
* Déjalo vacío para usar el valor predeterminado de la plataforma de **1.5 × el intervalo de envío de datos del dispositivo**. Establece primero ese intervalo correctamente en el dispositivo — si falta, el valor predeterminado da lugar a una ventana de 90 minutos, que es mucho más larga de lo que necesitan la mayoría de los comandos.
* O introduce un valor propio, de hasta 24 horas.
* Si la ventana transcurre sin una coincidencia, la ejecución se marca como **advertencia suave** advertencia suave en lugar de Fallida — el comando se entregó y fue reconocido, pero la plataforma no pudo confirmar el efecto dentro del tiempo esperado. Esta distinción importa operativamente: una advertencia suave es "no pudimos confirmar", no "falló definitivamente".
* Un comando que no se confirma dentro de su ventana no se vuelve a enviar. Vuelve a ejecutarlo tú mismo, o deja que una regla lo haga.
## Elegir una estrategia
| Estrategia | Confirma | Lo mejor para |
| -------------------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------- |
| Sin verificación | Solo entrega | Acciones de poco riesgo y repetibles |
| Esperar el siguiente enlace ascendente | Estado reportado en el siguiente mensaje programado | Dispositivos que reportan su estado de forma rutinaria |
| Consulta después del acuse | Estado reportado a partir de una consulta directa | Dispositivos que responden a lecturas pero no comunican su estado voluntariamente |
Una vez configurada la verificación, pasa a [Ejecución de comandos](/kilo-docs-es/kilo-iot-server/devices/commands/executing-commands.md) para enviar el comando y ver el resultado. Para ver toda la secuencia en un dispositivo — payload, verificación y ejecución — consulta [Ejemplo: enchufe inteligente](/kilo-docs-es/kilo-iot-server/devices/commands/smart-socket-example.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/verification.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.
