Re: [vz-users] Erkennung der libSML-Version

[Matthias Behr]

ich versuche die Tests morgen zu fixen oder wenigstens nur den einen 
problematischen zu deaktivieren.

> Am 12.12.2019 um 20:14 schrieb Marc Haber 
> :
> 
> On Thu, Dec 12, 2019 at 04:08:18PM +0100, Daniel Lauckner wrote:
>> am Mittwoch, 11. Dezember 2019 um 13:50 hat Marc Haber geschrieben:
>>> [2] debian/rules ergänzen um:
>> 
>> Ideal wärs du machst selbst ein PullRequest über git.
> 
> Ich finde das Abschalten der Testsuite ein Signal in die falsche
> Richtung. Schön wäre es, sie würde nicht failen.
> 
> Grüße
> Marc
> 
> -- 
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Gruß

Matthias

Re: [vz-users] plötzlicher logging stop

[Matthias Behr]

Hallo,

Dec  6 22:57:34 raspberrypi kernel: [391792.052069] cp210x ttyUSB0: cp210x 
converter now disconnected from ttyUSB0
Dec  6 22:57:34 raspberrypi kernel: [391792.052214] cp210x 1-1.4:1.0: device 
disconnected
Dec  6 22:57:34 raspberrypi systemd[1]: vzlogger.service: Main process exited, 
code=killed, status=11/SEGV

ja, das schaut nicht gut aus. Bitte dafür ein github Issue anlegen.

Das Hauptproblem ist der „verschwindene“ ttyUSB0 (falls er genutzt wird, wovon 
ich mal ausgehe). Dann fehlt vermutlich ein Error-Handling (das sollten wir 
hinzufügen).

Kannst du das reproduzieren, indem du während normalen Betriebs den USB Adapter 
abziehst?

> Am 09.12.2019 um 10:16 schrieb Andreas Goetz :
> 
> Moin.
> 
> Also erstmal soll das natürlich nicht passieren. Wenn es dennoch vorkommt 
> kann der Service so konfiguriert werden, dass er automatisch neu startet. 
> 
> Im Log von Rene ist zu sehen dass es anscheinend irgendwelche Probleme mit 
> einem USB gerät gibt- wird das vom Logger verwendet? Es könnte auch lohnen 
> mal bei Raspbian zu forschen ob/wer ähnliche Probleme mit diesem USB Gerät 
> hat. 
> 
> Auf den ersten Blick würde ich vermuten dass Vzlogger mit der Situation eines 
> sich “abmeldenden” USB Gerätes nicht gut klar kommt. Da das aber nicht der 
> Root cause is aus meiner Sicht erstmal kein Handlungsbedarf.
> 
> Viele Grüße, Andreas
> 
> 
>> On 9. Dec 2019, at 10:11, heine.tho...@online.de 
>>  wrote:
>> 
>> Hallo,
>> 
>> sehr witzig. Meiner stieg heute morgen um 3:45 Uhr auch aus. Siehe Bild
>> Da die Verbosity auf 0 war, keine Einträge im VZ-log...
>> Bei mir ist die Datebank auf dem RPI.
>> 
>> Verstehen tue ich das ganze auch nicht.
>> Nach einem Neustart lief alles wieder.
>> Ich stelle nun mal das verbosity auf 1
>> 
>> 
>> Gruß
>> Thomas
>> 
>> Am 09.12.2019 um 08:34 schrieb Andreas Goetz:
>>> Dein Screenshot ist unleserlerlich. Läuft der Daemon Prozess nich wenn das 
>>> log stoppt?
>>> 
 Am 09.12.2019 um 07:14 schrieb René W.  
 :
 
 
 Guten Morgen,
  
 mein vzlogger hat nun zum zweiten mal getoppt zu loggen. Es läuft über ein 
 RPi3 mit externer Synology Datenbank. Nach einem reboot oder manuellen 
 Start des Dienstes läuft der Log weiter. Im frontend sind aber Lücken zu 
 sehen.
 Da der verbose debug recht niedrig ist, habe ich hier eine log ausm 
 /var/log/sys.log
 
  
 Ich werde da nicht ganz schlau daraus und was ich als nächstes machen 
 sollte. Könnt ihr mir helfen?
  
 Gruß René
>> 
>> 
> 

Gruß

Matthias

Re: [vz-users] Mehrere vzlogger-Instanzen auf einem System?

[Matthias Behr]

kannst du mal statt
vzlogger -c /etc/…

ein

vzlogger —config /etc/…

machen
(also config/etc... )

die komische Ausgabe bei ps ist echt unverständlich.

> Am 26.11.2019 um 21:35 schrieb Winfried Peters :
> 
> Ok, viele Fragen. Ich benötige zwei Instanzen als Workaround für ein Problem, 
> das ich schon mal in einer Anfrage Anfang November beschrieben habe:
> "Mein vzlogger loggt S0-Impulsdaten von Gas- und Wasser-Zähler und sml-Daten 
> vom Stromzähler. Ich puffere die Daten für eine Stunde in HTTPd, um 
> gelegentliche Ausfälle meiner Hostanwendung für die Datenauswertung zu 
> kompensieren. Das ist für die Impulsdaten besonders wichtig. Der 
> buffer-Parameter gilt für die gesamte vzlogger-Instanz. Meine PV-Anlage 
> liefert bei Dunkelheit keine Energie. Ich bekomme sekündlich einen Datensatz 
> in den Puffer gestellt, bei dem sich in diesem Fall nichts ändert als der 
> Timestamp. Das macht dann 3.600 Tupels für diesen Channel. Der 
> HTTPd-JSON-String wird periodisch von meinem Hostprogramm abgefragt. Die 
> Länge des Puffers wird bei mehreren sml-Werten sehr unhandlich und mein 
> kleiner Beaglebone-Rechner kommt dann schon ins Schwitzen. Ein 
> funktionierender Parameter "duplicate" würde die Verarbeitung wesentlich 
> effizienter machen.
> Ein Workaround wäre wahrscheinlich eine zweite vzlogger-Instanz nur für 
> sml-Zählerdaten (mit "buffer": -1), die die Daten über einen anderen 
> HTTPd-Port zur Verfügung stellt. Es ist allerdings nicht so elegant, als wenn 
> alles in einer Instanz/Config erledigt werden kann."
> 
> Inzwischen ist mein Feature-Request, "duplicate" auch für das sml-Protokoll 
> zu implementieren, als Enhancement akzeptiert worden. Solange die Umsetzung 
> noch nicht erfolgt ist, wollte ich jetzt den Workaround mit zwei 
> vzlogger-Instanzen auf einem System umsetzen, woran ich scheitere.
> 
> Hier weitere Informationen dazu:
> Start der 1. Instanz:
> debian@bbb1:/etc$ sudo vzlogger –c /etc/vzlogger.conf
> [Nov 26 21:12:57][main] vzlogger v0.8.0 based on heads/master-0-g3c4ef603cb 
> from Sun, 18 Aug 2019 09:36:53 +0200 started.
> [Nov 26 21:12:57][main] log level is 3
> >> alles ist gut. Port 8080 steht mit Daten zur Verfügung.
> 
> Start der 2. Instanz mit anderem HTTPD-Port und Log-Datei:
> debian@bbb1:/etc$ sudo vzlogger –c vzloggerS0.conf
> [Nov 26 21:16:04][main] vzlogger v0.8.0 based on heads/master-0-g3c4ef603cb 
> from Sun, 18 Aug 2019 09:36:53 +0200 started.
> [Nov 26 21:16:04][main] log level is 3
> >> der Prozess wird nicht wie erwartet gestartet. Keine Fehlermeldungen, 
> >> keine Log-Datei. Der konfigurierter Port 8081 steht nicht zur Verfügung.
> 
> Ein grep auf vzlogger Prozesse zeigt folgendes Ergebnis:
> debian@bbb1:/var/log$ ps -ef | grep vzlogger
> root  6289 1  2 21:12 ?00:00:18 vzlogger ???c 
> /etc/vzlogger.conf
> root  6309 1  1 21:16 ?00:00:12 vzlogger ???c vzloggerS0.conf
> debian6365  5123  0 21:26 pts/000:00:00 grep vzlogger
> >> man beachte die Fragezeichen...
> Ausgabe vzlogger-Status:
> debian@bbb1:/var/log$ sudo systemctl status vzlogger
> ● vzlogger.service - vzlogger
>Loaded: loaded (/etc/systemd/system/vzlogger.service; disabled; vendor 
> preset: enabled)
>Active: inactive (dead)
> 
> Nov 26 10:26:39 bbb1 systemd[1]: Started vzlogger.
> Nov 26 21:12:36 bbb1 systemd[1]: Stopping vzlogger...
> Nov 26 21:12:37 bbb1 systemd[1]: Stopped vzlogger.
> 
> Ich vermute, dass vzlogger nicht gleichzeitig mit mehreren Instanzen auf 
> einem System laufen kann. Vielleicht kann das jemand bestätigen, oder kennt 
> einen Lösungsansatz.
> 
> Viele Grüße
> Winfried
> 
> Am Di., 26. Nov. 2019 um 19:50 Uhr schrieb Andreas Götz  >:
> Was heisst funktionieren mal nicht? Ich liebe detaillierte 
> Fehlerbesxhreibungen ;)
> 
> Viele Grüße,
> Andreas
> 
> > Am 26.11.2019 um 18:59 schrieb Winfried Peters  > >:
> > 
> > 
> > Kann mir jemand einen Tipp geben, ob, und wenn ja, wie ich zwei 
> > vzlogger-Instanzen auf einem System ausführen kann?
> > Zweimal vzlogger mit unterschiedlichen conf-Dateien aufzurufen funktioniert 
> > auf jeden Fall nicht.
> > 
> > Viele Grüße
> > 
> > 

Gruß

Matthias

Re: [vz-users] Mehrere vzlogger-Instanzen auf einem System?

[Matthias Behr]

ich habe mir grad mal den Source angeschaut.
Es sollte nichts gegen einen mehrfachen Einsatz sprechen, wenn du 2 
unterschiedliche Configs und insbes 2 unterschiedliche Log-Files nutzt.

Nutz bei den config Files mal immer absolute Dateinamen (mit Pfad). Ich glaube, 
wenn der vzlogger als Daemon läuft, wird das akt. Verzeichnis gewechselt.

Ansonsten bitte ein Ticket dafür erstellen. Ich schaue mir das spätestens am WE 
an!

> Am 26.11.2019 um 21:35 schrieb Winfried Peters :
> 
> Ok, viele Fragen. Ich benötige zwei Instanzen als Workaround für ein Problem, 
> das ich schon mal in einer Anfrage Anfang November beschrieben habe:
> "Mein vzlogger loggt S0-Impulsdaten von Gas- und Wasser-Zähler und sml-Daten 
> vom Stromzähler. Ich puffere die Daten für eine Stunde in HTTPd, um 
> gelegentliche Ausfälle meiner Hostanwendung für die Datenauswertung zu 
> kompensieren. Das ist für die Impulsdaten besonders wichtig. Der 
> buffer-Parameter gilt für die gesamte vzlogger-Instanz. Meine PV-Anlage 
> liefert bei Dunkelheit keine Energie. Ich bekomme sekündlich einen Datensatz 
> in den Puffer gestellt, bei dem sich in diesem Fall nichts ändert als der 
> Timestamp. Das macht dann 3.600 Tupels für diesen Channel. Der 
> HTTPd-JSON-String wird periodisch von meinem Hostprogramm abgefragt. Die 
> Länge des Puffers wird bei mehreren sml-Werten sehr unhandlich und mein 
> kleiner Beaglebone-Rechner kommt dann schon ins Schwitzen. Ein 
> funktionierender Parameter "duplicate" würde die Verarbeitung wesentlich 
> effizienter machen.
> Ein Workaround wäre wahrscheinlich eine zweite vzlogger-Instanz nur für 
> sml-Zählerdaten (mit "buffer": -1), die die Daten über einen anderen 
> HTTPd-Port zur Verfügung stellt. Es ist allerdings nicht so elegant, als wenn 
> alles in einer Instanz/Config erledigt werden kann."
> 
> Inzwischen ist mein Feature-Request, "duplicate" auch für das sml-Protokoll 
> zu implementieren, als Enhancement akzeptiert worden. Solange die Umsetzung 
> noch nicht erfolgt ist, wollte ich jetzt den Workaround mit zwei 
> vzlogger-Instanzen auf einem System umsetzen, woran ich scheitere.
> 
> Hier weitere Informationen dazu:
> Start der 1. Instanz:
> debian@bbb1:/etc$ sudo vzlogger –c /etc/vzlogger.conf
> [Nov 26 21:12:57][main] vzlogger v0.8.0 based on heads/master-0-g3c4ef603cb 
> from Sun, 18 Aug 2019 09:36:53 +0200 started.
> [Nov 26 21:12:57][main] log level is 3
> >> alles ist gut. Port 8080 steht mit Daten zur Verfügung.
> 
> Start der 2. Instanz mit anderem HTTPD-Port und Log-Datei:
> debian@bbb1:/etc$ sudo vzlogger –c vzloggerS0.conf
> [Nov 26 21:16:04][main] vzlogger v0.8.0 based on heads/master-0-g3c4ef603cb 
> from Sun, 18 Aug 2019 09:36:53 +0200 started.
> [Nov 26 21:16:04][main] log level is 3
> >> der Prozess wird nicht wie erwartet gestartet. Keine Fehlermeldungen, 
> >> keine Log-Datei. Der konfigurierter Port 8081 steht nicht zur Verfügung.
> 
> Ein grep auf vzlogger Prozesse zeigt folgendes Ergebnis:
> debian@bbb1:/var/log$ ps -ef | grep vzlogger
> root  6289 1  2 21:12 ?00:00:18 vzlogger ???c 
> /etc/vzlogger.conf
> root  6309 1  1 21:16 ?00:00:12 vzlogger ???c vzloggerS0.conf
> debian6365  5123  0 21:26 pts/000:00:00 grep vzlogger
> >> man beachte die Fragezeichen...
> Ausgabe vzlogger-Status:
> debian@bbb1:/var/log$ sudo systemctl status vzlogger
> ● vzlogger.service - vzlogger
>Loaded: loaded (/etc/systemd/system/vzlogger.service; disabled; vendor 
> preset: enabled)
>Active: inactive (dead)
> 
> Nov 26 10:26:39 bbb1 systemd[1]: Started vzlogger.
> Nov 26 21:12:36 bbb1 systemd[1]: Stopping vzlogger...
> Nov 26 21:12:37 bbb1 systemd[1]: Stopped vzlogger.
> 
> Ich vermute, dass vzlogger nicht gleichzeitig mit mehreren Instanzen auf 
> einem System laufen kann. Vielleicht kann das jemand bestätigen, oder kennt 
> einen Lösungsansatz.
> 
> Viele Grüße
> Winfried
> 
> Am Di., 26. Nov. 2019 um 19:50 Uhr schrieb Andreas Götz  >:
> Was heisst funktionieren mal nicht? Ich liebe detaillierte 
> Fehlerbesxhreibungen ;)
> 
> Viele Grüße,
> Andreas
> 
> > Am 26.11.2019 um 18:59 schrieb Winfried Peters  > >:
> > 
> > 
> > Kann mir jemand einen Tipp geben, ob, und wenn ja, wie ich zwei 
> > vzlogger-Instanzen auf einem System ausführen kann?
> > Zweimal vzlogger mit unterschiedlichen conf-Dateien aufzurufen funktioniert 
> > auf jeden Fall nicht.
> > 
> > Viele Grüße
> > 
> > 

Gruß

Matthias

Re: [vz-users] vzlogger-Cross-Compile für OpenWrt

[Matthias Behr]

Hmm. Code schaut ok aus. glob.h wird eingebunden.

Lt. https://linux.die.net/man/3/glob  gibt es 
da auch GLOB_BRACE.

Ich glaube das liegt an der Build-Umgebung. Siehe z.B. hier:
https://github.com/openwrt/packages-abandoned/blob/master/net/asterisk-11.x/patches/050-musl-glob-compat.patch
 

 

