openWB Forum

Update: Pfui, ist das alles hässlich!
Es soll ja Stretch-kompatibel sein, und das bedeutet Python 3.5, und das bedeutet "Ganz rudimentäres async" für Web-Sockets.
Und dann ist on top auf dem Websocket noch der GraphQL-Layer, für den es natürlich auch Libraries gibt, aber auch da wird bei Python 3.5 abgewunken.

Die Tibber-Client-Library (https://pypi.org/project/tibber.py/) läuft zwar wie Charme - aber erst ab Python 3.9.

Meine Überlegung geht dahin, über legacy_server einen Thread weg-zu-forken und in dem die Connection zu behandeln. Andere Ideen? Warum hat die Schönheit von MQTT nicht Tibber erreicht?

Ach du …

Hätte nicht gedacht das das so kompliziert ist. Wenn man die API anschaut sieht das ja sehr schlüssig aus.

Ich breche den Versuch jetzt ab, schade.
Selbst die wohl älteste, gängige Websocket-Bibliothek (websocket bzw. websocket-client), aktuell in Version 1.5.1, läuft erst ab Python 3.7. Die älteste Version mit Python 3.5 ist 0.59, und die schmiert m.E. schon beim Decoden der Antwort des Tibber-Servers ab, wenn ich auch nur einen Decoder aus 1.51 zurückportiere.
Im Vergleich zur aktuellen Tibber-Library, mit der ich binnen vielleicht 15 Minuten Sonicmasters Live-Daten über den Bildschirm laufen sah, ist mir das jetzt zu viel archäologische Arbeit.

Ich stelle jetzt mein Testsystem dann wieder auf Bullseye und die 2.0 Beta um
Trotzdem: Der Tibber-Support ist m.E. drängend. In meinem erweiterten Techniker-Bekanntenkreis kenne ich nur 2 "Awattare", aber bereits mind. 5 Tibberianer. Tibber rollt im Moment nach meiner Wahrnehmung den Markt der am Strompreis leidenden BEV-Fahrer auf.

Moin,
das Problem hat mir keine Ruhe gelassen, und ich habe noch ein wenig an einer Schmuddel-Lösung gecoded, die jetzt erste Proof-Of-Concept-Ergebnisse liefert. Die Lösung ist begrenzt hilfreich, weil sie nur Leuten hilft, die entweder
- Shell-Access auf ihre OpenWB haben und Software installieren können
oder aber:
- Grenzenloses Vertrauen haben (Tibber-Token sind heikel, Du kannst die Adresse ziehen und sehen, wann die Person offenbar im Urlaub ist)
- und zugleich Tibber von einer IP nur maximal 2 Verbindungen zulässt.

Aber zur Lösungs-Idee:
Ich habe eine "Tibber-2-MQTT-Bridge" in Java geschrieben (ist halt meine Haussprache). Auf der einen Seite implementiert das Programm einen extrem rudimentären MQTT-Server. Auf der anderen Seite nimmt es den Usernamen der MQTT-Client-Anmeldung als Tibber-Token, verbindet sich mit einem GraphQL-Websocket mit Tibber, und schiebt die empfangenen Werte im OpenWB-EVU-Format als MQTT-Messages an MQTT.
Das sollte funktionieren, weil OpenWB eben genau das, die Einbindung eines externen MQTT-Servers, erlaubt.

Damit gibt es 2 Möglichkeiten:
- Man lässt das Programm auf eigener, trusted Hardware laufen, konfiguriert OpenWB gegen den Mini-MQTT-Server, das Programm macht eine Websocket-Verbindung zu Tibber auf und holt die Werte.
- Ich ziehe eine Instanz inkl. TLS-Verschlüsselung "im Internet" hoch, gegen die sich genau 2 Personen mit dem nötigen Vertrauen mir ggü. mit Tibber verbinden können. Bzw: Wer zwar im Heimnetz keinen Dauer-Server im Zugriff hat, aber im Internet, installiert sich die Software dort.
- Eine andere Cloud-Variante wäre, wenn Tibber mich für mehr als 2 Verbindungen freischaltet, dann bleibt aber das Vertrauensproblem.
- Oder OpenWB hostet die Software als Cloudvariante, was weniger problematisch ist, weil OpenWB schon so die Daten zum Stromverbrauch erhält, und über die Kundendaten die Adresse hat. Es entstünde also für OpenWB-Hardware-Kunden kein zusätzliches Privacy-Problem.

Wie seht Ihr das? Gibt es Interessenten mit der Möglichkeit für die "Local-Variante"? Oder für die Cloud-Variante?
Je nach Interessenmenge und -richtung würde ich ggf. auch Tibber ggf. auf diesen Thread hinweisen und mal fragen, wie sie dazu denken. Am liebsten wäre uns allen (und nicht nur den OpenWB-Nutzern), wenn Tibber einfach MQTT direkt bereitstellen würde

Für heute erst mal fertig, Georg

Moin. Progress-Report: OpenWB 1.9 mit MQTT-Bridge konfiguriert, Daten (Stromzählerstand und Power) kommen vom Tibber Pulse an.

Wird aber noch hässlicher als oben geschrieben:
- Man muss die OpenWB in den Modus versetzen, beliebige MQTT-Set-Befehle zu empfangen (noch mehr Vertrauen nötig)
- Da (aus gutem Grund) Verschlüsselung fest vorgeschrieben ist, ist die Möglichkeit, meine Software auf irgendeinen Raspi daheim zu packen, echt erschwert: Man muss ein gültiges, offizielles Zertifikat einrichten, und der Name muss auflösbar sein.
- Eher Kleinkram: Die Konfiguration erzwingt, einen Topic-Prefix einzugeben.

Heißt: Nachdem ich nun liebevoll meinen Micro-MQTT-Server geschrieben habe, wäre für den lokalen Einsatz im heimischen Netz auf einem Raspi etc. eher ein MQTT-Client sinnvoll, der direkt den MQTT-Broker der OpenWB mit Daten versorgt.

Dafür würde ich gerne mal das Interesse abfragen. Für eine "lokaler Raspi"-Lösung hätte ich allerdings den Aufwand nicht treiben müssen: Dann hätte man den existierenden Tibber-Client für Python 3.9+ einfach um einen MQTT-Client erweitert und fertig.

Moin,

ich bin zwar noch kein openWB User, aber da euer Thread mir bei der Recherche geholfen hat möchte ich auch kurz mein Wissen hier teilen.

Die Tibber Pulse Bridge bietet über Umwege einen Local Mode. Dieser ist folgendermaßen zu erreichen:
1. Webserver der Tibber Bridge über den Setup Mode einschalten wie hier beschrieben
2. Über die URL http://tibber-bridge/data.json?node_id=1 kann man danach die Daten abrufen, die aus dem Stromzähler ausgelesen werden (Achtung: HEX Werte, bei mir im SML Format)
3. Diese SML Nachricht kann man entweder selbst encoden oder folgendes Projekt nutzen: https://github.com/micw/tibber-pulse-reader
Über eine Java Anwendung in einem Docker-Container wird die Bridge abgefragt und die Werte auf einen MQTT Server gepusht.
Standartmäßig wird alle 15 Sekunden ausgelesen, das kann aber konfiguriert werden.

Ich hoffe ich konnte dem ein oder anderen damit weiterhelfen

Hi!

Danke dir.

Bin beim ersten versuch gescheitert in den Modus zu kommen. Probiere es gleich nochmal ohne quengelige Kinder im Hintergrund.

@gvz

Ich meld mich bei dir wenn ich in dem local mode bin.

Moin, ja, das ist sehr interessant. Für den Web-Mode sollte es einfach sein, ein Modul zu schreiben. Und obendrein hat "lokal" den Charme höherer Verfügbarkeit.

myrng hat geschrieben: ↑Mi Mär 15, 2023 4:32 pm Moin,

ich bin zwar noch kein openWB User, aber da euer Thread mir bei der Recherche geholfen hat möchte ich auch kurz mein Wissen hier teilen.

Die Tibber Pulse Bridge bietet über Umwege einen Local Mode. Dieser ist folgendermaßen zu erreichen:
1. Webserver der Tibber Bridge über den Setup Mode einschalten wie hier beschrieben
2. Über die URL http://tibber-bridge/data.json?node_id=1 kann man danach die Daten abrufen, die aus dem Stromzähler ausgelesen werden (Achtung: HEX Werte, bei mir im SML Format)
3. Diese SML Nachricht kann man entweder selbst encoden oder folgendes Projekt nutzen: https://github.com/micw/tibber-pulse-reader
Über eine Java Anwendung in einem Docker-Container wird die Bridge abgefragt und die Werte auf einen MQTT Server gepusht.
Standartmäßig wird alle 15 Sekunden ausgelesen, das kann aber konfiguriert werden.

Ich hoffe ich konnte dem ein oder anderen damit weiterhelfen

Vielen Dank. Mir hats geholfen. Musste meine alte IR-USB-Schnittstelle gegen den Pulse tauschen und wollte die Daten aber weiter im Volkszähler haben. Wenns sonst noch jemand gebrauchen kann hier die paar Python Zeilen die bei mir gehen.

Wenn man Tibber in die OpenWB eingebunden hat, und oben in der Zeile auf "Stromtarif-Info" geht, bekommt man ja schon viel angezeigt. Auch was ich letzte Stunde verbraucht habe, und zu welchem Preis.

Eigentlich muss das TibberModul doch nur noch die Abfrage nach den Variabeln

- power
- powerProduction
- lastMeterProduction

durchführen?!