Fehlerbehebung

Die häufigste Support-Frage lautet: Mein Gerät sendet nichts – was jetzt? Die einzelnen Signale dafür stehen bereits in den jeweiligen Kapiteln — Cockpit, Geräte, Konsole, Signal, Decoder beschreiben jeweils, was eine Seite zeigt. Diese Seite verbindet sie zu einer Reihenfolge: welche Seite du zuerst öffnest, was ein Ergebnis dort ausschließt, und wohin du als Nächstes gehst.

Schritt 1 — Cockpit: was ist überhaupt betroffen?

Öffne zuerst dein Cockpit. Die Kachel Gerätestatus zeigt sofort, wie viele deiner Assets online sind, und die Liste Benötigen Aufmerksamkeit darunter nennt jedes einzelne Gateway oder Gerät, das gerade nicht im Normalzustand ist, mit einem Status-Badge (Kritisch, Warnung oder Offline).

• Steht dort ein Gateway, geh direkt zu Schritt 2 — ein gestörtes Gateway erklärt meist jedes Gerät dahinter gleich mit.
• Steht dort nur ein Gerät, das Gateway selbst aber nicht in der Liste, geh direkt zu Schritt 3.
• Ist die Liste leer und alle Zähler grün, ist es kein Verbindungsproblem — die Ursache liegt eher bei Schritt 4 (Decoder) oder bei einem Blick in die Konsole.

Schritt 2 — Ein Gateway zeigt sich offline

In der Geräteliste steht in der Spalte Status für ein betroffenes Gateway Nicht verbunden; auf der Detailseite des Gateways wiederholt sich das oben als Badge Getrennt, daneben Letztes Uplink — bleibt dieses Feld leer, hat das Gateway noch nie ein Uplink geliefert, nicht nur seit Kurzem keins mehr.

Was du als Nächstes prüfst, hängt davon ab, wie das Gateway verbunden ist:

• Mit Pallax Agent: Der Reiter Monitoring auf der Gateway-Detailseite zeigt CPU, Speicher, Uplink-Queue und Uptime, gemeldet vom Agent selbst. Bleiben diese Werte leer, hat der Agent seit Längerem keine Telemetrie mehr gesendet — prüfe den Agent auf dem Gerät selbst, siehe Pallax Agent.
• Ohne Agent: Diese Werte stehen grundsätzlich nicht zur Verfügung (die Reiter Compliance und Remote-Befehl sind für ein Gateway ohne Agent deaktiviert) — hier bleibt nur, die manuelle Verbindung selbst zu prüfen: Broker-Adresse und Zertifikat, siehe Gateway ohne Agent verbinden.

Schritt 3 — Ein Gerät sendet keine Daten

Zeigt die Geräteliste für ein einzelnes Gerät Nicht verbunden und Zuletzt gesehen bleibt leer, öffne die Detailseite des Geräts. Der Reiter Daten zeigt den Uplink-Stream; ist dort noch nichts angekommen, steht dort wörtlich Warten auf erste Uplinks statt eines leeren Diagramms — das unterscheidet "noch nie gesendet" bewusst von einem Diagramm ohne sichtbare Punkte.

Für eine feinere Prüfung als das Cockpit bietet der Reiter Konsole auf derselben Detailseite einen reinen Funk-Protokoll für genau dieses Gerät (Spalten Zeit, Richtung, Typ, Gateway, RSSI, SNR) — getrennt von der workspace-weiten Konsole unten. Zeigt dieser Live-Tail Noch keine Frames für dieses Gerät, ist auf Funkebene nichts angekommen; das grenzt ein Reichweiten- oder Konfigurationsproblem (DevEUI/AppKey, siehe Erste Schritte) von einem reinen Decoder-Problem ab, bei dem ja durchaus Frames ankämen.

Schritt 4 — Daten kommen an, wirken aber falsch oder unlesbar

Rohdaten werden erst durch einen zugeordneten Decoder lesbar (siehe Decoder). Fehlt einem Gerät der Decoder, zeigt die Geräteliste das direkt an: Spalte Decoder trägt das Label Fehlt, und die Detailseite listet unter Geräte-Informationen → Netzwerk → Decoder einen Strich statt eines Namens.

