Tibber und OpenDTU-OnBattery

[johannesosterberg]

Zuerst einmal vielen Dank, das ist das OpenDTU was ich immer wollte.
Früher hatte ich einen Tasmota mit Hitachi-Lesekopf auf meiner modernen Messeinrichtung, wo die MQTT-Daten für L1, L2 und L3 kein Problem darstellen würden, aber da ich jetzt bei Tibber bin und deren Lesegerät die Schnittstelle blockiert, musste ich mir etwas einfallen lassen.

https://github.com/johannesosterberg/tibber_mqtt

Ich habe ein kleines Python Script geschrieben, das den gesamten Verbrauch aus der Tibber API ausliest und an meinen MQTT Broker sendet. Spannend ist, dass OpenDTU-OnBattery zwar für alle drei Leiter einen MQTT Input benötigt, aber wenn, wie bei mir, L2 und L3 einfach psydo Topics sind, funktioniert es genauso gut. Von der Idee her sollte es auch einfach mit einem Sonoff POW mit Tasmota Firmware funktionieren. Das könnte für den einen oder anderen spannend sein, um bis zu drei Verbraucher mit dem Inverter zu versorgen. Vielleicht sollte man das noch in die Readme aufnehmen.

Auf jeden Fall vielen Dank!

[helgeerbe]

Hallo @johannesosterberg, schön zu sehen, dass man da nicht alleine ist. Die Dokumentation hinkt tatsächlich hinterher. Wenn du magst, kannst du gerne da unterstützen und Verbesserungen als PR einstellen. Bitte immer auf den development branch.

[Adminius]

Hallo @johannesosterberg wenn ich richtig verstehe, wird dein Script mit #153 nicht mehr erforderlich sein. Dann hätte man alles in einem.
3 MQTT Topics sind zwar für 3 Phasen gedacht, aber je nach Quelle, kann es sein, dass man nur eine Phase oder nur Gesamtverbrauch hat, deswegen reicht ein Topic aus.

[johannesosterberg]

@Adminius Ja, habe ich noch nicht ausprobiert, aber theoretisch braucht man das Script nicht mehr. Hoffentlich ist die HTTP-API stabiler als der andere Kram von Tibber, da gab es oft Abbrüche, aber das kann auch an meinem Script liegen. Danke nochmal an die Community, erstaunlich wie schnell hier Fortschritte erzielt werden.

[Adminius]

wenn alle an einem Strang ziehen, läuft es echt schnell, ich bin selbst begeistert :)

[berni2288]

Hallo,

also mit #153 wird es die Möglichkeit gegeben Polling basiert (alle 5 Sekunden) von einer JSON URL Daten abzurufen.

Wenn ich mir allerdings die Tibber API so ansehe bin ich mir nicht sicher ob das hier reicht:

• Das ganze verwendet OAuth - wie lange ist so ein Bearer Authentication Token gültig? Wenn der nur eine gewisse Zeit gültig ist, dann wirds schlecht funktionieren. Wir haben keine Unterstützung für Login-URLs.
• Websockets werden von uns noch nicht unterstützt, das wäre aber sehr nützlich wenn man Live-Daten abrufen will. Polling geht zwar, aber die Performance ist schlecht und es stellt sich die Frage ob Tibber das irgendwann limitiert. HTTP requests alle 5 Sekunden sind wahrscheinlich nicht so gern gesehen weil das viel Overhead macht.
• HTTP POST requests werden nicht unterstützt derzeit, nur GET. Wär aber nicht so der Aufwand das zu implementieren.

Grundsätzlich sollte man es vermeiden die Live-Daten von seinem Zähler übers Internet abzurufen, weil so ein Internet Service kann immer wieder mal ausfallen oder in den Wartungsmodus gehen. Auch kann dein Internet ausfallen. Aber ich verstehe dass es hier wohl nicht anders geht. Der Einbau eines Shelly 3 EM wäre grundsätzlich besser.

Wir könnten natürlich in OpenDTU-OnBattery dediziert Unterstützung für Tibber oder OAuth und Websockets einbauen, ist aber sicher etwas Aufwand.

[rmenzing]

Man bekommt ein binäres File. Das kann ich hier nicht hochladen. Habe es nach hex gewandelt und zusätzlich durch einen sml Parser convertiert.

