> 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-pt/kilo-iot-server/devices/commands/verification.md).
# Confirmar Comandos
Como o Kilo IoT Server confirma que um comando produziu efeito — sem verificação, controlo no uplink seguinte ou consulta após o ack.
Enviar um comando e saber que funcionou são duas coisas diferentes. Um downlink pode ser aceite para entrega e mesmo assim nunca alterar o dispositivo físico — o dispositivo pode estar a dormir, fora de alcance ou simplesmente ignorá-lo. A **Verificação** secção do editor de comandos permite-lhe indicar à plataforma como confirmar que um comando realmente produziu efeito, para que uma execução só seja marcada como bem-sucedida quando existe prova real por trás dela.
A verificação é configurada por comando, na **secção 4** do [editor de comandos](/kilo-docs-pt/kilo-iot-server/devices/commands/creating-commands.md). Escolha uma de três estratégias.
## Sem verificação
Enviar e esquecer. O comando é enviado e a plataforma não verifica o resultado.
Com esta estratégia, uma execução é marcada **Entregue assim que o downlink é aceite para entrega — não quando o dispositivo age sobre ele.** (O estado verde **Entregue** significa exatamente isso: enviado, mas não verificado — distinto de **Confirmado**, que só uma estratégia de verificação pode produzir.) Não há garantia de que a ação tenha tido qualquer efeito. Isto é apropriado para ações não críticas, idempotentes, em que um comando perdido é inofensivo e será reenviado de qualquer forma, mas nunca se baseie nisso como prova de que algo mudou fisicamente.
## Aguardar pelo próximo uplink
Depois de o comando ser enviado, a plataforma aguarda o próximo uplink regular do dispositivo e compara-o com os **estados de sensores esperados** que definir.
Quando os valores reportados correspondem, a execução é confirmada.
## Consulta após ack
A opção mais completa. Depois de o dispositivo reconhecer o comando, a plataforma envia um **comando de consulta** — uma pequena leitura que interpela o dispositivo para obter o seu estado atual — e compara a resposta uplink dessa consulta com os estados esperados.
Num dispositivo LoRaWAN, ative **Downlink confirmado** na secção 2 (Encaminhamento) antes de escolher esta estratégia. A consulta é enviada assim que o dispositivo reconhece o comando, por isso tem de haver um reconhecimento à espera — caso contrário, o comando não será guardado. Se preferir não usar um downlink confirmado, escolha *Aguardar pelo próximo uplink*.
* **Comando de consulta** — Selecione um comando de consulta existente, ou **crie um novo** em linha. Um comando de consulta é um tipo de comando dedicado e leve: uma **leitura de verificação de estado sem parâmetros do operador**, por isso não há nada a preencher no momento da execução. Ele próprio está sempre definido para **Sem verificação** — a consulta *é* a etapa de verificação, e o seu uplink é o que é verificado, por isso não tem o seu próprio bloco de verificação. Qualquer comando que não tenha parâmetros e use Sem verificação pode servir como comando de consulta e aparece nesta lista. Depois de guardado, aparece na lista de Comandos, assinalado como adequado para consulta, e pode ser reutilizado pela verificação de qualquer outro comando *Consulta após ack*.
* No **Novo comando de consulta** caixa de diálogo, define o payload que consulta o dispositivo. Para dispositivos MQTT, escolha se pretende **Enviar tal como está** (entregar o payload exatamente como foi escrito) ou **Processar com encoder** (executá-lo primeiro através do encoder do dispositivo).
* A consulta é executada depois de o dispositivo responder com ack, e a sua resposta é avaliada em relação aos estados esperados abaixo.
Use isto quando um dispositivo não indicar espontaneamente o seu estado nos uplinks de rotina, mas responder a uma leitura direta.
## Estados de sensores esperados
Ambos *Aguardar pelo próximo uplink* e *Consulta após ack* verificar a telemetria reportada pelo dispositivo em relação aos estados que declarar aqui. Clique **Adicionar estado** para adicionar uma linha e preencha os dois campos abaixo. Adicione pelo menos uma linha — o comando não será guardado sem ela.
### Métrica
Selecione o sensor que o comando altera. Um comando que liga/desliga um relé é verificado em relação ao sensor que reporta o estado do relé, e não em relação ao nível da bateria ou à intensidade do sinal.
A lista suspensa apresenta os sensores do dispositivo pelos nomes que lhes deu ao fazer o mapeamento — os mesmos nomes que vê em painéis e em regras. Esses nomes não são os nomes dos campos dentro do seu decoder: um decoder que emite `socket_status` pode aparecer aqui como *Estado da tomada*. Para ver qual sensor corresponde a que campo decodificado, abra a secção de Mapeamento do dispositivo — veja [Decodificação de carga útil e chaves do conector](/kilo-docs-pt/kilo-iot-server/devices/payload-decoding.md).
Escolha um sensor que já esteja mapeado e a receber leituras. Sensores não mapeados também aparecem nesta lista, e um comando verificado em relação a um deles nunca recebe um valor para comparar, por isso termina sempre com *aviso ligeiro* . Se o dispositivo ainda não tiver sensores mapeados, o editor encaminha-o para a secção de Mapeamento para os configurar primeiro.
### Valor esperado
Introduza o valor que o sensor deve reportar assim que o comando tiver efeito. Escreva-o exatamente como o dispositivo o reporta — abra a secção de Mapeamento do dispositivo e leia o valor atual do sensor para ver a forma a copiar.
**Para um estado de texto**, escreva-o diretamente. A capitalização não importa, por isso `ligados` corresponde a um dispositivo que reporta `LIGADO`.
**Para um estado numérico ou verdadeiro/falso**, faça referência a um parâmetro de comando em vez de escrever o valor: introduza `{{ parameterName }}` e declare esse parâmetro como Inteiro, Flutuante ou Booleano na secção de payload. Um valor que escreva é sempre tratado como texto, por isso um `1` escrito procura o texto `1` e não corresponderá a um dispositivo que reporte o número 1.
**Para seguir a entrada do operador**, use a mesma `{{ parameterName }}` referência — um comando "definir brilho" pode verificar que o dispositivo agora reporta o brilho que foi solicitado. O nome tem de corresponder a um parâmetro definido na secção de payload; o editor assinala-o se não corresponder.
| O sensor reporta | Introduza |
| ------------------------------- | ----------------------------------------------- |
| `ligados` ou `LIGADO` | `ligados` |
| `aberto` | `aberto` |
| `60` (um número) | `{{ level }}`, com **nível** declarado Inteiro |
| `verdadeiro` (verdadeiro/falso) | `{{ state }}`, com **state** declarado Booleano |
Se um comando continuar a terminar como *aviso ligeiro* mesmo que o dispositivo tenha respondido claramente, verifique primeiro este campo: compare o que introduziu com o valor que o sensor está realmente a reportar na secção de Mapeamento.
## Tempo limite de convergência
A **Tempo limite de convergência** é quanto tempo a plataforma espera que o estado reportado corresponda antes de desistir.
* Deixe-o em branco para usar o padrão da plataforma de **1,5 × o intervalo de envio de dados do dispositivo**. Defina primeiro esse intervalo corretamente no dispositivo — quando falta, o padrão resulta numa janela de 90 minutos, muito mais longa do que a maioria dos comandos precisa.
* Ou introduza um valor à sua escolha, até 24 horas.
* Se a janela passar sem correspondência, a execução é marcada **aviso ligeiro** como Aviso ligeiro em vez de Falhado — o comando foi entregue e reconhecido, mas a plataforma não conseguiu confirmar o efeito dentro do tempo esperado. Esta distinção é importante operacionalmente: um aviso ligeiro significa "não conseguimos confirmar", não "falhou definitivamente".
* Um comando que não seja confirmado dentro da sua janela não é enviado novamente. Execute-o novamente você próprio, ou deixe uma regra fazê-lo.
## Escolher uma estratégia
| Estratégia | Confirma | Ideal para |
| ---------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------- |
| Sem verificação | Apenas entrega | Ações de baixo risco, repetíveis |
| Aguardar pelo próximo uplink | Estado reportado na próxima mensagem agendada | Dispositivos que reportam o seu estado de forma rotineira |
| Consulta após ack | Estado reportado a partir de uma consulta direta | Dispositivos que respondem a leituras, mas não indicam espontaneamente o estado |
Assim que a verificação estiver definida, passe a [Executar comandos](/kilo-docs-pt/kilo-iot-server/devices/commands/executing-commands.md) para despachar o comando e observar o resultado. Para a sequência completa num único dispositivo — payload, verificação e execução — veja [Exemplo: tomada inteligente](/kilo-docs-pt/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-pt/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.