> Am 17.11.2019 um 17:21 schrieb Winfried Peters :
> 
> Hallo,
> 
> ich möchte ein neues Installationspaket der aktuellen vzlogger-Version für 
> Udo's YPORT+-OpenWrt-System erstellen. Dazu habe ich die OpenWrt-Umgebung mit 
> den erforderlichen Paketen und Zielsystem eingerichtet. Der Compile bricht 
> immer beim Stand von 7% beim Build von MeterW1therm.cpp.o ab. Hier der 
> Logausschnitt:
> [  6%] Building CXX object 
> src/protocols/CMakeFiles/proto.dir/MeterRandom.cpp.o
> cd 
> /home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/src/protocols
>  && 
> /home/romokerkid/openwrt/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.16/bin/mips-openwrt-linux-musl-g++
>-DHAVE_CONFIG_HPP -DNDEBUG 
> -I/home/romokerkid/openwrt/staging_dir/target-mips_24kc_musl-1.1.16/usr/include
>  
> -I/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master
>  
> -I/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/include
>   -W -Wall -Wextra -Werror -Wnon-virtual-dtor -Wno-system-headers -Winit-self 
> -Wmissing-include-dirs -Wno-pragmas -Wredundant-decls -Wno-unused-parameter 
> -std=c++11 -fpermissive -Wno-error=redundant-decls -Wno-ignored-qualifiers 
> -O3 -Wno-unused-parameter -Wno-redundant-decls   -g3 -o 
> CMakeFiles/proto.dir/MeterRandom.cpp.o -c 
> /home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/src/protocols/MeterRandom.cpp
> [  7%] Building CXX object 
> src/protocols/CMakeFiles/proto.dir/MeterW1therm.cpp.o
> cd 
> /home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/src/protocols
>  && 
> /home/romokerkid/openwrt/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl-1.1.16/bin/mips-openwrt-linux-musl-g++
>-DHAVE_CONFIG_HPP -DNDEBUG 
> -I/home/romokerkid/openwrt/staging_dir/target-mips_24kc_musl-1.1.16/usr/include
>  
> -I/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master
>  
> -I/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/include
>   -W -Wall -Wextra -Werror -Wnon-virtual-dtor -Wno-system-headers -Winit-self 
> -Wmissing-include-dirs -Wno-pragmas -Wredundant-decls -Wno-unused-parameter 
> -std=c++11 -fpermissive -Wno-error=redundant-decls -Wno-ignored-qualifiers 
> -O3 -Wno-unused-parameter -Wno-redundant-decls   -g3 -o 
> CMakeFiles/proto.dir/MeterW1therm.cpp.o -c 
> /home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/src/protocols/MeterW1therm.cpp
> /home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/src/protocols/MeterW1therm.cpp:
>  In member function 'virtual bool MeterW1therm::W1sysHWif::scanW1devices()':
> /home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/src/protocols/MeterW1therm.cpp:35:58:
>  error: 'GLOB_BRACE' was not declared in this scope
>   if (0 == glob("/sys/bus/w1/devices/{10,22,28,3b,42}-*", 
> GLOB_BRACE|GLOB_NOSORT, NULL, &glob_res) ) {
>   ^
> src/protocols/CMakeFiles/proto.dir/build.make:209: recipe for target 
> 'src/protocols/CMakeFiles/proto.dir/MeterW1therm.cpp.o' failed
> make[5]: *** [src/protocols/CMakeFiles/proto.dir/MeterW1therm.cpp.o] Error 1
> make[5]: Leaving directory 
> '/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master'
> CMakeFiles/Makefile2:1172: recipe for target 
> 'src/protocols/CMakeFiles/proto.dir/all' failed
> make[4]: *** [src/protocols/CMakeFiles/proto.dir/all] Error 2
> make[4]: Leaving directory 
> '/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master'
> Makefile:163: recipe for target 'all' failed
> make[3]: *** [all] Error 2
> make[3]: Leaving directory 
> '/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master'
> Makefile:46: recipe for target 
> '/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/.built'
>  failed
> make[2]: *** 
> [/home/romokerkid/openwrt/build_dir/target-mips_24kc_musl-1.1.16/vzlogger-master/.built]
>  Error 2
> make[2]: Leaving directory '/home/romokerkid/openwrt/package/utils/vzlogger'
> package/Makefile:109: recipe for target 'package/utils/vzlogger/compile' 
> failed
> make[1]: *** [package/utils/vzlogger/compile] Error 2
> make[1]: Leaving directory '/home/romokerkid/openwrt'
> /home/romokerkid/openwrt/include/toplevel.mk:205 : 
> recipe for target 'package/vzlogger/compile' failed
> make: *** [package/vzlogger/compile] Error

Re: [vz-users] Benennung MQTT Topic, Timestamp

[Matthias Behr]

Hallo,

für MQTT Channel Name wird intern bereits channel->name() genutzt. Die sind 
aber akt. nur als „chn“+Nr. 
Da müssten wir mal eine Konfigurationsoption bei den Channels ermöglichen.

Für Timestamps (und qos) gibt es PR#371. Ich habe Timestamps damals bei der 
ersten Implementierung nicht für notwendig erachtet, weil von der Logik her der 
MQTT Server einfach immer den letzten Wert liefert (der aus meiner Sicht eher 
mit höherer Frequenz aktualisiert werden sollte).

Aber prinzipiell gibt es gegen PR#371 nichts einzuwenden. Könnte jederzeit 
gemerged werden.

> Am 04.09.2019 um 09:45 schrieb oeffentliche.em...@posteo.org:
> 
> Hallo,
> 
> über MQTT bekomme ich Nachrichten wie "vzlogger/something/chn0/raw 
> 9346863.80".
> Gibt es die Möglichkeit statt "chn0" irgendwas aussagekräftigeres zu 
> schicken, z.B. den "identifier" : "1-0:1.8.0" oder die uuid?
> 
> Und es gibt auch keinen Timestamp in der MQTT-Nachricht, kann man den 
> irgendwie aktivieren
> oder muss man den aus der Middleware nehmen wenn die Nachricht ankommt?
> 
> Viele Grüße,
> Markus

Gruß

Matthias

Re: [vz-users] Debugging von SSL Problemen

[Matthias Behr]

ich schaue mir das mal bei mir mit einem test server an.

> Am 22.06.2019 um 14:32 schrieb Claas H. Köhler :
> 
> Hallo,
> 
> heute hatte ich wieder etwas Zeit, mich dem Problem zu widmen. Dazu habe
> ich auf Vorschlag von Matthias die Zeilen
> 
> curl_easy_setopt(_api.curl, CURLOPT_SSL_VERIFYPEER, 0L);
> curl_easy_setopt(_api.curl, CURLOPT_SSL_VERIFYHOST, 0L);
> 
> in /src/api/Volkszaehler.cpp eingefügt und im höchsten debug level getestet. 
> Das Resultat ist die gleiche Fehlermeldung wie bei Joerg:
> 
> [Jun 22 12:23:51][chn1] CURL: Connected to our.home (192.168.178.5) port
> 443 (#0)
> [Jun 22 12:23:51][chn0] CURL: Sent '^A' bytes
> [Jun 22 12:23:51][chn1] CURL: ALPN, offering http/1.1
> [Jun 22 12:23:51][chn1] CURL: Sent 5 bytes..
> [Jun 22 12:23:51][chn1] CURL: Sent '^V^C^A' bytes
> [Jun 22 12:23:51][chn1] CURL: TLSv1.2 (OUT), TLS handshake, Client hello
> (1):
> [Jun 22 12:23:51][chn1] CURL: Sent 203 bytes..
> [Jun 22 12:23:51][chn1] CURL: Sent '^A' bytes
> [Jun 22 12:23:51][chn0] CURL: Received 5 bytes
> [Jun 22 12:23:51][chn0] CURL: Received '^U^C^C' bytes
> [Jun 22 12:23:51][chn0] CURL: TLSv1.2 (IN), TLS alert, Server hello (2):
> [Jun 22 12:23:51][chn0] CURL: Received 2 bytes
> [Jun 22 12:23:51][chn0] CURL: Received '^B
> ' bytes
> [Jun 22 12:23:51][chn0] CURL: error:140943F2:SSL
> routines:ssl3_read_bytes:sslv3 alert unexpected message
> [Jun 22 12:23:51][chn0] CURL: stopped the pause stream!
> 
> Gibt es dafür schon einen Bug report ?
> 
> Viele Grüße
> Claas
> 
> 
> On 6/12/19 9:43 PM, Joerg Krohn wrote:
>> Hi,
>> 
>> ich habe das gleiche Problem schon seit langem, deswegen hab ich wieder
>> auf http umgestellt.
>> 
>> Anbei jedoch die Meldungen, die bei mir mit https auftreten.
>> 
>>> Kannst du mal ein log File schicken? (vzlogger.log) Prinzipiell
>>> sollte das gehen (aber es gibt viele Fallstricke).
>> debug level 15
>> [Jun 12 21:27:45][chn0] CURL:   Trying 87.230.93.240...
>> [Jun 12 21:27:45][chn0] CURL: TCP_NODELAY set
>> [Jun 12 21:27:45][chn0] CURL: Connected to vs02.gh26.net (87.230.93.240) 
>> port 440 (#0)
>> [Jun 12 21:27:45][chn0] CURL: ALPN, offering http/1.1
>> [Jun 12 21:27:45][chn0] CURL: Cipher selection: 
>> ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
>> [Jun 12 21:27:48][chn0] CURL: successfully set certificate verify locations:
>> [Jun 12 21:27:48][chn0] CURL:   CAfile: /etc/ssl/certs/ca-certificates.crt
>> [Jun 12 21:27:48][chn0] CURL: TLSv1.2 (OUT), TLS header, Certificate Status 
>> (22):
>> [Jun 12 21:27:48][chn0] CURL: Sent 5 bytes..
>> [Jun 12 21:27:48][chn0] CURL: Sent '^V^C^A^B' bytes
>> [Jun 12 21:27:48][chn0] CURL: TLSv1.2 (OUT), TLS handshake, Hello request 
>> (0):
>> [Jun 12 21:27:48][chn0] CURL: Sent 512 bytes..
>> [Jun 12 21:27:48][chn0] CURL: Sent '' bytes
>> [Jun 12 21:27:48][chn0] CURL: Received 5 bytes
>> [Jun 12 21:27:48][chn0] CURL: Received '^V^C^C' bytes
>> [Jun 12 21:27:48][chn0] CURL: TLSv1.2 (IN), TLS handshake, Server hello (2):
>> [Jun 12 21:27:48][chn0] CURL: Received 108 bytes
>> [Jun 12 21:27:48][chn0] CURL: Received '^B' bytes
>> [Jun 12 21:27:48][chn0] CURL: Received 5 bytes
>> [Jun 12 21:27:48][chn0] CURL: TLSv1.2 (IN), TLS handshake, Certificate (11):
>> [Jun 12 21:27:48][chn0] CURL: Received 2554 bytes
>> [Jun 12 21:27:48][chn0] CURL: Received '^K' bytes
>> [Jun 12 21:27:48][chn0] CURL: Received 5 bytes
>> [Jun 12 21:27:49][chn0] CURL: Received '^V^C^C^AM' bytes
>> [Jun 12 21:27:49][chn0] CURL: TLSv1.2 (IN), TLS handshake, Server key 
>> exchange (12):
>> [Jun 12 21:27:49][chn0] CURL: Received 333 bytes
>> [Jun 12 21:27:49][chn0] CURL: Received '^L' bytes
>> [Jun 12 21:27:49][chn0] CURL: Received 5 bytes
>> [Jun 12 21:27:49][chn0] CURL: Received '^V^C^C' bytes
>> [Jun 12 21:27:49][chn0] CURL: TLSv1.2 (IN), TLS handshake, Server finished 
>> (14):
>> [Jun 12 21:27:49][chn0] CURL: Received 4 bytes
>> [Jun 12 21:27:49][chn0] CURL: Received '^N' bytes
>> [Jun 12 21:27:49][chn0] CURL: Sent 5 bytes..
>> [Jun 12 21:27:50][chn0] CURL: Sent '^V^C^C' bytes
>> [Jun 12 21:27:50][chn0] CURL: TLSv1.2 (OUT), TLS handshake, Client key 
>> exchange (16):
>> [Jun 12 21:27:50][chn0] CURL: Sent 70 bytes..
>> [Jun 12 21:27:50][chn0] CURL: Sent '^P' bytes
>> [Jun 12 21:27:50][chn0] CURL: Sent 5 bytes..
>> [Jun 12 21:27:50][chn0] CURL: Sent '^T^C^C' bytes
>> [Jun 12 21:27:50][chn0] CURL: TLSv1.2 (OUT), TLS change cipher, Client hello 
>> (1):
>> [Jun 12 21:27:50][chn0] CURL: Sent 1 bytes..
>> [Jun 12 21:27:50][chn0] CURL: Sent '^A' bytes
>> [Jun 12 21:27:50][chn0] CURL: Sent 5 bytes..
>> [Jun 12 21:27:50][chn0] CURL: Sent '^V^C^C' bytes
>> [Jun 12 21:27:50][chn0] CURL: TLSv1.2 (OUT), TLS handshake, Finished (20):
>> [Jun 12 21:27:50][chn0] CURL: Sent 16 bytes..
>> [Jun 12 21:27:50][chn0] CURL: Sent '^T' bytes
>> CURL: Received 5 bytes
>> [Jun 12 21:27:50][chn0] CURL: Received '^U^C^C' bytes
>> [Jun 12 21:27:50][chn0] CURL: TLSv1.2 (IN), TLS alert, Server hello (2):
>> [Jun 12 21:27:50][chn0] CURL: Received 2 bytes
>> [Jun 12 21:27:50][chn0] 

Re: [vz-users] Debugging von SSL Problemen

[Matthias Behr]

Kannst du mal ein log File schicken? (vzlogger.log) Prinzipiell sollte das 
gehen (aber es gibt viele Fallstricke).

Schick bitte auch mal von dem curl Aufruf der funktioniert eine „curl -V“ 
Ausgabe.
Und der manuelle curl Aufruf klappt auch von dem Rechner (rpi?) aus, auf dem 
vzlogger läuft, oder?


> Am 09.06.2019 um 22:35 schrieb Andreas Götz :
> 
> Klingt alles gut. An der Stelle hört mein Latein auf. Mein Vorschlag wäre 
> Ticket mit Details zum Zertifikat- evtl hat Matthias eine Idee. 
> 
> Viele Grüße,
> Andreas
> 
>> Am 09.06.2019 um 22:04 schrieb Claas H. Köhler :
>> 
>> Hallo Andreas,
>> 
>> Die MW kann ich im Browser öffnen und Känäle anzeigen. Das Server Zertifikat 
>> habe ich signiert, indem ich eine eigene Zertifizierungsstelle erstellt 
>> habe. Meine Zertifizierungsstelle habe ich Systemweit installiert. Firefox 
>> und Chrome erkennen das Zertifikat beide und curl über die Kommandozeile 
>> anscheinend auch. Bei self-signed Zertifikaten sollte curl eigentlich eine 
>> Fehlermeldung generieren, falls keine entsprechenden Kommandozeilenparameter 
>> übergeben werden. Das ist bei der aktuellen Konfiguration nicht der Fall. 
>> Daher bin ich verhalten optimistisch, dass die SSL Konfiguration ok ist. Die 
>> Frage ist, was genau die curl Version vom vzlogger stört. Nur das ist für 
>> mich als Laie aus der Fehlermeldung schwer ersichtlich. Ein paar mehr 
>> Informationen wären daher schön, um dem Problem auf die Spur zu kommen.
>> 
>> Welche Informationen würdest Du denn für einen educated guess benötigen ?
>> 
>> Viele Grüße und danke für die Hilfe
>> Claas
>> 
>>> -Original Message-
>>> From: volkszaehler-users [mailto:volkszaehler-users-
>>> boun...@demo.volkszaehler.org] On Behalf Of Andreas Goetz
>>> Sent: Sunday, June 09, 2019 9:49 PM
>>> To: volkszaehler.org - users
>>> Subject: Re: [vz-users] Debugging von SSL Problemen
>>> 
>>> Hi Claas,
>>> 
>>> Das sollte prinzipiell gehen. Die MW im Browser kannst Du öffnen, keine
>>> Zertifikatsfehler? Falls ja- ich muss passen ob/welche Ssl Hosts Vzlogger 
>>> dann
>>> akzeptiert, ob die Curl Konfiguration bzgl. self-signed (?) Zertifikaten 
>>> picky ist
>>> etc.
>>> 
>>> Da bräuchte es dann ein paar Details zu Deinem Setup.
>>> 
>>> Viele Grüße, Andreas
>>> 
 Am 09.06.2019 um 20:52 schrieb Claas H. Köhler :
 
 Hallo Andreas,
 
 Danke für die schnelle Rückmeldung. Einen Webserver der SSL spricht habe
>>> ich (Apache). Auf dem läuft die VZ Middleware. Meinst Du die Middleware
>>> kann kein SSL oder der vzlogger, der die Daten sendet ? Ich dachte vzlogger
>>> verwendet CURL, um Requests zu senden ? Kann vzlogger dann nicht alles,
>>> was curl auch kann ?
 
 Oder unterliege ich hier einem grundsätzlichen Missverständnis ?
 
 Viele Grüße
 Claas
 
 
 
> -Original Message-
> From: volkszaehler-users [mailto:volkszaehler-users-
> boun...@demo.volkszaehler.org] On Behalf Of Andreas Götz
> Sent: Sunday, June 09, 2019 8:44 PM
> To: volkszaehler.org - users
> Subject: Re: [vz-users] Debugging von SSL Problemen
> 
> Hast Du denn einen Endpunkt/Webserver der auch https spricht?
>>> Vzlogger
> kann das nicht.
> 
> Falls nein: nginx, traefik oder einen nderen Reverse Proxy
>>> zwischenschalten.
> 
> Viele Grüße,
> Andreas
> 
>> Am 09.06.2019 um 20:22 schrieb Claas H. Köhler :
>> 
>> Hallo Community,
>> 
>> Ich versuche gerade, meine Volkszähler middleware auf https
>>> umzustellen.
>> Leider erhalte ich dabei im vzlogger log Fehler der Art "CURL: SSL
>> connect error".
>> 
>> In meiner vzlogger.conf habe ich bisher nur die Zeile
>> 
>> "middleware" : "https://our.home/monitor/api";
>> 
>> angepasst. Muss ich sonst noch etwas ändern ?
>> 
>> Über die Kommandozeile gibt der Befehl
>> 
>> curl https://our.home/monitor/api/channel/.json
>> 
>> ein brauchbares Ergebnis aus. Daher gehe ich davon aus, dass die SSL
>> Verbindung und das Zertifikat ordnungsgemäß konfiguriert sind.
>> 
>> Gibt es eine Möglichkeit, mehr Debug Informationen von curl zu
>>> erhalten ?
>> 
>> Viele Grüße
>> 
>> Claas
>> 
 
>> 

Gruß

Matthias

Re: [vz-users] waiting for someone to free some space...

[Matthias Behr]

+1

Mit freundlichen Grüßen / Best Regards
Matthias

Sent from a mobile device. 

> Am 17.05.2019 um 16:29 schrieb Andreas Götz :
> 
> > wenn das Programm schlecht geschrieben ist und unnötige Tabellen und 
> > Zugriffe dadurch erzeugt werden
> 
> Keine Ahnung was das heissen soll. Da werden keine unnötigen Tabellen erzeugt 
> und Zugriffe sind genau die die notwendig sind und bestmögliche Performance 
> liefern. 
> 
> Ich fände es super keine Unterstellungen (streich das- Annahmen) zu treffen 
> sondern die Ursache zu suchen, z.B. indem Du ein SQL Log anstellst und 
> schaust was auf der DB egtl. los ist. Oder eine andere Version von MariaDB 
> installierst oder mal schaust seit wann das Verhalten so ist und was Du zu 
> diesem Zeitpunkt geändert hast. 
> 
> Mein VZ läuft mit >40Mio Einträgen und >200 Kanälen problemlos auf einem 
> kleinen Raspi...
> 
> Viele Grüße,
> Andreas
> 
>> Am 17.05.2019 um 16:06 schrieb René W :
>> 
>> Naja, wenn das Programm schlecht geschrieben ist und unnötige Tabellen und 
>> Zugriffe dadurch erzeugt werden ist es kein Hardwareproblem.
>> Ich werde aber trotzdem parallel schauen wie ich mein /tmp auf mein Synology 
>> NAS vergrößern kann.
>> LG
>> 
>>> Am Sa., 11. Mai 2019 um 19:18 Uhr schrieb Andreas Götz :
>>> Du schreibst von einem Datenbankproblem laut Name der Tempfiles. Mit VZ hat 
>>> das m.M. erstmal nichts zu tun.
>>> 
>>> Wenn Deine Platte Platz hat und nur /tmp voll ist einfach tmp vergrössern?
>>> 
>>> Viele Grüße,
>>> Andreas
>>> 
 Am 11.05.2019 um 18:35 schrieb René W :
 
 Hi
 Die Platte aufm NAS ist nicht voll.
 Nur /tmp wird mit 100% belegt angezeigt. Dadurch erhalte ich im Frontend 
 Dir Fehlermeldung „waiting for someone to free some space...“
 Wenn ich das TMP Verzeichnisse per Hand leere wird es sofort wieder 
 gefüllt.
 
 Aber schonmal gut zu wissen das die Anzahl der Einträge nicht ungewöhnlich 
 sind.
 
 Ich möchte eher herausfinden warum das tmp so schnell gefüllt wird und 
 nicht alleine geleert wird. So kann ich VZ nicht nutzen. 
 
 Gruß René 
 
 Andreas Götz  schrieb am Sa. 11. Mai 2019 um 14:53:
> Hallo Rene,
> 
> Was genau ist Dein Problem? Platte voll auf dem Nas? /tmp einfach 
> löschen- dafür ist es da. 
>  
> Wobei soll ein Neustart der „Anlage“ etwas bringen?
> 
> Oder gefällt Dir die Anzahl der DB Einträge nicht? Bei mir sinds deutlich 
> mehr auf dem Raspi...
> 
> Viele Grüße,
> Andreas
> 
>> Am 11.05.2019 um 12:04 schrieb René W :
>> 
>> Hallo,
>> 
>> ich nutzt den VZ schon seit einigen Jahren. Ausgelesen wird über ein 
>> Raspberry und die Datenbank liegt auf ein Synology NAS. Soweit so gut. 
>> Seit kurzem wird der /tmp voll geknallt mit 250MB. Dort sind Dateien wie 
>> zum Beispiel /tmp/#sql_2681_0.MAI und /tmp/#sql_2681_0.MAD
>> 
>> VZ hat in der DB über 4 Millionen(!) Einträge und belegen 183MB Daten 
>> und 149MB Indizes. Ein Neustart der gesamten Anlage bringt leider auch 
>> nichts.
>> 
>> Was sind nun meine nächsten Schritte? TMP erhöhen? DB besser 
>> konfigurieren? Alte Daten löschen/zusammenfassen?
>> 
>> Lieben Gruß René

Re: [vz-users] RPI-Image / Update der VZ-Software - Fehler beim make: cannot find -lunistring

[Matthias Behr]

bei install.sh schadet es nicht, wenn die Tests nicht aktiv sind. 
Aber bei Travis CI sollten die durchlaufen.

> Am 31.12.2018 um 17:23 schrieb Daniel Lauckner :
> 
> Hallo,
> 
> 
> am Montag, 31. Dezember 2018 um 15:11 hat Matthias Behr geschrieben:
>> hab grad folgenden Fix on top of PR#370 hinzugefügt. Damit geht es
>> lokal bei mir wieder.
> 
> Ich hab vor einiger Zeit die Tests im install.sh deaktiviert, kann das
> so bleiben?
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] RPI-Image / Update der VZ-Software - Fehler beim make: cannot find -lunistring

[Matthias Behr]

hab grad folgenden Fix on top of PR#370 hinzugefügt. Damit geht es lokal bei 
mir wieder. Travis-CI läuft noch.

diff --git a/gmock/CMakeLists.txt b/gmock/CMakeLists.txt
index d1e36ea..96ac4c5 100644
--- a/gmock/CMakeLists.txt
+++ b/gmock/CMakeLists.txt
@@ -19,6 +19,6 @@ set(GTEST_INCLUDE_DIRS ${source_dir}/googletest/include 
PARENT_SCOPE)
 
 # Specify MainTest's link libraries
 ExternalProject_Get_Property(googlemock binary_dir)
-set(GTEST_LIBS_DIR ${binary_dir}/googlemock/gtest PARENT_SCOPE)
-set(GMOCK_LIBS_DIR ${binary_dir}/googlemock PARENT_SCOPE)
+set(GTEST_LIBS_DIR ${binary_dir}/lib PARENT_SCOPE)
+set(GMOCK_LIBS_DIR ${binary_dir}/lib PARENT_SCOPE)


> Am 31.12.2018 um 14:45 schrieb Matthias Behr :
> 
> ja, komisch. Der gleiche Fehler tritt bei meinem akt. PR auf travis auch auf. 
> Schaue ich mich gleich an.
> 
> In der Zwischenzeit kannst du die Tests beim Bauen abschalten:
> (aus vzlogger Verzeichnis bauen per)
> mkdir build
> cd build
> cmake .. -DBUILD_TEST=Off
> make
> 
> 
> 
> 
>> Am 31.12.2018 um 14:25 schrieb Klemens Kieninger > <mailto:klem...@k-kieninger.de>>:
>> 
>> Halllo Matthias,
>> 
>> jetzt bin ich einen Schritt weiter, habe jedoch eine neue Fehlermeldung:
>> 
>> make[2]: *** Keine Regel vorhanden, um das Ziel 
>> „gmock/src/googlemock-build/googlemock/gtest/libgtest.a“, 
>>   benötigt von „tests/vzlogger_unit_tests“, zu erstellen.  Schluss.
>> make[2]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
>> CMakeFiles/Makefile2:1284: die Regel für Ziel 
>> „tests/CMakeFiles/vzlogger_unit_tests.dir/all“ scheiterte
>> make[1]: *** [tests/CMakeFiles/vzlogger_unit_tests.dir/all] Fehler 2
>> make[1]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
>> Makefile:163: die Regel für Ziel „all“ scheiterte
>> make: *** [all] Fehler 2
>> 
>> 
>> Gruß Klemens
>> 
>> 
>> 
>>  Forwarded Message 
>> Subject: Re: [vz-users] RPI-Image / Update der VZ-Software - Fehler beim 
>> make: cannot find -lunistring
>> Date:Mon, 31 Dec 2018 12:47:05 +0100
>> From:Matthias Behr  <mailto:mb...@mcbehr.de>
>> Reply-To:volkszaehler.org <http://volkszaehler.org/> - users 
>>  
>> <mailto:volkszaehler-users@demo.volkszaehler.org>
>> To:  volkszaehler.org <http://volkszaehler.org/> - users 
>>  
>> <mailto:volkszaehler-users@demo.volkszaehler.org>
>> 
>> Hallo,
>> 
>> fehlt bei dir Packet libunistring-dev?
>> (z.B. per sudo apt-get install libunistring-dev installieren)
>> 
>>> Am 31.12.2018 um 12:16 schrieb Klemens Kieninger  
>>> <mailto:klem...@k-kieninger.de>:
>>> 
>>> Hallo zusammen,
>>> 
>>> dies ist mein erster Beitrag in der Liste; ich hoffe ich habe sie richtig 
>>> adressiert.
>>> 
>>> 
>>> Mein Problem:
>>> 
>>> Fehlermeldung beim Updaten der VZ-Softare nach Anleitung
>>> 
>>> https://wiki.volkszaehler.org/howto/raspberry_pi_image 
>>> <https://wiki.volkszaehler.org/howto/raspberry_pi_image>
>>> 
>>> Ich habe mich per ssh auf dem rpi eingeloggt und per copy&paste die befehle 
>>> ins terminal copiert.
>>> 
>>> Nach dem "make" kommen u.a. Warnmeldungen wie
>>> 
>>> /usr/include/c++/6/bits/stl_list.h:651:9: note: parameter passing for 
>>> argument of type ‘std::_List_const_iterator’ will change in GCC 7.1
>>> { _M_initialize_dispatch(__x.begin(), __x.end(), __false_type()); }
>>> 
>>> 
>>> jedoch auch eine Fehlermeldung:
>>> 
>>> /usr/bin/ld: cannot find -lunistring
>>> collect2: error: ld returned 1 exit status
>>> src/CMakeFiles/vzlogger.dir/build.make:269: die Regel für Ziel 
>>> „src/vzlogger“ scheiterte
>>> make[2]: *** [src/vzlogger] Fehler 1
>>> make[2]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
>>> CMakeFiles/Makefile2:1025: die Regel für Ziel 
>>> „src/CMakeFiles/vzlogger.dir/all“ scheiterte
>>> make[1]: *** [src/CMakeFiles/vzlogger.dir/all] Fehler 2
>>> make[1]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
>>> Makefile:163: die Regel für Ziel „all“ scheiterte
>>> make: *** [all] Fehler 2
>>> pi@rpivz:~/vzlogger $
>>> 
>>> Weiß wer Rat?
>>> 
>>> 
>>> Gruß
>>> 
>>> Klemens
>>> 
>>> 
>> 
>> Gruß
>> 
>> Matthias
>> 
>> 
> 
> Gruß
> 
> Matthias
> 

Gruß

Matthias

Re: [vz-users] RPI-Image / Update der VZ-Software - Fehler beim make: cannot find -lunistring

[Matthias Behr]

ja, komisch. Der gleiche Fehler tritt bei meinem akt. PR auf travis auch auf. 
Schaue ich mich gleich an.

In der Zwischenzeit kannst du die Tests beim Bauen abschalten:
(aus vzlogger Verzeichnis bauen per)
mkdir build
cd build
cmake .. -DBUILD_TEST=Off
make




> Am 31.12.2018 um 14:25 schrieb Klemens Kieninger :
> 
> Halllo Matthias,
> 
> jetzt bin ich einen Schritt weiter, habe jedoch eine neue Fehlermeldung:
> 
> make[2]: *** Keine Regel vorhanden, um das Ziel 
> „gmock/src/googlemock-build/googlemock/gtest/libgtest.a“, 
>   benötigt von „tests/vzlogger_unit_tests“, zu erstellen.  Schluss.
> make[2]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
> CMakeFiles/Makefile2:1284: die Regel für Ziel 
> „tests/CMakeFiles/vzlogger_unit_tests.dir/all“ scheiterte
> make[1]: *** [tests/CMakeFiles/vzlogger_unit_tests.dir/all] Fehler 2
> make[1]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
> Makefile:163: die Regel für Ziel „all“ scheiterte
> make: *** [all] Fehler 2
> 
> 
> Gruß Klemens
> 
> 
> 
>  Forwarded Message 
> Subject:  Re: [vz-users] RPI-Image / Update der VZ-Software - Fehler beim 
> make: cannot find -lunistring
> Date: Mon, 31 Dec 2018 12:47:05 +0100
> From: Matthias Behr  <mailto:mb...@mcbehr.de>
> Reply-To: volkszaehler.org - users 
>  
> <mailto:volkszaehler-users@demo.volkszaehler.org>
> To:   volkszaehler.org - users  
> <mailto:volkszaehler-users@demo.volkszaehler.org>
> 
> Hallo,
> 
> fehlt bei dir Packet libunistring-dev?
> (z.B. per sudo apt-get install libunistring-dev installieren)
> 
>> Am 31.12.2018 um 12:16 schrieb Klemens Kieninger  
>> <mailto:klem...@k-kieninger.de>:
>> 
>> Hallo zusammen,
>> 
>> dies ist mein erster Beitrag in der Liste; ich hoffe ich habe sie richtig 
>> adressiert.
>> 
>> 
>> Mein Problem:
>> 
>> Fehlermeldung beim Updaten der VZ-Softare nach Anleitung
>> 
>> https://wiki.volkszaehler.org/howto/raspberry_pi_image 
>> <https://wiki.volkszaehler.org/howto/raspberry_pi_image>
>> 
>> Ich habe mich per ssh auf dem rpi eingeloggt und per copy&paste die befehle 
>> ins terminal copiert.
>> 
>> Nach dem "make" kommen u.a. Warnmeldungen wie
>> 
>> /usr/include/c++/6/bits/stl_list.h:651:9: note: parameter passing for 
>> argument of type ‘std::_List_const_iterator’ will change in GCC 7.1
>> { _M_initialize_dispatch(__x.begin(), __x.end(), __false_type()); }
>> 
>> 
>> jedoch auch eine Fehlermeldung:
>> 
>> /usr/bin/ld: cannot find -lunistring
>> collect2: error: ld returned 1 exit status
>> src/CMakeFiles/vzlogger.dir/build.make:269: die Regel für Ziel 
>> „src/vzlogger“ scheiterte
>> make[2]: *** [src/vzlogger] Fehler 1
>> make[2]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
>> CMakeFiles/Makefile2:1025: die Regel für Ziel 
>> „src/CMakeFiles/vzlogger.dir/all“ scheiterte
>> make[1]: *** [src/CMakeFiles/vzlogger.dir/all] Fehler 2
>> make[1]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
>> Makefile:163: die Regel für Ziel „all“ scheiterte
>> make: *** [all] Fehler 2
>> pi@rpivz:~/vzlogger $
>> 
>> Weiß wer Rat?
>> 
>> 
>> Gruß
>> 
>> Klemens
>> 
>> 
> 
> Gruß
> 
> Matthias
> 
> 

Gruß

Matthias

Re: [vz-users] RPI-Image / Update der VZ-Software - Fehler beim make: cannot find -lunistring

[Matthias Behr]

Hallo,

fehlt bei dir Packet libunistring-dev?
(z.B. per sudo apt-get install libunistring-dev installieren)

> Am 31.12.2018 um 12:16 schrieb Klemens Kieninger :
> 
> Hallo zusammen,
> 
> dies ist mein erster Beitrag in der Liste; ich hoffe ich habe sie richtig 
> adressiert.
> 
> 
> Mein Problem:
> 
> Fehlermeldung beim Updaten der VZ-Softare nach Anleitung
> 
> https://wiki.volkszaehler.org/howto/raspberry_pi_image
> 
> Ich habe mich per ssh auf dem rpi eingeloggt und per copy&paste die befehle 
> ins terminal copiert.
> 
> Nach dem "make" kommen u.a. Warnmeldungen wie
> 
> /usr/include/c++/6/bits/stl_list.h:651:9: note: parameter passing for 
> argument of type ‘std::_List_const_iterator’ will change in GCC 7.1
>{ _M_initialize_dispatch(__x.begin(), __x.end(), __false_type()); }
> 
> 
> jedoch auch eine Fehlermeldung:
> 
> /usr/bin/ld: cannot find -lunistring
> collect2: error: ld returned 1 exit status
> src/CMakeFiles/vzlogger.dir/build.make:269: die Regel für Ziel „src/vzlogger“ 
> scheiterte
> make[2]: *** [src/vzlogger] Fehler 1
> make[2]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
> CMakeFiles/Makefile2:1025: die Regel für Ziel 
> „src/CMakeFiles/vzlogger.dir/all“ scheiterte
> make[1]: *** [src/CMakeFiles/vzlogger.dir/all] Fehler 2
> make[1]: Verzeichnis „/home/pi/vzlogger“ wird verlassen
> Makefile:163: die Regel für Ziel „all“ scheiterte
> make: *** [all] Fehler 2
> pi@rpivz:~/vzlogger $
> 
> Weiß wer Rat?
> 
> 
> Gruß
> 
> Klemens
> 
> 

Gruß

Matthias

Re: [vz-users] Daten auf MQTT Topics verteilen

[Matthias Behr]

Hallo,

schon mal https://github.com/volkszaehler/vzlogger/pull/357 
 angeschaut?

Gruß
Matthias

> Am 23.09.2018 um 21:47 schrieb Frank Richter :
> 
> Hi Christian,
> 
> was gibt's da groß zu "entschlüsseln", das ist doch auch nur JSON? Geht im 
> Prinzip genauso wie bei den Websockets-Messages vom Push-Server.
> 
> Gruß
> Frank
> 
> Christian Wulff mailto:christianwu...@gmx.de>> 
> schrieb am So., 23. Sep. 2018 20:11:
> Hallo Frank,
> 
>  
> 
> also so?:
> 
>  
> 
>   "push": [
> 
> {
> 
>   "url": "http://127.0.0.1:5582 "},
> 
> { "url": "http://127.0.0.1:1880/vzpush "
> 
> }
> 
>   ],
> 
>  
> 
> Das scheint zu funktionieren.
> 
> Auf jeden Fall kommt dann msg: Objects im debug Fenster von Node-RED raus.
> 
> Im debug Fenster habe ich diese Objects mal aufgeklappt und durchgesehen, und 
> tatsächlich einen Zählerstand eines Stromzählers gefunden *happy*
> 
>  
> 
> Jetzt müssen diese Objects „nur“ noch entschlüsselt und auf den MQTT Broker 
> gepublished werden.
> 
> Das sieht mir jetzt aber sehr komplex aus.
> 
> Hat da jemand ein Beispiel, wie man das hinkriegt? Da blicke ich so erstmal 
> gar nicht durch L
> 
>  
> 
> Liebe Grüße,
> 
> Chris
> 
>  
> 
> Von: Frank Richter [mailto:frank.richte...@gmail.com 
> ] 
> Gesendet: Samstag, 22. September 2018 18:47
> An: volkszaehler.org  - users
> Betreff: Re: [vz-users] Daten auf MQTT Topics verteilen
> 
>  
> 
> Hi Christian,
> 
>  
> 
> "push": [] ist doch ein Array, sollte also auch mit mehreren Zielen 
> klarkommen.
> 
>  
> 
> Grüße
> 
> Frank
> 
>  
> 
> Christian Wulff mailto:christianwu...@gmx.de>> 
> schrieb am Sa., 22. Sep. 2018, 17:00:
> 
> Hallo Frank,
> 
>  
> 
> ich möchte also zusätzlich zu den Werten, die über den Push Server an MQTT 
> gesendet werden, auch noch die Zählerstände vom vzlogger direkt an Node-RED 
> pushen.
> 
> Dazu steht im Wiki, dass man folgende Zeilen in /ect/vzlogger.conf editieren 
> soll:
> 
> "push": [
> 
>   {
> 
> "url": "http://127.0.0.1:1880/vzpush "
> 
>   }
> 
> ],
> 
>  
> 
>  
> 
> Nun habe ich in meiner /ect/vzlogger.conf allerdings schon drin stehen:
> 
>   "push": [
> 
> {
> 
>   "url": "http://127.0.0.1:5582 "
> 
> }
> 
>   ],
> 
>  
> 
> Was ist denn richtig?
> 
> Beides geht ja vermutlich nicht?!
> 
>  
> 
> Lieben Gruß,
> 
> Chris
> 
>  
> 
> Von: Frank Richter [mailto:frank.richte...@gmail.com 
> ] 
> Gesendet: Donnerstag, 20. September 2018 18:29
> An: volkszaehler.org  - users
> Betreff: Re: [vz-users] Daten auf MQTT Topics verteilen
> 
>  
> 
> Hi Christian,
> 
>  
> 
> richtig verstanden.
> 
>  
> 
> Für MQTT ist die Payload einfach ein String, ob da nur der Wert, JSON oder 
> sonstwas drin steht, ist dem Broker egal.
> 
>  
> 
> Zählerstände gibt's über den Push-Server nicht. Entweder von vzlogger direkt 
> an Node-RED pushen lassen (siehe Wiki) oder von Node-RED bei der Middleware 
> abholen.
> 
>  
> 
> Grüße
> 
> Frank
> 
>  
> 
> Christian Wulff mailto:christianwu...@gmx.de>> 
> schrieb am Do., 20. Sep. 2018, 14:11:
> 
> Moin Frank,
> 
>  
> 
> wenn ich dich richtig verstanden habe, wäre bei dem Design nicht 
> sichergestellt, dass der timestamp auch wirklich zu dem value gehört, richtig?
> 
> Okay, das verstehe ich, und hatte auch schon an diese potentielle 
> Fehlermöglichkeit gedacht.
> 
>  
> 
> Ich dachte ich hätte MQTT so verstanden, dass in den MQTT-Messages nur Werte, 
> aber keine komplexeren Strukturen (z.B. Timestamp und Wert) richtig wären.
> 
> Aber das scheint dann wohl egal zu sein?!
> 
>  
> 
> Wenn ich jetzt den Wasserzähler einmal auf einen Topic mit timestamp und 
> value und einmal nur den value publishe, dann habe ich halt einen Topic mehr. 
> Ich denke das funktioniert auch.
> 
> Bis jetzt fällt mir von meinen ganzen Sensoren auch eigentlich nur der 
> Wasserzähler ein, bei dem ich den timestamp brauche, weil ich aus dem letzten 
> timestamp und dem aktuellem timestamp die Durchflussrate berechne, und wenn 
> der nächste timestamp ausbleibt will ich die Durchflussrate auch noch gen 
> Null trimmen, je mehr Zeit verrinnt. (Ansonsten würde die Durchflussrate 
> immer zwischem einem Wert und Null toggeln, wenn man den Wasserhahn langsam 
> zudreht. Aber soweit bin ich noch nicht.
> 
> Die Sache mit dem „Send_zero = true“ habe ich übrigends relativ schnell 
> wieder gelassen, weil jede Sekunde eine „0“ gesendet wird, und so die 
> Durchflussrate zwangsweise jede Sekunde zwischen einem Wert und Null toggelt.
> 
>  
> 
> Wenn wir schon beim Thema MQTT sind:
> 
> Wie kriege ich denn die Stromzählerstände und Wasserzählerstand auf MQTT?
> 
> (bis jetzt kriege ich dort nur Momentanleistung raus)
> 
>  
> 
> Lieben Gruß,
> 
> Chris
> 
>  
> 
> Von: Frank Richter [mailto:frank

Re: [vz-users] vzlogger und EasyMeter Q3M

[Matthias Behr]

schick mal nen Dump der seriellen Daten

> Am 08.12.2017 um 13:27 schrieb Jan Strecker :
> 
> Hallo,
> 
> 
> hat hier einer schon mal den EasyMeter Q3M (genauer Q3MA1020 V6.02)
> Zweirichtungszähler mit vzlogger zum laufen bekommen?
> 
> Funktioniert leider weder mit sml noch mit d0.
> 
> 9600 8N1 scheint aber zu stimmen, da ich die Seriennummer mit minicom
> (oder auch cat /dev/ttyUSB0) im Sekundentakt mit lesen kann. Der Rest
> ist leider scheinbar im Binärformat.
> 
> 
> Jan
> 

Gruß

Matthias

Re: [vz-users] Wiederkehrende System-Crashes

[Matthias Behr]

Versuch mal ein besseres USB Netzteil. 
SD-Karten brauchen beim Schreiben relativ viel Strom. Das kann das Netzteil oft 
nicht liefern und es kommt gerade beim Schreiben zu Korruption. 

Mit freundlichen Grüßen / Best Regards
Matthias

Sent from a mobile device. 

> Am 03.12.2017 um 13:34 schrieb Rupert Schöttler :
> 
> Hallo ihr fleißigen Volkszähler,
> 
> nach Berichten in diesem Forum über "Raspberry legt Netzwerk lahm - ssh
> network storm" und "Crash der SD Karte" möchte ich über meine seltsamen
> Erfahrungen der letzten Wochen bzw. Monate berichten.
> 
> Mein gut ein Jahr alter Raspberry Pi 3 lief problemlos unter jessie,
> seit Anfang Mai d.J. auch mit der vz-middleware (Datenbank und Webserver
> - das Daten Sammeln erledigt ein zweiter Pi 1 Model B). Ende September
> dann plötzlich war die Systemlast extrem hoch, ich konnte mich nicht
> mehr per ssh einloggen, und nach dem Stecker Ziehen (ein ordentlicher
> shutdown ging ja nicht...) startete das System nicht mehr. Ein fsck auf
> die Karte im Leser eines anderen Rechners meldete tausende Fehler, auch
> nach dem Reparieren funktionierte die Karte nicht mehr. Also habe ich
> das System Anfang Oktober neu aufgesetzt. Diesmal unter stretch.
> 
> Gut zwei Wochen lief das System, dann wieder das gleiche Problem: Hohe
> Systemlast, kein ssh-login, nach dem "Stromausfall" kein Systemstart
> mehr. Alle Rettungsversuche der Daten auf der SD-Karte scheiterten, also
> "platt machen" und neu aufsetzen.
> 
> Der Thread "Raspberry legt Netzwerk lahm - ssh network storm" von Anfang
> November schien auf meine Probleme zu passen, denn ich hatte im
> September mein Heimnetzwerk über die von AVS (fritz.box) angebotenen
> Mechanismen nach außen geöffnet. Allerdings habe ich die im Thread
> angesprochenen Sicherheitsaspekte (PW ändern, updates) immer von Anfang
> an umgesetzt. Weil ich den Fernzugang aber eh nicht nutzte, habe ich ihn
> sicherheitshalber wieder zu gemacht.
> 
> Wieder lief der Pi gut 2 Wochen, als Updates anstanden und ein
> 
> $ sudo apt-get update && sudo apt-get upgrade
> 
> eine Fehlermeldung lieferte wie
> 
> dpkg: nicht behebbarer fataler Fehler, Abbruch:
> Abschließender Zeilenvorschub fehlt in Dateilisten-Datei des Paketes »acl«
> E: Sub-process /usr/bin/dpkg returned an error code (2)
> 
> Die Recherche nach möglichen Ursachen so eines Fehlers zeigte, dass die
> entsprechenden Listen-Dateien tatsächlich kein reiner Text mehr waren,
> in Pfadangaben einzelne Buchstaben sinnlos verändert waren, am
> Zeilenende Quatsch stand usw. Da ich mich außerstande sah, das einzeln
> zu korrigieren, versuchte ich einen reboot (ich war ja eingeloggt ;-) --
> der Pi startete aber nicht mehr. Also wieder fsck der SD-Karte im
> anderen Rechner, automatische Reparatur Tausender Fehler, Karte im Pi
> startet trotzdem nicht.
> 
> Also wird das System wieder neu aufgesetzt (wer hat mitgezählt, zum wie
> vielten Mal? :-), man bekommt ja Routine, und auch die parallel zu den
> Befehlen mitgeschriebene Anleitung wird immer besser. Das war letztes
> Wochenende. Am Dienstag dann wollte ich wieder Updates einspielen, und
> wieder kam die Fehlermeldung von dpkg. Diesmal habe ich aber (noch)
> keinen Reboot veranlasst, denn der Pi läuft stabil -- halt ohne Update.
> Aber die Datenbank und der Webserver funktionieren, immer noch. Trotzdem
> ist der Zustand natürlich nicht dauerhaft haltbar.
> 
> Folgende Vermutungen zu Ursachen habe ich schon angestellt:
> 
> 1. Fehlerhafte SD-Karte (Patriot microSDHC Card 16 GB): Vor dem letzten
> Neu-Aufsetzen habe ich sie mit H2testw -- by Harald Bögeholz / c't
> Magazin für Computertechnik, "Integritätstest für USB-Sticks und andere
> Datenträger", Version 1.4 getestet, sie wurde für gut befunden. Die
> komplette Installation inkl. Updates usw. lief ja auch fehlerfrei durch.
> Jetzt und auch schon vor drei Tagen aber meldet
> 
> $ fdisk -l
> Speicherzugriffsfehler
> 
> Seltsam, dass ich trotzdem Dateien auf diesem Filesystem korrekt
> erzeugen kann: Um wenigstens die kontinuierlich erfassten Daten zu
> retten, bevor das System wieder abschmiert, habe ich ein inkrementelles
> Backup für die Datentabelle eingerichtet, das stündlich eine CSV-Datei
> erzeugt und auf einem anderen Rechner kopiert.
> 
> 2. Hardware-Defekt am Kartenleser des Pi: Da gilt m.E. dasselbe wie
> oben: Wie hätte dann die ganze Installation, die ja mit Ausnahme des
> Aufspielens des Images komplett auf diesem Pi ablief, funktionieren sollen?
> 
> 3. Fehler in der Distribution (raspbian stretch oder vz Middleware):
> Dann sollten doch andere User ähnliches erleben.
> 
> 4. Mein System ist kompromittiert: Nicht der Pi, der den Ärger macht,
> sondern andere Rechner im Netz, die unauffällig weiter laufen und nur
> dieses eine Gerät torpedieren? M.E. ist so ein Szenario nicht
> ausgeschlossen, aber ist es realistisch? Wie könnte ich es herausfinden?
> 
> 5. Das Problem sitzt vor dem Rechner und schreibt gerade einen
> Hilferuf... :-) Was mache ich falsch?
> 
> Schöne Grüße

Re: [vz-users] vzlogger loggt nur im daemon Modus

[Matthias Behr]

ok. Das Problem habe ich verstanden.

Es handelt sich um eine Racecondition.

Nach dem Auslesen eines Wertes wird der „logging_thread“ einfach hart per 
„pthread_cancel“ abgebrochen.
Je nach dem, wie schnell der Logging Thread die Daten per curl verschicken 
konnte, bekommst du die oder eben auch nicht.

In deiner Konfig mit 2 Metern an die gleiche Middleware verschärft sich das 
noch. Da für das Übermitteln die gleiche Curl-Connection genutzt wird, sind die 
Logging_Threads defacto serialisiert. Dadurch wird es aber noch 
wahrscheinlicher, dass der 2. seine Daten nicht mehr übermitteln kann.

Du kannst mal für den 2. eine andere Middleware angeben (z.B. einfach die 
Groß-/Kleinschreibung beim Hostnamen ändern). Dann werden separate 
Curl-Sessions genutzt und die Daten werden parallel verschickt.
Das reduziert das Problem.

Wir brauchen aber für den Use-Case einen richtigen Fix. Ist nicht so trivial, 
weil wir die ganzen Fehlersituationen wie „keine/langsame Verbindung/Fehler" 
zur Middleware abfangen müssen, damit es nicht zum Hang kommt.

-> Kannst du einen Bug im github einstellen?

> Am 02.11.2017 um 18:21 schrieb Matthias Behr :
> 
> ich schaue mir das an (aber erst nächste Woche bin grad im Ausland)
> 
> Mit freundlichen Grüßen / Best Regards
> Matthias 
> 
> Sent from a mobile device. 
> 
>> Am 02.11.2017 um 17:08 schrieb Daniel Lauckner :
>> 
>> Hallo,
>> 
>> 
>> am Donnerstag, 2. November 2017 um 08:09 hat RaspberryVZ geschrieben:
>>> die Logs habe ich mit höherer verbosity erzeugt als in der beigefügten
>>> config, da kommt nicht mehr dabei raus.
>> 
>> Ich glaube du hast da ne falsche Vorstellung.
>> Natürlich kommt da keine Meldung: "Hier hat einer was vergessen", jede
>> Meldung muss irgendwer programmiert haben. Für Probleme die der
>> Programmierer nicht auf dem Schirm hat gibts natürlich auch keine
>> Logeinträge.
>> Dennoch ist es wichtig ein möglichst hohes Loglevel zu haben um
>> nachverfolgen zu können was gemacht wurde und was _nicht_.
>> 
>>> Wäre toll, wenn das wieder gehen würde. Man könnte ja einen neuen
>>> Parameter einbauen - Transfer zur MW oder nicht.
>> 
>> Könnte man. Ich nicht.
>> Vielleicht kann ich den Fehler ausfindig machen, aber neue Funktionen
>> und Optionen überschreiten meine Fähigkeiten.
>> 
>>> O.k., habe eben nochmal ein paarmal per Kommandozeile gestartet - bei 
>>> drei Aufrufen hat er EINMAL EINEN der beiden Werte geschrieben.
>> 
>> Das ja mal interessant.
>> Sieht fast so aus als würden die Daten gesendet wenn CURL (zufällig?)
>> genug Zeit hat. Vzlogger wird nicht beendet wenn CURL noch arbeitet,
>> aber wenn er noch nicht richtig angefangen hat...
>> 
>> Damit schwinden aber die Chancen das ich was ausrichten kann.
>> 
>> 
>> mfg Daniel
>> 
> 

Gruß

Matthias

Re: [vz-users] Fehlermeldung

[Matthias Behr]

mach mal nen serial dump

> Am 08.11.2017 um 16:36 schrieb Ottmar Koeder :
> 
> Hallo,
> 
> kann jemand etwas mit dieser Meldung aus vzlogger.log anfangen?
> 
>  "Too much data for obis_code (byte=0x7F)"
> 
> der vzlogger bleibt einfach stehen und aquiriert keine neuen Daten mehr 
> und der RPi scheint auch ziemlich beschäftigt zu sein (lange 
> Reaktionszeiten).
> Restart durch reboot oder coldstart beseitigt das Problem bis zum 
> nächsten Stillstand (tritt ca. 1*/Tag auf)
> 

Gruß

Matthias

Re: [vz-users] vzlogger loggt nur im daemon Modus

[Matthias Behr]

ich schaue mir das an (aber erst nächste Woche bin grad im Ausland)

Mit freundlichen Grüßen / Best Regards
Matthias 

Sent from a mobile device. 

> Am 02.11.2017 um 17:08 schrieb Daniel Lauckner :
> 
> Hallo,
> 
> 
> am Donnerstag, 2. November 2017 um 08:09 hat RaspberryVZ geschrieben:
>> die Logs habe ich mit höherer verbosity erzeugt als in der beigefügten
>> config, da kommt nicht mehr dabei raus.
> 
> Ich glaube du hast da ne falsche Vorstellung.
> Natürlich kommt da keine Meldung: "Hier hat einer was vergessen", jede
> Meldung muss irgendwer programmiert haben. Für Probleme die der
> Programmierer nicht auf dem Schirm hat gibts natürlich auch keine
> Logeinträge.
> Dennoch ist es wichtig ein möglichst hohes Loglevel zu haben um
> nachverfolgen zu können was gemacht wurde und was _nicht_.
> 
>> Wäre toll, wenn das wieder gehen würde. Man könnte ja einen neuen
>> Parameter einbauen - Transfer zur MW oder nicht.
> 
> Könnte man. Ich nicht.
> Vielleicht kann ich den Fehler ausfindig machen, aber neue Funktionen
> und Optionen überschreiten meine Fähigkeiten.
> 
>> O.k., habe eben nochmal ein paarmal per Kommandozeile gestartet - bei 
>> drei Aufrufen hat er EINMAL EINEN der beiden Werte geschrieben.
> 
> Das ja mal interessant.
> Sieht fast so aus als würden die Daten gesendet wenn CURL (zufällig?)
> genug Zeit hat. Vzlogger wird nicht beendet wenn CURL noch arbeitet,
> aber wenn er noch nicht richtig angefangen hat...
> 
> Damit schwinden aber die Chancen das ich was ausrichten kann.
> 
> 
> mfg Daniel
> 

Re: [vz-users] vzlogger-Update bricht bei 28% ab

[Matthias Behr]

schickst mal Output von:

cc —version
gcc —version
g++ —version
?

> Am 08.10.2017 um 20:39 schrieb D. Greulich :
> 
> Hallo Daniel,
> 
> leider läuft das Script nicht durch. Es beendet sich mit folgenden Zeilen:
> 
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/software/vzlogger
> make: *** Es wurden keine Ziele angegeben und keine „make“-Steuerdatei 
> gefunden.  Schluss.
> 
> Ich habe die gesamte Ausgabe des Scripts mal als Textdatei angehängt.
> 
> Ab Zeile 316 tauchen auch ein paar Warnungen auf, wie z.B.:
> 
> src/sml_message.c:305:63: warning: ISO C does not support ‘__FUNCTION__’ 
> predefined identifier [-Wpedantic]
> 
> oder 
> 
> unity/unity.c:17:23: warning: missing braces around initializer 
> [-Wmissing-braces]
> 
> oder 
> 
> configure.ac:19 : warning: LT_INIT was called before 
> AM_PROG_AR
> 
> 
> 
> 
> 
> Mit freundlichen Grüßen
> Dennis Greulich
> 
> ---
> 
> 
> Am 8. Oktober 2017 um 20:14 schrieb Daniel Lauckner  >:
> Hallo,
> 
> 
> am Sonntag, 8. Oktober 2017 um 20:09 hat Daniel Lauckner geschrieben:
> > ./install.sh vzlogger
> 
> Ups, Fehler! Nur:
> 
> ./install.sh
> 
> 
> mfg Daniel
> 
> 
> 

Gruß

Matthias

Re: [vz-users] Leerlauf Verbrauch im Haushalt

[Matthias Behr]

Ich habe bei mir nach Optimierung (Kühlschränke, Gefrierschrank, Beleuchtung,…) 
mein Jahresverbrauch auf 2200kWh/Jahr für 4 Pers. Haushalt (2 Erw, 2 Teenager) 
reduziert. Macht pro Tag 6kWh im Schnitt. Nicht im Leerlauf ;-)


> Am 17.08.2017 um 12:32 schrieb Christian Schnellrieder 
> :
> 
> Danke nochmal für Eure Beiträge. Zum einen schön zu sehen das ich nicht der 
> einzige bin mit ca 300Watt Stby... zum anderen das es auch Personen gibt die 
> es geschaft haben den Verbrauch doch stark zu optimieren.
> 
> 
> Zum Thema "Highlights der VZ:
> Ich betreibe die VZ nun rund 2 Jahre und so manche Dinge hätte ich damit 
> nicht so einfach gefunden oder geschaft:
> - Meiner Frau verständlich machen das der Trockner einfach nur purer Luxus 
> ist wenn man einen Garten hat und viel Sonne.
> - Die Zusatzheizung der WP so einzustellen das diese wirklich Sinn macht. 
> (Stichwort: Zwangstrennung um 11:00 )
> - Dem Vermieter bitten die Steckdose vom Nachbarn von meinem Zählerkasten 
> abzuklemmen ( ja 3 Entfeuchter verbrauchen viel )
> 
> Grüße,
> Christian
> 
> 
> Daniel Lauckner mailto:v...@jahp.de>> schrieb am Do., 17. Aug. 
> 2017 um 11:49 Uhr:
> Hallo,
> 
> 
> am Mittwoch, 16. August 2017 um 11:50 hat Christian Schnellrieder geschrieben:
> > Man findet zwar viele Infos im Netz bzgl Standby Verbrauch im
> > Haushalt aber keine direkten Werte was das nun ca so pro Haushalt ausmacht.
> 
> Die Zeiträume sind eher kurz, aber zum Vergleich sollte es reichen:
> 
> Sommer
> 1,15kWh in 11,1h (2,5kWh in 24h)
> 104W (Max: 180W)
> 
> Winter (ohne Ladepumpe)
> 1,67kWh in 14,55h
> 115W (Max: 195W)
> 
> 1 Kühlschrank (~72W)
> 1 Klingel
> 2 Torantriebe
> 3 elektronische Eltako
> 1 Heizungssteuerung daran
> 2 Heizkreispumpen
> 1 Ladepumpe
> 8 Stellantriebe
> 1 USV daran
> 1 Router
> 1 NAS
> 1 Telefon
> 1 Switch
> 1 WLAN AP (PoE)
> 1 Rpi (PoE)
> 2 Radiowecker
> 1 Herd (SB)
> 1 Backofen (SB)
> 1 Fernseher (SB)
> 1 DVD-Player (SB)
> 
> Ohne StandBy (als Merkposten, das ichs nicht vergessen hab) ;)
> 1 Drucker
> 1 Waschmaschine
> 11 Rolladenantriebe, elektronische Endabschaltung
> 
> Ich wohne in dem Haus seit 2012, ich möchte jetzt nicht behaupten das
> ich den SB gezielt optimiert hab, wenn was auffällig war hab ich aber
> reagiert. Und da war VZ durchaus eine Hilfe.
> 
> Ein Punkt war da die Ladepumpe vom Holzofen. Die fiel schon sehr früh
> auf weil die Pumpe der Rücklaufanhebung schlecht dimensioniert und alter
> Bauart war. Sie gönnte sich satte 70W. Im Winter läuft die ~6h
> täglich. Als ich das gegen eine energieeffizientere Pumpe gegenrechnete
> kam ich auf einen ROI von 12 Jahren.
> Es ergab sich aber das ich mit einer der Heizkreispumpen nicht ganz
> klar kam (Sollwerteingang, von der UVR1611 geregelt) und durch eine
> andere ersetzt hab. Damit hatte ich dann eine effizientere Pumpe über
> und konnte den Strombedarf auf ~10-15W reduzieren.
> 
> Ich hab in den Jahren irgendwann den Desktop PC durch ein Notebook
> ersetzt. Seltsamerweise konnte ich meine abendlichen PC-Zeiten dennoch
> im VZ nachverfolgen.
> Das lag daran das ich, statt am Schreibtisch, öfter am Esstisch meinen
> Kram erledigte. In der Esstischlampe waren aber Halogen (3x20W) verbaut.
> Wurden durch LED (3x4W) ersetzt.
> 
> Das war recht schnell zuzuordnen weil ich schon kurz nach Einzug
> einen ähnlichen Fall mit einem unerwarteten 800W Großverbraucher hatte.
> Es war das Treppenhauslicht.
> Zu der Zeit als ich die Lampen kaufte war LED noch recht teuer und
> nicht sehr leuchtstark. Ich wollte das kompensieren indem ich
> Lampen mit vielen Leuchtmitteln installierte. Halogenstahler mit 4
> Armen. Davon insgesamt 4 Stück. Alle gleichzeitig geschalten.
> Ich hab aber nicht sofort LED eingebaut sondern wollte die Halos erst
> verschleißen (die Dinger zu bauen kost ja schließlich auch Energie).
> Jetzt hatten die aber eine Nennleistung von je 50W...
> 
> Der extremste Fall war war mir schon in der Bauphase aufgefallen:
> Am Dachfenster ist auch ein elektrischer Rollladen. Dazu wurde auch eine
> Steuerung gekauft. Von Velux. Als ich den Karton in Händen hielt hatte
> ich schon ein sehr ungutes Gefühl, das Ding war überraschend schwer!
> Wie sich herausstellte war da ein dicker Trafo drin. Ausgelegt für
> AFAIR 5 Fenster. Nennleistung eines dieser Rolläden glaub 60-70W. StandBy
> der Steuerung: _80W_
> Ich hab dann nach etwas Suchen ein Netzteil gefunden das aus 2 230V
> Eingängen (Hoch und Runter) die nötige DC-Umpolung direkt bereitstellte.
> Wenn der Schalter nach dem schließen oder öffnen wieder in
> Ruhestellung gebracht wird (was die Regel ist) braucht der gar kein
> SB.
> 
> Einen Verbraucher ähnlicher Größenordnung hatte ich vorher mal
> aussortiert, mein erster Gigabit-Ethernet-Switch (19" und doch nur 6
> Ports) brauchte auch geschlagene 80W.
> 
> Ansonsten nutze ich den VZ hauptsächlich um das Nutzerverhalten zu
> steuern und Warmwasser aus PV zu machen.
> 
> 
> Auf der zweiten V

Re: [vz-users] [vz-dev] Wie kann man Drehzahlen messen?

[Matthias Behr]

ja
> Am 16.07.2017 um 19:30 schrieb Daniel Lauckner :
> 
> Hallo,
> 
> 
> am Sonntag, 16. Juli 2017 um 19:06 hat Matthias Behr geschrieben:
>> zu 9/10/12:
>> vzlogger kann die Frequenzen bis paar kHz auf rpi3 locker loggen. 
> 
> Nebenfrage dazu: Bei Impulsen sammelt der vzlogger immer eine
> Sekunde lang bevor er die Daten an die MW sendet?
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] [vz-dev] Wie kann man Drehzahlen messen?

