Live-Daten ohne Polling

⚠️ Diese Seite betrifft die eigenständige Hub-Firmware. Ein Hub mit dem ESPHome-Paket hat keine REST-API, kein WebSocket und kein MQTT — er ist ein ESPHome-Gerät, und Home Assistant spricht mit ihm über das RBgrid-Panel und die Aktion rbgrid_cmd. Alles Folgende setzt voraus, dass der Hub seine eigene Web-App ausliefert. → Im Home Assistant betreiben

Der Hub sendet von selbst. Öffnen Sie ein WebSocket zu /ws-telemetry, und die Messwerte kommen an, sobald der Hub sie erzeugt — statt dass Sie sie immer wieder abfragen und eine Kopie erhalten, die immer etwas veraltet ist.

Das nutzt die App selbst. Wenn Sie ein Dashboard, einen Node-RED-Flow oder etwas bauen, das einen Live-Wert auf einem Bildschirm braucht, ist dies der Transportweg; für alles, was einen Datensatz statt eines Werts braucht, nutzen Sie Historie über HTTP.

Die Routenliste und die Referenz der Live-Felder stehen in der generierten API-Referenz, einer Datei im Repository, die bei jedem Release aus dem eigenen Schema des Hubs erzeugt wird. Diese Seite wiederholt sie nicht: Eine von Hand kopierte Feldliste veraltet leise, und eine veraltete Feldliste ist schlechter als keine, weil sie glaubwürdig wirkt.


Anmelden aus einem Browser, ohne ein Token in die URL zu legen

Eine WebSocket-Adresse trägt keine Header, daher liegt der naheliegende Weg darin, das Token in den Query-String zu setzen — und so landen Tokens im Browserverlauf, in Server-Logs und auf Screenshots.

Der Hub bietet Ihnen die Alternative:

  1. POST /api/v1/ws-ticket über HTTP, mit Ihrem Token.
  2. Sie erhalten ein Ticket: einmal verwendbar, 30 Sekunden gültig.
  3. Öffnen Sie den Socket mit dem Ticket.

Dreißig Sekunden sind bewusst kurz, und Einmalverwendung heißt, dass ein abgefangenes Ticket bereits verbraucht ist. Holen Sie für jede Verbindung ein neues — auch bei jeder Wiederverbindung — statt eines auf Vorrat zu halten.

⚠️ Ein Ticket ist keine Sitzung. Es berechtigt nur zum Öffnen eines einzelnen Sockets. Wenn Sie es zwischenspeichern, schlägt Ihre Wiederverbindung im ungünstigsten Moment fehl — genau dann, wenn Sie sich wieder verbinden: nach einem Fehler.

Für einen serverseitigen Client, der kein Browser ist, ist dieses Vorgehen nicht nötig — senden Sie das Token auf die übliche Weise.

Lesezugriffe brauchen das read-Token, sobald der Hub beide Tokens gesetzt hat. → Settings


Den Stream starten und stoppen

Der Socket ist kein Dauerstrom, an den Sie sich nur anhängen. Er nimmt drei Nachrichten entgegen:

Nachricht Wirkung
get_telemetry ein Frame, jetzt
start_telemetry mit dem Senden beginnen
stop_telemetry Senden stoppen, Socket behalten

Stoppen Sie, wenn Ihre Seite ausgeblendet wird, und starten Sie erneut, wenn sie wieder angezeigt wird. Ein Browser-Tab, der über Nacht mit laufendem Stream offen bleibt, kostet den Hub echte Arbeit ohne jeden Nutzen, und der Hub bedient zugleich die App, die Broker-Verbindung und die Messschleife.

Ein Socket pro Client. Mehrere Sockets von einer Seite sind ein Fehler, der wie ein Leistungsproblem aussieht: Jeder davon ist ein Stream, den der Hub füllen muss.


Wie viel der Hub sendet

Telemetrie hat zwei Profile, lean und full, die auf dem Hub eingestellt werden (/api/system/telemetry-config). Lean ist das kleinere Frame; full enthält alles, was der Hub melden kann. Das Frame hat außerdem eine Größenobergrenze, die der Hub nicht überschreitet.

Wählen Sie lean, es sei denn, Sie nutzen Felder, die nur full enthält. Ein Dashboard, das Leistung und Kosten je Point zeigt, braucht full nicht, und der Unterschied sind Bytes in Ihrem Netzwerk alle paar Sekunden, solange der Client läuft.


Was ankommt, lesen

Drei Dinge sind zu tun, und die ersten beiden lassen Integrationen oft aus:

