!Reihe von Stromzählern an einer Wand
Am 25. September 2026 eröffnete ein Nutzer namens michaeltraxler im GitHub-Repository der Integration „ha-tibber-pulse-local" ein Issue mit dem Titel „Tibber changed over night data.json to node_data.json". Seit Jahren, schrieb er, sei die Adresse http://admin:[BRIDGE_PASSWORD]@[YOUR_IP]/data.json?node_id=1 der richtige Weg gewesen, um Messwerte vom Tibber Pulse abzuholen. Über Nacht, vermutlich durch ein Firmware-Update, liefere sie einen Fehler. Jetzt heiße der Endpunkt node_data.json.
Der Entwickler der Integration, auf GitHub marq24, antwortete ohne große Gefühlsregung: Die Schnittstelle sei „always unofficial" gewesen, da dürfe sich ohne Vorwarnung etwas ändern. Man habe Glück, dass die neue Firmware erst vier Tage zuvor ausgerollt worden sei und er gerade in der richtigen Stimmung für einen Fix gewesen sei.
Das ist ziemlich genau die Lage beim lokalen Auslesen des Tibber Pulse. Es geht, es funktioniert für viele ausgezeichnet, und es hängt an einer Tür, die Tibber nie offiziell aufgemacht hat. Dieser Artikel sortiert die Wege, erklärt die Vorbereitung an der Bridge, nennt die Grenzen und zeigt, wie die Werte ins Energie-Dashboard kommen. Stand der Angaben ist der 18. Oktober 2026.
Welche Wege es gibt
Es gibt drei Wege, und nur einer davon ist wirklich lokal.
Erstens der offizielle Weg über die Cloud. Die Home-Assistant-Integration „Tibber" braucht ein API-Token von developer.tibber.com. Laut Dokumentation ist ihre IoT-Klasse „Cloud Polling". Wer einen Pulse hat, bekommt damit auch den Verbrauch in Echtzeit angezeigt. Die Statistiken für das Energie-Dashboard (Verbrauch und Kosten pro Stunde) werden bei einem Echtzeit-Zähler einmal pro Stunde aktualisiert, sonst einmal am Tag. Das ist bequem, aber die Daten laufen vom Pulse erst zu Tibber und dann zurück zu Ihnen.
Zweitens der lokale Weg über den Webserver der Bridge. Die Pulse Bridge hat einen eingebauten Webserver. Die Custom Integration „Tibber Pulse Local" (Domain tibber_local) fragt ihn im Heimnetz direkt ab. Sie wird über HACS installiert und liegt auf GitHub unter marq24/ha-tibber-pulse-local. Das Repository gibt es seit Oktober 2023, derzeit hat es 289 Sterne, die letzte Version 2026.10.3 stammt vom 8. Oktober 2026. Die Integration ist nach Angaben des Autors nicht offiziell und nicht von Tibber unterstützt. Das ist der Weg, um den sich dieser Artikel dreht.
Drittens MQTT, und hier muss man sauber trennen. Es gibt einen dokumentierten Weg, den Pulse selbst auf einen eigenen MQTT-Broker umzubiegen: das Repository MSkjel/LocalPulse2Tibber. Die Anleitung extrahiert die TLS-Zertifikate aus dem Setup-Webinterface (zu erreichen unter 10.133.70.1, wenn man den Pulse zurückgesetzt und in der Tibber-App absichtlich ein falsches WLAN-Passwort eingegeben hat), richtet in Mosquitto eine Bridge-Verbindung ein und lässt den Pulse dann an den lokalen Broker senden, der die Daten weiter an Tibber reicht. Der Autor schreibt aber ausdrücklich, dass das auf der norwegischen Pulse-Variante beruht, die per M-Bus am AMS-Zähler hängt. Ob es mit anderen Varianten klappt, sei „untested". Der deutsche Pulse IR mit Bridge, um den es hier geht, wird dort nicht beschrieben.
Für Pulse-IR-Nutzer läuft MQTT in der Praxis anders herum: Home Assistant holt die Werte lokal ab und veröffentlicht sie selbst auf einem Broker, damit andere Programme sie bekommen. Dazu gleich mehr bei evcc.
Was an der Bridge zu tun ist
Die Integration funktioniert nur mit der IR-Version des Pulse. Das Repository nennt P1, HAN und KM (verkauft in Schweden, Norwegen und den Niederlanden) ausdrücklich als nicht kompatibel. Wer unsicher ist, schaut, ob es neben dem Lesekopf eine zusätzliche Bridge zum Einstecken in die Steckdose gibt. Hat man sie, passt es.
Dann kommt der unerfreuliche Teil. Der Webserver der Bridge läuft im Normalbetrieb nicht dauerhaft und muss einmalig per Parameter eingeschaltet werden. Die Anleitung des Autors (preparation.md) beschreibt es so:
- Die Bridge in den AccessPoint-Modus bringen: Stecker ziehen, drei Sekunden warten, einstecken, drei Sekunden warten, wieder ziehen, drei Sekunden warten, einstecken. Die LED leuchtet dann grün statt hellblau.
- Mit einem Laptop oder Handy ins WLAN „Tibber Bridge" gehen. Das Passwort sind die neun Zeichen auf der Bridge, inklusive Bindestrich, im Muster XXXX-XXXX. Es lohnt sich, beim Abziehen gleich ein Foto vom Aufdruck zu machen.
- Im Browser
http://10.133.70.1/öffnen. Benutzer istadmin, das Passwort dasselbe wie fürs WLAN. - Den Parameter
webserver_force_enableauftruesetzen und speichern. - Bridge ausstecken, zehn Sekunden warten, wieder einstecken. Sie verbindet sich mit dem Heim-WLAN und sendet weiter an Tibber, die LED wird wieder hellblau.
/console/: Mit param_get 39 prüft man, ob der Parameter 39 (das ist webserver_force_enable) noch bekannt ist, dann folgen param_set 39 TRUE (die Großschreibung ist wichtig) und param_store. td007 meldete am 12. September 2024: „Bei mir hat es funktioniert." Seitdem ist die Konsole in der Anleitung der empfohlene Weg.
Danach prüfen Sie drei Dinge, die der Autor ausdrücklich verlangt. Erstens, ob die Bridge im Heimnetz unter http://tibber-host/ oder http://tibber-bridge/ antwortet (besser: feste IP im Router vergeben). Zweitens, ob unter dem Menüpunkt „Pulse" mindestens ein Node gelistet ist, meist mit der ID 1. Drittens den Wert „Last data": Das ist die Zeit seit der letzten Messung des Lesekopfs, und sie sollte nicht über 2,5 bis 5 Sekunden liegen. Ist sie öfter höher, hilft laut Repository oft, den Lesekopf ein paar Grad gegen den Uhrzeigersinn zu drehen.
Die Integration einrichten
In HACS suchen Sie nach „Tibber Pulse Local", laden die Integration herunter und starten Home Assistant neu. Danach legen Sie sie unter Einstellungen, Geräte & Dienste an. Abgefragt werden ein Anzeigename, Adresse und Passwort der Bridge, das Abfrageintervall (der Autor nennt zwei Sekunden als möglichen Wert) und der Bereich.
Beim Einrichten prüft die Integration, ob die Bridge mindestens ein Datenfeld (einen OBIS-Code) liefert. Kommt nichts, bricht die Einrichtung mit dem Hinweis ab, dass keine Verbindung möglich sei. Wer mehrere Pulse an einer Bridge betreibt, legt für jeden eine eigene Instanz mit der jeweiligen Node-Nummer an. Eine WebSocket-Verbindung gibt es pro Bridge allerdings nur für einen Node, alle anderen laufen im HTTP-Polling.
Unterstützt werden derzeit die Zählerprotokolle SML 1.04, Klartext, IEC 62056-21 und Impulse (Blinken pro kWh). Die Bridge selbst kennt weitere Modi, für die dem Entwickler Beispieldaten fehlen. Wer so einen Zähler hat, soll ein Issue mit Debug-Log eröffnen.
Was die Antwort der Bridge angeht, ist sie kein hübsches JSON. In der evcc-Diskussion zu dem Thema fügte der Nutzer whisky2k2 im März 2025 aus dem Browser ein, was data.json ihm anzeigte: ein Zeichensalat, der mit ISK und ÿ durchsetzt war. Der Nutzer staudtm, der die Bridge mit FHEM abfragt, erklärte, das sei SML, die Smart Message Language, binär kodiert. Und auch die neue Firmware liefert laut daysleeper83 trotz der Endung .json binäre SML-Daten mit dem Content-Type text/text, die mit 1b1b1b1b01010101 beginnen. Die Integration dekodiert sie mit der Python-Bibliothek SmlLib von spacemanspiff2007. Gelegentlich liefert die Bridge ein kaputtes Paket (im Log „Bytes missing" oder „CRC while parse data"), dann versucht die Integration es einmal erneut.
Der Firmware-Bruch vom September 2026
Dass Tibber an der Firmware dreht, ist der Dauerzustand, nicht die Ausnahme. Am 21. September 2026 schrieb ein Nutzer in der Diskussion „Bridge Firmware - JSON Abfrage geht nicht mehr?", seine Integration bekomme 404 auf data.json und metrics.json. Die Oberfläche der Bridge sah komplett neu aus. Im Entwicklerwerkzeug des Browsers fand die Runde heraus, dass die neue Oberfläche node_metrics.json?node_id=3 und node_data.json?node_id=1 aufruft. Getestet wurde das auf einer Bridge mit der Firmware 1794-03b6cbaf: HTTP 200, die Zählerwerte wie 1-0:16.7.0 (aktuelle Leistung, positiv Bezug, negativ Einspeisung) sowie 1-0:1.8.0 und 1-0:2.8.0 (Zählerstände Bezug und Einspeisung) waren darin. node_params.json und nodes.json existierten unverändert.
Am 22. September erschien die Version 2026.9.8 als „Hot-Release [v3]". Marq24 schrieb in den Release Notes, es sei die Firmware 1794-03b6cbaf beziehungsweise 1798-2baebf71 im Umlauf, die alternative Endpunkte einführe. Er habe ein Update auf seiner Bridge erzwingen können und einen Rückfall auf Polling eingebaut, falls die WebSocket-Verbindung keine Daten liefert. Außerdem warnt er: Die Integration erkennt die neue Firmware nur beim Start. Wer sie hereinbekommt, muss die Integration neu laden, eine automatische Erkennung sei nicht geplant.
Ein Nachspiel hatte das auch bei den Statussensoren: In Issue 132 (25. September 2026) blieben nach einer Firmware- oder API-Änderung numerische Sensoren stehen, bis die Integration neu geladen wurde; Issue 133 meldete denselben Tag, dass hub_compression_error_readings_count mit der Firmware 1798-2baebf71 auf „unknown" bleibt. Beide sind inzwischen geschlossen. Die offenen Issues stehen aktuell bei null.
Meine Lesart: Das lokale Auslesen ist ein Hobbyprojekt mit erstaunlich schnellem Support, aber ohne Vertrag. Wer die Leistung des Hauses davon abhängig macht (zum Beispiel einen Batterie-Wechselrichter, der den Netzbezug braucht), sollte einplanen, dass die Werte ein paar Tage ausbleiben können.
Wie schnell ist lokal, wie schnell die Cloud?
Hier muss man vorsichtig vergleichen, denn zur Cloud nennt die Dokumentation von Home Assistant keine Sekunden. Belegt ist: Die offizielle Integration zeigt mit Pulse den Verbrauch „in real time" an, die stündlichen Statistiken fürs Energie-Dashboard werden stündlich nachgeführt.
Lokal ist der Takt in der Hand des Nutzers: Die Integration lässt Intervalle bis herunter zu zwei Sekunden zu, und laut Anleitung soll der Wert „Last data" an der Bridge unter 2,5 bis 5 Sekunden bleiben. Dazu kommt ein Unterschied bei der Ausfallsicherheit: Läuft die Tibber-Cloud nicht, laufen die Werte nicht ein. Ein Nutzer berichtete im November 2024 in der evcc-Diskussion, ein Ausfall von ein bis zwei Stunden habe evcc zum Stillstand gebracht, weil es die Werte aus der Cloud bezog.
Eine Einschränkung gibt es auch lokal: Der Lesekopf läuft mit Batterie. Der Autor nennt drei einfache Ursachen, die nach zwei Jahren Betrieb 99,89 Prozent aller Issues erklärten: den Lesekopf leicht gegen den Uhrzeigersinn drehen, die Batterien tauschen oder die richtige Node-Nummer einstellen.
Ins Energie-Dashboard bringen
Das Energie-Dashboard braucht für Netzbezug und Einspeisung Sensoren mit Einheit kWh, der Geräteklasse energy und der Zustandsklasse total_increasing. Das steht in der Home-Assistant-Dokumentation „Integrating your electricity grid", und wie das bei Lesekopf-Lösungen konkret aussieht, zeigt der Artikel zum Stromzähler mit IR-Lesekopf in Home Assistant. Die Tibber-Local-Integration legt Entitäten für die OBIS-Werte an. Ein Nutzer in der evcc-Diskussion nannte etwa sensor.ltibber_0100100700ff für die Wirkleistung, was dem Code 1-0:16.7.0 entspricht.
Zwei Stolpersteine zeigen sich in den Issues. Issue 61 fragt, ob sich Bezug und Einspeisung unterscheiden lassen, Issue 69 heißt „Split Grid Import and Grid Export". Hintergrund ist, dass die Leistung als eine Zahl mit Vorzeichen kommt. Das Dashboard will aber zwei getrennte Zählerstände. Dafür nehmen Sie die kumulierten Werte 1-0:1.8.0 und 1-0:2.8.0, nicht die Momentanleistung.
Wer die Leistung aus Home Assistant heraus an andere Programme geben will, nimmt MQTT. Der Nutzer Holgiman1 beschrieb in der evcc-Diskussion, wie er es löst: Der Pulse wird lokal erreichbar gemacht, Home Assistant holt die Werte ab, und eine Automation verteilt sie alle fünf Sekunden per MQTT, wo evcc sie als Zähler liest. Direkt in evcc einlesen lässt sich die Bridge nicht, weil dafür ein SML-Parser nötig wäre. Der evcc-Beitragende GrimmiMeloni stellte im März 2025 fest, dass die vorhandenen Bordmittel das nicht hergeben und sich erst ein Maintainer finden müsse. Wer für Zigbee ohnehin einen MQTT-Broker betreibt, kann ihn mitbenutzen; die Abwägung dazu steht im Vergleich Zigbee2MQTT gegen ZHA. Das Zusammenspiel von Wallbox und dynamischem Tarif, in dem die Zahlen dann ankommen, ist Thema im Artikel zu evcc mit Wallbox und Tibber-Tarif.
Wann sich der Aufwand lohnt
Es lohnt sich, wenn Sie Werte im Sekundentakt brauchen: für einen Wechselrichter, der dem Netzbezug folgt, für Nulleinspeisung, für eine Wallbox mit PV-Überschuss. Es lohnt sich auch, wenn Sie die Cloud nicht im Regelkreis haben wollen.
Es lohnt sich nicht, wenn Sie nur Statistiken wollen. Dafür reicht die offizielle Integration mit dem Token. Und wer den Tibber-Speicher nutzt, braucht ohnehin die Live-Daten der Bridge in Tibbers eigenen Systemen, wie der Artikel zur Tibber-Speichersteuerung ausführt. Lokales Auslesen ersetzt das nicht, es läuft daneben. Die Bridge sendet laut Anleitung auch nach dem Aktivieren des Webservers weiter an Tibber.
Eine Alternative für Zähler mit Smart-Meter-Gateway ist die HAN-Schnittstelle, die im Artikel Smart-Meter-Gateway in Home Assistant beschrieben ist. Die Bridge ist dagegen der Weg für Zähler mit optischer Schnittstelle, bei denen Sie schon einen Pulse haben.
Was Sie jetzt tun können
Öffnen Sie vor allem die Seite http://[IP]/pulse/ Ihrer Bridge (bei alter Firmware /nodes/) und sehen Sie nach, wie hoch „Last data" steht. Wenn die Bridge antwortet, installieren Sie die Integration über HACS und geben Sie ihr eine feste IP. Notieren Sie sich das Passwort von der Bridge. Und merken Sie sich die Regel für den Fall, dass die Werte eines Morgens ausbleiben: Zuerst die Integration neu laden, dann prüfen, ob es ein neues Release gibt, dann erst die Hardware verdächtigen.
