Re: [vz-users] Udo Lesekopf und Raspberry PI

sebastian_michel Tue, 07 Jan 2014 08:54:40 -0800

Ändere mal deine config dahingehend ab, dass als identifier "1.8.1" drin steht.

Was für eine vzlogger Version nutzt du eigentlich? Es gab/gibt ein Problem mit dem Setzen der parity vzlogger?

Sebastian

Am 07.01.2014 14:13 schrieb Michael Wulz <[email protected]>:

Hallo,

habe was bemerkt.

Wenn ich den vzlogger starte dann ist immer "crtscts" im ssty -F aktiv.
Dann geht nix.

Ich setze dann mit # stty -F /dev/ttyUSB0 -crtscts
diese Option weg und plötzlich spuckt mein Zähler daten aus.

VZlogger meldet folgenden Output:
root@raspberrypi:/data/vzlogger# vzlogger -c /etc/vzlogger.conf
[Jan 07 14:09:35]       Ignoring invalid field or type: debug=100 (int)
[Jan 07 14:09:35][mtr0] Creating new meter with protocol d0.
[Jan 07 14:09:35][d0]   pullseq len:5 found
[Jan 07 14:09:35][mtr0] Meter configured. enabled
[Jan 07 14:09:35]       New meter initialized (protocol=d0)
[Jan 07 14:09:35]       Configure channel.
[Jan 07 14:09:35][chn0] New channel initialized (uuid=...52365e protocol=mysmartgrid id=255-255:1.8.1)
[Jan 07 14:09:35]       Have 1 meters.
[Jan 07 14:09:35][main] foreground=1, daemon=0, local=0
[Jan 07 14:09:35]       NOT Daemonize process...
[Jan 07 14:09:35][]     ===> Start meters.
[Jan 07 14:09:35][mtr0] Meter connection established
[Jan 07 14:09:35][mtr0] Meter thread started
[Jan 07 14:09:35][mtr0] meter is opened. Start channels.
[Jan 07 14:09:35][chn0] Logging thread started
[Jan 07 14:09:35][]     Startup done.
[Jan 07 14:09:35][chn0] Start logging thread for mysmartgrid-api. Running as daemon: no
[Jan 07 14:09:35][chn0] ===> Create MySmartGrid-API
[Jan 07 14:09:35][chn0] msg_api_init() http://localhost/middleware.php/sensor/84c148f060e411e3ae1813537b52365e
[Jan 07 14:09:35][mtr0] Number of readers: 32
[Jan 07 14:09:35][mtr0] Config.daemon: 0
[Jan 07 14:09:35][mtr0] Config.local: 0
[Jan 07 14:09:35][d0]   sending pullsequenz send (len:5 is:5).
[Jan 07 14:09:35][chn0] Using MSG-Api.
[Jan 07 14:09:45][d0]   Meter supports baudrate of 9600

