Confirmation des commandes

Comment Kilo IoT Server confirme qu’une commande a pris effet — aucune vérification, contrôle à la liaison montante suivante ou requête après l’ACK.

Envoyer une commande et savoir qu'elle a fonctionné sont deux choses différentes. Un downlink peut être accepté pour livraison et ne jamais changer l'appareil physique — l'appareil peut être en veille, hors de portée, ou simplement l'ignorer. La Vérification section de l’éditeur de commandes vous permet d’indiquer à la plateforme comment confirmer qu’une commande a réellement pris effet, afin qu’une exécution ne soit marquée comme réussie que lorsqu’il existe de véritables preuves à l’appui.

La vérification se configure par commande, dans la section 4 de l’ éditeur de commandes. Choisissez l’une des trois stratégies.

Aucune vérification

Envoi et oubli. La commande est envoyée et la plateforme ne vérifie pas le résultat.

Avec cette stratégie, une exécution est marquée Livrée dès que le downlink est accepté pour livraison — et non lorsque l’appareil agit dessus. (Le statut vert Livré signifie exactement cela : envoyé, mais non vérifié — à distinguer de Confirmée, que seule une stratégie de vérification peut produire.) Rien ne garantit que l’action ait eu le moindre effet. Cela convient aux actions non critiques et idempotentes, où une commande manquée est sans conséquence et sera de toute façon renvoyée, mais ne vous y fiez jamais comme preuve qu’une chose a physiquement changé.

Attendez la prochaine liaison montante

Après l’envoi de la commande, la plateforme attend le prochain uplink régulier de l’appareil et le compare aux états de capteurs attendus que vous définissez. Lorsque les valeurs déclarées correspondent, l’exécution est confirmée.

Cela convient aux appareils qui remontent leurs données selon un calendrier et reflètent leur état dans la télémétrie normale — par exemple, un contrôleur qui inclut son point de consigne actuel ou la position de son relais dans chaque uplink.

Interroger après accusé de réception

L’option la plus complète. Après que l’appareil a accusé réception de la commande, la plateforme envoie une commande de requête — une petite lecture qui interroge l’appareil sur son état actuel — et compare la réponse uplink de cette requête aux états attendus.

Sur un appareil LoRaWAN, activez Liaison descendante confirmée dans la section 2 (Routage) avant de choisir cette stratégie. La requête est envoyée une fois que l’appareil a accusé réception de la commande, il faut donc qu’il y ait un accusé de réception à attendre — sinon la commande ne sera pas enregistrée. Si vous préférez ne pas utiliser de downlink confirmé, choisissez Attendez la prochaine liaison montante.

• Commande de requête — Sélectionnez une commande de requête existante, ou créez-en une nouvelle sur place. Une commande de requête est un type de commande dédié et léger : une lecture de sondage d’état sans paramètres d’opérateur, donc il n’y a rien à renseigner au moment de l’exécution. Elle est toujours elle-même définie sur Aucune vérification — la requête est l’étape de vérification, et son uplink est ce qui est contrôlé, elle n’a donc pas de bloc de vérification propre. Toute commande qui ne prend aucun paramètre et utilise Aucune vérification peut servir de commande de requête et apparaît dans cette liste. Une fois enregistrée, elle apparaît dans la liste des commandes, marquée comme adaptée à une requête, et peut être réutilisée par n’importe quelle autre commande Interroger après accusé de réception.

• Dans le champ Nouvelle commande de requête boîte de dialogue, vous définissez le payload qui interroge l’appareil. Pour les appareils MQTT, choisissez si vous voulez Envoyer tel quel (envoyer le payload exactement comme écrit) ou Traiter avec un encodeur (le faire passer d’abord par l’encodeur de l’appareil).

• La requête s’exécute après que l’appareil a accusé réception de la commande, et sa réponse est évaluée par rapport aux états attendus ci-dessous.

Utilisez-la lorsqu’un appareil ne communique pas spontanément son état dans ses uplinks de routine mais qu’il répond à une lecture directe.

États de capteur attendus

Les deux Attendez la prochaine liaison montante et Interroger après accusé de réception vérifient la télémétrie rapportée par l’appareil par rapport aux états que vous déclarez ici. Cliquez Ajouter un état pour ajouter une ligne, puis remplissez les deux champs ci-dessous. Ajoutez au moins une ligne — la commande ne sera pas enregistrée sans cela.

Métrique

