Publish to Tibber

[ggrote]

Hi,

leider kann ich dich anders nicht erreichen, daher als Github Ticket: Ich versuche auch mit meinem eigenen Lesekopf Daten an Tibber zu senden und bin dabei auf dein Projekt gestoßen. Hast du mal versucht wie es sich ohne das Senden der Metrics und Events verhält? Also wenn man nur die Daten des Zählers sendet? Oder mag Tibber das dann auch nicht?

Beste Grüße

[jsphuebner]

Ja, es hat anfangs die "May the force be with you" message gefehlt, daraufhin hat Tibber irgendwann keine Daten mehr angenommen. Ich vermute ähnlich verhielte es sich bei fehlenden Metrics, habe ich aber nicht probiert

[ggrote]

Ah okay, ich dachte zuerst das wäre ein Scherz von dir mit der Message. :) Hast du einen Screenshot wie es in der Tibber App aussehen muss? Also woran merke ich, dass die Werte angenommen werden?

[mdkeil]

Hat schon wer Erfahrungen damit, wenn die Meter Daten als raw-sml vorliegen? --werden so auch versendet, topic ist ebenfalls bekannt.

[micw]

Hallo Johannes,

sehr schönes Projekt und vielen Dank für den Link auf mein Blog. Ich hatte auch schon darüber nachgedacht, den Pulse so zu ersetzen. Leider hat mir bisher die Zeit gefehlt, die MQTT-Daten abzugreifen und zu analysieren. Außerdem läuft meine Alternative Lösung (Zähler per IR lessen und die Daten per IR 1:1 wieder ausgeben) sehr stabil. Das würde ja auch mit Deiner Lesehardware funktionieren.

Hättest Du vielleicht Lust, die MQTT-Kommunikation ein wenig genauer zu dokumentieren? Also wann welche Paket auf welcher Topic kommt und wie die Pakete mit den SML-Daten aussehen?

Viele Grüße, Michael.

[jsphuebner]

Hallo Michael,

danke für den Blogbeitrag, ohne den wärs schwierig gewesen ins Thema einzusteigen Die Variante hatte ich mir auch überlegt, wenn ich das direkte Senden nicht hinbekommen hätte.

Kann noch etwas zur Kommunikation schreiben, sie ist im Grunde recht simpel. Im Echtzeit-Takt gehen die OBIS Daten raus und alle paar Minuten die Metrics. Einmal am Start das "Hello"

[jsphuebner]

Hat schon wer Erfahrungen damit, wenn die Meter Daten als raw-sml vorliegen? --werden so auch versendet, topic ist ebenfalls bekannt.

Das Topic ist bekannt? Wie lautet es?

[mdkeil]

$aws/rules/ingest_tibber_bridge_data/tibber-bridge/<UID>/publish/TFD01/<EUI>/sml

[jsphuebner]

Danke :+1: Ich habe in der tibber readme jetzt ein paar Infos übers Protokoll reingeschrieben

[mdkeil]

Kein Problem.. die topics sind aber glaube case sensitive, sprich das SML am Ende muss komplett klein geschrieben werden.

[Holger237237]

Hallo Zusammen, Bis vor ein paar Tagen hatte ich ein SML-Lesekopf der mit zuverlässig Daten der Tasmota über MQTT an meinen Openhab-Server lieferte. Jetzt habe ich stattdessen einen Pulse, der zwar Tibber stabil beliefert, jedoch fällt die Datenlieferung an Openhab immer wieder aus. Das Projekt hier könnte da wohl eine Lösung liefern. Ich habe es aber noch nicht ganz verstanden. Könnte ich meine alte stabile Lösung wieder im Betrieb nehmen und meine MQTT-Daten zu Tibber senden? Wo muss ich dann was ergänzen? Im MQTT-Server? Oder im Tasmota? Danke Holger

[jsphuebner]

