:: contes.eu

SMA Energy Meter auswerten

Endlich habe ich es geschafft die Werte des Ende letzten Jahres eingebauten SMA Energy Meter auszuwerten. Dabei gab es gleich zwei Hürden zu nehmen: Zeit und Unwissen 🙂 Wobei das Unwissen die benötigte Zeit in unbekannte Dimensionen trieb. Denn das Programm zur Auswertung der Datenpakete des SMA EM ist in C geschrieben und bis dato wusste ich gerade mal, dass C eine Programmiersprache ist. Dank vieler Google Suchen und Forenpostings konnten die Hürden nach und nach genommen werden und das fertige Produkt erfreut den Frickler aus dem Heim und Hobbybereich – mich 🙂

Das SMA Energy Meter kann sich jeder Haus- und Wohnungsbesitzer in seinen Sicherungsschrank einbauen lassen. Es gibt hier keine zwingende Verbindung mit einer Photovoltaikanlage. Logischerweise wird dann nur der importierte Strom ausgewertet. Für Android und iOS gibt es Apps um sich die Daten in Realtime anzeigen zu lassen.

Wie sieht jetzt das Ergebnis meiner Bastelei aus?

Auswertung der 3 Phasen im Haus — Auswertung Last der 3 Phasen im Haus (15 Minuten)

Der erste Teil visualisiert die Last auf den 3 Phasen im Haus. Für jede Phase (L1, L2 und L3) wird ermittelt, ob Strom von EVU gezogen wird (Import) oder ob Strom „übrig“ ist und zum EVU exportiert wird (Export). Übrig bedeutet, von der Solaranlage erzeugter Strom abzüglich Eigenverbrauch.

Auswertung Import, Export und PV Leistung — Auswertung Import, Export und Solarertrag (15 Minuten)

Aufsummiert ergibt sich dieses Bild. Zusätzlich wird noch die gerade gelieferte Leistung der PV Anlage angezeigt. Die grafische Aufarbeitung übernimmt Highcharts.

Was wurde alles gemacht um das Ergebnis zu erhalten?
1. Ein Programm in C geschrieben, dass die Multicast Pakete vom SMA Energy Meter aufnimmt und in eine SQLite Datenbank schreibt
2. Installation und Konfiguration von SBFSpot, ein Programm zur Auswertung von SMA Wechselrichtern. Die gewonnenen Daten werden ebenfalls in eine SQLite DB geschrieben
3. Erstellung einer Webseite, die die gespeicherten Daten aus der Datenbank ausliest und grafisch darstellt.

Getestet wurde das meiste davon auf einem Raspberry Pi2 (die Quadcore Variante). Das Livesystem ist ein Ubuntu Linux unter ESXi. Der Pollingintervall beträgt 1 Minute. Auf dem Pi hatte ich auch mit 5 Sekunden experimentiert. Lässt man sich dann aber mehrere Tage gleichzeitig anzeigen, dauert die Darstellung von 100.000 Datensätzen recht lange.

ToDo: Optimierung der Webseite um z.B. einzelne Tage auszuwerten. Im Moment kann man sich nur die letzten XYZ Minuten anzeigen lassen.

Mein Dank geht an die Helfer aus dem Computerbase Unterforum für Programmierung, Fefe, Jürgen Wolf für das Buch Linux-Unix Programmierung und EB-Systeme für die Protokollanalyse.

Solarertrag, Export und Import (12 Stunden)

Relaix Fiberlinx.Home

Relaix Fiberlinx.Home 250 Glasfaseranschluß – Uploaderhöhung auf 50 MBit

Seit April nutzen wir jetzt den Fiberlinx.Home Anschluß der Relaix. Die dafür nötige Glasfaser wurde uns vom regionalen Energieversorger, der Enwor, bereitgestellt. Im Laufe der Woche wurde der Upload kostenlos von 10 MBit auf 50 MBit erhöht. Damit liegt die Relaix mit ihrem Fiberlinx.Home 250 Anschluss weit vor der Kupferkonkurrenz. Nicht nur was die Bandbreite betrifft, sondern auch technologisch. Bleibt noch zu erwähnen, dass die letzten zwei Monate absolut störungsfrei verliefen und wir mit dem Anschluss mehr als zufrieden sind.

Die bereitgestellte Geschwindigkeit wird, schnelle Gegenstelle vorausgesetzt, regelmäßig erreicht.

Selber Bier brauen