[Jan 07 14:09:48][d0]   Parsed reading (OBIS code=0.0.0, value=11111111, unit=)
[Jan 07 14:09:49][d0]   Parsed reading (OBIS code=0.1.0, value=13, unit=)
[Jan 07 14:10:01][d0]   Parsed reading (OBIS code=1.8.1, value=002502.1, unit=kWh)
[Jan 07 14:10:11][d0]   Parsed reading (OBIS code=2.8.1, value=000000.0, unit=kWh)
[Jan 07 14:10:21][d0]   Parsed reading (OBIS code=0.9.1, value=00:26:35, unit=)
[Jan 07 14:10:21][d0]   Parsed reading (OBIS code=0.9.2, value=01-01-03, unit=)
[Jan 07 14:10:22][d0]   Parsed reading (OBIS code=0.2.0, value=B14, unit=)
[Jan 07 14:10:22][d0]   Parsed reading (OBIS code=0.2.1, value=TEST, unit=)
[Jan 07 14:10:23][d0]   Parsed reading (OBIS code=0.2.2, value=999, unit=)
[Jan 07 14:10:23][d0]   Parsed reading (OBIS code=C.2.1, value=00-01-01 00:00, unit=)
[Jan 07 14:10:23][d0]   --> skipped because of parse errors
[Jan 07 14:10:24][d0]   Read package with 9 tuples (vendor=LGZ, baudrate=5, identification=\2ZMD3102400.B14)
[Jan 07 14:10:24][mtr0] Got 9 new readings from meter:
[Jan 07 14:10:24][mtr0] Reading: id=255-255:0.0.0*255/ObisItentifier:255-255:0.0.0*255 value=11111111.00 ts=1389100188.854
[Jan 07 14:10:24][mtr0] Reading: id=255-255:0.1.0*255/ObisItentifier:255-255:0.1.0*255 value=13.00 ts=1389100189.240
[Jan 07 14:10:24][mtr0] Reading: id=255-255:1.8.1*255/ObisItentifier:255-255:1.8.1*255 value=2502.10 ts=1389100201.685
[Jan 07 14:10:24][mtr0] Reading: id=255-255:2.8.1*255/ObisItentifier:255-255:2.8.1*255 value=0.00 ts=1389100211.515
[Jan 07 14:10:24][mtr0] Reading: id=255-255:0.9.1*255/ObisItentifier:255-255:0.9.1*255 value=0.00 ts=1389100221.174
[Jan 07 14:10:24][mtr0] Reading: id=255-255:0.9.2*255/ObisItentifier:255-255:0.9.2*255 value=1.00 ts=1389100221.741
[Jan 07 14:10:24][mtr0] Reading: id=255-255:0.2.0*255/ObisItentifier:255-255:0.2.0*255 value=0.00 ts=1389100222.164
[Jan 07 14:10:24][mtr0] Reading: id=255-255:0.2.1*255/ObisItentifier:255-255:0.2.1*255 value=0.00 ts=1389100222.623
[Jan 07 14:10:24][mtr0] Reading: id=255-255:0.2.2*255/ObisItentifier:255-255:0.2.2*255 value=999.00 ts=1389100223.057
[Jan 07 14:10:24][chn0] Adding reading to queue (value=2502.10 ts=1389100201.685)
[Jan 07 14:10:24][chn0] ==> 1389100201, 2502.100098 - 2502100
[Jan 07 14:10:24][chn0] JSON request body is null. Nothing to send now.
[Jan 07 14:10:24][chn0] Buffer dump (size=0 keep=32): {}
[Jan 07 14:10:24][mtr0] Next reading in 61 seconds

Es scheint als ob der Obis Wert richtig gelesen wird, aber anscheinend kein JSON zur Middleware da is.

Meine Config:
/**
* vzlogger configuration
*
* use proper encoded JSON with _javascript_ comments
*
* take a look at the wiki for detailed information:
* http://wiki.volkszaehler.org/software/controller/vzlogger#configuration
*/

{
"retry" : 30,            /* how long to sleep between failed requests, in seconds */
//"daemon": false,        /* run periodically */
"foreground" : true,        /* run in background */
"verbosity" : 15,        /* between 0 and 15 */
"debug" : 100,
//"log" : "/var/log/vzlogger.log",/* path to logfile, optional */

"local" : {
    "enabled" : false,    /* should we start the local HTTPd for serving live readings? */
    "port" : 8080,        /* the TCP port for the local HTTPd */
    "index" : true,        /* should we provide a index listing of available channels if no UUID was requested? */
    "timeout" : 30,        /* timeout for long polling comet requests, 0 disables comet, in seconds */
    "buffer" : 600        /* how long to buffer readings for the local interface, in seconds */
},

"meters" : [{
        "enabled" : true,       /* disabled meters will be ignored */
        "protocol" : "d0",      /* see 'vzlogger -h' for list of available protocols */
        "device" : "/dev/ttyUSB0",
        "interval" : 61,
        "baudrate" : 300,
        "parity" : "7E1",
        "pullseq" : "2F3F210D0A",
//        "resolution" : 1,
        "channels" : [{
              "protocol" : "mysmartgrid", /* use MySmartgrid as middleware protocol */
              "type" : "sensor",
              "device" :    "52709939-4183-472e-a3bb-78d944da9937",
              "uuid" :      "84c148f0-60e4-11e3-ae18-13537b52365e",
              "secretKey" : "57c56da4-5932-497c-bd80-6cb210c0b891",
//             "interval" : 300, /* */
              "middleware" : "http://localhost/middleware.php",
              /* identifier for measurement: 1-0:1.8.0 */
             //"identifier" : "1.8.1", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */
             "identifier" : "255-255:1.8.1", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */
             //"identifier" : "1-0:1.8.0", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */
              "scaler" : 1000, /* d0 counter is in kWh, so scaling is 1000 */
            }]
    }
]}

