Smartmeter D0, SML

Diese Seite ist aktuell noch eine Materialsammlung. Das Projekt ist noch nicht abgeschlossen.

Ein "Stromzähler" der per "Blinkimpulse" anzeigt wie viel Energie gerade verbraucht wird, ist relativ einfach auszulesen. Eine passende Seite dazu habe ich auf Arduino und S0 schon veröffentlicht. Interessant wird es nun natürlich in Verbindung mit den "neuen" Zählern, die neben einer "blinkenden" LED auch noch einen Datenausgang haben. Durch den Einzug in ein neues Haus mit Zweirichtungszähler (Solarzellen) und zudem einem Zweitarifzähler (Wärmepumpenstrom) habe ich nun zwei Zähler, die nicht mehr "sichtbar" Blinken (IR-LEDs) sondern auch noch die erweiterte "D0-Schnittstelle" haben. Diese Seite beschreibt meine Schritte diese Schnittstelle per Ethernet erreichbar.

Moderne Zähler und D0

Die modernen Zähler sind mittlerweile kleine Computer, wie ein Blick in die Beschreibungen der Hersteller zeigen. Mein Zähler ist wohl von ein "EHZ-I" von EMH (http://www.emh-metering.com/de/produkte/ehz-i/)


Quelle: Produkthandbuch http://www.nzr.de/download.php?id=612

Da ich nicht genau weiß, wie die Zähler noch kommunizieren können oder vielleicht aus der Ferne beeinflussbar sind, habe ich die Seriennummern, ServerID, PublicKey etc. Unkenntlich gemacht. Interessant sind auf dem Zähler oben die grüne Öffnung, hinter der sich wohl eine IR-LED verbirgt, die bei diesem Zähler 10.000 Impulse pro kWh liefert, zumindest steht dies so auf dem Zähler. Auf dem LCD kann man sehr einfach unterschiedliche Werte ablesen. Links oben steht dazu ein Zahlencode, der die Bedeutung festlegt. Ich habe in meinem Haus allerdings zwei diese Zähler. Einer für den normalen "Gebrauchsstrom" für Licht, über den aber auch die Solaranlage (Siehe PRTG Kostal) angeschlossen ist und Strom einspeist (abzüglich dem Eigenverbrauch). Der zweite Zähler bedient die Wärmepumpe mit aktuell noch "günstigerem" Wärmepumpenstrom.

Code  Zwei Richtungszähler Zweittarifzählen.

1.8.0

Strombezug Haupttarif

nicht vorhanden

1.8.1

nicht vorhanden

Strombezug Tarif 1 (Haupttarif)

1.8.2

nicht vorhanden

Strombezug Tarif 2 (Niedertarif)

2.8.0

Eingespeister Strom

0

Beim Zweirichtungszähler gibt es noch eine "A+"-Anzeige, wenn man Strom bezieht und "A-", wenn man Strom einspeist.

Interessanter sind rechts die beiden Öffnungen mit der Metallplatte. So können über einen Magnet als Halter sehr einfach eine IR-LED und ein IR-Fototransistor montiert werden, die mit dem Zähler kommunizieren. Ich will dabei gar nichts an den Zähler senden. Aber der Zähler soll laut Beschreibung alle 1-4 Sekunden eigenständig ein Datenprotokoll ausgeben. Das ist durchaus interessanter als nur "Impulse zählen.

Man kann aber auch mit einer einfachen Taschenlampe den Zähler "anblinken" und so folgende Funktionen abrufen:

Anzahl der Blinken  Ausgabe im Display Beschreibung

1

 

Displaytest für beide Zeilen

2

PIN

Eingabe der PIN 

3

P

Aktuelle Leistung

4

E

Stromverbrauch seit der letzten Null-Stellung

5

1d

Stromverbrauch des letzten Tages

6

7d

Stromverbrauch der letzten 7 Tages

7

30d

Stromverbrauch der letzten 30 Tage

8

365d

Stromverbrauch der letzten 365 Tage 

9

0.2.2

Aktivierung der PIN-Eingabe

Einige der Werte können Sie durch ein langes Anleuchten (>5 Sek) auf 0 setzen.

Köpfe für D0

Und so ist es auch kein Wunder, wenn es verschiedene fertige Zählerköpfe und Selbstbaulösungen gibt. Die Zähler senden ihre Datentelegramme nämlich relativ überschaubar mit 9600,8,n.1 als Bytes. Die fertigen Köpfe kosten aber meist deutlich mehr, als der geübte Elektronikbastler ausgeben will. 100-300€ sind einfach zu viel für eine IR-LED mit eventuell einen Schnittstellenwandler, insbesondere wenn man nur Lesen will. Hier dennoch ein paar Links zu verschiedenen Ansätzen:

D0 am meinem Stromzähler ?

Mechanisch wird so ein Fototransistor am besten per Ring-Magnet befestigt. Das Verfahren nutzen kommerzielle Zählerköpfe und die Metallplatte am Zähler legt auch genau das Verfahren nahe. Die Fläche ist bei meinem Energiezähler ca. 28mm breit und die beiden LEDs haben einen Abstand von etwas über 6mm.

 

Da ich allerdings gar nicht schreiben oder steuern möchte, sondern einfach nur "passiv" lesen, recht mir eine LED, die halbwegs passend über die Sende-LED gesetzt wird. Relevant für das Datenprotokoll ist die rechte LED. Die mittlere LED ist zum Steuern und die ganz Links mit "IR" bezeichnete LED sendet 10.000 Impulse/kWh. Insofern bin ich sehr flexibel was die Anordnung betrifft. Es dürfte ein einfacher Ringmagnet reichen, in den der Empfänger eingebaut wird. Um sichtbares Licht auszusperren, würde ich eine kleine schwarze Filzschicht dazwischen setzen. Zwei Magnete habe ich dazu verwendet.

Alle 1-4 Sek sendet der Zähler hier mit 9600 Baud ein Telegramm nach SML-Standard. Ein Telegramm ist maximal 400ms lang. Allerdings steht im Produkthandbuch auch, dass diese Schnittstelle per Konfiguration freigegeben werden kann. Eventuell hat ihr Netzbetreiber die Schnittstelle deaktiviert. Einen ersten Test können Sie mit einer normalen Digitalkamera machen. Die meisten nehmen auch IR-Licht auf, welches vom Auge nicht gesehen wird.

 

So können Sie aber gut kontrollieren, ob die LED sendet. Interessanterweise sehe ich aber an der linken LED keine Impulse. Damit sind aber die Grundlagen vorhanden die Daten abzufragen.

Signalaufbereitung

Ich habe noch nicht das basteln angefangen, aber vielleicht starte ich mit einer BPW40, die an einen analogen Eingang beim Lichteinfall auf "Masse" zieht und dann die Daten eingelesen werden. Aber mit 9600Bit/Sek, also ca. 10000/Sek ist ein Bit ca. 100µs lang. Der Aufnehmer sollte also deutlich flotter sein. Ich bin aber noch nicht sicher, ob ich die Daten dann wirklich über einen Schmitt-Trigger auf den RxD-Anschluss des Arduino leite oder die Daten am Analogport einfach direkt selbst einlese. Wenn ein ESP8266 unter 5€ kostet, dann möchte ich nicht wirklich noch mal 50+€ allein für einen Lesekopf ausgeben. Das muss einfacher gehen. Also habe ich etwas rumgestöbert und diverse Schaltungen gefunden, bei denen ein Fototransistor direkt einen Pin eines Mikroprozessors auf Masse zieht. Vielleicht reicht das ja schon aus:

Wenn der Mikroprozessor sogar über einen internen Pullup-Widerstand verfügt, könnte es noch einfacher gehen. Allerdings muss man sich immer bewusst sein, dass man sich hier ein Stück weit in der Analogtechnik bewegt und man nicht mit TTL-Pegeln zwischen 1 und 0 unterscheiden kann. Lange Leitungen mit Kapazitäten, Fremdlicht etc. sind nicht zu unterschätzen.

Nach etwas Recherche in diversen Foren und um das Wissen der Wellenlänge habe ich einfach mal ein paar Foto-Transistoren vom Typ SP201 bestellt. Fototransistoren sollten es schon sein, da sie in der Regel schnell der Fotodioden und viel schneller als LDRs sind. Die SP201 haben folgende relevante Daten:

Parameter  Daten Bemerkung

Bauform

NPN-Fototransistor in LED-Bauform 

LED-Form mit 3mm Durchmesser passen gut in Rundmagnete und Gehäuse und sind einfacher zu Handhaben als SMD-Bauteile.

Wellenlänge für max. Empfindlichkeit

780nm

Ideal für IR-Signale und hoffentlich gut genug unempfindlich gegen normales Licht

Kollektor-Emitter-Spannung 

max. 32 V

Das ist unkritisch, da wir uns im 3,3 Volt oder 5Volt-Bereich bewegen

Gesamtverlustleistung

max. 50 mW

Das hilft für die Ermittlung des minimalen Vorwiderstandes. Bei 5V ergibt sich nach (U*I=P oder U/P=I) mit 0.05W/5V = 0,01A. Der strombegrenzende Widerstand bei 5V muss nach U/I=R mindestens 500Ohm betragen.

Anstiegszeit / Abfallzeit

je 5 Microsek

Die Daten kommen mit 9600 Baud, aufgerundet also 10.000Hz oder 0,1ms/Bit. 100Microsekunden ist ein Bit lang. Da sollten 5 Mikrosekunden an den Flanken genug Reserven bieten.

Preis 

0,25 Euro

(z.B. Pollin  https://www.pollin.de/shop/dt/Mjk5ODc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Optoelektronik/Fototransistor_SP201.html
Datenblatt: https://www.pollin.de/shop/downloads/D121007D.PDF

Den ersten Test habe ich mit der SP201 und einem RS232/USB-Adapter erfolgreich gemacht. Allerdings hat, warum auch immer, dieser Fototransistor nicht mit einem WeMos-Modul funktioniert. Dort habe ich eine BPW40 erfolgreich verwendet.

Im Datenblatt ist sichtbar, dass die Anschlussleitung des Emitter etwas kürzer ist also des Kollektors. Das was bei mit nicht der Fall. Eine Abflachung einer Seite des Gehäuse konnte ich auch nicht erkennen. Aber Anhand der einen und zwei Nasen am Anschlussdraht sind Kollektor und Emitter zu ermitteln:

Für einen ersten Test habe ich einfach mal einen USB/RS232-Adapter mit TTL-Pegel genutzt. Diese "billigst"-Adapter haben vier Anschlusskabel für Vcc, GND, RxD und RxD und gibt es bei E-Bay für unter 2€. Senden möchte ich nichts, also könnte es sogar reichen, wenn ein passender Fototransistor oder eine Fotodiode wie oben im Bild die RxD-Leitung bei Licht auf Masse zieht. Der "Ruhezustand" von RxD ist -12V (RS232) oder +5V (TTL). Das ist so gewählt, dass im Ruhezustand schon erkannt werden kann, ob die Leitung "passt" und sehr sparsame Gerät können sich so sogar parasitär mit Strom versorgen.

Als Vorwiderstand habe ich einen 10kOhm Potentiometer genutzt. So ausgestattet bin ich mit einem Terminal-Programm und dem Kabel zum Stromzähler gelaufen und habe die LED einfach mal "drangehalten". Ich war selbst verwundert, das es auf Abhieb geklappt hat.

Anscheinend hat der 10kOhm Vorwiederstand mit dem Serial/USB-Chip und dem Fototransistor genau ausgereicht, Daten zu bekommen. Aus den ersten Blick mögen die Daten "komisch" aussehen, aber das mehrfache Auftauchen des String "EMH", welches der Hersteller des Smartmeters ist, deute ich als gutes Zeichen. Er sendet 396 Zeichen. Das ist problemlos in einem UDP-Paket intern versendbar.

Ebenfalls geeignet sein sollte

Wer doch auch in die Gegenrichtung arbeiten will, muss sich entsprechende IR-Sendedioden beschaffen, die auf der fraglichen Wellenlänge schnell genug senden können. Denkbar sind hier

Hier ist dann natürlich etwas "experimentieren" angesagt, wenn der Empfänger nicht genau bekannt ist. Sowohl die Wellenlänge als auch die Intensität sind hier variabel. Mittlerweile habe ich schon Angebote auf Amazon und Co gesehen, die noch billiger sind. Aber verwechseln Sie bitte nicht IR-LEDs zum senden von Daten mit IR-LEDs als Beleuchtung für Nachtaufnahmen mit Kameras. Diese sind wohl heller aber sowohl Wellenlänge als auch die Schaltzeit dürften hier nicht ausreichend sein.

SML Protokoll

Die Bedeutung der Bits bzw. Bytes ist natürlich einheitlich festgelegt. Allerdings gibt es so viele Besonderheiten, dass ein generischer Parser zu viel verlangt wäre. Ich werde also wohl nur "meinen" Zähler entsprechend aufbereiten". Nach der Startsequenz werden alle weiteren Gruppen mit einem "01 01 01 01" eingeleitet. Ich habe daher die ganzen Werte hier aufgetrennt.

Abgesehen von Trenn-Bytes, Längenbytes Prüfsummern etc. könnte ein einfacher Parser sich erst mal an den Feldern orientieren, die mit "77 01" beginnen. Dies steht im SML-Protokoll für "SML_GetList_Response - ClientID (not set)". Diese werden direkt gefolgt von einer Nummer aus dem "OBIS Kennzahlen System", die ebenfalls aus einer Tabelle des BDEW (Bundesverband der Energie und Wasserwirtschaft e.V." entnommen werden kann.

So steht die Zeichenkette 77 07 01 00 01 08 01 FF 01 01 62 1E 52 für "Wirk Energie Tarif 1 Bezug  1.8.1" und ergibt sich aus

  • 77 07 SML_GetList_Response - ClientID (not set)".
  • 01 XX Elektrizität
  • 01 XX Kanal 1
  • 01 XX Gemessener Wert (1= Summe Wirkleistung+, 2= Wirkleistung-, 3 = Blindleistung+ etc.
  • 01 Max, Aktuell
  • xx 62 Tarifstufe
  • xx 52 Vorwertzählerstand


Quelle: BDEV http://www.edi-energy.de/files2/OBIS-Kennzahlen-System_2_2d_20151001.pdf  Seite 3 

Der Zähler hat natürlich noch einige weitere Daten geliefert. Ich habe mich mal daran versucht die Daten zu decodieren, was mit aber noch nicht komplett gelungen ist.

Bytes Bedeutung

1B 1B 1B 1B

Escape Sequenz zum Start

01 01 01 01

SML Start

76
07
00 07 06 15 FC E7
62 00
62 00
72 63 01 01

StartSMLMessage
Länge
TransactionID
GroupNo
abortOnError 

76
01
01 07 00 07 02 E0 
53 CE 0B 09 01
45 4D 48
00 00 48 95 F7 01 01 63 33 AA 00

StartSMLMessage
Länge
TransactionID

"EMH"

76
07
00 07 06 15 FC E8
62 00
62 00
72 63 07 01
77 01
0B 09 01 45 4D 48 00 00
48 95 F7 07 01 00 62 0A FF FF 72 62 01 65 02 E0 0F 29
7A 77 07
81 81
C7 82 03 FF

StartSMLMessage
Länge
TransactoinID
GroupNo
abortOnError 
MessageBody
SMLGetList+ClietnID
Seriennummer "EMH" 

SensorTime ?
HerstellerID ?
ServerID ?

01 01 01 01

SML Start 

04
45 4D 48
01
77 07 01 00 00 00 09-FF  


"EMH" 

01 01 01 01  

SML Start 

0B 09 01
45 4D 48
00 00 48 95 F7 01


"EMH" 

77 07 01 00 01 08 00 FF 64 01 02 82
01 62 1E 52 FF 56 00 04 1E D3 E9 01

Wirkenergie Total Bezug
1.8.0*255 

77 07 01 00 02 08 00 FF 64 01 02 82 01
62 1E 52 FF 56 00 00 00 07 28 01 

Wirkenergie Total Lieferung
2.8.0*255

77 07 01 00 01 08 01 FF 01 01 62 1E 52
FF 56 00 02 BE DD 30 01 

Wirk Energie Tarif 1 Bezug 
1.8.1*255

77 07 01 00 02 08 01 FF 01 01 62 1E 52
FF 56 00 00 00 07 28 01

Wirk Energie Tarif 1 Lieferung
2.8.1*255

77 07 01 00 01 08 02 FF 01 01 62 1E 52
FF 56 00 01 5F F6 BA 01  

Wirk Energie Tarif 2 Bezug 
1.8.2*255 

77 07 01 00 02 08 02 FF FF 56 00 01 5F
F6 BA 01

Wirk Energie Tarif 2 Lieferung
2.8.1*255 

77 07 01 00 02 08 02 FF 01 01 62 1E 52
FF 56 00 00 00 00 00 01

Wirk Energie Tarif 2 Lieferung
2.8.2*255  

77 07 01 00 10 07 00 FF 01 01 62 1B 52 FF 55 00 00 7F 4D 01  

 

77 07 81 81 C7 82 05 FF 01 72 62 01 65 02 E0 0F 29 01 01 83 

 

 

 

02 E2 24 E1 43 E5 3C B3 3F DB 27 51 B7 E1 5C BE EA 2A 2C
E2 A3 28 D3 C5 D8 7C 9D 19 C7 E2 D4 45 45 59 C3 49 62 57

76 AC 88 10 4B 3F

76 61 97 FA 39 01 01 01 63 48 C2 00

76 07 00 07 06 15 FC E9
62 00
62 00
72 63 02 01 71 01 63 E8 35

00
00

Start der Füllbytes um durch 4 teilbare Bytes zu bekommen.
Füllbyte

1B 1B 1B 1B

Escape Sequenz zum Ende

1A 01 AF 56 FC

Prüfsume

Es dürfte also ganz schön knifflig sein, einen richtigen SML-Parser mal eben schnell zu schreiben. Das ist aber auch gar nicht mein Ziel. Ich möchte ja "nur" Die Zählerstände und ggfls. andere Werte ermitteln, die über ein OBIS-Feld aber klar definiert sind. Eine OBIS-Kennzahl ist aber immer wieder gleich und bei den Zählerständen des EMH immer mit "77 07 01 xx" eingeleitet. Ich denke eine Such nach diesen drei Bytes ist mit 2^24 Wahrscheinlichkeit für mich zielführend genug, um die Werte auszulesen.

Ich wollte sowieso auf dem Aufnahmegerät nur eine minimale Logik implementieren.

Über zwei Datenschnittstellen (Kunden- und MSB-Schnittstelle) werden mittels SML-Protokoll (Smart Message Language) Zählerdaten übertragen.
Quelle: http://www.emh-metering.com/de/produkte/ehz-i/

SML auf Ethernet (UDP)

Zuerst hatte ich vor, per Arduino Ethernet-Schnittstelle ein Bindeglied zwischen dem Zähler und meinem LAN und der zur Visualisierung genutzten PRTG-Installation zu nutzen. Aber zum einen muss ich dann "Kabel legen" und einen Port freischalten oder per PowerLAN erst Ethernet in den Schaltschrank legen. Zum anderen habe ich mit dem ESP8266 eine viel interessantere Option gefunden, um einfache Aufgaben per WiFi direkt in ein Haus-WLAN oder eigenes "Mess-WLAN" abzuliefern.

Technisch hätte ich natürlich auch einfach die serielle Schnittstelle dieser USB-Wandler-Schaltung an einen RaspberryPi oder gleich an den PC anschließen können. Aber wollen Sie deswegen permanent einen PC laufen zu lassen? Und in meinem RaspberryPI ist die erste SD-Karte auch schon kaputt gewesen. Seitdem ich mal mit dem ESP8266 SoC und NodeMCU gebastelt habe, ist der für solche Aufgaben einfach genial. Meine Überlegung war folgende.

  • ESP8266 als Basis
    Versorgung mit Batterie oder 5V Netzadapter, IR-Fototransistor an RxD.
  • System bucht sich ins WiFi ein, liest die Messwerte und sendet diese per UDP ins LAN oder per HTTPS an einen hinterlegten Server. Ich erspare mir so einen permanent aktiven Client auf dem ein Server läuft.
  • Erfassung
    Mein eh vorhandenes Monitoring-System (Siehe PRTG) startet regelmäßig ein Skript, welches genau diese UDP-Pakete empfängt und an PRTG übergibt

Zuerst musste ich natürlich die Hardware entsprechend vorbereiten. Ich habe mich für ein "fertiges" Board entschiede, welches schon einen USB-Anschluss inkl. Programmierung hat, von der Arduino-IDE unterstützt wird und sehr klein ist. Meine Wahl fiel auf das WeMos D1 und eine BPW40, die ich einfach direkt angeschlossen habe:

Der Emitter ist auf "G" = (GND) verbunden und der Kollektor an "RxD" angeschlossen. Zum "Programmieren" muss ich den Fototransistor allerdings "dunkel" abdecken oder abziehen. Ich habe vorher mit einem Amperemeter den Kurzschlussstrom gemessen (5 mA). Selbst bei 5 Volt wären das also maximal 25mW. Laut Datenblatt soll die BPW40 aber bis zu 150mW bzw. einen Kollektorstrom von bis zu 100mA aushalten. Das ist im grünen Bereich. Später wird die Schaltung natürlich in ein Gehäuse eingebaut und die LED mit einem Ringmagnet und schwarzen Abdeckungen montiert. Aber auch so ist die Funktion schon sehr zuverlässig.

Der nächste Schritt ist die Software, die folgende Schritte durchläuft. Knifflig war etwas, dass die serielle Kommunikation nur einen Puffer von 64bytes hat, während ein Datagramm knapp 400Bytes sind. Also darf ich beim Lesen nicht trödeln. Insbesondere Ausgaben zur Fehlersuche bremsen bei 9600 Baud den Ablauf. Da der Stromzähler aber immer wieder sendet, macht es hier mal nichts aus, ein Paket zu verlieren. Ich habe meinen Code dann einfach den Buffer leert, bis ca. keine Daten mehr kommen. Dann kann ich davon ausgehen, dass es bald "losgeht" und dann stumpf lesen, bis wieder eine Pause kommt. Um den Code einfach zu halten, findet im Code keine umfangreiche Validierung, Normalisierung oder Konvertierung statt. Das überlasse ich dem empfangenden Programm. So ist der Code mit der Hardware quasi universell mit vielen Systemen einsetzbar, die spontan Daten senden.

Die eingebaute LED nutze ich als Statusanzeige.

Blink (Anzahl, Einschaltzeit, Ausschaltzeit, Pause am Ende) Phase Beschreibung

blink(1,5000,500,1000)

INIT Startet

 

blink(4,100,500,2000)

Serial ist initialisiert

 

blink(5,50,100,2000)

WiFi Verbindung wird hergestellt

 

blink(6,100,500,2000)

WiFi Connected

 

blink(7,100,500,2000)

INIT abgeschlossen

 

blink(2,400,100,2000)

LOOP Startet

 

Sek Aus, 0,5 Sek an 

Warte auf Serial Bytes

 

blink(5,100,100,0)

Sende UDP Paket 

 

blink(10,100,100,2000)

Fehler beim Einlesen

 

blink(100,30,70,0)

10 Sek "warten"

 

Zum Testen konnte ich das System erst mal direkt am PC seriell ansteuern. Jede Information, die ich an den ESP8266 gesendet habe, wurde dann per UDP wieder zurück gesendet. Ich habe dann natürlich den RxD-Eingang mit einem Fototransistor gegen Masse ziehen lassen und diesen vor den Zähler gehängt.

 

Die Ausgabe ist im WireShark gut zu sehen.

PRTG Probe

Nun fehlt nur noch die PRTG-Probe, die ab uns an mal gestartet wird und die eingehenden Daten einfängt, verarbeitet und zur Auswertung weiter gibt. Auch hier ist natürlich wieder PowerShell meine erste Wahl. Es ist damit viel einfacher einen UDP-Port zum "Lesen" zu starten als in VBScript o.ä. und eine EXE wollte ich nun doch mal nicht schreiben.

Hinweis
Achten Sie darauf, dass Sie den UDP-Port auch in der Firewall freischalten, sonst wartet ihre Probe vergeblich auf eingehende Pakete

Auf der Seite PS UDP habe ich schon entsprechende Vorarbeiten geleistet. Allerdings muss ich hier natürlich noch die Daten auflösen und konvertieren um sie dann z.B. an PRTG zu übergeben.

# Smartmeter2prtg

param (
   [string]$localip = "0.0.0.0",
   [string]$udplistenport="12345"
)

$udpClient = New-Object system.Net.Sockets.Udpclient($udplistenport)
$RemoteIpEndPoint = New-Object System.Net.IPEndPoint([system.net.IPAddress]::Parse($localip)  , $udplistenport);

Write-host "Receive-UDP:Wait für Data on Port: $udplistenport"
$data=$udpclient.receive([ref]$RemoteIpEndPoint)
write-host "Received packet from IP " $RemoteIpEndPoint.address ":" $RemoteIpEndPoint.Port

# Parse Content
write-host "Content" ([string]::join("",([System.Text.Encoding]::ASCII.GetChars($data))))


# Generate PRTG Output

Das Skript ist noch nicht fertig

Mittelfristig wäre es natürlich auch eine Idee, einen Dienst zu schreiben, der von mehreren Sensoren die Daten annimmt und dann an PRTG z.B. als HTTPPush-Sensor an PRTG zu senden. Noch direkter wäre, wenn die Aufbereitung der SML-Daten in dem WeMos selbst passiert und dieser dann gleich als HTTPPushSensor die Daten an PRTG übermittelt. Das macht aber erst Sinn, wenn ich mal mehrere SML-Zähler als Beispiele ausgelesen habe. Schon mein Zähler konnte ich nur eingeschränkt decodieren..Ich vermute ja nicht, dass PRTG selbst irgendwann selbst SML-Datenstöme direkt lesen kann.

Selbst einsetzen ?

Sie wollen selbst auf der gleichen Basis ihre ersten Schritte tun? Nichts leichter als das, denn die Hardware ist ja "Super Simpel". Einen WeMos bekommen Sie bei AlIExpress, eBay und anderen Quellen, einen BPW40 Fototransistor bei jedem gut sortierten Elektronik-Versender (Reichelt, Conrad und Co).

Die Software stelle ich hier einfach kostenfrei zum Download.

Smartmeter D0 - Code

Sie brauchen dann nur noch die Arduino IDE mit dem ESP8266 Libraries und im Code müssen Sie natürlich die IP-Adresse des Zielsystems, die WiFi-SSID und das Kennwort anpassen und dann auf den WeMos herunter laden.

Weitere Links