Tasmota und openHAB sagt mir nur bedingt was, das Projekt hier ist ja quasi "bare metal". Aber genau das ist das Ziel, den Pulse durch einen eigenen Lesekopf zu ersetzen. Du brauchst nur die Rohdaten vom Zähler auf einem beliebigen MQTT topic.

[Holger237237]

Die Rohdaten liegen mir ja als MQTT topic vor. Der Hardware Teil wäre also erledigt. Nur wie ich dies dann zu Tibber bekomme, habe ich nicht verstanden.

Danke

Johannes Huebner @.***> schrieb am So., 29. Okt. 2023, 08:11:

Tasmota und openHAB sagt mir nur bedingt was, das Projekt hier ist ja quasi "bare metal". Aber genau das ist das Ziel, den Pulse durch einen eigenen Lesekopf zu ersetzen. Du brauchst nur die Rohdaten vom Zähler auf einem beliebigen MQTT topic.

— Reply to this email directly, view it on GitHub https://github.com/jsphuebner/esp-egycounter/issues/2#issuecomment-1784018632, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWNGKOYYTOL6Q7R64Z6M3MLYBXXP3AVCNFSM6AAAAAA5X3VILSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGAYTQNRTGI . You are receiving this because you commented.Message ID: @.***>

[mdkeil]

Wenn du die Daten nicht in kurzen Intervallen für Steuerungsaufgaben benötigst, reicht es auch, wenn du dir die Zählerdaten von der Bridge ausliest.. 5-10s Intervall sollte da problemlos möglich sein.

[micw]

@jsphuebner Ist es egal, ob man TFD01//obis_stream oder TFD01//SML sendet? Wie sieht so ein "obis_stream" denn aus? Und ist "binary SML format" tatsächlich ein Binär-Blob? Sind das genau die Daten, die man auch im Pulse angezeigt bekommt?

Obis_Stream finde ich ja sehr interessant, da Tibber noch nicht jeden Zähler unterstützt. Wenn man selbst die Daten als OBIS bereitstellen kann, könnte man darüber generisch jeden Zähler unterstützen. Ich könnte mir vorstellen, das als weitere Datensenke in https://github.com/micw/homedatabroker zu implementieren.

Ich habe mich übrigens für eine reine Hardware-Lösung entschieden. Damit funktioniert Tibber unabhängig von meiner eigenenInfrastruktur: https://github.com/micw/ir-lesekopf

[Holger237237]

Dieses interval wäre mehr als ausreichend. Aktuell nutze ich nur 30s

Gesendet von Outlook für Androidhttps://aka.ms/AAb9ysg

---

From: mdkeil @.> Sent: Sunday, October 29, 2023 9:11:32 AM To: jsphuebner/esp-egycounter @.> Cc: Holger237237 @.>; Comment @.> Subject: Re: [jsphuebner/esp-egycounter] Publish to Tibber (Issue #2)

Wenn du die Daten nicht in kurzen Intervallen für Steuerungsaufgaben benötigst, reicht es auch, wenn du dir die Zählerdaten von der Bridge ausliest.. 5-10s Intervall sollte da problemlos möglich sein.

— Reply to this email directly, view it on GitHubhttps://github.com/jsphuebner/esp-egycounter/issues/2#issuecomment-1784029767, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AWNGKOYNTSIUM4U34Q6JTWLYBX6SJAVCNFSM6AAAAAA5X3VILSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGAZDSNZWG4. You are receiving this because you commented.Message ID: @.***>

[mdkeil]

@micw

unter /sml wird genau das erwartet, was man auf der Bridge auch unter Daten abrufen kann. Der Stream wird auch so Richtung Tibber verschickt..

[micw]

Dieses interval wäre mehr als ausreichend. Aktuell nutze ich nur 30s

Das kannst du mir meinem Tool ohne großen Aufwand machen. Tibber Http als source, mqtt als Output, starten, fertig ;-)

[mdkeil]

Wie sieht so ein "obis_stream" denn aus?