gruss
Michael

Am 04.01.14 12:35, schrieb Michael Wulz:

Hallo,

so hab nun das mit dem lokalen Echo getestet.

Laptop mit Putty am Raspi neben dem IR Kopf (im Keller - puh war Kalt...)

So hab den Kopf gegen ein weisses Papier im Abstand von ca 2 cm gehalten, 1 Putty Session zum Senden und eine zum Empfangen .

1tes Putty: # cat /dev/ttyUSB0

2te Putty: # echo "asdf" > /dev/ttyUSB0

wenn ich nun den echo Befehl absetze seh ich schön im 1ten Putty die Daten vom cat kommend. Wenn ich den Kopf weiter enferne
gehts nicht mehr (ca 15 cm) näher dran gehts dann wieder.

Soo voller Euphorie hatte ich nun den Kopf wieder auf den Zähler gegeben und die Trigger-Sequenz mit Echo gesendet
# echo $'\x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB0

Anschließend kam eine Antwort im 1ten Putty Fenster vom Zähler:

/LGZ5\2ZMD3102400.B14

F.F(020000000)
0.0.0(11111111)

usw....

Das ganze hab ich jetzt drei bis vier mal gemacht - geht problemlos.

Cool dachte ich - starten wir dann mal den vzlogger mit der Config:
root@raspberrypi:/etc# cat vzlogger.conf
/**
* vzlogger configuration
*
* use proper encoded JSON with _javascript_ comments
*
* take a look at the wiki for detailed information:
* http://wiki.volkszaehler.org/software/controller/vzlogger#configuration
*/

{
"retry" : 30,            /* how long to sleep between failed requests, in seconds */
//"daemon": false,        /* run periodically */
"foreground" : true,        /* run in background */
"verbosity" : 15,        /* between 0 and 15 */
"debug" : 100,
//"log" : "/var/log/vzlogger.log",/* path to logfile, optional */

"local" : {
    "enabled" : false,    /* should we start the local HTTPd for serving live readings? */
    "port" : 8080,        /* the TCP port for the local HTTPd */
    "index" : true,        /* should we provide a index listing of available channels if no UUID was requested? */
    "timeout" : 30,        /* timeout for long polling comet requests, 0 disables comet, in seconds */
    "buffer" : 600        /* how long to buffer readings for the local interface, in seconds */
},

"meters" : [{
        "enabled" : true,       /* disabled meters will be ignored */
        "protocol" : "d0",      /* see 'vzlogger -h' for list of available protocols */
        "device" : "/dev/ttyUSB0",
//        "interval" : 61,
        "baudrate" : 300,
        "parity" : "7E1",
//        "pullseq" : "2F3F210D0A",
//        "resolution" : 1,
        "channels" : [{
              "protocol" : "mysmartgrid", /* use MySmartgrid as middleware protocol */
              "type" : "sensor",
              "device" :    "52709939-4183-472e-a3bb-78d944da9937",
              "uuid" :      "84c148f0-60e4-11e3-ae18-13537b52365e",
              "secretKey" : "57c56da4-5932-497c-bd80-6cb210c0b891",
//             "interval" : 300, /* */
              "middleware" : "https://api.mysmartgrid.de:8443",
              /* identifier for measurement: 1-0:1.8.0 */
             "identifier" : "1.8.1", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */
             //"identifier" : "255-255:1.8.1", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */
             //"identifier" : "1-0:1.8.0", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */
              "scaler" : 1000, /* d0 counter is in kWh, so scaling is 1000 */
            }]
    }
]}