00000000: 1b 1b 1b 1b 01 01 01 01 76 07 00 1b 24 2a dc 8c ........v...$..
00000010: 62 00 62 00 72 63 01 01 76 01 01 07 00 1b 16 58 b.b.rc..v......X
00000020: 49 84 0b 06 45 4d 48 01 02 71 5c 18 fe 01 01 63 I...EMH..q....c
00000030: f9 4c 00 76 07 00 1b 24 2a dc 8d 62 00 62 00 72 .L.v...$..b.b.r
00000040: 63 07 01 77 01 0b 06 45 4d 48 01 02 71 5c 18 fe c..w...EMH..q..
00000050: 01 72 62 01 65 16 58 6c 4e 79 77 07 81 81 c7 82 .rb.e.XlNyw.....
00000060: 03 ff 01 01 01 01 04 45 4d 48 01 77 07 01 00 00 .......EMH.w....
00000070: 00 09 ff 01 01 01 01 0b 06 45 4d 48 01 02 71 5c .........EMH..q
00000080: 18 fe 01 77 07 01 00 01 08 00 ff 63 01 a2 01 62 ...w.......c...b
00000090: 1e 52 ff 56 00 15 3c 4e b1 01 77 07 01 00 02 08 .R.V..<N..w.....
000000a0: 00 ff 63 01 a2 01 62 1e 52 ff 56 00 48 63 07 5d ..c...b.R.V.Hc.]
000000b0: 01 77 07 01 00 01 08 01 ff 01 01 62 1e 52 ff 56 .w.........b.R.V
000000c0: 00 15 3c 4e b1 01 77 07 01 00 02 08 01 ff 01 01 ..<N..w.........
000000d0: 62 1e 52 ff 56 00 48 63 07 5d 01 77 07 01 00 01 b.R.V.Hc.].w....
000000e0: 08 02 ff 01 01 62 1e 52 ff 56 00 00 00 00 00 01 .....b.R.V......
000000f0: 77 07 01 00 0f 07 00 ff 01 01 62 1b 52 ff 55 00 w.........b.R.U.
00000100: 00 b3 4e 01 77 07 81 81 c7 82 05 ff 01 01 01 01 ..N.w...........
00000110: 83 02 8b de 3c 9d f8 3c 29 30 98 2f 77 ae b8 37 ....<..<)0./w..7
00000120: de d3 a6 32 fc ab b2 2d 19 43 4e cb 0d 12 aa f9 ...2...-.CN.....
00000130: 2c 05 2a 9f d8 18 65 04 6d ea 01 a7 1c 15 a5 d3 ,....e.m.......
00000140: 51 fd 01 01 01 63 d8 25 00 76 07 00 1b 24 2a dc Q....c.%.v...$.
00000150: 8e 62 00 62 00 72 63 02 01 71 01 63 2e c8 00 00 .b.b.rc..q.c....
00000160: 1b 1b 1b 1b 1a 01 23 04

curl -s -u admin:PASWORD http://192.168.0.122/data.json?node_id=5 | python3 pysmlparser.py

transaction_id: 001b242ae40c
group_no : 0
abort_on_error: 0
message_body
codepage : None
client_id : None
req_file_id: 001b16584c04
server_id : 06454d480102715c18fe
ref_time : None
sml_version: None
crc16 : 34993

transaction_id: 001b242ae40d group_no : 0 abort_on_error: 0 message_body client_id : None server_id : 06454d480102715c18fe list_name : None act_sensor_time : 374894106 val_list: obis : 8181c78203ff (129-129:199.130.3*255) status : None val_time : None unit : None scaler : None value : EMH value_signature: None -> (Hersteller-Identifikation) obis : 0100000009ff (1-0:0.0.9*255) status : None val_time : None unit : None scaler : None value : 06454d480102715c18fe value_signature: None -> (Geräteeinzelidentifikation) obis : 0100010800ff (1-0:1.8.0*255) status : 418 val_time : None unit : 30 scaler : -1 value : 356273841 value_signature: None -> 35627384.1Wh (Zählerstand Bezug Total) obis : 0100020800ff (1-0:2.8.0*255) status : 418 val_time : None unit : 30 scaler : -1 value : 1214455362 value_signature: None -> 121445536.2Wh (Zählerstand Einspeisung Total) obis : 0100010801ff (1-0:1.8.1*255) status : None val_time : None unit : 30 scaler : -1 value : 356273841 value_signature: None -> 35627384.1Wh (Zählerstand Bezug Tarif 1) obis : 0100020801ff (1-0:2.8.1*255) status : None val_time : None unit : 30 scaler : -1 value : 1214455362 value_signature: None -> 121445536.2Wh (Zählerstand Einspeisung Tarif 1) obis : 0100010802ff (1-0:1.8.2*255) status : None val_time : None unit : 30 scaler : -1 value : 0 value_signature: None -> 0.0Wh (Zählerstand Bezug Tarif 2) obis : 01000f0700ff (1-0:15.7.0*255) status : None val_time : None unit : 27 scaler : -1 value : 46254 value_signature: None -> 4625.4W obis : 8181c78205ff (129-129:199.130.5*255) status : None val_time : None unit : None scaler : None value : 8bde3c9df83c2930982f77aeb837ded3a632fcabb22d19434ecb0d12aaf92c052a9fd81865046dea01a71c15a5d351fd value_signature: None -> (Öffentlicher Schlüssel) list_signature : None act_gateway_time: None crc16 : 29397 transaction_id: 001b242ae410 group_no : 0 abort_on_error: 0 message_body global_signature: None crc16 : 10582