Da würde ich mich anschließen.. wollte eigentlich den raw-sml stream schicken.. das was ich aber auslese ist 24 byte kleiner-- keine Ahnung, inwiefern der übermittelte sml-stream noch Zusatzdaten enthält. Ich würde dann eher mal versuchen einen entsprechenden obis-stream aus meinen Daten zu erzeugen.. ist glaube einfacher.

[micw]

tibber obis_stream ist genug Futter für Google, hab das hier gefunden: https://openinverter.org/forum/viewtopic.php?p=60335&sid=c1e87bdf5e381e16a5ecfe574e2557dd#p60335

by johu » Thu Aug 17, 2023 1:31 pm

I have finally cracked it. It seems tibber now supports my meter so I was able to intercept some actual data packets.

The data is sent in topic $aws/rules/ingest_tibber_bridge_data/tibber-bridge/xxx/publish/TJH01/yyy/obis_stream xxx is the long uid and yyy the eui (see metric)

The contents is just the raw data read from the meter with one newline removed

/EBZ5DD3BZ06ETA_107
1-0:0.0.0*255(1EBZzzzz)
1-0:96.1.0*255(1EBZzzzz)
1-0:1.8.0*255(009094.27916715*kWh)
1-0:16.7.0*255(000169.25*W)
1-0:36.7.0*255(000133.51*W)
1-0:56.7.0*255(000035.74*W)
1-0:76.7.0*255(000000.00*W)
1-0:32.7.0*255(233.4*V)
1-0:52.7.0*255(234.5*V)
1-0:72.7.0*255(234.6*V)
1-0:96.5.0*255(001C0104)
0-0:96.8.0*255(08F0EAB3)
!

I am currently brushing up the code then will publish the python script. You will need to extract the longer tibber uid that is found in the parameter "mqtt_topic", the bridge id that you can obtain by running the "version" command on the console, and the "EUI" of the actual IR device which is found on the "Nodes" tab. Then you also need to extract the three certificates for the MQTT connection into PEM files.

[mdkeil]

Das hatte ich auch gefunden, bringt mich aber nur bedingt weiter.. das scheint auch kein Zweirichtungszähler zu sein.

[micw]

Der hat ja auch nur andere OBIS-Codes

Edit: https://de.wikipedia.org/wiki/OBIS-Kennzahlen

[mdkeil]

stimmt natürlich.. ich brauche es zum Glück aber nicht mehr.. habe es mit dem sml-stream via node red hinbekommen.. Werte werte angenommen und angezeigt.. werde mich morgen dann nochmal an die Metriken machen. Wenn alles fertig ist, werde ich das Ergebnis zur Verfügung stellen.

[TheCutter]

stimmt natürlich.. ich brauche es zum Glück aber nicht mehr.. habe es mit dem sml-stream via node red hinbekommen.. Werte werte angenommen und angezeigt.. werde mich morgen dann nochmal an die Metriken machen. Wenn alles fertig ist, werde ich das Ergebnis zur Verfügung stellen.

Welches Plugin für Node-Red hast du genutzt um SML Binary lesen zu können? Das Smartmeter Plugin funktioniert für unseren Anwendungsfall ja nicht...

[mdkeil]

