Zähler mit DIN EN 62056-21 an den Bus bringen?

[ctr]

Ich würde gern meine Zähler (je nach Aufwand einen oder mehrere: Photovoltaik, Wärmepumpe, Normalzähler) "an den Bus" bringen. Verbaut wurden vom Energieversorger (Süwag) Hager-Zähler mit einer Datenschnittstelle nach "DIN EN 62056-21".
Wenn ich das jetzt richtig gegoogelt habe, ist das eben NICHT, die hier viel zitierte S0-Schnittstelle (DIN EN 62056-31)... also wie bekomme ich das Ding an den Bus? Muß ich echt für jeden Zähler einen einzelnen Umsetzer auf RS232 holen und den dann wieder per RS232 Schnittstelle anschließen?

Edit: Ich denke mal sowas hier, sollte gehen:
hhcontrols.com
Habe ich aber bis jetzt nur von dem einen Hersteller gefunden und auch noch keinen Preis, geschweige denn Verfügbarkeit... ich forsche weiter

[Gast]

Überlegung:
Besorg Dir einen L&J Zähler, welcher Bezug. Lieferung und Blind kann. Dann sollte Dein Problem gelöst sein.
Dieser Zähler wird nach dem Hager als (Zwischenzähler) eingebaut.

[ctr]

Nunja auf einen zusätzlichen Zähler würde ich dann doch gern verzichten, 4 Stück reichen mir vorerst ;-)

habe das hhcontrols Gerät inzwischen als OEM-Version bei einem deutschen Händler gefunden: Kommunikationsmodul Janitza Eib-Knx, JANITZA versandkostenfrei | voelkner - direkt günstiger
Wäre halt nur zu klären ob das Gerät auch mit dem Hager-Zähler "spricht" (aber wofür gibt es schließlich Standards?) und wie ich die Infrarot-Übertragung zwischen beiden hinbekomme. Von Hager gibt es derzeit nur ein IR-Modul für die Rückwandmontage. Das "runde klobige" von hhcontrols/Janitza paßt wohl eher nicht in die kleine Ausbuchtung des Hagers... jemand eine Idee?

[ctr]

Habe mir jetzt einfach mal ein paar Opto-Köpfe besorgt und mußte feststellen, dass meine Zähler sogar schon SML sprechen... naja es hätte ja auch einfach werden können.
Muß ich mir mal OpenMUC angucken und ob ich die Daten dadurch irgendwie auf den Bus bekomme.

[nortecc]

Zähler auf den Bus

Ich schiebe dieses Thema derzeit auch vor mir her und möchte nicht zusätzlich zu meinen beiden "Smarten" Zählern noch zusätzliche Zähler kaufen.
Mir würde es schon reichen, wenn ich im ersten Gang die Impulse (10000/kWh) über einen Optokoppler einlese und die Sigmale dann in einem Binäreingang zähle. Dieser könnte dann alle paar kWh den Stand auf den Bus bringen.
Leider habe ich bisher noch keinen passenden Optokoppler gefunden. Weiter geplant ist natürlich auch die Wasserzähler anzubinden und hier eine günstige Lösung zu finden. Vor Basteleien schrecke ich hier nicht zurück, es soll nur um qualitative Aussagen zum Verbrauch gehen, kleine Zählerabweichungen sind nicht tragisch.
Wie habt Ihr es realisiert?

Gruß,
Christian

[ctr]

Nunja, Optokoppler heißen in diesem Zusammenhang die Infrarot-Magnetköpfe, die gibt es um die €70/Stück bei eBay (Händler co.met).

Für den Impulsausgang (Impuls/10kWh) reicht auch eine etwas einfachere Fotodiode an einen Binäreingang, aber da gibt es afaik nichts Fertiges, sondern es ist Löten angesagt, dazu gibt es aber schon einige Threads hier...

[ctr]

Hat sich hier zufällig schonmal jemand mit SML beschäftigt?
Ich erkenne im Hexdump einer Nachricht zwar die Escape Sequenzen zum Beginn und Ende (1b 1b 1b 1b bzw 1a <crc>) aber die eigentlichen SML Messages bekomme ich weder mit den Sourcen von openMUC noch den SML 1.03 Specs vernünftig interpretiert.

