Ereignisse

Events zeigt Ihnen, wann etwas Ihre Aufmerksamkeit braucht: ein Sensor, der nicht mehr antwortet, ein Neustart des Hubs oder eine abgebrochene Verbindung zum Hub. Außerdem zeigt die Seite das eigene Protokoll des Hubs. Öffnen Sie sie über die linke Navigation der App: Monitoring → Events.

Tabs

Gibt es nichts anzuzeigen, sagt die Seite „✓ No active alarms“. Diese Meldung erscheint nicht, solange die Verbindung zum Hub unterbrochen ist, weil die App den aktuellen Zustand dann nicht kennen kann.

Banners

Banner erscheinen über den Karten.

Verbindung verloren

Hat die App 15–20 Sekunden lang nichts vom Hub gehört:

No connection to the hub since time. The alarm state is unknown — the last known is shown below.

Was unter dem Banner steht, ist der zuletzt bekannte Zustand, nicht der aktuelle. Hat die App noch nie Daten vom Hub erhalten, lautet der Banner „No connection to the hub. The alarm state is unknown.“ Im Demo-Modus wird der Banner nicht angezeigt.

Was zu prüfen ist: ob Ihr Telefon oder Computer noch im Netz des Hubs ist und ob der Hub Strom hat. Der Banner verschwindet von selbst, sobald die Verbindung wieder steht.

Der Hub wurde neu gestartet

Hat der Hub in den letzten 7 Tagen neu gestartet (und war seine Uhr zu diesem Zeitpunkt gestellt), zeigt ein Banner, wann und warum:

The hub restarted day month, time — reason.

War er länger als eine Minute aus oder außer Betrieb, ergänzt der Banner: „It was off or down for ≈ duration; history records for that time may be missing, but “today” counts it from the hub's counters.“ (siehe History).

Ein geplanter Neustart wird als Information angezeigt, die anderen als Warnung. Meldet der Hub einen Grundcode, den die App nicht kennt, wird der Code unverändert angezeigt. Die Spalte What to check ist unser Rat; der Banner selbst zeigt nur den Grund.

Sensor antwortet nicht

Für jeden zugeordneten Point, dessen Sensor nicht antwortet, erscheint eine Karte.

Die Karte zeigt:

• den Schweregrad warning;
• den Namen des Points;
• „sensor not responding“, gefolgt von „ · module n, channel“, wenn der Hub das Modul meldet;
• seit wann, entnommen dem Hub-Log, wenn möglich:
  • „the hub has logged poll failures since time“ – der Hub konnte das Modul vorher lesen und kann es jetzt nicht mehr;
• „the hub didn't find the module at start-up (time) and keeps looking“ – das Modul war beim Start des Hubs nicht vorhanden;
• sonst: „seen in this browser since time (the hub log has no poll failure for this module — perhaps it wasn’t found at start-up)“;
• Open point, das die Seite des Points öffnet.

Solange ein Sensor schweigt, liest die App das Hub-Log jede Minute erneut.

Was zu prüfen ist

1. Die Stromversorgung des rbAmp-Moduls und das I2C-Kabel zum Hub (der eigene Hinweis der Karte).
2. Points → rbAmp modules (n): Zeigt die Modulkarte not found? Zeigt die Seite eine Bus-Warnung („A module bus line is held low…“ oder „The module bus is stuck…“)? Siehe Points.
3. Hat der Hub das Modul beim Start nicht gefunden, prüfen Sie die Verbindung des Moduls. Der Hub sucht weiter danach.
4. Hilft das nicht, öffnen Sie das Hub log, drücken Sie Copy und wenden Sie sich an Ihren Installateur oder den Support.

Ein Point, der einem Kanal zugeordnet ist, den das eingebaute Modul nicht hat, bekommt diese Karte nicht. Stattdessen sagt seine eigene Seite dies (siehe Points).

Hub log

Das Hub log (im Tab Log) ist das, was der Hub selbst aufgezeichnet hat: Neustarts und ihre Ursachen, Updates, Wi-Fi, Abfragefehler der Module sowie das Abschließen von Stunden und Tagen. Die Zeilen sind technisch und für einen Techniker oder den Support gedacht. Remote-Nodes schreiben hier ihre Kopplung, die Einstellungen, die sie bestätigen, und FAIL-Zeilen für Rahmen oder Datensätze, die der Hub nicht zählen konnte. Ein Node, der offline geht oder zurückkommt, steht nicht in diesem Log: Der Hub veröffentlicht das über MQTT und zeigt es auf der Node-Karte (siehe Remote nodes).

Oben steht die Firmware-Zeile des Hubs: die Version, eine kurze Image-ID und die Partition, von der er läuft.

Preiszeilen

Ab v1.2.0 hinterlässt das Hub-Log, wenn ein dynamischer Preis eingeschaltet ist, die Spur der Preisabrufe – und es ist der Ort, an dem Sie nachsehen, wenn ein Kostenwert nicht Ihren Erwartungen entspricht:

Die Fehlergründe sind die eigenen Codes des Hubs – fetch_failed, http_status, parse, auth, no_data_for_zone, rate_limited –, und welcher davon vorliegt, entscheidet, was zu tun ist. Die Seite Prices nennt denselben Grund in einfachen Worten, und Woher Ihr Preis kommt erklärt, was jeder für Sie bedeutet.

Zeiten in diesen Zeilen sind so geschrieben, wie der Hub sie schreibt, als Unix-Sekunden.

⚠️ Eine FAIL price:-Zeile ist keine verlorene Messung. Energie wird weiterhin gezählt und bepreist; was ein fehlgeschlagener Abruf ändert, ist welcher Preis angewendet wurde – der des Backups oder der Zonensatz des Tarifs. Das Preisprotokoll sagt für jede Periode, welcher es war.

Filter

Zeilen lesen

• Neueste zuerst, gruppiert nach Start: „Start #n“, mit „· current“ beim laufenden.
• Die Zeit ist die Uhr des Hubs, mit Sekunden. Solange die Uhr nicht gestellt war, steht dort „s s after start“.
• Jede Zeile hat eine Stufe: failure, event oder routine. Fehlerzeilen sind hervorgehoben. Die Meldung wird so angezeigt, wie der Hub sie geschrieben hat.

Eine Abfrage reicht über einen festen Abschnitt des Logs zurück; Show earlier lädt mehr.

Buttons

• Refresh lädt das Log neu.
• Copy legt eine kurze Firmware-Zeile (wenn die Version bekannt ist) und die angezeigten Zeilen als Klartext in die Zwischenablage, eine tabulatorgetrennte Zeile je Zeile. Die Schaltfläche zeigt „Copied“ für 2 Sekunden; sie ist aus, wenn keine Zeilen geladen sind. Fügen Sie den Text in Ihre Nachricht ein, wenn Sie den Support kontaktieren.

Messages

Ein fehlgeschlagenes Firmware-Update eines Moduls hat einen Link Hub log → (siehe Sensors and modules). Er öffnet Events auf dem Tab Active; wechseln Sie zu Log, um zu sehen, warum.