NECH2004 / smartmeter_austria_energy

MIT License
0 stars 1 forks source link

Frage: Integration anderer Netzbetreiber #2

Closed tofuSCHNITZEL closed 5 months ago

tofuSCHNITZEL commented 9 months ago

Hallo, ich bin auf dieses Repo gestoßen bei meiner Suche nach bestehenden Projekten die sich mit dem auslesen österreichischer Smartmeter beschäftigen, da ich eine python library und eine home assistant integration erstellen will die Wiene Netze Smartmeter auslesen kann.

das problem ist, dass der Wiener Netze Isramenco komplett anders zu funktionieren scheint als die Meter die du hier mit dieser Lib unterstützt.

glaubst du es macht sinn diese library so anzupassen sodas auch diese "Spezialanforderungen" abdeckbar sind? (ich denke es ist auch ein eigener "serial read prozess" notwendig und eine eigene Decrypt klasse und nicht nur ein eigener "Supplier")

oder wäre es besser das überhaupt in eine library zu packen weil es funktional so stark von dieser hier abweicht (aber wie sollte ich die dann nennen wenn diese hier schon "austria" smart meter heißt)

Bin froh für jeden Input. Danke! Lg

NECH2004 commented 8 months ago

Hallo Tobias,

 

tut mir leid, dass ich mich erst heute melde. Ich würde mich freuen, wenn du eine Lösung für Home Assistant programmieren könntest.

 

Kurz vorangestellt meine Gedanken dazu:

Benutzerfreundlichkeit für Endkunden war bei der Einführung der Smartmeter in Österreich (und auch anderswo) nie treibendes Thema, nur billige Smartmeter. Also dürfen wir uns Hard- und Softwareseitig auch nicht allzuviel erwarten, die Geräte sind Großteils China-Ware, vermutlich auch die Firmware. Somit kann dir auch der Kundendienst der Energielieferanten nicht wirklich helfen. Die optische Schnittstelle geht so, aber vor allem die M-Bus Schnittstelle stammt aus der Hölle.

Was so alles verwendet wird, kann man hier nachlesen, auch die definierten OBIS-Codes:

Konzept (oesterreichsenergie.at)

 

Grundsätzlich sollte es so sein, dass als Protokollschicht DLMS / COSEM, IDIS CII verwendet wird (vgl. Spezifikation Kundenschnittstelle E450 (netzburgenland.at)), die Nutzdaten dann mittels OBIS-Datenmodell verschlüsselt als Payload gesendet werden.

Das COSEM-Protokoll bietet eine Vielzahl an Möglichkeiten an, wie Daten gesendet werden können, daher wäre es sehr gut, wenn man eine Bibliothek dafür verwenden könnte.

gurux.fi bietet dabei einiges an, auch open source für Python. Wäre also die Wahl der Methode.

Leider haben weder Dominik, Michael oder auch ich in ihren jeweiligen Versuchen es geschafft, mittels der Beispiele die Payload zu decodieren. Irgenwo zwischen "wir verstehen die Beispiele nicht", "die DLL ist fehlerhaft", "das Smartmeter ist nicht richtig implementiert" wird es wohl liegen. (Das wir zu dumm sind, schließe ich - zumindest für die Kollegen - aus).

 

Dominik beschreibt z. B. ein fehlerhaftes Protokoll bei Netz NOE

https://github.com/DomiStyle/esphome-dlms-meter/issues/12

 

Michael beschreibt Probleme mit der Länge:

https://www.michaelreitbauer.at/kaifa-ma309-auslesen-smart-meter-evn/

 

hier ist auch noch ein Beispiel von Michael, der im Prinzip die GURUX libs verwendet:

https://github.com/greenMikeEU/SmartMeterEVNKaifaMA309/blob/main/EvnSmartmeterMQTTKaifaMA309.py

 

Leider kann ich damit meine Nutzdaten nicht dekodieren, vermutlich benutze ich die lib falsch.

 

 

Ich habe dann auf der Lösung von Stefan aufgebaut

https://github.com/tirolerstefan/kaifa/blob/master/kaifareader.py

 

Diese Methode gewinnt keinen Architekturpreis, da sie weder sauber noch nachhaltig ist. Sie verzichtet auf sämtliche Informationen des COSEM-Protokolls und verlässt sich darauf, dass die Energieanbieter das Protokoll niemals ändern. (Beruflich hätte ich dies niemals akzeptiert.)

Die Nutzdaten sind für einen Frame zu groß, daher müssen die Daten in 2 Frames gesendet werden. Da diese Frames immer gleich aufgebaut sind, kann man diese fixen needles (68 FA FA 68, 68 72 72 68, 68 14 14 68) im byte stream suchen, an Hand der ermittelten Länge die Nutzdaten extrahieren und zu einem Datensatz zusammenbauen. Der wird dann dekodiert und dann mit Hilfe eines nachgebauten OBIS-Datenmodells dekodiert.