Hoffe das hilft dir was
Gruß
Richie

[rmenzing]

sml.txt

[johannesosterberg]

Ich glaube dein Zähler ist noch nicht geöffnet?
Es fehlt die 1-0:16.7.0 (Leistung (Momentan)) in deiner SML-Datei.

Da ich das nicht wirklich testen kann, muss dir jemand helfen, der das schon mal gemacht hat.

[rmenzing]

Mein Zähler ist geöffnet, Tibber funktioniert.
Anbei noch die aktuelle Leistung

obis : 01000f0700ff (1-0:15.7.0*255)
status : None
val_time : None
unit : 27
scaler : -1
value : 44806
value_signature: None
-> 4480.6W

[johannesosterberg]

Ach so, im Internet stand immer nur etwas von 1-0:16.7.0, was bei mir soweit auch gepasst hat. Wie gesagt, ich kann das nicht wirklich testen und dir in diesem speziellen Fall leider nicht weiterhelfen. Bei mir ist schon alles in Assci und ich kann das mit einer relativ einfachen Funktion auslesen. Du könntest aber mal mit Chatgpt probieren, ob du deinen Python-Code so erweitern kannst, dass er einen Webserver öffnet und dann den Wert als JSON ausgibt, so dass das OpenDTU das dann lesen kann, so hatte ich auch angefangen.

[johannesosterberg]

Tibber hat auf deren Seite was von HTTP POST mit curl stehen und dachte deswegen es würde gehen.

curl \ -H "Authorization: Bearer 5K4MVS-OjfWhK_4yrjOlFe1F6kJXPVf7eQYggo8ebAE" \ -H "Content-Type: application/json" \ -X POST \ -d '{ "query": "{viewer {homes {currentSubscription {priceInfo {current {total energy tax startsAt }}}}}}" }' https://api.tibber.com/v1-beta/gql

Ich dachte, es ginge auch per Post und man müsste nur den Authorization Key dorthin schicken, aber ich gebe dir Recht, das Ganze über das Internet zu machen ist nicht ideal. Im Moment bin ich wieder mit einem Tasmota mit Hichi Auslesekopf unterwegs, der das ganze über MQTT macht. Perspektivisch muss ich mir was überlegen um Tibber Pulse und Tasmota gleichzeitig am Zähler zu betreiben, ab 1.6 wäre bei mir der Flex-Tarif am Start, vielleicht mit einem Prisma :)

[berni2288]

Schau dir auch mal https://github.com/MSkjel/LocalPulse2Tibber an, damit kann man die Tibber-Daten lokal abgreifen, scheinbar verwendet das auch MQTT intern? Aber keine Ahnung ob das für die deutsche Version auch funktioniert ;) Sieht etwas kompliziert aus.

[johannesosterberg]

@berni2288 Ja, das hatte ich auch im Kopf, aber das ist für mich eher Plan B, nicht dass Tibber dann denkt, ich will sie übervorteilen, weil man rein technisch so Werte manipulieren könnte? Vielleicht schreibe ich Tibber einfach mal an, technisch müsste es ja möglich sein, die Werte auch an einen zweiten MQTT Broker zu schicken, dann müsste der auch nicht so viel Rechenkapazität vorhalten. Aber ich werde erst mal versuchen zwei IR Leseköpfe gleichzeitig anzuschließen.

[johannesosterberg]

