<div dir="ltr"><div><div><div><div><div><div>Hallo,<br><br>so hab nun das mit dem lokalen Echo getestet.<br><br></div>Laptop mit Putty am Raspi neben dem IR Kopf (im Keller - puh war Kalt...)<br><br></div>So hab den Kopf gegen ein weisses Papier im Abstand von ca 2 cm gehalten, 1 Putty Session zum Senden und eine zum Empfangen .<br>
<br></div>1tes Putty: # cat /dev/ttyUSB0<br></div>2te Putty: # echo "asdf" > /dev/ttyUSB0<br><br></div>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<br>
gehts nicht mehr (ca 15 cm) näher dran gehts dann wieder.<br><br></div><div>Soo voller Euphorie hatte ich nun den Kopf wieder auf den Zähler gegeben und die Trigger-Sequenz mit Echo gesendet<br># echo $'\x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB0<br>
<br></div><div>Anschließend kam eine Antwort im 1ten Putty Fenster vom Zähler:<br></div><div>/LGZ5\2ZMD3102400.B14<br></div><div>F.F(020000000)<br>0.0.0(11111111)<br></div><div>usw....<br><br></div><div>Das ganze hab ich jetzt drei bis vier mal gemacht - geht problemlos.<br>
</div><div><br></div><div>Cool dachte ich - starten wir dann mal den vzlogger mit der Config:<br>root@raspberrypi:/etc# cat vzlogger.conf<br>/**<br> * vzlogger configuration<br> * <br> * use proper encoded JSON with javascript comments<br>
*<br> * take a look at the wiki for detailed information:<br> * <a href="http://wiki.volkszaehler.org/software/controller/vzlogger#configuration">http://wiki.volkszaehler.org/software/controller/vzlogger#configuration</a><br>
*/<br><br>{<br>"retry" : 30, /* how long to sleep between failed requests, in seconds */<br>//"daemon": false, /* run periodically */<br>"foreground" : true, /* run in background */<br>
"verbosity" : 15, /* between 0 and 15 */<br>"debug" : 100,<br>//"log" : "/var/log/vzlogger.log",/* path to logfile, optional */<br><br>"local" : {<br> "enabled" : false, /* should we start the local HTTPd for serving live readings? */<br>
"port" : 8080, /* the TCP port for the local HTTPd */<br> "index" : true, /* should we provide a index listing of available channels if no UUID was requested? */<br> "timeout" : 30, /* timeout for long polling comet requests, 0 disables comet, in seconds */<br>
"buffer" : 600 /* how long to buffer readings for the local interface, in seconds */<br>},<br><br>"meters" : [{<br> "enabled" : true, /* disabled meters will be ignored */<br>
"protocol" : "d0", /* see 'vzlogger -h' for list of available protocols */<br> "device" : "/dev/ttyUSB0",<br>// "interval" : 61,<br> "baudrate" : 300,<br>
"parity" : "7E1",<br>// "pullseq" : "2F3F210D0A",<br>// "resolution" : 1,<br> "channels" : [{<br> "protocol" : "mysmartgrid", /* use MySmartgrid as middleware protocol */<br>
"type" : "sensor",<br> "device" : "52709939-4183-472e-a3bb-78d944da9937",<br> "uuid" : "84c148f0-60e4-11e3-ae18-13537b52365e",<br>
"secretKey" : "57c56da4-5932-497c-bd80-6cb210c0b891",<br> // "interval" : 300, /* */<br> "middleware" : "<a href="https://api.mysmartgrid.de:8443">https://api.mysmartgrid.de:8443</a>",<br>
/* identifier for measurement: 1-0:1.8.0 */<br> "identifier" : "1.8.1", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */<br> //"identifier" : "255-255:1.8.1", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */<br>
//"identifier" : "1-0:1.8.0", /* see 'vzlogger -v20' for an output with all available identifiers/OBIS ids */<br> "scaler" : 1000, /* d0 counter is in kWh, so scaling is 1000 */<br>
}]<br> }<br>]}<br><br></div><div>dann kam folgender Output:<br>root@raspberrypi:~# vzlogger -c /etc/vzlogger.conf<br>[Jan 04 12:21:51] Ignoring invalid field or type: debug=100 (int)<br>[Jan 04 12:21:51][mtr0] Creating new meter with protocol d0.<br>
[Jan 04 12:21:51][mtr0] Meter configured. enabled<br>[Jan 04 12:21:51] New meter initialized (protocol=d0)<br>[Jan 04 12:21:51] Configure channel.<br>[Jan 04 12:21:51][chn0] New channel initialized (uuid=...52365e protocol=mysmart grid id=1.8.1)<br>
[Jan 04 12:21:51] Have 1 meters.<br>[Jan 04 12:21:51][main] foreground=1, daemon=0, local=0<br>[Jan 04 12:21:51] NOT Daemonize process...<br>[Jan 04 12:21:51][] ===> Start meters.<br>[Jan 04 12:21:51][mtr0] Meter connection established<br>
[Jan 04 12:21:51][mtr0] Meter thread started<br>[Jan 04 12:21:51][mtr0] meter is opened. Start channels.<br>[Jan 04 12:21:51][chn0] Logging thread started<br>[Jan 04 12:21:51][] Startup done.<br>[Jan 04 12:21:51][chn0] Start logging thread for mysmartgrid-api. Running as dae mon: no<br>
[Jan 04 12:21:51][chn0] ===> Create MySmartGrid-API<br>[Jan 04 12:21:51][chn0] msg_api_init() <a href="https://api.mysmartgrid.de:8443/sensor/84">https://api.mysmartgrid.de:8443/sensor/84</a> c148f060e411e3ae1813537b52365e<br>
[Jan 04 12:21:51][mtr0] Number of readers: 32<br>[Jan 04 12:21:51][mtr0] Config.daemon: 0<br>[Jan 04 12:21:51][mtr0] Config.local: 0<br>[Jan 04 12:21:51][chn0] Using MSG-Api.<br><br></div><div>HIER HAB ICH DEN TRIGGER im 2ten Putty gestartet...<br>
</div><div><br>[Jan 04 12:22:02][d0] nothing received for more than 10 seconds<br>[Jan 04 12:22:02][d0] Something unexpected happened: read:377!<br>[Jan 04 12:22:02][mtr0] Got 0 new readings from meter:<br>[Jan 04 12:22:02][chn0] JSON request body is null. Nothing to send now.<br>
[Jan 04 12:22:02][chn0] Buffer dump (size=0 keep=32): {}<br>[Jan 04 12:22:13][d0] nothing received for more than 10 seconds<br>[Jan 04 12:22:13][d0] Something unexpected happened: read:377!<br>[Jan 04 12:22:13][mtr0] Got 0 new readings from meter:<br>
[Jan 04 12:22:13][chn0] JSON request body is null. Nothing to send now.<br>[Jan 04 12:22:13][chn0] Buffer dump (size=0 keep=32): {}<br>[Jan 04 12:22:24][d0] nothing received for more than 10 seconds<br>[Jan 04 12:22:24][d0] Something unexpected happened: read:377!<br>
[Jan 04 12:22:24][mtr0] Got 0 new readings from meter:<br>[Jan 04 12:22:24][chn0] JSON request body is null. Nothing to send now.<br>[Jan 04 12:22:24][chn0] Buffer dump (size=0 keep=32): {}<br>[Jan 04 12:22:35][d0] nothing received for more than 10 seconds<br>
[Jan 04 12:22:35][d0] Something unexpected happened: read:377!<br>[Jan 04 12:22:35][mtr0] Got 0 new readings from meter:<br>[Jan 04 12:22:35][chn0] JSON request body is null. Nothing to send now.<br>[Jan 04 12:22:35][chn0] Buffer dump (size=0 keep=32): {}<br>
[Jan 04 12:22:46][d0] nothing received for more than 10 seconds<br>[Jan 04 12:22:46][d0] Something unexpected happened: read:377!<br>[Jan 04 12:22:46][mtr0] Got 0 new readings from meter:<br>[Jan 04 12:22:46][chn0] JSON request body is null. Nothing to send now.<br>
[Jan 04 12:22:46][chn0] Buffer dump (size=0 keep=32): {}<br>[Jan 04 12:22:57][d0] nothing received for more than 10 seconds<br>[Jan 04 12:22:57][d0] Something unexpected happened: read:377!<br>[Jan 04 12:22:57][mtr0] Got 0 new readings from meter:<br>
[Jan 04 12:22:57][chn0] JSON request body is null. Nothing to send now.<br>[Jan 04 12:22:57][chn0] Buffer dump (size=0 keep=32): {}<br>^C[Jan 04 12:22:57] terminating on signal 2.<br>[Jan 04 12:22:57] Closing connections to terminate<br>
*** glibc detected *** vzlogger: free(): corrupted unsorted chunks: 0x00b6ac28 ***<br>Aborted<br><br></div><div>komisch - lt. VZLogger kommt da nix an.<br></div><div>Habe dann nochmal das mit cat getestet wie vor dem VZlogger Test und jetzt kommen keine Daten mehr an.<br>
</div><div>Auch der lokale Echo Test mit dem weissen Blatt geht nicht mehr.<br><br></div><div>stty -F /dev/ttyUSB0 sagt mir immer noch das gleiche wie vor dem vzlogger Test.<br><br></div><div>Ich verstehe das ganze nicht, irgendwas macht der vzlogger mit der /dev/ttyUSB0 sodass entweder nix mehr<br>
raus oder rein geht?<br><br>Versteht das einer von euch? Ich langsam nichtmehr....<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Am 2. Januar 2014 17:53 schrieb <span dir="ltr"><<a href="mailto:joisey04@mac.com" target="_blank">joisey04@mac.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hallo Michael,<br>
<br>
ich habe das gleiche Problem, ich habe einen Siemens TD3511 und bin leider noch nicht weiter……<br>
Unter Windows funktioniert er unter linux am Raspi nicht….<br>
<br>
Hast du schon mal versucht, mit einem Terminal Programm am Raspi Zeichen zu senden?<br>
Echo aufdrehen, ein weisses Blatt Papier vor den Kopf halten, dann solltest du die Antwort direkt über die Empfangsdiode zurückbekommen.<br>
So lässt sich zumindest mal herausfinden, ob es am Senden oder am Empfangen scheitert….<br>
<br>
Grüße,<br>
Martin<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 02.01.2014, at 17:47, Michael Wulz <<a href="mailto:michael.wulz@gmail.com">michael.wulz@gmail.com</a>> wrote:<br>
<br>
> Hallo Leute,<br>
><br>
> ich hab eine Frage bezüglich dem Lesekopf von UDO und dem Raspi.<br>
><br>
> Ich nutze den USB Kopf mit einer Platine, der Kopf funktioniert unter Windows mit hterm einwandfrei (300 baud, 7n1, parity even)<br>
> Wenn ich die Triggerzeichen sende antwortet der Zähler mit der Seriennummer und den Werten.<br>
> Mein Zähler ist ein Landis&Gyr, arbeitet aber wie dieser: <a href="http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511" target="_blank">http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511</a><br>
><br>
> Nun zu meinem Problem, wenn ich den Kopf am Raspi anstecke dann wird dieser korrekt erkannt:<br>
> [232113.932187] usb 1-1.3: new full-speed USB device number 6 using dwc_otg<br>
> [232114.041152] usb 1-1.3: New USB device found, idVendor=10c4, idProduct=ea60<br>
> [232114.041188] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br>
> [232114.041208] usb 1-1.3: Product: CP2104 USB to UART Bridge Controller<br>
> [232114.041224] usb 1-1.3: Manufacturer: Silicon Labs<br>
> [232114.041239] usb 1-1.3: SerialNumber: 0061EA6B<br>
> [232114.054462] cp210x 1-1.3:1.0: cp210x converter detected<br>
> [232114.132234] usb 1-1.3: reset full-speed USB device number 6 using dwc_otg<br>
> [232114.236155] usb 1-1.3: cp210x converter now attached to ttyUSB0<br>
><br>
> Er hat das Devicefile /dev/ttyUSB0 bekommen.<br>
><br>
> Ich setze dann mit stty die Schnittstellenparameter:<br>
> stty -F /dev/ttyUSB0 300 parenb -parodd cs7 -cstopb raw -echo<br>
><br>
> und kontrolle:<br>
> root@raspberrypi:~# stty -F /dev/ttyUSB0<br>
> speed 300 baud; line = 0;<br>
> min = 1; time = 0;<br>
> -brkint -icrnl -imaxbel<br>
> -opost<br>
> -isig -icanon -echo<br>
><br>
> sollte also passen.<br>
><br>
> wenn ich nun einen Trigger absende:<br>
> root@raspberrypi:~# echo $'\x2f\x3f\x21\x0d\x0a' > /dev/ttyUSB0<br>
> und gleich drauf lausche:<br>
> root@raspberrypi:~# cat /dev/ttyUSB0<br>
><br>
> totenstille...<br>
><br>
> Ich hab auch schon in einer anderen SSH parallell ein cat laufen gehabt und dann getriggert. Nichts!<br>
><br>
> Hatte jemand von euch auch das Problem? Ich mache viel mit Linux und hab schon alles mögliche mit stty versucht<br>
> jedoch ohne Erfolg.<br>
><br>
> Tests mit dem Programm:<br>
> root@raspberrypi:/data/vz_test# cat test.sh<br>
> #!/usr/bin/perl<br>
><br>
> #<br>
> # (m)ein Stromzähler mit IR-Schnittstelle blubbert nach einem "Anforderung-<br>
> # telegramm" Daten raus. Das Telegramm ist mit 300 Baud, 7 Bit, 1 Stoppbit<br>
> # und gerader Parität zu senden. Das ist der Initialmodus von Geräten,<br>
> # die das Protokoll IEC 62056-21 implementieren.<br>
> #<br>
> # Autor: Andreas Schulze<br>
> # Bugfix: Eric Schanze<br>
> # Datum: 20120302<br>
> #<br>
><br>
> my $PORT='/dev/ttyUSB0';<br>
> my $anforderungstelegramm = "\n/?!\r\n";<br>
><br>
> use warnings;<br>
> use strict;<br>
> use utf8;<br>
> use Device::SerialPort;<br>
><br>
> my $tty = new Device::SerialPort($PORT) || die "can't open $PORT: $!";<br>
> $tty->baudrate(300) || die 'fail setting baudrate';<br>
> $tty->databits(7) || die 'fail setting databits';<br>
> $tty->stopbits(1) || die 'fail setting stopbits';<br>
> $tty->parity("even") || die 'fail setting parity';<br>
> $tty->write_settings || die 'fail write settings';<br>
> $tty->debug(1);<br>
><br>
> my $num_out = $tty->write($anforderungstelegramm);<br>
> die "write failed\n" unless ($num_out);<br>
> die "write inclomplete\n" unless ($num_out == length($anforderungstelegramm));<br>
> print "$num_out Bytes written\n";<br>
><br>
> $tty->close || die "can't close $PORT: $!";<br>
><br>
><br>
> sind ebenfalls ohne Erfolg. Es kommt kein Output vom /dev/ttyUSB0.<br>
> Ich hatte es einmal geschafft nach einem Reboot den Zähler auszulesen, jedoch beim zweiten Trigger war dann schonwieder aus.<br>
><br>
> Meine Vermutung, dass der USB nicht genügend Power liefert? Hat jemand von euch auch am USB Probleme?<br>
> Es steckt sonst nix am USB! Am Raspi steckt noch die Erweiterung von UDO mit den S0 Eingängen (an der GPIO Pinleiste)<br>
> diese: <a href="http://wiki.volkszaehler.org/hardware/controllers/raspberry_pi_erweiterung_rev1" target="_blank">http://wiki.volkszaehler.org/hardware/controllers/raspberry_pi_erweiterung_rev1</a><br>
><br>
> Die Erweiterung funktioniert übrigens mit s0vz einwandfrei!<br>
><br>
> Hier die Daten vom Raspi:<br>
> root@raspberrypi:~# uname -a<br>
> Linux raspberrypi 3.10.25+ #616 PREEMPT Mon Dec 23 18:13:02 GMT 2013 armv6l GNU/Linux<br>
><br>
> root@raspberrypi:~# lsmod<br>
> Module Size Used by<br>
> snd_bcm2835 16165 0<br>
> snd_soc_bcm2708_i2s 5474 0<br>
> regmap_mmio 2806 1 snd_soc_bcm2708_i2s<br>
> snd_soc_core 131268 1 snd_soc_bcm2708_i2s<br>
> snd_compress 8076 1 snd_soc_core<br>
> cp210x 8243 0<br>
> regmap_i2c 1645 1 snd_soc_core<br>
> regmap_spi 1897 1 snd_soc_core<br>
> snd_pcm 81593 2 snd_bcm2835,snd_soc_core<br>
> snd_page_alloc 5156 1 snd_pcm<br>
> snd_seq 53769 0<br>
> snd_seq_device 6473 1 snd_seq<br>
> snd_timer 20133 2 snd_pcm,snd_seq<br>
> usbserial 26929 1 cp210x<br>
> leds_gpio 2059 0<br>
> led_class 3688 1 leds_gpio<br>
> snd 61291 7 snd_bcm2835,snd_soc_core,snd_timer,snd_pcm,snd_seq,snd_seq_device,snd_compress<br>
><br>
> Das Netzteil am Raspi hat +5V und 3A - liefert also auch genügen Saft.<br>
><br>
> besten Dank im Vorraus<br>
> Michael<br>
><br>
<br>
</div></div></blockquote></div><br></div>