> 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-fr/kilo-iot-server/devices/commands/verification.md).
# 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](/kilo-docs-fr/kilo-iot-server/devices/commands/creating-commands.md). 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](/kilo-docs-fr/kilo-iot-server/devices/payload-decoding.md).
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](/kilo-docs-fr/kilo-iot-server/devices/commands/executing-commands.md) 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](/kilo-docs-fr/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-fr/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.
