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?
Nicht direkt aber ich ich hab da auch schon mal mit dem Gedanken gespielt. Ich würde versuchen ob der Pulse diese bytefolge hier richtig liest:
https://www.msxfaq.de/sonst/bastelbude/smartmeter_d0_sml.htm
Dann könnte man mit der Beschreibung und den links weiter schauen
Damit ließe sich natürlich auch betrügen aber das ist nicht der Plan.
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.
Also habe das hier mal überflogen: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03109/TR-03109-1_Anlage_Feinspezifikation_Drahtgebundene_LMN-Schnittstelle_Teilb.pdf?__blob=publicationFile
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
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.
Ein paar allgemeine Infos zum Format gibts hier: https://www.msxfaq.de/sonst/bastelbude/smartmeter_d0_sml_protokoll.htm
Und zum eBZ: https://stadtwerke-bsa.de/magic/show_image.php?id=300413&download=1
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:
https://blog.wyraz.de/allgemein/a-brief-analysis-of-the-tibber-pulse-bridge/
PIP 5048MS | 6x 340Wp mono (2KWp) Ostdach | 14S80P Powerwall
3x MP2 5000 | 11 kWp Ost- + Westdach | 14kWh LFP
Mitsubishi Multi MXZ2F42VF+MSZEF25VGKW+MSZEF35VGK
IEC 1107, welches keine Checksumme schickt. Aus dem Grund wollen/können sie diese Werte im Pulse nicht nutzen.
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.
Wie die Kommunikation zwischen dem Pulse und Tibber funktioniert hat hier jemand zum Teil beschrieben:
https://blog.wyraz.de/allgemein/a-brief-analysis-of-the-tibber-pulse-bridge/
Das ist ja sehr interessant. Ich habe das jetzt alles mal nachvollzogen und kann tatsächlich eine MQTT Verbindung herstellen.
> mosquitto_sub --cafile ca.pem --cert cert.pem --key private.pem -d -h ***.iot.eu-west-1.amazonaws.com -t tibber-bridge/<geheime_id>/receive Client mosqsub|7877-beaglebone sending CONNECT Client mosqsub|7877-beaglebone received CONNACK (0) Client mosqsub|7877-beaglebone sending SUBSCRIBE (Mid: 1, Topic: tibber-bridge/<geheim>/receive, QoS: 0) Client mosqsub|7877-beaglebone received SUBACK Subscribed (mid: 1): 0
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 ( https://github.com/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.
PIP 5048MS | 6x 340Wp mono (2KWp) Ostdach | 14S80P Powerwall
3x MP2 5000 | 11 kWp Ost- + Westdach | 14kWh LFP
Mitsubishi Multi MXZ2F42VF+MSZEF25VGKW+MSZEF35VGK
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.
Ich hoffe ehrlichgesagt, dass Tibber sich gegen Betrug schützt, indem die Daten automatisiert auf Plausibilität geprüft werden.
Das nützt leider wenig, ich bin selbst Spieleprogrammierer im Multiplayer/Online Bereich, und hier ist es sehr leicht plausible Daten zu senden.
Wäre schade wenn sie auf teurere Technik umsteigen müssten wegen ein paar Schlaumeiern.
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.
So, die Sache ist gelöst, siehe hier https://github.com/MSkjel/LocalPulse2Tibber/issues/6 und hier https://openinverter.org/forum/viewtopic.php?t=3654
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.
10x 130Wp + 2x 210Wp -> 3x MPPT 100/20 + 2x HM300 + BlueSmart IP22 24/16 -> 2x 24V 100 Ah LFP -> Multiplus C 24/2000
Ja also das meine ich, man könnte eine Batterie simulieren die gar nicht da ist.
Naja egal: https://github.com/jsphuebner/esp-egycounter/tree/main/battery-control/tibber