[Matthias Behr]

zu 9/10/12:
vzlogger kann die Frequenzen bis paar kHz auf rpi3 locker loggen. 

Gruß
Matthias

Sent from a mobile device. 

> Am 16.07.2017 um 17:06 schrieb Christian Wulff :
> 
> Moin,
>  
> denn antworte/verschiebe ich mal in die Users Liste.
> Wo und wie ist denn definiert was in die Users und Dev Liste gehört?
>  
> Vielleicht muss ich nochmal von vorne anfangen und noch genauer definieren 
> was genau meine Fragen sind:
>  
> 1.   Ich habe 3 Lüfter mit vermutlich unter 2000rpm, von denen ich die 
> Drehzahl messen und im Volkszähler loggen möchte. Dargestellt werden sollen 
> die Drehzahlen im Frontend.
> 2.   Geht das?
> 3.   Wie geht das?
> 4.   Hat das schon mal jemand gemacht?
> 5.   Wie genau hat derjenige das gemacht?
> 6.   Wie sind die Erfahrungen damit? (z.B. Zuverlässigkeit, Genauigkeit, 
> Was würde derjenige beim nächsten Mal anders machen?)
> 7.   Wie misst man das am besten?
> 8.   Mit welchen Sensoren?
> 9.   Wo schließt man das am Raspberry Pi 3 an?
> 10.   Ist es besser das an einen ESP8266 anzuschließen? So könnte man den 
> Prozessor vom Raspi entlasten.
> 11.   Was brauch ich dafür an Hardware?
> 12.   Was brauch ich dafür an Software?
> 13.   Welche Datenformate sind dafür sinnvoll?
> 14.   …..
>  
> Lieben Gruß,
> Chris
>  
>  
> Von: Andreas Goetz [mailto:cpui...@gmail.com] 
> Gesendet: Sonntag, 16. Juli 2017 14:42
> An: volkszaehler.org
> Betreff: Re: [vz-dev] Wie kann man Drehzahlen messen?
>  
> Es wird gespeichert was Du willst. Viel wichtiger: wie willst Du denn messen? 
> Was kommt aus Deinem Meßaufbau raus?
>  
> Viele Grüße, Andreas
>  
> PS.: Die Diskussion gehört nicht auf die Entwicklerliste…
>  
> On 16. Jul 2017, at 12:18, Christian Wulff  wrote:
>  
> Hallo Frank,
>  
> Die Drehzahl weiss ich nicht genau, nehmen wir mal 2000rpm an, wahrscheinlich 
> weniger. Sicher keine >5000rpm.
>  
> Bei Temperaturen werden Temperaturwerte (z.B. 19,357) im VZ gespeichert.
> Beim Stromzähler, werden die Stromzählerstände (z.B. 8354,7) im VZ 
> gespeichert.
> Bei der Wasseruhr werden die S0 Impulse (z.B. 1,1,1,1,1,1,1,1,1,1,1,1 ) im VZ 
> gespeichert.
> Soweit klar.
>  
> Was wird denn bei Frequenz / Drehzahl gespeichert bzw. was erwartet der VZ da?
>  
> Hochfrequente Impulse wohl eher nicht?! (z.B. 1,1,1,1,1,1,1,1,1,1,1,1 )
> Impulse pro Zeiteinheit? (z.B. 10357/5min)
> Frequenzwerte (z.B. 33,235 Hz)
> Drehzahl (z.B. 1987rpm)
>  
>  
> Lieben Gruß,
> Chris
>  
>  
>  
> Von: Frank Richter [mailto:frank.richte...@gmail.com] 
> Gesendet: Samstag, 15. Juli 2017 20:49
> An: volkszaehler.org
> Betreff: Re: [vz-dev] Wie kann man Drehzahlen messen?
>  
> Hi Christian,
>  
> von welchen Drehzahlen reden wir da?
> So Realtime-Sachen gehen vielleicht besser mit einem kleinen Microcontroller, 
> z.B. Arduino. Will allerdings auch nicht ausschließen dass es direkt mit dem 
> Pi geht, da hab ich aber keine Erfahrung.
>  
> Grüße
> Frank
>  
>  
> Am 15.07.2017 18:34 schrieb "Christian Wulff" :
> Hallo Frank,
>  
> die erste Frage war, ob das überhaupt geht. Die scheint beantwortet zu sein. 
> Ja, geht. Sehr gut J
>  
> Und nun natürlich die nächste Frage: Wie? Also was braucht man da als 
> Hardware? Damit meine ich noch nicht den Sensor, das könnte ne Lichtschranke, 
> Magnet, Hallsensor oder, oder, oder sein.
> Braucht man noch irgendeinen Frequenzzähler, den der Raspi dann ausließt oder 
> zählt der Raspi auf einem GPIO selber, oder gibt’s nen 1-Wire counter?
> Wenn der Raspi selber zählt vermute ich, dass die CPU stark belastet wird?!
> Hat sowas schon mal jemand gemacht?
>  
> Lieben Gruß,
> Chris
>  
>  
> Von: Frank Richter [mailto:frank.richte...@gmail.com] 
> Gesendet: Freitag, 14. Juli 2017 23:25
> An: volkszaehler.org
> Betreff: Re: [vz-dev] Wie kann man Drehzahlen messen?
>  
> Hallo Christian,
>  
> geht es dir um Hardware (passende Sensorik) oder Software 
> (Loggen/Darstellen)? Volkszähler kennt Drehzahl und Frequenz als Kanaltyp, 
> das sollte also kein Problem sein.
>  
> Grüße
> Frank
>  
> Am 14.07.2017 22:09 schrieb "Christian Wulff" :
> Moin,
>  
> gibt es eine Möglichkeit Drehzahlen mit dem Volkszähler zu messen?
>  
> Mir schwebt da vor drei Lüfterdrehzahlen unserer Luft-Wasser Wärmepumpe zu 
> loggen.
>  
> Danke und lieben Gruß,
> Chris
>  

Re: [vz-users] 20 Stromzähler auswerten (mittels S0)

[Matthias Behr]

der RPi hat doch ca 20 GPIOs. Vzlogger hat mit der Last kein Problem. 
(Zur Not nimm 2 RPis statt einem)

Gruß
Matthias 

Sent from a mobile device. 

> Am 23.06.2017 um 18:45 schrieb Karol Babioch :
> 
> Hallo,
> 
> ich evaluiere derzeit meine Optionen ca. 20 Stromzähler auszuwerten,
> welche mittels S0 Impulse ausgeben. Die im Wiki vorgestellten Lösungen
> zielen ja im wesentlichen auf einige wenige solcher Stromzähler ab.
> Grundsätzlich ist der Ablauf bei 20 und mehr Zählern natürlich der
> Gleiche, allerdings stößt man halt an die Grenzen was man an einen
> Raspberry bzw. andere Mikroncontroller ohne I/O Expansion direkt
> anschließen kann.
> 
> Aktuell sehe ich einen dedizierten Mikrocontroller (AVR, weil ich damit
> vertraut bin) vor, der die Impulse auswertet (ggf. noch entprellt, etc.)
> und für jeden Impuls mittels UART eine kurze Nachricht verschickt, die
> ein Raspberry entgegen nimmt und speichert. Rein rechnerisch sollte das
> selbst mit einem langsam getakteten AVR überhaupt kein Problem darstellen.
> 
> Auf Seiten des Raspberry würde ich gerne vzlogger benutzen. Dieser
> bietet laut [1] ja diverse Möglichkeiten, um Signale auszuwerten.
> Besonders interessant wären für mich wohl "file" bzw. "exec". Leider ist
> die Doku relativ dürftig und man muss den Quelltext studieren [2], um zu
> entschlüsseln was genau erwartet wird.
> 
> In meinem Fall müsste es ja zumindest in triviales Protokoll geben, um
> zwischen den verschiedenen Impulse differenzieren zu können.
> Idealerweise könnte man sogar etwas in die Richtung implementieren, dass
> der Raspberry den Empfang des Impulses bestätigen muss, bevor der
> Mikrocontroller ihn verwirft. Wird er in x Sekunden nicht abgenommen, so
> wird er ins EEPROM geschrieben, da auf Seiten des Raspberrys dann wohl
> ein Fehler vorliegt.
> 
> Nun frage ich mich, ob hier jemand schon etwas ähnliches gemacht hat und
> ggf. Empfehlungen aus der Praxis geben kann bzw. ob das Rad eventuell
> gar nicht neu erfunden werden muss.
> 
> Mit freundlichen Grüßen,
> Karol Babioch
> 
> [1]: https://wiki.volkszaehler.org/software/controller/vzlogger/overview_en
> [2]: https://github.com/volkszaehler/vzlogger/tree/master/src/protocols
> 

Re: [vz-users] Installation vzlogger stockt

[Matthias Behr]

Wo ist denn deine Confg Datei?
> Am 04.04.2017 um 22:19 schrieb Andreas Löffler :
> 
> PS Ich glaube, ich habe den Fehler. In der Log steht
> 
> [Apr 04 22:15:12][main] vzlogger v0.6.1 based on heads/master-0-g99f8edbcb4 
> from Mon, 6 Mar 2017 19:03:42 +0100 started.
> [Apr 04 22:15:12]   New meter initialized (protocol=sml)
> [Apr 04 22:15:12][chn0] New channel initialized (uuid=...0ced10 
> api=volkszaehler id=power)
> [Apr 04 22:15:12][chn1] New channel initialized (uuid=...42a90c 
> api=volkszaehler id=counter)
> [Apr 04 22:15:12][chn2] New channel initialized (uuid=...104b48 
> api=volkszaehler id=1-0:1.8.0)
> [Apr 04 22:15:12]   New meter initialized (protocol=s0)
> [Apr 04 22:15:12][chn3] New channel initialized (uuid=...45c7b2 
> api=volkszaehler id=Impulse)
> [Apr 04 22:15:12]   New meter initialized (protocol=d0)
> [Apr 04 22:15:12][chn4] New channel initialized (uuid=...ee api=volkszaehler 
> id=1-0:1.8.1)
> [Apr 04 22:15:12]   New meter initialized (protocol=random)
> [Apr 04 22:15:12]   Identifier is not set. Set it to default value 
> 'NilIdentifier'.
> [Apr 04 22:15:12][chn5] New channel initialized (uuid=...1e5a66 
> api=volkszaehler id=NilIdentifier)
> [Apr 04 22:15:12]   New meter initialized (protocol=file)
> [Apr 04 22:15:12]   New meter initialized (protocol=exec)
> [Apr 04 22:15:12]   New meter initialized (protocol=fluksov2)
> [Apr 04 22:15:12][chn6] New channel initialized (uuid=...53edec 
> api=volkszaehler id=sensor0/power)
> [Apr 04 22:15:12]   New meter initialized (protocol=w1therm)
> [Apr 04 22:15:12][main] log level is 5
> [Apr 04 22:15:12]   Process not  daemonized...
> [Apr 04 22:15:12][mtr0] Meter for protocol 'sml' is disabled. Skipping.
> [Apr 04 22:15:12][mtr1] Meter for protocol 's0' is disabled. Skipping.
> [Apr 04 22:15:12][mtr2] Meter for protocol 'd0' is disabled. Skipping.
> [Apr 04 22:15:12][mtr3] Meter for protocol 'random' is disabled. Skipping.
> [Apr 04 22:15:12][mtr4] Meter for protocol 'file' is disabled. Skipping.
> [Apr 04 22:15:12][mtr5] Meter for protocol 'exec' is disabled. Skipping.
> [Apr 04 22:15:12][mtr6] Meter for protocol 'fluksov2' is disabled. Skipping.
> [Apr 04 22:15:12][mtr7] Meter for protocol 'w1t' is disabled. Skipping.
> [Apr 04 22:15:12]   No functional meters found - quitting!
> 
> und die letzte Zeile sagt mir, woran es liegt. Leider stehe ich hier etwas 
> auf dem Schlauch: Ich habe mir den USB-IR-Kopf für die IR-Schnittstelle 
> besorgt - leider bin ich etwas hilflos, wie ich den "anschließe". Gibt es da 
> einen Link mit Hinweisen?
> 
> Vielen Dank vorab für die Hilfe.
> 
> Am 4. April 2017 um 22:03 schrieb Andreas Löffler  >:
> 
> Du kannst es auch per Hand installieren:
> http://wiki.volkszaehler.org/software/controller/vzlogger/installation_cpp-version#build_von_hand
>  
> 
> 
> Dazu vorher die Abhängigkeiten installieren:
> http://wiki.volkszaehler.org/software/controller/vzlogger/installation_cpp-version#systemvoraussetzungen_zur_kompilierung_des_vzlogger
>  
> 
> Beides habe ich jetzt getan, leider ohne Erfolg. Die Installation bricht ab 
> bei Zeile 286 des install.sh-Skriptes. Ich habe dann von Hand 
> vzlogger.service und  vzlogger.conf in das entsprechende 
> /etc/systemd-Verzeichnung kopiert und konnte den Service starten. Die 
> Statusmeldung aber lautet
> 
> ● vzlogger.service - vzlogger
> 
>Loaded: loaded (/etc/systemd/system/vzlogger.service; disabled)
> 
>Active: failed (Result: exit-code) since Di 2017-04-04 21:59:53 CEST; 9s 
> ago
> 
>   Process: 19587 ExecStart=/usr/local/bin/vzlogger -c /etc/vzlogger.conf 
> (code=exited, status=1/FAILURE)
> 
>  Main PID: 19587 (code=exited, status=1/FAILURE)
> 
> Apr 04 21:59:53 keller systemd[1]: Started vzlogger.
> 
> Apr 04 21:59:53 keller systemd[1]: vzlogger.service: main process exited, 
> code=exited, status=1/FAILURE
> 
> Apr 04 21:59:53 keller systemd[1]: Unit vzlogger.service entered failed state.
> 
> 
> Ich möchte das gesamte Image nicht installieren, weil ich andere Dienste auf 
> dem RPi noch laufen lassen will. Daher dachte ich mir, ich installiere das 
> besser von Hand. Aber irgendwo ist der Wurm drin. Viele Grüße, Andreas 
> 

Gruß

Matthias

Re: [vz-users] neue Frage

[Matthias Behr]

ja, du bist wohl auf dem falschen Rechner ;-)

> Am 17.02.2017 um 10:01 schrieb Frans Oonk :
> 
> Wen ich eingebe  fdisk -l
>  
> root@raspberrypi:/home/pi# fdisk -l
>  
> Disk /dev/mmcblk0: 4008 MB, 4008706048 bytes
> 4 heads, 16 sectors/track, 122336 cylinders, total 7829504 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x000b5098
>  
> Device Boot  Start End  Blocks   Id  System
> /dev/mmcblk0p18192  122879   57344c  W95 FAT32 (LBA)
> /dev/mmcblk0p2  122880 5785599 2831360   83  Linux
> /dev/mmcblk0p3 5785600 7626751  920576   83  Linux
>  
>  
> Muss ich hier etwas andern?
>  
>  
>  
>  
>  
>  
> Van: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Namens Matthias Behr
> Verzonden: donderdag 16 februari 2017 21:53
> Aan: volkszaehler.org - users
> Onderwerp: Re: [vz-users] neue Frage
>  
> mach mal 
> ps aux|grep vzlogger
>  
>> Am 16.02.2017 um 18:51 schrieb Frans Oonk > <mailto:f-o...@wxs.nl>>:
>>  
>> Hallo allerseits,
>>  
>> Ich habe mal wieder etwas falsch gemacht. Wollte das dbcopy reinbringen aber 
>> nun kann ich das vzlogger und das vzlogger.conf nicht mehr finden.
>> Auch nicht nach reboot.
>>  
>> Das System lauft und die Daten sind im Frontend zu sehen und in Ordnung. 
>>  
>> find / -name vzlogger* bringt auch keine Lösung.
>>  
>> Wie oder wo kann ich eine File tree von das VZ finden.
>>  
>> Mit freundlichem Gruß,
>>  
>> Frans
>>  
>>  
> 
>  
> Gruß
>  
> Matthias

Gruß

Matthias

Re: [vz-users] falschen Messwert in der Aggregation löschen

[Matthias Behr]

670mb/s geht mit USB2 nicht. Messfehler oder doch USB3?


> Am 17.02.2017 um 08:39 schrieb Andreas Goetz :
> 
> Mein Raspi3 läuft jetzt mit USB Adapter und m.2 SSD komplett ohne SD Karte. 
> Performance:
> 
> pi@keller:~/volkszaehler.org  $ sudo hdparm -tT 
> /dev/sda
> 
> /dev/sda:
>  Timing cached reads:   1350 MB in  2.00 seconds = 674.42 MB/sec
>  Timing buffered disk reads: 106 MB in  3.02 seconds =  35.06 MB/sec
> 
> Viele Grüße, 
> Andreas
> 
> 
> 2017-02-14 9:44 GMT+01:00 Andreas Götz  >:
> So isses. Eine 3GB Datenbank ist schon ganz ordentlich. Im Jahre 2011 wäre 
> das für VZ noch unmöglich gewesen zu handeln- kein Aggregation, nur Raspi1. 
> Klar lässt sich immer optimieren aber am Ende muss einfach die Plattform zu 
> den Anforderungen passen. Bzgl. tmpfs ist hier eben ein Limit erreicht.
> 
> Viele Grüße, Andreas
> 
> Ps.: ich stelle meinen Pi3 jetzt mal auf Usb Boot via m.2 SSD um (ca 50€) und 
> werde berichten...
> 
> > Am 14.02.2017 um 09:10 schrieb Daniel Lauckner  > >:
> >
> > Hallo,
> >
> >
> > am Dienstag, 14. Februar 2017 um 00:33 hast du geschrieben:
> >> Alles was man loggen will wird per Push ins Netz geschoben.
> >
> > Wir wollen die Kirche aber mal im Dorf lassen.
> >
> > Ein Log braucht man schließlich nur wenns nicht mehr rund läuft.
> > Wenn es dann nicht da liegt wo man es erwartet oder beim Transfer
> > verloren geht hat keiner was davon.
> >
> >> Das
> >> sagt einem dann, was an der Query so lang dauert
> >
> > Das dauert so lang weils scheiß viele Daten sind.
> >
> > Der Rpi ist eine kostengünstige Einsteigerlösung. Es ist absolut
> > vorhersehbar das User mit erhöhten Anforderungen damit nicht
> > glücklich werden. Aber deswegen ist VZ ja modular aufgebaut. Man
> > kann die Bestandteile problemlos voneinander getrennt betreiben,
> > auf Hardware die den Bedürfnissen gerecht wird.
> >
> >
> > mfg Daniel
> >
> 

Gruß

Matthias

Re: [vz-users] neue Frage

[Matthias Behr]

mach mal 
ps aux|grep vzlogger

> Am 16.02.2017 um 18:51 schrieb Frans Oonk :
> 
> Hallo allerseits,
>  
> Ich habe mal wieder etwas falsch gemacht. Wollte das dbcopy reinbringen aber 
> nun kann ich das vzlogger und das vzlogger.conf nicht mehr finden.
> Auch nicht nach reboot.
>  
> Das System lauft und die Daten sind im Frontend zu sehen und in Ordnung. 
>  
> find / -name vzlogger* bringt auch keine Lösung.
>  
> Wie oder wo kann ich eine File tree von das VZ finden.
>  
> Mit freundlichem Gruß,
>  
> Frans
>  
>  

Gruß

Matthias

Re: [vz-users] falschen Messwert in der Aggregation löschen

[Matthias Behr]

naja, aber viel mehr als 480mbit/s wird der rpi3 eh nicht verarbeiten können. 
Das sollte daher nicht der Bottleneck sein ;-)

> Am 14.02.2017 um 09:53 schrieb Andreas Götz :
> 
> OT: leider bindet auch der Raspi3 die SSD nur via Usb2 an 😢
> 
> Viele Grüße,
> Andreas
> 
>> Am 14.02.2017 um 09:51 schrieb Daniel Lauckner :
>> 
>> Hallo Andreas,
>> 
>> 
>> am Dienstag, 14. Februar 2017 um 09:44 hast du geschrieben:
>>> Ps.: ich stelle meinen Pi3 jetzt mal auf Usb Boot via m.2 SSD um (ca 50€) 
>>> und werde berichten...
>> 
>> Wegen Udos Issue hab ich gestern vzlogger paralell aufm RpiB auf SD und
>> aufm BananaPro auf SSD compilieren lassen.
>> Ein Unterschied wie Tag und Nacht...
>> 
>> 
>> mfg Daniel
>> 

Gruß

Matthias

Re: [vz-users] Elster AS1440 - vzlogger.conf

[Matthias Behr]

Nee. Wenn du die Daten brauchst, musst du mir kurz Info schicken, wofür die 
stehen, dann kann ich vzlogger anpassen.

> Am 20.01.2017 um 08:37 schrieb Jörg Hildering :
> 
> 
> Ok. vzlogger kennt das nicht. Muss bzw kann ich da was machen, anpassen?
> 
> Gruß
> Jörg
> 
> In der log steht
> 
> Failed to parse obis code (1-1:7d)
> Failed to parse obis code (1-1:1d)
> Failed to parse obis code (1-1:30d)
> 
> Was bedeutet das?
> 
> Gruß
> Jörg
> 
> 
>> Am 19.01.2017 um 12:00 schrieb 
>> volkszaehler-users-requ...@demo.volkszaehler.org:
>> 
>> Send volkszaehler-users mailing list submissions to
>>  volkszaehler-users@demo.volkszaehler.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  https://demo.volkszaehler.org/mailman/listinfo/volkszaehler-users
>> or, via email, send a message with subject or body 'help' to
>>  volkszaehler-users-requ...@demo.volkszaehler.org
>> 
>> You can reach the person managing the list at
>>  volkszaehler-users-ow...@demo.volkszaehler.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of volkszaehler-users digest..."
>> 
>> 
>> Today's Topics:
>> 
>> 1. Re: Elster AS1440 - vzlogger.conf (Udo1)
>> 2. Re: Elster AS1440 - vzlogger.conf (Daniel Lauckner)
>> 
>> 
>> --
>> 
>> Message: 1
>> Date: Wed, 18 Jan 2017 23:11:04 +0100
>> From: Udo1 
>> To: volkszaehler-users@demo.volkszaehler.org
>> Subject: Re: [vz-users] Elster AS1440 - vzlogger.conf
>> Message-ID: <7d16efa6-cfc6-63bc-47d0-a5202b26f...@gmx.net>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
>>> Am 18.01.2017 um 23:02 schrieb Jörg Hildering:
>>> Bei Auflösung hab ich 0.0001 eingetragen. Kann das passen? Aktuell
>>> werden mir 90W bei 1.7.0 Bezugs Leistung angezeigt.
>> Was steht in der vzlogger.log?
>> 
>> Gruß
>> Udo
>> 
>> 
>> --
>> 
>> Message: 2
>> Date: Wed, 18 Jan 2017 23:43:31 +0100
>> From: Daniel Lauckner 
>> To: "volkszaehler.org - users"
>>  
>> Subject: Re: [vz-users] Elster AS1440 - vzlogger.conf
>> Message-ID: <101169563.20170118234...@jahp.de>
>> Content-Type: text/plain; charset=utf-8
>> 
>> Hallo Udo,
>> 
>> 
>> am Mittwoch, 18. Januar 2017 um 22:23 hast du geschrieben:
>>> Bei der Config schaltet der Zähler aber nicht auf 9600bd um, da die
>>> "ackseq": "063035300d0a",
>>> fehlt.
>> 
>> Soweit ich den Code verstanden hab wird der Schlüssel "ackseq", wenn
>> er fehlt, von vzlogger standardmäßig mit "auto" belegt.
>> 
>> 
>> mfg Daniel
>> 
>> 
>> 
>> --
>> 
>> Subject: Digest Footer
>> 
>> ___
>> volkszaehler-users mailing list
>> volkszaehler-users@demo.volkszaehler.org
>> https://demo.volkszaehler.org/mailman/listinfo/volkszaehler-users
>> 
>> 
>> --
>> 
>> End of volkszaehler-users Digest, Vol 66, Issue 95
>> **

Gruß

Matthias

Re: [vz-users] Elster AS1440 - vzlogger.conf

[Matthias Behr]

ja. sieht gut aus!

Gruß
Matthias 

Sent from a mobile device. 

> Am 18.01.2017 um 18:47 schrieb Jörg Hildering :
> 
> Hallo,
> 
> ich habe noch was gefunden. Und zwar stand in der dump_file ganz oben 
> folgendes. Heißt das das der Zähler tatsächlich einmal richtig ausgelesen 
> hat? Ich weiß nur leider nicht mehr mit welcher config. Wenn das aber die 
> richtigen Daten sind würde ich noch weiter testen.
> 
> # 23.996506000s ( 0 ms) opened
> # 24.022769000s ( 8 ms) read
> # 24.022875000s ( 0 ms) TCIOFLUSH and cfsetiospeed
> < 24.123478000s (94 ms) 
> 2f 3f 21 0d 0a/?!  
> 
> > 25.00548s (   876 ms) 
> 38 2e 33 2a 32 32 28 30 30 30 30 30 30 30 2e 30   8.3*22(000.0 
> 06 26 5d 7d 3d 5f 5d 1c 61 31 2d 31 3a 31 2e 38&]}=_] a1-1:1.8 
> 2e 34 28 30 30 30 30 30 30 30 2e 30 30 30 2a 6b   .4(000.000*k 
> 57 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e 34 2a 33   Wh)  1-1:1.8.4*3 
> 36 28 30 30 30 30 30 30 30 2e 30 30 30 2a 6b 57   6(000.000*kW 
> 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e 34 2a 33 35   h)  1-1:1.8.4*35 
> 28 30 30 30 30 30 30 30 2e 30 30 30 2a 6b 57 68   (000.000*kWh 
> 29 0a 0a 31 2d 31 3a 31 2e 38 2e 34 2a 33 34 28   )  1-1:1.8.4*34( 
> 30 30 30 30 30 30 30 2e 30 30 30 2a 6b 57 68 29   000.000*kWh) 
> 0a 0a 31 2d 31 3a 31 2e 38 2e 34 2a 33 33 28 30 1-1:1.8.4*33(0 
> 30 30 30 30 30 30 2e 30 30 30 2a 6b 57 68 29 0d   00.000*kWh)  
> 0a 31 2d 31 3a 31 2e 38 2e 34 2a 33 32 28 30 301-1:1.8.4*32(00 
> 30 30 30 30 30 2e 30 30 30 2a 6b 57 68 29 0a 0a   0.000*kWh)   
> 31 2d 31 3a 31 2e 38 2e 34 2a 33 31 28 30 30 30   1-1:1.8.4*31(000 
> 30 30 30 30 2e 30 30 30 2a 6b 57 68 29 0a 0a 31   .000*kWh)  1 
> 2d 31 3a 31 2e 38 2e 34 2a 33 30 28 30 30 30 30   -1:1.8.4*30( 
> 30 30 30 2e 30 30 30 2a 6b 57 68 29 0a 0a 31 2d   000.000*kWh)  1- 
> 31 3a 31 2e 38 2e 34 2a 32 39 28 30 30 30 30 30   1:1.8.4*29(0 
> 30 30 2e 30 30 30 2a 6b 57 68 29 0a 0a 31 2d 31   00.000*kWh)  1-1 
> 3a 31 2e 38 2e 34 2a 32 38 28 30 30 30 30 30 30   :1.8.4*28(00 
> 30 2e 30 30 30 2a 6b 57 68 29 0a 0a 31 2d 31 3a   0.000*kWh)  1-1: 
> 31 2e 38 2e 34 2a 32 37 28 30 30 30 30 30 30 30   1.8.4*27(000 
> 2e 30 30 30 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31   .000*kWh)  1-1:1 
> 2e 38 2e 34 2a 32 36 28 30 30 30 30 30 30 30 2e   .8.4*26(000. 
> 30 30 30 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e   000*kWh)  1-1:1. 
> 38 2e 34 2a 32 35 28 30 30 30 30 30 30 30 2e 30   8.4*25(000.0 
> 30 30 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e 38   00*kWh)  1-1:1.8 
> 2e 34 2a 32 34 28 30 30 30 30 30 30 30 2e 30 30   .4*24(000.00 
> 30 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e   0*kWh)  1-1:1.8. 
> 34 2a 32 33 28 30 30 30 30 30 30 30 2e 30 30 30   4*23(000.000 
> 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e 34   *kWh)  1-1:1.8.4 
> 2a 32 32 28 30 30 30 30 30 30 30 2e 30 30 30 2a   *22(000.000* 
> 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e 35 28   kWh)  1-1:1.8.5( 
> 30 30 33 35 37 31 37 2e 35 37 35 2a 6b 57 68 29   0035717.575*kWh) 
> 0a 0a 31 2d 31 3a 31 2e 38 2e 35 2a 33 36 28 30 1-1:1.8.5*36(0 
> 30 33 34 34 39 32 2e 39 31 37 2a 6b 57 68 29 0d   034492.917*kWh)  
> 0a 31 2d 31 3a 31 2e 38 2e 35 2a 33 35 28 30 301-1:1.8.5*35(00 
> 33 32 34 31 38 2e 30 35 35 2a 6b 57 68 29 0d 0a   32418.055*kWh)   
> 31 2d 31 3a 31 2e 38 2e 35 2a 33 34 28 30 30 30   1-1:1.8.5*34(000 
> 30 35 35 32 2e 32 34 31 2a 6b 57 68 29 0a 0a 31   0552.241*kWh)  1 
> 2d 31 3a 31 2e 38 2e 35 2a 33 33 28 30 30 32 30   -1:1.8.5*33(0020 
> 35 38 35 2e 30 32 33 2a 6b 57 68 29 0a 0a 31 2d   585.023*kWh)  1- 
> 31 3a 31 2e 38 2e 35 2a 33 32 28 30 30 32 39 30   1:1.8.5*32(00290 
> 36 36 2e 39 32 37 2a 6b 57 68 29 0a 0a 31 2d 31   66.927*kWh)  1-1 
> 3a 31 2e 38 2e 35 2a 33 31 28 30 30 32 39 31 36   :1.8.5*31(002916 
> 32 2e 35 36 33 2a 6b 57 68 29 0a 0a 31 2d 31 3a   2.563*kWh)  1-1: 
> 31 2e 38 2e 35 2a 33 30 28 30 30 32 39 30 34 36   1.8.5*30(0029046 
> 2e 33 30 30 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31   .300*kWh)  1-1:1 
> 2e 38 2e 35 2a 32 39 28 30 30 32 38 39 31 30 2e   .8.5*29(0028910. 
> 34 38 35 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e   485*kWh)  1-1:1. 
> 38 2e 35 2a 32 38 28 30 30 32 38 35 35 38 2e 37   8.5*28(0028558.7 
> 39 37 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e 38   97*kWh)  1-1:1.8 
> 2e 35 2a 32 37 28 30 30 32 37 35 35 30 2e 37 34   .5*27(0027550.74 
> 31 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e   1*kWh)  1-1:1.8. 
> 35 2a 32 36 28 30 30 32 35 36 34 32 2e 31 36 32   5*26(0025642.162 
> 2a 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e 35   *kWh)  1-1:1.8.5 
> 2a 32 35 28 30 30 32 33 34 38 33 2e 37 38 30 2a   *25(0023483.780* 
> 6b 57 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e 35 2a   kWh)  1-1:1.8.5* 
> 32 34 28 30 30 32 30 39 39 34 2e 34 30 36 2a 6b   24(0020994.406*k 
> 57 68 29 0a 0a 31 2d 31 3a 31 2e 38 2e 35 2a 32   Wh)  1-1:1.8.5*2 
> 33 28 30 30 31 39 33 34 35 2e 38 32 31 2a 6b 57   3(0019345.821*kW 
> 68 29 0a 0a 31 2d 31 3a 31 2e 

Re: [vz-users] Ich wünsche allen ein frohes Fest

[Matthias Behr]

Gleichfalls!


> Am 25.12.2016 um 09:35 schrieb Udo1 :
> 
> Ich wünsche allen ein Frohes Fest.
> 
> Gruß
> Udo

Gruß

Matthias

Re: [vz-users] vzlogger Easymeter Q3C (SML Meter) antwortet nicht auf pull Sequenz -> vzlogger wartet für immer

[Matthias Behr]

Hallo,

zu 1)
Wir sollten min. Plausi Check (Zeit kleiner 2016-> nimm andere Zeit) einführen. 
Machst ein Issue dafür auf?

