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

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