> 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/emulated-devices.md).
# Appareils émulés
Créez un appareil émulé dans Kilo IoT — préréglages de l’appareil, clés et types de données, intervalle de remontée, et basculement vers du matériel réel.
Un appareil émulé enregistré sur le serveur Kilo IoT est un jumeau numérique comme n’importe quel autre — même profil, mêmes tableaux de bord, mêmes règles, mêmes alarmes. Sa particularité est que la plateforme génère sa télémétrie au lieu de la recevoir du matériel. C’est donc le moyen de construire et de valider un déploiement avant même qu’un capteur n’existe.
Cette page couvre les champs spécifiques à l’Emulator dans le formulaire de l’appareil et l’onglet Emulator. Le flux d’enregistrement environnant — nommer l’appareil, l’onglet Metrics, l’onglet Logs, l’enregistrement — est le flux partagé documenté dans [Enregistrement des appareils](/kilo-docs-fr/kilo-iot-server/devices/registering-devices.md).
## Prérequis
* **Un connecteur Emulator.** Un par organisation, sans rien à configurer. Voir [Connecteur Emulator](/kilo-docs-fr/kilo-iot-server/connectors/emulator-connector.md).
* **Rien d’autre.** Aucun identifiant, aucun identifiant fabricant, aucune passerelle, aucune couverture radio. C’est précisément le but.
## Sélection du connecteur
Dans le formulaire de l’appareil, ouvrez l’ **Connexion** onglet et choisissez le connecteur Emulator comme type de connecteur. Le formulaire affiche alors les champs ci-dessous.
| Champ | Ce qu’il fait |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **ID de l’appareil** | L’identifiant sous lequel cet appareil émulé se présente. 1 à 64 caractères, en utilisant des lettres, des chiffres, des espaces, `.`, `_` et `-`. Il doit être **unique sur l’ensemble de la plateforme**, pas seulement au sein de votre organisation, donc une valeur lisible mais spécifique comme `cold-room-01` fonctionne mieux que `sensor1`. |
| **Intervalle d’envoi des données** | À quelle fréquence l’appareil émet une lecture, sous forme d’un nombre suivi d’une unité (par exemple 10 minutes). Choisissez quelque chose de proche du rythme de remontée du capteur réel afin que vos règles se comportent de manière réaliste. |
| **Prendre en charge les commandes** | Activez cette option pour donner à l’appareil un **Commandes et états** onglet, afin que vous puissiez définir et exécuter des commandes contre lui exactement comme vous le feriez contre du matériel physique. Voir [Commandes d’appareil](/kilo-docs-fr/kilo-iot-server/devices/commands.md). |
| **Utiliser un préréglage d’appareil** | Partez d’un modèle d’appareil réel plutôt que de saisir les métriques à la main. |
Contrairement à tous les autres connecteurs, l’intervalle ici ne décrit pas un planning déjà assuré par le matériel — c’est le planning. La plateforme émet selon celui-ci.
## À partir d’un préréglage d’appareil
Cocher **Utiliser un préréglage d’appareil** ouvre une liste de modèles de capteurs réels. Choisissez celui que vous avez — ou celui que vous avez commandé — et la plateforme renseigne pour vous les mesures réelles de ce modèle.
Un préréglage multi-capteurs, par exemple, renseigne l’ensemble complet de ses mesures — température, humidité, qualité de l’air et le reste — chacune avec le bon type de données, et définit un intervalle de remontée pertinent. C’est le moyen le plus rapide d’obtenir un appareil réaliste, et cela signifie que les noms de métriques sur lesquels vous construisez vos tableaux de bord sont ceux que le capteur réel enverra.
> **Un préréglage remplace ce qui est déjà là.** En en sélectionnant un, vous écrasez les métriques saisies à la main et réinitialisez l’intervalle à celui du préréglage. Choisissez d’abord le préréglage, puis ajustez.
**Les préréglages d’appareil ne sont pas** [**des modèles de profil d’appareil**](/kilo-docs-fr/kilo-iot-server/devices/registering-devices.md#for-lorawan-devices-lns-connector)**.** Un modèle de profil d’appareil LoRaWAN configure la façon dont un appareil physique communique avec le réseau — classe, bande, codec. Un préréglage d’appareil décrit ce que mesure un appareil émulé *mesure*, et n’existe que sur l’Emulator.
## Définir les métriques manuellement
Sans préréglage — ou en complément de celui-ci — utilisez **Ajouter une clé de données de l’appareil** pour définir chaque mesure :
* **Clé de données de l’appareil** — le nom de la métrique, tel que `temperature`. C’est ce à quoi les tableaux de bord, les règles et les mappages font référence.
* **Type de données** — `Flottant` pour tout ce qui comporte des décimales, `Entier` pour les nombres entiers, et les autres types pris en charge pour les booléens et le texte. Voir [Métriques](/kilo-docs-fr/kilo-iot-server/devices/metric-templates.md) pour savoir comment les types se normalisent dans l’ensemble d’un déploiement.
Choisissez le type de données avec soin. Une **Entier** métrique tronque les décimales : envoyez `1.5` et l’appareil signale `1`. Si une lecture nécessite une précision décimale, il faut que ce soit une **Flottant**.
## Envoi de valeurs
Une fois l’appareil enregistré, son **Émulateur** onglet répertorie chaque métrique avec deux commandes :
* **Enregistrer** épingle une valeur. L’appareil continue à signaler cette valeur à son intervalle, ce qui vous permet de maintenir un réservoir à 8 % ou un congélateur à −18 °C pendant que vous observez la réaction d’une règle.
* **Envoyer une fois** transmet immédiatement une seule lecture, sans modifier ce que l’appareil signale ensuite. C’est l’option à utiliser lorsque vous voulez déclencher un seuil à la demande.
L’envoi d’une valeur est une **action d’écriture** — elle alimente l’historique, les règles et les alarmes exactement comme la télémétrie réelle. Un utilisateur disposant d’un accès en lecture seule peut consulter un appareil émulé mais ne peut pas y injecter des lectures. Voir [Utilisateurs et autorisations](/kilo-docs-fr/kilo-iot-server/account/users-and-permissions.md).
## Exécuter des commandes sur un appareil émulé
Avec **Prendre en charge les commandes** activé, l’appareil obtient un **Commandes et états** onglet et se comporte comme du matériel commandable. C’est ce qui vous permet de construire et de répéter une boucle fermée avant que l’équipement n’existe : une règle détecte une condition, envoie une commande, et l’alarme enregistre que cela s’est produit — sans risque d’actionner quoi que ce soit de réel.
La définition et l’exécution de commandes fonctionnent de la même manière que sur un appareil physique. Voir [Créer des commandes](/kilo-docs-fr/kilo-iot-server/devices/commands/creating-commands.md) et [Exécution des commandes](/kilo-docs-fr/kilo-iot-server/devices/commands/executing-commands.md).
## Passage en production : basculer vers un appareil réel
C’est l’étape autour de laquelle l’Emulator est conçu. Lorsque le matériel arrive, ouvrez l’ **Connexion** onglet de l’appareil et remplacez le connecteur de **Émulateur** par le véritable — LoRaWAN, par exemple — puis fournissez les identifiants dont l’appareil physique a besoin.
Tout le reste de l’appareil reste en place : son nom, sa place sur vos tableaux de bord, les règles qui lui sont liées, ses définitions d’alarmes et ses chaînes d’escalade. Vous remplacez la source des données, pas le déploiement.
Le basculement est délibérément limité aux paires qui impliquent l’Emulator — de l’Emulator vers le réel, ou du réel vers l’Emulator. Le passage direct entre deux types de connecteurs physiques n’est pas proposé, car les identifiants de l’appareil et les mappages de charge utile diffèrent suffisamment pour que le mappage doive de toute façon être reconstruit.
> L’inverse est tout aussi utile : faites passer un appareil réel sur l’Emulator pour reproduire un problème, puis remettez-le.
## Copier un appareil émulé
Copier un appareil vous donne une avance sur l’enregistrement de l’appareil, mais **cela ne reprend pas la configuration de l’Emulator**. Le nouvel appareil est prérempli avec le nom d’origine, les lignes de modèle de métriques, la sélection de connexion et les paramètres, ainsi que les images. Tout ce qui le fait *émuler* doit être configuré à nouveau :
* **Les définitions de signal de l’Emulator** — les métriques qu’il génère et leurs types de données.
* **L’intervalle de remontée**, qui revient à sa valeur par défaut au lieu de celle de l’original.
* **Prendre en charge les commandes**, qui revient à l’état désactivé.
* **Commandes issues du préréglage.** Sélectionner de nouveau le préréglage d’origine est le moyen le plus rapide de revenir en arrière.
D’ici là, la copie n’émet rien du tout — c’est un appareil lié à l’Emulator avec une spécification vide. **Les mappages de capteurs ne sont pas repris non plus**, donc recréez-les sur la copie après l’enregistrement.
Voir [Gestion des appareils](/kilo-docs-fr/kilo-iot-server/devices/device-management.md#copying-a-device).
## Demandez à l’assistant de le faire
L’ensemble du flux de travail ci-dessus est disponible en langage naturel via le [Assistant IA IoT](/kilo-docs-fr/kilo-iot-server/ai-assistant.md). Il peut lister les préréglages d’appareil disponibles, provisionner un appareil émulé, lire et mettre à jour sa configuration et son intervalle, envoyer une lecture ponctuelle, et mettre l’appareil en production sur une vraie **LoRaWAN** connexion lorsque votre matériel arrive. Il peut aussi déplacer n’importe quel appareil réel vers l’Emulator. Le basculement d’un appareil émulé vers un connecteur Mioty, Tracker ou MQTT est une étape manuelle dans l’onglet Connection — l’assistant ne le propose pas.
## Et ensuite
* **Construisez des automatisations à partir de données émulées** afin qu’elles soient validées avant la mise en service. Voir [Moteur de règles](/kilo-docs-fr/kilo-iot-server/rules-engine.md).
* **Répétez une chaîne d’escalade** de bout en bout sans attendre une vraie panne. Voir [Alarmes](/kilo-docs-fr/kilo-iot-server/alarm.md).
* **Terminez le flux d’enregistrement commun** — informations de l’appareil, Metrics, Logs. Voir [Enregistrement des appareils](/kilo-docs-fr/kilo-iot-server/devices/registering-devices.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/emulated-devices.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.
