Commandes d’appareil

Envoyez des commandes descendantes depuis Kilo IoT Server pour contrôler les appareils — à la main, depuis une règle ou en demandant à l’assistant IA.

La surveillance vous indique ce qu’un appareil est en train de faire. Commandes vous permet de le modifier. Avec Device Commands, le serveur Kilo IoT cesse d’être un simple tuyau de données à sens unique et devient une interface de contrôle bidirectionnelle : vous définissez les actions qu’un appareil peut effectuer, puis vous les envoyez à la demande depuis la page de l’appareil, depuis un tableau de bord, ou automatiquement depuis une règle.

Presque tout ce qu’on peut demander à un appareil de faire est une commande. Allumer ou éteindre un relais ou une prise connectée. Faire varier un luminaire à 40 % et régler sa température de couleur à 4000 K. Envoyer un nouveau point de consigne de température à un contrôleur CVC. Ouvrir ou fermer une vanne. Redémarrer un contrôleur relié à une passerelle, modifier son intervalle de remontée d’informations ou écrire un registre de configuration. Si le matériel accepte une liaison descendante, la plateforme peut l’envoyer — et elle l’envoie de la même manière, que l’appareil parle MQTT ou LoRaWAN.

Pourquoi c’est important

Sans couche de commande intégrée, contrôler un appareil signifie quitter la plateforme : une application distincte du fournisseur, un émetteur MQTT développé à la main, un script qui fabrique des octets bruts de liaison descendante, ou un technicien de terrain avec un ordinateur portable. Chacun de ces chemins n’est pas géré, sans audit, sans vérification, et sans définition commune de ce que « l’allumer » signifie réellement pour un modèle donné.

Device Commands réduit tout cela à une seule interface modélisée, réutilisable et auditable :

• Définir une fois, réutiliser partout. Une commande est une action nommée avec des paramètres typés. Les opérateurs l’exécutent sans jamais voir la charge utile brute, la structure des octets ou le topic.

• Contrôle indépendant du protocole. Le même concept de commande couvre une liaison descendante MQTT vers une prise connectée et une liaison descendante LoRaWAN vers un contrôleur de classe C — la plateforme gère l’encodage et la livraison pour chacun.

• Confiance en boucle fermée. Les commandes peuvent vérifier que l’appareil a réellement agi, pas seulement que le message a bien quitté la plateforme (voir Confirmation des commandes).

• Historique complet des exécutions. Chaque envoi est enregistré avec les paramètres qu’il transportait, son résultat et le moment où il a eu lieu — ainsi, les équipes d’exploitation et de conformité peuvent voir exactement ce qui a été envoyé à un appareil et ce qu’il en est résulté.

Où se trouvent les commandes

Les commandes sont gérées sur la page de détail de l’appareil, sous l’ Commandes et états onglet. Cet onglet comporte deux sous-onglets :

• Commandes — l’espace de conception. Définissez, modifiez et supprimez les actions qu’un appareil peut effectuer. Voir Créer des commandes.

• États — l’espace d’exploitation. Exécutez les commandes disponibles et examinez le cycle de vie et le résultat de chaque exécution passée. Voir Exécution des commandes.

Les Commandes et états onglet apparaît pour les appareils pouvant recevoir des liaisons descendantes :

• Appareils MQTT — tout appareil connecté via un connecteur MQTT.

• Appareils LoRaWAN de classe C — les appareils de classe C écoutent en continu et sont toujours prêts à recevoir des commandes, de sorte que l’onglet devient disponible dès qu’un appareil est configuré en classe C. (Les appareils de classe A n’ouvrent qu’une brève fenêtre de réception après chaque liaison montante, ils ne sont donc pas éligibles au contrôle à la demande.)

• Appareils émulés avec la prise en charge des commandes activée — un l’appareil émulé se comporte comme un matériel contrôlable, ce qui vous permet de définir et de répéter un flux de commandes complet avant même que l’équipement n’existe.

Un appareil est considéré comme contrôlable dès qu’il a au moins une commande définie — c’est aussi ce qui le rend sélectionnable pour un tableau de bord widget de contrôle.

Prérequis

Avant de pouvoir contrôler un appareil, assurez-vous que :

1. L’appareil peut recevoir des liaisons descendantes — il est connecté via MQTT, c’est un appareil LoRaWAN de classe C, ou c’est un l’appareil émulé avec Commandes de support activé.

2. Au moins une commande est définie — un appareil vide n’expose rien à exécuter. Commencez dans Créer des commandes.

3. Vous avez les droits d’accès pour gérer ou exécuter des commandes — la définition des commandes et leur envoi sont régis par la politique d’accès de votre organisation.

4. Les paramètres sont valides — lorsqu’une commande prend des entrées (un niveau de luminosité, une consigne), les valeurs doivent respecter les limites définies pour chaque paramètre avant que la commande ne soit envoyée.

Comment le contrôle s’articule

Il existe cinq façons d’envoyer une commande à un appareil :

• Depuis la page de l’appareil — l’ États onglet, où vous exécutez n’importe quelle commande de l’appareil et consultez leur historique.

• Depuis un tableau de bord — une widget de contrôle associe une commande à un interrupteur ou à un bouton afin que toute personne ayant accès au tableau de bord puisse piloter l’appareil sans ouvrir sa page de détail.

• Depuis une règle — l’ Moteur de règles peut désormais envoyer automatiquement une commande lorsqu’une condition est remplie, à l’aide d’un nœud Exécuter une commande. La même commande que vous lancez manuellement est envoyée par la règle sans intervention humaine — ainsi, une mesure hors limites à 3 h du matin ferme elle-même la vanne. Voir Exécution des commandes sur les appareils.

• En demandant à l’assistant — l’ Assistant IA IoT énumère ce qu’un appareil peut faire, exécute l’une de ces commandes après vous avoir montré ce qu’elle enverra et avoir attendu votre confirmation, puis indique si elle a été transmise. Voir Construire avec l’IA.

• Depuis votre propre client IA — connectez ChatGPT, Claude ou tout autre client MCP et il peut faire de même, dans le cadre de vos autorisations et enregistré comme tout autre envoi. Voir Serveur MCP.

Chaque parcours aboutit au même endroit : les définitions de commandes de cet onglet, le même pipeline d’exécution et le même historique. Bien définir une commande est ce qui rend les cinq approches sûres.

Le système d’alarme fonctionne en parallèle de tout cela : il veille à ce que les bonnes personnes soient averties lorsqu’une condition est remplie — qu’une règle ait déjà agi dessus ou non. Agir et alerter sont complémentaires, et une seule règle peut faire les deux : contenir le problème avec une commande et déclencher l’alarme afin que l’équipe soit informée.

Continuer vers Créer des commandes pour définir votre première action.