> 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-de/kilo-iot-server/devices/device-diagnostics.md).
# Gerätediagnose
Lesen Sie Empfangsstatus, Pipeline und Ereignis-Feed eines Geräts, um herauszufinden, warum Telemetriedaten nicht ankommen.
Die Inbetriebnahme eines Sensors ist der Moment, in dem ein Rollout am ehesten still wird. Das Gerät ist registriert, das Profil sieht richtig aus, die Zuordnungstabelle ist ausgefüllt – und auf dem Dashboard erscheint nichts. Die anschließende Frage ist immer dieselbe: schläft die Hardware, ist das Funknetz außer Reichweite, kommt die Nutzlast an, landet aber nirgendwo, oder funktioniert alles und das Gerät hat einfach noch nicht seinen nächsten geplanten Bericht erreicht?
Die Gerätediagnose beantwortet diese Frage direkt. Anstatt Sie den Zustand der Integration aus einem leeren Diagramm ableiten zu lassen, meldet die Plattform, was sie tatsächlich vom Gerät gesehen hat – ob eine Nachricht den Server erreicht hat, ob die darin enthaltenen Schlüssel zu Ihren Sensoren passten und ob die daraus resultierenden Werte in der Historie gespeichert wurden. Jeder ungesunde Zustand wird mit dem konkreten Punkt zum Prüfen und einem Direktlink zu der Oberfläche geliefert, auf der Sie ihn beheben.
## Warum das wichtig ist
Ohne Diagnose ist ein stilles Gerät von einem falsch konfigurierten nicht zu unterscheiden. Ein Ingenieur, der fünfzig Kühlketten-Sonden in einem Verteilzentrum in Betrieb nimmt, kann nicht erkennen, ob eine Sonde außer Reichweite eines Gateways ist oder ob eine Sonde perfekt sendet, aber in eine nie abgeschlossene Zuordnung schreibt. Beides sieht aus wie ein leeres Dashboard, und beides kostet einen Vor-Ort-Termin.
Die Diagnose trennt diese Fälle an der Quelle. Eine Sonde, die dem Netzwerk beigetreten ist, aber keine Uplinks gesendet hat, ist eine Funk- oder Zeitplanfrage. Eine Sonde, deren Nutzlast in Schlüssel entschlüsselt wird, die nie zugeordnet wurden, ist eine Zwei-Minuten-Korrektur vom Schreibtisch aus. Zu wissen, welchen Fall Sie vor sich haben, ist der ganze Punkt.
## Wo Sie es finden
Öffnen Sie das Gerät und wechseln Sie zur **Verbindung** Registerkarte. Die Diagnose erscheint neben den Verbindungseinstellungen in drei Blöcken:
| Block | Was es beantwortet |
| ------------------ | ------------------------------------------------------------------------------------------------- |
| **Empfangsstatus** | Kommt gerade Daten an, und werden sie gespeichert? |
| **Pipeline** | Wie weit sind Nachrichten im letzten Zeitraum gekommen – weitergeleitet, zugeordnet, gespeichert? |
| **Ereignis-Feed** | Nachricht für Nachricht: Was ist wann passiert? |
Lesen Sie sie in genau dieser Reihenfolge. Der Empfangsstatus liefert das Urteil, die Pipeline das Muster und der Ereignis-Feed die einzelnen Belege.
## Empfangsstatus
Der Block mit dem Empfangsstatus fasst den gesamten Ingest-Pfad des Geräts zu einem Zustand zusammen, mit einer kurzen unterstützenden Zeile darunter. Eine **EMPFANG** Überschrift kennzeichnet den Block, und ein **LIVE** oder **KEINE DATEN** Indikator (in kompakter Form als **Live** oder **Inaktiv** angezeigt) zeigt, ob gerade Verkehr fließt.
Während der Block geladen wird, sehen Sie **Empfangsstatus wird geladen…**. Wenn die Diagnosedaten nicht abgerufen werden können, steht im Block **Diagnose nicht verfügbar** — das Gerät selbst ist davon nicht betroffen; versuchen Sie die Registerkarte erneut.
### Die Zustände und was Sie jeweils tun sollten
| Status | Was das bedeutet | Ihr nächster Schritt |
| ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Empfangen & speichern** | Der gesunde Zustand. Die unterstützende Zeile lautet `{{count}} Sensoren zugeordnet · letzter Wert {{last}}`. Nachrichten kommen an, Schlüssel passen zu Ihren Sensoren, und Werte werden in die Historie geschrieben. | Nichts. Wenn die Zeile außerdem sagt `{{count}} weitere Schlüssel verfügbar, nicht zugeordnet`, sendet das Gerät Felder, die Sie noch nicht zugeordnet haben – das ist überprüfenswert, wenn Sie sie in Dashboards sehen wollen. |
| **Daten werden gesendet — Zuordnung einrichten, damit sie gespeichert werden** | Das Gerät sendet, und seine Nutzlast wird sauber entschlüsselt — `{{count}} Schlüssel entschlüsselt · noch keiner zugeordnet` — aber kein Schlüssel ist einem Sensor zugeordnet, daher wird nichts gespeichert. | Verwenden Sie **Zuordnung einrichten** oder **Einen Schlüssel zuordnen** um die Zuordnung zu öffnen und mindestens einen eingehenden Schlüssel mit einem Sensor zu verknüpfen. Werte werden ab der nächsten Nachricht gesammelt. |
| **Daten kommen an, aber nichts wird gespeichert** | *„Daten kommen an, aber bisher wird nichts gespeichert.“* Nachrichten erreichen die Plattform, aber kein Wert gelangt in die Historie – meist eine Lücke in der Zuordnung oder ein Decoder, der andere Schlüssel erzeugt als die, die Ihre Sensoren erwarten. | Klicken Sie auf **Zuordnung beheben**. Vergleichen Sie die Schlüssel im Ereignis-Feed mit Ihren zugeordneten Sensoren. Wenn die Schlüssel eher falsch als nur nicht zugeordnet aussehen, prüfen Sie den Payload-Decoder auf dieser Registerkarte. |
| **Hat nicht gemeldet — Gerät wirkt offline** | *„Das Gerät hat berichtet, ist aber still geworden.“* Das Gerät hat vorher funktioniert und aufgehört. Die unterstützende Zeile — `Erwartet alle {{interval}} {{unit}} · zuletzt gesehen {{last}}` — zeigt Ihnen den Zeitplan, mit dem die Plattform vergleicht. | Das ist Feldarbeit: Prüfen Sie die Stromversorgung oder den Akku des Geräts, bestätigen Sie, dass es sich noch in Reichweite eines Gateways befindet, und stellen Sie sicher, dass sich der Sendetakt nicht geändert hat. Wenn sich der echte Takt des Geräts geändert hat, korrigieren Sie **Daten-Sendeintervall** auf dieser Registerkarte, damit es nicht unnötig markiert wird. |
| **Warten auf die ersten Daten** / **Warten auf den ersten Uplink** / **Noch keine Uplinks empfangen** | Der Geräterecord existiert, aber die Plattform hat noch nie etwas von ihm empfangen. | Geben Sie ihm ein Reporting-Intervall Zeit zum Senden. Wenn das Fenster vergeht, arbeiten Sie die Punkte unter **WAS ZU PRÜFEN IST** unten durch — und wenn das Gerät jemals in einem anderen Netzwerk verwendet wurde, sehen Sie [Bevor etwas ankommt: dem Netzwerk beitreten](#before-anything-arrives-joining-the-network). |
| **Netzwerk erreicht — warten auf Daten** | `Dem Netzwerk beigetreten · noch keine Uplinks`. Bei einem LoRaWAN-Gerät sind das gute Nachrichten: Die Zugangsdaten stimmen und die Funkverbindung funktioniert. Das Gerät hat einfach noch keine Nutzlast gesendet. | Warten Sie ein Reporting-Intervall ab. Wenn es hier bleibt, tritt das Gerät zwar bei, sendet aber nicht — prüfen Sie den Sendeplan und den Stromzustand. |
Wenn ein Gerät konfiguriert, aber inaktiv ist, erscheint noch eine weitere unterstützende Zeile: `{{count}} Sensoren konfiguriert · 0 empfangen Werte`. Ihre Sensoren existieren, aber keiner von ihnen wird versorgt. Behandeln Sie es genauso wie *Daten kommen an, aber nichts wird gespeichert* — an der Zuordnung liegt es.
### Bevor etwas ankommt: dem Netzwerk beitreten
Die Empfangszustände oben beschreiben einen Lebenszyklus, und es lohnt sich, sie der Reihe nach zu lesen:
**Warten auf die ersten Daten** → **Netzwerk erreicht — warten auf Daten** → **Empfangen & speichern**
Der Schritt zwischen den ersten beiden ist der, der Menschen aus dem Konzept bringt, weil er vollständig auf der Geräteseite passiert und die Plattform nur darauf warten kann.
Ein LPWAN-Gerät ist nicht einfach nur „konfiguriert“ in einem Netzwerk – es muss **beitreten** einem. Ein LoRaWAN-Gerät sendet eine **Beitrittsanfrage**, der Netzwerkserver prüft sie gegen die registrierte DevEUI und AppKey und antwortet mit einem Join Accept. Erst dann hat das Gerät eine Sitzung und beginnt, Uplinks zu senden. Ein MIOTY-Endpunkt tut das Entsprechende: Er **verbindet sich** über eine Basisstation, wodurch die Plattform zu *Netzwerk erreicht — warten auf Daten*wechselt. Bis dieser Handshake stattfindet, ist ein Geräteeintrag auf der Plattform nur ein Eintrag – inklusive korrekter Zugangsdaten.
**Ein Gerät gehört immer nur zu einem Netzwerk gleichzeitig.** Das ist der Teil, der viele überrascht. Ein Gerät, das zuvor irgendwo anders in Betrieb genommen wurde – ein von einer anderen Baustelle zurückgekehrtes Gerät, gebraucht gekauftes Hardware, ein Sensor, der auf einer anderen Plattform oder im Netzwerk eines früheren Betreibers war, oder ein Demo-Gerät, das vom Messestand zurückkam – ist weiterhin mit diesem Netzwerk verbunden. Es tritt nicht einfach Ihrem bei, nur weil Sie es hier registriert haben. Es sucht nicht nach einem neuen Netzwerk; aus Sicht seiner Firmware hat es bereits eines.
Das Symptom ist eindeutig: Das Gerät bleibt auf **Warten auf die ersten Daten** unbegrenzt stehen, während jede überprüfbare Einstellung korrekt ist. Die DevEUI stimmt. Die AppKey stimmt. Es ist mit Strom versorgt, in Reichweite, und das Reporting-Intervall ist mehrfach verstrichen. Nichts in **WAS ZU PRÜFEN IST** behebt das, weil nichts davon falsch ist.
Die Lösung ist, **das Gerät zurückzusetzen** damit es eine neue Beitrittsanfrage sendet. Das Vorgehen ist herstellerspezifisch – ein Magnetwisch, gedrückt halten eines Knopfs, ein Reed-Schalter, ein Power-Cycle mit bestimmter Länge oder ein Downlink-Befehl – prüfen Sie also die Anleitung des Herstellers für Ihr Modell, statt zu raten. Manche Geräte unterscheiden zwischen einem einfachen Neustart und einem vollständigen erneuten Beitritt, und nur Letzterer löscht die vorherige Sitzung.
Sobald es erneut beitritt, wechselt der Status zu *Netzwerk erreicht — warten auf Daten* und dann zu *Empfangen & speichern* bei der nächsten geplanten Übertragung des Geräts.
Zwei verwandte Fälle, die man erkennen sollte:
* **Ein Gerät, das einmal beigetreten ist und dann aufgehört hat** ist ein anderes Problem. Das ist *Hat nicht gemeldet — Gerät wirkt offline*, und es weist auf Stromversorgung, Reichweite oder Zeitplan hin – nicht auf den Beitritt. Ein Gerät tritt nicht lautlos aus.
* **Ein Gerät, das immer wieder zu *****Warten auf die ersten Daten*** zurückkehrt, obwohl der Beitritt erfolgreich war, bedeutet meist, dass die Zugangsdaten auf der Plattform und die im Gerät gespeicherten Zugangsdaten sich in einer Weise unterscheiden, die den Beitritt still scheitern lässt. DevEUI und AppKey erneut eingeben – [QR-Code scannen](/kilo-docs-de/kilo-iot-server/devices/registering-devices.md) verringert das Risiko von Übertragungsfehlern – und das Gerät erneut zurücksetzen.
### WAS ZU PRÜFEN IST und WÄHREND SIE WARTEN
Neben einem ungesunden oder ausstehenden Zustand listet die Plattform die relevanten Prüfungen unter einer **WAS ZU PRÜFEN IST** Überschrift auf, und – wenn der Zustand einfach noch früh ist – die kürzere **WÄHREND SIE WARTEN** Liste. Zu den Einträgen, die Sie sehen werden, gehören:
* Bestätigen Sie, dass das Gerät eingeschaltet ist und sendet
* Prüfen Sie die Stromversorgung oder den Akku des Geräts
* Stellen Sie sicher, dass es sich in Reichweite eines Gateways befindet / Bestätigen Sie, dass es sich noch in Reichweite eines Gateways befindet
* Prüfen Sie, ob AppKey und DevEUI mit dem Gerät übereinstimmen
* Prüfen Sie, ob der Payload-Decoder zu diesem Gerät passt
* Prüfen Sie, ob die Verbindungseinstellungen korrekt sind
* Bestätigen Sie, dass das Gerät nach seinem Zeitplan sendet
* Stellen Sie sicher, dass sich der Sendeplan nicht geändert hat
* Geben Sie ihm ein Reporting-Intervall Zeit zum Senden
* Ordnen Sie mindestens einen eingehenden Schlüssel einem Sensor zu
Die Liste ist zustandsbewusst, daher lohnt es sich, sie zu lesen statt nur zu überfliegen: Ein Gerät, das dem Netzwerk beigetreten ist, wird nicht nach AppKey und DevEUI gefragt, weil diese Frage bereits beantwortet ist.
Was die Liste nicht sagen kann, ist, ob das Gerät noch mit einem Netzwerk verbunden ist, in dem es vor Ihrem verwendet wurde — das ist von der Plattformseite aus unsichtbar. Wenn hier alles passt und das Gerät trotzdem noch nie berichtet hat, ist das der Verdachtsfall: siehe [Bevor etwas ankommt: dem Netzwerk beitreten](#before-anything-arrives-joining-the-network).
Jeder Eintrag verweist auf eine Einstellung, die Sie kontrollieren. AppKey, DevEUI, der Payload-Decoder und die Verbindungseinstellungen liegen alle auf derselben **Verbindung** Registerkarte. Der Sendeplan wird direkt am Gerät festgelegt und in **Daten-Sendeintervall** gespiegelt — siehe [Geräteverwaltung](/kilo-docs-de/kilo-iot-server/devices/device-management.md). Die Zuordnung liegt auf der **Metriken** Registerkarte, und die **Beheben**, **Zuordnung beheben**, **Zuordnung einrichten**, und **Einen Schlüssel zuordnen** Aktionen führen Sie direkt dorthin.
### MQTT-Geräte
MQTT-Integrationen haben ihre eigenen Empfangszustände, weil zwei Verbindungen zu prüfen sind – die Verbindung der Plattform zu Ihrem Broker und das Veröffentlichungsverhalten des Geräts darauf. Zwei Felder rahmen die Diagnose ein: **Erwartetes Topic** zeigt das Topic, für das der Geräterecord konfiguriert ist, und **Veröffentlicht auf** zeigt das Topic, auf dem eine Nachricht tatsächlich angekommen ist.
| Was Sie sehen | Was das bedeutet | Ihr nächster Schritt |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Broker verbunden** — *„Ihr Broker ist erreichbar und Kilo ist abonniert“* | Die Connector-Seite ist gesund. | Gehen Sie zur Geräteseite weiter. |
| **Verbindung zu Ihrem Broker wird hergestellt…** | Das Abonnement wird eingerichtet. | Geben Sie ihm einen Moment. Wenn es bestehen bleibt, überprüfen Sie die Connector-Einstellungen. |
| **Kilo kann Ihren Broker nicht erreichen** — *„Prüfen Sie die Broker-URL und die Zugangsdaten in den Connector-Einstellungen.“* | Die Plattform kann das Abonnement nicht herstellen, daher kann kein Gerät an diesem Connector Daten liefern. | Öffnen Sie den Connector und korrigieren Sie die Broker-URL und die Zugangsdaten. Siehe [MQTT-Fehlerbehebung](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md). |
| **Warten darauf, dass das Gerät an den Kilo-Broker veröffentlicht…** | Das Abonnement ist aktiv; dieses Gerät hat noch nicht veröffentlicht. | Warten Sie ein Reporting-Intervall ab und bestätigen Sie dann, dass das Gerät läuft und auf den richtigen Broker zeigt. |
| **Eine Nachricht kam auf einem Topic an, für das dieses Gerät nicht eingerichtet ist** — *„Aktualisieren Sie das Topic oben oder ändern Sie, wohin das Gerät veröffentlicht.“* | Eine Veröffentlichung erreichte die Plattform, aber ihr Topic stimmt nicht mit diesem Geräterecord überein. Vergleichen Sie **Veröffentlicht auf** mit **Erwartetes Topic**. | Korrigieren Sie das Topic auf dieser Registerkarte so, dass es mit dem übereinstimmt, was das Gerät tatsächlich veröffentlicht, oder konfigurieren Sie das Gerät so, dass es auf das erwartete Topic veröffentlicht. |
| **Es ist noch kein Publish-Topic konfiguriert — legen Sie oben eines fest.** | Der Geräterecord hat kein Topic, mit dem verglichen werden kann. | Legen Sie das Publish-Topic auf dieser Registerkarte fest. |
Wenn das Gerät korrekt veröffentlicht, bestätigt der Block die Bedingungen, die erfüllt sein mussten, damit die Nachricht ankommt: *„Das Gerät veröffentlicht auf dem erwarteten Topic“*, *„Die Nutzlast ist gültiges JSON“*, *„Die Geräte-ID wird wie konfiguriert aufgelöst“*, und – für Geräte mit von der Plattform ausgestellten Zugangsdaten – *„Es ist mit den generierten MQTT-Zugangsdaten verbunden“*.
## Pipeline
Der Pipeline-Block zählt, wie weit Nachrichten im letzten Zeitraum gekommen sind, aufgeteilt in **Weitergeleitet**, **Zugeordnet**, und **Gespeichert**.
Diese Zählwerte beziehen sich auf ein rollierendes, aktuelles Zeitfenster, nicht auf eine Lebenszeitsumme. Das Fenster ist in der eigenen Bezeichnung des Blocks angegeben – **Statistik über die letzten {{days}} Tage** — lesen Sie also diese Bezeichnung, bevor Sie Schlüsse ziehen. Ein Gerät, das im letzten Quartal falsch konfiguriert und letzte Woche korrigiert wurde, zeigt hier saubere Werte; das Fenster liegt inzwischen nach dem Vorfall.
Lesen Sie die drei Zahlen als Trichter:
* **Weitergeleitet hoch, Zuordnung null** — Nachrichten kommen an und werden diesem Gerät zugeordnet, aber kein Schlüssel ist mit einem Sensor verbunden. Die Zuordnung ist die Lösung.
* **Zugeordnet hoch, Gespeichert null** — Schlüssel passten, aber Werte wurden nicht dauerhaft gespeichert. Prüfen Sie die Zuordnungszeilen und die Sensortypen, auf die sie zeigen.
* **Alle drei null** — es ist überhaupt nichts bei diesem Geräterecord angekommen. Das ist ein Empfangsproblem, kein Zuordnungsproblem; gehen Sie zurück zum Block mit dem Empfangsstatus.
* **Alle drei gemeinsam ansteigend** — die Integration ist gesund.
Wenn der Block lautet **Keine Pipeline-Daten**, hat die Plattform im aktuellen Fenster nichts für dieses Gerät zu zählen — dieselbe Schlussfolgerung wie bei allen drei Werten auf null.
## Ereignis-Feed
Der Ereignis-Feed ist der Nachricht-für-Nachricht-Datensatz hinter der Zusammenfassung. Während die Pipeline-Zählwerte Ihnen sagen *wie oft*sagt der Feed Ihnen *welche Nachricht, wann und warum*.
| Spalte | Was sie anzeigt |
| ------------ | ----------------------------------------------------------------------------------------------- |
| **Zeit** | Wann die Plattform das Ereignis verarbeitet hat |
| **Phase** | Welcher Schritt der Pipeline die Zeile beschreibt — Weitergeleitet, Zugeordnet oder Gespeichert |
| **Ergebnis** | Ob dieser Schritt erfolgreich war — OK, Übersprungen oder Fehler |
| **Detail** | Die Einzelheiten für diesen Schritt |
Bevor Daten existieren, sehen Sie **Noch keine Ereignisse** und *„Hier werden Ereignisse erscheinen, sobald das Gerät Daten sendet.“* — zu erwarten für ein Gerät, das noch nicht gesendet hat.
Der Feed wird seitenweise geladen. Klicken Sie **Mehr laden** um die nächste Seite abzurufen; angezeigt wird **Wird geladen…** während des Abrufs und **Alle Datensätze geladen** sobald Sie das Ende der verfügbaren Historie erreicht haben. Einzelne Zeilen bieten **Details** um den vollständigen Kontext eines Ereignisses aufzuklappen, und **Ausblenden** um es wieder zusammenzuklappen. **Empfangsstatus anzeigen** führt Sie zurück zum Zusammenfassungsblock oben.
### Was diese Zustände bedeuten
Der Feed enthält seine eigene Legende unter der Überschrift **Was diese Zustände bedeuten**:
| Begriff | Bedeutung |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| **Weitergeleitet** | Die Nachricht erreichte die Plattform und wurde diesem Gerät zugeordnet. |
| **Zugeordnet** | Eingehende Schlüssel wurden Ihren konfigurierten Sensoren zugeordnet. |
| **Gespeichert** | Sensorwerte wurden in der Historie gespeichert. |
| **OK** | Dieser Schritt wurde erfolgreich abgeschlossen. |
| **Übersprungen** | Absichtlich nicht verarbeitet (z. B. keine passende Zuordnung oder ein unerwartetes Topic). Nicht unbedingt ein Fehler. |
| **Fehler** | Dieser Schritt ist fehlgeschlagen und muss beachtet werden. |
**Übersprungen ist die Zeile, die Menschen in die Irre führt.** Es ist kein Fehler – die Plattform teilt Ihnen mit, dass sie eine bewusste Entscheidung getroffen hat. Eine `Zuordnung / Übersprungen` Zeile bedeutet, dass ein Schlüssel angekommen ist, den kein Sensor beansprucht; wenn dieser Schlüssel für Sie wichtig ist, ordnen Sie ihn zu. Wenn nicht, ist die Zeile korrektes Verhalten und Sie können sie ignorieren. Eine `Fehler` Zeile ist das Gegenteil: Etwas ist kaputtgegangen und die Nachricht hat ihren Schritt nicht abgeschlossen. Klappen Sie sie mit **Details** auf und reagieren Sie auf das, was gemeldet wird.
## Den Feed lesen, um ein Gerät zu reparieren
Eine praktische Reihenfolge, wenn ein Gerät keine Daten liefert:
1. Öffnen Sie das Gerät und gehen Sie zur **Verbindung** Registerkarte zu wechseln.
2. Lesen Sie den Empfangsstatus. Wenn dort ein konkretes Problem genannt wird – nicht zugeordnete Schlüssel, ein unerwartetes Topic, ein nicht erreichbarer Broker – verwenden Sie die Schaltfläche daneben (**Beheben**, **Zuordnung beheben**, **Zuordnung einrichten**, **Einen Schlüssel zuordnen**) und beheben Sie es dort.
3. Wenn der Status sagt, dass das Gerät wartet oder still ist, prüfen Sie die unterstützende Zeile für das Intervall und die zuletzt gesehene Zeit und arbeiten Sie dann **WAS ZU PRÜFEN IST**.
4. Sehen Sie sich die Pipeline-Zahlen an, um zu erkennen, wo im Trichter Nachrichten hängen bleiben, und behalten Sie das Fenster in der **Statistik über die letzten {{days}} Tage** Bezeichnung im Kopf.
5. Öffnen Sie den Ereignis-Feed und suchen Sie die neuesten Zeilen in dieser Phase. Klappen Sie eine Zeile mit **Details** auf, um genau zu sehen, welcher Schlüssel oder welches Topic beteiligt war.
6. Wenden Sie die Korrektur an, warten Sie dann ein Reporting-Intervall und lesen Sie den Block erneut. Werte werden ab der nächsten qualifizierenden Nachricht gespeichert – frühere Nachrichten werden nicht erneut verarbeitet, daher bestätigt eine frische Übertragung die Reparatur.
Connector-Schlüssel erscheinen in der Zuordnung automatisch, sobald das Gerät sendet – Sie müssen sie nicht eintippen. Deshalb ist die Reihenfolge wichtig: Erst das Gerät zum Senden bringen, dann das zuordnen, was tatsächlich angekommen ist.
## Connector-Diagnose
Eine Diagnose gibt es auch auf der nächsten Ebene. Öffnen Sie einen Connector, und Sie finden einen **Connector-Diagnose** Bereich, der jedes Gerät darauf abdeckt, mit einer **Source-Health** Zusammenfassung und zwei Registerkarten:
* **Eingehend** — was am Connector ankommt, mit einer `{{count}} gesehen` Zahl.
* **Aktivität** — die jüngste Ereignishistorie des Connectors. Vor jedem Verkehr steht dort **Noch keine Aktivität**. Wenn die Diagnosedaten nicht geladen werden können, steht dort **Diagnose nicht verfügbar**.
Eine **Gerät verbinden** Aktion können Sie von hier aus ein Gerät dem Connector zuordnen.
Verwenden Sie die Connector-Diagnose, wenn *mehrere* Geräte gleichzeitig still sind — dieses Muster weist meist auf den Connector oder den Broker hin, nicht auf die Hardware. Verwenden Sie die Gerätediagnose, wenn ein Gerät still ist, während seine Nachbarn in Ordnung sind. Die Connector-Diagnose ist auf MQTT-Connectoren beschränkt; andere Connectortypen zeigen nur ihre Einstellungen.
Für Probleme auf Broker-Seite, mit TLS, Authentifizierung und Topic-Routing siehe [MQTT-Fehlerbehebung](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md).
## Tipps
* **Daten-Sendeintervall ehrlich einstellen.** Die Diagnose misst „still geworden“ gegen das von Ihnen eingegebene Intervall. Eine Sonde, die einmal pro Tag berichtet, aber als stündlich konfiguriert ist, wird 23 Mal am Tag als offline markiert; ein tatsächlich toter Sensor, der als monatlich konfiguriert ist, bleibt wochenlang grün.
* **Prüfen Sie den Empfangsstatus, bevor Sie ein Ticket öffnen.** *Daten werden gesendet — Zuordnung einrichten, damit sie gespeichert werden* ist eine Schreibtischlösung. *Hat nicht gemeldet — Gerät wirkt offline* ist ein Vor-Ort-Termin. Der Unterschied ist die 30 Sekunden wert.
* **Behalten Sie das Pipeline-Fenster während der Inbetriebnahme im Blick.** Die Zählwerte decken die Tage ab, die in der **Statistik über die letzten {{days}} Tage** Bezeichnung genannt werden, daher trägt ein vor einer Stunde repariertes Gerät seine fehlgeschlagenen Nachrichten noch immer in der Zählung. Beurteilen Sie eine frische Korrektur anhand der neuesten Zeilen im Ereignis-Feed, nicht anhand der Summen.
* **Nicht zugeordnete Schlüssel sind eine Chance, kein Fehler.** Wenn ein gesundes Gerät `{{count}} weitere Schlüssel verfügbar, nicht zugeordnet`meldet, sendet die Hardware Messungen, die Sie noch nicht verwenden – ein Vibrationssensor meldet vielleicht zusätzlich Temperatur, ohne zusätzlichen Verbrauch bei Batterie oder Sendezeit.
* **Die Diagnose ergänzt die Registerkarte Protokolle, sie ersetzt sie nicht.** Die Diagnose erklärt *warum* , warum die Verarbeitung so verlaufen ist. Die Registerkarte Protokolle zeigt die Rohmessungen selbst. Siehe [Geräteverwaltung](/kilo-docs-de/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-de/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.