Sélectionnez le capteur que la commande modifie. Une commande qui active un relais est vérifiée par rapport au capteur qui indique l’état du relais, et non par rapport au niveau de batterie ou à la puissance du signal.

La liste déroulante affiche les capteurs de l’appareil sous les noms que vous leur avez donnés lors du mappage — les mêmes noms que vous voyez sur les tableaux de bord et dans les règles. Ces noms ne sont pas les noms de champs à l’intérieur de votre décodeur : un décodeur qui renvoie socket_status peut apparaître ici comme État de la prise. Pour voir quel capteur correspond à quel champ décodé, ouvrez la section Mappage de l’appareil — voir Décodage des charges utiles et clés des connecteurs.

Choisissez un capteur déjà mappé et recevant des mesures. Les capteurs non mappés apparaissent aussi dans cette liste, et une commande vérifiée sur l’un d’eux ne reçoit jamais de valeur à comparer, donc elle se termine comme Avertissement léger à chaque fois. Si l’appareil n’a encore aucun capteur mappé, l’éditeur vous redirige vers la section Mappage pour les configurer d’abord.

Valeur attendue

Saisissez la valeur que le capteur doit rapporter une fois que la commande a pris effet. Écrivez-la exactement comme l’appareil la rapporte — ouvrez la section Mappage de l’appareil et lisez la valeur actuelle du capteur pour voir la forme à recopier.

Pour un état textuel, saisissez-le directement. La casse n’a pas d’importance, donc on correspond à un appareil qui renvoie ON.

Pour un état numérique ou vrai/faux, faites plutôt référence à un paramètre de commande qu’à une valeur tapée : saisissez {{ parameterName }} et déclarez ce paramètre comme Entier, Flottant ou Booléen dans la section du payload. Une valeur saisie est toujours traitée comme du texte, donc un 1 tapé cherche le texte 1 et ne correspondra pas à un appareil qui renvoie le nombre 1.

Pour suivre la saisie de l’opérateur, utilisez la même {{ parameterName }} référence — une commande « définir la luminosité » peut vérifier que l’appareil indique désormais la luminosité demandée. Le nom doit correspondre à un paramètre défini dans la section du payload ; l’éditeur le signale si ce n’est pas le cas.

Le capteur rapporte	Saisissez
on ou ON	on
ouvert	ouvert
60 (un nombre)	{{ level }}, avec level déclaré comme Entier
vrai (vrai/faux)	{{ state }}, avec state déclaré comme Booléen

Si une commande continue de se terminer comme Avertissement léger alors que l’appareil a clairement répondu, vérifiez d’abord ce champ : comparez ce que vous avez saisi à la valeur que le capteur rapporte réellement dans la section Mappage.

Délai de convergence

Les Délai de convergence est le délai pendant lequel la plateforme attend que l’état rapporté corresponde avant d’abandonner.

• Laissez-le vide pour utiliser la valeur par défaut de la plateforme de 1,5 × l’intervalle d’envoi de données de l’appareil. Définissez d’abord cet intervalle correctement sur l’appareil — s’il manque, la valeur par défaut équivaut à une fenêtre de 90 minutes, ce qui est bien plus long que nécessaire pour la plupart des commandes.

• Ou saisissez votre propre valeur, jusqu’à 24 heures.

• Si la fenêtre expire sans correspondance, l’exécution est marquée Avertissement léger comme Avertissement plutôt que comme Échec — la commande a été livrée et acquittée, mais la plateforme n’a pas pu confirmer l’effet dans le délai prévu. Cette distinction compte opérationnellement : un avertissement léger signifie « nous n’avons pas pu confirmer », et non « cela a définitivement échoué ».

• Une commande qui n’est pas confirmée dans sa fenêtre n’est pas renvoyée. Relancez-la vous-même, ou laissez une règle le faire.

Choisir une stratégie

Stratégie	Confirme	Idéal pour
Aucune vérification	Livraison uniquement	Actions répétables à faible enjeu
Attendez la prochaine liaison montante	État signalé lors du prochain message planifié	Appareils qui signalent régulièrement leur état
Interroger après accusé de réception	État signalé à partir d’une requête directe	Appareils qui répondent aux lectures mais ne signalent pas spontanément leur état

Une fois la vérification définie, passez à Exécution des commandes pour envoyer la commande et surveiller le résultat. Pour la séquence complète sur un appareil — payload, vérification et exécution — voir Exemple : prise intelligente.