OK, also mein Energieversorger und Netzbetreiber Wels Strom hat meinen nicht ganz so smarten Iskra MT-174 durch einen „wirklich“ smarten Siemens IM350 ersetzt. Nicht nur den Iskra, sondern auch meinen zweiten dummen Ferraris-Zähler für die Wärmepumpe. Bei der Installation durch die Fachkraft vom E-Werk fiel mir auf, dass auch der Siemens eine optische Schnittstelle hat, wie der Iskra. Also, sollte es ja kein Problem sein, den neuen Zähler auf ähnliche Weise auszulesen. Jedoch stellte sich heraus, dass die optische Schnittstelle nicht für Kunden freigeschaltet ist, sondern nur die RJ12-Schnittstelle an der Unterseite des Gerätes.

Nach kurzer duckduckgo.com-Recherche bin ich auf dieses Forum gestoßen:

https://www.photovoltaikforum.com/thread/139837-siemens-im350/?pageNo=1

Hiermit ein herzlicher Dank an die Teilnehmer des Forums für Vorarbeit, ohne die es um einiges schwieriger geworden wäre. Aber zunächst musste ich mir erst die richtige Hardware basteln, damit ich die Zählerstände auch wirklich auslesen konnte. Zunächst musste ich mir entsprechende Teile bestellen.

Sämtliche Links zu bestellten Teilen stellen keine Kaufempfehlung dar. Es gibt sicher auch andere Modelle von anderen Händlern, mit denen man das gewünschte erreichen kann. Ich habe mich halt hierfür entschieden.

RJ12-Kabel mit Steckern:
https://www.amazon.de/gp/product/B000VMZHG4/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Seriell-USB-Konverter:
https://www.reichelt.de/usb-2-0-konverter-seriell-ttl-6-offene-kabelenden-1-8m-5v–delock-83116-p120573.html?CCOUNTRY=445&LANGUAGE=de

Als „Bauanleitung“ habe ich das hier verwendet:

https://www.photovoltaikforum.com/core/attachment/103207-kundenschnittstelle-converter-pdf/

Also drei Adern vom RJ12-Kabel mit dem Konverter verbinden und einem Widerstand dazwischen. Sollte, auch für mich als Nichtlöter, kein Problem sein. Voilá, Version 1 war fertig:

Ich las zwar vorher im Forum, dass man die Eingangswerte invertieren muss, dachte aber, dass das auch softwaretechnisch gehen sollte. Zumindest merkte das auch ein Teilnehmer im Forum an. Tja, es geht vielleicht mit einem Arduino, aber leider nicht mit Python auf einem Raspberry Pi. Somit erhielt ich zwar schöne Bytes im Konsolenfenster, aber die falschen.

