Beispiel um eine PV-Anlage mit zwei EMH eHZ-Zählern auszulesen.

Die hier beschriebene PV-Anlage wurde 2011 mit Volleinspeisung errichtet und im Dezember 2012 auf Direktverbrauch umgestellt. Sie hat eine Leistung von 7,62 kWp, besteht aus 32 Sunpower SPR-238 Solarmodulen und einem Sunpower SPR-8001-F2 (baugleich Fronius IG Plus 100-V2) Wechselrichter.

Vor der Umstellung auf Direktverbrauch wurden der Bezug durch einen mechanischen Ferraris-Drehstromzähler und die Lieferung durch einen EMH eHZ gemessen.

Nach der Umstellung wurde der Ferraris-Drehstromzähler vom VNB (Verteilungs-Netz-Betreiber) gegen einen Zweirichtungszähler EDL21 eHZ für Bezug und Einspeisung ausgetauscht. Der EMH eHZ verblieb als Erzeugungszähler. Der Zweirichtungszähler zeigt im Wechsel für jeweils 15 Sekunden den Wert für Bezug +A und Lieferung -A an.

Das Loggen der Daten erfolgt auf einem Laptop Dell Latitude D800 (Pentium M). Auf dem Laptop wurde Ubuntu 12.10 mit MySql, PHP und Lighttpd installiert. Statt Lightpd kann man auch Apache nehmen. Ich habe Lighttpd gewählt, weil das Loggen später einmal meine D-Link DNS-323 NAS übernehmen soll. Für die gibt es die Möglichkeit ein Linux auf ihr zu installieren und in dem zur Zeit installierten fun_plug 0.5 ist als Webserver eben der Lighttpd enthalten. Da wollte ich schon mal Erfahrungen sammeln. Die beiden Zähler werden mit je einem USB-IR-Lesekopf am Laptop angeschlossen.

Installation wie im Installationsleitfaden beschrieben.

Eigentlich ist an den USB-IR-Leseköpfen nichts zu konfigurieren. Wie in USB-IRLesekopf Linux Support beschrieben, kann es passieren, dass die Leseköpfe nicht immer den gleichen Devicenamen bekommen. Aber das udev System bietet da Abhilfe an. Wir sagen dem udev System, dass es anhand der Seriennummer des Lesekopfes immer einen sym. Link zum richtigen Device anlegen soll. Wir benutzen dann in der Konfiguration immer die sym. Links.

Dazu muss man die Seriennummer ermitteln.

# udevadm info --query=all --name=/dev/ttyUSB0

Ergibt dann folgende etwas gekürzte Ausgabe.

P: /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/ttyUSB0/tty/ttyUSB0
N: ttyUSB0
S: serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_0061E011-if00-port0
...
E: ID_SERIAL_SHORT=0061E011
...
E: SUBSYSTEM=tty
...

Davon interessiert uns ID_SERIAL_SHORT=0061E011. Das ist die Seriennummer des Lesekopfes. Das wiederholt man für den zweiten Lesekopf, der unter „/dev/ttyUSB1“ zu finden sein wird.

Man erstellt jetzt eine Datei /etc/udev/rules.d/99-usb-ir-lesekopf.rules mit folgendem Inhalt.

SUBSYSTEM=="tty", ENV{ID_SERIAL_SHORT}=="0061E011", SYMLINK+="usb-ir-lesekopf0"
SUBSYSTEM=="tty", ENV{ID_SERIAL_SHORT}=="0061DF28", SYMLINK+="usb-ir-lesekopf1"

Natürlich statt „0061E011“ und „0061DF28“ die eigenen Seriennummern verwenden.

Ein anschließendes

# udevadm trigger

bringt das udev System dazu die neue Regel anzuwenden und die beiden sym. Links anzulegen. Die beiden Leseköpfe sind ab sofort immer unter /dev/usb-ir-lesekopf0 und /dev/usb-ir-lesekopf1 ansprechbar.

# ls -la /dev/usb*
lrwxrwxrwx 1 root root 7 Jan 13 22:19 /dev/usb-ir-lesekopf0 -> ttyUSB0
lrwxrwxrwx 1 root root 7 Jan 13 22:19 /dev/usb-ir-lesekopf1 -> ttyUSB1