Ich nutze auf meinem RPI ser2net, um den entsprechenden Port auszulesen und die Ausgabe auf einen lokalen tcp-port zu binden. In Node Red nutze ich dann den "tcp in"-Node, verbinde mich auf den host:port mit Ausgabe in einem Buffer. Pro raw-sml-stream ergibt das 30separate messages (29x 8byte Buffer, 1x 4byte Buffer), die ich dann via Join-Node (manuell, binärer Buffer, verbunden mit buffer [keine Eintragung] zu einer Nachricht (260byte Buffer) verbinde. Die 4byte Buffer Nachricht bekommt msg.complete. Die 2 Metriken und die Event-Message habe ich ebenfalls umgesetzt.. Muss ich heute Abend dann alles mal Testen.

[mdkeil]

Test erfolgreich-- läuft seit über 2h durch. Edit: 31.10. // über 24h problemlos

tibbersend_Node-RED.json

[TheCutter]

Danke! Ich habe ein Wemos D1 Mini mit einer modifizierten Version von https://github.com/mruettgers/SMLReader laufen, der mir die Daten als Raw Binary und geparstes SML in MQTT published. So kann ich die Daten direkt selber verwenden und die Binärdaten direkt an Tibber weiterleiten. So zumindest mein Plan.

Habt ihr euch schon Gedanken gemacht zu den Metriken in Bezug auf Versionsnummern und OTA Updates? Der Pulse kann ja auch Kommandos empfangen von Tibber. Da wird die Selbstbaulösung ja nicht drauf reagieren.

[jsphuebner]

Habt ihr euch schon Gedanken gemacht zu den Metriken in Bezug auf Versionsnummern und OTA Updates? Der Pulse kann ja auch Kommandos empfangen von Tibber. Da wird die Selbstbaulösung ja nicht drauf reagieren.

Nein, noch nicht. Eine Idee wäre mal alles mitzuloggen, was von Tibber so reinkommt. Momentan wird das nur auf den lokalen MQTT weitergeleitet und niemand liest es. Eventuell müsste man dann die Versionsnummern in den Metrics anpassen als Reaktion?

[TheCutter]

Ah okay, ja mitloggen würde ich es auch und dann mal schauen. Die Versionsnummer ändern wäre vermutlich irgendwann sinnvoll. :)

[mdkeil]

Ähnliches habe ich auch vor.. wenn sich von der reinen Struktur der Metriken nichts ändert, sollte es auch kein großes Problem sein eine automatische Änderungen der Metriken zu erzeugen.. was ich am Ende des Tages aber vermeiden will, dass ich hier und da wieder die Bridge anschließen muss, um diese zu aktualisieren um dann schlussendlich die neuen Metriken zu erhalten..

[mdkeil]

Eine Idee wäre mal alles mitzuloggen, was von Tibber so reinkommt. Momentan wird das nur auf den lokalen MQTT weitergeleitet und niemand liest es.

Sind denn die topics ggfs. schon bekannt?

[TheCutter]

Sind denn die topics ggfs. schon bekannt?

tibber-bridge/<UID>/receive

ist das Topic für eingehende Nachrichten.

[irqnet]

Hat jemand ne grobe Idee in welche Richtung ich suchen muss, warum ich hier laufend CONNECT Meldungen bekomme?

Initial hatte das Ganze einmal funktioniert, aber seitdem der Pulse mit dem IR in Betrieb ist und in der App Werte anzeigt. stehe ich via MQTT scheinbar nichts mehr, oder der Connect wird abgewiesen?!

[mdkeil]

Habt ihr euch schon Gedanken gemacht zu den Metriken in Bezug auf Versionsnummern und OTA Updates? Der Pulse kann ja auch Kommandos empfangen von Tibber. Da wird die Selbstbaulösung ja nicht drauf reagieren.

Nein, noch nicht. Eine Idee wäre mal alles mitzuloggen, was von Tibber so reinkommt. Momentan wird das nur auf den lokalen MQTT weitergeleitet und niemand liest es. Eventuell müsste man dann die Versionsnummern in den Metrics anpassen als Reaktion?

kurze Rückmeldung.. mein node-red-flow läuft seit Oktober '23 durch, ohne eine Anpassung der Metriken.. habe bis dato glaube auch auf dem tibber-bridge//receive - topic noch nichts erhalten oder ich habe es übersehen ;)

[mdkeil]

@jsphuebner @micw

Eine kurze Frage.. Habe für einen anderen User meinen flow angepasst, da er einen nicht tibber-kompatiblen Zähler nutzt. folgender obis_stream wird ausgelsen und auf das entsprechende topic geschickt.