Was ein Decoder-Fehler selbst — ein zugeordneter Decoder, der auf echte Uplinks falsche oder unsinnige Werte liefert — in der Oberfläche zeigt, konnte an keinem der beiden verfügbaren Mandanten beobachtet werden: Das einzige erreichbare Gerät hat weder einen Decoder noch je ein Uplink gesendet. Bevor hier ein bestimmtes Fehlerbild dokumentiert wird, braucht es eine echte Beobachtung an einem Gerät mit zugeordnetem Decoder und tatsächlichen Uplinks.

Schritt 5 — Ein Alarm löst ohne erkennbaren Grund aus (oder bleibt aus)

Wichtig zuerst: Signal meldet sich nicht automatisch, nur weil ein Gerät offline geht. Das lässt sich direkt gegenprüfen — im selben Mandanten, in dem Cockpit ein Gateway als Kritisch und ein Gerät als Offline führt, zeigte die Signal-Inbox zeitgleich "Alle Systeme arbeiten normal", mit Offen/Pausiert/Gelöst je bei 0. Der Grund: Der Regelassistent (Neue Regel) bietet als Regeltyp Schwellenwert an — eine Regel löst aus, wenn eine Metrik einen Wert über- oder unterschreitet, nicht wenn ein Gerät den Kontakt verliert. Bleibt Signal bei einem Verbindungsproblem still, ist das kein Fehler, sondern erwartet: für "Gerät offline" existiert keine automatische Regel, solange du nicht selbst eine passende Schwellenwert-Regel dafür anlegst.

Löst umgekehrt eine Regel aus und der Grund ist nicht offensichtlich, findest du unter dem Reiter Regeln die Definition zurück — welche Metrik, welcher Schwellenwert, welcher Schweregrad. Wie eine ausgelöste Warnung selbst in der Inbox aussieht und wie weit sie sich bis zum auslösenden Gerät zurückverfolgen lässt, konnte in keinem der beiden Mandanten beobachtet werden, da nie eine echte Warnung vorlag — das absichtlich auszulösen hätte bedeutet, eine Regel anzulegen und zu aktivieren, was diese Untersuchung nicht vorsieht.

Die Konsole als plattformweites Werkzeug

Zeigen die Schritte oben nichts Auffälliges am Gerät oder Gateway selbst, ist die workspace-weite Konsole die nächste Ebene: Sie bündelt Protokolle von Broker, Network Server, Gateway-Bridge, Mioty-Diensten, Agent und Audit in einem durchsuchbaren Verlauf. Beachte dabei: Für plattforminterne Log-Zeilen (etwa interne API-Aufrufe) trägt die Spalte Gerät die Kennung der internen Dienstinstanz, nicht die eines Kundengeräts — die Konsole lässt sich hier nicht zuverlässig nach einem bestimmten Gerät filtern; für gerätespezifische Funk-Frames ist der Konsole-Reiter auf der Geräte-Detailseite (Schritt 3) die genauere Quelle.

Was diese Seite (noch) nicht abdeckt

Diese Zustände ließen sich an keinem der beiden verfügbaren Mandanten beobachten, ohne etwas anzulegen oder zu verändern — sie sind deshalb hier bewusst nicht beschrieben:

• Wie ein zugeordneter Decoder aussieht, der falsche oder unsinnige Werte liefert.
• Wie eine tatsächlich ausgelöste Signal-Warnung in der Inbox aussieht und wie sich ihre Ursache von dort zurückverfolgen lässt.
• Der genaue Zeitpunkt, ab dem ein zuvor verbundenes Gateway oder Gerät als "Nicht verbunden" markiert wird (beobachtet wurde nur ein Gerät, das noch nie verbunden war).
• Jeder Erststart-Zustand eines leeren Arbeitsbereichs (leeres Cockpit, leere Geräteliste, leerer Decoder) — der dafür vorgesehene zweite Mandant war zum Zeitpunkt dieser Untersuchung durchgehend hinter einer Tarifauswahl gesperrt.