Anschliessend kann man dann gleich mal testen, ob die neuen Device sym. Links auch funktioieren. Testmoeglichkeiten unter Linux

Vzlogger ist der Teil, der die Zähler ausliest und die Daten per Middleware in die MySQL Datenbank speichert. Um eine passende vzlogger.conf zu erstellen, wollen wir jetzt erstmal wissen, was unsere Zähler den so von sich geben. Dazu erstellen wir uns nun eine minimale /etc/vzlogger.conf die nur das Notwendigste enthält.

vzlogger.conf

{
"retry" : 0,                   /* how long to sleep between failed requests, in seconds */
"verbosity" : 15,               /* between 0 and 15 */
"log" : "/var/log/vzlogger/vzlogger.log",/* path to logfile, optional */
 
"local" : {
        "enabled" : false,      /* should we start the local HTTPd for serving live readings? */
        "port" : 8081,            /* the TCP port for the local HTTPd */
        "index" : true,         /* should we provide a index listing of available channels? */
        "timeout" : 30,         /* timeout for long polling comet requests, 0 disables comet, in seconds */
        "buffer" : 600          /* how long to buffer readings for the local interface, in seconds */
},
 
"meters" : [{
        "enabled" : true,       /* disabled meters will be ignored */
        "protocol" : "sml",     /* use 'vzlogger -h' for list of available protocols */
        "device" : "/dev/usb-ir-lesekopf0",
        },{
        "enabled" : true,       /* disabled meters will be ignored */
        "protocol" : "sml",     /* use 'vzlogger -h' for list of available protocols */
        "device" : "/dev/usb-ir-lesekopf1",
        }
]}

Wenn wir jetzt

sudo systemctl start vzlogger

aufrufen, dann sollte im logfile /var/log/vzlogger/vzlogger.log sowas in der Art stehen:

[Jan 15 22:30:39][]     ===> Start meters.
[Jan 15 22:30:39][mtr0] Meter connection established
[Jan 15 22:30:39][mtr0] Meter thread started
[Jan 15 22:30:39][mtr0] meter is opened. Start channels.
[Jan 15 22:30:39][mtr0] Number of readers: 32
[Jan 15 22:30:39][mtr0] Config.daemon: 0
[Jan 15 22:30:39][mtr0] Config.local: 0
[Jan 15 22:30:39][mtr1] Meter connection established
[Jan 15 22:30:39][mtr1] Meter thread started
[Jan 15 22:30:39][mtr1] meter is opened. Start channels.
[Jan 15 22:30:39][]     Startup done.
[Jan 15 22:30:39][mtr1] Number of readers: 32
[Jan 15 22:30:39][mtr1] Config.daemon: 0
[Jan 15 22:30:39][mtr1] Config.local: 0
[Jan 15 22:30:42][mtr0] Got 11 new readings from meter:
[Jan 15 22:30:42][mtr0] Reading: id=129-129:199.130.3*255/ObisItentifier:129-129:199.130.3*255 value=0.00 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=1-0:0.0.9*255/ObisItentifier:1-0:0.0.9*255 value=0.00 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=1-0:1.8.0*255/ObisItentifier:1-0:1.8.0*255 value=756082.40 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=1-0:2.8.0*255/ObisItentifier:1-0:2.8.0*255 value=26925.90 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 value=756082.40 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=1-0:2.8.1*255/ObisItentifier:1-0:2.8.1*255 value=26925.90 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=1-0:1.8.2*255/ObisItentifier:1-0:1.8.2*255 value=0.00 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=1-0:2.8.2*255/ObisItentifier:1-0:2.8.2*255 value=0.00 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=1-0:16.7.0*255/ObisItentifier:1-0:16.7.0*255 value=561.30 ts=1358285442.060
[Jan 15 22:30:42][mtr0] Reading: id=129-129:199.130.5*255/ObisItentifier:129-129:199.130.5*255 value=0.00 ts=2210964.000
[Jan 15 22:30:42][mtr0] Reading: id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000
[Jan 15 22:30:42][mtr0] Updating interval to 3
[Jan 15 22:30:42][mtr1] Got 6 new readings from meter:
[Jan 15 22:30:42][mtr1] Reading: id=129-129:199.130.3*255/ObisItentifier:129-129:199.130.3*255 value=0.00 ts=1358285442.080
[Jan 15 22:30:42][mtr1] Reading: id=1-0:0.0.9*255/ObisItentifier:1-0:0.0.9*255 value=0.00 ts=1358285442.080
[Jan 15 22:30:42][mtr1] Reading: id=1-0:2.8.1*255/ObisItentifier:1-0:2.8.1*255 value=12018020.10 ts=1358285442.080
[Jan 15 22:30:42][mtr1] Reading: id=1-0:1.7.0*255/ObisItentifier:1-0:1.7.0*255 value=0.00 ts=1358285442.080
[Jan 15 22:30:42][mtr1] Reading: id=1-0:2.7.0*255/ObisItentifier:1-0:2.7.0*255 value=0.00 ts=1358285442.080
[Jan 15 22:30:42][mtr1] Reading: id=0-0:0.0.0*0/ObisItentifier:0-0:0.0.0*0 value=0.00 ts=0.000
[Jan 15 22:30:42][mtr1] Updating interval to 3