Die Qualität durchreichen. Live-Frames und Datensätze sagen gleichermaßen, was der Hub von den eigenen Zahlen hält: teilweise, geschätzt, neu berechnet oder aus einem Ausfall. Ein Dashboard, das diese Kennzeichen wegwirft, kann eine seltsame Zahl später nicht erklären, und die Erklärung steht meist genau in diesem Kennzeichen. → History

Die Zeit des Hubs vertrauen, nicht Ihrer eigenen. Perioden, Tage und Tarifzonen werden nach der eigenen Uhr und Zeitzone des Hubs eingeordnet. Ein Client, der beim Eintreffen neu zeitstempelt, wird mit dem Hub darüber uneins sein, zu welcher Stunde ein Messwert gehört — und der Widerspruch bleibt unsichtbar, bis eine Tagesgrenze erreicht ist. → Time

Ein fehlendes Feld als fehlend behandeln, nicht als Null. Ein Point ohne Spannungsmodul meldet überhaupt keine Energie, statt eine aus einer Nennspannung berechnete Energie; der Hub weigert sich, sie zu erfinden, und Sie sollten es genauso halten.


Wiederverbinden

Der Socket wird irgendwann schließen: Der Hub startet für ein Update neu, das WLAN fällt aus, ein Router startet neu. Planen Sie dafür, statt überrascht zu sein:

  • Holen Sie pro Versuch ein frisches Ticket. Das alte ist verbraucht oder abgelaufen.
  • Warten Sie zwischen den Versuchen, und steigern Sie die Wartezeit weiter. Ein Client, der in enger Schleife gegen einen Hub wiederholt, der gerade neu startet, trifft genau dann ein, wenn der Hub am wenigsten antworten kann.
  • Senden Sie start_telemetry erneut. Ein neuer Socket streamt nicht, bis Sie es verlangen.
  • Rechnen Sie damit, dass Sie etwas verpasst haben. Der Stream besteht aus Live-Werten, nicht aus einer Warteschlange; nichts wird nachgeliefert. Wenn Verpasstes wichtig ist, steht es in der Historie, die erhalten bleibt, und im Preisprotokoll, das 40 Tage lang erhalten bleibt.

Wann etwas anderes zu nutzen ist

Sie wollen Verwenden Sie
einen Live-Wert auf einem Bildschirm dies
Home Assistant oder alles, das bereits an einem Broker hängt MQTT — Discovery inbegriffen
„Ist Energie gerade günstig?“ die beibehaltene Preisbenachrichtigung über MQTT: ein Zustand, kein Strom → Knowing when energy is cheapest
abgeschlossene Perioden, Kosten, ein Monat Daten HTTP oder export.csv

Für die Preisbenachrichtigung speziell bauen Sie nichts auf diesem Socket. Sie ist ein Zustand, den der Hub bei jeder 15-Minuten-Grenze und bei jeder Änderung erneut veröffentlicht, und über MQTT wird sie beibehalten — daher bekommt ein Client, der spät verbindet, trotzdem den aktuellen Zustand. Ein WebSocket-Client, der während eines Übergangs offline war, hat ihn einfach verpasst.


Wenn es nicht funktioniert: was zu prüfen ist

Der Socket öffnet sich und schließt sofort. Das Ticket wurde bereits verwendet oder ist älter als 30 Sekunden. Holen Sie pro Verbindung eines.

Der Socket bleibt offen, und nichts kommt an. Es wurde kein start_telemetry gesendet. Ein frischer Socket schweigt, bis man ihn darum bittet.

Es lief, dann hielt es nach einem Hub-Update an. Der Hub hat neu gestartet, und der Socket ging mit. Verbinden Sie sich mit einem neuen Ticket erneut und starten Sie den Stream wieder.

Werte kommen an, aber das Geld nicht. Es ist kein Tarif gesetzt, oder der Hub ist noch auf dem Werksbeispiel-Plan. → Tariffs

Ein Point sendet Strom, aber nie Energie. Dahinter liegt keine Spannung. Der Hub zeigt die Live-Leistung als Schätzung aus der Nennspannung und verbucht bewusst keine Energie. → Remote nodes

Meine Stundensummen weichen von denen der App um eine Stunde ab. Sie versehen die Messwerte mit Ihrer eigenen Uhr. Der Hub entscheidet, zu welcher Stunde ein Messwert gehört. → Time

Ein Browser-Client wird abgewiesen, während ein Skript auf demselben Rechner funktioniert. Der Browser erzwingt Origin-Regeln, die das Skript nicht hat. Erlauben Sie Ihren Origin auf dem Hub. → Talking to the hub over HTTP

⚠️ Für jede Arbeit im Inneren eines Elektrokastens rufen Sie eine Elektrofachkraft.