Zählerabfrage als Wiregate Plugin

[lio123]

Hi Gunnar,

nur um dem richtigen Faden zu folgen...
...geht es bei Dir ebenso ums das SML-Skript von Mirko, mit den selben Ursachen?

Danke und Gruß,
Lio

[gklein]

klar, die Arbeit hast Du ja schon gemacht :-)
socat tut schonmal - auch einiges fixer als Perl. Der Rest dann morgen (hoffentlich).

Hier mal der Aufruf:
socat -T 3 - /dev/ttyUSB1,echo=0,b9600,raw,parenb=1,parodd=0,cstopb= 1,readbytes=512|od -x|cut -c 9-|sed 's/ //g'
1b1b1b1b01010101077611001e025abe
00620062637201010176070111004a02
1eea04099f03dec87458018a6301b73c
760000070211be1e625b620072000763
770109010304c89f58de8a7472010162
0265e94a79b10777818182c7ff030101
01014504484d770101070000090001ff
010109010304c89f58de8a7477010107
0100000863ff82016201521e56ff0500
f45b0172077700010802ff0001630182
1e62ff52005600002b12770101070100
010801ff6201521e56ff0300ad8b014b
077700010802ff0101011e62ff520056
00002b12770101070100020801ff6201
521e56ff010047d0012707770001070f
ff0001011b62ff5200557100019d0777
818182c7ff050101010102830f0afd92
eb550cea6621fd9f2edb9dc797ddd394
3a82433dfaaaf3f4d88b6a91151ea4f3
44a05db7e777c7ccf5be2b1d01016301
29a4760000070211be1e625e62007200
0263710163010b2e000000001b1b1b1b
031a528d1b1b1b1b0101010107761100
1e0260be006200626372010101760701
11004a0220ea04099f03dec87458018a
6301eb2c760000070211be1e62616200
72000763770109010304c89f58de8a74
720101620265e94a79b30777818182c7
ff03010101014504484d770101070000
090001ff010109010304c89f58de8a74
770101070100000863ff82016201521e
56ff0500f45b017e077700010802ff00

[JuMi2006]

Die Auswertung ist ja schon gemacht
Du musst lediglich einen Datensatz rausfiltern ...

[gklein]

Gute Idee, Script läuft momentan immer noch vor sich hin.
Hab parallel mal socat am zweiten Kopf getestet. Sieht erst mal ganz gut aus:

socat -T 3 - /dev/ttyUSB1,echo=0,b9600,raw,parenb=1,parodd=0,cstopb= 1|od -tx1
0000000 1b 1b 1b 1b 01 01 01 01 76 07 00 11 02 1e 3d f0
0000020 62 00 62 00 72 63 01 01 76 01 01 07 00 11 02 4a
0000040 bf 50 09 04 03 9f c8 de 58 74 8a 01 01 63 02 9c
0000060 00 76 07 00 11 02 1e 3d f1 62 00 62 00 72 63 07
0000100 01 77 01 09 04 03 9f c8 de 58 74 8a 01 72 62 01
0000120 65 02 4a c3 7d 79 77 07 81 81 c7 82 03 ff 01 01
0000140 01 01 04 45 4d 48 01 77 07 01 00 00 00 09 ff 01
0000160 01 01 01 09 04 03 9f c8 de 58 74 8a 01 77 07 01
0000200 00 01 08 00 ff 63 01 82 01 62 1e 52 ff 56 00 05
0000220 5b 5b 31 01 77 07 01 00 02 08 00 ff 63 01 82 01
0000240 62 1e 52 ff 56 00 00 00 12 2b 01 77 07 01 00 01
0000260 08 01 ff 01 01 62 1e 52 ff 56 00 03 8b 14 0a 01
0000300 77 07 01 00 02 08 01 ff 01 01 62 1e 52 ff 56 00
0000320 00 00 12 2b 01 77 07 01 00 01 08 02 ff 01 01 62
0000340 1e 52 ff 56 00 01 d0 47 27 01 77 07 01 00 0f 07
0000360 00 ff 01 01 62 1b 52 ff 55 00 00 04 dc 01 77 07
0000400 81 81 c7 82 05 ff 01 01 01 01 83 02 0a 0f 92 fd
0000420 55 eb ea 0c 21 66 9f fd db 2e c7 9d dd 97 94 d3
0000440 82 3a 3d 43 aa fa f4 f3 8b d8 91 6a 1e 15 f3 a4
0000460 a0 44 b7 5d 77 e7 cc c7 be f5 1d 2b 01 01 01 63
0000500 c4 c5 00 76 07 00 11 02 1e 3d f4 62 00 6

