LBS 19000149 - Landis & Gyr E350 auslesen

[starwarsfan]

Hallo miteinander,

im Download-Bereich gibt es nun den LBS 19000149 V1.2, um einen Landis & Gyr Zähler via IR-Lesekopf von Volkzähler.org auszulesen.

Die Besonderheit des Bausteines ist, dass er diese Abfrage via ssh auf einer anderen Maschine durchführen kann, da es mit den aktuellen Versionen des IR-Lesekopfes von Volkszähler.org unter CentOS6.5 Probleme mit der Erkennung des Lesekopfes gibt.

Der Doku-Text:

Dieser Baustein liest via Volkszaehler IR-USB-Lesekopf die Daten eines Landis & Gyr E350
Zaehlers aus. Die entsprechenden Shellscripte /usr/local/edomi/main/LB_LBSID_vzGetData.sh
und /usr/local/edomi/main/LB_LBSID_callVzGetData.sh werden beim ersten Ausfuehren des
Bausteines automatisch erzeugt.

Es gibt Varianten der IR-Lesekoepfe welche unter CentOS 6.5 nicht korrekt erkannt werden.
Aus diesem Grund bietet der Baustein die Moeglichkeit, die Abfrage via ssh auf einem anderen
Linux-Rechner durchzufuehren, welcher den Lesekopf korrekt erkennt. Dazu sind die folgenden
Schritte notwendig:
- E15 auf 1 setzen
- Baustein einmalig triggern
- Das erzeugte Caller-Script LB_LBSID_callVzGetData.sh mit der IP der Remote-Maschine anpassen
- Das erzeugte Abfrage-Script LB_LBSID_vzGetData.sh auf die Remote-Maschine kopieren und mit
Execute-Rechten versehen (chmod +x /home/edomi/LB_LBSID_vzGetData.sh)
- Key-Login von der Edomi-Maschine auf die Remote-Maschine einrichten

E1: Debug-Modus de-/aktivieren. Default: 0 (aus)
E2: Trigger des Bausteines.
E3: Zu verwendendes Device, i.d.R. /dev/ttyUSB0.
E4: Zu verwendende Baudrate, Default 300. Wird aktuell nicht verwendet!
E5: Abfragescript lokal (0) oder via ssh (1) ausfuehren. Wird hier ssh gewaehlt, muss
der ssh-Login eingerichtet und die IP der Remote-Maschine im Caller-Script eingetragen werden.
E6-E15: Auszulesende Werte 1-10. Hier muss der entsprechende Schluessel, also der Wert vor der
Klammer angegeben werden. Der Output des E350 Zaehlers sieht bspw. so aus:

<li>/LGZ4ZMF100AC.M27 - Herstellerkennung</li>
<li>F.F(00) - Fehlercode</li>
<li>0.0( 6909) - Zaehlernummer</li>
<li>C.1.0(15257077) - Identification number 2.1</li>
<li>C.1.1( ) - Identification number 2.2</li>
<li>1.8.1(013518.301*kWh) - Hochtarif, bzw. einziger Tarif: Zaehlerstand
Energielieferung
</li>
<li>1.8.2(022253.319*kWh) - Niedertarif: Zaehlerstand Energielieferung</li>
<li>2.8.1(000000.001*kWh) - Hochtarif, bzw. einziger Tarif: Zaehlerstand
Energieeinspeisung
</li>
<li>2.8.2(000000.000*kWh) - Niedertarif: Zaehlerstand Energieeinspeisung</li>
<li>1.8.0(035771.620*kWh) - Summe Zaehlerstand Energielieferung</li>
<li>2.8.0(000000.001*kWh) - Summe Zaehlerstand Energieeinspeisung</li>
<li>15.8.0(035771.622*kWh) - Summe Energie gesamt</li>
<li>C.7.0(0010) - Number of phase fails L1..L3</li>
<li>32.7(234*V) - Spannung L1</li>
<li>52.7(231*V) - Spannung L2</li>
<li>72.7(231*V) - Spannung L3</li>
<li>31.7(00.481*A) - Strom L1</li>
<li>51.7(002.85*A) - Strom L2</li>
<li>71.7(004.57*A) - Strom L3</li>
<li>82.8.1(0005) - ?</li>
<li>82.8.2(0000) - ?</li>
<li>0.2.0(M27) - Software ID</li>
<li>C.5.0(0421) - Internal operating state</li>
<li>! - Endesequenz</li>

