[vz-dev] SML

[Justin Otherguy]

N'Abend,

manche von Euch sind vielleicht schon über das SML-Protokoll [1] gestolpert. Das Lastenheft EDL [2] des FNN im VDE (das ist die Definition des "Standard Smart Meters für elektrische Energie") definiert SML (derzeit) als das einzige Kommunikationsprotokoll des Smart Meters. Für den volkszaehler ist das natürlich spannend, da das bedeutet, dass mit der Unterstützung von SML auch die Standard-Zähler Werte in den volkszaehler einliefern können.
Mathias hatte schon vor ner Weile mal mit einer Bibliothek (libehz [3]) angefangen.
Ich habe mir einige Gedanken über die Bedeutung von SML für den volkszaehler gemacht und bin zum Ergebnis gekommen, dass wir SML nicht nur "ein bisschen" machen sollten, sondern dass uns SML helfen kann, die Architektur etwas gerade zu ziehen.
Bisher hatten wir die Komponenten des volkszaehlers in diese 4 Abschnitte eingeteilt:
- erfassen
- verarbeiten
- speichern
- visualisieren
Grund dafür war das ursprüngliche Setup mit dem Hutschienenzähler und dem Net-IO. Mit der Unterteilung in
- messen
- übertragen
- speichern
- visualisieren
wird es m. E. deutlich klarer, welche Funktion in welchen Abschnitt gehört.

Alles, was ein Smart Meter macht, gehört in den Abschnitt "messen".
Der Smart Meter hat i.d.R. eine lokale Schnittstelle (optische, RS232, RS485, ...) mit SML-Protokoll
Der nächste Abschnitt bildet die Brücke zur WAN-Kommunikation: "übertragen". Die Komponente nimmt also SML entgegen und spricht gegen die volkszaehler-API [4] (via HTTP).

Natürlich wird es Ausnahmen geben:
- wer ein ATmega-Board mit LAN-Schnittstelle benutzt, wird auf SML verzichten
- wenn es um Temperaturen geht, ist SML nicht das Mittel der Wahl (und wird es wohl nie werden): ist schliesslich kein Smart Metering
- ich bin nicht sicher, ob SML (derzeit) für den Wasserzähler verwendet werden kann - über die (für Gas vorgesehene) OBIS-Kennzahl [5] für Volumina könnte das klappen

Ich denke, dass SML auch für die Ausgabe der Messwerte des fluksoUSB eine gute Idee wären.
Tobias Jeske hat sich der Sache angenommen. Er baut eine Bibliothek, die:
- SML parsen kann (im Endstadium sowohl das binäre als auch das ASCII-Format und - falls es mal kommen sollte - auch die XML-Variante)
- SML ausgeben kann
- VZ-API sprechen kann

Diese Bibliothek wird sich dann an folgenden Stellen nutzen lassen:
- beim Umwandeln von SML in die VZ-API (z.B. LAMP-System, welches zwischen einem EDL und der VZ-Middleware hängt)
- beim Ausgeben von SML wenn ein Transducer mit fluksoUSB SML ausgeben können soll

Da es sich bei der Bibliothek vorrangig um SML dreht, schlage ich als Namen "libsml" vor (Kommentare willkommen).
Ich habe gerade entdeckt, dass domke auch schon etwas hat, was nach einem Parser aussieht.

Ich würde gerne die Arbeiten, die in diese Richtung gehen bündeln - wäre ja albern, dass hier alle im stillen Kämmerlein das gleiche Ding bauen.
Wollte nun aber nicht gleich vz-dev und msg-dev cross-posten.

Ich habe mal eine Wiki-Seite angelegt, auf der ich meine SML-Erkenntnisse zusammen geschrieben habe [8].

Jegliche Kommentare sind sehr willkommen.

Bin nicht so sicher, ob wir sämtliche Kommunikation über die Liste führen sollten - ich bin aber überzeugt, dass wir etwas mehr verbosity brauchen...


Gruss, J.

[1] http://de.wikipedia.org/wiki/Smart_Message_Language
[2] http://www.vde.de/de/fnn/arbeitsgebiete/messwesen/documents/FNN_Lastenheft-EDL_1-0_2010-01-13.pdf
[3] https://github.com/gonium/libehz
[4] http://wiki.volkszaehler.org/development/api/reference
[5] http://de.wikipedia.org/wiki/OBIS-Kennzahlen
[6] https://github.com/volkszaehler/volkszaehler.org/tree/master/misc/controller/vzlogger/
[7] https://github.com/domke/optoreader
[8] http://wiki.volkszaehler.org/software/sml