Vzlogger kann dann wieder beendet werden:

sudo systemctl stop vzlogger

Nun sehen wir alle OBIS-Kennzahlen die unsere Zähler ausgeben. mtr0 ist der Zähler an /dev/usb-ir-lesekopf0 (im Beispiel der Zweirichtungszähler) und mtr1 der Zähler an /dev/usb-ir-lesekopf1 (Erzeugungszähler). Nun ist auch ersichtlich, warum ich die Kanäle so benannt habe, wie ich es tat.

Für die Beispielanlage brauchte ich

Vom Zweirichtungszähler

• 1.8.0 = Wirkarbeit Bezug +A
• 2.8.0 = Wirkarbeit Lieferung -A
• 16.7.0 = Wirkleistung

Vom Erzeugungszähler

• 2.7.0 = Wirkleistung
• 2.8.1 = Wirkarbeit Lieferung -A

Nun, das sind fünf Kanäle, die aus den Zählern in der Datenbank landen.

Die restlichen OBIS-Kennzahlen, die die Zähler ausgeben werden nicht benötigt

• 1.8.1 = Wirkarbeit Bezug Tarif 1 (da nur Tarif 1, ist 1.8.0 = 1.8.1)
• 1.8.2 = Wirkarbeit Bezug Tarif 2 (nicht vorhanden)
• 2.8.1 = Wirkarbeit Lieferung Tarif 1 (da nur in Tarif 1, ist auch hier 2.8.0 = 2.8.1)
• 2.8.2 = Wirkarbeit Lieferung Tarif 2 (nicht vorhanden)
• 1.7.0 = Wirkleistung Bezug ?

Nun erstellen wir die Kanäle in der Middleware. Dazu in einem Browser die IP des Raspi aufrufen. Wir brauchen insgesamt sieben Stück. Vier mit Leistungswerten und drei Zählerständen. Bei allen Kanälen: Style „steps“ einstellen, sowie öffentlich, aktiv und Cookie aktivieren. Als Initialzählerstand ist der jeweils aktuelle Stand der drei Zähler einzutragen.
Bei den Kanälen 1, 3 und 5 kann man unter Kosten noch die Vergütung bzw. den Strompreis angeben. Wird z.B. der Direktverbrauch mit 0,1236 €/kWh vergütet, trägt man 0.0001236 unter Kosten ein. Bekommt man 0,2874 €/kWh für Einspeisung, dann 0.0002874 bei Kanal 5 eintragen und kostet die kWh vom Energieversorger 0,2575 €, dann 0.0002575 bei Kanal 3 eingeben.

• Kanal 1: Haus 1.8.0 (Bezug +A), Typ El. Energie (Zählerstände), Auflösung 1000
• Kanal 2: Haus 16.7.0 (Leistung), Typ El. Energie (Leistungswerte)
• Kanal 3: Haus 2.8.0 (Lieferung -A), Typ El. Energie (Zählerstände), Auflösung 1000
• Kanal 4: PV 2.7.0 (Leistung), Typ StomEl. Energie (Leistungswerte)sensor
• Kanal 5: PV 2.8.1 (Erzeugung -A), Typ El. Energie (Zählerstände), Auflösung 1000