zu 2) bitte auch hier Issue. Mal schauen, ob man da sinnvoll ein Timeout 
einbauen kann. 

Gruß
Matthias

Sent from a mobile device. 

> Am 22.12.2016 um 09:24 schrieb Claus Beckenbauer :
> 
> Hallo zusammen,
> 
> Mit vzlogger in Verbindung mit dem o.g.  Zähler habe ich zwei Probleme die 
> genau in der Form schon im Forum beschrieben sind:
> http://www.photovoltaikforum.com/viewtopic.php?f=131&t=12&p=1357667&hilit=SML+h%C3%A4ngt#p1357667
> 
> Zusammenfassung des Threads:
> Zähler hat zwei Eigenheiten:
> 
> Problem 1)
> Uhrzeit beim Zähler ist nicht gestellt und demnach derzeit irgendwo in den 
> 70ern. MeterSML.cpp verwendet den timestamp des Zählers sobald einer gefunden 
> wurde, was dazu führt, dass in der middleware die Daten auch in den 70ern 
> landen. Im Frontend muss man ziemlich lange zurückscrollen bis man was sieht.
> Könnte man hier nicht, wie im Forum vorgeschlagen, einen Plausibilitätscheck 
> durchführen?
> Ist es denkbar über einen Konfigurationsparameter zu steuern ob der 
> Zeitstempel vom Meter oder Lokalzeit verwendet wird?
> 
> Problem 2)
> Easymeter hat sporadisch Sprechpause und antwortet nicht auf pull Sequenz. 
> Das führt dazu, dass der reading thread für den SML Meter bis in alle 
> Ewigkeit wartet.
> /* wait until we receive a new datagram from the meter (blocking read) */
> bytes = sml_transport_read(_fd, buffer, SML_BUFFER_LEN);
> Das Problem besteht ja auch grundsätzlich dann, wenn z.B. der Optokopf beim 
> starten des vzloggers noch nicht auf der Opto Schnittstelle des Meters hängt.
> 
> So wie ich das sehen, ist Problem 2 schon als bug einzustufen.
> 
> Viele Grüße,
> Claus

Re: [vz-users] vzlogger s0 protocol + aggtime funktioniertsporadisch nicht wie erwartet

[Matthias Behr]

Hallo Claus,

die Schleife schadet vermutlich nicht. 

Sicherer wäre noch:

do {
…
} while (aggIntEnd <= time(NULL) && mtr->aggtime() > 0); 

ggf. wird mrt->aggtime() >0 aber vorher schon geprüft.

Bereits du Commit vor oder soll ich?

Gruß
Matthias

> Am 20.12.2016 um 09:50 schrieb Claus Beckenbauer :
> 
> Hallo Matthias,
> 
> das Problem bei blockierenden Zählern besteht aber weiterhin.
> Was hälst du denn von der vorgeschlagenen Änderung in reading_thread():
> 
> do {
>aggIntEnd += mtr->aggtime(); /* end of this aggregation period */
> } while(aggIntEnd <= time(NULL)); /* aggIntEnd has to be in the future */
> 
> aggIntEnd bleibt (ausgehend vom Startpunkt der Messung) im Raster, würde aber 
> nur max nach Ablauf der aggregation period neue Werte an die middleware 
> senden.
> 
> Gruß,
> Claus
> 
> Am 18. Dezember 2016 um 22:58:16 +01:00, hat Matthias Behr  
> geschrieben:
>> Hallo,
>> 
>> das Problem tritt mit den nicht blockierenden S0 Zähler nicht auf. Ich habe 
>> über die Problematik auch länge nachgedacht, aber kam zu dem Entschluss, 
>> nicht Aggmode zu ändern, sondern auf nicht blockierende Zähler umzustellen 
>> (z.B. per gpio mit sendzero).
>> Dann bekommst du ziemlich genaue Daten und es skaliert viel besser für 
>> hochfrequente (bis paar hundert kHz) Signale.
>> 
>> Am 18.12.2016 um 21:38 schrieb > <mailto:m...@claus-beckenbauer.de>> > <mailto:m...@claus-beckenbauer.de>>:
>> 
>> Hallo Zusammen,
>>  
>> hier eine kurzer Auszug aus dem LogFile, der das Verhalten belegt und auch 
>> erklärt. Ich bin mir nur nicht sicher ob es ein Bug oder doch en Feature 
>> ist. Zur Erinnerung: aggtime ist auf 180 Sekunden konfiguriert.
>>  
>> $ cat vzlogger.log | grep RESULT
>> [Dec 18 16:18:18][SUM]  RESULT 1.00 @ 1482074297367
>> [Dec 18 16:26:24][SUM]  RESULT 1.00 @ 1482074784160
>> [Dec 18 16:34:30][SUM]  RESULT 1.00 @ 1482075269620
>> [Dec 18 16:42:44][SUM]  RESULT 1.00 @ 1482075763855
>> [Dec 18 16:50:54][SUM]  RESULT 1.00 @ 1482076253440
>> [Dec 18 16:59:04][SUM]  RESULT 1.00 @ 1482076743708
>> [Dec 18 17:07:11][SUM]  RESULT 1.00 @ 1482077230993
>> [Dec 18 17:15:14][SUM]  RESULT 1.00 @ 1482077713184
>> [Dec 18 17:23:16][SUM]  RESULT 1.00 @ 1482078195362
>> [Dec 18 17:30:23][SUM]  RESULT 1.00 @ 1482078623062
>> [Dec 18 17:31:23][SUM]  RESULT 1.00 @ 1482078682365
>> [Dec 18 17:32:12][SUM]  RESULT 1.00 @ 1482078731995
>> [Dec 18 17:33:38][SUM]  RESULT 1.00 @ 1482078817905
>> [Dec 18 17:35:01][SUM]  RESULT 1.00 @ 1482078901141
>> [Dec 18 17:35:57][SUM]  RESULT 1.00 @ 1482078957060
>> [Dec 18 17:36:36][SUM]  RESULT 1.00 @ 1482078995379
>> [Dec 18 17:37:07][SUM]  RESULT 1.00 @ 1482079026684
>> [Dec 18 17:38:05][SUM]  RESULT 1.00 @ 1482079084316
>> [Dec 18 17:38:55][SUM]  RESULT 1.00 @ 1482079134720
>> [Dec 18 17:39:44][SUM]  RESULT 1.00 @ 1482079183307
>> [Dec 18 17:40:27][SUM]  RESULT 1.00 @ 1482079226809
>> [Dec 18 17:41:11][SUM]  RESULT 1.00 @ 1482079271028
>> [Dec 18 17:41:53][SUM]  RESULT 1.00 @ 1482079312363
>> [Dec 18 17:42:31][SUM]  RESULT 1.00 @ 1482079351137
>> [Dec 18 17:43:10][SUM]  RESULT 1.00 @ 1482079389844
>> [Dec 18 17:43:50][SUM]  RESULT 1.00 @ 1482079430045
>> [Dec 18 17:44:30][SUM]  RESULT 1.00 @ 1482079470132
>> [Dec 18 17:45:10][SUM]  RESULT 1.00 @ 1482079509486
>> [Dec 18 17:45:49][SUM]  RESULT 1.00 @ 1482079548973
>> [Dec 18 17:46:29][SUM]  RESULT 1.00 @ 1482079588680
>> [Dec 18 17:47:09][SUM]  RESULT 1.00 @ 1482079628743
>> [Dec 18 17:47:50][SUM]  RESULT 1.00 @ 1482079669334
>> [Dec 18 17:48:34][SUM]  RESULT 1.00 @ 1482079713419
>> [Dec 18 17:49:19][SUM]  RESULT 1.00 @ 1482079758291
>> [Dec 18 17:50:02][SUM]  RESULT 1.00 @ 1482079801734
>> [Dec 18 17:50:45][SUM]  RESULT 1.00 @ 1482079844569
>> [Dec 18 17:51:28][SUM]  RESULT 1.00 @ 1482079887909
>> [Dec 18 17:52:11][SUM]  RESULT 1.00 @ 1482079931165
>> [Dec 18 17:52:54][SUM]  RESULT 1.00 @ 1482079973669
>> [Dec 18 17:53:38][SUM]  RESULT 1.00 @ 1482080017676
>> [Dec 18 17:56:18][SUM]  RESULT 3.00 @ 1482080177836
>> [Dec 18 17:59:27][SUM]  RESULT 3.00 @ 1482080366835
>> [Dec 18 18:02:54][SUM]  RESULT 3.00 @ 1482080573948
>> [Dec 18 18:05:13][SUM]  RESULT 2.00 @ 1482080712362
>> [Dec 18 18:08:41][SUM]  RESULT 3.00 @ 1482080920902
>>  
>> Aus dem Log wird ersichtlich, dass die gehäuften Logeinträge immer dann 
>> Zustande kommen, wenn die Last von wen

Re: [vz-users] vzlogger s0 protocol + aggtime funktioniertsporadisch nicht wie erwartet

[Matthias Behr]

Hallo,

das Problem tritt mit den nicht blockierenden S0 Zähler nicht auf. Ich habe 
über die Problematik auch länge nachgedacht, aber kam zu dem Entschluss, nicht 
Aggmode zu ändern, sondern auf nicht blockierende Zähler umzustellen (z.B. per 
gpio mit sendzero).
Dann bekommst du ziemlich genaue Daten und es skaliert viel besser für 
hochfrequente (bis paar hundert kHz) Signale.

> Am 18.12.2016 um 21:38 schrieb  
> :
> 
> Hallo Zusammen,
>  
> hier eine kurzer Auszug aus dem LogFile, der das Verhalten belegt und auch 
> erklärt. Ich bin mir nur nicht sicher ob es ein Bug oder doch en Feature ist. 
> Zur Erinnerung: aggtime ist auf 180 Sekunden konfiguriert.
>  
> $ cat vzlogger.log | grep RESULT
> [Dec 18 16:18:18][SUM]  RESULT 1.00 @ 1482074297367
> [Dec 18 16:26:24][SUM]  RESULT 1.00 @ 1482074784160
> [Dec 18 16:34:30][SUM]  RESULT 1.00 @ 1482075269620
> [Dec 18 16:42:44][SUM]  RESULT 1.00 @ 1482075763855
> [Dec 18 16:50:54][SUM]  RESULT 1.00 @ 1482076253440
> [Dec 18 16:59:04][SUM]  RESULT 1.00 @ 1482076743708
> [Dec 18 17:07:11][SUM]  RESULT 1.00 @ 1482077230993
> [Dec 18 17:15:14][SUM]  RESULT 1.00 @ 1482077713184
> [Dec 18 17:23:16][SUM]  RESULT 1.00 @ 1482078195362
> [Dec 18 17:30:23][SUM]  RESULT 1.00 @ 1482078623062
> [Dec 18 17:31:23][SUM]  RESULT 1.00 @ 1482078682365
> [Dec 18 17:32:12][SUM]  RESULT 1.00 @ 1482078731995
> [Dec 18 17:33:38][SUM]  RESULT 1.00 @ 1482078817905
> [Dec 18 17:35:01][SUM]  RESULT 1.00 @ 1482078901141
> [Dec 18 17:35:57][SUM]  RESULT 1.00 @ 1482078957060
> [Dec 18 17:36:36][SUM]  RESULT 1.00 @ 1482078995379
> [Dec 18 17:37:07][SUM]  RESULT 1.00 @ 1482079026684
> [Dec 18 17:38:05][SUM]  RESULT 1.00 @ 1482079084316
> [Dec 18 17:38:55][SUM]  RESULT 1.00 @ 1482079134720
> [Dec 18 17:39:44][SUM]  RESULT 1.00 @ 1482079183307
> [Dec 18 17:40:27][SUM]  RESULT 1.00 @ 1482079226809
> [Dec 18 17:41:11][SUM]  RESULT 1.00 @ 1482079271028
> [Dec 18 17:41:53][SUM]  RESULT 1.00 @ 1482079312363
> [Dec 18 17:42:31][SUM]  RESULT 1.00 @ 1482079351137
> [Dec 18 17:43:10][SUM]  RESULT 1.00 @ 1482079389844
> [Dec 18 17:43:50][SUM]  RESULT 1.00 @ 1482079430045
> [Dec 18 17:44:30][SUM]  RESULT 1.00 @ 1482079470132
> [Dec 18 17:45:10][SUM]  RESULT 1.00 @ 1482079509486
> [Dec 18 17:45:49][SUM]  RESULT 1.00 @ 1482079548973
> [Dec 18 17:46:29][SUM]  RESULT 1.00 @ 1482079588680
> [Dec 18 17:47:09][SUM]  RESULT 1.00 @ 1482079628743
> [Dec 18 17:47:50][SUM]  RESULT 1.00 @ 1482079669334
> [Dec 18 17:48:34][SUM]  RESULT 1.00 @ 1482079713419
> [Dec 18 17:49:19][SUM]  RESULT 1.00 @ 1482079758291
> [Dec 18 17:50:02][SUM]  RESULT 1.00 @ 1482079801734
> [Dec 18 17:50:45][SUM]  RESULT 1.00 @ 1482079844569
> [Dec 18 17:51:28][SUM]  RESULT 1.00 @ 1482079887909
> [Dec 18 17:52:11][SUM]  RESULT 1.00 @ 1482079931165
> [Dec 18 17:52:54][SUM]  RESULT 1.00 @ 1482079973669
> [Dec 18 17:53:38][SUM]  RESULT 1.00 @ 1482080017676
> [Dec 18 17:56:18][SUM]  RESULT 3.00 @ 1482080177836
> [Dec 18 17:59:27][SUM]  RESULT 3.00 @ 1482080366835
> [Dec 18 18:02:54][SUM]  RESULT 3.00 @ 1482080573948
> [Dec 18 18:05:13][SUM]  RESULT 2.00 @ 1482080712362
> [Dec 18 18:08:41][SUM]  RESULT 3.00 @ 1482080920902
>  
> Aus dem Log wird ersichtlich, dass die gehäuften Logeinträge immer dann 
> Zustande kommen, wenn die Last von weniger als ein S0 Impuls innerhalb von 
> 180 s auf mind. 1 S0 Impuls innerhalb von 180 s steigt.
>  
> Nach einem Blick in die Sourcen von vzlogger, insb. threads.cpp ist das 
> Verhalten auch erklärbar. Ob das so gewollt ist, kann der Entwickler 
> beurteilen. Für mich kam es erst einmal überraschend.
>  
> Die verantwortliche Stelle im Code stammt aus der Funktion reading_thread().
>  
> aggIntEnd = time(NULL);
> do { /* start thread main loop */
> aggIntEnd += mtr->aggtime(); /* end of this aggregation period */
> do { /* aggregate loop */
> /* fetch readings from meter and calculate delta */
> n = mtr->read(rds, details->max_readings); // blocking call 
> bei S0 Protokol
>  
> // nicht relevanter Code gelöscht
>  
> } while((mtr->aggtime() > 0) && (time(NULL) < aggIntEnd)); /* 
> default aggtime is -1 */
>  
> Ein Blick in mein angehängtes Logfile zeigt, dass mtr->read in Situation mit 
> sehr wenig Last deutlich länger als die konfigurierte aggtime blockiert 
> (teilweise bis zu 15 Minuten).
> Das führt nun dazu, dass aggIntEnd sehr weit in der Vergangenheit liegt. Die 
> nächste Berechnung von aggIntEnd += mtr->aggtime() führt zu einem Wert, der 
> immer noch weit in der Vergangenheit liegt, womit die Abbruchbedingung der 
> Aggregation loop weiterhin erfüllt ist.
>  
> Ist dieses Verhalten absichtlich so implementiert? Immerhin hat man dadurch 
> über den kompletten Messzeitraum durchschnittlich immer einen Wert innerhalt 
> von aggt

Re: [vz-users] Middlware und vzlogger.conf

[Matthias Behr]

hast du mal ein vzlogger.log geschickt? >90% CPU Last ist nicht normal (auch 
nicht auf RPI A).

> Am 13.12.2016 um 18:00 schrieb Heiko W. :
> 
> Hallo Frank, 
> 
> schein nicht besser zu werden .. 
> 
> aber Vorsicht ist ein Pi A, und nicht Übertaktet usw.
> 
> 
> 
> Mit freundlichen Grüßen
> Heiko W.
> 
> Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich 
> geschützte Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
> erhalten haben,
> informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist 
> nicht gestattet.
> 
> 
> Von: volkszaehler-users  im 
> Auftrag von Frank Richter 
> Gesendet: Dienstag, 13. Dezember 2016 17:35
> An: volkszaehler.org - users
> Betreff: Re: [vz-users] Middlware und vzlogger.conf
>  
> Dann gehen mir leider langsam die Ideen aus...
> Bin kein Linux-Profi, aber die 92,8% CPU für vzlogger sehen ungesund aus.
> Macht er das auch, wenn du ihn stoppst und neu startest? Das geht mit:
> sudo systemctl stop vzlogger
> sudo systemctl start vzlogger
> 
> Gruß
> Frank
> 
> Am 13. Dezember 2016 um 17:17 schrieb Heiko W.  >:
> Hallo 
> 
> Verwendest du das aktuelle VZ-Image oder was anderes? 
> Image ist das 'aktuelle' von der Seite, es ist auf dem Pi nur das Image 
> installiert sonst nichts.
> 
> Montierst du den Kopf richtig herum (Kabel unten)?
> Ja, die Kabel der USB Adapter hängen nach unten.
> 
> Läuft auf dem Pi irgendwas, was die Daten der seriellen Schnittstelle abfängt?
> Nein!
> 
> Wie startest du vzlogger?
> startet sich selber, ich habe nichts gemacht
> 
> 
> 
> 
> Mit freundlichen Grüßen
> Heiko W.
> 
> Von: volkszaehler-users  > im Auftrag von 
> Frank Richter mailto:frank.richte...@gmail.com>>
> Gesendet: Dienstag, 13. Dezember 2016 17:10
> 
> An: volkszaehler.org  - users
> Betreff: Re: [vz-users] Middlware und vzlogger.conf
>  
> Dann kommt aber nix davon bei vzlogger an.
> Montierst du den Kopf richtig herum (Kabel unten)?
> Verwendest du das aktuelle VZ-Image oder was anderes? 
> Läuft auf dem Pi irgendwas, was die Daten der seriellen Schnittstelle abfängt?
> Wie startest du vzlogger?
> Gruß
> Frank
> Am 13.12.2016 17:02 schrieb "Heiko W."  >:
> Hallo 
> 
> beide Zähler blinken (ziemlich gleichmäßig) aus der rechten LED
> 
> hätte mich aber auch gewundert wenn die Zähler sich in den 3 Jahren als ich 
> den Volkszähler nicht genutzt habe 'verstellt' hätten.
> 
> 
> Mit freundlichen Grüßen
> Heiko W.
> 
> Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich 
> geschützte Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
> erhalten haben,
> informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist 
> nicht gestattet.
> 
> 
> Von: volkszaehler-users  > im Auftrag von 
> Frank Richter mailto:frank.richte...@gmail.com>>
> Gesendet: Dienstag, 13. Dezember 2016 16:52
> An: volkszaehler.org  - users
> Betreff: Re: [vz-users] Middlware und vzlogger.conf
>  
> Du sollst nicht die Adapter testen, sondern deine Zähler...
> Am 13.12.2016 16:47 schrieb "Heiko W."  >:
> Hallo 
> 
> die 'Anlage' (Pi) ist schon vor ca. 3 Jahren gelaufen mit genau den USB (Udo) 
> IR Adaptern, 
> 'damals' konnte ich das fast 1 zu 1 vom HowTo 
> http://wiki.volkszaehler.org/howto/emh_pv-anlage 
>  nehmen und das hat 
> geklappt.
> zz finde ich leider kein Howto das einem Noob wie mir das einigermaßen nahe 
> bringt
> 
> leider komm ich überhaupt nicht mit dem 'neuen' BS klar und auch die config 
> geht nicht (so wie ich das will). 
> 
> Ich denke die Zähler funktionieren, gingen ja 'damals' auch 
> USB Adapter hab ich mit HandyCam probiert, kann es aber gern noch mal mit ner 
> 'normalen' Cam testen. 
> 
> 
> 
> Mit freundlichen Grüßen
> Heiko W.
> 
> 
> Von: volkszaehler-users  > im Auftrag von 
> Udo1 mailto:u...@gmx.net>>
> Gesendet: Dienstag, 13. Dezember 2016 08:50
> An: volkszaehler-users@demo.volkszaehler.org 
> 
> Betreff: Re: [vz-users] Middlware und vzlogger.conf
>  
> Am 09.12.2016 um 16:18 schrieb Heiko W.:
> >
> > nach langer zeit ohne Pi wollte ich den nun wieder mal anwerfen und 
> > schauen was meine Haus so alles verbraucht usw.
> >
> >
> Hat das denn schon jemals funktioniert?
> 
> > gerade nachgeschaut.
> >
> > die Dioden sind beide 'dunkel', scheint also als werden die nicht 
> > erkannt/angesteuert
> >
> Womit nachgeschaut?
> IR-Dioden kann man nicht mit bloßem Auge leuchten sehen.
> Vorsi

Re: [vz-users] NT und HT anzeigen / zählen lassen

[Matthias Behr]

du könntest den
gpio_dir
dafür missbrauchen.
Z.B. per cronjob einfach den gpio umschalten.

vzlogger liefert die Werte dann als
Impulse_neg


> Am 12.12.2016 um 12:33 schrieb Markus Reiß :
> 
> Hallo,
> bin ganz neu hier.
> Ich möchte gerne den Volkszähler meine Zählerdaten in Nt und Ht anzeigen 
> lassen.
> Lese die Impulse über GPIO4 an meinem Zähler mit einem Fototransistor aus.
> Das ganze funktioniert auch ganz gut.
> S0 impulese kommen an 1 imp/KWh
> das ganze möchte ich nun der übersichtshalber auf NT und HT trennen Nt 
> startet um ca. 22:00 bis 6:00 Uhr morgens.
> Wie kann ich das bewerkstelligen ?
> Anbei meine vzlogger.cfg:
> {
>   "retry": 0,
>   "daemon": true,
>   "verbosity": 0,
>   "log": "/tmp/vzlogger.log",
>   "local": {
> "enabled": false,
> "port": 8080,
> "index": false,
> "timeout": 0,
> "buffer": 0
>   },
>   "meters": [
> {
>   "enabled": true,
>   "allowskip": false,
>   "interval": -1,
>   "aggtime": -1,
>   "aggfixedinterval": false,
>   "channels": [
> {
>   "uuid": "f",
>   "identifier": "Impulse",
>   "api": "volkszaehler",
>   "middleware": "http://Heimnetz_IP/middleware.php";,
>   "aggmode": "none",
>   "duplicates": 0
> }
>   ],
>   "protocol": "S0",
>   "gpio": 4,
>   "configureGPIO": true,
>   "debounce_delay":0
> }
>   ]
> }
> 
> vielen dank schon mal für eueren Imput
>  
> Mfg
> Markus Reiß

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Falls die Mitte nicht erkannt wird, siehst du gar keinen Kreis.
Autocenter müsste immer aktiv sein, d.h. du müsstest dann bei der Suche mehrere 
Kreise sehen.

Allerdings sehe ich gerade, dass falls keine Mitte erkannt wird, keine 
Autocenter Suche mehr stattfindet.

Ich glaube bei dir, könnte es daran liegen, dass da paar dunkle Flecken um die 
Mitte herum sind. Du könntest mal den rot-Ton intensivieren
(per kernelColorString in der Config) oder im Source mal
static const unsigned int RED_COLOR_LIMIT = 0x8000;
auf einen kleineren Wert setzen.

> Am 07.11.2016 um 18:48 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> am Montag, 7. November 2016 um 18:38 hast du geschrieben:
>> ja, heißt, dass in der Mitte des blauen Kreises nichts rotes
>> erkannt wird. Ist ein Plausi-Check. Eigentlich eher ein Zeichen,
>> dass das Bild komplett daneben liegt.
> 
> Hatte ich einmal als ich die falsch Konfig aktiv hatte. Da wars aber
> wirklich total daneben, nicht so wie jetzt.
> 
>> Habe dann „autocenter“ dafür eingeführt (s.u.) und den
>> Plausi-Check, dass zumindest die Mitte am Anfang noch was rotes hat.
> 
> Kanne sein das dann im Debug-Bild mehrere blaue Kreise auftauchen?
> Oder muss ich das erst aktivieren?
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

ja, heißt, dass in der Mitte des blauen Kreises nichts rotes erkannt wird. Ist 
ein Plausi-Check. Eigentlich eher ein Zeichen, dass das Bild komplett daneben 
liegt. (Ich hatte bei mir Probleme, dass die Kamera sich jeden Tag um paar mm 
verstellt hatte.

Habe dann „autocenter“ dafür eingeführt (s.u.) und den Plausi-Check, dass 
zumindest die Mitte am Anfang noch was rotes hat.



if (b.autocenter){
// autocenter: check distance 
from center at the detected
// needle +90/+180/+270 degrees 
to the circle
// adjust ac_dx/ac_dy so that 
the distances are equal:
// if ac_dx/ac_dy changes >+/-1 
then redo calc a few times:
int det_r[3];
int ind=0;
for (int deg = degAvg+90; deg < 
degAvg+360; deg+=90){
int opx=-1 ,opy=-1;
int r;
for (r=b.cr-1; r>0; 
--r){
int px = 
cx+r*sin(deg * PIrad);
int py = 
cy-r*cos(deg * PIrad);
if (px!=opx || 
py!=opy) {

unsigned int c=0;

(void)pixGetPixel(image, px, py, &c);
if 
(c>RED_COLOR_LIMIT) {

break;
}
opx=px;
opy=py;
}
}
if (r<=0) break;
det_r[ind++] = r;
print(log_debug, 
"scanning at %d: r=%d", "ocr", deg, r);
}
if (ind<3){
print(log_error, 
"couldn't autocenter!", "ocr");

 
> Am 07.11.2016 um 10:41 schrieb Daniel Lauckner :
> 
> Hallo,
> 
> 
> "recognizerNeedle center not red!"
> WTF?
> 
> 
> [Nov 07 09:42:15][ocr]  MeterOCR::read: 32, 32
> [Nov 07 09:42:15][ocr]  got inotify_event 8
> [Nov 07 09:42:16][ocr]  image = 1280 x 960 with 32 bits each pixel
> [Nov 07 09:42:16][ocr]  Cropping image to (782,334)-(922,474)
> [Nov 07 09:42:16][ocr]  scanning at 272: r=18
> [Nov 07 09:42:16][ocr]  scanning at 362: r=18
> [Nov 07 09:42:16][ocr]  scanning at 452: r=18
> [Nov 07 09:42:16][ocr]  ndx=-0.00 ndy=-0.00
> [Nov 07 09:42:16][ocr]  ndx=0.00 ndy=-0.00
> [Nov 07 09:42:16][ocr]  Cropping image to (716,469)-(856,609)
> [Nov 07 09:42:16][ocr]  scanning at 81: r=17
> [Nov 07 09:42:16][ocr]  scanning at 171: r=17
> [Nov 07 09:42:16][ocr]  scanning at 261: r=17
> [Nov 07 09:42:16][ocr]  ndx=0.00 ndy=-0.00
> [Nov 07 09:42:16][ocr]  ndx=0.00 ndy=0.00
> [Nov 07 09:42:16][ocr]  returning rounded up: smaller=0.00 nr=0 
> fnr=9.75
> 
> [Nov 07 09:42:16][ocr]  Cropping image to (588,521)-(728,661)
> [Nov 07 09:42:16][ocr]  recognizerNeedle center not red!
> 
> [Nov 07 09:42:16][ocr]  Cropping image to (423,461)-(563,601)
> [Nov 07 09:42:16][ocr]  recognizerNeedle center not red!
> 
> [Nov 07 09:42:18][ocr]  returning: id <8-0:3.2.0> value 
> [Nov 07 09:42:18][mtr0] Got 0 new readings from meter:
> [Nov 07 09:42:18][chn0] ==> number of tuples: 0
> [Nov 07 09:42:18][chn0] JSON request body is null. Nothing to send now.
> [Nov 07 09:42:18][mtr0] Next reading in 20 seconds
> [Nov 07 09:42:38][ocr]  MeterOCR::read: 32, 32
> [Nov 07 09:42:38][mtr0] Got 0 new readings from meter:
> [Nov 07 09:42:38][chn0] ==> number of tuples: 0
> [Nov 07 09:42:38][chn0] JSON request body is null. Nothing to send now.
> [Nov 07 09:42:38][mtr0] Next reading in 20 seconds
> 
> www.jahp.de/picsextern/volkszaehler/wasserzaehler.png_debug.jpg
> 
> Nachdem ich etwas Wasser gezapft hatte war der Fehler immernoch. An
> beiden Zeigern. Ich hab die Mitte dann um 1 Pixel verschoben.
> 
> 
> Aktuell geht auch der zweite Zeiger wieder ein Digit daneben. Wobei
> ich das daran festmache das wieder eine der Zahlen im Weg ist.
> 
> Ich werde versuchen mehr Bilder zu sammeln um

Re: [vz-users] Schell EZZ1 / Köhler AEL.MF.07 auslesen

[Matthias Behr]

hmm. D.h. der Zaehler antwortet jedes Mal nur mit seiner Ident?

Kann dir nur raten noch mal mit baudrate_change_delay zu spielen (von 0 bis 
z.B. 1500).
Was benutzt du für einen seriellen Port? (USB auf Ser?)


> Am 06.11.2016 um 21:09 schrieb m.guetl...@gmx.de:
> 
> 
> Am 06.11.2016 um 20:41 schrieb Matthias Behr:
>> versuch mal unterschiedliche Werte für baudrate_change_delay (200, 300, 400)
>>> Am 06.11.2016 um 20:40 schrieb m.guetl...@gmx.de:
>>> 
>>> 
>>> Am 06.11.2016 um 20:33 schrieb Matthias Behr:
>>>> mach mal
>>>> daemon: true
>>>> baudrate_change_delay auf 100ms
>>>> 
>>>> 
>>>>> Am 06.11.2016 um 20:31 schrieb m.guetl...@gmx.de:
>>>>> 
>>>>> 
>>>>> 
>>>>> Am 06.11.2016 um 20:28 schrieb Matthias Behr:
>>>>>> schick mal deine Config
>>>>>> 
>>>>>>> Am 06.11.2016 um 20:27 schrieb m.guetl...@gmx.de:
>>>>>>> 
>>>>>>> 
>>>>>>> Am 06.11.2016 um 20:09 schrieb Matthias Behr:
>>>>>>>> und beim nächsten Read? was passiert wenn du vzlogger laufen lässt? 
>>>>>>>> antwortet der Zähler noch mal oder bleibt er stumm?
>>>>>>>> 
>>>>>>>>> Am 06.11.2016 um 18:15 schrieb m.guetl...@gmx.de:
>>>>>>>>> 
>>>>>>>>> Am 06.11.2016 um 17:54 schrieb Matthias Behr:
>>>>>>>>>> Schickst mal ein „dump_file“?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Am 06.11.2016 um 17:52 schrieb m.guetl...@gmx.de:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Am 06.11.2016 um 17:41 schrieb Matthias Behr:
>>>>>>>>>>>> Versuch mal ackseq: auto
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> Am 06.11.2016 um 17:39 schrieb m.guetl...@gmx.de:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Am 06.11.2016 um 15:44 schrieb Matthias Behr:
>>>>>>>>>>>>>> Wie sprichst du den Zähler denn an? vzlogger?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Welche Baudrate nutzt du?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Falls vzlogger kannst du mal ein „dump_file“ erstellen und 
>>>>>>>>>>>>>> schicken?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Am 06.11.2016 um 12:05 schrieb m.guetl...@gmx.de:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hallo zusammen,
>>>>>>>>>>>>>>> ich wurde in folgendem Thread an diese Mailingliste verwiesen: 
>>>>>>>>>>>>>>> http://www.photovoltaikforum.com/volkszaehler-org-f131/schell-ezz1-t114836.html
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Mein Problem besteht darin, dass ich die Zählerstände eines 
>>>>>>>>>>>>>>> "Schell EZZ1/Köhler AEL.MF.07" (Schell ist wohl der deutsche 
>>>>>>>>>>>>>>> Vermarkter des AEL.MF.07) Stromzählers über die 
>>>>>>>>>>>>>>> D0-Schnittstelle auslesen möchte. Dieser sendet keine 
>>>>>>>>>>>>>>> periodischen Statusinfos aus.
>>>>>>>>>>>>>>> Grundsätzlich funktioniert die Kommunikation, wenn ich sie 
>>>>>>>>>>>>>>> anstoße:
>>>>>>>>>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>>>>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>>>>>>>>>> <== "06 30 30 30 0D 0A"
>>>>>>>>>>>>>>> Ende
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Für den Programmiermodus:
>>>>>>>&g

Re: [vz-users] Schell EZZ1 / Köhler AEL.MF.07 auslesen

[Matthias Behr]

versuch mal unterschiedliche Werte für baudrate_change_delay (200, 300, 400)
> Am 06.11.2016 um 20:40 schrieb m.guetl...@gmx.de:
> 
> 
> Am 06.11.2016 um 20:33 schrieb Matthias Behr:
>> mach mal
>> daemon: true
>> baudrate_change_delay auf 100ms
>> 
>> 
>>> Am 06.11.2016 um 20:31 schrieb m.guetl...@gmx.de:
>>> 
>>> 
>>> 
>>> Am 06.11.2016 um 20:28 schrieb Matthias Behr:
>>>> schick mal deine Config
>>>> 
>>>>> Am 06.11.2016 um 20:27 schrieb m.guetl...@gmx.de:
>>>>> 
>>>>> 
>>>>> Am 06.11.2016 um 20:09 schrieb Matthias Behr:
>>>>>> und beim nächsten Read? was passiert wenn du vzlogger laufen lässt? 
>>>>>> antwortet der Zähler noch mal oder bleibt er stumm?
>>>>>> 
>>>>>>> Am 06.11.2016 um 18:15 schrieb m.guetl...@gmx.de:
>>>>>>> 
>>>>>>> Am 06.11.2016 um 17:54 schrieb Matthias Behr:
>>>>>>>> Schickst mal ein „dump_file“?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Am 06.11.2016 um 17:52 schrieb m.guetl...@gmx.de:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Am 06.11.2016 um 17:41 schrieb Matthias Behr:
>>>>>>>>>> Versuch mal ackseq: auto
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Am 06.11.2016 um 17:39 schrieb m.guetl...@gmx.de:
>>>>>>>>>>> 
>>>>>>>>>>> Am 06.11.2016 um 15:44 schrieb Matthias Behr:
>>>>>>>>>>>> Wie sprichst du den Zähler denn an? vzlogger?
>>>>>>>>>>>> 
>>>>>>>>>>>> Welche Baudrate nutzt du?
>>>>>>>>>>>> 
>>>>>>>>>>>> Falls vzlogger kannst du mal ein „dump_file“ erstellen und 
>>>>>>>>>>>> schicken?
>>>>>>>>>>>> 
>>>>>>>>>>>>> Am 06.11.2016 um 12:05 schrieb m.guetl...@gmx.de:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hallo zusammen,
>>>>>>>>>>>>> ich wurde in folgendem Thread an diese Mailingliste verwiesen: 
>>>>>>>>>>>>> http://www.photovoltaikforum.com/volkszaehler-org-f131/schell-ezz1-t114836.html
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Mein Problem besteht darin, dass ich die Zählerstände eines 
>>>>>>>>>>>>> "Schell EZZ1/Köhler AEL.MF.07" (Schell ist wohl der deutsche 
>>>>>>>>>>>>> Vermarkter des AEL.MF.07) Stromzählers über die D0-Schnittstelle 
>>>>>>>>>>>>> auslesen möchte. Dieser sendet keine periodischen Statusinfos aus.
>>>>>>>>>>>>> Grundsätzlich funktioniert die Kommunikation, wenn ich sie 
>>>>>>>>>>>>> anstoße:
>>>>>>>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>>>>>>>> <== "06 30 30 30 0D 0A"
>>>>>>>>>>>>> Ende
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Für den Programmiermodus:
>>>>>>>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>>>>>>>> <== "06 30 30 __31__ 0D 0A"
>>>>>>>>>>>>> ==> "06"
>>>>>>>>>>>>> Ende und keine Reaktion auf Befehle wie unter 
>>>>>>>>>>>>> http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
>>>>>>>>>>>>>  genannt.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Nach dieser Initialisierungssequenz ist also Schluss und ich 
>>>>>>>>>>>>> erhalte keine Informationen über den Stromverbrauch. Kennt jemand 

Re: [vz-users] Schell EZZ1 / Köhler AEL.MF.07 auslesen

[Matthias Behr]

mach mal
daemon: true
baudrate_change_delay auf 100ms


> Am 06.11.2016 um 20:31 schrieb m.guetl...@gmx.de:
> 
> 
> 
> Am 06.11.2016 um 20:28 schrieb Matthias Behr:
>> schick mal deine Config
>> 
>>> Am 06.11.2016 um 20:27 schrieb m.guetl...@gmx.de:
>>> 
>>> 
>>> Am 06.11.2016 um 20:09 schrieb Matthias Behr:
>>>> und beim nächsten Read? was passiert wenn du vzlogger laufen lässt? 
>>>> antwortet der Zähler noch mal oder bleibt er stumm?
>>>> 
>>>>> Am 06.11.2016 um 18:15 schrieb m.guetl...@gmx.de:
>>>>> 
>>>>> Am 06.11.2016 um 17:54 schrieb Matthias Behr:
>>>>>> Schickst mal ein „dump_file“?
>>>>>> 
>>>>>> 
>>>>>>> Am 06.11.2016 um 17:52 schrieb m.guetl...@gmx.de:
>>>>>>> 
>>>>>>> 
>>>>>>> Am 06.11.2016 um 17:41 schrieb Matthias Behr:
>>>>>>>> Versuch mal ackseq: auto
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Am 06.11.2016 um 17:39 schrieb m.guetl...@gmx.de:
>>>>>>>>> 
>>>>>>>>> Am 06.11.2016 um 15:44 schrieb Matthias Behr:
>>>>>>>>>> Wie sprichst du den Zähler denn an? vzlogger?
>>>>>>>>>> 
>>>>>>>>>> Welche Baudrate nutzt du?
>>>>>>>>>> 
>>>>>>>>>> Falls vzlogger kannst du mal ein „dump_file“ erstellen und schicken?
>>>>>>>>>> 
>>>>>>>>>>> Am 06.11.2016 um 12:05 schrieb m.guetl...@gmx.de:
>>>>>>>>>>> 
>>>>>>>>>>> Hallo zusammen,
>>>>>>>>>>> ich wurde in folgendem Thread an diese Mailingliste verwiesen: 
>>>>>>>>>>> http://www.photovoltaikforum.com/volkszaehler-org-f131/schell-ezz1-t114836.html
>>>>>>>>>>> 
>>>>>>>>>>> Mein Problem besteht darin, dass ich die Zählerstände eines "Schell 
>>>>>>>>>>> EZZ1/Köhler AEL.MF.07" (Schell ist wohl der deutsche Vermarkter des 
>>>>>>>>>>> AEL.MF.07) Stromzählers über die D0-Schnittstelle auslesen möchte. 
>>>>>>>>>>> Dieser sendet keine periodischen Statusinfos aus.
>>>>>>>>>>> Grundsätzlich funktioniert die Kommunikation, wenn ich sie anstoße:
>>>>>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>>>>>> <== "06 30 30 30 0D 0A"
>>>>>>>>>>> Ende
>>>>>>>>>>> 
>>>>>>>>>>> Für den Programmiermodus:
>>>>>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>>>>>> <== "06 30 30 __31__ 0D 0A"
>>>>>>>>>>> ==> "06"
>>>>>>>>>>> Ende und keine Reaktion auf Befehle wie unter 
>>>>>>>>>>> http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
>>>>>>>>>>>  genannt.
>>>>>>>>>>> 
>>>>>>>>>>> Nach dieser Initialisierungssequenz ist also Schluss und ich 
>>>>>>>>>>> erhalte keine Informationen über den Stromverbrauch. Kennt jemand 
>>>>>>>>>>> diesen Zähler und kann mir weiterhelfen? Ich habe mich auch schon 
>>>>>>>>>>> an den Hersteller gewandt, allerdings noch keine Antwort erhalten.
>>>>>>>>>>> 
>>>>>>>>>>> Mit freundlichen Grüßen
>>>>>>>>>>> Max
>>>>>>>>>> Gruß
>>>>>>>>>> 
>>>>>>>>>> Matthias
>>>>>>>>>> 
>>>>>>>>> Direkt im Terminal mit 'echo "xyz" > /dev/ttyUSB0' und 'cat 
>>>>>>>>> /dev/ttyUSB0' in einem anderen Terminal. Ich kommuniziere mit einer 
>>>>>>>>> Baudrate von 30

Re: [vz-users] Schell EZZ1 / Köhler AEL.MF.07 auslesen

[Matthias Behr]

schick mal deine Config

> Am 06.11.2016 um 20:27 schrieb m.guetl...@gmx.de:
> 
> 
> Am 06.11.2016 um 20:09 schrieb Matthias Behr:
>> und beim nächsten Read? was passiert wenn du vzlogger laufen lässt? 
>> antwortet der Zähler noch mal oder bleibt er stumm?
>> 
>>> Am 06.11.2016 um 18:15 schrieb m.guetl...@gmx.de:
>>> 
>>> Am 06.11.2016 um 17:54 schrieb Matthias Behr:
>>>> Schickst mal ein „dump_file“?
>>>> 
>>>> 
>>>>> Am 06.11.2016 um 17:52 schrieb m.guetl...@gmx.de:
>>>>> 
>>>>> 
>>>>> Am 06.11.2016 um 17:41 schrieb Matthias Behr:
>>>>>> Versuch mal ackseq: auto
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Am 06.11.2016 um 17:39 schrieb m.guetl...@gmx.de:
>>>>>>> 
>>>>>>> Am 06.11.2016 um 15:44 schrieb Matthias Behr:
>>>>>>>> Wie sprichst du den Zähler denn an? vzlogger?
>>>>>>>> 
>>>>>>>> Welche Baudrate nutzt du?
>>>>>>>> 
>>>>>>>> Falls vzlogger kannst du mal ein „dump_file“ erstellen und schicken?
>>>>>>>> 
>>>>>>>>> Am 06.11.2016 um 12:05 schrieb m.guetl...@gmx.de:
>>>>>>>>> 
>>>>>>>>> Hallo zusammen,
>>>>>>>>> ich wurde in folgendem Thread an diese Mailingliste verwiesen: 
>>>>>>>>> http://www.photovoltaikforum.com/volkszaehler-org-f131/schell-ezz1-t114836.html
>>>>>>>>> 
>>>>>>>>> Mein Problem besteht darin, dass ich die Zählerstände eines "Schell 
>>>>>>>>> EZZ1/Köhler AEL.MF.07" (Schell ist wohl der deutsche Vermarkter des 
>>>>>>>>> AEL.MF.07) Stromzählers über die D0-Schnittstelle auslesen möchte. 
>>>>>>>>> Dieser sendet keine periodischen Statusinfos aus.
>>>>>>>>> Grundsätzlich funktioniert die Kommunikation, wenn ich sie anstoße:
>>>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>>>> <== "06 30 30 30 0D 0A"
>>>>>>>>> Ende
>>>>>>>>> 
>>>>>>>>> Für den Programmiermodus:
>>>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>>>> <== "06 30 30 __31__ 0D 0A"
>>>>>>>>> ==> "06"
>>>>>>>>> Ende und keine Reaktion auf Befehle wie unter 
>>>>>>>>> http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
>>>>>>>>>  genannt.
>>>>>>>>> 
>>>>>>>>> Nach dieser Initialisierungssequenz ist also Schluss und ich erhalte 
>>>>>>>>> keine Informationen über den Stromverbrauch. Kennt jemand diesen 
>>>>>>>>> Zähler und kann mir weiterhelfen? Ich habe mich auch schon an den 
>>>>>>>>> Hersteller gewandt, allerdings noch keine Antwort erhalten.
>>>>>>>>> 
>>>>>>>>> Mit freundlichen Grüßen
>>>>>>>>> Max
>>>>>>>> Gruß
>>>>>>>> 
>>>>>>>> Matthias
>>>>>>>> 
>>>>>>> Direkt im Terminal mit 'echo "xyz" > /dev/ttyUSB0' und 'cat 
>>>>>>> /dev/ttyUSB0' in einem anderen Terminal. Ich kommuniziere mit einer 
>>>>>>> Baudrate von 300.
>>>>>>> 
>>>>>>> Testweise habe ich es einmal mit vzlogger versucht. Einmal mit einer 
>>>>>>> ACK-Sequence für 300 ("ackseq":  "063030300D0A") und einmal für 4800 
>>>>>>> ("ackseq":  "063034300D0A") Baud:
>>>>>>> 
>>>>>>> Nov 06 17:35:42][mtr0] Creating new meter with protocol d0.
>>>>>>> [Nov 06 17:35:42][d0]   pullseq len:5 found
>>>>>>> [Nov 06 17:35:42][d0]   ackseq len:6 found 000
>>>>>>> , 6
>>>>>>> [Nov 06 17:35:42][mtr0] Meter configured, enabled.
>>>>>>> [Nov 

Re: [vz-users] Schell EZZ1 / Köhler AEL.MF.07 auslesen

[Matthias Behr]

und beim nächsten Read? was passiert wenn du vzlogger laufen lässt? antwortet 
der Zähler noch mal oder bleibt er stumm?

> Am 06.11.2016 um 18:15 schrieb m.guetl...@gmx.de:
> 
> Am 06.11.2016 um 17:54 schrieb Matthias Behr:
>> Schickst mal ein „dump_file“?
>> 
>> 
>>> Am 06.11.2016 um 17:52 schrieb m.guetl...@gmx.de:
>>> 
>>> 
>>> Am 06.11.2016 um 17:41 schrieb Matthias Behr:
>>>> Versuch mal ackseq: auto
>>>> 
>>>> 
>>>> 
>>>>> Am 06.11.2016 um 17:39 schrieb m.guetl...@gmx.de:
>>>>> 
>>>>> Am 06.11.2016 um 15:44 schrieb Matthias Behr:
>>>>>> Wie sprichst du den Zähler denn an? vzlogger?
>>>>>> 
>>>>>> Welche Baudrate nutzt du?
>>>>>> 
>>>>>> Falls vzlogger kannst du mal ein „dump_file“ erstellen und schicken?
>>>>>> 
>>>>>>> Am 06.11.2016 um 12:05 schrieb m.guetl...@gmx.de:
>>>>>>> 
>>>>>>> Hallo zusammen,
>>>>>>> ich wurde in folgendem Thread an diese Mailingliste verwiesen: 
>>>>>>> http://www.photovoltaikforum.com/volkszaehler-org-f131/schell-ezz1-t114836.html
>>>>>>> 
>>>>>>> Mein Problem besteht darin, dass ich die Zählerstände eines "Schell 
>>>>>>> EZZ1/Köhler AEL.MF.07" (Schell ist wohl der deutsche Vermarkter des 
>>>>>>> AEL.MF.07) Stromzählers über die D0-Schnittstelle auslesen möchte. 
>>>>>>> Dieser sendet keine periodischen Statusinfos aus.
>>>>>>> Grundsätzlich funktioniert die Kommunikation, wenn ich sie anstoße:
>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>> <== "06 30 30 30 0D 0A"
>>>>>>> Ende
>>>>>>> 
>>>>>>> Für den Programmiermodus:
>>>>>>> <== "2F 3F 21 0D 0A"
>>>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>>>> <== "06 30 30 __31__ 0D 0A"
>>>>>>> ==> "06"
>>>>>>> Ende und keine Reaktion auf Befehle wie unter 
>>>>>>> http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
>>>>>>>  genannt.
>>>>>>> 
>>>>>>> Nach dieser Initialisierungssequenz ist also Schluss und ich erhalte 
>>>>>>> keine Informationen über den Stromverbrauch. Kennt jemand diesen Zähler 
>>>>>>> und kann mir weiterhelfen? Ich habe mich auch schon an den Hersteller 
>>>>>>> gewandt, allerdings noch keine Antwort erhalten.
>>>>>>> 
>>>>>>> Mit freundlichen Grüßen
>>>>>>> Max
>>>>>> Gruß
>>>>>> 
>>>>>> Matthias
>>>>>> 
>>>>> Direkt im Terminal mit 'echo "xyz" > /dev/ttyUSB0' und 'cat /dev/ttyUSB0' 
>>>>> in einem anderen Terminal. Ich kommuniziere mit einer Baudrate von 300.
>>>>> 
>>>>> Testweise habe ich es einmal mit vzlogger versucht. Einmal mit einer 
>>>>> ACK-Sequence für 300 ("ackseq":  "063030300D0A") und einmal für 4800 
>>>>> ("ackseq":  "063034300D0A") Baud:
>>>>> 
>>>>> Nov 06 17:35:42][mtr0] Creating new meter with protocol d0.
>>>>> [Nov 06 17:35:42][d0]   pullseq len:5 found
>>>>> [Nov 06 17:35:42][d0]   ackseq len:6 found 000
>>>>> , 6
>>>>> [Nov 06 17:35:42][mtr0] Meter configured, enabled.
>>>>> [Nov 06 17:35:42]   New meter initialized (protocol=d0)
>>>>> [Nov 06 17:35:42]   Have 1 meters.
>>>>> [Nov 06 17:35:42][main] log level is 15
>>>>> [Nov 06 17:35:42][main] daemon=0, local=0
>>>>> [Nov 06 17:35:42]   Process not  daemonized...
>>>>> [Nov 06 17:35:42]   Opened logfile /var/log/vzlogger.log
>>>>> [Nov 06 17:35:42][push] pushdata_thread created.
>>>>> [Nov 06 17:35:42][push] Start push_data_thread
>>>>> [Nov 06 17:35:42][] ===> Start meters
>>>>> [Nov 06 17:35:42][mtr0] Meter connection established
>>>>> [Nov 06 17:35:42][mtr0] Meter thread started
>>>>> [Nov 0

Re: [vz-users] Schell EZZ1 / Köhler AEL.MF.07 auslesen

[Matthias Behr]

Schickst mal ein „dump_file“?


> Am 06.11.2016 um 17:52 schrieb m.guetl...@gmx.de:
> 
> 
> Am 06.11.2016 um 17:41 schrieb Matthias Behr:
>> Versuch mal ackseq: auto
>> 
>> 
>> 
>>> Am 06.11.2016 um 17:39 schrieb m.guetl...@gmx.de:
>>> 
>>> Am 06.11.2016 um 15:44 schrieb Matthias Behr:
>>>> Wie sprichst du den Zähler denn an? vzlogger?
>>>> 
>>>> Welche Baudrate nutzt du?
>>>> 
>>>> Falls vzlogger kannst du mal ein „dump_file“ erstellen und schicken?
>>>> 
>>>>> Am 06.11.2016 um 12:05 schrieb m.guetl...@gmx.de:
>>>>> 
>>>>> Hallo zusammen,
>>>>> ich wurde in folgendem Thread an diese Mailingliste verwiesen: 
>>>>> http://www.photovoltaikforum.com/volkszaehler-org-f131/schell-ezz1-t114836.html
>>>>> 
>>>>> Mein Problem besteht darin, dass ich die Zählerstände eines "Schell 
>>>>> EZZ1/Köhler AEL.MF.07" (Schell ist wohl der deutsche Vermarkter des 
>>>>> AEL.MF.07) Stromzählers über die D0-Schnittstelle auslesen möchte. Dieser 
>>>>> sendet keine periodischen Statusinfos aus.
>>>>> Grundsätzlich funktioniert die Kommunikation, wenn ich sie anstoße:
>>>>> <== "2F 3F 21 0D 0A"
>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>> <== "06 30 30 30 0D 0A"
>>>>> Ende
>>>>> 
>>>>> Für den Programmiermodus:
>>>>> <== "2F 3F 21 0D 0A"
>>>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>>>> <== "06 30 30 __31__ 0D 0A"
>>>>> ==> "06"
>>>>> Ende und keine Reaktion auf Befehle wie unter 
>>>>> http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
>>>>>  genannt.
>>>>> 
>>>>> Nach dieser Initialisierungssequenz ist also Schluss und ich erhalte 
>>>>> keine Informationen über den Stromverbrauch. Kennt jemand diesen Zähler 
>>>>> und kann mir weiterhelfen? Ich habe mich auch schon an den Hersteller 
>>>>> gewandt, allerdings noch keine Antwort erhalten.
>>>>> 
>>>>> Mit freundlichen Grüßen
>>>>> Max
>>>> Gruß
>>>> 
>>>> Matthias
>>>> 
>>> Direkt im Terminal mit 'echo "xyz" > /dev/ttyUSB0' und 'cat /dev/ttyUSB0' 
>>> in einem anderen Terminal. Ich kommuniziere mit einer Baudrate von 300.
>>> 
>>> Testweise habe ich es einmal mit vzlogger versucht. Einmal mit einer 
>>> ACK-Sequence für 300 ("ackseq":  "063030300D0A") und einmal für 4800 
>>> ("ackseq":  "063034300D0A") Baud:
>>> 
>>> Nov 06 17:35:42][mtr0] Creating new meter with protocol d0.
>>> [Nov 06 17:35:42][d0]   pullseq len:5 found
>>> [Nov 06 17:35:42][d0]   ackseq len:6 found 000
>>> , 6
>>> [Nov 06 17:35:42][mtr0] Meter configured, enabled.
>>> [Nov 06 17:35:42]   New meter initialized (protocol=d0)
>>> [Nov 06 17:35:42]   Have 1 meters.
>>> [Nov 06 17:35:42][main] log level is 15
>>> [Nov 06 17:35:42][main] daemon=0, local=0
>>> [Nov 06 17:35:42]   Process not  daemonized...
>>> [Nov 06 17:35:42]   Opened logfile /var/log/vzlogger.log
>>> [Nov 06 17:35:42][push] pushdata_thread created.
>>> [Nov 06 17:35:42][push] Start push_data_thread
>>> [Nov 06 17:35:42][] ===> Start meters
>>> [Nov 06 17:35:42][mtr0] Meter connection established
>>> [Nov 06 17:35:42][mtr0] Meter thread started
>>> [Nov 06 17:35:42][mtr0] Meter is opened. Starting channels.
>>> [Nov 06 17:35:42][] Startup done.
>>> [Nov 06 17:35:42][mtr0] Number of readers: 400
>>> [Nov 06 17:35:42][mtr0] Config.daemon: 0
>>> [Nov 06 17:35:42][mtr0] Config.local: 0
>>> [Nov 06 17:35:42][d0]   sending pullsequenz send (len:5 is:5).
>>> [Nov 06 17:35:43][d0]   Pull answer (vendor=AEL, baudrate=4, 
>>> identification=<1>AEL.MF.07)
>>> [Nov 06 17:35:43][d0]   Sending ack sequence send (len:6 is:6,000
>>> ).
>>> [Nov 06 17:35:47][push] waitAndSendOnceToAll empty dataMap (timeout?)
>>> [Nov 06 17:35:52][push] waitAndSendOnceToAll empty dataMap (timeout?)
>>> [Nov 06 17:35:54][d0]   nothing received for more than 10 seconds
>>> [Nov 06 17:35:54][d0]   read timed out!, context: 6, bytes read:

