Logs
Die Logs-Seite ist der Ereignisverlauf des Kontos: Gerätemeldungen, Alarme, Downlinks, Änderungen der Zugriffsrechte und Bearbeitungen, die neuesten zuerst.

Dieselbe Liste erscheint auf dem Logs-Tab eines Geräts, dort auf dieses Gerät eingegrenzt, und im Logs-Widget auf einem Dashboard. Das Widget übernimmt dieselben Filter und dieselbe Zeitanzeige, sodass alles, was Sie hier herausfiltern können, auch dauerhaft auf einem Dashboard stehen kann.
Einen Eintrag lesen
| Teil | Was er Ihnen sagt |
|---|---|
| Der farbige Punkt | Der Typ des Eintrags - Error, Warning, Info, Debug oder Verbose |
| Die Nachricht | Was passiert ist |
| Die Ressource | Das Gerät oder die andere Ressource, der es passiert ist. Klicken Sie darauf, um nur die Logs dieses Geräts zu sehen |
| Die Kategorie | Um welche Art von Ereignis es sich handelt |
| Die Prioritäts-Pille | Wird bei nicht quittierten Einträgen oberhalb niedriger Priorität angezeigt |
| Die Zeit | Im Format, das unter Zeitanzeige eingestellt ist |
Ein quittierter Alarm trägt [Acknowledged by: <username>] hinter seiner Nachricht, sodass
ersichtlich ist, wer sich darum gekümmert hat.
Alarme
Ein Alarm ist ein nicht quittierter Log-Eintrag hoher oder schwerwiegender Priorität. Er ist weder eine eigene Art von Eintrag noch eine Kategorie - er ist diese beiden Eigenschaften zusammen.
Drei Bedienelemente steuern sie.
Schnellfilter: Alarms ist ein Umschalter in der Werkzeugleiste. Er leert die übrigen Filter und setzt die Priorität auf High und Severe, nicht quittiert. Erneut drücken hebt ihn auf.

Acknowledge erscheint bei einem Eintrag hoher oder schwerwiegender Priorität, der noch nicht quittiert wurde. Das Quittieren hält Ihren Benutzernamen dazu fest und nimmt ihn aus dem Alarmfilter heraus. Unacknowledge stellt ihn zurück.
Acknowledge all quittiert alle offenen Alarme auf einmal. Vom Logs-Tab eines Geräts aus geöffnet, ist die Aktion auf dieses Gerät begrenzt, sodass das Quittieren der Alarme eines Geräts nicht mehr die des gesamten Kontos mit erledigt.
Hinweis: Ein Alarm muss quittiert werden, bevor derselbe Alarm erneut ausgelöst werden kann. Bleibt er unquittiert, löst er kein zweites Mal aus. Aus demselben Grund feuert der Trigger Missing expected report in der Rule Engine einmal statt wiederholt.
Filter
Show filters öffnet das Filterpanel und zeigt an, wie viele Filter aktiv sind. Clear filters leert sie wieder.

