|
Linux-Projekte
für den Raspberry Pi
(in Python realisiert)
Zählerdaten
(EDL21/SML) auswerten und am LCD-Display darstellen
|
Mit der
Solaranlage wurde ein neuer Zweirichtungszähler 'eHZ' der Firma
'EMH metering' verbaut.
|
Bildquelle: J.Hoppe
|
|
Spannung
|
3 x 230/ 400 V
|
|
Strom
|
0,25 – 5 (60) A
|
|
Frequenz
|
50 Hz
|
|
IR- LED Impulse
|
10.000/ kWh
|
|
Zähler
|
2
|
|
LC-Display
|
2-Zeilig (8 mm)
|
|
Schnittstellen
|
1.Vorderseite (1-Weg: SML 9600 Baud)
2. Rückseite
(2Weg: SML/ COSEM 921,6 kBaud)
|
|
Auflösung
|
0,1 W
|
|
Dieser
sendet über eine optische Infrarot-Schnittstelle ständig
Datentelegramme im SML (Smart Meter Language) Format.
Die
optischen Rohdaten werden über den bereits beschriebenen
Lesekopf am Raspberry Pi an die TTY-Schnittstelle der GPIO
(PIN 10) angelegt.
Die Schnittstellenprameter
dazu sind (9600, 8, N, 1)
-
|
9600
|
9600 Baud
|
|
8
|
8 Datenbit
|
|
N
|
Keine
Parität
|
|
1
|
1 Stopbit
|
Beim Start des
Rechners wird per cronjob automatisch ein shell-Programm
ausgeführt, das das Programm zur Vorverarbeitung startet. Dieser
Weg wurde gewählt, um bei Änderungen des Programmnamens nicht
jedes mal den cronjob ändern zu müssen. So ist es nur
notwendig, den neuen Programmnamen in der .sh-Datei (Textdatei)
anzupassen.
Hier eine
Darstellung des Beginns eines Datentelgramms am Oszilloskop
(Grob- und Feinsicht)
|
|
|
|
Bildquelle: J. Hoppe
|
Ein Klick auf
die Grafiken öffnet eine vergrößerte Darstellung
Das
Verarbeitungsprogramm öffnet die tty-Schnittstelle zur Eingabe
mit den bereits beschriebenen Parametern.
Der EDL21 Zähler
sendet laut Datenblatt alle 1-4 Sekunden ein aktuelles
SML-Datentelegramm.
Dieses wird über die TTY-Schnittstelle
eingelesen und vorverarbeitet.
Das heißt:
Die
Start- und Ende Escape-Sequenz werden gesucht,
Wird KEINE
Ende-Sequenz gefunden, wird das Datentelegramm verworfen.
Danach
werden die einzelnen SML Blöcke untersucht.
Eine SML
Telegramm setzt sich folgendermaßen zusammen:
1. SML
Nachricht 'SML_PublicOpen.Res' (1.1)
2.
SML-Nachricht 'SML_GetList.Res' (7.1)
3.
SML-Nachricht 'SML_PublicClose.Res' (2.1)
Jeder Block,
als auch die gesamte Nachricht enthält eine CRC_16 Prüfsumme.
Diese werden im Programm NICHT überprüft! Mögliche
Übertragungsfehler können daher nicht erkannt werden.
Block
2 enthält die 'wichtigen' Daten. Dieser wird dekodiert und in
die einzelnen Nachrichtenteile (Listeneinträge) zerlegt. Diese
Listeneinträge sind OBIS-Blöcke, die entsprechend der
Spezifikation (man, war die schwer zu finden) aufbereitet
werden.
In meinem Fall werden vom Zähler folgende
OBIS-Werte bereitgestellt:
|
OBIS-Kennung
|
Beschreibung
|
|
(129-129:199.130.3*255)
|
(Hersteller-ID)
|
|
(0-
0: 0. 0. 9*255)
|
(Server
ID)
|
|
0:1.8.0*255
|
Wirkenergie
Total Bezug
|
|
0:2.8.0*255
|
Wirkenergie
Total Lieferung
|
|
0:1.8.1*255
|
Wirkenergie
Tarif 1 Bezug
|
|
0:2.8.1*255
|
Wirkenergie
Tarif 1 Lieferung
|
|
0:1.8.2*255
|
Wirkenergie
Tarif 2 Bezug
|
|
0:2.8.2*255
|
Wirkenergie
Tarif 2 Lieferung
|
|
0:16.7.0*255
|
Momentane
Wirkleistung
|
(Es sind noch weitere Werte verfügbar,
die aber nichts mit der gewünschten Darstellung zu tun haben und
vom Programm vernachlässigt werden)
Bei den
OBIS-Kennzahlen hat mir dieses
Dokument entscheidend weiter geholfen!
Diese
OBIS-Einträge werden 'schnell und schlampig (quick and dirty)'
dekodiert und in einer Datei auf der SD-Karte abgelegt. Dabei
werden die Daten nur dann geschrieben, wenn ein interner Puffer
die (willkürlich gewählte) Größe von 4K überschreitet und
stehen daher erst nach einer gewissen Verzögerung in der Datei
bereit.
Achtung: Es
werden momentan NUR die beschriebenen OBIS-Kennungen dekodiert.
Falls bei ähnlichen Zählern andere Kennungen übertragen
werden, läuft das Programm nicht oder nicht fehlerfrei!
Die
Bezeichnung der generierten Text-Datei setzt sich aus dem Prefix
'SMLreindaten_' und dem Tagesdatum (JJJJMMTT) , gefolgt von der
Endung '.edl' zusammen.
Erkennt das Programm eine
Datumswechsel, wird die aktuelle Ausgabe-Datei geschlossen und
eine Neue, mit neuem Tagesdatum erzeugt.
Hier ein
kurzer Auszug aus der erzeugten Datei
'SMLreindaten_20161129.edl':
|
Struktur: TID, T, BS, LS, T1B, T1L,
T2B, T2L, Wist
Feldname: TransferID, Time, BezugSumme,
LieferSumme, Tarif1Bezug, Tarif1Liefer, Tarif2Bezug,
Tarif2Liefer,
WirkleistungIst
000a012db9f7/1480374193.0/255323.8/455012.0/255323.8/455012.0/0.0/0.0/69.9/
000a012db9fd/1480374197.0/255323.9/455012.0/255323.9/455012.0/0.0/0.0/74.6/
000a012dba03/1480374199.0/255324.0/455012.0/255324.0/455012.0/0.0/0.0/71.9/
000a012dba09/1480374204.0/255324.0/455012.0/255324.0/455012.0/0.0/0.0/70.0/
|
Die
ersten beiden Zeilen werden vom Programm für den Strukturaufbau
verwendet und wurden vom Ausleseprogramm hinzugefügt.
Ab
der dritten Zeile stehen die Meßwerte des Zählers durch
Schrägstrich separiert.
Transfer
ID:
|
Dies
ist eine laufende Nummer, die der Zähler zu jeder SML-
Nachricht erzeugt.
|
Time:
|
Die
aktuelle (per Auslese-Programm korrigierte) Meßzeit in
UNIX-Format.
|
BezugSumme:
|
Die
bisher aufgelaufene Summe in W/h, die bisher vom EVU
bezogen wurden.
|
LieferSumme:
|
Die
bisher aufgelaufene Summe in W/h, die bisher an das
EVU geliefert wurden.
|
Tarif1Bezug:
|
Hier
ist die Summe des Bezuges vom EVU bei Tarif 1
|
Tarif1Liefer:
|
und
hier die Summe der Lieferung an das EVU bei Tarif
1.
|
Tarif2Bezug:
|
Hier
ist die Summe des Bezuges vom EVU bei Tarif 2
|
Tarif2Liefer:
|
und
hier die Summe der Lieferung an das EVU bei Tarif
2.
|
WirkleistungIst:
|
Hier
ist endlich der Wert der interessant ist:
die Leistung
in W/h, die aktuell bezogen (+) oder geliefert (-)
wird.
|
Zum
Thema Zeit (Time) gibt es noch eine Besonderheit:
Der
EDL21-Modus beinhaltet anscheinend KEINE 'echte' Uhr, sondern
einen 'Zeitzähler', der nach dem Anschluß an das öffentliche
Stromnetz los läuft.
Durch Vergleich dieses 'Zeitzählers'
- der als Wert in den reinen OBIS-Daten enthalten ist - mit der
aktuellen Uhrzeit habe ich eine ungefähre Differenz
herausgefunden. Diese 'Korrektur' wird im Auslese-Programm zum
'Zeitzähler' hinzugefügt. Damit ist eine ungefähre Annäherung
an die korrekte Meßzeit möglich (die Abweichung beträgt so
plus minus 1-2 Minuten).