Re: [vz-users] Schell EZZ1 / Köhler AEL.MF.07 auslesen

[Matthias Behr]

Versuch mal ackseq: auto



> Am 06.11.2016 um 17:39 schrieb m.guetl...@gmx.de:
> 
> Am 06.11.2016 um 15:44 schrieb Matthias Behr:
>> Wie sprichst du den Zähler denn an? vzlogger?
>> 
>> Welche Baudrate nutzt du?
>> 
>> Falls vzlogger kannst du mal ein „dump_file“ erstellen und schicken?
>> 
>>> Am 06.11.2016 um 12:05 schrieb m.guetl...@gmx.de:
>>> 
>>> Hallo zusammen,
>>> ich wurde in folgendem Thread an diese Mailingliste verwiesen: 
>>> http://www.photovoltaikforum.com/volkszaehler-org-f131/schell-ezz1-t114836.html
>>> 
>>> Mein Problem besteht darin, dass ich die Zählerstände eines "Schell 
>>> EZZ1/Köhler AEL.MF.07" (Schell ist wohl der deutsche Vermarkter des 
>>> AEL.MF.07) Stromzählers über die D0-Schnittstelle auslesen möchte. Dieser 
>>> sendet keine periodischen Statusinfos aus.
>>> Grundsätzlich funktioniert die Kommunikation, wenn ich sie anstoße:
>>> <== "2F 3F 21 0D 0A"
>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>> <== "06 30 30 30 0D 0A"
>>> Ende
>>> 
>>> Für den Programmiermodus:
>>> <== "2F 3F 21 0D 0A"
>>> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
>>> <== "06 30 30 __31__ 0D 0A"
>>> ==> "06"
>>> Ende und keine Reaktion auf Befehle wie unter 
>>> http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
>>>  genannt.
>>> 
>>> Nach dieser Initialisierungssequenz ist also Schluss und ich erhalte keine 
>>> Informationen über den Stromverbrauch. Kennt jemand diesen Zähler und kann 
>>> mir weiterhelfen? Ich habe mich auch schon an den Hersteller gewandt, 
>>> allerdings noch keine Antwort erhalten.
>>> 
>>> Mit freundlichen Grüßen
>>> Max
>> Gruß
>> 
>> Matthias
>> 
> Direkt im Terminal mit 'echo "xyz" > /dev/ttyUSB0' und 'cat /dev/ttyUSB0' in 
> einem anderen Terminal. Ich kommuniziere mit einer Baudrate von 300.
> 
> Testweise habe ich es einmal mit vzlogger versucht. Einmal mit einer 
> ACK-Sequence für 300 ("ackseq":  "063030300D0A") und einmal für 4800 
> ("ackseq":  "063034300D0A") Baud:
> 
> Nov 06 17:35:42][mtr0] Creating new meter with protocol d0.
> [Nov 06 17:35:42][d0]   pullseq len:5 found
> [Nov 06 17:35:42][d0]   ackseq len:6 found 000
> , 6
> [Nov 06 17:35:42][mtr0] Meter configured, enabled.
> [Nov 06 17:35:42]   New meter initialized (protocol=d0)
> [Nov 06 17:35:42]   Have 1 meters.
> [Nov 06 17:35:42][main] log level is 15
> [Nov 06 17:35:42][main] daemon=0, local=0
> [Nov 06 17:35:42]   Process not  daemonized...
> [Nov 06 17:35:42]   Opened logfile /var/log/vzlogger.log
> [Nov 06 17:35:42][push] pushdata_thread created.
> [Nov 06 17:35:42][push] Start push_data_thread
> [Nov 06 17:35:42][] ===> Start meters
> [Nov 06 17:35:42][mtr0] Meter connection established
> [Nov 06 17:35:42][mtr0] Meter thread started
> [Nov 06 17:35:42][mtr0] Meter is opened. Starting channels.
> [Nov 06 17:35:42][] Startup done.
> [Nov 06 17:35:42][mtr0] Number of readers: 400
> [Nov 06 17:35:42][mtr0] Config.daemon: 0
> [Nov 06 17:35:42][mtr0] Config.local: 0
> [Nov 06 17:35:42][d0]   sending pullsequenz send (len:5 is:5).
> [Nov 06 17:35:43][d0]   Pull answer (vendor=AEL, baudrate=4, 
> identification=<1>AEL.MF.07)
> [Nov 06 17:35:43][d0]   Sending ack sequence send (len:6 is:6,000
> ).
> [Nov 06 17:35:47][push] waitAndSendOnceToAll empty dataMap (timeout?)
> [Nov 06 17:35:52][push] waitAndSendOnceToAll empty dataMap (timeout?)
> [Nov 06 17:35:54][d0]   nothing received for more than 10 seconds
> [Nov 06 17:35:54][d0]   read timed out!, context: 6, bytes read: 0, last byte 
> 0xa
> [Nov 06 17:35:54][mtr0] Got 0 new readings from meter:
> [Nov 06 17:35:54][mtr0] Next reading in 3 seconds
> [Nov 06 17:35:57][push] waitAndSendOnceToAll empty dataMap (timeout?)
> [Nov 06 17:35:57][mtr0] Stopped reading.
> [Nov 06 17:35:57][] Server stopped.
> [Nov 06 17:35:57][] Waiting for pushdata_thread to stop...
> [Nov 06 17:36:02][push] waitAndSendOnceToAll empty dataMap (timeout?)
> [Nov 06 17:36:02][push] Stopped push_data_thread
> [Nov 06 17:36:02][] pushdata_thread stopped
> [Nov 06 17:36:02][] deleted pushdataList
> [Nov 06 17:36:02][] Trying to delete curlSessionProvider...
> [Nov 06 17:36:02][] deleted curlSessionProvider
> 
> Grüße
> Max
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Die Bilder haben ja super Qualität!

Mach die blauen Kreise mal kleiner. Können ruhig viel kleiner sein. Als Wert 
wird dann die Mitte der im blauen Kreis liegenden roten Punkte gewählt.
Das sollte das Auslesen deutlich stabiler machen und es macht auch nichts, wenn 
mal ein wenig Zahl dabei ist. Nur der Spitze gegenüberliegende Ende vom Zeiger 
sollte nicht den blauen Kreis berühren.

> Am 06.11.2016 um 11:59 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> hab mich die letzten Tage um anderes gekümmert..
> 
> am Mittwoch, 2. November 2016 um 18:07 hast du geschrieben:
>>> Überseh ich was im Logfile oder besteht da Verbesserungspotenzial?
>>> 
>> Schick mir mal so ein Log, wo er falsch/schlecht erkennt. Und auch mal ein 
>> Debug.Png.
> 
> www.jahp.de/picsextern/volkszaehler/wasserzaehler.png_debug.jpg
> www.jahp.de/picsextern/volkszaehler/vzlogger.log
> www.jahp.de/picsextern/volkszaehler/data.json
> 
> Das aktuelle Beispiel ist nicht unbedingt das Beste, das gleiche Problem
> hatte ich auch am Mittwoch als ich das aktuelle Bild vom Raspi holte.
> Da gings nämlich so weit daneben das er nach:
> [Nov 06 11:21:12][ocr]  Cropping image to (690,443)-(882,635)
> garnicht mehr weiter machte. Dann ist es ja offensichtlich wo es
> klemmt.
> 
> Weiter oben im Log sind aber auch so Fälle wo das nicht so einfach ist.
> Nachm schneiden sucht er zwar, findet aber wohl nix und macht dann am
> nächsten Zeiger weiter. Z.B hier:
> [Nov 06 09:06:27][ocr]  returning: id <8-0:3.2.0> value 
> 
> Hab auch mal einen Datentupel mit online gestellt. Ich hab da nämlich
> noch ein Problem: Die Digits "springen" gerne mal:
> [1478406851839,0.361,1],[1478406914804,0.261,1],
> 
> 
> Teil meines Problems sind wahrscheinlich die schwarzen Ziffern vor den
> roten Zeigern. Ich bekomms aber nicht hin den Ring so zu setzen das
> ich immer die Lücke zwischen Zahl und Strich treffe. Am 3. Zeiger seh
> ich da mit dem aktuellen Aufbau gar keine Chance. Der Abstand zwischen
> Kamera und Zähler ist recht knapp (~12cm) um möglichst viel Uhr aufs
> Bild zu bekommen. Hab mir das aber mit Parallaxefehler erkauft.
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Mehr als ein Zeiger ist prinzipiell besser, weil dann eine 
Plausibilitätsprüfung auf Sprünge basierend auf dem jeweils kleineren Zeiger 
passiert.
Wichtig ist, dass nur beim kleinsten Zeiger „digit true“ konfiguriert ist.
 
> Am 06.11.2016 um 12:39 schrieb Udo1 :
> 
> Am 06.11.2016 um 11:59 schrieb Daniel Lauckner:
>> Nachm schneiden sucht er zwar, findet aber wohl nix und macht dann am
>> nächsten Zeiger weiter.
> Ich habe da mal ne dumme Frage ^^:
> 
> Wieso muss man alle 4 Zeiger aufnehmen?
> 
> Jedem Zeiger ist eine Einheit zugeordnet. Entsprechend sucht man sich den 
> Zeiger aus, dessen Auflösung einem am Besten passt und Fertig.
> Muss man alles komplizieren?
> 
> Gruß
> Udo

Gruß

Matthias

Re: [vz-users] Schell EZZ1 / Köhler AEL.MF.07 auslesen

[Matthias Behr]

Wie sprichst du den Zähler denn an? vzlogger?

Welche Baudrate nutzt du?

Falls vzlogger kannst du mal ein „dump_file“ erstellen und schicken?

> Am 06.11.2016 um 12:05 schrieb m.guetl...@gmx.de:
> 
> Hallo zusammen,
> ich wurde in folgendem Thread an diese Mailingliste verwiesen: 
> http://www.photovoltaikforum.com/volkszaehler-org-f131/schell-ezz1-t114836.html
> 
> Mein Problem besteht darin, dass ich die Zählerstände eines "Schell 
> EZZ1/Köhler AEL.MF.07" (Schell ist wohl der deutsche Vermarkter des 
> AEL.MF.07) Stromzählers über die D0-Schnittstelle auslesen möchte. Dieser 
> sendet keine periodischen Statusinfos aus.
> Grundsätzlich funktioniert die Kommunikation, wenn ich sie anstoße:
> <== "2F 3F 21 0D 0A"
> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
> <== "06 30 30 30 0D 0A"
> Ende
> 
> Für den Programmiermodus:
> <== "2F 3F 21 0D 0A"
> ==> "/AEL4<1>AEL.MF.07<\r><\n>"
> <== "06 30 30 __31__ 0D 0A"
> ==> "06"
> Ende und keine Reaktion auf Befehle wie unter 
> http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440
>  genannt.
> 
> Nach dieser Initialisierungssequenz ist also Schluss und ich erhalte keine 
> Informationen über den Stromverbrauch. Kennt jemand diesen Zähler und kann 
> mir weiterhelfen? Ich habe mich auch schon an den Hersteller gewandt, 
> allerdings noch keine Antwort erhalten.
> 
> Mit freundlichen Grüßen
> Max

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Hallo Daniel,

> 
> pi@volkszaehler_wasser ~/testprog $ ./testprog /tmp/bild.png
> ./testprog got argc=2
> got inotify_event 4, check for 88
> got inotify_event 400, check for 88
> got inotify_event 8000, check for 88
> ^C
> 
> Ist das so hilfreich?
> 

ja, 8000 ist -> IN_IGNORE also genau das Problem wie bei mir im Test bei 
rename/mv...

> 
> am Dienstag, 1. November 2016 um 21:44 hast du geschrieben:
>> Kannst du dir erstmal aushelfen mit
> 
>> raspistill -o /tmp/wasserzaehler2.png
>> cp /tmp/wasserzaehler2.png /tmp/wasserzaehler.png
>> ?
> 
> Ja.
> 
> Bin nebenbei noch am optimieren. Das ist teilweise etwas nervig
> weils mal geht und dann kurz drauf wieder nicht.
> Ich kann im Log auch nicht erkennen welcher meiner 4 Zeiger denn jetzt
> Probleme macht. Es reicht ja eine erfolglose boundingbox und der
> recognizer wird komplett als  verworfen.
> Man muss also übers Debug-Bild gehen (die Logik hinter der Darstellung
> hab ich glaub verstanden), aber das hilft nix wenn die vorletzte
> Erkennung daneben ging.
> 
> Überseh ich was im Logfile oder besteht da Verbesserungspotenzial?
> 
Schick mir mal so ein Log, wo er falsch/schlecht erkennt. Und auch mal ein 
Debug.Png.

> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

ok. Per kleinem Testprogramm (s.u.) lässt sich folgendes feststellen:

bei einem rename / mv erfolgt defacto ein delete und ein neuerstellen.

Es kommen die Events
IN_DELETE
und
IN_IGNORE

Eine danach mit gleichem Namen erstellte Datei, wird wie eine andere Datei 
angesehen.

D.h. defact muss ich den Code umstellen.
Bei rename/mv muss das File geschlossen und neu geöffnet werden. Gleiches gilt 
für den inotify Handle. Das IN_IGNORE ist das letzte Event was für das Handle 
ankommt.

Kannst du dir erstmal aushelfen mit

raspistill -o /tmp/wasserzaehler2.png
cp /tmp/wasserzaehler2.png /tmp/wasserzaehler.png
?


> Am 01.11.2016 um 21:08 schrieb Matthias Behr :
> 
> ja, das ist die temp. Datei, die raspistill erstellt und dann umbenennt in 
> den Zielnamen.
> Mir ist nur unklar, was mit der vorherigen Datei passiert. Wenn die vorher 
> gelöscht wird, ist klar, warum mein Code nicht funktioniert. 
> 
> 
>> Am 01.11.2016 um 21:01 schrieb Daniel Lauckner :
>> 
>> Hallo Matthias,
>> 
>> 
>> mir ist gerade aufgefallen das eine Datei
>> /tmp/wasserzaehler.png~ existiert wenn raspistill am werkeln ist.
>> 
>> am Dienstag, 1. November 2016 um 20:52 hast du geschrieben:
>>> schade. ich teste bei mir mal mit kleinem Bsp.Programm.
>> 
>> 
>> mfg Daniel
>> 
> 
> Gruß
> 
> Matthias
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Hier noch das kleine Testprogramm:

#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
printf("%s got argc=%d\n", argv[0], argc);
if (argc<2) return 1;
char *file = argv[1];

int _notify_fd = inotify_init1(IN_NONBLOCK);
if (_notify_fd != -1) {
inotify_add_watch(_notify_fd, file, 0xfff);
}


while (1) {
const int EVENTSIZE = sizeof(struct inotify_event) + NAME_MAX + 
1;
if (_notify_fd!=-1){
// read all events from fd:
char buf[EVENTSIZE *5];
bool changed=false;
ssize_t len;
int nr_events;
do{
nr_events = 0;
len = read(_notify_fd, buf, sizeof(buf));
const struct inotify_event *event = (struct 
inotify_event *)(&buf[0]);
for (char *ptr = buf; ptr < buf + len;
ptr += sizeof(struct 
inotify_event) + event->len) {
++nr_events;
event = (const struct inotify_event *) 
ptr;
printf("got inotify_event %x, check for 
%x\n", event->mask, (IN_CLOSE_WRITE|IN_MOVED_TO));
if ((event->mask & 
(IN_CLOSE_WRITE|IN_MOVED_TO))!=0) changed=true; // anyhow continue reading all 
events
}
} while(len>0 && nr_events>=5); // if 5 events received 
there might be some more pending.
if (changed)
printf("file change detected!\n");
}
    }

return 0;
}

