Ab dem 15.5. sind wir beim Tibber und ich wollte natürlich den Tarif mit stündlicher Abrechnung um mein E-Auto zu günstigen Zeiten zu laden und eventuell sogar meinen kleinen 1,5 kWh Heimspeicher. Nun hat sicher aber herausgestellt, dass der Pulse zwar grundsätzlich mit eBZ Zählern kompatibel ist aber nicht mit meiner Version. Ich kann den Pulse zurückschicken und bekomme mein Geld zurück, aber ich habe da einen anderen Plan.
Zumal ich den Stromzähler ohnehin mit meiner Selbstbaulösung auslese, könnte ich doch einfach per IR ein Telegramm senden, das der Pulse versteht. Damit ließe sich natürlich auch betrügen aber das ist nicht der Plan. Noch geschmeidiger wäre es natürlich, direkt mit der Bridge zu kommunizieren, aber im Gegensatz zu den Stromzählerprotokollen ist das Funkprotokoll ja nicht offen. Und noch viel geschmeidiger wäre eine direkte Kommunikation mit der Tibber API.
Also erstmal: Weiß jemand welches Format der Pulse versteht?
Ich wundere mich schon lange wie das mit dem Pulse noch gut gehen kann. Einen beliebig großen "Stromspeicher" in Software zu implementieren ist trivial und ich vermute es haben schon einige gemacht. Vermutlich halten die schön die Füße still, aber sobald sowas für 30€ auf eBay auftaucht ist Schluß mit Lustig.
Eher umfangreich, weil SML für alles mögliche verwendet wird. Erste Erkenntnis: das Telegramm beginnt immer mit 1B 1B 1B 1B 01 01 01 01 und endet mit einer CCITT-CRC16 . Gängige Übertragungsgeschwindigkeit ist scheinbar 96008N1
Es gibt viele Implementierungen zum Lesen aber zum Generieren habe ich bisher nichts gefunden
Einfach die Generierungsimplementation umkehren. Ich vermute daß auch im Pulse diese "Junk-DNABytes" ignoriert werden. Auf jeden Fall danke für das Dokument, ich habe nämlich festgestellt mein Stromzähler (EMH eBZD-G) hat auch eine RJ12 Buchse unter einer Abdeckung welche SML über RS485 mit 960kbps spricht. Mal schauen ob die mehr Daten rausgibt als die optische Schnittstelle. Und ich vermute mal daß man da auch keinen PIN Eiertanz nach jedem Stromausfall mehr aufführen muss. Ein weiter Vorteil wäre die integrierte 12V Stromversorgung.
Hat jemand ein SML-Telegramm von einem eBZ Zähler parat? Da würde ich mich gerne dran orientieren, da ja auch die Zählernummer auf einen EBZ-Zähler hinweist.
Ich habe das selbe Problem und hatte auch schon mit Tibber in Norwegen geschrieben. Es gibt eine API wo stündliche Verbräuche gemeldet werden können, diese ist aber nur für Norwegen nutzbar und in Deutschland gesperrt. In Norwegen kommuniziert der Netzbetreiber mit der Tibber API. Und mein Zälhler "Blinkt" mit dem Protikoll IEC 1107, welches keine Checksumme schickt. Aus dem Grund wollen/können sie diese Werte im Pulse nicht nutzen.
Wie die Kommunikation zwischen dem Pulse und Tibber funktioniert hat hier jemand zum Teil beschrieben:
Das erklärt einiges. Nicht daß die Checksumme fälschungssicher wäre, aber ein umgekipptes Bit kommt immer mal vor, und diese Fehler hundertprozentig sicher herausfiltern war denen dann doch zu unsicher.
Das heißt wenn man jetzt noch rausfindet, was die bridge an tibber-bridge/<geheim>/publish sendet, dann könnte man da auch direkt eigene Werte hinschicken. Scheinbar hat schonmal jemand die Bridge auf einen lokalen MQTT Server umgebogen (GitHub - MSkjel/LocalPulse2Tibber ) aber da steht jetzt nicht das Datenformat.
@johuebner Das wäre cool wenn das funktionieren würde, auch wenn da natürlich ein hohes Betrugspotenzial besteht.
LocalPulse2Tibber scheint die Daten einfach nur local zu nutzen. Dann müsste man ja eigentlich die Daten sehen, die man selbst an Tibber schicken könnte.
Leider kann ich nicht sehen, was der Pulse schicken würde, weil er ja meinen Zähler nicht ausliest. Anyone?
Ich hoffe ehrlichgesagt, dass Tibber sich gegen Betrug schützt, indem die Daten automatisiert auf Plausibilität geprüft werden. Wäre schade wenn sie auf teurere Technik umsteigen müssten wegen ein paar Schlaumeiern.
Das nützt leider wenig, ich bin selbst Spieleprogrammierer im Multiplayer/Online Bereich, und hier ist es sehr leicht plausible Daten zu senden.
Das ist leider unvermeidlich, wobei es nicht zu teuer sein muss. Mein EMH Stromzähler, den der Netzbetreiber 2018 installiert hat, hat ein RS485 interface, welches die BSI Richtlinie für kryptographische Datenübertragung in Messstellen einhält. Damit wäre die fälschungssichere Datenübermittlung möglich. Ich werde es mal selbst versuchen auszulesen, als alternative zum IR Lesekopf.
Aus o.g. Gründen bin ich noch nicht ganz sicher ob ich das Python-Skript veröffentlichen will, obwohl es jedem halbwegs sattelfesten Bastler gelingen sollte das Ganze nachzuprogrammieren.
Da der Zähler immernoch regelmäßig durch den Netzbetreiber abgelesen wird ist der grosse Betrug ja nicht so einfach möglich.
Einzig das schieben vom Verbrauch auf günstigere Zeiten sehe ich da als "Gefahr".
Aber die Lösung wäre auch für alle Interessant, wo der Zähler nicht in Funkreichweite ist. Wenn ich dann die Daten aus einem Em540 schicken könnte der in Reichweite ist wäre das klasse.
Naja, die technischen Voraussetzungen würden ja existieren. Den Public-Key schickt der Zähler ja jedes Mal mit über die optische Schnittstelle raus. Man müsste nur die Werte oder den kompletten Datensatz signieren und es wäre absolut fälschungs- und manipulationssicher. Leider scheint das Normungsgremium mal wieder mit heißer Luft gefüllt gewesen zu sein... Und die Übetragung des Public-Key ist nichts anderes als Energieverschwendung
Ich wollte dieses Thema nochmal aufgreifen. Ich habe einen Tibber Pulse, leider liest der nich meinen Zähler. Da habe ich die Whitelist nicht richtig geprüft. Also mal wieder wer lesen kann ist klar im Vorteil. Da der Support von Tibber scheinbar kundenorientiertes Handeln nicht wirklich kann, wollte ich selber nach einer Lösung schauen und bin hier auf diesen Post gestoßen.
Also, ich habe einen Tibber Pulse von dem ich die notwendigen Zertifikatsinformationen bekommen kann. Auch die Struktur, wie der die Daten verschickt kann ich darüber abfangen. Jetzt meinen Frage. Wenn ich einen IR Lesekopf mit beschaffe und diesen mit einem ESP32 verbinde, könnte ich über Tasmota diese Werte abgreifen. Aber wie kann ich diese Werte jetzt an Tibber senden? Ich habe soweit verstanden, dass es dazu schon ein Script gibt, aber wie kann ich dieses Script dann einbinden. Also wie bekomme ich dann den ESP32 mit Tasmota dazu die Daten vom Zähler an Tibber zu senden und welche Daten müssen das genau sein. Hat dazu einer mal einen Anleitung bzw Quellen, wie ich das machen könnte?
MfG
Vielleicht ist statt der Softwaresimulation etwas Hardware einfacher: SML-Nachrichten könnte man ja zusammenbauen und per IR-LED an den Tibber Pulse senden.