Muss mich dann nur mal an der Auswertung im Perl versuchen.

Grüße
Gunnar

[JuMi2006]

Hallo Gunnar,

mangels eigenen SML-Zählers kann da natürlich was im Argen sein. Die Fehlerbehandlung war ja auch nicht implementiert.

Perl + Serielle + Ich sind über Device::SerialPort auch nie richtig Freunde geworden. Generell ist das sehr "gewöhnungsbedürftig" ich hatte mal 3 (drei!) Alix1D die beim gleichen Script anders reagierten (bis hin zum wegfliegen des USB).
Versuch das ganze vielleicht mal so umzustellen wie hier:
SourceForge.net Repository - [openautomation] Contents of /tools/d0-IEC62056-meter/iec62056-meter.pl
Ab Zeile 66 bzw. 86 wircd das ganze über "echo socat" gelöst ...

Die Device::SerialPort Geschichte würde ich in Perl als "broken" bezeichnen. Damit habe ich schon Tage verbracht.

@Lio:
Ich vermute da USB-Probleme ... will aber auch nicht ausschließen dass das Script irgendwo mal ins leere läuft.

[gklein]

Hallo lio, hallo Mirko,

ich habe ein ähnliches Verhalten. Mein raspberry hängt sich nach ca 4 bis 5 Stunden Scriptlaufzeit einfach auf. Ich hab jetzt schon verschiedenste Sachen getestet:
- Skript darf nur einfach laufen (siehe vorherige Post)
- hab parallel Logging mitlaufen lassen ob die Last nach oben geht - Fehlanzeige, steht auf einmal
- gleiches für den Speicher - ebenso Fehlanzeige,.

Momentan vermute ich, dass es an der tty-Behandlung im Perl liegt, da der Rapsi mit vzlogger und dem gleichen Lesekopf tagelang problemlos läuft.

Ich habe jetzt das Perlscript so verändert, das es als Schleife alle 20 Sekunden die tty liest und die Daten ausgibt ohne den Port zu schließen. Ist quasi ein Daemon geworden.
Der Test läuft seit heute - ich werde berichten.

Grüße
Gunnar

[lio123]

Hallo Mirko,

das beruhigt.
Als nachdem der Wandler nun lange am WG ohne Nutzung ist und das System läuft, kanns nun mehr nur an Cron, dem skript oder irgendwas mit usb liegen.

GRüße,
lio

[JuMi2006]

Das sorgt dafür dass keine Nachricht an root geschickt wird.
Falls ein aktiver email-Dienst im WireGate hinterlegt ist würde Dir das Wiregate sonst jedes mal die Ausgabe per Mail schicken

[lio123]

Hallo,

danke Mirko,
sowas hatte ich mir schon gedacht.

Leider gibt es bzgl des Test schlechte neuigkeiten.
Datt ding will einfach nich.
Hab mir anstelle des PL2303 Wandler einen FTDI FT232R Wandler getauscht.
Dem neuen Wandler wird nun auch ein Namen (/dev/usbserial-A601NKCL) im WG zugewiesen (udev??)
Das hat Makki erwirkt. Beim PL2303 war dies danach nicht der Fall.

Jedoch nach ca 3h ist das WG mit dem neuen Wandler auch nicht mehr erreichbar. Da hilft nur ein Spannung abschalten.

Ich werde nun mal den cornjob deaktivieren und den Wandler aber stecken lassen. Mal gucken was passiert.

Mirko,
könntest Du mir noch diese Zeile erklären (aufruf cornjob)

/usr/bin/perl /home/user/sml.pl das hier: >/dev/null 2>&1

[JuMi2006]

Eigentlich ist es ganz einfach. Auch bei SML wird der s.g. OBIS-Code verwendet.
Im SVN hab ich den Link zu Wikipedia hinterlegt das wiederum auf ein die Erklärung der Codes verweist.

Beispiel:

1.8.0 = Gesamtbezug über alle Tarife
1.8.1 = Bezug Tarif 1
1.8.2 = Bezug Tarif 2
usw.
2.8.0 = Einspeisung über alle Tarife
2.8.1 = Einspeisung Tarif 1
usw.
Dann gibt es noch diverse andere Codes für Leistung, Spannung pro Phase usw. hier ist es jedoch vom EVU/Messstellenbetreiber abhängig welche Werte der Zähler liefert. Das EVU bestellt die Zähler meist vorkonfiguriert beim Hersteller.

Im SML Protokoll werden diese Codes nun auch verwendet, das zeigt der Kommentar im Plugin:

#070100010801FF = 1.8.1


Das FIXME! bezieht sich auf einen Wert den ich bei Dir keinem Obis-Code zuordnen konnte. Da würde es nur helfen das mit mehreren Zählern zu vergleichen...bleibt also als Aufgabe für zukünftige Nutzer ... "0F" ist dort irgendwie nicht nachvollziehbar.

So jetzt zum eigentlichen Problem:
Die Werte die Du auslesen willst trägst Du hier ein:

my @obis;
push @obis,{obis=>"1.8.0",  fact=>10000, ga =>"14/8/1", dpt => 14, rrd_name => "Zaehler_Verbrauch", rrd => "c"   }; #rrd: c=counter ; g=gauge
push @obis,{obis=>"7.0",    fact=>10,    ga =>"14/8/0", dpt => 9 , rrd_name => "Zaehler_Leistung",  rrd => "g" };
#neuer Wert
push @obis,{obis=>"1.8.1",    fact=>10,    ga =>"14/8/2", dpt => 14 , rrd_name => "Zaehler_Leistung",  rrd => "c" };
#usw.

Zählerstände haben hier immer den DPT14 und c=counter.
Ein Momentanwert (Leistung,Spannung etc.) bekommt DPT9 g=gauge
Den Faktor muss man ausprobieren ... das hab ich nun nicht implementiert ... so tief wollte ich mich nicht in SML einlesen.


Grüße

[lio123]

Hallo,

leider kann ich noch nicht berichten, hatte (habe?) wohl probleme mit dem USB-Wandler. Nun habe ich einen neuen und werde testen.

Ein erster Zwischenerfolg:
Den gleichen Zähler, nämlich EMH-EHZ-H benutze ich für die Wärmepumpe mit 2 Tarifen. Irgendwie gab's da wohl ein Sichtproblem zwischen Zähler und Lesekopf, wie sich eher zufällig herausstelle.

Aber nun:
Mirko, dazu bräuchte ich ausser den OBIS
#0701000F0700FF = 7.0 FIXME !!! [0F]0700
#070100010801FF = 1.8.1
noch die
#070100010802FF = 1.8.2
#070100010800FF = ???

Ist das was größeres?
Leider verstehe ich nicht ganz, wie Du da vorgehst.
Die Hex-Obis sind ja im skript nur kommentiert.


Danke und GRüße,
Lio

[XueSheng]

Das kommt davon, wenn man zu faul ist mal eben die Kernel Version zu prüfen. Irgendwie hatte ich im Hinterkopf, dass Ubuntu 12.10 einen neueren Kernel verwendet.

Makki hatte mir gestern noch einen neuen Kernel für das Wiregate aufgespielt. Danach funktionierte die Kommunikation mit dem Schreib-Lese-Kopf ohne Probleme!

Nochmals Danke für die schnelle Hilfe!

[Udo1]

meinen Laptop mit Ubuntu 12.10 bemüht. Mir ist noch nicht ganz klar, warum ich damit nicht weitergekommen bin.

Weil die Kernel-Version von Ubuntu 12.10 < 3.3-rc2 ist.

Gruß
Udo

Edit: Asche auf mein Haupt... Du hast Recht. 12.10 hat schon Kernel 3.5.4 und höher.
Warum es dann nicht funktioniert hat? Keine Ahnung.

[XueSheng]

Auf welcher Linux-Distri läuft das? Welche Kernel-Version?

Beachte bitte den Hinweis bezüglich der Kernel-Version:
volkszaehler.org - wiki - USB-IR-Schreib-Lesekopf

Der Hinweis zum Kernel war mir nicht entgangen. Daher hatte ich nach den ersten Gehversuchen mit dem Wiregate meinen Laptop mit Ubuntu 12.10 bemüht. Mir ist noch nicht ganz klar, warum ich damit nicht weitergekommen bin.

Allerdings habe ich nun hterm mit win7 getestet und siehe da, es kommt eine Rückmeldung!

Also nochmals Danke an JuMi und Udo für die schnelle Hilfe!
@Makki: Ich schick Dir ne PM bzgl. dem Wiregate und dem Kernel patch.

[makki]

Die meisten WG haben 2.6.32..

Es gibt seit Aug 2012 (u.a. deswegen) Kernel 3.5.1, der Ubuntu.next entspricht - nachdem das aber schon schiefging und dann mehr Frust als Freude bereitet, machen wir das Update lieber händisch nach Meldung: offenes Wartung-VPN + Post/PN/eMail + Zeitfenster für reboot.

Makki