> Am 01.11.2016 um 21:44 schrieb Matthias Behr :
> 
> ok. Per kleinem Testprogramm (s.u.) lässt sich folgendes feststellen:
> 
> bei einem rename / mv erfolgt defacto ein delete und ein neuerstellen.
> 
> Es kommen die Events
> IN_DELETE
> und
> IN_IGNORE
> 
> Eine danach mit gleichem Namen erstellte Datei, wird wie eine andere Datei 
> angesehen.
> 
> D.h. defact muss ich den Code umstellen.
> Bei rename/mv muss das File geschlossen und neu geöffnet werden. Gleiches 
> gilt für den inotify Handle. Das IN_IGNORE ist das letzte Event was für das 
> Handle ankommt.
> 
> Kannst du dir erstmal aushelfen mit
> 
> raspistill -o /tmp/wasserzaehler2.png
> cp /tmp/wasserzaehler2.png /tmp/wasserzaehler.png
> ?
> 
> 
>> Am 01.11.2016 um 21:08 schrieb Matthias Behr :
>> 
>> ja, das ist die temp. Datei, die raspistill erstellt und dann umbenennt in 
>> den Zielnamen.
>> Mir ist nur unklar, was mit der vorherigen Datei passiert. Wenn die vorher 
>> gelöscht wird, ist klar, warum mein Code nicht funktioniert. 
>> 
>> 
>>> Am 01.11.2016 um 21:01 schrieb Daniel Lauckner :
>>> 
>>> Hallo Matthias,
>>> 
>>> 
>>> mir ist gerade aufgefallen das eine Datei
>>> /tmp/wasserzaehler.png~ existiert wenn raspistill am werkeln ist.
>>> 
>>> am Dienstag, 1. November 2016 um 20:52 hast du geschrieben:
>>>> schade. ich teste bei mir mal mit kleinem Bsp.Programm.
>>> 
>>> 
>>> mfg Daniel
>>> 
>> 
>> Gruß
>> 
>> Matthias
>> 
> 
> Gruß
> 
> Matthias
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

ja, das ist die temp. Datei, die raspistill erstellt und dann umbenennt in den 
Zielnamen.
Mir ist nur unklar, was mit der vorherigen Datei passiert. Wenn die vorher 
gelöscht wird, ist klar, warum mein Code nicht funktioniert. 


> Am 01.11.2016 um 21:01 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> mir ist gerade aufgefallen das eine Datei
> /tmp/wasserzaehler.png~ existiert wenn raspistill am werkeln ist.
> 
> am Dienstag, 1. November 2016 um 20:52 hast du geschrieben:
>> schade. ich teste bei mir mal mit kleinem Bsp.Programm.
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

schade. ich teste bei mir mal mit kleinem Bsp.Programm.

> Am 01.11.2016 um 20:51 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> am Dienstag, 1. November 2016 um 19:36 hast du geschrieben:
>> kannst du beim MeterOCR.cpp
>> inotify_add_watch mal ein „ | IN_MOVED_TO“ hinter das IN_CLOSE_WRITE hängen?
> 
>> auch hier:
>>print(log_debug, "got inotify_event %x", "ocr", event->mask);
>>if (event->mask & IN_CLOSE_WRITE) changed=true; //
>> in
>>if (event->mask & (IN_CLOSE_WRITE | IN_MOVED_TO)) changed=true;
> 
> Leider keine Besserung.
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

hmm. raspistill macht tatsächlich ein rename:

if (output_file != stdout)
  {
 rename_file(&state, output_file, final_filename, 
use_filename, frame);
  }

Da gibt es vermutlich kein IN_CLOSE_WRITE event sondern ein IN_MOVED_TO

if (!_use_v4l2) {
_notify_fd = inotify_init1(IN_NONBLOCK);
if (_notify_fd != -1) {
inotify_add_watch(_notify_fd, _file.c_str(), 
IN_CLOSE_WRITE); // use IN_ONESHOT and retrigger after read?
}

kannst du beim MeterOCR.cpp
inotify_add_watch mal ein „ | IN_MOVED_TO“ hinter das IN_CLOSE_WRITE hängen?

auch hier:
print(log_debug, "got inotify_event %x", "ocr", event->mask);
if (event->mask & IN_CLOSE_WRITE) changed=true; // anyhow 
continue reading all events

in
if (event->mask & (IN_CLOSE_WRITE | IN_MOVED_TO)) changed=true;



> Am 01.11.2016 um 16:58 schrieb Matthias Behr :
> 
> Komisch. Ich schaue mir mal an, wie raspistill das Outfile erzeugt. Irgendwas 
> ist da komisch.
> 
>> Am 01.11.2016 um 16:38 schrieb Daniel Lauckner :
>> 
>> Hallo Matthias,
>> 
>> 
>> am Dienstag, 1. November 2016 um 15:11 hast du geschrieben:
>>> Schick mal ein 
>>> ls -al der Datei/Verz.
>> 
>> pi@volkszaehler_wasser /tmp $ ls -al
>> insgesamt 3072
>> drwxrwxrwt  7 root root4096 Nov  1 16:17 .
>> drwxr-xr-x 21 root root4096 Nov 25  2015 ..
>> -rw-r--r--  1 pi   pi  3228 Nov  1 16:15 crontab.log
>> drwxrwxrwt  2 root root4096 Nov  1 11:47 .font-unix
>> drwxrwxrwt  2 root root4096 Nov  1 11:47 .ICE-unix
>> drwxrwxrwt  2 root root4096 Nov  1 11:47 .Test-unix
>> -rw-r--r--  1 root root   30997 Nov  1 16:15 vzlogger.log
>> -rw-r--r--  1 root root 2098360 Nov  1 16:15 wasserzaehler.png
>> -rw-r--r--  1 root root  974325 Nov  1 16:15 wasserzaehler.png_debug.jpg
>> drwxrwxrwt  2 root root4096 Nov  1 11:47 .X11-unix
>> drwxrwxrwt  2 root root4096 Nov  1 11:47 .XIM-unix
>> 
>> Die Uhrzeiten der .png und .png_debug.jpg sind da identisch weil ich
>> einen workaround gebastelt hatte.
>> 
>>> Kann es sein dass du beim Verändern die Datei umbenennst und dann neue 
>>> erstellst?
>> 
>> Sie wird einfach überschrieben.
>> 
>>> Wie veränderst du die Datei?
>> 
>> sudo raspistill -n -t 1000 -w 1280 -h 960 -e png -o /tmp/wasserzaehler.png
>> 
>>> Ich habe bei mir per „scp … „ die Datei aktualisiert.
>>> Jedes normal cp … sollte ausreichen.
>> 
>> Wenn ich die Datei zusätzlich nochmal umkopiere gehts:
>> 
>> sudo raspistill -n -t 1000 -w 1280 -h 960 -e png -o /tmp/bild.png
>> sudo cp /tmp/bild.png /tmp/wasserzaehler.png
>> 
>> Ist aber auch nur ein workaround.
>> 
>> 
>> mfg Daniel
>> 
> 
> Gruß
> 
> Matthias
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Komisch. Ich schaue mir mal an, wie raspistill das Outfile erzeugt. Irgendwas 
ist da komisch.

> Am 01.11.2016 um 16:38 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> am Dienstag, 1. November 2016 um 15:11 hast du geschrieben:
>> Schick mal ein 
>> ls -al der Datei/Verz.
> 
> pi@volkszaehler_wasser /tmp $ ls -al
> insgesamt 3072
> drwxrwxrwt  7 root root4096 Nov  1 16:17 .
> drwxr-xr-x 21 root root4096 Nov 25  2015 ..
> -rw-r--r--  1 pi   pi  3228 Nov  1 16:15 crontab.log
> drwxrwxrwt  2 root root4096 Nov  1 11:47 .font-unix
> drwxrwxrwt  2 root root4096 Nov  1 11:47 .ICE-unix
> drwxrwxrwt  2 root root4096 Nov  1 11:47 .Test-unix
> -rw-r--r--  1 root root   30997 Nov  1 16:15 vzlogger.log
> -rw-r--r--  1 root root 2098360 Nov  1 16:15 wasserzaehler.png
> -rw-r--r--  1 root root  974325 Nov  1 16:15 wasserzaehler.png_debug.jpg
> drwxrwxrwt  2 root root4096 Nov  1 11:47 .X11-unix
> drwxrwxrwt  2 root root4096 Nov  1 11:47 .XIM-unix
> 
> Die Uhrzeiten der .png und .png_debug.jpg sind da identisch weil ich
> einen workaround gebastelt hatte.
> 
>> Kann es sein dass du beim Verändern die Datei umbenennst und dann neue 
>> erstellst?
> 
> Sie wird einfach überschrieben.
> 
>> Wie veränderst du die Datei?
> 
> sudo raspistill -n -t 1000 -w 1280 -h 960 -e png -o /tmp/wasserzaehler.png
> 
>> Ich habe bei mir per „scp … „ die Datei aktualisiert.
>> Jedes normal cp … sollte ausreichen.
> 
> Wenn ich die Datei zusätzlich nochmal umkopiere gehts:
> 
> sudo raspistill -n -t 1000 -w 1280 -h 960 -e png -o /tmp/bild.png
> sudo cp /tmp/bild.png /tmp/wasserzaehler.png
> 
> Ist aber auch nur ein workaround.
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Schick mal ein 
ls -al der Datei/Verz.

Kann es sein dass du beim Verändern die Datei umbenennst und dann neue 
erstellst?

Wie veränderst du die Datei? Ich habe bei mir per „scp … „ die Datei 
aktualisiert. 
Jedes normal cp … sollte ausreichen.

> Am 01.11.2016 um 13:11 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> am Dienstag, 1. November 2016 um 12:55 hast du geschrieben:
>> Kann es sein, dass die Datei ein symbolischer Link ist?
> 
> Nein.
> 
> Ich hatte schon die Vermutung das es am tmpfs liegt, aber wenn die
> Datei unter /home/pi/ liegt beobachte ich das selbe Verhalten.
> 
>> Mach mal bei laufendem System ein 
>> touch /tmp/wasserzaehler.png
> 
> Jetzt wirds kompliziert...
> 
> Das hat nämlich nur einmal geklappt, kurz nach dem Start des
> vzloggers. Er hat damit das selbe Bild zweimal bearbeitet.
> Nachdem aber ein neues Bild gemacht wurde hats nicht mehr
> funktioniert. Vzlogger hat die Änderung nicht erkannt.
> Der Befehl wurde erfolgreich ausgeführt, ich seh die veränderte
> Uhrzeit der Datei.
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Hmm. Ja, Da wird keine Dateiänderung erkannt.

Kann es sein, dass die Datei ein symbolischer Link ist?
Mach mal bei laufendem System ein 
touch /tmp/wasserzaehler.png

und schaue, ob danach die Auswertung des Bildes läuft.

> Am 01.11.2016 um 12:29 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> am Dienstag, 1. November 2016 um 12:21 hast du geschrieben:
>> siehst du die folgende Log Ausgabe:
>>print(log_debug, "got inotify_event %x", "ocr", event->mask);
> 
> Nö.
> 
>> Schick mal Log mit LOG_DEBUG.
> 
> Ein Logfile mit verbosity=15 hab ich in der letzen Mail verlinkt.
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Prima.
Bzgl. Erkennung neue Datei:
siehst du die folgende Log Ausgabe:
print(log_debug, "got inotify_event %x", "ocr", event->mask);

Im Filemodus wird per inotify das Filehandle überprüft.
D.h. du brauchst nur normal read aufzurufen (z.B. jede Sekunde) und dann 
erfolgt ein:
ssize_t MeterOCR::read(std::vector &rds, size_t max_reads) {

unsigned int i = 0;
std::string outfilename;
std::string id;
print(log_debug, "MeterOCR::read: %d, %d", name().c_str(), rds.size(), 
max_reads);

if (max_reads<1) return 0;

Pix *image = 0;

if (!_use_v4l2) {
if (!isNotifiedFileChanged() && !_forced_file_changed) return 0;
_forced_file_changed = false;

Beim ersten Aufruf ist _forced_file_changed gesetzt, danach dann nur, falls das 
OS per inotify bescheid gibt.

Schick mal Log mit LOG_DEBUG.


> Am 01.11.2016 um 10:57 schrieb Daniel Lauckner :
> 
> Hallo,
> 
> 
> am Montag, 31. Oktober 2016 um 09:06 hast du geschrieben:
>> Bin grad noch am schauen ob er wirklich alle 4 Zeiger richtig
>> erkennt...
> 
> War etwas knifflig, der dritte Zeiger machte ziemliche Probleme weil
> der teilweise von einer der Zahlen verdeckt war.
> Nachdem ich die Hardwware änderte hab ich alle 4 und der Datensatz kam
> auch in der MW an.
> 
> Aber: vzlogger erkennt nicht das ein neues Bild vorliegt obwohl ich
> jede Minute ein neues mache.
> 
> www.jahp.de/picsextern/volkszaehler/wasserzaehler.png  10:45
> www.jahp.de/picsextern/volkszaehler/wasserzaehler_old.png  10:30
> www.jahp.de/picsextern/volkszaehler/wasserzaehler.png_debug.jpg  10:12
> www.jahp.de/picsextern/volkszaehler/vzlogger.conf  10:08
> www.jahp.de/picsextern/volkszaehler/vzlogger.log  10:45
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

cmake . -DENABLE_OCR=true

(ist aber unschön, weil es ein „in-source tree“ Build ist. Besser wäre Bau im 
sep. Verz. ist aber sep. Thema)


> Am 31.10.2016 um 09:06 schrieb Udo1 :
> 
> Am 31.10.2016 um 08:59 schrieb Matthias Behr:
>> -DENABLE_OCR=true
> Öhm, sorry, schreibfehler?*  -Denable_OCR?
> *Ich hätte jetzt vermutet: -Enable_OCR=true*
> 
> *Gruß
> Udo*
> *

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

an den cmake Aufruf ein 
-DENABLE_OCR=true

hängen.

Aber aufpassen, dass es nicht wg. fehlender Dependencies wieder autom. 
abgewählt wird.

> Am 31.10.2016 um 08:55 schrieb Udo1 :
> 
> Am 30.10.2016 um 18:42 schrieb Daniel Lauckner:
>> nachdem die ersten Stolpersteine
>> https://github.com/volkszaehler/vzlogger/issues/276
>> aus dem Weg geräumt sind bin ich zwar etwas weiter gekommen
> Wie wird denn jetzt vzlogger mit OCR gebaut?
> 
> Gruß
> Udo

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Ich würde bei deinem Zähler nur auf die roten Zeiger gehen (type needle). Das 
klappt recht gut.
D.h. du brauchst kein tesseract.

Du solltest v4ldev auf leer lassen („“) und per File erstmal das Bild übergeben.

Dann sollte es keine „VIDIOC_…“ Fehler geben. Die sind ein Zeichen dafür, dass 
du die Bilder von einer v4l Kamera holst.

Schick mir mal das komplette Bild, wenn du magst.


> Am 31.10.2016 um 08:35 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> 2 Nebenfragen:
> 
> Im Logfile ist mir ein Error aufgefallen.
> [Oct 31 08:23:25][mtr0] Stopped reading.
> [Oct 31 08:23:25][ocr]  Error VIDIOC_STREAMOFF
> [Oct 31 08:23:25][] Server stopped.
> Für mich nicht weiter interessant?
> 
> Ich hab jetzt nur mit ENABLE_OCR=true compiliert. Wenn ich das
> Rollenzählwerk auswerten wollte muss ich nochmal und auch
> teseract aktivieren?
> 
> 
> 
> mfg Daniel

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

> Am 31.10.2016 um 08:26 schrieb Daniel Lauckner :
> 
> Hallo Matthias,
> 
> 
> am Montag, 31. Oktober 2016 um 08:16 hast du geschrieben:
> ->> boundingboxes muss ein array sein (muss da eine Überprüfung einbauen…)
> 
>> Änder mal in
>> "boundingboxes": [{
>>   "identifier": "8-0:3.2.0",
>>   "scaler": -1,
>>   "digit": true,
>>   "type": "circle",
>>   "circle": {
>> "cx": 992,
>> "cy": 452,
>> "cr": 70,
>> "offset": 0
>>   }
>> }],
> 
> Jupp, geht.
> 
> Wie im Eröffungsposting geschrieben:
> Der Fehler wurde vom vzlogger.conf-Editor eingebaut!
> 

oh. blöd. schaue ich mir an.

> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Program received signal SIGSEGV, Segmentation fault.
0x0816b9af in array_list_get_idx ()
(gdb) bt
#0  0x0816b9af in array_list_get_idx ()
#1  0x0811ee09 in MeterOCR::Recognizer::Recognizer (this=0x838cbf0, 
str_type="needle", jr=0x838b658)
at /home/mbehr/develop/volkszaehler/vzlogger/src/protocols/MeterOCR.cpp:196
#2  0x0811f141 in MeterOCR::RecognizerNeedle::RecognizerNeedle (this=0x838cbf0, 
jr=0x838b658)
at /home/mbehr/develop/volkszaehler/vzlogger/src/protocols/MeterOCR.cpp:217
#3  0x081217ba in MeterOCR::MeterOCR (this=0x838cb28, options=...)
at /home/mbehr/develop/volkszaehler/vzlogger/src/protocols/MeterOCR.cpp:729



-> boundingboxes muss ein array sein (muss da eine Überprüfung einbauen…)

Änder mal in
 "boundingboxes": [{
   "identifier": "8-0:3.2.0",
   "scaler": -1,
   "digit": true,
   "type": "circle",
   "circle": {
 "cx": 992,
 "cy": 452,
 "cr": 70,
 "offset": 0
   }
 }],



> Am 31.10.2016 um 07:00 schrieb Daniel Lauckner :
> 
> Hallo,
> 
> 
> am Montag, 31. Oktober 2016 um 06:32 hast du geschrieben:
>> und nichts in
>> /tmp/vzlogger.log
> 
> pi@volkszaehler_wasser ~ $ ls -l /tmp
> insgesamt 1820
> -rw-r--r-- 1 root root 1862152 Okt 30 10:26 wasserzaehler.png
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

und nichts in
/tmp/vzlogger.log

?

> Am 31.10.2016 um 06:21 schrieb Daniel Lauckner :
> 
> Morgen Matthias,
> 
> 
> am Montag, 31. Oktober 2016 um 06:11 hast du geschrieben:
>> Beendet sich wirklich oder läuft als daemon weiter?
> 
> Definitiv.
> 
>> mach mal
>> ps aux|grep vzlogger
> 
> pi@volkszaehler_wasser ~ $ ps aux|grep vzlogger
> pi   30801  0.0  0.5   4748  1924 pts/0S+   06:19   0:00 grep 
> --color=auto vzlogger
> 
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Wasserzähler, vzlogger und OCR

[Matthias Behr]

Beendet sich wirklich oder läuft als daemon weiter?

mach mal
ps aux|grep vzlogger

> Am 30.10.2016 um 18:42 schrieb Daniel Lauckner :
> 
> Hallo,
> 
> 
> nachdem die ersten Stolpersteine
> https://github.com/volkszaehler/vzlogger/issues/276
> aus dem Weg geräumt sind bin ich zwar etwas weiter gekommen, weiß
> jetzt aber nicht weiter weil mir vzlogger weder ein Logfile noch ein
> Diagnosebild generiert.
> 
> sudo vzlogger -c ~/config/vzlogger.ocrtest.conf
> [Oct 30 18:36:28][main] vzlogger v0.6.0 based on heads/master-0-g1484f9aad1 
> from Mon, 22 Aug 2016 22:32:51 +0200 started.
> [Oct 30 18:36:28][push] Ignoring push entry due to empty array or duplicate 
> section
> [Oct 30 18:36:28][mtr0] Creating new meter with protocol ocr.
> [Oct 30 18:36:28][ocr]  recognizer=[ { "boundingboxes": { "identifier": 
> "8-0:3.2.0", "scaler": -1, "digit": true, "type": "circle", "circle": { "cx": 
> 992, "cy": 452, "cr": 70, "offset": 0 } }, "type": "needle", 
> "kernelColorString": "2 -1 -1 0 0 0 0 0 0" } ]
> [Oct 30 18:36:28][ocr]  boundingboxes={ "identifier": "8-0:3.2.0", "scaler": 
> -1, "digit": true, "type": "circle", "circle": { "cx": 992, "cy": 452, "cr": 
> 70, "offset": 0 } }
> 
> Der vzlogger wird danach beendet.
> 
> ~/config/vzlogger.ocrtest.conf:
> {
>  "retry": 3,
>  "daemon": true,
>  "verbosity": 15,
>  "log": "/tmp/vzlogger.log",
>  "push": [],
>  "local": {
>"enabled": false,
>"port": 8080,
>"index": true,
>"timeout": 0,
>"buffer": 0
>  },
>  "meters": [
>{
>  "enabled": true,
>  "allowskip": true,
>  "interval": -1,
>  "aggtime": -1,
>  "aggfixedinterval": false,
>  "channels": [
>{
>  "uuid": "UUID",
>  "identifier": "8-0:3.2.0",
>  "api": "volkszaehler",
>  "middleware": "URL",
>  "secretKey": "",
>  "type": "device",
>  "scaler": 1,
>  "aggmode": "none",
>  "duplicates": 0
>}
>],
>  "protocol": "ocr",
>  "impulses": 0,
>  "file": "/tmp/wasserzaehler.png",
>  "v4l2_dev": "",
>  "generate_debug_image": true,
>  "rotate": 0.0,
>  "recognizer": [
>{
>  "boundingboxes": {
>"identifier": "8-0:3.2.0",
>"scaler": -1,
>"digit": true,
>"type": "circle",
>"circle": {
>  "cx": 992,
>  "cy": 452,
>  "cr": 70,
>  "offset": 0
>}
>  },
>  "type": "needle",
>  "kernelColorString": "2 -1 -1 0 0 0 0 0 0"
>}
>  ]
>}
>  ]
> }
> 
> 
> mfg Daniel

Gruß

Matthias

Re: [vz-users] Frage zur Darstellung mit Steps

[Matthias Behr]

Hallo,

das erfassen eines Zustandes ist Bestandteil dieses Issues (als neue 
Erweiterung):
https://github.com/volkszaehler/vzlogger/issues/252 

noch nicht umgesetzt. (Könnte ich aber am WE mal versuchen.)


> Am 07.09.2016 um 17:03 schrieb Daniel Lauckner :
> 
> Hallo Torsten,
> 
> 
> am Mittwoch, 7. September 2016 um 08:10 hast du geschrieben:
>> was soll den statt "Impulse" eingetragen werden? Wenn ich den gazen
>> "identifier":  Impulse" lösche, sehe ich ab dem Zeitpunkt nichts mehr 
>> von dem Kanal im Frondend(nur bisherige Daten).
> 
> Das Problem, soweit ich es überschauen kann, ist das du ein Ventil
> dargestellt haben möchtest, die Erfassung der Daten aber mit dem
> vzlogger machst - der dafür nicht programmiert wurde.
> Er kann zwar Impulse, aber halt kein State. Die Middleware kann
> zwischenzeitlich State darstellen, aber wenn in die Datenbank nur
> Impulse geschrieben werden hilft das nix.
> 
> Der Threaderöffner Matthias hat nie erwähnt wie er die Ventildaten
> erfasst (vermutlich ein Script).
> 
> 
> mfg Daniel
> 

Gruß

Matthias

Re: [vz-users] Zählertausch

[Matthias Behr]

Aehm. Vorsicht. So setzt du alle Werte auf 1.25.  (und danach sind die alten 
Werte weg!)

(oder meinst du set value=value*1.25 ?)

Gruß
Matthias 

Sent from a mobile device. 

> Am 27.06.2016 um 07:38 schrieb Thomas Höpfner :
> 
> Hallo Matthias,
>  
> so habe ich jetzt gemacht. Meine SQL - Anweisung :
>  
> UPDATE `data`
> SET `value`=1.25
> WHERE `channel_id`=1
> AND `timestamp`<146695830
>  
> Eingegeben über phpmyadmin. Deine Lösung mit Berechnung gefällt mir besser, 
> mit den Syntax bin ich mir aber nicht sicher
>  
> Gruß,
>  
> Thomas
>  
> Von: volkszaehler-users 
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von 
> Matthias Behr
> Gesendet: Sonntag, 26. Juni 2016 22:02
> An: volkszaehler.org - users 
> Betreff: Re: [vz-users] Zählertausch
>  
> müsste per einzelnem mysql update statement gehen ala:
> UPDATE t1 SET col1 = col1 / 1600 * 2000;
> (wenn jetzt noch jemand die korrekten Tabellennamen und Spaltennamen nennen 
> könnte… ;-)
>  
> Am 26.06.2016 um 21:56 schrieb Klaus Reichenecker :
>  
> Nicht schön,
>  
> aber ich würde jetzt einen neuen Kanal anlegen,
> beim alten die UUID ändern, und wenn ich Vergleiche übers Jahr sehen will 
> beide anschalten
>  
> Grüße
>  
> Klaus
> - Original Message - 
> From: Thomas Höpfner
> To: volkszaehler-us...@lists.volkszaehler.org
> Sent: Sunday, June 26, 2016 8:26 PM
> Subject: [vz-users] Zählertausch
>  
> Hallo zusammen,
>  
> heute musste ich meinen Zähler tauschen. 
> Das Problem, der alte hatte 1600 Imp/kWh, der neue 2000.
> Nachdem ich die Einstellung für den Zähler im Frontend stimmen die alten 
> Daten nicht mehr.
> Ich suche jetzt nach einer Möglichkeit das die alten und neuen Daten als ein 
> Kanal im Frontend angezeigt werden.
> Kann man die Daten in der Datenbank irgendwie "migrieren"?
> Es muss auch in der Datenbank sein, die Impulse werden von einen Net-IO mit 
> Ethersex an die Middleware übertragen. Auf den habe ich im Moment keinen 
> Zugriff.
>  
> Ich hoffe jemand kann mir helfen.
>  
> Gruß,
>  
> Thomas
>  
>  
>  
> Gruß
>  
> Matthias
>  

Re: [vz-users] Zählertausch

[Matthias Behr]

müsste per einzelnem mysql update statement gehen ala:
UPDATE t1 SET col1 = col1 / 1600 * 2000;
(wenn jetzt noch jemand die korrekten Tabellennamen und Spaltennamen nennen 
könnte… ;-)

> Am 26.06.2016 um 21:56 schrieb Klaus Reichenecker :
> 
> Nicht schön,
>  
> aber ich würde jetzt einen neuen Kanal anlegen,
> beim alten die UUID ändern, und wenn ich Vergleiche übers Jahr sehen will 
> beide anschalten
>  
> Grüße
>  
> Klaus
>> - Original Message - 
>> From: Thomas Höpfner 
>> To: volkszaehler-us...@lists.volkszaehler.org 
>> 
>> Sent: Sunday, June 26, 2016 8:26 PM
>> Subject: [vz-users] Zählertausch
>> 
>> Hallo zusammen,
>>  
>> heute musste ich meinen Zähler tauschen. 
>> Das Problem, der alte hatte 1600 Imp/kWh, der neue 2000.
>> Nachdem ich die Einstellung für den Zähler im Frontend stimmen die alten 
>> Daten nicht mehr.
>> Ich suche jetzt nach einer Möglichkeit das die alten und neuen Daten als ein 
>> Kanal im Frontend angezeigt werden.
>> Kann man die Daten in der Datenbank irgendwie "migrieren"?
>> Es muss auch in der Datenbank sein, die Impulse werden von einen Net-IO mit 
>> Ethersex an die Middleware übertragen. Auf den habe ich im Moment keinen 
>> Zugriff.
>>  
>> Ich hoffe jemand kann mir helfen.
>>  
>> Gruß,
>>  
>> Thomas
>>  
>>  

Gruß

Matthias

Re: [vz-users] /dev/bus/w1 plötzlich weg, wie geht die Fehlereingrenzung?

[Matthias Behr]

> Am 05.06.2016 um 13:27 schrieb Bernd Gewehr :
> 
> [Jun 05 13:26:00][w1t]  scanW1devices failed!


als welcher User wird vzlogger ausgeführt?

Gruß

Matthias

Re: [vz-users] /dev/bus/w1 plötzlich weg, wie geht die Fehlereingrenzung?

[Matthias Behr]

> Am 05.06.2016 um 13:27 schrieb Bernd Gewehr :
> 
> s0]   unknown option for mmap (). Falling back to normal gpio.



schickst mal deine Config?

Gruß

Matthias

Re: [vz-users] Betriebsstundenzähler

[Matthias Behr]

Ich überleg mal eine Lösung/Vorschlag.

> Am 03.05.2016 um 19:24 schrieb Andreas Götz :
> 
> Hi Matthias,
> 
> Am 03.05.2016 um 18:56 schrieb Matthias Behr  <mailto:mb...@mcbehr.de>>:
> 
>> Hallo Andi,
>> 
>> du meinst:
>> 
>>> 
>>> Dein Problem ist, dass du keine Impulse am S0-Eingang hast, sondern 
>>> statische Zustände 1 oder 0.
>>> vzlogger erfasst aber nur die Flanken einer Zustandsänderung. Also die 
>>> Änderung von 0 nach 1 oder von 1 auf 0.
>>> 
>>> @Udo/Matthias: genau dafür ist in der Middleware der Typ "Sensor" zuständig.
>>> 
>>> Ich überlege gerade ob uns da im vzlogger eine Funktion fehlt die als 
>>> Protocol statt S0 (=Impulse) da so etwas wie "Sensor" anbietet mit dem also 
>>> bei einer Statusänderung einfach der aktuelle Wert in die MW geschrieben 
>>> wird.
>> 
>> keine Impulse melden, sondern jeweils nur die Statusänderung melden? Könnte 
>> man schnell einbauen.
> 
> Genau. Z.b. Bei w1-therm und sml machen wir das ja auch- nur bei S0 sind wir 
> anders geeicht was für Impulse ja auch richtig ist, aber es gibt eben noch 
> mehr Varianten. Man stelle sich nur ein analoges IO Pin vor :O
> 
> Naming ist ein Thema- Iostate find ich gruselig. Dann fast lieber "Value" 
> oder meinetwegen "Direct"- das wäre dann eine der Alternativen zu S0, Sml etc 
> und würde fürs erste nur mit GPIO funktionieren?
> 
>> 
>>> 
>>> Habe ich jetzt einen Knoten im Kopf oder ist es nicht das was wir brauchen? 
>>> Kann es sein dass und das bisher nur nicht aufgefallen ist weil die "Art" 
>>> des Protokolls immer auch die Meßwerterfassung mit bestimmt hat (z.B. 
>>> w1therm -> Sensor)? 
>>>  
>>> D.h. du bekommst einmal einen Impuls beim Einschalten der Pumpe und einmal 
>>> beim Ausschalten der Pumpe.
>>> Das funktioniert also nicht so wie du dir das vorstellst.
>>> Du brauchst noch den Betriebsstundenzähler:
>>> http://wiki.volkszaehler.org/hardware/channels/meters/working_hours?s[]=betriebsstundenz%C3%A4hler
>>>  
>>> <http://wiki.volkszaehler.org/hardware/channels/meters/working_hours?s[]=betriebsstundenz%C3%A4hler>
>>> 
>>> Der setzt dir den Zustand Pumpe An-Aus in Impulse um, die dann vzlogger 
>>> erfassen kann.
>>> 
>>> Ich frag mich ob das sein muss. Da wir GPIOs lesen können lässt sich auch 
>>> ein 0/1 Wert loggen wenn wir statt "Schaltimpuls" auf "Schaltzustand" gehen.
>>> 
>>> 
>>> 
>>> Das Problem ist, das vzlogger, wenn er statische Eingangszustände erfassen 
>>> soll, die Eingänge ständig pollen müsste und nichts anderes mehr machen 
>>> kann.
>>> 
>>> Das ließe sich ja- wenn dem so ist ändern. Auch bei Logging von Zuständen 
>>> reicht es ja diese zu loggen wenn sich der Eingang ändert. M.E. müssten wir 
>>> daher gar nicht so viel anpassen.
>>>  
>>> Was meint ihr?
>>> 
>>> 
>>> Gruß
>>> Udo
>>> 
>>> Viele Grüße,
>>> Andreas
>>> 
>> 
>> Gruß
>> 
>> Matthias

Gruß

Matthias

Re: [vz-users] Betriebsstundenzähler

[Matthias Behr]

Hallo Andi,

du meinst:

> 
> Dein Problem ist, dass du keine Impulse am S0-Eingang hast, sondern statische 
> Zustände 1 oder 0.
> vzlogger erfasst aber nur die Flanken einer Zustandsänderung. Also die 
> Änderung von 0 nach 1 oder von 1 auf 0.
> 
> @Udo/Matthias: genau dafür ist in der Middleware der Typ "Sensor" zuständig.
> 
> Ich überlege gerade ob uns da im vzlogger eine Funktion fehlt die als 
> Protocol statt S0 (=Impulse) da so etwas wie "Sensor" anbietet mit dem also 
> bei einer Statusänderung einfach der aktuelle Wert in die MW geschrieben wird.

keine Impulse melden, sondern jeweils nur die Statusänderung melden? Könnte man 
schnell einbauen.

> 
> Habe ich jetzt einen Knoten im Kopf oder ist es nicht das was wir brauchen? 
> Kann es sein dass und das bisher nur nicht aufgefallen ist weil die "Art" des 
> Protokolls immer auch die Meßwerterfassung mit bestimmt hat (z.B. w1therm -> 
> Sensor)? 
>  
> D.h. du bekommst einmal einen Impuls beim Einschalten der Pumpe und einmal 
> beim Ausschalten der Pumpe.
> Das funktioniert also nicht so wie du dir das vorstellst.
> Du brauchst noch den Betriebsstundenzähler:
> http://wiki.volkszaehler.org/hardware/channels/meters/working_hours?s[]=betriebsstundenz%C3%A4hler
>  
> 
> 
> Der setzt dir den Zustand Pumpe An-Aus in Impulse um, die dann vzlogger 
> erfassen kann.
> 
> Ich frag mich ob das sein muss. Da wir GPIOs lesen können lässt sich auch ein 
> 0/1 Wert loggen wenn wir statt "Schaltimpuls" auf "Schaltzustand" gehen.
> 
> 
> 
> Das Problem ist, das vzlogger, wenn er statische Eingangszustände erfassen 
> soll, die Eingänge ständig pollen müsste und nichts anderes mehr machen kann.
> 
> Das ließe sich ja- wenn dem so ist ändern. Auch bei Logging von Zuständen 
> reicht es ja diese zu loggen wenn sich der Eingang ändert. M.E. müssten wir 
> daher gar nicht so viel anpassen.
>  
> Was meint ihr?
> 
> 
> Gruß
> Udo
> 
> Viele Grüße,
> Andreas
> 

Gruß

Matthias

Re: [vz-users] [solved] vzlogger Daten werden im Daemon Modus nicht aktualisiert

[Matthias Behr]

Hallo,

ja, ich gehe davon aus, dass der Zähler auch ohne Aufforderung nach initialer 
Kommunikation seine Daten/Telegramme sekündlich verschickt (macht meiner auch 
so). Und du hast ja auch keine Pullsequenz gesetzt, d.h. der Zähler schickt die 
Daten von allein.
Da vzlogger den Port offen hat (in deinem Fall ja sogar per TCP Port/Host), 
puffert min. das Betriebssystem die Daten.

Der Unterschied zum Neustart von vzlogger ist, dass der Port geschlossen und 
neu geöffnet wird. Dabei werden die gesendeten Daten weggeschmissen.


Immer wenn der Zähler seine Daten autom. schickt, sollte kein „Interval“ 
genutzt werden, sondern aggmode.