Also sehr fragil und umständich. Die Probleme dabei sind vorallem ein Versagen bei Protokolländerungen, Fehler bei Datensätzen, die nicht dem Muster entsprechen (z. B. sendet der zähler alle 15 min so etwas wie Summensätze).

 

Ich habe mir in den letzen Tagen daher nochmals eine cosem-basierte Lösung angesehen, die auch den ISKRA kennt.

smartmeter-datacollector/smartmeter_datacollector/smartmeter/hdlc_dlms_parser.py at master · scs/smartmeter-datacollector · GitHub

Vielleicht finde ich doch noch eine Lösung, dass ich cosem verwenden kann.

 

 

Aber zurück zu deinen Fragen

Vor über 2 Jahren hatte ich die Idee, den Smartmeter der SalzburgNetz einzubinden und eine Plattform für die östereichischen Smartmeter anzubieten. Darum auch der Name Smart Meter Austria bzw. Smart Meter Austria Energy für die Lib in PyPi.

In der Konfiguration sollte man diese Integration auswählen können, und dann auf der Unterseite das Bundesland. Die Amazon-Integration zeigt dies als Beispiel, in Github sieht man, wie man das konfigurieren kann.

 

Da mir meine Lösung aber nicht besonders gut gefällt, habe ich noch nicht versucht meine Lösung in den HA zu integrieren.

Du kannst deine Integration daher so nennen, wie du willst - auch Smart Meter Austria. Falls ich die Integration doch noch einmal angehe, dann würde ich den Domänen-Namen (=Verzeichnisname) sowieso kürzer machen oder bei einem bestehenden Projekt einen Subfolder verwenden.

 

Zur Implementierung:

ich teile deine Einschätzung, dass die Smartmeter zu unterschiedlich sind, dass man source code wiederverwenden kann. Der Read-Prozess sucht nur nach einer Nadel und liest dann eine fixe Länge an Daten aus. Du brauchst daher nicht nach Teil 1 und Teil 2 suchen, das vereinfacht den serial read deutlich. Die Klasse supplier kann man auch einsparen, da es bisher nur einen Anbieter mit diesem Smartmeter/Protokoll gibt. Decrypt funktioniert auch komplett unterschiedlich. Somit bleibt von einer Wiederverwendung eigentlich nichts mehr übrig ausser dem Konzept. Selbst wenn ich den Zähler implementieren würde, würde ich eine komplett getrennte lib bauen. Da spielen noch ganz andere Dinge mit, wie z. B. Gesamttests bei bugfixes, etc. da du dann ja die gesamte lib auslieferst.

 

Falls du Code von mir kopieren willst um leichter starten zu können, kein Problem. Allerdings programmiere ich Python nicht professionell, da gibt es deutlich bessere Programmierer.

Ich dich kann aber - falls du es wünschts - bei Code und Architektur mit Reviews  unterstützen und bei allgemeinen Fragen - was gehört zu Home Assistant, was gehört in die Lib bei PyPi, etc.

 

Falls du Fragen hast, einfach melden.

Liebe Grüße und viel Spass beim Coden!

Christian

 

 

Gesendet: Samstag, 09. Dezember 2023 um 16:49 Uhr Von: "Tobias Perschon" @.> An: "NECH2004/smartmeter_austria_energy" @.> Cc: "Subscribed" @.***> Betreff: [NECH2004/smartmeter_austria_energy] Question: integration andere Netzbetreiber (Issue #2)

 

Hallo, ich bin auf dieses Repo gestoßen bei meiner Suche nach bestehenden Projekten die sich mit dem auslesen österreichischer Smartmeter beschäftigen, da ich eine python library und eine home assistant integration erstellen will die Wiene Netze Smartmeter auslesen kann.

das problem ist, dass der Wiener Netze Isramenco komplett anders zu funktionieren scheint als die Meter die du hier mit dieser Lib unterstützt.

es werden nicht zwei frames via IR - Serial Schnittstelle geschickt sondern "ein Frame" mit einer fixen länge (bei mir 105 bytes) mit fixen start und endbytes (7E) jede Sekunde
das decoden mit Systemtitle+IV counter ist gleich und funktioniert
in den dekodierten daten sind keine OBIS codes für mich erkennbar sondern nur 9 Werte (in dieser reihenfolge: https://www.wienernetze.at/kundenschnittstelle2)

glaubst du es macht sinn diese library so anzupassen sodas auch diese "Spezialanforderungen" abdeckbar sind? (ich denke es ist auch ein eigener "serial read prozess" notwendig und eine eigene Decrypt klasse und nicht nur ein eigener "Supplier")

oder wäre es besser das überhaupt in eine library zu packen weil es funktional so stark von dieser hier abweicht (aber wie sollte ich die dann nennen wenn diese hier schon "austria" smart meter heißt)

Bin froh für jeden Input. Danke! Lg

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>