[ctr]

Habe jetzt direkt mit OpenMUC angefangen und das sieht auch recht erfolgversprechend aus: die Zählernummer bekomme ich schonmal.
Die eigentlichen Zählerwerte sind aber in irgendeinem "selbstgestricktem" Array-Konstrukt und irgendwie finde ich nicht die richtigen Typen um die die Werte auszulesen... falls sich jemand mit Java auskennt und helfen mag -> gerne mal bei mir melden.

(Es geht um das OpenMUC Framework von openMUC: Home, bis SML_List bekomme ich Daten extrahiert, aber dann muß man über eine Array von SML_ListEntry's noch an die eigentlichen Daten kommen...)

[MSC]

Habe jetzt direkt mit OpenMUC angefangen und das sieht auch recht erfolgversprechend aus: die Zählernummer bekomme ich schonmal.
Die eigentlichen Zählerwerte sind aber in irgendeinem "selbstgestricktem" Array-Konstrukt und irgendwie finde ich nicht die richtigen Typen um die die Werte auszulesen... falls sich jemand mit Java auskennt und helfen mag -> gerne mal bei mir melden.

(Es geht um das OpenMUC Framework von openMUC: Home, bis SML_List bekomme ich Daten extrahiert, aber dann muß man über eine Array von SML_ListEntry's noch an die eigentlichen Daten kommen...)

Hallo ctr,

habe mal kurz in die Quellen geschaut.
So wie es aussieht, bekommst Du mit getValListEntry() ein Array von SML_ListEntry.
Auf dem Objekt lohnt aus meiner (bislang theoretischen Sicht) mal ein Aufruf von print()...
Bei weiteren konkreten Fragen, am besten mit Code und Ausgaben noch mal melden.

Gruß Matthias

[misterspliss]

Hager SML-Zähler - Zugriff per Perl

Ich greife per Perl auf den Hager-Zähler zu.
Anbei mein Perl-Skript.

Es tut hier seit Dezember klaglos seine Dienste.
Es könnte stark eingedampft werden, aber ich hab mir nicht die Mühe gemacht, die Debugging-Einträge zu löschen.

Ab und an liefert das Skript hohe Werte zurück, so dass ich im verarbeitenden Shell-Skript noch eine Sicherheitsabfrage eingebaut habe, wenn ein bestimmter Wert überschritten wird.

Da ich nicht hoffe, pro Jahr mehr als 4000 kWh zu verbrauchen, scheint mir das Anpassen dieses Sicherheitswerts alle zwei Jahre einfacher, als die Suche nach dem Fehler. Die fehlerhaften Zahlen sind üblicherweise mindestens eine Zehnerpotenz größer.

Die Werte landen in einer rrd und werden grafisch für Misterhouse aufbereitet (Bild im Anhang).

Gruß
Misterspliss

[ctr]

Da sieht mir aber nicht nach SML aus was Du da geliefert bekommst?!

[misiu]

@ctr @MSC
Hallo,
ich versuche auch per jsml an die Daten zu kommen.
Bekomme aber nur in meinen Auge Unsinn zurück (siehe Anlage).
Könnt ihr mir das weiter helfen. Es wäre schön, wenn ich wenigstens die Seriennummer des Zähler sehen würde.

Grüße Oliver

[makki]

Keine akute Hilfe aber @Misterspliss, wenn ich einen tipp loswerden darf: ttyUSBx - x wird je nach Mondphase, Kernelversion und Ansteckreihenfolge neu ausgewürfelt.

Eine udev-rule

~# cat /etc/udev/rules.d/pl2303.rules 
# There are a number of modifiers that are allowed to be used in some
# of the different fields. They provide the following subsitutions:
#
# %n the "kernel number" of the device.
#    For example, 'sda3' has a "kernel number" of '3'
# %k the kernel name for the device
# %M the kernel major number for the device
# %m the kernel minor number for the device
# %b the bus id for the device
# %c the string returned by the PROGRAM
# %s{filename} the content of a sysfs attribute
# %% the '%' char itself
#

# PROLIFIC PL2303/FTDI USB to Serial unique port
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
	ATTRS{product}=="USB-Serial Controller", \
					SYMLINK+="usbserial-%b"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
        ATTRS{product}=="USB-Serial Controller", \
                                        SYMLINK+="ttyUSB-%b"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
        ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6001" \
                                        SYMLINK+="usbserial-%b"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
        ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6001" \
                                        SYMLINK+="ttyUSB-%b"

macht die Sache deterministischer (solange es innerhalb der Hub/Port-Topologie am selben Port bleibt) z.B. als /dev/ttyUSB-2-4.1

Makki

[misiu]

Für die, den das Interessiert...
So, nun habe ich mir mal mit den Daten die "jsml" "openMUC: Home" ausspuckt näher beschäftigt.
In einer Anleitung für ein Hager eHz habe ich folgendes gefunden:

Datentelegramm nach FNN Lastenheft EDL:
OBIS-Kennzahl Inhalt
81 81 C7 82 03 FF Hersteller-Identifikation
01 00 00 00 09 FF Geräteeinzelidentifikation / Server-ID
01 00 01 08 00 FF Zählerstand Totalregister
01 00 01 08 01 FF Zählerstand Tarif 1
01 00 01 08 02 FF Zählerstand Tarif 2

Statusinformation
01 00 0F 07 00 FF aktuelle Wirkleistung
01 00 15 07 00 FF: Wirkleistung L1
01 00 29 07 00 FF: Wirkleistung L2
01 00 3D 07 00 FF: Wirkleistung L3
01 00 01 11 00 FF (nur rückseitige Schnittstelle)
letzter signierter Total-Zählerstand
81 81 C7 82 05 FF öffentlicher Schlüssel

Zusatztelegramm (optional):
OBIS-Kennzahl Inhalt
01 00 60 32 00 02: Aktuelle Chiptemperatur
01 00 60 32 00 03: Minimale Chiptemperatur
01 00 60 32 00 04: Maximale Chiptemperatur
01 00 60 32 00 05: Gemittelte Chiptemperatur
01 00 60 32 03 03: Spannungsminimum
01 00 60 32 03 04: Spannungsmaximum
01 00 1F 07 00 FF: Strom L1
01 00 20 07 00 FF: Spannung L1
01 00 33 07 00 FF: Strom L2
01 00 34 07 00 FF: Spannung L2
01 00 47 07 00 FF: Strom L3
01 00 48 07 00 FF: Spannung L3

Und siehe da ich konnte folgenden Daten raus schreiben.

2.8.0 Zählerstand Einspeisung
OctetString of length 6 hex: 0x01 0x00 0x02 0x08 0x01 0xff
String:�
1580748

1.8.0 Zählerstand Eigenverbrauch
OctetString of length 6 hex: 0x01 0x00 0x01 0x08 0x01 0xff
String:�
1647944

aktuelle Wirkleistung
OctetString of length 6 hex: 0x01 0x00 0x0f 0x07 0x00 0xff
String: ?
1022

Die Werte für die Zählerstände muss nur noch durch 10000 geteilt werden
und dies deckt sich mit dem im Display angezeigten.
Die aktuelle Wirkleistung habe ich durch 10 geteilt. Dieser Werte scheinen realistisch zu sein.
Nun kann ich alles schön in eine MySQL DB schreiben und mit RRDTOOL graphisch anzeigen lassen.
Mein SMA WR lese ich mit den Opensource Tool "sma-bluetooth" Da bekomme ich "Ertrag seit Inbetriebnahme", "Aktuelle Leistung" und berechnet "Ertrag heute".

Grüße Oliver F.

[lio123]

@ Oliver, welchen Ehz hast Du? -Mit MUC? oder dierekt an der Schnittstelle?
-Wenn Schnittstelle, womit greifst Du die ab?

@ Wiregate: Kannst Du das auch bald machen?


Grüße,
Lio