Was könnte man Karfreitags besseres machen, als sein eigenes Bier zu brauen? Eben. Zum Eigenbräu führen viele Wege. Ich habe mich für den einfachen Weg entschieden und ein Brauset von Besserbrauer gekauft. Das kostet 75 Euro und enthält die meisten Utensilien, die man zum Brauen benötigt. Meine Wahl fiel auf die Sorte „Hell“. Aus der eigenen Küche benötigt man noch einen, besser zwei große Kochtöpfe (8-10 Liter, hat nicht Jedermann), einen Kochlöffel, einen Messbecher, ein großes grobmaschiges Küchensieb, eine (grammgenaue) Küchenwaage und einen Trichter. Während der Woche Gärung hast Du außerdem Zeit, 12 leere Bierflaschen für die Abfüllung zu sammeln. Ich habe Flensburger (0.33 Liter, Bügelverschluss) benutzt. Wer lieber 0.5 Liter Flaschen nehmen möchte, kann zB. Zischke Kellerbier (gibt es u.a. im Trinkgut) kaufen – ebenfalls mit Bügelverschluss.

Ein ganzer Brautag dauert ungefähr 6 Stunden. Angefangen beim Bereitstellen der Utensilien und endet mit der Reinigung der Küche. Der erste Schritt ist das Anmischen der Maische. Die Malzmischung muss hier unter ständigem Rühren eine Stunde lang auf 67-69 Grad gehalten werden. So erhält man die Bierwürze.

Nach einer Stunde schöpft man das Malz in ein Sieb und beginnt mit dem Läutern. Hierbei wird die Würze mehrfach durch das Malz im Sieb gegossen um den Restzucker aus dem Malz zu lösen.

Ist man mit dem Läutern fertig kommen noch 3 Liter Wasser zur Würze dazu und man beginnt mit dem Hopfenkochen. Dazu werden die ca. 6-7 Liter Würze 3 Stunden lang gekocht. Nach einiger Zeit gibt man den Hopfen dazu.

Der letzte Schritt vor der Gärung ist das Abfüllen in den Gärbehälter, der im Set enthalten ist. Fertig abgefüllt und nach dem Hinzufügen der Hefe sieht das dann so aus. Der Gärspund sorgt dafür, dass das CO2 entweichen kann.

Die Gärzeit beträgt eine Woche. Die Hefe hat sich am Boden abgesetzt und der Schaum ist verschwunden. Das Bier ist deutlich klarer geworden.

Hier beginnt jetzt die Flaschenfüllung unter Beimischung von ein wenig Zucker (oder Alternativ Restwürze, die man aufgehoben hat). In den Flaschen muss das Bier 3 Wochen gären. Nach 4 langen Wochen des Wartens darf das erste Glas probiert und genossen werden.

Ich finde, das kann sich sehen lassen. Und schmecken natürlich auch 🙂

Shuttle DS57U – Performance als Firewall Update

Eigentlich war der Zotac CI321 Barebone als neue Firewall angedacht. Der Releasetermin lies recht lange auf sich warten und als die ersten Händler das Teil verfügbar hatten, wurde ich auf eine Alternative aufmerksam: Shuttle DS57U mit Intel Broadwell.

Die groben Specs:

Intel Celeron 3205U CPU, 2 Kerne, 2 Threads
Zwei SO-Dimm Steckplätze
Ein 2.5 Zoll Slot für HDD oder SDD
Zwei MiniPCIe Steckplätze (Full- und Halfsize)
Ein MiniPCIe Steckplatz mit Realtek Wifi Karte (150 MBit)
Zwei Intel NICs onboard:
– Intel i211 Ethernet Controller mit MAC, PHY und PCIe-Schnittstelle
– Intel i218LM PHY verbunden mit dem MAC des Prozessors
Integrierter SD Kartenleser
2x USB3, 4x USB2
HDMI und Displayport

Details findet man auf der Shuttle Seite.

Als Massenspeicher diente mir eine Sandisk 16 GB Micro SDHC Karte (UHS 1). Für den RAM habe ich ein Crucial Modul mit 4 GB DDR3 Low Voltage eingebaut. Installiert wurde IPFire in der aktuellen Version 2.17 mit Core Update 89. Die Intel i211 habe ich als grünes, internes Interface genutzt. Entsprechend die Intel i218LM als rote, externe Schnittstelle.

Wozu aber der späte Sinneswandel vom Zotac zum Shuttle? Der Hauptgrund war ein Unterschied bei den Netzwerkkarten. Während der Zotac Barebone auf zwei passive Realtek Karten setzt, sind beim Shuttle zwei mehr oder weniger aktive Intel NICs verbaut. Die aktiven Karten sollten zu deutlich geringerer CPU Auslastung unter Last führen. Ein weiterer Bonus beim Shuttle ist eine Intel CPU der aktuellen Broadwell Architektur. Entgegen erster Informationen bietet die CPU kein AES-NI und damit keine Beschleunigung bei OpenVPN. Umso wichtiger, dass die aktiven NICs den Prozessor entlasten. Bei 250 MBit Downstream, Proxy, URL Filter etc. ist man um jedes Stück Performance dankbar. Apropos Performance, hier die Testergebnisse. Hauptaugenmerk war natürlich die Netzwerkperformance. Alles gemessen mit angepassten iperf Parametern. Vorab aber noch das Netzschema:

iperf Client und Server sind Intel Quadcore mit Intel bzw. Broadcom Netzwerkkarten. Der OpenVPN Client ist ebenfalls ein Quadcore mit Broadcom Client. Alle Tests wurden im lokalen Netz gemacht. Als Switch diente ein Gigabit Modell.

Erster Test. iperf Client zu iperf Server. Wie man den Parametern entnehmen kann, habe ich auf eine große TCP Windowsize gesetzt und zwei parallele Threads gestartet:

F:\iperf>iperf -c 192.168.0.200 -w 256k -l 256k -P2
————————————————————
Client connecting to 192.168.0.200, TCP port 5001
TCP window size: 256 KByte
————————————————————
[ 4] local 192.168.1.1 port 52004 connected with 192.168.0.200 port 5001
[ 3] local 192.168.1.1 port 52003 connected with 192.168.0.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 562 MBytes 471 Mbits/sec
[ 3] 0.0-10.0 sec 562 MBytes 471 Mbits/sec
[SUM] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec

Die bwm-ng Anzeige unter IPFire:

htop auf IPFire während der Übertragung:

Zweiter Test. Diesmal mit kleiner Window Size:

F:\iperf>iperf -c 192.168.0.200 -w 64k -l 64k -P2 -t 60
————————————————————
Client connecting to 192.168.0.200, TCP port 5001
TCP window size: 64.0 KByte
————————————————————
[ 4] local 192.168.1.1 port 52019 connected with 192.168.0.200 port 5001
[ 3] local 192.168.1.1 port 52018 connected with 192.168.0.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 3.28 GBytes 469 Mbits/sec
[ 3] 0.0-60.0 sec 3.28 GBytes 469 Mbits/sec
[SUM] 0.0-60.0 sec 6.56 GBytes 939 Mbits/sec

bwm-ng:

htop:

Der Stromverbrauch lag während dieser Tests bei 10.5 Watt im Leerlauf und 13.2 Watt unter Last.

Dritter Test. Download ISO Image aus dem Internet. Proxy und URL Filter (Ads, Adv) aktiv. Limitierung durch die max. verfügbare Internetbandbreite.

bwm-ng:

htop:

Vierter Test. OpenVPN Tunnel gegen externes IPFire Interface.

F:\iperf>iperf -c 192.168.1.200 -w 256k -l 256k -P2 -t 60
————————————————————
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 256 KByte
————————————————————
[ 4] local 10.41.21.6 port 54484 connected with 192.168.1.200 port 5001
[ 3] local 10.41.21.6 port 54483 connected with 192.168.1.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.1 sec 270 MBytes 37.7 Mbits/sec
[ 3] 0.0-60.1 sec 384 MBytes 53.7 Mbits/sec
[SUM] 0.0-60.1 sec 654 MBytes 91.3 Mbits/sec

bwm-ng:

htop:

Das Ganze nochmal mit kleiner TCP Window Size und nur einem Thread:

F:\iperf>iperf -c 192.168.1.200 -t 60
————————————————————
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 63.0 KByte (default)
————————————————————
[ 3] local 10.41.21.6 port 54489 connected with 192.168.1.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 681 MBytes 95.2 Mbits/sec

Und nochmal mit großer Window Size und einem Thread:

F:\iperf>iperf -c 192.168.1.200 -w 256k -l 256k -t 60
————————————————————
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 256 KByte
————————————————————
[ 3] local 10.41.21.6 port 54497 connected with 192.168.1.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.1 sec 648 MBytes 90.6 Mbits/sec

Die CPU Last variierte in beiden Fällen nicht nennenswert. Es wurden keine speziellen Anpassungen der Konfiguration vorgenommen.

*Update*

Fünfter Test. Download ISO Image aus dem Internet. Proxy und URL Filter (Ads, Adv) aktiv. Limitierung durch die max. verfügbare Internetbandbreite. Snort auf Rot aktiv.

bwm-ng:

htop:

Snort Settings:

Emergingthreats.net Community Rules:

community.rules
emerging-attack_response.rules
emerging-exploit.rules
emerging-malware.rules
emerging-mobile_malware.rules
emerging-trojan.rules
emerging-worm.rules