Nun, ich habe schon einiges ausprobiert, z.B. eine Weiterleitung der Infrarotdaten mit einem zweiten Lesekopf, so dass ich ein Tasmota und den Tibber Puls gleichzeitig benutzen kann, was nicht stabil funktioniert hat, auch die Lösung über die Tibber-API war nicht wirklich stabil.
Meine momentan funktionierende Lösung sieht wie folgt aus.

Nach der Anleitung:

https://forum.fhem.de/index.php?topic=133358.0

konnte ich die Pulse-Bridge über einen get reqest dazu bringen, die Daten der moderne Messeinrichtung auszugeben.

Der Aufruf sieht wie folgt aus

http://admin:passwort@ip_der_Bride/data.json?node_id=1

Mein Zähler (EBZ DD32R)gibt die Daten im Asci OBIS Format aus, manchmal machen die auch OBIS in Hex, aber bei mir nicht.

/EBZxxxx
1-0:0.0.0255(1EBZxxxxxxx)
1-0:96.1.0255(1EBZxxxxx)
1-0:1.8.0255(001304.66128930kWh)
1-0:2.8.0255(000025.30378515kWh)
1-0:16.7.0255(-000010.84W)
1-0:36.7.0255(-000021.21W)
1-0:56.7.0255(000010.37W)
1-0:76.7.0255(000000.00W)
1-0:32.7.0255(237.3V)
1-0:52.7.0255(237.8V)
1-0:72.7.0255(236.9V)
1-0:96.5.0255(xxxx)
0-0:96.8.0255(xxx)
!

Diese Daten greife ich dann mit einem Python-Skript ab und bereite sie soweit auf, dass ich ein JSON an OpenDTU übergeben kann. Das Skript läuft auf einem Rasberry PI im gleichen Netzwerk.
Diese Lösung funktioniert nun seit einem Monat recht gut. Schöner wäre es natürlich, wenn ich den Umweg über den Rasberry PI nicht bräuchte, aber vielleicht kommt das ja noch.

Vielleicht hat jemand ein ähnliches Problem und kann damit weiter basteln.

[linuxdep]

Hi, habe zwar etwas anderes vor, aber passt hier glaube trotzdem ganz gut rein, da es um die Schnittstelle zum openDTUonBattery geht.
Also ich habe einen Lesekopf mit ESPhome auf dem Zähler, wie kann man diesen abfragen oder wie benötigt openDTU die Daten, damit es als Verbrauchsdaten ausgewertete werden kann. Habt ja was von JSON geschrieben, wird das an openDTU gesendet oder holt die sich das ab?

[Adminius]

MQTT Brocker ist genauso Verfügbar wie HA, verstehe das Problem nicht.
ESP Home kann sowohl per MQTT als auch direkt zu HA die Daten senden.
Open DTU nimmt dann die Daten von MQTT Brocker, HA direkt von ESPHome

[stefankolling]

@johannesosterberg Funktioniert deine Lösung mit der Kombination aus ESP32, Tibber Pulse und DTU weiterhin zuverlässig? Könnte genau das auch gebrauchen, würde mich freuen wenn du ein Git dafür machen würdest.

[johannesosterberg]

@stefankolling Ja, es funktioniert wunderbar. Ich habe nur im Moment keine Zeit, den Code fertigzustellen und hochzuladen. Es ist auch sehr Stromzähler-spezifisch. Hast du deinen Tibber schon dazu gebracht, die Daten freizugeben? Und etwas auf http://admin:passwort@ip_der_bride/data.json?node_id=1 anzuzeigen?

[stefankolling]

@johannesosterberg Genau, das klappt bereits. Die fünfte Zeile der Ausgabe scheint dabei mein aktueller Verbrauch zu sein (per Abgleich mit der Tibber App). Einen ESP32 und openDTU muss ich mir jetzt erst kaufen, daher hat es mich interessiert ob du weiterhin zufrieden bist und ob dein Skript verwendbar ist.

[johannesosterberg]

@stefankolling Vielleicht ist die Tatsache, dass es jemandem helfen könnte, ein Ansporn für mich, das zu Ende zu bringen. Das Python-Script oben funktioniert nach dem gleichen Prinzip, da kannst du schon mal ausprobieren, ob die Vorbedingungen funktionieren, das kannst du ohne opendtu und esp32 ausprobieren.

[marvincarstensen]