> Am 02.04.2016 um 15:30 schrieb Joerg Krohn :
> 
> Hallo Matthias,
> 
>> Mach mal 
>> interval auf -1
>> 
>> Der Logger scheint seine Daten nicht loszuwerden. 
>> 
>> Wenn dir das dann zu viele Datensätze sind, dann kannst du per
>> aggmode avg oder max die Frequenz reduzieren. 
> 
>  "interval" : -1,
>  "aggtime" : 30, // in sekunden (optional)
>  "channels": [{
>  "aggmode" : "MAX",
>  [..]
> 
> Scheint jetzt alles zu laufen.
> 
> Also dann fasse ich mal mein Verständnis der Situation zusammen.
> 
> - Zähler sendet sekündlich seinen Zählerstand
> - vzlogger buffered alle Werte
> - bei Verwendung der Einstellung "interval" : 60 wird nicht alle 60s
>  der letzte ausgelesene Zählerstand ausgewertet, sondern der nächste
>  Wert in der Queue. In diesem konkreten Beispiel laufen die Werte
>  also immer weiter auseinander. Der erste Wert ist noch ok, nach 60s
>  wird allerdings der Wert verarbeitet, der 1s nach dem ersten Wert vom
>  Zähler gesendet wurde => 59s Versatz. Nach weiteren 60s wird der Wert
>  der 3. Sekunde genommen => 118s Versatz ...
> 
> Lösung:
> interval auf -1 stellen
> und zur Vermeidung einer Datenflut aggtime und aggmode verwenden.
> 
> Vielen Dank an alle Beteiligten für die Lösung des Problems.
> 
> Gruß
> Jörg

Gruß

Matthias

Re: [vz-users] vzlogger Daten werden im Daemon Modus nicht aktualisiert

[Matthias Behr]

Interval steht auf 60. Ich vermute der Logger möchte aber häufiger Daten 
schicken. 

Gruß
Matthias 

Sent from a mobile device. 

> Am 01.04.2016 um 20:31 schrieb Andreas Götz :
> 
> Könnten wir sonst per pm mal auf die Kiste schauen? Würde gerne verstehen 
> warum der Logger seine Daten nicht los wird. Auslastung zu hoch?
> 
> Viele Grüße, Andreas 
> 
>> Am 01.04.2016 um 20:15 schrieb Matthias Behr :
>> 
>> Mach mal 
>> interval auf -1
>> 
>> Der Logger scheint seine Daten nicht loszuwerden. 
>> 
>> Wenn dir das dann zu viele Datensätze sind, dann kannst du per aggmode avg 
>> oder max die Frequenz reduzieren. 
>> 
>> Gruß
>> Matthias 
>> 
>> Sent from a mobile device. 
>> 
>>> Am 01.04.2016 um 18:06 schrieb Joerg Krohn :
>>> 
>>> Hallo Matthias,
>>> 
>>>> Also lt. Log funktioniert alles bestens.
>>>> Die Werte ändern sich lt. Meter aber nur marginal von 19453.0685 hin
>>>> zu 19453.0706 z.B. von 14:07:22 bis 14.11:24. Und werden so auch
>>>> korrekt an die Middleware geschickt.
>>> 
>>> Und genau das ist das Problem. Nach dem Neustart des vzloggers ändern
>>> sich die Werte nämlich innerhalb einer Minute wie folgt:
>>> value=017896.5304, 14:25:27
>>> value=019453.0720, 14:25:28
>>> 
>>> value=017896.8327, 14:26:31
>>> value=019453.1475, 14:26:31
>>> 
>>> Und das liegt nicht dran, dass ich die Stromversorgung des Hanf
>>> Gewächshauses eingeschaltet habe ;-)
>>> 
>>> Im den Graphen sieht man das Ergebnis sofort. Lasse ich den vzlogger
>>> als Daemon laufen, bekomme ich quasi ein Null Linie, während ich bei
>>> minütlichen Neustart des vzloggers per cron den richtigen Verbrauch
>>> erhalte.
>>> 
>>> Viele Grüße
>>> Jörg

Re: [vz-users] vzlogger Daten werden im Daemon Modus nicht aktualisiert

[Matthias Behr]

Mach mal 
interval auf -1

Der Logger scheint seine Daten nicht loszuwerden. 

Wenn dir das dann zu viele Datensätze sind, dann kannst du per aggmode avg oder 
max die Frequenz reduzieren. 

Gruß
Matthias 

Sent from a mobile device. 

> Am 01.04.2016 um 18:06 schrieb Joerg Krohn :
> 
> Hallo Matthias,
> 
>> Also lt. Log funktioniert alles bestens.
>> Die Werte ändern sich lt. Meter aber nur marginal von 19453.0685 hin
>> zu 19453.0706 z.B. von 14:07:22 bis 14.11:24. Und werden so auch
>> korrekt an die Middleware geschickt.
> 
> Und genau das ist das Problem. Nach dem Neustart des vzloggers ändern
> sich die Werte nämlich innerhalb einer Minute wie folgt:
> value=017896.5304, 14:25:27
> value=019453.0720, 14:25:28
> 
> value=017896.8327, 14:26:31
> value=019453.1475, 14:26:31
> 
> Und das liegt nicht dran, dass ich die Stromversorgung des Hanf
> Gewächshauses eingeschaltet habe ;-)
> 
> Im den Graphen sieht man das Ergebnis sofort. Lasse ich den vzlogger
> als Daemon laufen, bekomme ich quasi ein Null Linie, während ich bei
> minütlichen Neustart des vzloggers per cron den richtigen Verbrauch
> erhalte.
> 
> Viele Grüße
> Jörg

Re: [vz-users] vzlogger Daten werden im Daemon Modus nicht aktualisiert

[Matthias Behr]

Also lt. Log funktioniert alles bestens.
Die Werte ändern sich lt. Meter aber nur marginal von 19453.0685 hin zu 
19453.0706 z.B. von 14:07:22 bis 14.11:24.
Und werden so auch korrekt an die Middleware geschickt. Achtung: Die Angaben 
„Reading: id=… „ werden nach 2 Stellen gerundet. Daher bleibt die Ausgabe da 
konstant. An die Middleware werden aber die korrekten Werte geschickt.
(Gleiches beim anderen Zähler, wo sich die Werte noch geringer ändern.)


Ich kann hier kein Fehler feststellen.

[Mar 28 14:07:22][d0]   Parsed reading (OBIS code=1-0:1.8.1*255, 
value=019453.0685, unit=)
[Mar 28 14:07:22][mtr1] Reading: id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 
value=19453.07 ts=1459166842944
[Mar 28 14:07:22][chn1] Adding reading to queue (value=19453.07 
ts=1459166842944)
[Mar 28 14:07:22][chn1] JSON request body: [ [ 1459166842944, 
19453.06850001 ] ]
[Mar 28 14:07:23][chn1] CURL: Sent '[ [ 1459166842944, 19453.06850001 ] ]' 
bytes
[Mar 28 14:08:23][d0]   Parsed reading (OBIS code=1-0:1.8.1*255, 
value=019453.0686, unit=)
[Mar 28 14:08:23][mtr1] Reading: id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 
value=19453.07 ts=1459166903138
[Mar 28 14:08:23][chn1] Adding reading to queue (value=19453.07 
ts=1459166903138)
[Mar 28 14:08:23][chn1] JSON request body: [ [ 1459166903138, 
19453.0685 ] ]
[Mar 28 14:08:23][chn1] CURL: Sent '[ [ 1459166903138, 19453.0685 ] ]' 
bytes
[Mar 28 14:09:23][d0]   Parsed reading (OBIS code=1-0:1.8.1*255, 
value=019453.0687, unit=)
[Mar 28 14:09:23][mtr1] Reading: id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 
value=19453.07 ts=1459166963448
[Mar 28 14:09:23][chn1] Adding reading to queue (value=19453.07 
ts=1459166963448)
[Mar 28 14:09:23][chn1] JSON request body: [ [ 1459166963448, 19453.0687 ] ]
[Mar 28 14:09:23][chn1] CURL: Sent '[ [ 1459166963448, 19453.0687 ] ]' bytes
[Mar 28 14:10:23][d0]   Parsed reading (OBIS code=1-0:1.8.1*255, 
value=019453.0688, unit=)
[Mar 28 14:10:24][d0]   Parsed reading (OBIS code=1-0:1.8.1*255, 
value=019453.0705, unit=)
[Mar 28 14:10:24][mtr1] Reading: id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 
value=19453.07 ts=1459167023760
[Mar 28 14:10:24][mtr1] Reading: id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 
value=19453.07 ts=1459167024070
[Mar 28 14:10:24][chn1] Adding reading to queue (value=19453.07 
ts=1459167023760)
[Mar 28 14:10:24][chn1] Adding reading to queue (value=19453.07 
ts=1459167024070)
[Mar 28 14:10:24][chn1] JSON request body: [ [ 1459167023760, 
19453.06880001 ], [ 1459167024070, 19453.07050002 ] ]
[Mar 28 14:10:24][chn1] CURL: Sent '[ [ 1459167023760, 19453.06880001 ], [ 
1459167024070, 19453.07050002 ] ]' bytes
[Mar 28 14:11:24][d0]   Parsed reading (OBIS code=1-0:1.8.1*255, 
value=019453.0706, unit=)
[Mar 28 14:11:24][mtr1] Reading: id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 
value=19453.07 ts=1459167084404
[Mar 28 14:11:24][chn1] Adding reading to queue (value=19453.07 
ts=1459167084404)
[Mar 28 14:11:24][chn1] JSON request body: [ [ 1459167084404, 
19453.0705 ] ]


> Am 28.03.2016 um 18:46 schrieb Joerg Krohn :
> 
>> Im Log sieht man aber deutlich das der Wert sich ändert und auch der
>> geänderte Wert erfolgreich an die WM gesendet wird.
> 
> Ich sehe nur an einer Stelle eine Änderung und das ist um 14:26 Uhr,
> nachdem ich vzlogger neu gestartet habe. Die gesamte übrige Zeit
> bleibt der 1. Zähler auf diesem Wert:
> [Mar 28 14:07:21][mtr0] Reading:
> id=1-0:1.8.1*255/ObisItentifier:1-0:1.8.1*255 value=17896.53
> ts=1459166841833
> 
> value=17896.53 für den ersten Zähler und
> value=19453.07 für den zweiten Zähler.
> 
> An welcher Stelle siehst du eine Änderung des Wertes für 1-0:1.8.1?
> 
> Viele Grüße
> Jörg

Gruß

Matthias

Re: [vz-users] Keine Daten mehr vom Stomzähler

[Matthias Behr]

Siehe Fix hier fix regression on UART hw-if introduced with #237 



> Am 19.02.2016 um 13:31 schrieb Volker :
> 
> Moin Udo,
> 
> ich meine mich daran zu erinnern, daß bei mir, nach einem restart des 
> vzloggers auch keine impulse mehr über strace kamen,
> bin mir aber nicht sicher. Kann ich jetzt auch nicht mehr prüfen, dafür sagt 
> f3, daß meine SD-Karte völlig in Ordnung ist :)
> 
> Gruß Volker
> 
> 
> Am 19.02.2016 um 12:50 schrieb Udo1:
>> Am 19.02.2016 um 11:48 schrieb Volker:
>>> Ich werde jetzt einfach das Image nochmal runterladen, eine neue SD-Karte 
>>> nehmen und nochmal von vorne,
>>> vorher lief der Gaszähler ja..(Irgendwie komme ich mir jetzt schon ein 
>>> wenig GaGa vor) 
>> Warte mal. Ich habe hier das gleiche Problem das keine Impulse von ttyUSB0 
>> geloggt werden.
>> 
>> pi@raspberrypi:/ $ cat /tmp/vzlogger.log
>> [Feb 19 12:33:05]   Opened logfile /tmp/vzlogger.log
>> [Feb 19 12:33:05][push] No pushDataServer defined.
>> [Feb 19 12:33:05][] ===> Start meters
>> [Feb 19 12:33:05][s0]   counter_thread created
>> [Feb 19 12:33:05][s0]   Counter thread started with blocking hwif
>> [Feb 19 12:33:05][mtr0] Meter connection established
>> [Feb 19 12:33:05][mtr0] Meter thread started
>> [Feb 19 12:33:05][mtr0] Meter is opened. Starting channels.
>> [Feb 19 12:33:05][mtr0] Number of readers: 4
>> [Feb 19 12:33:05][mtr0] Config.daemon: 1
>> [Feb 19 12:33:05][chn0] Logging thread started
>> [Feb 19 12:33:05][mtr0] Config.local: 0
>> [Feb 19 12:33:05][] Startup done.
>> [Feb 19 12:33:05][chn0] Start logging thread for volkszaehler-api. Running 
>> as daemon: yes
>> [Feb 19 12:33:05][chn0] Using default volkszaehler api.
>> 
>> Keine Ahnung woran das liegen kann. Ein strace liefert Impulse.
>> 
>> pi@raspberrypi:~ $ strace -ttt -e read cat < /dev/ttyUSB0
>> 1455882142.282508 read(3, 
>> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0h\5\0\0004\0\0\0"..., 512) = 
>> 512
>> 1455882142.283171 read(3, 
>> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 960) 
>> = 960
>> 1455882142.283612 read(3, 
>> "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\3\f\1\22\4\24"..., 47) = 47
>> 1455882142.285775 read(3, 
>> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0L\204\1\0004\0\0\0"..., 512) 
>> = 512
>> 1455882142.286233 read(3, 
>> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2840) 
>> = 2840
>> 1455882142.286650 read(3, 
>> "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\23\1\24"..., 47) = 47
>> 1455882142.291998 read(0, "\0", 131072) = 1
>> 1455882148.848782 read(0, "\0", 131072) = 1
>> 1455882149.795341 read(0, "\0", 131072) = 1
>> 1455882150.538159 read(0, "\0", 131072) = 1
>> 1455882151.311037 read(0, "\0", 131072) = 1
>> 1455882152.175352 read(0, "\0", 131072) = 1
>> 1455882153.019253 read(0, "\0", 131072) = 1
>> 1455882153.789557 read(0, "\0", 131072) = 1
>> 1455882154.647452 read(0, "\0", 131072) = 1
>> 1455882155.499034 read(0, "\0", 131072) = 1
>> 1455882156.208132 read(0, "\0", 131072) = 1
>> 1455882156.911132 read(0, "\0", 131072) = 1
>> 1455882157.632694 read(0, "\0", 131072) = 1
>> 1455882158.346780 read(0, "\0", 131072) = 1
>> 1455882159.032140 read(0, "\0", 131072) = 1
>> 
>> 
>> In der Datenbank kommt auch nichts an.
>> 
>> Hat jemand eine Idee?
>> 
>> Gruß
>> Udo
>> 
> 

Gruß

Matthias

Re: [vz-users] Keine Daten mehr vom Stomzähler

[Matthias Behr]

Gibt es schon einen normalen Log mit loglevel 15?

Gruß
Matthias 

Sent from a mobile device. 

> Am 17.02.2016 um 09:46 schrieb Udo1 :
> 
> Ok, dann funktioniert das wohl bei sml-Meter nicht.
> Da kann dann nur Matthias noch helfen.
> 
> Gruß
> Udo
> 
>> Am 17.02.2016 um 09:35 schrieb Volker:
>> Es wird leider keine Datei erzeugt.
>> 
>> Gruß volker
>> 
>> 
>>> Am 17.02.2016 um 09:10 schrieb Udo1:
 Am 17.02.2016 um 07:52 schrieb Volker:
 der letzte Logeintrag der den Stromzähler betrifft, ist jedesmal "sending 
 pullsequenz" 
>>> Bin jetzt nicht sicher ob das bei SML-Meter auch geht, aber füge mal unter 
>>> "device": "/dev/Strom-lesekopf",
>>> 
>>> "dump_file": "/var/log/smldump.log",
>>> 
>>> ein und zeig mal was dann darin steht.
>>> 
>>> Gruß
>>> Udo
>> 
>> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] Keine Daten mehr vom Stomzähler

[Matthias Behr]

Ja. da baue ich mal ein besseres Fehlerhandling ein. 

Gruß
Matthias

Sent from a mobile device. 

> Am 16.02.2016 um 19:42 schrieb Klaus Stetter :
> 
> Mit dem USB-Lesekopf kann ich durch kurzes Aus/Einstecken vzlogger dazu 
> bringen, dass er nichts mehr liest
> (bzw. in einer Endlosschleife mit 100% CPU läuft).
> Könnte es sowas sein (dmesg mal anschauen?)
> 
> Gruß Klaus
> 
>> Am 15.02.2016 um 19:42 schrieb Volker:
>> vzlogger läut noch,  im syslog ist nichts vermerkt.
>> 
>> Den Kopf hab ich versucht genau zu positionieren. Wie groß ist denn der 
>> Spielraum für den Kopf ?
>> 
>> 
>> Gruß Volker
>> 
>> 
>> 
>>> Am 15.02.2016 um 18:55 schrieb Udo1:
>>> Am 15.02.2016 um 18:46 schrieb Volker: Hab ich in der config alles richtig 
>>> gemacht ? Sieht ok, aus. Bis auf 'verbosity'. Würde ich runter setzen.
>>> 
>>> 
>>> Also vzlogger läuft dann noch, es kommen nur keine Daten mehr vom Zähler?
>>> 
>>> Was steht zu dem Zeitpunkt, wenn der Fehler auftritt, dann in der 
>>> /var/log/syslog?
>>> Sitzt der IR-Kopf exakt?
>>> 
>>> Gruß
>>> Udo
>> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: [vz-users] Update

[Matthias Behr]

git checkout -- .

dann
git checkout master
git pull

> Am 12.02.2016 um 17:54 schrieb Thomas Hümmerich :
> 
> 
> Wenn ich wüsste, wie man an einem Windows-Notebook aus dem Fenster mit 
> schwarzem Bildschirm Text rauskopieren kann, wäre es einfacher.
> 
> Nach git checkout master und git pull
> kam die Fehlermeldung:
> error: your local changes to the following files would be overwritten by 
> merge:
> /etc/vzlogger.conf
> Please, commit your changes or stash them before you can merge.
> Aborting.
> 
> git branch ergibt 
> master
> * pr219
> 
> From: mb...@mcbehr.de
> Date: Fri, 12 Feb 2016 17:36:33 +0100
> To: volkszaehler-users@demo.volkszaehler.org
> Subject: Re: [vz-users] Update
> 
> tipp mal „git branch“ ein
> 
> (und zum Updaten:
> git checkout master
> git pull
> 
> )
> 
> Am 12.02.2016 um 17:35 schrieb Thomas Hümmerich  >:
> 
> Nach dem Wechsel in /home/pi/vzlogger
> und Eingabe von 
> git pull
> 
> kommt die Meldung:
> There is no tracking information for this branch.
> Please specify which branch you want to merge with.
> 
> Und nun?
> Gruß, Thomas
> From: mar...@tarlowski.de 
> Date: Fri, 12 Feb 2016 09:48:05 +0100
> To: volkszaehler-users@demo.volkszaehler.org 
> 
> Subject: Re: [vz-users] Update
> 
> Ach du nutzt Udos Image.
> vorgehen ist trotztdem wie oben beschrieben. Ich glaube im Wiki ist auch eine 
> updateanleitung...
> 
> Am 12. Februar 2016 um 09:46 schrieb Thomas Hümmerich 
> mailto:thomas.huemmer...@arcor.de>>:
> Hallo,
> danke.
> Nein, der vzlogger war in dem Raspberry-Image enthalten, wo der herkam, weiß 
> ich nicht :=)
>  
> From: mar...@tarlowski.de 
> Date: Fri, 12 Feb 2016 09:43:21 +0100
> 
> To: volkszaehler-users@demo.volkszaehler.org 
> 
> Subject: Re: [vz-users] Update
> 
> hi,
> 
> gehe in den Ordner in den du das Git geladen hast.
> vermutlich /home/pi/vzlogger.
> 
> mache: 
> git pull
> cmake .
> make
> make install
> 
> der vzlogger kam ja nicht über apt-get. oder?
> 
> Am 12. Februar 2016 um 09:39 schrieb Thomas Hümmerich 
> mailto:thomas.huemmer...@arcor.de>>:
> Hallo,
> ich komme im Moment nicht auf das Wiki , aber ich habe die dort angegebenen 
> Kommandos eingegeben zum Update der Installation.
> Aus dem Kopf:
> $ sudo apt-get update
> $ sudo apt-get upgrade
> und dann noch make...
>  
> Und danach das Update des Volkszählers wie dort beschrieben.
>  
> Sobald das Wiki wieder geht, kann ich genau reproduzieren, was ich eingegeben 
> habe.
>  
> Gruß, Thomas
> 
>  
> From: cpui...@gmail.com 
> Date: Fri, 12 Feb 2016 08:36:05 +0100
> To: volkszaehler-users@demo.volkszaehler.org 
> 
> Subject: Re: [vz-users] Update
> 
> Hallo Thomas,
> 
> Fehlersuche wie immer: Du beschreibst den Vorgang bis Versionstest und wir 
> sagen Dir wo der Fehler liegt. Ins blaue raten funktioniert einfach nict ohne 
> Glaskugel ;)
> 
> Viele Grüße, Andreas 
> 
> Am 12.02.2016 um 08:31 schrieb Thomas Hümmerich  >:
> 
> 
>  Hallo,
> vor der Aktualisierung habe ich das System upgedated und upgegraded.
> Nun ist mir nicht offensichtlich, was zu tun ist, damit eine aktuelle Version 
> des vzlogger läuft.
> Danke und Gruß, Thomas
> From: cpui...@gmail.com 
> Date: Fri, 12 Feb 2016 07:21:45 +0100
> To: volkszaehler-users@demo.volkszaehler.org 
> 
> Subject: Re: [vz-users] Update
> 
> Du hast offensichtlich nicht den Stand aus git.
> 
> Viele Grüße, Andreas 
> 
> Am 12.02.2016 um 06:43 schrieb Thomas Hümmerich  >:
> 
> Hallo,
> mit vzlogger -V erhalte ich 0.4.7,
> obwohl ich vorher der Anleitung folgend mit git pull usw. ein Update gemacht 
> habe.
> 
> Stimmt die Version denn - ich dachte, Ihr hättet einige Verbesserungen 
> eingebaut.
> 
> Danke und Gruß, Thomas
> 
> Gruß
> 
> Matthias

Gruß

Matthias

Re: [vz-users] Update

[Matthias Behr]

tipp mal „git branch“ ein

(und zum Updaten:
git checkout master
git pull

)

> Am 12.02.2016 um 17:35 schrieb Thomas Hümmerich :
> 
> Nach dem Wechsel in /home/pi/vzlogger
> und Eingabe von 
> git pull
> 
> kommt die Meldung:
> There is no tracking information for this branch.
> Please specify which branch you want to merge with.
> 
> Und nun?
> Gruß, Thomas
> From: mar...@tarlowski.de
> Date: Fri, 12 Feb 2016 09:48:05 +0100
> To: volkszaehler-users@demo.volkszaehler.org
> Subject: Re: [vz-users] Update
> 
> Ach du nutzt Udos Image.
> vorgehen ist trotztdem wie oben beschrieben. Ich glaube im Wiki ist auch eine 
> updateanleitung...
> 
> Am 12. Februar 2016 um 09:46 schrieb Thomas Hümmerich 
> mailto:thomas.huemmer...@arcor.de>>:
> Hallo,
> danke.
> Nein, der vzlogger war in dem Raspberry-Image enthalten, wo der herkam, weiß 
> ich nicht :=)
>  
> From: mar...@tarlowski.de 
> Date: Fri, 12 Feb 2016 09:43:21 +0100
> 
> To: volkszaehler-users@demo.volkszaehler.org 
> 
> Subject: Re: [vz-users] Update
> 
> hi,
> 
> gehe in den Ordner in den du das Git geladen hast.
> vermutlich /home/pi/vzlogger.
> 
> mache: 
> git pull
> cmake .
> make
> make install
> 
> der vzlogger kam ja nicht über apt-get. oder?
> 
> Am 12. Februar 2016 um 09:39 schrieb Thomas Hümmerich 
> mailto:thomas.huemmer...@arcor.de>>:
> Hallo,
> ich komme im Moment nicht auf das Wiki , aber ich habe die dort angegebenen 
> Kommandos eingegeben zum Update der Installation.
> Aus dem Kopf:
> $ sudo apt-get update
> $ sudo apt-get upgrade
> und dann noch make...
>  
> Und danach das Update des Volkszählers wie dort beschrieben.
>  
> Sobald das Wiki wieder geht, kann ich genau reproduzieren, was ich eingegeben 
> habe.
>  
> Gruß, Thomas
> 
>  
> From: cpui...@gmail.com 
> Date: Fri, 12 Feb 2016 08:36:05 +0100
> To: volkszaehler-users@demo.volkszaehler.org 
> 
> Subject: Re: [vz-users] Update
> 
> Hallo Thomas,
> 
> Fehlersuche wie immer: Du beschreibst den Vorgang bis Versionstest und wir 
> sagen Dir wo der Fehler liegt. Ins blaue raten funktioniert einfach nict ohne 
> Glaskugel ;)
> 
> Viele Grüße, Andreas 
> 
> Am 12.02.2016 um 08:31 schrieb Thomas Hümmerich  >:
> 
> 
>  Hallo,
> vor der Aktualisierung habe ich das System upgedated und upgegraded.
> Nun ist mir nicht offensichtlich, was zu tun ist, damit eine aktuelle Version 
> des vzlogger läuft.
> Danke und Gruß, Thomas
> From: cpui...@gmail.com 
> Date: Fri, 12 Feb 2016 07:21:45 +0100
> To: volkszaehler-users@demo.volkszaehler.org 
> 
> Subject: Re: [vz-users] Update
> 
> Du hast offensichtlich nicht den Stand aus git.
> 
> Viele Grüße, Andreas 
> 
> Am 12.02.2016 um 06:43 schrieb Thomas Hümmerich  >:
> 
> Hallo,
> mit vzlogger -V erhalte ich 0.4.7,
> obwohl ich vorher der Anleitung folgend mit git pull usw. ein Update gemacht 
> habe.
> 
> Stimmt die Version denn - ich dachte, Ihr hättet einige Verbesserungen 
> eingebaut.
> 
> Danke und Gruß, Thomas

Gruß

Matthias

Re: [vz-users] Probleme mit dem vzlogger und dem Zeitstempel

[Matthias Behr]

Ah. Du nutzt MeterSML. Ja da ist das so. Hintergrund ist, dass dort die 
Einträge oft relativ lange in den Metern gepuffert werden und nur selten 
übertragen. Da würde die lokale Empfangszeit wenig Sinn machen.

struct timeval tv;
if (entry->val_time) { /* use time from meter */
tv.tv_sec = *entry->val_time->data.timestamp;
tv.tv_usec = 0;
}
else {
gettimeofday(&tv, NULL); /* use local time */
}


Kann man natürlich leicht abschalten. Am besten wäre eine Config-Option? (wobei 
wir die immer vermeiden wollen, weil wir eh schon so viele haben…).

> Am 12.02.2016 um 16:46 schrieb Volker :
> 
> Ich habe jetzt die richtige Zeit und auch einen Graphen.
> 
> Das ist so wie ich schon vermutet habe, der vzlogger nimmt die Zeit vom 
> SML-Meter,
> in meinem Fall vom Easymeter. (Steht auch so in der MeterSML)
> 
> Der Installateur von den Stadtwerken hat die Uhr aber nicht gestellt,
> sondern  nur den Zähler angeklemmt. Ich denke mal das wird häufiger vorkommen.
> 
> 
> Wäre es nicht sinnvoll für solche Fälle dem vzlogger sagen zu können, er soll 
> die lokale Zeit nehmen ?
> 
> Leider stammen meine rudimentären c++ Kenntnisse aus dem vorigen Jahrhundert 
> und sind limitiert.
> 
> 
> Gruß Volker
> 
> 
> Am 09.02.2016 um 21:48 schrieb Matthias Behr:
>> Kannst du mal deine Config und kompletten Log (mit Loglevel 15) schicken?
>> 
>> Das ist total komisch.
>> 
>> Welche Version nutzt du? (vzlogger -V)
>> 
>>> Am 09.02.2016 um 21:02 schrieb Volker < 
>>> <mailto:waldbo...@gmail.com>waldbo...@gmail.com 
>>> <mailto:waldbo...@gmail.com>>:
>>> 
>>> Es handelt sich um "richtigen Log"
>>> 
>>> Der erste Timestamp 1454402544996 ist die Zeit vom rpi (stimmt ja auch mit 
>>> der Logzeit überein)
>>> 
>>> Die 121440397000 ist ebenfalls real und wird bei den folgenden Logs jede 
>>> Minute um 600 hochgezählt, deswegen meine Vermutung es handelt sich um eine 
>>> Uhr, die nicht gestellt wurde und somit am 1.1.1970 begann zu laufen. (Der 
>>> Zähler wurde vor ca 48 Monaten installiert)
>>> 
>>> 
>>> 
>>> Am 09.02.2016 um 20:35 schrieb Matthias Behr:
>>>> Die Zeit wird immer auf die Empfangszeit vom vzlogger (Host) gesetzt:
>>>> 
>>>>ReadingIdentifier *rid(new 
>>>> ObisIdentifier(obis));
>>>>
>>>> rds[number_of_tuples].identifier(rid);
>>>>rds[number_of_tuples].time();
>>>> 
>>>> 
>>>> D.h. wenn die Zeit falsch ist, einfach den rpi,… korrekte Zeit stellen. 
>>>> (ntpdate,…)
>>>> 
>>>> Natürlich liesse sich auf die Zeit aus dem 96.8.0 übernehmen. Da müsste 
>>>> ich mir mal die Spec anschauen für was die dann gilt, …
>>>> Aber ist das notwendig? Wie stark weicht die Zeit ab? Wie oft schickt der 
>>>> die Daten?
>>>> 
>>>> 
>>>>> Am 09.02.2016 um 10:33 schrieb Volker >>>> <mailto:waldbo...@gmail.com>>:
>>>>> 
>>>>> Hallo,
>>>>> 
>>>>> ich habe das Problem, daß der vzlogger einen Wert aus meinem Easymeter 
>>>>> Q3C liest und diesen dann als Zeitstempel nimmt.
>>>>> Wenn das eine Uhr im Easymeter ist, hat leider jemand vergessen sie zu 
>>>>> stellen.
>>>>> Der erste Zeitstempel von "0-0:96.8.0" hat die richtige Zeit.
>>>>> Der eingelesene Wert entspricht grob geschätzt der Anzahl an 
>>>>> Millisekunden seit Inbetriebnahme des Stromzählers.
>>>>> 
>>>>> [Feb 02 09:42:24][sml] sending pullsequenz send (len:96 is:96).
>>>>> [Feb 02 09:42:24][mtr1] Got 12 new readings from meter:
>>>>> [Feb 02 09:42:24][mtr1] Reading: 
>>>>> id=0-0:96.8.0*255/ObisItentifier:0-0:96.8.0*255 value=1214403970.00 
>>>>> ts=1454402544996
>>>>> [Feb 02 09:42:25][mtr1] Reading: 
>>>>> id=1-1:1.8.0*255/ObisItentifier:1-1:1.8.0*255 value=7289640.00 
>>>>> ts=121440397000
>>>>> [Feb 02 09:42:25][mtr1] Reading: 
>>>>> id=1-2:2.8.0*255/ObisItentifier:1-2:2.8.0*255 value=45190.00 
>>>>> ts=121440397000
>>>>> [Feb 02 09:42:25][mtr1] Reading: 
>>>>> id=1-1:1.8.1*255/ObisItentifier:1-1:1

Re: [vz-users] Probleme mit dem vzlogger und dem Zeitstempel

[Matthias Behr]

aber der Fehler hat mit dem Entprellen nichts zu tun.

> Am 10.02.2016 um 09:17 schrieb Udo1 :
> 
> Am 10.02.2016 um 07:16 schrieb Volker:
>> Ich benutze Version 0.5.1 (Das Raspi Image von der Volkszähler Seite)
> Musst du updaten.  Leider wurde bei der letzten Änderung nicht die 
> Versionsnummer erhöht.  (Änderung Prellen).
> 
> Gruß
> Udo

Gruß

Matthias

Re: [vz-users] Probleme mit dem vzlogger und dem Zeitstempel

[Matthias Behr]

Kannst du mal deine Config und kompletten Log (mit Loglevel 15) schicken?

Das ist total komisch.

Welche Version nutzt du? (vzlogger -V)

> Am 09.02.2016 um 21:02 schrieb Volker :
> 
> Es handelt sich um "richtigen Log"
> 
> Der erste Timestamp 1454402544996 ist die Zeit vom rpi (stimmt ja auch mit 
> der Logzeit überein)
> 
> Die 121440397000 ist ebenfalls real und wird bei den folgenden Logs jede 
> Minute um 600 hochgezählt, deswegen meine Vermutung es handelt sich um eine 
> Uhr, die nicht gestellt wurde und somit am 1.1.1970 begann zu laufen. (Der 
> Zähler wurde vor ca 48 Monaten installiert)
> 
> 
> 
> Am 09.02.2016 um 20:35 schrieb Matthias Behr:
>> Die Zeit wird immer auf die Empfangszeit vom vzlogger (Host) gesetzt:
>> 
>>  ReadingIdentifier *rid(new 
>> ObisIdentifier(obis));
>>  
>> rds[number_of_tuples].identifier(rid);
>>  rds[number_of_tuples].time();
>> 
>> 
>> D.h. wenn die Zeit falsch ist, einfach den rpi,… korrekte Zeit stellen. 
>> (ntpdate,…)
>> 
>> Natürlich liesse sich auf die Zeit aus dem 96.8.0 übernehmen. Da müsste ich 
>> mir mal die Spec anschauen für was die dann gilt, …
>> Aber ist das notwendig? Wie stark weicht die Zeit ab? Wie oft schickt der 
>> die Daten?
>> 
>> 
>>> Am 09.02.2016 um 10:33 schrieb Volker < 
>>> <mailto:waldbo...@gmail.com>waldbo...@gmail.com 
>>> <mailto:waldbo...@gmail.com>>:
>>> 
>>> Hallo,
>>> 
>>> ich habe das Problem, daß der vzlogger einen Wert aus meinem Easymeter Q3C 
>>> liest und diesen dann als Zeitstempel nimmt.
>>> Wenn das eine Uhr im Easymeter ist, hat leider jemand vergessen sie zu 
>>> stellen.
>>> Der erste Zeitstempel von "0-0:96.8.0" hat die richtige Zeit.
>>> Der eingelesene Wert entspricht grob geschätzt der Anzahl an Millisekunden 
>>> seit Inbetriebnahme des Stromzählers.
>>> 
>>> [Feb 02 09:42:24][sml] sending pullsequenz send (len:96 is:96).
>>> [Feb 02 09:42:24][mtr1] Got 12 new readings from meter:
>>> [Feb 02 09:42:24][mtr1] Reading: 
>>> id=0-0:96.8.0*255/ObisItentifier:0-0:96.8.0*255 value=1214403970.00 
>>> ts=1454402544996
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-1:1.8.0*255/ObisItentifier:1-1:1.8.0*255 value=7289640.00 
>>> ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-2:2.8.0*255/ObisItentifier:1-2:2.8.0*255 value=45190.00 ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-1:1.8.1*255/ObisItentifier:1-1:1.8.1*255 value=7283990.00 
>>> ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-1:1.8.2*255/ObisItentifier:1-1:1.8.2*255 value=1130.00 ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-1:1.8.3*255/ObisItentifier:1-1:1.8.3*255 value=1110.00 ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-1:1.8.4*255/ObisItentifier:1-1:1.8.4*255 value=1100.00 ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-1:1.8.5*255/ObisItentifier:1-1:1.8.5*255 value=1110.00 ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-1:1.8.6*255/ObisItentifier:1-1:1.8.6*255 value=1200.00 ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-2:2.8.7*255/ObisItentifier:1-2:2.8.7*255 value=44080.00 ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-2:2.8.8*255/ObisItentifier:1-2:2.8.8*255 value=1110.00 ts=121440397000
>>> [Feb 02 09:42:25][mtr1] Reading: 
>>> id=1-0:96.5.5*255/ObisItentifier:1-0:96.5.5*255 value=167840.00 
>>> ts=1454402544996
>>> 
>>> Gibt es irgendeine Möglichkeit den vzlogger dazu zu bringen, den ersten 
>>> Timestamp zu verwenden.
>>> 
>>> 
>>> Gruß Volker
>> 
>> Gruß
>> 
>> Matthias
>> 
> 

Gruß

Matthias

Re: [vz-users] Probleme mit dem vzlogger und dem Zeitstempel

[Matthias Behr]

Btw: ist das ein richtiger Log oder hast du den 12144000… bei ts=… nur als Bsp. 
eingetragen, oder?