/LOG5LK13BE803039
1-0:96.1.0*255(001LOG0065477994)
1-0:1.8.0*255(010344.4321*kWh)
1-0:2.8.0*255(000000.0000*kWh)
1-0:16.7.0*255(000426*W)
1-0:32.7.0*255(239.0*V)
1-0:52.7.0*255(238.8*V)
1-0:72.7.0*255(239.3*V)
1-0:31.7.0*255(000.17*A)
1-0:51.7.0*255(001.64*A)
1-0:71.7.0*255(000.32*A)
1-0:81.7.1*255(117*deg)
1-0:81.7.2*255(241*deg)
1-0:81.7.4*255(030*deg)
1-0:81.7.15*255(036*deg)
1-0:81.7.26*255(014*deg)
1-0:14.7.0*255(49.9*Hz)
1-0:1.8.0*96(00006.6*kWh)
1-0:1.8.0*97(00047.1*kWh)
1-0:1.8.0*98(00144.3*kWh)
1-0:1.8.0*99(00865.4*kWh)
1-0:1.8.0*100(10344.4*kWh)
1-0:0.2.0*255(ver.03,432F,20170504)
1-0:96.90.2*255(0F66)
1-0:97.97.0*255(00000000)
!

In der App laufen aber keine Daten ein, die Metriken schon. Kann es ggfs sein, dass "gewisse" Zählerdaten abgeglichen werden mit der Kompatibilitätsdatenbank? Wenn ja, müsste man diese ja vorab ersetzen und dadurch einen anderen Zählertyp vortäuschen?! Oder ob der obis_stream zu "komplex" ist? Wie gesagt, alles reine Mutmaßung.

[kalaws]

@jsphuebner @micw

Eine kurze Frage.. Habe für einen anderen User meinen flow angepasst, da er einen nicht tibber-kompatiblen Zähler nutzt. folgender obis_stream wird ausgelsen und auf das entsprechende topic geschickt.

/LOG5LK13BE803039
1-0:96.1.0*255(001LOG0065477994)
1-0:1.8.0*255(010344.4321*kWh)
1-0:2.8.0*255(000000.0000*kWh)
1-0:16.7.0*255(000426*W)
1-0:32.7.0*255(239.0*V)
1-0:52.7.0*255(238.8*V)
1-0:72.7.0*255(239.3*V)
1-0:31.7.0*255(000.17*A)
1-0:51.7.0*255(001.64*A)
1-0:71.7.0*255(000.32*A)
1-0:81.7.1*255(117*deg)
1-0:81.7.2*255(241*deg)
1-0:81.7.4*255(030*deg)
1-0:81.7.15*255(036*deg)
1-0:81.7.26*255(014*deg)
1-0:14.7.0*255(49.9*Hz)
1-0:1.8.0*96(00006.6*kWh)
1-0:1.8.0*97(00047.1*kWh)
1-0:1.8.0*98(00144.3*kWh)
1-0:1.8.0*99(00865.4*kWh)
1-0:1.8.0*100(10344.4*kWh)
1-0:0.2.0*255(ver.03,432F,20170504)
1-0:96.90.2*255(0F66)
1-0:97.97.0*255(00000000)
!

In der App laufen aber keine Daten ein, die Metriken schon. Kann es ggfs sein, dass "gewisse" Zählerdaten abgeglichen werden mit der Kompatibilitätsdatenbank? Wenn ja, müsste man diese ja vorab ersetzen und dadurch einen anderen Zählertyp vortäuschen?! Oder ob der obis_stream zu "komplex" ist? Wie gesagt, alles reine Mutmaßung.

Is your solution working without you having bought a Pulse first? Think it would work in Sweden? We don’t have Tibber Bridge I think.

Update: Actually, what I would ideally like to do is to publish solar production data as I have an inverter that’s not supported by Tibber.

[mdkeil]

you need to buy a pulse first.. I think It should work in Sweden too.. but I think, the mqtt-topics are different and you have to do some trial and error.. its not that simple I think.. for your solar inverter I don't think, that there is a simple mqtt-solution.