Ich habe das bestehende HTTP Power Meter erweitert, sodass nun auch der Tibber Pulse direkt über die Bridge ausgelesen werden kann. Vorausgesetzt der lokale Web-Server der Bridge wurde aktiviert: #915

[PhilJaro]

Erstmal finde ich Deine Lösung cool! Mir stellen sich aber ein paar Fragen, ohne den Code bisher genauer durgeschaut zu haben. Beachtest du das Problem, dass die Bridge auch veraltete Werte ausgibt wenn man einfach per HTTP anfrägt. Es ist ja gut möglich, dass die letzte Verbindung zum Pulse IR reader schon 5 Sekunden alt ist, der letzte Wert auf der Bridge wird dann aber als "aktuell" an die DTU weitergegeben.
Das kann zu einem starken Schwanken führen.

Desweiteren gibts, wie schon geschreiben wurde, verschiedene Arten in welcher Form die Informationen auf der Bridge bereitstehen, wäre schön, wenn die Lösung für jeden Pulse nutzer funktioniert.
Am besten wäre natürlich wenn es eine möglichkeit gabe auf dem Pulse einen zweiten MQTT Server zu hinterlegen, aber ich denke davon kann man nur Träumen ;)

[johannesosterberg]

So wie ich das sehe, liest der Puls die Werte immer neu, wenn er eine HTTP-Anfrage bekommt. Die Befehlskette aber sowieso nicht so super schnell, die Befehler muss ja auch noch an den Wechselrichter gesendet werden usw. In der Praxis ist das nicht so dramatisch, ob das jetzt 2, 4 oder 8 Sekunden dauert, bis der Wechselrichter sich wieder stabilisiert hat.

Einen Code zu schreiben, der für jeden Zähler funktioniert, ist wohl nur möglich, wenn hier Beispiele eingestellt werden.

MQQT direkt vom Pulse wäre natürlich am einfachsten :).

[PhilJaro]

"So wie ich das sehe, liest der Puls die Werte immer neu, wenn er eine HTTP-Anfrage bekommt"

Dem ist leider nicht so, die Bridge speichert den letzten Wert und wird immer diesen ausgeben, bis eine neuer vom Pulse kommt.

"In der Praxis ist das nicht so dramatisch, ob das jetzt 2, 4 oder 8 Sekunden dauert, bis der Wechselrichter sich wieder stabilisiert hat."

Die annahme scheint auf den ersten Blick richtig zu sein, spielt man das aber mal durch, sind die Folgen schon größer.
Veraltete Daten können zum häufigen abschalten des Wechselrichters führen, da das Powerlimit oft ins Negative rutscht.
Angenommen der WR speist mit 600 Watt ein und der Verbrauch sinkt auf 100 Watt, nun reduziert die DTU auf diese 100 Watt, die nächste Anfrage an den Pulse beinhaltet diese absenkung auf 100 Watt noch nicht und meldet immernoch -500 Watt als aktuellen Wert, daraufhin schaltet die DTU den WR ab, da das Powerlimit auf -400W und somit unter das Minimum sinkt.

[johannesosterberg]

"Dem ist leider nicht so, die Bridge speichert den letzten Wert und wird immer diesen ausgeben, bis eine neuer vom Pulse kommt."

Das Problem wird man ja immer mit dem Puls haben.

"Die annahme scheint auf den ersten Blick richtig zu sein, spielt man das aber mal durch, sind die Folgen schon größer.
Veraltete Daten können zum häufigen abschalten des Wechselrichters führen, da das Powerlimit oft ins Negative rutscht.
Angenommen der WR speist mit 600 Watt ein und der Verbrauch sinkt auf 100 Watt, nun reduziert die DTU auf diese 100 Watt, die nächste Anfrage an den Pulse beinhaltet diese absenkung auf 100 Watt noch nicht und meldet immernoch -500 Watt als aktuellen Wert, daraufhin schaltet die DTU den WR ab, da das Powerlimit auf -400W und somit unter das Minimum sinkt."

Dann wäre es besser noch Träger zu reagieren oder langsam hoch und runter zu fahren? Ich weiß auch nicht, ob es den Wechselrichter stört, wenn er ständig hoch und runter geschaltet wird?

Bei mir läuft das Ding jetzt seit 3 Monaten zuverlässig, ob da jetzt ein bisschen was daneben geht, spielt für mich keine Rolle.

[mikerway]

Danke @marvincarstensen , funktioniert wirklich gut! Hoffentlich "sperrt" Tibber diese Möglichkeit nicht durch ein update...