| Filter | |
|---|---|
| Resource | Die Art der Ressource: Device, Organization, User group, Connector oder Rule. Standardmäßig alle |
| Type | Eines oder mehrere von Error, Warning, Info, Debug, Verbose |
| Priority | Eines oder mehrere von Severe, High, Medium, Low |
| Category | Eines von Access, Analytics, Command, Rule, Status, System, Update |
| Message | Freitext, der gegen die Nachricht geprüft wird |
| Acknowledged | Quittiert oder nicht quittiert |
| Time range | Der anzuzeigende Zeitraum |
Type und Priority nehmen mehrere Werte zugleich an. Die übrigen nehmen einen.
Typ
| Typ | Was er bedeutet |
|---|---|
| Error | Ein erkannter Fehler - ein Befehl, der nicht rechtzeitig beantwortet wurde, ein Gerät, das nicht gemeldet hat |
| Warning | Etwas, das Aufmerksamkeit verdient, etwa schwacher Empfang oder ein Sensorereignis. Die Priorität sagt, wie viel |
| Info | Ein gewöhnlicher informativer Eintrag |
| Debug | Meldungen für Entwickler, einschließlich Translator-Abstürzen |
| Verbose | Statusmeldungen von Integrationen, zum Beispiel einem LoRaWAN-Netzwerkserver. Nützlich, um die Netzqualität zu beobachten |
Debug und Verbose liegen für den Alltag abseits des Wegs, und sie sind die beiden, die man kennen sollte, wenn etwas nicht stimmt. In Debug meldet sich ein abgestürzter Translator, und in Verbose sagt der Netzwerkserver, was er mit einem Gerät tut.
Priorität
| Priorität | |
|---|---|
| Severe | Ein kritisches Ereignis, das sofortige Aufmerksamkeit erfordert - etwa Brand- oder Explosionsgefahr. Löst eine Benachrichtigung aus |
| High | Eine ernste Warnung, die rasches Handeln erfordert. Löst eine Benachrichtigung aus |
| Medium | Eine Maßnahme kann nötig sein, hat aber Zeit. Keine Benachrichtigung |
| Low | Nichts zu tun. Keine Benachrichtigung |
High und Severe sind zugleich das, was einen Eintrag zu einem Alarm macht.
Kategorie
| Kategorie | Was sie abdeckt |
|---|---|
| Status | Allgemeine Ereignisse: Alarme, Zustandsänderungen, externe Fehler |
| Update | Node-Update-Ereignisse |
| Command | Downlinks |
| Access | Ereignisse zu Zugriffsrechten, zum Beispiel Konto X erteilt Benutzer Y Lesezugriff |
| Analytics | Geräteaktualisierungen, wenn neue Daten eintreffen |
| Rule | Ereignisse der Rule Engine, einschließlich der Aktion Write log |
| System | Meldungen auf Plattformebene, einschließlich Translator-Abstürzen |
Wenn ein Translator abstürzt
Ein Translator, der beim Dekodieren einer Payload eine Ausnahme wirft, schreibt einen Log-Eintrag zu dem Gerät, das er gerade dekodiert hat. Nur dort wird dieser Fehler gemeldet - das Gerät trägt schlicht keine dekodierten Werte, und nichts sonst sagt warum.
Zu finden mit Type: Debug und Category: System. Der Eintrag nennt den Translator und seine Version und trägt den Fehler:
Translator "milesight-am319" (v2.1.0) error: Cannot read properties of undefined (reading 'length')
Der Fehlertext wird bei 400 Zeichen abgeschnitten, und der Eintrag wird mit mittlerer Priorität zum Gerät geschrieben, steht also auch auf dem Logs-Tab dieses Geräts.
Hinweis: Diese Einträge werden sechs Stunden aufbewahrt. Die Aufbewahrungsregel für Debug ist kürzer als die der Kategorie System, und die kürzere gewinnt. Kopieren Sie noch am selben Tag heraus, was Sie brauchen.
Drei Ursachen machen die meisten davon aus:
- Das Gerät sendet eine Payload, für die der Translator nicht geschrieben wurde;
- die Version des Translators passt nicht zur Firmware des Geräts;
- auf dem Gerät liegt der falsche Translator.
Zeitraum
Standardmäßig aus, sodass die Liste alles abdeckt. Schalten Sie ihn ein und wählen Sie einen Zeitraum.
Vorgefertigte Zeiträume sind die letzten 15 Minuten, die letzte Stunde, 6 Stunden, 24 Stunden, 7 Tage, 30 Tage und 90 Tage; beim Einschalten des Filters wird mit den letzten 24 Stunden begonnen. Anfang und Ende lassen sich auch von Hand setzen, und All time schaltet den Filter wieder aus.
Ein Ende vor dem Anfang wird zurückgewiesen, statt stillschweigend nichts zu liefern.
Zeitanzeige
Drei Formate, neben den Listenbedienelementen statt im Filterpanel eingestellt - das ändert, wie Einträge geschrieben werden, nicht welche Sie sehen.
| Einstellung | Zeigt |
|---|---|
| Relative time | vor 5 Minuten |
| Exact time | 11/09 2026 14:23:07 - 24-Stunden-Format, sekundengenau |
| Both | vor 5 Minuten (11/09 2026 14:23:07) |
Die relative Zeit beantwortet die Frage, ob etwas aktuell ist. Die exakte Zeit brauchen Sie in dem Moment, in dem Sie Yggio mit etwas anderem vergleichen: dem Log eines Netzwerkservers, einem Vor-Ort-Termin, der Meldung dessen, dem das Problem aufgefallen ist. Sekunden zählen, wenn mehrere Einträge in dieselbe Minute fallen und die Reihenfolge die Geschichte erzählt.
Both ist beim Untersuchen die nützliche Voreinstellung, da es die schnelle Lesbarkeit und den zitierfähigen Zeitstempel zugleich behält.
Die Liste aktuell halten
Die Liste lädt sich alle zwei Minuten neu, und der Hinweis darüber sagt, wann sie das zuletzt getan hat. Die Aktualisieren-Schaltfläche daneben lädt sofort neu.
Die Fußzeile bestimmt, wie viele Einträge pro Seite erscheinen - 5, 20, 50 oder 100 - und blättert durch sie.
Wie lange Einträge aufbewahrt werden
Einträge werden automatisch gelöscht. Die Aufbewahrung richtet sich nach der Kategorie, außer bei den beiden entwicklernahen Typen, die sich stattdessen nach dem Typ richten.
| Aufbewahrt für | |
|---|---|
| Access | 10 Jahre |
| Status, Command | 2 Jahre |
| Update, Analytics | 1 Jahr |
| Rule | 4 Wochen |
| System | 14 Tage |
| Verbose (Typ) | 14 Tage |
| Debug (Typ) | 6 Stunden |
Translator-Fehler werden als Typ Debug unter der Kategorie System geschrieben, sodass die 6-Stunden-Regel zuerst greift. Kopieren Sie alles, was Sie aus einem Debug-Eintrag brauchen, noch am selben Tag heraus.