> 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/device-diagnostics.md).
# Diagnostics des appareils
Lisez l’état de réception d’un appareil, son pipeline et son flux d’événements pour comprendre pourquoi la télémétrie n’arrive pas.
La mise en service d’un capteur est le moment où un déploiement a le plus de chances de devenir silencieux. L’appareil est enregistré, le profil semble correct, la table de correspondance est remplie — et rien n’apparaît sur le tableau de bord. La question qui suit est toujours la même : le matériel est-il en veille, la radio est-elle hors de portée, la charge utile arrive-t-elle mais n’atterrit-elle nulle part, ou tout fonctionne-t-il et l’appareil n’a-t-il simplement pas encore atteint son prochain rapport programmé ?
Les diagnostics de l’appareil répondent directement à cette question. Au lieu de vous laisser déduire l’état de l’intégration à partir d’un graphique vide, la plateforme indique ce qu’elle a réellement vu de l’appareil — qu’un message soit parvenu au serveur, que les clés qu’il contient correspondent à vos capteurs, et que les valeurs obtenues aient été écrites dans l’historique. Chaque état non sain s’accompagne de l’élément précis à vérifier et d’un raccourci vers l’écran où vous pouvez le corriger.
## Pourquoi c’est important
Sans diagnostics, un appareil silencieux est indiscernable d’un appareil mal configuré. Un technicien qui met en service cinquante sondes de chaîne du froid dans un centre de distribution n’a aucun moyen de faire la différence entre une sonde hors de portée de la passerelle et une sonde qui transmet parfaitement vers une correspondance qui n’a jamais été finalisée. Les deux ressemblent à un tableau de bord vide, et dans les deux cas il faut se déplacer sur site.
Les diagnostics distinguent ces cas à la source. Une sonde qui a rejoint le réseau mais n’a envoyé aucune liaison montante est une question de radio ou de planification. Une sonde dont la charge utile se décode en clés qui n’ont jamais été mappées se corrige en deux minutes depuis votre bureau. Savoir lequel vous avez sous les yeux, c’est tout l’intérêt.
## Où le trouver
Ouvrez l’appareil et basculez vers l’onglet **Connexion** . Les diagnostics apparaissent à côté des paramètres de connexion, en trois blocs :
| Bloc | Ce à quoi il répond |
| --------------------- | ---------------------------------------------------------------------------------------- |
| **État de réception** | Les données arrivent-elles en ce moment, et sont-elles conservées ? |
| **Pipeline** | Sur la fenêtre récente, jusqu’où les messages sont-ils allés — routés, mappés, stockés ? |
| **Flux d’événements** | Message par message, que s’est-il passé et quand ? |
Lisez-les dans cet ordre. L’état de réception vous donne le verdict, le Pipeline vous donne le schéma, et le flux d’événements vous donne les preuves individuelles.
## État de réception
Le bloc d’état de réception réduit tout le chemin d’ingestion de l’appareil à un seul état, avec une courte ligne de détail en dessous. Un **RÉCEPTION** titre marque le bloc, et un indicateur **ACTIF** ou **AUCUNE DONNÉE** (affiché sous la forme **Actif** ou **Inactif** en version compacte) indique si le trafic circule actuellement.
Pendant le chargement du bloc, vous voyez **Chargement de l’état de réception…**. Si les données de diagnostic ne peuvent pas être récupérées, le bloc affiche **Diagnostics indisponibles** — l’appareil lui-même n’est pas affecté ; réessayez l’onglet.
### Les états et quoi faire pour chacun
| Statut | Ce que cela signifie | Votre prochaine étape |
| ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Réception et stockage** | L’état sain. La ligne de support indique `{{count}} capteurs mappés · dernière valeur {{last}}`. Les messages arrivent, les clés correspondent à vos capteurs, et les valeurs sont écrites dans l’historique. | Rien. Si la ligne indique aussi `{{count}} clés supplémentaires disponibles, non mappées`, l’appareil envoie des champs que vous n’avez pas encore mappés — utile à vérifier si vous voulez les voir dans les tableaux de bord. |
| **Envoi de données — configurez le mappage pour les conserver** | L’appareil transmet et sa charge utile se décode proprement — `{{count}} clés décodées · aucune mappée pour l’instant` — mais aucune clé n’est reliée à un capteur, donc rien n’est conservé. | Utilisez **Configurer le mappage** ou **Mapper une clé** pour ouvrir le mappage et relier au moins une clé entrante à un capteur. Les valeurs commencent à s’accumuler à partir du message suivant. |
| **Les données arrivent, mais rien n’est stocké** | *« Les données arrivent, mais rien n’est encore stocké. »* Les messages atteignent la plateforme, mais aucune valeur ne survit dans l’historique — généralement une lacune de mappage ou un décodeur qui produit des clés différentes de celles attendues par vos capteurs. | Cliquez sur **Corriger le mappage**. Comparez les clés du flux d’événements avec vos capteurs mappés. Si les clés semblent incorrectes plutôt que simplement non mappées, vérifiez le décodeur de charge utile dans cet onglet. |
| **N’a pas envoyé de rapport — l’appareil semble hors ligne** | *« L’appareil rapportait, puis est devenu silencieux. »* L’appareil fonctionnait auparavant et s’est arrêté. La ligne de support — `Attendu toutes les {{interval}} {{unit}} · dernière détection {{last}}` — vous indique le planning par rapport auquel la plateforme mesure. | C’est du terrain : vérifiez l’alimentation ou la batterie de l’appareil, confirmez qu’il est toujours à portée d’une passerelle, et assurez-vous que le planning d’envoi n’a pas changé. Si le vrai planning de l’appareil a changé, corrigez **Intervalle d’envoi des données** dans cet onglet afin qu’il ne soit pas signalé inutilement. |
| **En attente des premières données** / **En attente de la première liaison montante** / **Aucune liaison montante reçue pour l’instant** | L’enregistrement de l’appareil existe, mais la plateforme n’a encore jamais rien reçu de sa part. | Laissez-lui un intervalle de rapport pour transmettre. Si la fenêtre passe, passez en revue **À VÉRIFIER** ci-dessous — et si l’unité a déjà été utilisée sur un autre réseau, consultez [Avant toute arrivée : rejoindre le réseau](#before-anything-arrives-joining-the-network). |
| **Réseau atteint — en attente de données** | `A rejoint le réseau · aucune liaison montante pour l’instant`. Pour un appareil LoRaWAN, c’est une bonne nouvelle : les identifiants sont corrects et la liaison radio fonctionne. L’appareil n’a simplement pas encore envoyé de charge utile. | Attendez un intervalle de rapport. Si cela reste ainsi, l’appareil rejoint le réseau mais ne transmet pas — vérifiez son planning d’envoi et son état d’alimentation. |
Une autre ligne de support apparaît lorsqu’un appareil est configuré mais inactif : `{{count}} capteurs configurés · 0 valeurs reçues`. Vos capteurs existent, mais aucun n’est alimenté. Traitez cela comme *Les données arrivent, mais rien n’est stocké* — c’est le mappage qu’il faut regarder.
### Avant toute arrivée : rejoindre le réseau
Les états de réception ci-dessus décrivent un cycle de vie, et il vaut la peine de les lire dans l’ordre :
**En attente des premières données** → **Réseau atteint — en attente de données** → **Réception et stockage**
L’étape entre les deux premières est celle qui piège les gens, car elle se produit entièrement côté appareil et la plateforme ne peut qu’attendre.
Un appareil LPWAN ne se contente pas d’être « configuré » sur un réseau — il doit s’y **rejoindre** . Un appareil LoRaWAN envoie une **demande de jonction**, le serveur réseau la valide par rapport au DevEUI et à l’AppKey que vous avez enregistrés, puis répond par une acceptation de jonction. Ce n’est qu’alors que l’appareil dispose d’une session et commence à envoyer des liaisons montantes. Un point d’accès MIOTY fait l’équivalent : il **se connecte** via une station de base, ce qui fait passer la plateforme à *Réseau atteint — en attente de données*. Tant que cette poignée de main n’a pas eu lieu, un enregistrement d’appareil sur la plateforme n’est qu’un enregistrement — identifiants corrects et tout le reste.
**Un appareil n’appartient qu’à un seul réseau à la fois.** C’est la partie qui surprend les gens. Un appareil qui a déjà été mis en service ailleurs — une unité renvoyée d’un autre site, du matériel acheté d’occasion, un capteur qui était sur une autre plateforme ou le réseau d’un opérateur précédent, ou une unité de démonstration revenue d’un salon — reste associé à ce réseau. Il ne rejoindra pas le vôtre simplement parce que vous l’avez enregistré ici. Il ne cherche pas un nouveau réseau ; du point de vue de son micrologiciel, il en a déjà un.
Le symptôme est caractéristique : l’appareil reste sur **En attente des premières données** indéfiniment alors que tous les paramètres que vous pouvez vérifier sont corrects. Le DevEUI correspond. L’AppKey correspond. Il est alimenté, il est à portée et l’intervalle de rapport est passé plusieurs fois. Rien dans **À VÉRIFIER** ne résout le problème, car rien de tout cela n’est faux.
La solution consiste à **réinitialiser l’appareil** pour qu’il envoie une nouvelle demande de jonction. La procédure dépend du fabricant — passage d’un aimant, maintien d’un bouton, interrupteur Reed, cycle d’alimentation d’une durée précise, ou commande de liaison descendante — vérifiez donc les instructions du fournisseur pour votre modèle plutôt que de deviner. Certains appareils distinguent un simple redémarrage d’une jonction complète, et seule cette dernière efface la session précédente.
Une fois qu’il rejoint à nouveau le réseau, l’état passe à *Réseau atteint — en attente de données* puis à *Réception et stockage* à la prochaine transmission programmée de l’appareil.
Deux cas connexes à reconnaître :
* **Un appareil qui a rejoint le réseau une fois puis s’est arrêté** est un problème différent. Il s’agit de *N’a pas envoyé de rapport — l’appareil semble hors ligne*, et cela pointe vers l’alimentation, la portée ou le planning — pas vers la jonction. Un appareil ne se dé-joint pas en silence.
* **Un appareil qui revient sans cesse à *****En attente des premières données*** après une jonction réussie signifie généralement que les identifiants sur la plateforme et ceux inscrits dans l’appareil diffèrent d’une manière qui fait échouer la jonction sans bruit. Ressaisissez le DevEUI et l’AppKey — [Scanner le code QR](/kilo-docs-fr/kilo-iot-server/devices/registering-devices.md) supprime le risque de transcription — puis réinitialisez l’appareil une nouvelle fois.
### À VÉRIFIER et EN ATTENDANT
À côté d’un état non sain ou en attente, la plateforme liste les vérifications pertinentes sous un en-tête **À VÉRIFIER** , et — lorsque l’état est simplement trop tôt — la liste plus courte **EN ATTENDANT** . Les éléments que vous verrez incluent :
* Confirmer que l’appareil est sous tension et transmet
* Vérifier l’alimentation ou la batterie de l’appareil
* S’assurer qu’il est à portée d’une passerelle / Confirmer qu’il est toujours à portée d’une passerelle
* Vérifier que l’AppKey et le DevEUI correspondent à l’appareil
* Vérifier que le décodeur de charge utile correspond à cet appareil
* Vérifier que les paramètres de connexion sont corrects
* Confirmer que l’appareil envoie selon son planning
* S’assurer que le planning d’envoi n’a pas changé
* Laissez-lui un intervalle de rapport pour transmettre
* Mapper au moins une clé entrante à un capteur
La liste tient compte de l’état, il vaut donc mieux la lire que la survoler : un appareil qui a rejoint le réseau ne sera pas interrogé sur l’AppKey et le DevEUI, car cette question a déjà reçu une réponse.
Une chose que la liste ne peut pas vous dire, c’est si l’appareil est encore associé à un réseau sur lequel il était utilisé avant le vôtre — cela est invisible du côté de la plateforme. Si tout ici est correct et que l’appareil n’a toujours jamais rapporté, c’est le cas à suspecter : voir [Avant toute arrivée : rejoindre le réseau](#before-anything-arrives-joining-the-network).
Chaque élément pointe vers un paramètre que vous contrôlez. L’AppKey, le DevEUI, le décodeur de charge utile et les paramètres de connexion vivent tous sur cet **Connexion** onglet. Le planning d’envoi est défini sur l’appareil lui-même et répercuté dans **Intervalle d’envoi des données** — voir [Gestion des appareils](/kilo-docs-fr/kilo-iot-server/devices/device-management.md). Le mappage se trouve dans l’onglet **Métriques** , et les actions **Corriger**, **Corriger le mappage**, **Configurer le mappage**, et **Mapper une clé** vous y conduisent directement.
### Appareils MQTT
Les intégrations MQTT ont leurs propres états de réception, car deux liens doivent être vérifiés — la connexion de la plateforme à votre broker, et le comportement de publication de l’appareil dessus. Deux champs cadrent le diagnostic : **Sujet attendu** indique le sujet pour lequel l’enregistrement de l’appareil est configuré, et **Publié vers** indique le sujet sur lequel un message est réellement arrivé.
| Ce que vous voyez | Ce que cela signifie | Votre prochaine étape |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Broker connecté** — *« Votre broker est joignable et Kilo est abonné »* | Le côté connecteur est sain. | Passez au côté appareil. |
| **Connexion à votre broker…** | L’abonnement est en cours d’établissement. | Patientez un instant. Si cela persiste, vérifiez les paramètres du connecteur. |
| **Kilo ne peut pas atteindre votre broker** — *« Vérifiez l’URL du broker et les identifiants dans les paramètres du connecteur. »* | La plateforme ne peut pas établir l’abonnement, donc aucun appareil sur ce connecteur ne peut envoyer de données. | Ouvrez le connecteur et corrigez l’URL du broker et les identifiants. Voir [Dépannage MQTT](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md). |
| **En attente que l’appareil publie vers le broker Kilo…** | L’abonnement est actif ; cet appareil n’a pas encore publié. | Attendez un intervalle de rapport, puis vérifiez que l’appareil fonctionne et qu’il pointe vers le bon broker. |
| **Un message est arrivé sur un sujet pour lequel cet appareil n’est pas configuré** — *« Mettez à jour le sujet ci-dessus, ou modifiez l’endroit où l’appareil publie. »* | Une publication a atteint la plateforme mais son sujet ne correspond pas à cet enregistrement d’appareil. Comparez **Publié vers** avec **Sujet attendu**. | Corrigez le sujet dans cet onglet pour qu’il corresponde à ce que l’appareil publie réellement, ou reconfigurez l’appareil pour publier vers le sujet attendu. |
| **Aucun sujet de publication n’est encore configuré — définissez-en un ci-dessus.** | L’enregistrement de l’appareil n’a aucun sujet avec lequel faire la correspondance. | Définissez le sujet de publication dans cet onglet. |
Lorsque l’appareil publie correctement, le bloc confirme les conditions qui devaient être réunies pour que le message aboutisse : *« L’appareil publie vers le sujet attendu »*, *« La charge utile est un JSON valide »*, *« L’ID de l’appareil se résout comme configuré »*, et — pour les appareils utilisant des identifiants fournis par la plateforme — *« Il est connecté avec ses identifiants MQTT générés »*.
## Pipeline
Le bloc Pipeline compte jusqu’où les messages sont allés sur la période récente, répartis en **Routés**, **Mappés**, et **Stockés**.
Ces comptes correspondent à une fenêtre récente glissante, pas à un total cumulatif. La fenêtre est indiquée dans le libellé du bloc lui-même — **Statistiques sur les {{days}} derniers jours** — alors lisez ce libellé avant de tirer des conclusions. Un appareil mal configuré le trimestre dernier et corrigé la semaine dernière affichera ici des comptes propres ; la fenêtre est passée au-delà de l’incident.
Lisez les trois nombres comme un entonnoir :
* **Routés élevés, Mappés à zéro** — les messages arrivent et sont associés à cet appareil, mais aucune clé n’est reliée à un capteur. Le mappage est la solution.
* **Mappés élevés, Stockés à zéro** — les clés correspondent, mais les valeurs ne persistent pas. Vérifiez les lignes de mappage et les types de capteurs vers lesquels elles pointent.
* **Tous les trois à zéro** — rien n’a du tout atteint cet enregistrement d’appareil. C’est un problème de réception, pas de mappage ; revenez au bloc d’état de réception.
* **Les trois évoluent ensemble** — l’intégration est saine.
Si le bloc indique **Aucune donnée de pipeline**, la plateforme n’a rien à compter pour cet appareil dans la fenêtre actuelle — la même conclusion que si les trois étaient à zéro.
## Flux d’événements
Le flux d’événements est l’enregistrement message par message qui se cache derrière le résumé. Là où les comptes du pipeline vous disent *à quelle fréquence*, le flux vous dit *quel message, quand et pourquoi*.
| Colonne | Ce qu’il affiche |
| ------------ | ----------------------------------------------------------------- |
| **Heure** | Moment où la plateforme a traité l’événement |
| **Étape** | Quelle étape du pipeline la ligne décrit — Routé, Mappé ou Stocké |
| **Résultat** | Si cette étape a réussi — OK, Ignoré ou Erreur |
| **Détail** | Les précisions pour cette étape |
Avant que des données n’existent, vous voyez **Aucun événement pour le moment** et *« Les événements apparaîtront ici une fois que l’appareil enverra des données. »* — attendu pour un appareil qui n’a pas transmis.
Le flux se charge par pages. Cliquez sur **Charger plus** pour récupérer la page suivante ; cela affiche **Chargement…** pendant la récupération et **Tous les enregistrements sont chargés** une fois que vous avez atteint la fin de l’historique disponible. Les lignes individuelles offrent **Détails** pour développer le contexte complet d’un événement et **Masquer** pour le replier à nouveau. **Voir l’état de réception** vous ramène au bloc récapitulatif en haut.
### Ce que signifient ces états
Le flux inclut sa propre légende sous l’en-tête **Ce que signifient ces états**:
| Terme | Signification |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Routés** | Le message est arrivé à la plateforme et a été associé à cet appareil. |
| **Mappés** | Les clés entrantes ont été associées à vos capteurs configurés. |
| **Stockés** | Les valeurs des capteurs ont été enregistrées dans l’historique. |
| **OK** | Cette étape s’est terminée avec succès. |
| **Ignoré** | Non traité intentionnellement (par exemple, aucun mappage correspondant ou un sujet inattendu). Pas nécessairement une erreur. |
| **Erreur** | Cette étape a échoué et nécessite une attention. |
**Ignoré est la ligne qui induit les gens en erreur.** Ce n’est pas un échec — c’est la plateforme qui vous indique qu’elle a pris une décision délibérée. Une `Mappé / Ignoré` ligne signifie qu’une clé est arrivée et qu’aucun capteur ne la revendique ; si cette clé compte pour vous, mappez-la. Si ce n’est pas le cas, la ligne est un comportement correct et vous pouvez l’ignorer. Une ligne `Erreur` est l’inverse : quelque chose s’est cassé et le message n’a pas terminé son étape. Dépliez-la avec **Détails** et agissez selon ce qu’elle indique.
## Lire le flux pour corriger un appareil
Une séquence pratique lorsqu’un appareil ne fournit pas de données :
1. Ouvrez l’appareil et allez à l’ **Connexion** onglet.
2. Lisez l’état de réception. S’il nomme un problème précis — clés non mappées, sujet inattendu, broker injoignable — utilisez le bouton d’action à côté (**Corriger**, **Corriger le mappage**, **Configurer le mappage**, **Mapper une clé**) et corrigez-le là.
3. Si l’état indique que l’appareil attend ou est silencieux, vérifiez la ligne de support pour l’intervalle et l’heure de dernière vue, puis passez en revue **À VÉRIFIER**.
4. Regardez les comptes du Pipeline pour voir où, dans l’entonnoir, les messages s’arrêtent, en gardant la fenêtre du **Statistiques sur les {{days}} derniers jours** libellé à l’esprit.
5. Ouvrez le flux d’événements et trouvez les lignes les plus récentes à cette étape. Dépliez une ligne avec **Détails** pour voir exactement quelle clé ou quel sujet était impliqué.
6. Appliquez la correction, puis attendez un intervalle de rapport et relisez le bloc. Les valeurs sont stockées à partir du prochain message éligible — les messages antérieurs ne sont pas retraités, donc une nouvelle transmission est ce qui confirme la réparation.
Les clés du connecteur apparaissent automatiquement dans le mappage une fois que l’appareil transmet — vous n’avez pas besoin de les saisir. C’est pourquoi l’ordre compte : faites d’abord transmettre l’appareil, puis mappez ce qui est réellement arrivé.
## diagnostics du connecteur
Les diagnostics existent aussi à un niveau supérieur. Ouvrez un connecteur et vous trouverez une **diagnostics du connecteur** zone couvrant chaque appareil qui y est rattaché, avec un **État de la source** résumé et deux onglets :
* **Entrant** — ce qui arrive sur le connecteur, avec un indicateur `{{count}} vus` .
* **Activité** — l’historique récent des événements du connecteur. Avant tout trafic, il affiche **Aucune activité pour le moment**. Si les données de diagnostic ne peuvent pas être chargées, il affiche **Diagnostics indisponibles**.
A **Connecter l’appareil** l’action vous permet d’enregistrer ici un appareil sur le connecteur.
Utilisez les diagnostics du connecteur lorsque *plusieurs* appareils sont silencieux en même temps — ce schéma pointe généralement vers le connecteur ou le broker, pas vers le matériel. Utilisez les diagnostics de l’appareil lorsqu’un seul appareil est silencieux alors que ses voisins fonctionnent. Les diagnostics du connecteur sont limités aux connecteurs MQTT ; les autres types de connecteurs n’affichent que leurs paramètres.
Pour les problèmes côté broker, TLS, authentification et routage des sujets, voir [Dépannage MQTT](/kilo-docs-fr/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md).
## Conseils
* **Définissez honnêtement l’intervalle d’envoi des données.** Les diagnostics mesurent le « silence » par rapport à l’intervalle que vous avez saisi. Une sonde qui rapporte une fois par jour mais qui est configurée à l’heure sera signalée hors ligne vingt-trois fois par jour, et un capteur réellement mort configuré au mois restera vert pendant des semaines.
* **Vérifiez l’état de réception avant d’ouvrir un ticket.** *Envoi de données — configurez le mappage pour les conserver* est une correction de bureau. *N’a pas envoyé de rapport — l’appareil semble hors ligne* est une visite sur site. La distinction vaut bien trente secondes.
* **Surveillez la fenêtre du pipeline pendant la mise en service.** Les comptes couvrent les jours nommés dans le **Statistiques sur les {{days}} derniers jours** libellé, donc un appareil corrigé il y a une heure conserve encore ses messages échoués dans le compte. Jugez une correction récente à partir des lignes les plus récentes du flux d’événements, pas à partir des totaux.
* **Les clés non mappées sont une opportunité, pas une erreur.** Lorsqu’un appareil sain rapporte `{{count}} clés supplémentaires disponibles, non mappées`, le matériel envoie des mesures que vous n’utilisez pas encore — un capteur de vibrations peut aussi transmettre la température, sans coût supplémentaire en batterie ni en temps de diffusion.
* **Les diagnostics complètent l’onglet Journaux, ils ne le remplacent pas.** Les diagnostics expliquent *pourquoi* pourquoi le traitement s’est déroulé ainsi. L’onglet Journaux affiche les relevés bruts eux-mêmes. Voir [Gestion des appareils](/kilo-docs-fr/kilo-iot-server/devices/device-management.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/device-diagnostics.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.