Beim Erstellen der Kanäle werden automatisch auch die UUIDs der Kanäle in der MySQL Datenbank angelegt. Diese UUIDs brauchen wir später noch. Es aber nicht nötig die jetzt zu notieren, da wir da jederzeit leicht ran kommen. Neben den erstellten Kanälen finden wir dieses Zeichen , mit dem wir die UUID später abrufen können.

Die Namen der Kanäle können selbstverständlich frei gewählt werden. Ich habe mich jedoch an den OBIS-Kennzahlen, die meine Zähler ausgeben orientiert.

Nun kann man die korrekte /etc/vzlogger.conf erstellen. Die UUIDs wie oben beschrieben auslesen und an die korrekte Stelle einfügen.

vzlogger.conf

{
"retry" : 0, /* how long to sleep between failed requests, in seconds */
"verbosity" : 15, /* between 0 and 15 */
"log" : "/var/log/vzlogger/vzlogger.log", /* path to logfile, optional */
 
"local" : {
"enabled" : false, /* should we start the local HTTPd for serving live readings? */
"port" : 8081, /* the TCP port for the local HTTPd */
"index" : true, /* should we provide a index listing of available channels if no UUID was requested? */
"timeout" : 30, /* timeout for long polling comet requests, 0 disables comet, in seconds */
"buffer" : 600 /* how long to buffer readings for the local interface, in seconds */
},
 
"meters" : [{
         "enabled" : true, /* disabled meters will be ignored */
         "protocol" : "sml", /* see 'vzlogger -h' for list of available prot$ */
         "device" : "/dev/usb-ir-lesekopf0",
         "channels": [{
         "uuid" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
         "middleware" : "http://localhost/middleware.php",
         "identifier" : "1-0:16.7.0", /* Leistung */
         }, {
         "uuid" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
         "middleware" : "http://localhost/middleware.php",
         "identifier" : "1-0:1.8.0", /* Wirkarbeit Bezug +A */
         }, {
         "uuid" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
         "middleware" : "http://localhost/middleware.php",
         "identifier" : "1-0:2.8.0", /* Wirkarbeit Lieferung -A */
         }]
         }, {
         "enabled" : true,
         "protocol" : "sml",
         "device" : "/dev/usb-ir-lesekopf1",
         "channels" :[{
         "uuid" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
         "middleware" : "http://localhost/middleware.php",
         "identifier" : "1-0:2.7.0", /* Leistung Erzeugung */
         }, {
         "uuid" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
         "middleware" : "http://localhost/middleware.php",
         "identifier" : "1-0:2.8.1", /* Wirkarbeit Erzeugung -A */
         }]
}
]}

Speichern als /etc/vzlogger.conf. Testen dann mit

sudo systemctl start vzlogger

Nach erfolgreichem Test noch „verbosity“ : 15, in „verbosity“ : 0, ändern.

Nun ist neben dem Bezug und der Lieferung auch der Gesamt- und Direktverbrauch von Interesse. Diese Werte können jedoch nicht aus den Zählern ausgelesen werde. Sie können nur durch Berechnung ermittelt werden.

• Direktverbrauch = Erzeugung - Lieferung
• Gesamtverbrauch = Bezug + Erzeugung - Lieferung

Da alle für die Berechnung notwendigen Werte vorliegen erstellt man 2 virtuelle Kanäle vom Typ „Verbrauchsensor (virt.)“.

• Kanal 6:
  • Einheit: W
  • Regel: val(in1) - val(in2)
  • Eingang 1: UUID von Kanal 5 (PV 2.8.1)
  • Eingang 2: UUID von Kanal 3 (Haus 2.8.0)
• Kanal 7:
  • Einheit: W
  • Regel: val(in1) + val(in2) - val(in3)
  • Eingang 1: UUID von Kanal 1 (Haus 1.8.0)
  • Eingang 2: UUID von Kanal 5 (PV 2.8.1)
  • Eingang 3: UUID von Kanal 3 (Haus 2.8.0)

Wurde alles korrekt eingerichtet, dann sollte sich unter http://localhost/ folgendes Bild bieten. Man beachte die enorme Erzeugung und den ebenso enormen Direktverbrauch. Das Modulfeld war an dem Tag zugeschneit.

Wer es optisch mag kann in den Kanal-Eigenschaften den Füllgrad noch etwas höher setzen.