A1: Herstellerkennung
A2: Fehlercode
A3: Zaehlernummer
A4: Das Gesamtresultat der Abfrage. Zeilen jeweils separiert durch "|".
A6-A15: Abgefragte Werte analog zu E6-E15

Changelog:
1.2 (2017-05-30)
- Debug-Output korrigiert.

1.1 (2016-12-30)
- Dateiname der Logs korrigiert: LandisGyrAuslesen_LBS19000149_&lt;id&gt;

1.0 (2016-11-19)
- Initiale Version

Der Baustein erzeugt beim ersten Aufruf die beiden Shell-Scripte /usr/local/edomi/main/LB_LBSID_vzGetData.sh
und /usr/local/edomi/main/LB_LBSID_callVzGetData.sh. Das call-Script wird verwendet, um das get-Script aufzurufen. Wird E5 auf 1 gesetzt, also die ssh-Variante verwendet, ist einmalig folgendes zu tun:

• Auf der Remote-Maschine einen User edomi anlegen
• Das erzeugte Script /usr/local/edomi/main/LB_LBSID_vzGetData.sh auf die Remote-Maschine nach /home/edomi/LB_LBSID_vzGetData.sh kopieren
• Script ggf. ausführbar machen:
  

  # [I]chmod +x /home/edomi/LB_LBSID_vzGetData.sh[/I]

• Das Script sollte sich direkt auf der Remote-Maschine nun bereits ausführen lassen und alle gelesenen Werte auf der Konsole ausgeben:
  

  # /home/edomi/LB_LBSID_vzGetData.sh

• ssh-Login von der Edomi-Maschine auf die Remote-Maschine einrichten
  • ssh-keygen auf edomi-Maschine,
  • kein Passwort für den erzeugten Schlüssel vergeben
  • public-Key auf der Remote-Maschine in die Datei /home/edomi/.ssh/authorized_keys einfügen, ggf. Rechte setzen:
    

    # [I]chmod 644 /home/edomi/.ssh/authorized_keys[/I]

• ssh-Login von der edomi-Maschine auf die Remote-Maschine sollte nun bereits funktionieren:
  

  [I]ssh edomi@<ip-remote-maschine>[/I]

  Beim ersten Verbinden muss man den noch unbekannten Key einmalig mit yes bestätigen. Wichtig: Das muss ohne Eingabe eines Passwortes funktionieren!
• IP der Remote-Maschine in /usr/local/edomi/main/LB_LBSID_callVzGetData.sh eintragen
• Nun sollte sich "/usr/local/edomi/main/LB_LBSID_callVzGetData.sh 1" aufrufen lassen, den Zähler via ssh-Tunnel auslesen und die Werte auf der Konsole ausgeben.

Hinweis 1:
Sollte das Schlüsselpaar nicht mit dem Default-Namen id_rsa angelegt worden sein, muss dessen Name in LB_LBSID_callVzGetData.sh natürlich ebenfalls angepasst werden.

Hinweis 2:
Sollte sich das Device des Lesekopfes ändern und es wird die SSH-Variante des Bausteines verwendet, dann muss das neue Device im Script auf der Remote-Maschine angepasst werden! Am einfachsten geht das, indem das lokale Script gelöscht und in E3 das neue Device eingetragen wird. Der LBS generiert daraufhin das Script neu, welches dann lediglich mit identischen Rechten auf die Remote-Maschine kopiert werden muss.
Viel Spass mit dem Baustein und immer her mit dem Feedback!

[Stoxn]

Wie äußert sich denn das Problem mit CentOS 6.5 bei Dir?

Nach Installation des Kernel Moduls aus diesem Thread und Setzen der richtigen Baudrate sieht meine Ausgabe schon besser aus.
Aber es scheint noch ein Problem mit der Codepage oder immer noch mit dem Modul zu geben.

Habe gerade kein anderes Linux rumfliegen - setze die Tage mal ein Raspberry auf
Sieht das bei Dir unter CentOS ähnlich aus:

??SY5?3DA?00??V3.0??
?
?-0:0.0.0??55(009009??3??
?-0:?.?.0??55(0000????.5?66?0????詍
?-0:??.?.0??55(000060.?5?ש?
?-0:??.?.0??55(000??3.6??ש?
?-0:6?.?.0??55(000?66.36?ש?
?-0:?.?.0??55(0003?0.?3?ש?
?-0:96.5.5??55(?0??
0-0:96.?.?55??55(??SY?309005??3??
!?

Danke & Gruß,
Patrick

[Stoxn]

Hm, habe das Cent OS Modul in meiner Test edomi noch mal gebaut und den Lesekopf unter Mac OS getestet: Gleiche Ausgabe. Befürchte, dass es ein Hardware Problem ist :-/

[starwarsfan]

Hi

Das Problem äußert sich so, als dass der Lesekopf nach einem Reboot nicht mehr funktioniert, da dabei wieder der alte Treiber geladen wird. Es müsste also eine neue initrd gebaut werden.

Die Codepage-Probleme kann ich nicht nachvollziehen. Die Ausgabe ist sowohl unter CentOS 6.5 als auch 7.2 korrekt.

[Stoxn]

Okay, danke für die Info - probiere es dann noch mal mit dem volkszaehler Raspberry Image...

[Stoxn]

Auweia, lag an meinen STTY Einstellungen; die Ausgabe passt jetzt.
Dann schaue ich mal, was ich mit den Werten machen kann.

Ich hoffe mal, dass ich mit dem Reboot Problem leben kann.

[martinb07]

Hallo starwarsfan

Danke für den Tipp mit deinem LBS. (Link)
Kann ich das Script auch ohne Probleme auf Debian verwenden?

Das Script beschwert mit folgendem Text:

LBS...: 4: read: Illegal option -t
LBS...: 8: read: Illegal option -t

[jonofe]

verwendet der User, der das Skript auf dem Debian Server ausführt 'bash' als shell?

Wenn das nicht der Fall ist, dann kann das die Ursache sein.

Herausfinden kannst du es mit:

echo $0

[martinb07]

ja, tut er.

[jonofe]

könnte noch an der version der bash liegen:

$ [COLOR=#0000CD][I]echo "$BASH_VERSION"[/I][/COLOR]
4.3.48(1)-release

ansonsten mal auf dem Debian System

read --help

eingeben.

Welches OS ist es denn genau?

[martinb07]

martin@debian:~$ echo "$BASH_VERSION"
4.3.30(1)-release
martin@debian:~$ cat /etc/debian_version
8.8
martin@debian:~$ uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux
martin@debian:~$ read -h
-bash: read: -h: Ungültige Option
read: Gebrauch: read [-ers] [-a Feld] [-d Begrenzer] [-i Text] [-n Zeichenanzahl] [-N Zeichenanzahl] [-p Prompt] [-t Zeitlimit] [-u fd] [Name ...]

[martinb07]

Auf dem Wiregate klappt das mit dem Script, nur erhalte ich keine Ausgabe. Weder beim manuellen Starten des Scripts, noch in der Logik.

Was mache ich, wenn ich mehr als einen Zähler auslesen will? Ich habe bei mir drei Zähler die ich abfragen will.

Edit: Beim Wiregate werden die Leseköpfe wie im Anhang angesprochen.

[starwarsfan]

Hi,

werden die Sensoren überhaupt korrekt erkannt?

[martinb07]

Ja. Mit dem Script am Wiregate werden die korrekten Zählerstände ausgelesen.
Wenn ich die GA aber mit Edomi abfrage kommen da ganz komische Zahlen raus. auf jeden Fall nicht die Zählerstände.
Kann es an dem Protokoll nach IEC ... liegen?

[starwarsfan]

Hallo Martin,

wenn ich mir Dein Script ansehe, dann findet sich dort in den Zeilen 23-25 folgendes:

#my $device = "/dev/ttyUSB0";        #Studio
#my $device = "/dev/ttyUSB1";        #Heizung
my $device = "/dev/ttyUSB2";        #Haus

Damit wird also /dev/ttyUSB2 abgefragt, ttyUSB0 und ttyUSB1 sind auskommentiert.

Das Script vom LBS 19000149 fragt im Moment fix /dev/ttyUSB0 ab. Du könntest testweise direkt im Script die entsprechenden Stellen ändern und das Script von Hand aufrufen. Alle verfügbaren Werte sollten dann Zeile für Zeile direkt auf der Konsole ausgegeben werden.

Mehrere Zähler abfragen ist im Moment nicht so ganz einfach. Folgendes sollte aber händisch klappen:

• Entsprechend viele Kopien des Script anlegen und jeweils das entsprechende Device eintragen.
• Den LBS entsprechend oft unter einer neuen Baustein-Nummer importieren
• In jedem dieser LBS den ssh-Script-Aufruf so anpassen, dass das jeweils zugehörige Script aufgerufen wird.

Das ist aber nur ein Workaround, nach dem Du ein und denselben LBS unter verschiedenen Nummern im System hast, da der Baustein aktuell nicht verschiedene Scripts triggern kann.

Interessante Idee für die Weiterentwicklung...