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 👍 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 <#2 (comment)>, 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 Android<https://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 GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWNGKOYNTSIUM4U34Q6JTWLYBX6SJAVCNFSM6AAAAAA5X3VILSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGAZDSNZWG4>. You are receiving this because you commented.Message ID: ***@***.***>