dann kam folgender Output:
root@raspberrypi:~# vzlogger -c /etc/vzlogger.conf
[Jan 04 12:21:51]       Ignoring invalid field or type: debug=100 (int)
[Jan 04 12:21:51][mtr0] Creating new meter with protocol d0.
[Jan 04 12:21:51][mtr0] Meter configured. enabled
[Jan 04 12:21:51]       New meter initialized (protocol=d0)
[Jan 04 12:21:51]       Configure channel.
[Jan 04 12:21:51][chn0] New channel initialized (uuid=...52365e protocol=mysmart                              grid id=1.8.1)
[Jan 04 12:21:51]       Have 1 meters.
[Jan 04 12:21:51][main] foreground=1, daemon=0, local=0
[Jan 04 12:21:51]       NOT Daemonize process...
[Jan 04 12:21:51][]     ===> Start meters.
[Jan 04 12:21:51][mtr0] Meter connection established
[Jan 04 12:21:51][mtr0] Meter thread started
[Jan 04 12:21:51][mtr0] meter is opened. Start channels.
[Jan 04 12:21:51][chn0] Logging thread started
[Jan 04 12:21:51][]     Startup done.
[Jan 04 12:21:51][chn0] Start logging thread for mysmartgrid-api. Running as dae                              mon: no
[Jan 04 12:21:51][chn0] ===> Create MySmartGrid-API
[Jan 04 12:21:51][chn0] msg_api_init() https://api.mysmartgrid.de:8443/sensor/84                              c148f060e411e3ae1813537b52365e
[Jan 04 12:21:51][mtr0] Number of readers: 32
[Jan 04 12:21:51][mtr0] Config.daemon: 0
[Jan 04 12:21:51][mtr0] Config.local: 0
[Jan 04 12:21:51][chn0] Using MSG-Api.

HIER HAB ICH DEN TRIGGER im 2ten Putty gestartet...

[Jan 04 12:22:02][d0]   nothing received for more than 10 seconds
[Jan 04 12:22:02][d0]   Something unexpected happened: read:377!
[Jan 04 12:22:02][mtr0] Got 0 new readings from meter:
[Jan 04 12:22:02][chn0] JSON request body is null. Nothing to send now.
[Jan 04 12:22:02][chn0] Buffer dump (size=0 keep=32): {}
[Jan 04 12:22:13][d0]   nothing received for more than 10 seconds
[Jan 04 12:22:13][d0]   Something unexpected happened: read:377!
[Jan 04 12:22:13][mtr0] Got 0 new readings from meter:
[Jan 04 12:22:13][chn0] JSON request body is null. Nothing to send now.
[Jan 04 12:22:13][chn0] Buffer dump (size=0 keep=32): {}
[Jan 04 12:22:24][d0]   nothing received for more than 10 seconds
[Jan 04 12:22:24][d0]   Something unexpected happened: read:377!
[Jan 04 12:22:24][mtr0] Got 0 new readings from meter:
[Jan 04 12:22:24][chn0] JSON request body is null. Nothing to send now.
[Jan 04 12:22:24][chn0] Buffer dump (size=0 keep=32): {}
[Jan 04 12:22:35][d0]   nothing received for more than 10 seconds
[Jan 04 12:22:35][d0]   Something unexpected happened: read:377!
[Jan 04 12:22:35][mtr0] Got 0 new readings from meter:
[Jan 04 12:22:35][chn0] JSON request body is null. Nothing to send now.
[Jan 04 12:22:35][chn0] Buffer dump (size=0 keep=32): {}
[Jan 04 12:22:46][d0]   nothing received for more than 10 seconds
[Jan 04 12:22:46][d0]   Something unexpected happened: read:377!
[Jan 04 12:22:46][mtr0] Got 0 new readings from meter:
[Jan 04 12:22:46][chn0] JSON request body is null. Nothing to send now.
[Jan 04 12:22:46][chn0] Buffer dump (size=0 keep=32): {}
[Jan 04 12:22:57][d0]   nothing received for more than 10 seconds
[Jan 04 12:22:57][d0]   Something unexpected happened: read:377!
[Jan 04 12:22:57][mtr0] Got 0 new readings from meter:
[Jan 04 12:22:57][chn0] JSON request body is null. Nothing to send now.
[Jan 04 12:22:57][chn0] Buffer dump (size=0 keep=32): {}
^C[Jan 04 12:22:57]       terminating on signal 2.
[Jan 04 12:22:57]       Closing connections to terminate
*** glibc detected *** vzlogger: free(): corrupted unsorted chunks: 0x00b6ac28 ***
Aborted