> Am 09.02.2016 um 10:33 schrieb Volker :
> 
> Hallo,
> 
> ich habe das Problem, daß der vzlogger einen Wert aus meinem Easymeter Q3C 
> liest und diesen dann als Zeitstempel nimmt.
> Wenn das eine Uhr im Easymeter ist, hat leider jemand vergessen sie zu 
> stellen.
> Der erste Zeitstempel von "0-0:96.8.0" hat die richtige Zeit.
> Der eingelesene Wert entspricht grob geschätzt der Anzahl an Millisekunden 
> seit Inbetriebnahme des Stromzählers.
> 
> [Feb 02 09:42:24][sml] sending pullsequenz send (len:96 is:96).
> [Feb 02 09:42:24][mtr1] Got 12 new readings from meter:
> [Feb 02 09:42:24][mtr1] Reading: 
> id=0-0:96.8.0*255/ObisItentifier:0-0:96.8.0*255 value=1214403970.00 
> ts=1454402544996
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.0*255/ObisItentifier:1-1:1.8.0*255 value=7289640.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-2:2.8.0*255/ObisItentifier:1-2:2.8.0*255 value=45190.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.1*255/ObisItentifier:1-1:1.8.1*255 value=7283990.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.2*255/ObisItentifier:1-1:1.8.2*255 value=1130.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.3*255/ObisItentifier:1-1:1.8.3*255 value=1110.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.4*255/ObisItentifier:1-1:1.8.4*255 value=1100.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.5*255/ObisItentifier:1-1:1.8.5*255 value=1110.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.6*255/ObisItentifier:1-1:1.8.6*255 value=1200.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-2:2.8.7*255/ObisItentifier:1-2:2.8.7*255 value=44080.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-2:2.8.8*255/ObisItentifier:1-2:2.8.8*255 value=1110.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-0:96.5.5*255/ObisItentifier:1-0:96.5.5*255 value=167840.00 
> ts=1454402544996
> 
> Gibt es irgendeine Möglichkeit den vzlogger dazu zu bringen, den ersten 
> Timestamp zu verwenden.
> 
> 
> Gruß Volker

Gruß

Matthias

Re: [vz-users] Probleme mit dem vzlogger und dem Zeitstempel

[Matthias Behr]

Die Zeit wird immer auf die Empfangszeit vom vzlogger (Host) gesetzt:

ReadingIdentifier *rid(new 
ObisIdentifier(obis));

rds[number_of_tuples].identifier(rid);
rds[number_of_tuples].time();


D.h. wenn die Zeit falsch ist, einfach den rpi,… korrekte Zeit stellen. 
(ntpdate,…)

Natürlich liesse sich auf die Zeit aus dem 96.8.0 übernehmen. Da müsste ich mir 
mal die Spec anschauen für was die dann gilt, …
Aber ist das notwendig? Wie stark weicht die Zeit ab? Wie oft schickt der die 
Daten?


> Am 09.02.2016 um 10:33 schrieb Volker :
> 
> Hallo,
> 
> ich habe das Problem, daß der vzlogger einen Wert aus meinem Easymeter Q3C 
> liest und diesen dann als Zeitstempel nimmt.
> Wenn das eine Uhr im Easymeter ist, hat leider jemand vergessen sie zu 
> stellen.
> Der erste Zeitstempel von "0-0:96.8.0" hat die richtige Zeit.
> Der eingelesene Wert entspricht grob geschätzt der Anzahl an Millisekunden 
> seit Inbetriebnahme des Stromzählers.
> 
> [Feb 02 09:42:24][sml] sending pullsequenz send (len:96 is:96).
> [Feb 02 09:42:24][mtr1] Got 12 new readings from meter:
> [Feb 02 09:42:24][mtr1] Reading: 
> id=0-0:96.8.0*255/ObisItentifier:0-0:96.8.0*255 value=1214403970.00 
> ts=1454402544996
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.0*255/ObisItentifier:1-1:1.8.0*255 value=7289640.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-2:2.8.0*255/ObisItentifier:1-2:2.8.0*255 value=45190.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.1*255/ObisItentifier:1-1:1.8.1*255 value=7283990.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.2*255/ObisItentifier:1-1:1.8.2*255 value=1130.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.3*255/ObisItentifier:1-1:1.8.3*255 value=1110.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.4*255/ObisItentifier:1-1:1.8.4*255 value=1100.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.5*255/ObisItentifier:1-1:1.8.5*255 value=1110.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-1:1.8.6*255/ObisItentifier:1-1:1.8.6*255 value=1200.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-2:2.8.7*255/ObisItentifier:1-2:2.8.7*255 value=44080.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-2:2.8.8*255/ObisItentifier:1-2:2.8.8*255 value=1110.00 ts=121440397000
> [Feb 02 09:42:25][mtr1] Reading: 
> id=1-0:96.5.5*255/ObisItentifier:1-0:96.5.5*255 value=167840.00 
> ts=1454402544996
> 
> Gibt es irgendeine Möglichkeit den vzlogger dazu zu bringen, den ersten 
> Timestamp zu verwenden.
> 
> 
> Gruß Volker

Gruß

Matthias

Re: [vz-users] Erfahrungen Heizölverbrauch messen?

[Matthias Behr]

ich habe den PR gerade kommentiert. muss noch leicht nachgebessert werden. 

> Am 01.02.2016 um 21:21 schrieb Andreas Götz :
> 
> @matthias: auf github gibts nen PR der Debouncing korrigieren will. Kann es 
> sein dass das hier einfach nicht richtig tut?
> 
> Viele Grüße, Andreas 
> 
>> Am 01.02.2016 um 20:46 schrieb Michael Baer :
>> 
>> Am Montag, 1. Februar 2016 schrieb sollner11:
>>> so!
>>> 
>>> 
>>> 
>>> Auflösung = 1 nach Held Andi
>>> sa um 17:12 begann der vorletzte Takt mit den anderen Einstellungen
>>> noch umgestellt habe ich 17:40
>>> 
>>> sagt uns das was?
>>> 
>> 
>> Da prellt/schwingt was ganz gewaltig!
>> 
>> Was ich im ganzen Thread nicht gefunden habe: Wie sieht dein Schaltplan aus.
>> 
>> Wie hängt der Betriebstundenzähler am Brenner - wie wird ein- und 
>> ausgeschaltet (Relais?) usw
>> 
>> 
>> --
>> 
>> 
>> Gruss,
>> Michael
>> 
>> GnuPG-ID 0x1E4ED700 http://pgp.mit.edu/

Gruß

Matthias

Re: [vz-users] Erfahrungen Heizölverbrauch messen?

[Matthias Behr]

Hallo,

Andreas, warum meinst du, da sollte nur 0 oder 1 drin stehen? Send_zero ist in 
der Config auf false. D.h. 0 sollte da nie stehen.
debounce_delay steht auch auf 0 -> d.h. die Werte wie 4, 5, 7 sind vermutlich 
Preller.

Oder?

> Am 01.02.2016 um 18:36 schrieb Andreas Götz :
> 
> Die Werte sind Schrott. Da sollte nur 0 oder 1 drin stehen. M.E. Geht das 
> aktuell mit vzlogger nicht bzw. nicht sicher. Ich würd auf die bash (so wie 
> plattes Obst ;) Lösung o.ä. umsteigen.
> 
> Viele Grüße, Andreas 
> 
>> Am 01.02.2016 um 18:18 schrieb Udo1 :
>> 
>>> Am 01.02.2016 um 18:02 schrieb sollner11:
>>> so!
>> Ich würde jetzt mal ein wenig mit den Einstellungen spielen: (man kann ja 
>> nichts kaputt machen...)
>> Setz mal debounce_delay auf 500.
>> Wie sieht es dann aus?
>> 
>> Gruß
>> Udo

Gruß

Matthias

Re: [vz-users] Erfahrungen Heizölverbrauch messen?

[Matthias Behr]

Schick mal nen Log mit Level 15. Das sollte doch herauszubekommen sein, wo die 
komischen Werte herkommen.


> Am 01.02.2016 um 18:36 schrieb Andreas Götz :
> 
> Die Werte sind Schrott. Da sollte nur 0 oder 1 drin stehen. M.E. Geht das 
> aktuell mit vzlogger nicht bzw. nicht sicher. Ich würd auf die bash (so wie 
> plattes Obst ;) Lösung o.ä. umsteigen.
> 
> Viele Grüße, Andreas 
> 
>> Am 01.02.2016 um 18:18 schrieb Udo1 :
>> 
>>> Am 01.02.2016 um 18:02 schrieb sollner11:
>>> so!
>> Ich würde jetzt mal ein wenig mit den Einstellungen spielen: (man kann ja 
>> nichts kaputt machen...)
>> Setz mal debounce_delay auf 500.
>> Wie sieht es dann aus?
>> 
>> Gruß
>> Udo

Gruß

Matthias

Re: [vz-users] Probleme mit der Baudraten-Umstellung eines D0-Drehstromzählers

[Matthias Behr]

Ich schaue mir das noch mal in Ruhe an, schaffe ich aber erst nächsten Sonntag.

> Am 22.01.2016 um 18:41 schrieb Winfried Peters :
> 
> Hallo,
> 
> es gelingt mir nicht meinen Drehstromzähler dauerhaft auf eine höhere 
> Baudrate umzustellen.
> 
> Es handelt sich um ein EMH-ITZ Gerät.Folgende Informationen habe ich auf 
> Anfrage vom zuständigen Stromnetzbetreiber bekommen:
> Die Infrarotschnittstelle kommuniziert über das Schnittstellenprotokoll 
> IEC1107
> Die Schnittstelle muss über eine Initialisierungssequenz mit Passwort 
> aktiviert werden. Das Passwort ist die Eigentumsnummer
> Zu Anfang erwartet der Zähler Kommunikation mit 300 baud, 7 Datenbits, 1 
> Stopbit, Parität even.
> Jeder Befehl muss mit CR&LF abgeschlossen werden.
> Wenn die Kommunikation läuft, kann man auf höhere Datenraten umstellen.
> Der Zähler antwortet sofort mit /AAAB\@nn
> wobei:AAA = „EMH“
> B gibt die maximale Baudrate an (4 = 4800 Bd)
> „\@“ bedeutet, dass der Zähler R5, W5 und R6-Befehle unterstützt
> nn bezeichnet die 14-stellige Geräte-ID.
> Wenn innerhalb von 1,5s keine weiteren Befehle gesendet werden, gibt der 
> Zähler die aktuellen Messwerte aus und meldet sich ab
> Mit den vzlogger-Parametern
> Initialisierung: "pullseq": "2F3F343230383138210D0A"
> Aufforderung Baudratenwechsel 4800 Bd: "ackseq": "063034300D0A"
> "baudrate": 300 und "baudrate_read": 4800
> sollte sich im Prinzip die Kommunikation einstellen lassen.
> 
> Nach Permutation von verschiedenen Parametern konnte ich mit 
> "baudrate_change_delay": 500 und "wait_sync": "end" das bisher beste Ergebnis 
> erzielen: Das 1. Zählertelegramm wird in umgestellter Baudrate ausgegeben, 
> die nachfolgenden Telegramme allerdings wieder nur in 300 Bd.
> 
> Das sieht im d0-Dump (die komplette Datei d0-169.txt im Anhang) dann so aus:
> 
> --- Anfang 
> d0-dump---
> # 50.15503s ( 0 ms) opened
> # 50.171490960s (13 ms) read
> # 50.171546136s ( 0 ms) TCIOFLUSH and cfsetiospeed
> < 50.671836289s (   500 ms)
> 2f 3f 34 32 30 38 31 38 21 0d 0a  /?420818!
> 
> > 50.705414525s (34 ms)
> 2f 3f 34 32 30 38 31 38 21 0a 0a 2f 45 4d 48 34   /?420818!  /EMH4
> 5c 40 2d 2d 49 54 5a 2d 47 30 30 33 38 45 0a 0a   \@--ITZ-G0038E
> 
> < 52.585570689s (  1880 ms)
> 06 30 34 30 0d 0a  040
> 
> # 53.087406779s (   502 ms) usleep cfsetispeed
> > 53.087504791s ( 0 ms)
> 06 30 34 30 0a 0a 02 46 2e 46 28 30 30 30 30 30040   F.F(0   1. 
> Zählertelegramm
> 30 30 30 29 0a 0a 30 2e 30 2e 30 28 30 30 34 32   000)  0.0.0(0042
> 30 38 31 38 29 0a 0a 30 2e 30 2e 31 28 30 32 32   0818)  0.0.1(022
> 35 36 32 33 30 29 0a 0a 30 2e 31 2e 30 28 36 35   56230)  0.1.0(65
> 
> 
> 2a 56 29 0a 0a 35 32 2e 32 35 28 32 33 31 2e 30   *V)  52.25(231.0
> 2a 56 29 0a 0a 37 32 2e 32 35 28 32 33 30 2e 33   *V)  72.25(230.3
> 2a 56 29 0a 0a 21 *V)  !
> 
> # 59.602715084s (  6515 ms) read
> # 59.602767305s ( 0 ms) TCIOFLUSH and cfsetiospeed
> < 60.103714342s (   501 ms)
> 2f 3f 34 32 30 38 31 38 21 0d 0a  /?420818!
> 
> > 60.134602742s (31 ms)
> 2f 3f 34 32 30 38 31 38 21/?420818!
> 
> # 60.403894575s (   269 ms) read
> # 60.403946531s ( 0 ms) TCIOFLUSH and cfsetiospeed
> < 60.904221804s (   501 ms)
> 2f 3f 34 32 30 38 31 38 21 0d 0a  /?420818!
> > 60.904947849s ( 0 ms)
> 0a 0a 2f 3f 34 32 30 38 31 28 21/?42081(!
> 
> # 61.205930809s (   301 ms) read
> # 61.205983535s ( 0 ms) TCIOFLUSH and cfsetiospeed
> < 61.706251638s (   501 ms)
> 2f 3f 34 32 30 38 31 38 21 0d 0a  /?420818!
> 
> > 61.706938172s ( 0 ms)
> 00 02 63 05 2d 2d 49 54 5a 2d 47 30 30 33 38 05 c --ITZ-G0038   2. 
> Zählertelegramm
> 05 02 36 42 0b 43 0b 6a 0a 02 46 2e 46 28 30 30 6B C j  F.F(00
> 30 30 30 30 30 30 29 0a 0a 30 2e 30 2e 30 28 30   00)  0.0.0(0
> 
> 
> 30 2e 37 2a 56 29 0a 0a 37 32 2e 32 35 28 32 32   0.7*V)  72.25(22
> 39 2e 39 2a 56 29 0a 0a 219.9*V)  !
> 
> # 52.591701715s ( 90885 ms) read
> # 52.591754756s ( 0 ms) TCIOFLUSH and cfsetiospeed
> < 53.092015394s (   501 ms)
> 2f 3f 34 32 30 38 31 38 21 0d 0a  /?420818!
> 
> > 53.092768889s ( 0 ms)
> 0a 0a 03 6e 2f 3f 34 32 30 38 31 38 21   n/?420818!
> 
> # 53.391805484s (   299 ms) read
> # 53.391857725s ( 0 ms) TCIOFLUSH and cfsetiospeed
> < 53.892111733s (   501 ms)
> 2f 3f 34 32 30 38 31 38 21 0d 0a  /?420818!
> 
> > 53.892736371s ( 0 ms)
> 0a 0a 2f 3f 34 32 30 38 31 20 21/?42081 !
> 
> # 54.194921780s (   302 ms) read
> # 54.194977016s ( 0 ms) TCIOFLUSH and cfsetiospeed
> < 54.695234624s (   501 ms)
> 2f 3f 34 32 30 38 31 38 21

Re: [vz-users] VZLOGGER Hilfe bei Easymeter und Temperatur

[Matthias Behr]

schick mal nen Log dazu. Loglevel 10 oder 15. (Achtung, danach wieder 
runtersetzen, sonst loggst du dir nen Wolf ;-)


> Am 21.01.2016 um 11:29 schrieb Nils Radde :
> 
> Super vielen Dank.
> 
> Ich habe jetzt nur noch das Problem, das ich jeden Tag um 8 Uhr vom Easymeter 
> einen komischen Wert geliefert bekomme.
> 
> hat jemand dazu eine Idee ?
> 
> 
> 
> Am 19. Januar 2016 um 09:02 schrieb Nils Radde  >:
> Über s0 ha ich einen Gaszähler angeschlossen.
> 
> -Ursprüngliche Nachricht-
> Von: volkszaehler-users
> [mailto:volkszaehler-users-boun...@demo.volkszaehler.org 
> ] Im Auftrag von
> Udo1
> Gesendet: Dienstag, 19. Januar 2016 00:02
> An: volkszaehler.org  - users 
>  >
> Betreff: Re: [vz-users] VZLOGGER Hilfe bei Easymeter und Temperatur
> 
> Am 18.01.2016 um 23:52 schrieb Nils Radde:
> > Kann ist sonst noch etwas optimieren ?
> Was ist mit dem S0-Zähler den du in der vzlogger.conf konfiguriert hast?
> 
> > Ich habe zur Zeit zwei Temperatursensoren, aber möchte gerne das die nur
> > alle 60 Sekunden ihre Daten liefern.
> *"interval": 60,*
>"aggtime": -1,
>"aggfixedinterval": false,
>"channels": [
>  {
>"uuid": "UUID",
>"identifier": "28-0215725b5aff",
> 
> Gruß
> Udo
> 
> 
> 
> -- 
> Mit freundlichem Gruß aus Harsefeld
>  
> Nils Radde
>  
> Spreenweg 1
> 21698 Harsefeld

Gruß

Matthias

Re: [vz-users] Einträge in die vzlogger.log unterdrücken?

[Matthias Behr]

Ich bereite einen Patch/PR vor. 

> Am 16.01.2016 um 23:14 schrieb applicationMGR ecoCuyo 
> :
> 
> Hallo Matthias,
> 
> keine Ahnung, was die Gemeinde denkt... für meine Belange wäre das eine 
> Lösung.
> 
> Beste Grüße
> Armin
> 
> Am 16.01.2016 um 13:48 schrieb Matthias Behr  <mailto:mb...@mcbehr.de>>:
> 
>> Das Problem ist, dass die nicht der 
>> IEC 62056-21 entsprechen.
>> 
>> Erlaubt wäre höchtens ein C.60.5*2 aber nicht ein C.60.5.2.
>> 
>> Ich könnte aber den Loglevel eins höher setzen Fehler sind ja nicht wirklich 
>> kritisch. Soll ich das tun?
>> 
>>  
>>> Am 15.01.2016 um 18:12 schrieb application MGR >> <mailto:application...@ecocuyo.de>>:
>>> 
>>> Hallo Andreas,
>>> 
>>> Fehler sind das nicht unbedingt, vielmehr sind das weitere Register für 
>>> IDs, Tamper…
>>> Beispielsweise wäre C.60.9 = Fraud flag, nur das kommt bei dem Zähler gar 
>>> nicht vor.
>>> 
>>> Jedoch wirft der Zähler für C.60.5.2 folgendes aus (Hardware ID 
>>> (=Revision.Produktzustand)):
>>> 
>>> C.60.5.2(07.000   0998 B7FD)(12-11-16 06:32)Line: 'C.60.5.2(07.000  
>>>  0998 B7FD)(12-11-16 06:32)
>>> 
>>> Siehe 
>>> http://www.ooe-ausfuehrungsbestimmungen.at/assets/download/AMIS-Zaehler.pdf 
>>> <http://www.ooe-ausfuehrungsbestimmungen.at/assets/download/AMIS-Zaehler.pdf>
>>> 
>>> Für die Energiezählung, Leistung-, Spannungs-, Strom- und Phasenmessung 
>>> sind diese Codes m.E. unerheblich.
>>> 
>>> Hilft das?
>>> 
>>> Beste Grüße
>>> Armin
>>> 
>>>> Am 15.01.2016 um 17:38 schrieb Andreas Goetz >>> <mailto:cpui...@gmail.com>>:
>>>> 
>>>> Bei log_level=0 werden nur Fehler geloggt- das sind Fehler. Mich würde 
>>>> eher interessieren ob wir in der Lage sein sollten diesen Obis Code nicht 
>>>> als Fehler zu interpretieren?
>>>> 
>>>> Viele Grüße,
>>>> Andreas
>>>> 
>>>> 
>>>> On Fri, Jan 15, 2016 at 10:45 AM, application MGR 
>>>> mailto:application...@ecocuyo.de>> wrote:
>>>> Hallo zusammen,
>>>> 
>>>> eine Frage zu Log-Einträgen bei einer Konfiguration mit einem Siemens 
>>>> TD3511 D0-Zähler:
>>>> 
>>>> Einstellung in der vzlogger.conf_
>>>> 
>>>> "verbosity" : 0,  /* 0 = log_error or log-warning, 5 = 
>>>> log_info, 10 = log-debug, 15 = log_finest */
>>>>   "log" : "/var/log/vzlogger.log",  /* path to logfile, optional */
>>>> 
>>>> 
>>>> Weil der Zähler an vzlogger unbekannte OBIS-Codes auswirft, schreibt er 
>>>> fortlaufend folgende Meldungen in die vzlogger.log-Datei, die dadurch 
>>>> massiv anschwillt:
>>>> 
>>>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.1)
>>>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.2)
>>>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.1)
>>>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.2)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.3)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.4)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.5)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.6)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.1)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.2)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.3)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.4)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.5)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.6)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.1)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.2)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.3)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.4)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.5)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.6)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.7)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.11)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.13)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.14)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.15)
>>>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.16)
>>>> 
>>>> Wie kann man das unterbinden ohne das Logging komplett abzuschalten? 
>>>> 
>>>> Beste Grüße
>>>> Armin
>>>> 
>>> 
>> 
>> Gruß
>> 
>> Matthias
>> 

Gruß

Matthias

Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen

[Matthias Behr]

/EMH4\@--ITZ-G0038E

die 4 steht für 4800 Baud. 

Ich frage mich, ob du Reflexionen am Lesekopf hast:
 /?420818!

>>>>> 54.417798573s (33 ms) 
2f 3f 34 32 30 38 31 38 21/?420818!

da kommt genau die Anforderungsseq zurück.

Kannst du mal ackseq:auto machen und baudrate_change_delay:100 und mir Dump 
schicken?

(Falls du mir Zugriff per ssh geben kannst, könnte ich auch mal direkt drauf 
schauen.)



> Am 16.01.2016 um 14:56 schrieb Winfried Peters :
> 
> Deine Hinweise sind interessant. Ich habe schon mehrere Dutzend 
> Parametervarianten erfolglos durchdekliniert. Da waren auch kleinere 
> baudrate_change_delay dabei als auch ackseq-Sequenzen von 300 bis 9600 Baud. 
> Ich hatte z.B. schon mal mit "ackseq": "063034300d0a“ und "baudrate_read": 
> 4800 oder "ackseq": "auto“ erfolglos experimentiert.
> 
> read_timeout ist deshalb so groß, weil ein kompletter Lesezyklus des 
> übermittelten Zählertelegramms ca. 90 Sekunden (mit Baud 300) benötigt. Bei 
> kleineren Werten erfolgte immer ein Timeout.
> 
> Wahrscheinlicht liegt das Geheimnis ja in der richtigen Parameterkombination. 
> Laut Auskunft meines Stromnetzbetreibers ist der Zähler mit 2400 oder 4800 
> Baud auszulesen. Das habe ich aber weder mit HTerm als auch mit verschiedenen 
> vzlogger-Parameterkombinationen hinbekommen. Nur 300 Baud hat funktioniert.
> 
> Aber vielleicht hat ja bei meinen Versuchen immer der "read_timeout 100" im 
> Weg gestanden. Ich werde weiter testen. Inzwischen habe ich dazu das Issue 
> #233 aufgemacht.
> 
> Woran erkennst Du, dass mein Zähler mit 4800 Baud kommunizieren will?
> 
> Viele Grüße
> 
> Am 16. Januar 2016 um 14:07 schrieb Matthias Behr  <mailto:mb...@mcbehr.de>>:
> Hast du mal 
> baudrate_change_delay
> 
> kleiner gemacht?
> 
> Und mal „ackseq“: „auto“ probiert? (Bist du sicher, dass der Logger kein 
> ACKSEQ braucht? Er meldet, dass er eigentlich mit Baudrate 4800 arbeiten 
> will. Normalerweise erfolgt nach der Pullseq mit 300 Baud eine Baudraten 
> Umschaltung.
> 
> Und mach mal „read_timeout“ kleiner. Das 100 ist eher störend.d
> 
>> Am 16.01.2016 um 13:42 schrieb Winfried Peters > <mailto:winfried.pet...@gmail.com>>:
>> 
>> Hallo,
>> 
>> "vzlogger.conf.conf" war ein Schreibfehler. Grundsätzlich habe ich mit dem 
>> Aufruf "vzlogger -c /etc/vzlogger.conf -l" keine Probleme. HTTPd wird damit 
>> gestartet.
>> 
>> @Andreas: Ich werde ein Issue aufmachen.
>> 
>> Viele Grüße
>> Winfried
>> 
>> Am 16. Januar 2016 um 11:16 schrieb Udo1 > <mailto:u...@gmx.net>>:
>> Am 16.01.2016 um 10:06 schrieb Winfried Peters:
>> [Jan 16 09:48:17][main] vzlogger v0.5.1 based on 
>> heads/master-0-g11364f0d0d-dirty from Sat, 22 Aug 2015 09:23:50 -0700 
>> started.
>> Zur Klarstellung. Es handelt sich hierbei um einen YPORT+ auf OpenWrt-Basis. 
>> vzlogger ist die aktuelle Version. Die Meldung ist falsch:
>> based on heads/master-0-g11364f0d0d-dirty from Sat, 22 Aug 2015 09:23:50 
>> -0700
>> 
>> root@OpenWrt:/etc# vzlogger -c vzlogger.conf.conf -l
>> Der Aufruf ist mir immer noch suspekt. Kann man vzlogger so aufrufen?
>> 
>> Gruß
>> Udo
>> 
> 
> Gruß
> 
> Matthias
> 
> 

Gruß

Matthias

Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen

[Matthias Behr]

Hast du mal 
baudrate_change_delay

kleiner gemacht?

Und mal „ackseq“: „auto“ probiert? (Bist du sicher, dass der Logger kein ACKSEQ 
braucht? Er meldet, dass er eigentlich mit Baudrate 4800 arbeiten will. 
Normalerweise erfolgt nach der Pullseq mit 300 Baud eine Baudraten Umschaltung.

Und mach mal „read_timeout“ kleiner. Das 100 ist eher störend.d

> Am 16.01.2016 um 13:42 schrieb Winfried Peters :
> 
> Hallo,
> 
> "vzlogger.conf.conf" war ein Schreibfehler. Grundsätzlich habe ich mit dem 
> Aufruf "vzlogger -c /etc/vzlogger.conf -l" keine Probleme. HTTPd wird damit 
> gestartet.
> 
> @Andreas: Ich werde ein Issue aufmachen.
> 
> Viele Grüße
> Winfried
> 
> Am 16. Januar 2016 um 11:16 schrieb Udo1 mailto:u...@gmx.net>>:
> Am 16.01.2016 um 10:06 schrieb Winfried Peters:
> [Jan 16 09:48:17][main] vzlogger v0.5.1 based on 
> heads/master-0-g11364f0d0d-dirty from Sat, 22 Aug 2015 09:23:50 -0700 started.
> Zur Klarstellung. Es handelt sich hierbei um einen YPORT+ auf OpenWrt-Basis. 
> vzlogger ist die aktuelle Version. Die Meldung ist falsch:
> based on heads/master-0-g11364f0d0d-dirty from Sat, 22 Aug 2015 09:23:50 -0700
> 
> root@OpenWrt:/etc# vzlogger -c vzlogger.conf.conf -l
> Der Aufruf ist mir immer noch suspekt. Kann man vzlogger so aufrufen?
> 
> Gruß
> Udo
> 

Gruß

Matthias

Re: [vz-users] Einträge in die vzlogger.log unterdrücken?

[Matthias Behr]

Das Problem ist, dass die nicht der 
IEC 62056-21 entsprechen.

Erlaubt wäre höchtens ein C.60.5*2 aber nicht ein C.60.5.2.

Ich könnte aber den Loglevel eins höher setzen Fehler sind ja nicht wirklich 
kritisch. Soll ich das tun?

 
> Am 15.01.2016 um 18:12 schrieb application MGR :
> 
> Hallo Andreas,
> 
> Fehler sind das nicht unbedingt, vielmehr sind das weitere Register für IDs, 
> Tamper…
> Beispielsweise wäre C.60.9 = Fraud flag, nur das kommt bei dem Zähler gar 
> nicht vor.
> 
> Jedoch wirft der Zähler für C.60.5.2 folgendes aus (Hardware ID 
> (=Revision.Produktzustand)):
> 
>   C.60.5.2(07.000   0998 B7FD)(12-11-16 06:32)Line: 'C.60.5.2(07.000  
>  0998 B7FD)(12-11-16 06:32)
> 
> Siehe 
> http://www.ooe-ausfuehrungsbestimmungen.at/assets/download/AMIS-Zaehler.pdf 
> 
> 
> Für die Energiezählung, Leistung-, Spannungs-, Strom- und Phasenmessung sind 
> diese Codes m.E. unerheblich.
> 
> Hilft das?
> 
> Beste Grüße
> Armin
> 
>> Am 15.01.2016 um 17:38 schrieb Andreas Goetz > >:
>> 
>> Bei log_level=0 werden nur Fehler geloggt- das sind Fehler. Mich würde eher 
>> interessieren ob wir in der Lage sein sollten diesen Obis Code nicht als 
>> Fehler zu interpretieren?
>> 
>> Viele Grüße,
>> Andreas
>> 
>> 
>> On Fri, Jan 15, 2016 at 10:45 AM, application MGR > > wrote:
>> Hallo zusammen,
>> 
>> eine Frage zu Log-Einträgen bei einer Konfiguration mit einem Siemens TD3511 
>> D0-Zähler:
>> 
>> Einstellung in der vzlogger.conf_
>> 
>> "verbosity" : 0,  /* 0 = log_error or log-warning, 5 = 
>> log_info, 10 = log-debug, 15 = log_finest */
>>   "log" : "/var/log/vzlogger.log",  /* path to logfile, optional */
>> 
>> 
>> Weil der Zähler an vzlogger unbekannte OBIS-Codes auswirft, schreibt er 
>> fortlaufend folgende Meldungen in die vzlogger.log-Datei, die dadurch massiv 
>> anschwillt:
>> 
>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.1)
>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.2)
>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.1)
>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.2)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.3)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.4)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.5)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.6)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.1)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.2)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.3)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.4)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.5)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.6)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.1)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.2)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.3)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.4)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.5)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.6)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.7)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.11)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.13)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.14)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.15)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.16)
>> 
>> Wie kann man das unterbinden ohne das Logging komplett abzuschalten? 
>> 
>> Beste Grüße
>> Armin
>> 
> 

Gruß

Matthias

Re: [vz-users] Syntax Fehler in vzlogger.conf

[Matthias Behr]

Was steht denn da in Zeile 77?
je nach gcc Version wird doch entweder nur whitespaces oder whitespaces und 
Kommentare mit // erlaubt.


> Am 16.01.2016 um 11:19 schrieb Udo1 :
> 
> Am 16.01.2016 um 10:55 schrieb Oliver OF. Friedrichs:
>> [Jan 16 10:27:44][main] vzlogger v0.5.1 based on heads/master-0-gf4a1f98bbf 
>> from Tue, 5 Jan 2016 08:10:50 +0100 started.
>> [Jan 16 10:27:44]   extra data after end of configuration in 
>> /etc/vzlogger.conf:77
>> [Jan 16 10:27:44]   Failed to parse configuration due to: extra data 
>> after end of configuration
> Steht doch da. Du hast hinter der letzten Klammer noch Daten oder Leerzeilen 
> eingefügt.
> 
> @Matthias. Ich dachte das wäre Geschichte in der vzlogger-Version?
> 
> Gruß
> Udo

Gruß

Matthias

Re: [vz-users] Einträge in die vzlogger.log unterdrücken?

[Matthias Behr]

Ich bereite Änderung vor, damit die Einträge korrekt ausgewertet werden.


> Am 15.01.2016 um 18:12 schrieb application MGR :
> 
> Hallo Andreas,
> 
> Fehler sind das nicht unbedingt, vielmehr sind das weitere Register für IDs, 
> Tamper…
> Beispielsweise wäre C.60.9 = Fraud flag, nur das kommt bei dem Zähler gar 
> nicht vor.
> 
> Jedoch wirft der Zähler für C.60.5.2 folgendes aus (Hardware ID 
> (=Revision.Produktzustand)):
> 
>   C.60.5.2(07.000   0998 B7FD)(12-11-16 06:32)Line: 'C.60.5.2(07.000  
>  0998 B7FD)(12-11-16 06:32)
> 
> Siehe 
> http://www.ooe-ausfuehrungsbestimmungen.at/assets/download/AMIS-Zaehler.pdf 
> 
> 
> Für die Energiezählung, Leistung-, Spannungs-, Strom- und Phasenmessung sind 
> diese Codes m.E. unerheblich.
> 
> Hilft das?
> 
> Beste Grüße
> Armin
> 
>> Am 15.01.2016 um 17:38 schrieb Andreas Goetz > >:
>> 
>> Bei log_level=0 werden nur Fehler geloggt- das sind Fehler. Mich würde eher 
>> interessieren ob wir in der Lage sein sollten diesen Obis Code nicht als 
>> Fehler zu interpretieren?
>> 
>> Viele Grüße,
>> Andreas
>> 
>> 
>> On Fri, Jan 15, 2016 at 10:45 AM, application MGR > > wrote:
>> Hallo zusammen,
>> 
>> eine Frage zu Log-Einträgen bei einer Konfiguration mit einem Siemens TD3511 
>> D0-Zähler:
>> 
>> Einstellung in der vzlogger.conf_
>> 
>> "verbosity" : 0,  /* 0 = log_error or log-warning, 5 = 
>> log_info, 10 = log-debug, 15 = log_finest */
>>   "log" : "/var/log/vzlogger.log",  /* path to logfile, optional */
>> 
>> 
>> Weil der Zähler an vzlogger unbekannte OBIS-Codes auswirft, schreibt er 
>> fortlaufend folgende Meldungen in die vzlogger.log-Datei, die dadurch massiv 
>> anschwillt:
>> 
>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.1)
>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.60.5.2)
>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.1)
>> [Jan 15 10:36:58][d0]   Failed to parse obis code (C.1.8.2)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.3)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.4)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.5)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.1.8.6)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.1)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.2)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.3)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.4)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.5)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.2.8.6)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.1)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.2)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.3)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.4)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.5)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.6)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.7)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.11)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.13)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.14)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.15)
>> [Jan 15 10:36:59][d0]   Failed to parse obis code (C.60.4.16)
>> 
>> Wie kann man das unterbinden ohne das Logging komplett abzuschalten? 
>> 
>> Beste Grüße
>> Armin
>> 
> 

Gruß

Matthias

Re: [vz-users] vzlogger - w1herm kompatibel zu DS2482-800?

[Matthias Behr]

Gesucht wird nach den folgenden Geräten:
/sys/bus/w1/devices/{10,22,28,3b,42}-*

Mach mal ein 
ls -al /sys/bus/w1/devices

wenn deine Geräte mit 10,22,28, 3b oder 42 anfängt, wird es unterstützt.

(Wenn nicht müssen wir das einbauen ;-)

> Am 14.01.2016 um 17:00 schrieb Thomas Oeding :
> 
> Hallo Liste,
> 
> ich nutze an meinem Raspberry Pi einen DS2482(-800) um DS18B20 
> Temperatur-Sensoren auszulesen.
> 
> Funktioniert dieses auch mit vzlogger? Auf der Wiki Seite ist nur der DS2582 
> erwähnt.
> Weitere Dokumentation konnte ich leider nicht finden.
> 
> Grüße
> Thomas

Gruß

Matthias

Re: [vz-users] S0-Werte aggregieren nur mit "aggfixedinterval": true

[Matthias Behr]

ok, zwar komischer Anwendungsfall, aber zumindest verstehe ich nun, dass es 
jemand nutzt.

Hinweis: bei aggmode AVG ist die Berechnung dann falsch (was bei hohen 
Impulsen/Events nichts ausmacht, bei wenigen aber prozentual schon hoch werden 
kann).

> Am 08.01.2016 um 09:59 schrieb sollner11 :
> 
> 
>> ...da dadurch die Timestamps verfälscht werden. Das macht _nur_ dann Sinn 
>> wenn man- z.B. für Rechenzwecke- identische Timestamps über mehrere Kanäle 
>> braucht.
> 
> ja, wie bei mir, vor Jahren dankenswerter Weise von Peter Evertz, Jan Tamm in 
> den vzlogger reinoperiert
> läuft wunderbar bei aggtime = 300 !!!
> brauche ich für die Auswertung Solar
> und zur Berechnung des Gesamtverbrauch
> also drei Werte auf gleichem Timestamp obwohl von 2 Zählern kommend
> 
> das bleibt mir wichtig
> bei aller Wissenschaftlichkeit ;-)
> 
>> Sollen wir aggfixedinterval ausbauen?
> 
> Bitte nur, wenn das o.g. erhalten bleibt
> 
> 
> Danke und Gruss
> Sollner

Gruß

Matthias