> 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/rules-engine/running-device-commands.md). # Exécution de commandes sur les appareils Faites agir une règle Kilo toute seule — le nœud Exécuter la commande envoie une commande à l’appareil lorsque les conditions sont remplies. C'est le changement qui transforme le moteur de règles d'un système qui *observe* en un système qui *agit*. Jusqu'à présent, lorsqu'une règle détectait un problème, le plus qu'elle pouvait faire était de lancer une alarme et de mettre un humain dans la boucle — quelqu'un devait lire l'alerte et aller actionner l'interrupteur. Le **nœud Exécuter une commande** comble cette lacune. Une règle peut désormais envoyer une commande directement à un appareil dès que ses conditions sont remplies, sans personne entre les deux. Pensez à ce que cela signifie en pratique. Un capteur de fuite se déclenche dans une salle technique. Avant, la règle déclenchait une alarme et un opérateur se précipitait pour fermer la vanne principale — quelques minutes de dégâts des eaux dans tous les cas. Désormais, la même règle ferme elle-même la vanne dans la même évaluation qui a détecté la fuite, et *puis* déclenche l'alarme afin que l'équipe sache que cela s'est produit. Le stockage frigorifique sort de la plage, et la règle pousse un point de consigne plus bas vers le contrôleur avant que le produit ne soit en danger. Un réservoir atteint un niveau haut, et la règle ferme l'arrivée. C'est de l'automatisation en boucle fermée : détecter, décider et agir, de bout en bout, dans une seule règle. L'action s'exécute sur le même [moteur Device Commands](/kilo-docs-fr/kilo-iot-server/devices/commands.md) que vous utilisez manuellement — la règle envoie simplement une commande que vous avez déjà définie sur l'appareil. Ainsi, tout ce qui rend les commandes manuelles sûres (paramètres typés, vérification facultative, journal d'exécution complet) s'applique automatiquement lorsqu'une règle en déclenche une. ## Avant de commencer Le nœud Exécuter une commande envoie l'une des **existantes** commandes. Il n'en définit pas de nouvelles. Donc, avant qu'une règle puisse agir sur un appareil : 1. **L'appareil doit être pilotable** — connecté via MQTT, ou être un appareil LoRaWAN de classe C (les appareils de classe C écoutent en continu, donc ils peuvent recevoir un downlink à tout moment). 2. **L'appareil doit avoir au moins une commande définie** — configurez cela d'abord sur l' **onglet Commandes et états** . Voir [Création de commandes](/kilo-docs-fr/kilo-iot-server/devices/commands/creating-commands.md). 3. **Vous avez l'autorisation de gérer la règle et les commandes de l'appareil** — les deux sont régis par la politique d'accès de votre organisation. Si un appareil n'a encore aucune commande, il ne proposera rien à exécuter — définissez d'abord la commande, puis revenez à la règle. ## Ajouter un nœud Exécuter une commande 1. Ouvrez la règle dans l' [Éditeur visuel](/kilo-docs-fr/kilo-iot-server/rules-engine/visual-editor.md) et passez en **mode d'édition** . 2. Faites glisser **nœud Exécuter une commande** depuis la palette sur le canevas. Il se trouve dans le même groupe que Définir une alarme et Enrichissement — c'est une action que la règle exécute lorsque l'exécution l'atteint. 3. Reliez-le à votre flux. En général, il suit une branche de passerelle exclusive — la règle évalue une condition, et la branche qui signifie « agir maintenant » mène au nœud Exécuter une commande. 4. Cliquez sur le nœud pour ouvrir son panneau de propriétés et renseigner les champs ci-dessous. 5. Cliquez sur **Enregistrer**, puis **Compiler** et déployez la règle comme d'habitude. La commande ne se déclenche qu'une fois la règle compilée et en cours d'exécution. ## Panneau de propriétés | Champ | Description | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Nom** | Une étiquette pour le nœud sur le canevas. Si vous la laissez vide et choisissez une commande, elle se remplit avec le nom de la commande. Exemple : « Fermer la vanne d'admission ». | | **Appareil** | Une liste déroulante consultable des appareils de votre organisation. Choisissez l'appareil auquel la commande doit être envoyée. | | **Commande** | Une liste déroulante des commandes définies sur cet appareil. Désactivée jusqu'à ce qu'un appareil soit sélectionné, puis elle affiche toutes les commandes disponibles sur l'appareil choisi. | | **Paramètres** | Apparaît une fois qu'une commande est choisie, avec une ligne par paramètre attendu par la commande (un niveau de luminosité, une consigne, un indicateur ouvrir/fermer). Chaque paramètre est fourni soit comme une **Valeur** ou une **expression CEL** — voir ci-dessous. | | **Entrées / Sorties** | Facultatif. Expressions CEL nommées pour le façonnage avancé des données, selon le même modèle utilisé sur d'autres nœuds. Utilisez les Entrées pour préparer des valeurs d'aide et les Sorties pour publier des résultats destinés aux nœuds en aval. | **Enregistrer / Annuler** se trouvent en bas du panneau. ### Définition des paramètres de commande : Valeur ou expression Chaque paramètre défini par la commande obtient sa propre ligne, et pour chacun vous choisissez comment la valeur est fournie : * **Valeur** — une valeur littérale fixe que vous saisissez. Utilisez-la lorsque la règle doit toujours envoyer la même valeur : une consigne de `4`, un état de `désactivé`, un rapport cyclique de `100`. Le champ est validé par rapport à la définition du paramètre de la commande, de sorte qu'une valeur hors plage ou de type incorrect est signalée avant que vous puissiez enregistrer. * **Expression** — une [CEL](/kilo-docs-fr/kilo-iot-server/rules-engine/cel-reference.md) évaluée lorsque la règle s'exécute. C'est ce qui rend l'action *dynamique*: le contexte actif de la règle est disponible via `vars`, de sorte qu'un paramètre de commande peut être calculé à partir de la mesure même qui a déclenché la règle. Par exemple, définir une vitesse de ventilateur à partir de la température mesurée, ou transmettre directement la valeur du capteur avec `vars.value`. La combinaison est puissante : une passerelle exclusive décide *si* agir, et une expression CEL sur le nœud Exécuter une commande décide *quelle valeur envoyer* — ainsi, une seule règle peut à la fois réagir à un seuil et répondre proportionnellement à l'écart de la mesure au-delà de ce seuil. ## Ce qui se passe lorsque le nœud s'exécute 1. La règle atteint le nœud Exécuter une commande au fil de son flux. 2. Chaque paramètre est résolu — les littéraux tels quels, les expressions évaluées par rapport au contexte actuel `vars`. 3. La commande est envoyée à l'appareil sous forme de downlink, via MQTT ou LoRaWAN, exactement comme si elle avait été exécutée à la main depuis l'onglet **États** de l'appareil. 4. L'envoi est enregistré dans l'historique d'exécution de l'appareil avec son résultat (En attente, Confirmé, Livré, Avertissement mineur ou Échec), de sorte qu'il existe un audit complet de chaque action prise par une règle. Parce que la commande passe par le chemin standard des Commandes d'appareils, toute vérification configurée sur cette commande s'applique ici aussi — la règle peut confirmer que l'appareil a réellement agi, et pas seulement que le downlink a été envoyé. Voir [Confirmation des commandes](/kilo-docs-fr/kilo-iot-server/devices/commands/verification.md). ## Agir *et* et alerter dans une même règle Agir sur un appareil ne remplace pas l'alerte — les deux fonctionnent mieux ensemble. Une seule règle peut fermer la vanne **et** déclencher une alarme, de sorte que la situation soit automatiquement contenue *et* les bonnes personnes en soient informées. Schéma courant : | Étape | Nœud | Ce qu'il fait | | -------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Détecter | Événement de démarrage → passerelle exclusive | Se lier au capteur de fuite ; bifurquer lorsqu'une fuite est détectée | | Agir | nœud Exécuter une commande | Envoyer « fermer la vanne » à la vanne d'arrêt | | Notifier | Définir une alarme | Déclencher une alarme de gravité élevée avec un message de justification qui inclut la température en direct, afin que l'ingénieur de permanence sache que la vanne a été fermée et pourquoi | Si l'action elle-même peut échouer — par exemple si l'appareil est brièvement hors ligne — attachez un [événement d'erreur de frontière](/kilo-docs-fr/kilo-iot-server/rules-engine/node-reference.md#boundary-error-event) au nœud Exécuter une commande et acheminez le chemin d'erreur vers un nœud Définir une alarme, afin qu'une commande qui ne passe pas quand même parvienne à un humain. ## Un exemple concret Une règle de chaîne du froid protège un congélateur pharmaceutique. L'événement de démarrage se lie à la sonde de température du congélateur. Une passerelle exclusive oriente toute mesure supérieure à −15 °C vers une branche « dérive vers le chaud ». Sur cette branche : 1. Un **nœud Exécuter une commande** nœud envoie une `set_setpoint` commande au contrôleur du congélateur, avec le paramètre de consigne défini comme une **Expression** expression qui abaisse la cible en fonction de l'écart de la mesure — une correction plus froide pour un écart plus important. 2. Un **Définir une alarme** nœud déclenche une alarme de gravité élevée avec un message de justification qui inclut la température en direct, afin que l'ingénieur de permanence soit informé même si la règle a déjà commencé à corriger le problème. Le produit est protégé au moment où la dérive est détectée, et l'équipe obtient quand même la vue d'ensemble complète. C'est la différence entre une plateforme qui vous dit qu'un problème s'est produit et une autre qui fait quelque chose à ce sujet. ## Pages associées * [moteur Device Commands](/kilo-docs-fr/kilo-iot-server/devices/commands.md) — définir les commandes qu'une règle peut exécuter, et les exécuter manuellement * [Référence des nœuds](/kilo-docs-fr/kilo-iot-server/rules-engine/node-reference.md) — tous les types de nœuds, y compris Exécuter une commande, en détail * [Référence CEL](/kilo-docs-fr/kilo-iot-server/rules-engine/cel-reference.md) — le langage d'expression pour les valeurs de paramètres dynamiques * [Widget de contrôle](/kilo-docs-fr/kilo-iot-server/dashboards/adding-widgets/control-widget.md) — utiliser les mêmes commandes depuis un tableau de bord --- # 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/rules-engine/running-device-commands.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.