Elektrozähler auslesen

Ich wollte unseren Stromverbrauch transparent machen, also habe ich gegen schlappe 100€ einen elektronischen Stromzähler von SYNA einbauen lassen. Es ist ein Iskra ("Funke") MT175 mit einer Infrarot-Schnittstelle. Jetzt geht es darum, den Zähler an unseren FHEM Server anzuschließen.

IR-Lesekopf

Mein Zähler sollte mit Volkszähler funktionieren und Smart Metering Language (SML) sprechen. Deswegen habe ich einen Volkszähler IR-Lesekopf mit dem TTL-Ausgang zusammengelötet. Eine schöne Übung in SMT. Volkszähler Lesekopf ist sehr zu empfehlen: er hat eine ordentliche Verstärkung, stabiles Gehäuse und einen starken Magneten (vorsicht!). Ein Schmitt-Inverter sorgt für Hystherese.

Ich habe die Schaltung mit EveryCircuit simuliert. Es reichen schon ca. 50 uA Photostrom (0,7V / 13kOhm) um den Pegel zu kippen.

Ich habe den Lesekopf zum Testen zuerst mal an einen CH-340 USB-seriell Wandler angeschlossen. Vorsicht, wie so oft sind die "RX" und "TX" vertauscht! "Transmit" und "Receive" sind eben nicht eindeutig. Man soll dazu "in" und "out" schreiben. Die Treiber sind unter Linux normalerweise mit an Bord, unter Windows muss man eventuell auf die Suche gehen.

Man kann den Lesekopf erst mal an sich testen. Dazu richtet man ihn ohne Gehäuse gegen eine IR-reflektierende Fläche, um eine geschlossene Kommunikationsschleife (Loopback) einzurichten. Bei mir hat die Arbeitsplatte gereicht. Mit screen /dev/ttyUSB0 9600 (oder einem anderen Terminalprogramm) und einigen Tastendrücken testet man sie durch. Optimalerweise kommen die gleichen Buchstaben zurück, die man getippt hat. Kommen Rechtecke o. ä. zurück, dann kommt zumindest der Startbit durch. screen beendet man mit Strg+A, \ . Man kann auch mit einer kleineren Baudrate probieren. 9600 baud ist eben die von unserem Zähler. Den kann man auch gleich anpeilen, um die Sendeseite ist herauszufinden. Der Iskra sendet von sich aus, ohne Anforderung. Man kann im binären Datenstrom Strings wie "ISK" sehen, also die Kommunikation funktioniert. Der Aufbau des binären SML Protokolls wird auf der Schattenseite beschrieben und in der Technischen Richtlinie BSI TR-03109-1 definiert. FHEM sollte die Sprache aber gut beherrschen.

FHEM auf Raspberry Pi Zero W

Es schien mir am besten, eine lokale FHEM Instanz zu etablieren und sie an den Hauptserver per fhem2fhem anzubinden. Dafür ist ein Raspberry Pi Zero W mit WLAN optimal. Ich habe das aktuelle Debian Stretch auf die uSD Karte geschrieben und vor dem ersten Boot SSH Server und g_ether USB Gadget eingeschaltet, damit ich per USB Kabel und SSH darauf kommen kann:

• Datei ssh anlegen, um den SSH-Zugang 1 mal freizuschalten
• In config.txt USB OTG Device Tree Overlay freichalten, gleich den Bluetooth ausgeschalten und den besseren UART PL011 freischaufeln.

  # Additional overlays and parameters are documented /boot/overlays/README
  dtoverlay=dwc2
  #dtoverlay=pi3-miniuart-bt
  dtoverlay=pi3-disable-bt

• Kernel Module freischalten in cmdline.txt: modules-load=dwc2,g_ether

Nach dem ersten Boot, sudo raspi-config (enable SSH, expand Filesystem, passwort und hostname-Änderung, WLAN-Zugang usw.), den obligatorischen sudo apt get update, sudo apt dist-upgrade, habe ich den Lesekopf angeschlossen (Stromversorgung an +3,3V, Pin 1 - Pi ist nicht 5V tolerant!) und den screen /dev/ttyAMA0 9600 Test wiederholt. Dann wurde FHEM Debian installiert, zum Laufen gebracht, fhem update durchgeführt, und abgesichert. Den Zähler und FileLog habe ich angelegt

define MT175 OBIS /dev/ttyAMA0@9600
define FileLog_MT175 FileLog ./log/MT175-%Y-%m.log MT175

und die Readings kamen jede Sekunde! Das macht ca. 2,5 MB FileLog in 1,5 Stunden. Um die Datenmenge zu reduzieren habe ich event-on-change eingeschaltet (empfehlenswert für alle FHEM Readings, damit verschwinden konstante Version, ServerId usw. aus dem Log) und das interval auf 60 Sekunden hochgesetzt. Mit einem Excel-Sheet unten auf dieser Seite konnte ich die Readings für Leistung pro Phase entziffern.

attr MT175 event-on-change-reading .*
attr MT175 suppressReading total_consumption_Ch1
attr MT175 interval 60
attr MT175 alignTime 00:00
attr MT175 channels {"1.0.36.7.0.255"=>"powerL1", "1.0.56.7.0.255"=>"powerL2",
 "1.0.76.7.0.255"=>"powerL3"}

Ein Mittelwert pro Interval wäre besser, bisher hatte ich aber mit einem event-aggregator keinen Erfolg:

attr MT175 event-aggregator power:60:linear:mean, powerL1:60:linear:mean, 
 powerL2:60:linear:mean, powerL3:60:linear:mean,total_consumption:60:none:v

Jetzt kann man den Zaehler-FHEM mit dem Haupt-FHEM verbinden, dabei ist zaehler der hostname des Zähler-FHEMs und auch sein Instanzname in Haupt-FHEM.

define zaehler FHEM2FHEM zaehler LOG:.* xxx
define MT175 cloneDummy OBIS
define FileLog_MT175 FileLog ./log/MT175-%Y-%m.log MT175

Hier ein Beispieltag: Man sieht das Rushhour am Morgen, abends wurde gebacken. Die Phasen sind nicht gleichmässig belastet. Ich muss die Ofenbeschaltung überprüfen...

Die vorläufige Montageart bringt einen akzeptablen WLAN-Empfang :)

Gas- und Wasserzähler

To be continued :)