Was anderes gibt es auch noch zu beachten: Man muss vorher im Online-Kundenportal von der EWW (https://mein.eww.at) die Kundenschnittstelle freischalten und den Schlüssel für den Datenstrom, welcher verschlüsselt aus der RJ12-Kundenschnittstelle kommt, abholen.

Aber zurück zur Hardware: Jetzt mache ich es richtig(er). Dazu brauche ich wieder ein paar neue Teile:

PCB-Schraubklemmen:
https://www.amazon.de/gp/product/B08L77HFFQ/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1

Kunstoffgehäuse:
https://www.amazon.de/gp/product/B019GFLNV4/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1

Lochrasterplatinen:
https://www.amazon.de/gp/product/B00HJ6AERW/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1

Widerstände und einen Transistor hatte ich noch zu Hause. Danach in Fritzing einen Plan erstellt:

Lotkolben an und Version 2 sah dann so aus:

Leider lieferte dieses Konstrukt nicht das erwünschte Ergebnis: Es kamen zwar Daten an, aber unvollständig und in unregelmäßigen Abständen.

Es half alles nichts, also los ging es mit Version 3: Es fiel mir ein, dass im Forum ein User seine Schnittstelle mit einem IC-Inverter gebaut hat.

IC-Inverter:
https://www.ebay.de/itm/5x-SN74LS04N-Inverter-6-fach-DIP14/310240986690?hash=item483bcdc642:g:v4MAAOSwUKZfdrSA

Im Nachhinein betrachtet, braucht man wohl keinen 6-fach, aber das war genau der Inverter, welchen der Kollege im Forum verwendet hat.

Einen neuen Schaltplan erstellt:

Das Meiste von der Platine wieder runtergelötet und den Inverter eingebaut. PIN1 und PIN6 vom RJ12-Kabel müssen meines Erachtens nicht verbunden werden. Auf alle Fälle funktionierte es bei mir auch ohne.

Die Hardware funktionierte also soweit. Aber wie kommen die Daten jetzt am Rasbperry Pi an bzw. wie werden die Daten entschlüsselt? Auch hier wieder mein Dank an die Vorreiter, welche dieses Python-Skript entwickelt haben:
https://gitlab.com/astrnad/szreader

Die Konfigdatei szreader.config muss natürlich vorher entsprechend angepasst werden. Hier trägt man auch den Schlüssel von der EWW ein:

Ich habe mich für die Ausgabe in eine Datei entschieden:

Die Daten werden dann durch eine wirre Kombination von Shell-Skript, Python, SQLite-Datenbank, PHP, HTML, JavaScript und CSS visualisiert:

Der Wert für die Erzeugung wird, wie im Jahre 2014 beschrieben, vom SMA-Wechselrichter geholt: SMA-Wechselrichter und Raspberry Pi

Was kommt als nächstes? Nochmals die selbe Schaltung für den zweiten Siemens IM350 bauen, welcher die Wärmepumpe ausliest.

Da es immer wieder Fragen zu diesem Thema gibt, hier noch ein paar Zusatzinformationen:

Wo das Skript hingelegt wird, sollte eigentlich egal sein. Bei mir heißt es readfrommt174.py und liegt im Home-Verzeichnis vom „pi“-Benutzer (/home/pi/). Nachdem die Skript-Datei erstellt wurde, muss man es noch ausführbar machen:
sudo chmod +x readfrommt174.py

Mit
./readfrommt174.py
kann man es dann starten. Danach sollte Folgendes angezeigt werden:

Sollten mehrere USB-Geräte an dem Raspi angeschlossen sein, kann es natürlich sein, dass noch der USB-Port im Skript geändert werden muss:
SERIALPORT = "/dev/ttyUSB0"
Ins /dev Verzeichnis wechseln und mit ls den Inhalt aufrufen. Bei mir gibt es nur das eine ttyUSB-Device:

Wenn das soweit läuft, dann funktioniert die Kommunikation mit dem Stromzähler.

Bereits beim Einzug ins Eigenheim 2013 wollte ich den Stromzähler auslesen können, um zu prüfen, ob gerade Strom ins Netz fließt oder von dort kommt. Durch die vorhandene Photovoltaik-Anlage war das natürlich eine interessante Information, damit der Eigenverbrauch optimiert werden kann.

Der digitale Iskra MT-174 Stromzähler, welcher mir von meinem Energieanbieter zur Verfügung gestellt wurde, bietet, neben einem LCD-Display, auch eine Infrarot-Schnittstelle, um an die entsprechenden Daten zu kommen. Um diese serielle Schnittstelle auslesen zu können benötigt man einen entsprechenden Lesekopf mit einer IR-LED und einem Fototransistor für die Sende- bzw. Leserichtung:

Der von mir gekaufte Kopf ist von der Firma Weidmann Elektronik (http://shop.weidmann-elektronik.de/index.php?page=product&info=24) und wurde problemlos auch nach Österreich geliefert. Das Gehäuse wurde offensichtlich mit einem 3D-Drucker erstellt und hat einen innenliegenden Magnetring und hält so sicher am Stromzähler:

Der Lesekopf hat auf der anderen Seite einen USB-Typ-A-Stecker und lässt sich somit ohne Probleme mit dem Raspberry Pi verbinden und bindet sich z.B. unter Raspbian auch sofort als /dev/ttyUSB0 ein.

Mit dem kleinen Python-Skript von hier https://stackoverflow.com/questions/38836848/read-serial-python

#!/usr/bin/env python

import serial
import time

SERIALPORT = „/dev/ttyUSB0“
BAUDRATE = 300

ser = serial.Serial(SERIALPORT, BAUDRATE, serial.SEVENBITS, serial.PARITY_EVEN)

ser.write(„\x2F\x3F\x21\x0D\x0A“)

time.sleep(0.5)
numberOfLine = 0

while True:
   response = ser.readline()
   print(response)

  numberOfLine = numberOfLine + 1
   if (numberOfLine >= 11):
     break

ser.close()

lassen sich dann die entsprechenden Informationen auslesen:

In der Folge habe ich dann diese Informationen über ein PHP-Skript auf einer Webseite bereitgestellt und von dort über eine Xamarin-Android-App gemeinsam mit den Daten aus dem Wechselrichter dargestellt:

Neben dem aktuellem Strombezug (links) sieht man auch den aktuellen Zählerstand. Die Lieferung (rechts) beträgt um 20:18 Uhr natürlich 0.000kW.

Ein möglicher weiterer Schritt wäre jetzt, dass man anhand der Daten automatisch bei Überschuss aus der Photovoltaik-Anlage eine Steckdose aktiviert, welche den Akku für den Rasenmäher lädt und bei Bezug aus dem Netz diese wieder deaktiviert wird. Oder die Pumpe vom Pool, etc. etc.

Und www.seventeenfour.com ist wieder mal übersiedelt 🙂 Vom treuen Raspberry Pi auf einen Turris Omnia Router. Dieser Open-Source-Router wurde von der tschechischen nic entwickelt.

Ein ARM-Prozessor mit zwei Kernen, welche mit 1,6 GHZ laufen, und bis zu 2 GB Arbeitsspeicher, sowie 8 GB Flashspeicher sprechen für sich.

Dass der Router viel mehr als ein Router ist, sieht man auch daran, dass der sogenannte Linux-Container (LXC) unterstützt. Damit lassen sich in sich „abgeschottete“ Linux-Installationen betreiben. Der Router selber läuft auf einem Derivat von openWRT, jedoch kann z.B. ein Linux-Container eine Debian-Installation beheimaten. Im Moment habe ich vier solcher Container laufen:

– Webserver (z.B. für www.seventeenfour.com)
– Fileserver (siehe mSATA im nächsten Absatz)
– VPN-Server (mit Softether-VPN)
– Test-Server (zum Rumspielen, damit nicht gleich der Webserver dran glauben muss :-))

Darüber hinaus bietet der Router, neben zwei PCI-Express-Ports für das 2,4GHZ bzw. 5GHZ-WiFi-Modul, noch einen internen mSATA-Anschluss für SSD-Platten. Somit dient er mir auch als stromsparender Massenspeicher. Ein Datenbackup wird wöchentlich auf den Linux-SAT-Receiver gemacht, der ja sowieso auch 24 Stunden läuft (zumindest im Standby).

Neben den fünf Stück Gbit-LAN-Ports und einem Gbit-WAN-Port gibt es sogar noch einen SFP-Port. Somit kann man sogar direkt, mit einem entsprechenden Modul, einen Glasfaseranschluss anschließen. Zwei externe USB-Ports runden die Anschlüsse ab, welche ich jedoch im Moment nicht im Einsatz habe. Leider habe ich noch Probleme einen Bluetooth-Dongle zu finden, welcher auch problemlos in einem LXC funktioniert. Wenn wer Tipps hat, bitte unten reinschreiben. Danke!

Die Ursachen, warum Windows Phone/Mobile leider gescheitert ist, sind man­nig­fal­tig. Darauf möchte ich gar nicht näher eingehen. Auch für mich ist die Zeit des Abschieds gekommen: Seit Mitte letzten Jahres habe auch ich auf Android „umgestellt“. Zuerst nannte ich ein OnePlus3 mein Eigen und vor Kurzem auf die Mittelklasse umgestiegen und habe jetzt ein Moto G4.

Leider läuft halt geoEarl nicht auf Android. Eine Portierung würde einer vollständigen Neuentwicklung gleich kommen, da geoEarl z.B. mit VB.net entwickelt wurde. Bei den beiden Migrationspfade auf entweder Xamarin/C# oder Java werden einem schon ein paar schöne Steine in den Weg gelegt. Ich hatte Anfang voriges Jahres sogar angefangen, eine C#-UWP-Version zu erstellen, aber es zeichnete damals ab, dass Windows 10 Mobile wohl auch nicht den Durchbruch schaffen wird.

Statt geoEarl verwende ich auf Android jetzt drei Apps:
1) GCDroid (Datenbank, Livedaten)
2) GCC (Umfangreiche Umwandlungen)
3) Go(x)° (Rechner für Multis)

P.S. geoEarl 6.0.0 ist natürlich weiterhin im Windows Store verfügbar. Ich werde es nicht löschen, solange es MS nicht löscht 😉