komisch - lt. VZLogger kommt da nix an.

Habe dann nochmal das mit cat getestet wie vor dem VZlogger Test und jetzt kommen keine Daten mehr an.

Auch der lokale Echo Test mit dem weissen Blatt geht nicht mehr.

stty -F /dev/ttyUSB0 sagt mir immer noch das gleiche wie vor dem vzlogger Test.

Ich verstehe das ganze nicht, irgendwas macht der vzlogger mit der /dev/ttyUSB0 sodass entweder nix mehr
raus oder rein geht?

Versteht das einer von euch? Ich langsam nichtmehr....

Am 2. Januar 2014 17:53 schrieb <[email protected]>:

Hallo Michael,

ich habe das gleiche Problem, ich habe einen Siemens TD3511 und bin leider noch nicht weiter……
Unter Windows funktioniert er unter linux am Raspi nicht….

Hast du schon mal versucht, mit einem Terminal Programm am Raspi Zeichen zu senden?
Echo aufdrehen, ein weisses Blatt Papier vor den Kopf halten, dann solltest du die Antwort direkt über die Empfangsdiode zurückbekommen.
So lässt sich zumindest mal herausfinden, ob es am Senden oder am Empfangen scheitert….

Grüße,
Martin

On 02.01.2014, at 17:47, Michael Wulz <[email protected]> wrote:

> Hallo Leute,
>
> ich hab eine Frage bezüglich dem Lesekopf von UDO und dem Raspi.
>
> Ich nutze den USB Kopf mit einer Platine, der Kopf funktioniert unter Windows mit hterm einwandfrei (300 baud, 7n1, parity even)
> Wenn ich die Triggerzeichen sende antwortet der Zähler mit der Seriennummer und den Werten.
> Mein Zähler ist ein Landis&Gyr, arbeitet aber wie dieser: http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511
>
> Nun zu meinem Problem, wenn ich den Kopf am Raspi anstecke dann wird dieser korrekt erkannt:
> [232113.932187] usb 1-1.3: new full-speed USB device number 6 using dwc_otg
> [232114.041152] usb 1-1.3: New USB device found, idVendor=10c4, idProduct=ea60
> [232114.041188] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [232114.041208] usb 1-1.3: Product: CP2104 USB to UART Bridge Controller
> [232114.041224] usb 1-1.3: Manufacturer: Silicon Labs
> [232114.041239] usb 1-1.3: SerialNumber: 0061EA6B
> [232114.054462] cp210x 1-1.3:1.0: cp210x converter detected
> [232114.132234] usb 1-1.3: reset full-speed USB device number 6 using dwc_otg
> [232114.236155] usb 1-1.3: cp210x converter now attached to ttyUSB0
>
> Er hat das Devicefile /dev/ttyUSB0 bekommen.
>
> Ich setze dann mit stty die Schnittstellenparameter:
> stty -F /dev/ttyUSB0 300 parenb -parodd cs7 -cstopb raw -echo
>
> und kontrolle:
> root@raspberrypi:~# stty -F /dev/ttyUSB0
> speed 300 baud; line = 0;
> min = 1; time = 0;
> -brkint -icrnl -imaxbel
> -opost
> -isig -icanon -echo
>
> sollte also passen.
>
> wenn ich nun einen Trigger absende:
> root@raspberrypi:~# echo $'\x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB0
> und gleich drauf lausche:
> root@raspberrypi:~# cat /dev/ttyUSB0
>
> totenstille...
>
> Ich hab auch schon in einer anderen SSH parallell ein cat laufen gehabt und dann getriggert. Nichts!
>
> Hatte jemand von euch auch das Problem? Ich mache viel mit Linux und hab schon alles mögliche mit stty versucht
> jedoch ohne Erfolg.
>
> Tests mit dem Programm:
> root@raspberrypi:/data/vz_test# cat test.sh
> #!/usr/bin/perl
>
> #
> # (m)ein Stromzähler mit IR-Schnittstelle blubbert nach einem "Anforderung-
> # telegramm" Daten raus. Das Telegramm ist mit 300 Baud, 7 Bit, 1 Stoppbit
> # und gerader Parität zu senden. Das ist der Initialmodus von Geräten,
> # die das Protokoll IEC 62056-21 implementieren.
> #
> # Autor: Andreas Schulze
> # Bugfix: Eric Schanze
> # Datum: 20120302
> #
>
> my $PORT='/dev/ttyUSB0';
> my $anforderungstelegramm = "\n/?!\r\n";
>
> use warnings;
> use strict;
> use utf8;
> use Device::SerialPort;
>
> my $tty = new Device::SerialPort($PORT) || die "can't open $PORT: $!";
> $tty->baudrate(300) || die 'fail setting baudrate';
> $tty->databits(7) || die 'fail setting databits';
> $tty->stopbits(1) || die 'fail setting stopbits';
> $tty->parity("even") || die 'fail setting parity';
> $tty->write_settings || die 'fail write settings';
> $tty->debug(1);
>
> my $num_out = $tty->write($anforderungstelegramm);
> die "write failed\n" unless ($num_out);
> die "write inclomplete\n" unless ($num_out == length($anforderungstelegramm));
> print "$num_out Bytes written\n";
>
> $tty->close || die "can't close $PORT: $!";
>
>
> sind ebenfalls ohne Erfolg. Es kommt kein Output vom /dev/ttyUSB0.
> Ich hatte es einmal geschafft nach einem Reboot den Zähler auszulesen, jedoch beim zweiten Trigger war dann schonwieder aus.
>
> Meine Vermutung, dass der USB nicht genügend Power liefert? Hat jemand von euch auch am USB Probleme?
> Es steckt sonst nix am USB! Am Raspi steckt noch die Erweiterung von UDO mit den S0 Eingängen (an der GPIO Pinleiste)
> diese: http://wiki.volkszaehler.org/hardware/controllers/raspberry_pi_erweiterung_rev1
>
> Die Erweiterung funktioniert übrigens mit s0vz einwandfrei!
>
> Hier die Daten vom Raspi:
> root@raspberrypi:~# uname -a
> Linux raspberrypi 3.10.25+ #616 PREEMPT Mon Dec 23 18:13:02 GMT 2013 armv6l GNU/Linux
>
> root@raspberrypi:~# lsmod
> Module Size Used by
> snd_bcm2835 16165 0
> snd_soc_bcm2708_i2s 5474 0
> regmap_mmio 2806 1 snd_soc_bcm2708_i2s
> snd_soc_core 131268 1 snd_soc_bcm2708_i2s
> snd_compress 8076 1 snd_soc_core
> cp210x 8243 0
> regmap_i2c 1645 1 snd_soc_core
> regmap_spi 1897 1 snd_soc_core
> snd_pcm 81593 2 snd_bcm2835,snd_soc_core
> snd_page_alloc 5156 1 snd_pcm
> snd_seq 53769 0
> snd_seq_device 6473 1 snd_seq
> snd_timer 20133 2 snd_pcm,snd_seq
> usbserial 26929 1 cp210x
> leds_gpio 2059 0
> led_class 3688 1 leds_gpio
> snd 61291 7 snd_bcm2835,snd_soc_core,snd_timer,snd_pcm,snd_seq,snd_seq_device,snd_compress
>
> Das Netzteil am Raspi hat +5V und 3A - liefert also auch genügen Saft.
>
> besten Dank im Vorraus
> Michael
>

Re: [vz-users] Udo Lesekopf und Raspberry PI

Antwort per Email an