Re: [vz-users] SML meter hängt sich auf
Hallo Rupert, danke für deine Hinweise. Ich musste erst mal Deinen Thread vom November 2019 lesen, um zu verstehen, was Dich zu diesem Setting bewegt hat... Warum fahre ich zwei vzlogger-Instanzen? Ich werte die vzlogger-Daten nur über HTTPd aus. Die S0-Werte puffere ich über eine Stunde. Damit kann ich Ausfälle meiner Auswerte-SW überbrücken. Bei einer Pufferung von einer Stunde für die S0-Werte kamen mit einer vzlogger-Instanz mit zwei meters-Konfigurationen zu viele SML-Tupel an. Solange das duplicate-Feature für das SML-Protokoll noch nicht implementiert ist (ich habe vor Jahren dafür mal ein Feature-Request gestellt: Support "duplicates" for httpd #397 <https://github.com/volkszaehler/vzlogger/issues/397> ), muss ich als Workaround zwei vzlogger-Instanzen mit jeweils einer meters-Konfiguration fahren. Das hat bisher funktioniert. Hast du "vor ein paar Wochen" was geändert, z.B. ein Update eingespielt? Ich habe Ende letzten Jahres meinen Verbrauchszähler-Rechner mit Bullseye neu aufgesetzt. In unregelmäßigen Abständen führe ich auch OS-Updates aus. Dann habe ich Anfang diesen Jahres zwei weitere Verbrauchszähler über einen USB-Hub an meinen Beaglebone angeschlossen, deren Daten aber nicht über vzlogger verarbeitet werden. Insgesamt sind drei USB-Geräte an den Hub angeschlossen. Ich habe einen verdächtigen syslog-Eintrag gefunden, der mit dem vzloggerSML-Ausstiegszeitpunkt einigermaßen korreliert: Jun 22 14:28:05 bbb2 kernel: [6563983.887425] musb-hdrc musb-hdrc.1: ep3 RX three-strikes error Jun 22 14:28:05 bbb2 kernel: [6563983.893433] musb-hdrc musb-hdrc.1: ep12 RX three-strikes error Der musb-Treiber-Fehler scheint auf eine kurzfristige USB-Unterbrechung hinzudeuten. Ob das die Ursache für den vzloggerSML-Ausstieg war, kann ich nicht beurteilen. Inzwischen habe ich als Workaround ein Watchdog aufgesetzt, der nach fünf Minuten Stille auf dem Kanal ein Restart von vzloggerSML durchführt. Viele Grüße, Winfried Am So., 25. Juni 2023 um 12:43 Uhr schrieb Rupert Schöttler < rupert.schoett...@gmx.de>: > Hallo Winfried, > > die Experten sind scheint's grad nicht online, daher versuche ich mich mal > :-) > > > Am 23.06.23 um 11:45 schrieb Winfried Peters: > > Ich betreibe seit vielen Jahren zwei vzlogger-Instanzen (vzloggerS0 und > vzloggerSML) auf einem Beaglebone (aktuell mit Debian v11.7) ohne > nennenswerte Probleme. > > Ich musste erst mal Deinen Thread vom November 2019 lesen, um zu > verstehen, was Dich zu diesem Setting bewegt hat... > > > Seit ein paar Wochen stellt die SML-Meter-Instanz regelmäßig nach einer > Zeit von ca. 1 bis 2 Wochen ihren Dienst ein. Es werden keine Werte mehr > gelesen. > > Hast du "vor ein paar Wochen" was geändert, z.B. ein Update eingespielt? > > > Nach einem Service-Restart liefert der Service wieder Daten, bis er nach > besagtem Zeitraum seinen Dienst wieder einstellt. > > Als "Würg-around" ein > > sudo systemctl restart vzloggerSML > > per cron tgl. nachts, wenn die PV-Anlage eh keine neue Daten liefert? > > > Viele Grüße, Rupert >
[vz-users] SML meter hängt sich auf
Ich betreibe seit vielen Jahren zwei vzlogger-Instanzen (vzloggerS0 und
vzloggerSML) auf einem Beaglebone (aktuell mit Debian v11.7) ohne
nennenswerte Probleme. Seit ein paar Wochen stellt die SML-Meter-Instanz
regelmäßig nach einer Zeit von ca. 1 bis 2 Wochen ihren Dienst ein. Es
werden keine Werte mehr gelesen. Nach einem Service-Restart liefert der
Service wieder Daten, bis er nach besagtem Zeitraum seinen Dienst wieder
einstellt. Die Service-Instanz meines S0 meters macht keine Probleme und
läuft durch. Das vzlogger-Upgrade auf v0.8.2 hat das Problem leider nicht
beseitigt.
Mein Verbose 10-Log zeigt folgende Einträge:
[Jun 22 22:12:18][http] Local request received: method=GET url=/180
mode=(null)
[Jun 22 22:12:18][180] ==> number of tuples: 1
[Jun 22 22:12:20][http] Local request received: method=GET url=/167
mode=(null)
[Jun 22 22:12:20][167] ==> number of tuples: 1
[Jun 22 22:12:20][http] Local request received: method=GET url=/280
mode=(null)
[Jun 22 22:12:20][280] ==> number of tuples: 1
[Jun 22 22:14:18][http] Local request received: method=GET url=/180
mode=(null)
[Jun 22 22:14:18][180] ==> number of tuples: 1
[Jun 22 22:14:20][http] Local request received: method=GET url=/167
mode=(null)
[Jun 22 22:14:20][167] ==> number of tuples: 1
[Jun 22 22:14:20][http] Local request received: method=GET url=/280
mode=(null)
[Jun 22 22:14:20][280] ==> number of tuples: 1
Hier mein, bis auf den hohen Ressourcenbedarf, unauffälligen Service-Status:
debian@bbb2:~$ sudo systemctl status vzloggerSML
● vzloggerSML.service - vzloggerSML
Loaded: loaded (/etc/systemd/system/vzloggerSML.service; enabled;
vendor preset: enabled)
Active: active (running) since Thu 2023-06-08 14:20:22 CEST; 2 weeks 0
days ago
Main PID: 3710 (vzlogger)
Tasks: 6 (limit: 1026)
Memory: 112.1M
CPU: 13h 28min 52.150s
CGroup: /system.slice/vzloggerSML.service
└─3710 /usr/local/bin/vzlogger -c /etc/vzloggerSML.conf
Hier meine vzloggerSML-Konfiguration:
// vzlogger.conf with sml (Strom)
{
"daemon": true,
"verbosity": 10,
"log": "/var/log/vzloggerSML.log",
"retry": 30,// http retry delay in seconds
// Build-in HTTP server
"local": {
"enabled": true,
"port": 8081,
"index": true,
"timeout": 30,
"buffer": -1
},
// Meter configuration
"meters": [
// sml meter (Strom)
{
"enabled": true,
"protocol": "sml",
"device": "/dev/ttyUSB0",
"baudrate": 9600,
"parity": "8n1",
"use_local_time": true,
"skip": false,
"channels": [
{
"uuid": "180",
"identifier": "*1-0:1.8.0*", // counter 1-0:1.8.0
Zaehlerstand Bezug [Wh]
"api": "null",
"duplicates": 300
},
{
"uuid": "167",
"identifier": "*1-0:16.7.0*",// 1-0:16.7.0 Momentanleistung
[W]
"api": "null",
"duplicates": 300
},
{
"uuid": "280",
"identifier": "*1-0:2.8.0*", // counter-out 1-0:2.8.0
Zaehlerstand Einspeisung [Wh]
"api": "null",
"duplicates": 3600
}
]
}
]
}
Hat jemand eine Idee, was das Problem ist oder wie ich das Problem weiter
eingrenzen kann?
Ich bin für jeden Tipp dankbar.
Viele Grüße
Winfried
Re: [vz-users] Mehrere vzlogger-Instanzen auf einem System?
Guten Abend Justin, Yepp, das war der entscheidende Tipp. Es hat sich tatsächlich ein falsches Minuszeichen eingeschlichen. Man muss schon ganz genau hinschauen, um einen Unterschied zu entdecken. Mehrere Augen sehen einfach besser. Da ich den Befehl aus Bequemlichkeitsgründen immer nur mit Copy&Paste einsetze, ist daraus ein systematischer Fehler geworden, der sich aber bisher bei mir noch nie ausgewirkt hat - bis jetzt. Nun funktioniert mein Workaround so wie erwartet. Nochmal vielen Dank an die Community für den regen Austausch und die Lösungsfindung. Viele Grüße Winfried Am Mi., 27. Nov. 2019 um 19:53 Uhr schrieb Justin Otherguy < jus...@justinotherguy.org>: > Moin, > > > Am 26.11.2019 um 23:34 schrieb Winfried Peters < > winfried.pet...@gmail.com>: > > > > Und hier die Ausgabe mit Doppelminus-Option: > > debian@bbb1:/var/log$ sudo vzlogger –-config /etc/vzlogger.conf > > Das, was da vor "config" steht, sind keine zwei regulären "-"-Zeichen :) > > Bitte mal von Hand tippen - dann sollte 1. die Option ziehen (und somit 2 > unterschiedliche Configs aktiviert werden) und 2. die Fragezeichen im > ps-Output verschwinden :) > > > Gruß, J. > >
Re: [vz-users] Mehrere vzlogger-Instanzen auf einem System?
Und hier die Ausgabe mit Doppelminus-Option:
debian@bbb1:/var/log$ sudo vzlogger –-config /etc/vzlogger.conf
[Nov 26 23:28:28][main] vzlogger v0.8.0 based on heads/master-0-g3c4ef603cb
from Sun, 18 Aug 2019 09:36:53 +0200 started.
[Nov 26 23:28:28][main] log level is 3
debian@bbb1:/var/log$ sudo vzlogger –-config /etc/vzloggerS0.conf
[Nov 26 23:28:47][main] vzlogger v0.8.0 based on heads/master-0-g3c4ef603cb
from Sun, 18 Aug 2019 09:36:53 +0200 started.
[Nov 26 23:28:47][main] log level is 3
debian@bbb1:/var/log$ ps -ef | grep vzlogger
root 3534 1 2 23:28 ?00:00:00 vzlogger ???-config
/etc/vzlogger.conf
root 3542 1 1 23:28 ?00:00:00 vzlogger ???-config
/etc/vzloggerS0.conf
debian3549 3394 0 23:29 pts/000:00:00 grep vzlogger
Die Fragezeichen bleiben...
Erstmal vielen Dank für die Fragen und Anregungen. Für heute mache ich
Schluss.
Gute Nacht
Winfried
Am Di., 26. Nov. 2019 um 23:23 Uhr schrieb Winfried Peters <
winfried.pet...@gmail.com>:
> Klar. Hier Konfiguration der 1. Instanz:
> cat vzlogger.conf
> // vzlogger.conf with sml (Strom)
> {
> "daemon": true,
> "verbosity": 3,
> "log": "/var/log/vzlogger.log",
> "retry": 30,// http retry delay in seconds
> // Build-in HTTP server
> "local": {
> "enabled": true,
> "port": 8080,
> "index": true,
> "timeout": 30,
> "buffer": -1
> },
> // Meter configuration
> "meters": [
> // sml meter (Strom)
> {
> "enabled": true,
> "protocol": "sml",
> "device": "/dev/ttyUSB0",
> "baudrate": 9600,
> "parity": "8n1",
> "use_local_time": true,
> "skip": false,
> "channels": [
>{
> "uuid": "180a",
> "identifier": "1-0:1.8.0", // counter 1-0:1.8.0 Zaehlerstand
> Bezug [Wh]
> "api": "null",
> "duplicates": 300
>},
>{
> "uuid": "180b",
> "identifier": "1-0:16.7.0",// 1-0:16.7.0 Momentanleistung [W]
> "api": "null",
> "duplicates": 300
>},
>{
> "uuid": "180c",
> "identifier": "1-0:2.8.0", // counter-out 1-0:2.8.0
> Zaehlerstand Einspeisung [Wh]
> "api": "null",
> "duplicates": 3600
>}
> ]
> }
> ]
> }
>
> Und hier die Konfiguration der 2. Instanz:
> cat vzloggerS0.conf
> // vzloggerS0.conf only S0 meter
> {
> "daemon": true,
> "verbosity": 3,
> "log": "/var/log/vzloggerS0.log",
> "retry": 30,// http retry delay in seconds
> // Build-in HTTP server
> "local": {
> "enabled": true,
> "port": 8081,
> "index": true,
> "timeout": 30,
> "buffer": 300
> },
> // Meter configuration
> "meters": [
> // S0 meter S0.0 GPIO 27 (Wasser)
> {
> "enabled": true,
> "allowskip": false,
> "interval": -1,
> "aggtime": 60,
> "aggfixedinterval": false,
> "channels": [
> {
> "uuid": "121e",
> "identifier": "Power",
> "api": "null",
> "aggmode": "avg",
> "duplicates": 0
> },
> {
> "uuid": "121a",
> "identifier": "Impulse",
> "api": "null",
> "aggmode": "sum",
> "duplicates": 0
> }
> ],
> "protocol": "s0",
> "gpio": 27,
> "configureGPIO": true,
> "resolution": 1,
> "send_zero": true,
> "debounce_delay": 10
> }
> ]
> }
>
> Viele Grüße
> Winfried
>
> Am Di., 26. Nov. 2019 um 22:31 Uhr schrieb Andreas Goetz <
> cpui...@gmail.com>:
>
>> Könntest Du Deine Konfigurationen teilen?
>>
>> Viele Grüße, Andreas
>>
>>
>> On 26. Nov 2019, at 22:23, Winfried Peters
>> wrote:
>>
>> Hallo Daniel,
>>
>> das mit der systemctl-Kontrolle habe ich jetzt verstanden. Wie ich
>> geschrieben habe, wird trotz config-Definition leider kein zweites Log-File
>> angelegt. Im syslog gibt es auch keine Hinweise. Ich kann ohne Hilfe
>> zurzeit leider keine weiteren Infos liefern.
>>
>> Viele Grüße
>> Winfried
>>
>>
>> Am Di., 26. Nov. 2019 um 22:03 Uhr schrieb Daniel Lauckner :
>>
>>> Hallo,
>>>
>>>
>>> wenn man die Anwendung manuell startet
>>>
>>> > debian@bbb1:/etc$ sudo vzlogger –c /etc/vzlogger.conf
>>>
>>> hat systemctl auch keine Kontrolle über die Instanz.
>>>
>>> > debian@bbb1:/var/log$ sudo systemctl status vzlogger
>>>
>>> Deswegen kommt da Käse bei raus.
>>>
>>> Wenn du also wissen willst warum die zweite Instanz nicht wie erwartet
>>> arbeitet schau dir das Logfile zur zweiten Instanz an. Sind ja
>>> hoffentlich zwei konfiguriert.
>>>
>>>
>>> mfg Daniel
>>>
>>>
>>
Re: [vz-users] Mehrere vzlogger-Instanzen auf einem System?
Klar. Hier Konfiguration der 1. Instanz:
cat vzlogger.conf
// vzlogger.conf with sml (Strom)
{
"daemon": true,
"verbosity": 3,
"log": "/var/log/vzlogger.log",
"retry": 30,// http retry delay in seconds
// Build-in HTTP server
"local": {
"enabled": true,
"port": 8080,
"index": true,
"timeout": 30,
"buffer": -1
},
// Meter configuration
"meters": [
// sml meter (Strom)
{
"enabled": true,
"protocol": "sml",
"device": "/dev/ttyUSB0",
"baudrate": 9600,
"parity": "8n1",
"use_local_time": true,
"skip": false,
"channels": [
{
"uuid": "180a",
"identifier": "1-0:1.8.0", // counter 1-0:1.8.0 Zaehlerstand
Bezug [Wh]
"api": "null",
"duplicates": 300
},
{
"uuid": "180b",
"identifier": "1-0:16.7.0",// 1-0:16.7.0 Momentanleistung [W]
"api": "null",
"duplicates": 300
},
{
"uuid": "180c",
"identifier": "1-0:2.8.0", // counter-out 1-0:2.8.0
Zaehlerstand Einspeisung [Wh]
"api": "null",
"duplicates": 3600
}
]
}
]
}
Und hier die Konfiguration der 2. Instanz:
cat vzloggerS0.conf
// vzloggerS0.conf only S0 meter
{
"daemon": true,
"verbosity": 3,
"log": "/var/log/vzloggerS0.log",
"retry": 30,// http retry delay in seconds
// Build-in HTTP server
"local": {
"enabled": true,
"port": 8081,
"index": true,
"timeout": 30,
"buffer": 300
},
// Meter configuration
"meters": [
// S0 meter S0.0 GPIO 27 (Wasser)
{
"enabled": true,
"allowskip": false,
"interval": -1,
"aggtime": 60,
"aggfixedinterval": false,
"channels": [
{
"uuid": "121e",
"identifier": "Power",
"api": "null",
"aggmode": "avg",
"duplicates": 0
},
{
"uuid": "121a",
"identifier": "Impulse",
"api": "null",
"aggmode": "sum",
"duplicates": 0
}
],
"protocol": "s0",
"gpio": 27,
"configureGPIO": true,
"resolution": 1,
"send_zero": true,
"debounce_delay": 10
}
]
}
Viele Grüße
Winfried
Am Di., 26. Nov. 2019 um 22:31 Uhr schrieb Andreas Goetz :
> Könntest Du Deine Konfigurationen teilen?
>
> Viele Grüße, Andreas
>
>
> On 26. Nov 2019, at 22:23, Winfried Peters
> wrote:
>
> Hallo Daniel,
>
> das mit der systemctl-Kontrolle habe ich jetzt verstanden. Wie ich
> geschrieben habe, wird trotz config-Definition leider kein zweites Log-File
> angelegt. Im syslog gibt es auch keine Hinweise. Ich kann ohne Hilfe
> zurzeit leider keine weiteren Infos liefern.
>
> Viele Grüße
> Winfried
>
>
> Am Di., 26. Nov. 2019 um 22:03 Uhr schrieb Daniel Lauckner :
>
>> Hallo,
>>
>>
>> wenn man die Anwendung manuell startet
>>
>> > debian@bbb1:/etc$ sudo vzlogger –c /etc/vzlogger.conf
>>
>> hat systemctl auch keine Kontrolle über die Instanz.
>>
>> > debian@bbb1:/var/log$ sudo systemctl status vzlogger
>>
>> Deswegen kommt da Käse bei raus.
>>
>> Wenn du also wissen willst warum die zweite Instanz nicht wie erwartet
>> arbeitet schau dir das Logfile zur zweiten Instanz an. Sind ja
>> hoffentlich zwei konfiguriert.
>>
>>
>> mfg Daniel
>>
>>
>
Re: [vz-users] Mehrere vzlogger-Instanzen auf einem System?
Hallo Daniel, das mit der systemctl-Kontrolle habe ich jetzt verstanden. Wie ich geschrieben habe, wird trotz config-Definition leider kein zweites Log-File angelegt. Im syslog gibt es auch keine Hinweise. Ich kann ohne Hilfe zurzeit leider keine weiteren Infos liefern. Viele Grüße Winfried Am Di., 26. Nov. 2019 um 22:03 Uhr schrieb Daniel Lauckner : > Hallo, > > > wenn man die Anwendung manuell startet > > > debian@bbb1:/etc$ sudo vzlogger –c /etc/vzlogger.conf > > hat systemctl auch keine Kontrolle über die Instanz. > > > debian@bbb1:/var/log$ sudo systemctl status vzlogger > > Deswegen kommt da Käse bei raus. > > Wenn du also wissen willst warum die zweite Instanz nicht wie erwartet > arbeitet schau dir das Logfile zur zweiten Instanz an. Sind ja > hoffentlich zwei konfiguriert. > > > mfg Daniel > >
Re: [vz-users] Mehrere vzlogger-Instanzen auf einem System?
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 < > winfried.pet...@gmail.com>: > > > > > > 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 > > > > >
[vz-users] Mehrere vzlogger-Instanzen auf einem System?
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
[vz-users] vzlogger-Cross-Compile für OpenWrt
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 2
Hier mein Makefile dazu:
-
include $(TOPDIR)/rules.mk
PKG_NAME:=vzlogger
PKG_VERSION:=master
PKG_RELEASE:=1
PKG_REV:=master
PKG_FIXUP:=autoreconf
PKG_BUILD_DEPENDS:=libmosquitto libsml libmicrohttpd libjson libcurl
libopenssl libstdcpp libgcrypt librt libsasl2
#PKG_BUILD_DEPENDS:=sml microhttpd json curl openssl stdcpp gcrypt rt sasl2
#PKG_BUILD_PARALLEL:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=git://github.com/volkszaehler/vzlogger.git
PKG_SOURCE_VERSION:=$(PKG_REV)
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
PKG_SOURCE_PROTO:=git
CMAKE_INSTALL:=1
include $(INCLUDE_DIR)/package.mk
include $(INCLUDE_D
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Hallo Andreas, Frank hat geschrieben, dass "duplicates" nur für die Volkszähler-API implementiert ist. Wenn dem so ist, habe ich die Anforderung "duplicates" für HTTPd zu implementieren, so dass ich die Funktion für sml nutzen kann. Viele Grüße Am Di., 5. Nov. 2019 um 21:48 Uhr schrieb Andreas Goetz : > Hallo Winfried, > > Dein Request ist also “duplicates” für den httpd zu implemetieren? Oder > willst Du sagen dass er *nur* für SML nicht funktioniert? > > Viele Grüße, Andreas > > > On 3. Nov 2019, at 14:40, Winfried Peters > wrote: > > 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. > > Viele Grüße > > Am So., 3. Nov. 2019 um 13:16 Uhr schrieb Andreas Goetz >: > >> Laut Issue werden “duplicates” für “sml” über “httpd” ausgegeben. Ich >> verstehe das Problem nicht so ganz. Da der httpd ja aktiv abgeholt werden >> muss- was spricht a) dagegen die Duplikate dort anzuzeigen und b) was hat >> das Ganze mit sml zu tun? >> >> Viele Grüße, Andreas >> >> >> On 3. Nov 2019, at 10:14, Winfried Peters >> wrote: >> >> Ich werde ein Issue aufmachen - und wenn ich schon mal dabei bin, auch >> eins für den Parameter "duplicates", der auch nicht funktioniert. >> >> Viele Grüße >> >> Am Sa., 2. Nov. 2019 um 22:52 Uhr schrieb Andreas Götz > >: >> >>> Machst Du ein Issue auf? Das sollte so nicht sein... >>> >>> Viele Grüße, >>> Andreas >>> >>> Am 02.11.2019 um 21:11 schrieb Winfried Peters < >>> winfried.pet...@gmail.com>: >>> >>> >>> Das war's. Mit voll qualifiziertem Identifier "1-0:1.8.0" funktioniert >>> es, mit "1.8.0" oder den Alias "Counter" nicht. ts=0 war nicht die Ursache. >>> Es geht auch ohne Timestamp. >>> >>> Anscheinend sind die Protokolle D0 und sml für HTTPd etwas >>> unterschiedlich implementiert: Bei "D0" funktioniert "1.8.0", bei sml >>> nicht. Ebenso funktionieren bei sml die Aliase nicht, obwohl das die >>> vzlogger-Hilfe sagt und in den Beispiel-Konfiguration auch angegeben ist. >>> >>> Nochmal vielen Dank für den entscheidenden Tipp. >>> >>> Viele Grüße >>> >>> Am Sa., 2. Nov. 2019 um 17:52 Uhr schrieb Frank Richter < >>> frank.richte...@gmail.com>: >>> >>>> Hast du's (nochmal) mit vollständigen Identifiern (z.B. "1-0:1.8.0") >>>> versucht? Ansonsten sieht die Config für mich gut aus. >>>> >>>> Grüße >>>> Frank >>>> >>>> Winfried Peters schrieb am Sa., 2. Nov. >>>> 2019, 17:26: >>>> >>>>> So, ich bin jetzt ein paar Schritte weiter gekommen, aber immer noch >>>>> ohne Erfolg. Die von vzlogger geparsten sml-Daten werden immer noch nicht >>>>> über den HTTPd-Server ausgegeben. >>>>> >>>>> Ich habe über die PIN meines DWS74-Zählers auf den erweiterten >>>>> Datensatz umgestellt. >>>>> Ich habe vzlogger mit der aktuellen Version 0.8.0 compiliert, >>>>> installiert, für meinen sml-Zähler konfiguriert und gestartet. >>>>> Die sml-Daten meines Zählers kommen in vzlogger an. Im verbose 15-Log >>>>> sehe ich die geparsten Werte des Zählers als Readings, jetzt auch mit >>>>> Timestamp ts, der über den Parameter "use_local_time" geliefert wird. >>>
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
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.
Viele Grüße
Am So., 3. Nov. 2019 um 13:16 Uhr schrieb Andreas Goetz :
> Laut Issue werden “duplicates” für “sml” über “httpd” ausgegeben. Ich
> verstehe das Problem nicht so ganz. Da der httpd ja aktiv abgeholt werden
> muss- was spricht a) dagegen die Duplikate dort anzuzeigen und b) was hat
> das Ganze mit sml zu tun?
>
> Viele Grüße, Andreas
>
>
> On 3. Nov 2019, at 10:14, Winfried Peters
> wrote:
>
> Ich werde ein Issue aufmachen - und wenn ich schon mal dabei bin, auch
> eins für den Parameter "duplicates", der auch nicht funktioniert.
>
> Viele Grüße
>
> Am Sa., 2. Nov. 2019 um 22:52 Uhr schrieb Andreas Götz >:
>
>> Machst Du ein Issue auf? Das sollte so nicht sein...
>>
>> Viele Grüße,
>> Andreas
>>
>> Am 02.11.2019 um 21:11 schrieb Winfried Peters > >:
>>
>>
>> Das war's. Mit voll qualifiziertem Identifier "1-0:1.8.0" funktioniert
>> es, mit "1.8.0" oder den Alias "Counter" nicht. ts=0 war nicht die Ursache.
>> Es geht auch ohne Timestamp.
>>
>> Anscheinend sind die Protokolle D0 und sml für HTTPd etwas
>> unterschiedlich implementiert: Bei "D0" funktioniert "1.8.0", bei sml
>> nicht. Ebenso funktionieren bei sml die Aliase nicht, obwohl das die
>> vzlogger-Hilfe sagt und in den Beispiel-Konfiguration auch angegeben ist.
>>
>> Nochmal vielen Dank für den entscheidenden Tipp.
>>
>> Viele Grüße
>>
>> Am Sa., 2. Nov. 2019 um 17:52 Uhr schrieb Frank Richter <
>> frank.richte...@gmail.com>:
>>
>>> Hast du's (nochmal) mit vollständigen Identifiern (z.B. "1-0:1.8.0")
>>> versucht? Ansonsten sieht die Config für mich gut aus.
>>>
>>> Grüße
>>> Frank
>>>
>>> Winfried Peters schrieb am Sa., 2. Nov.
>>> 2019, 17:26:
>>>
>>>> So, ich bin jetzt ein paar Schritte weiter gekommen, aber immer noch
>>>> ohne Erfolg. Die von vzlogger geparsten sml-Daten werden immer noch nicht
>>>> über den HTTPd-Server ausgegeben.
>>>>
>>>> Ich habe über die PIN meines DWS74-Zählers auf den erweiterten
>>>> Datensatz umgestellt.
>>>> Ich habe vzlogger mit der aktuellen Version 0.8.0 compiliert,
>>>> installiert, für meinen sml-Zähler konfiguriert und gestartet.
>>>> Die sml-Daten meines Zählers kommen in vzlogger an. Im verbose 15-Log
>>>> sehe ich die geparsten Werte des Zählers als Readings, jetzt auch mit
>>>> Timestamp ts, der über den Parameter "use_local_time" geliefert wird.
>>>> Mir fehlen im Log die Hinweise, dass für jeden der Channel ein
>>>> Logging-Thread gestartet wurde (Start logging thread for null-api. Running
>>>> as daemon: yes) und die Readings auf die Queue gestellt wurden (Adding
>>>> reading to queue..).
>>>> Sonst ist das Log aus meiner Sicht unauffällig.
>>>>
>>>> So sehe ich im Browser die Daten des HTTPD-Servers:
>>>>
>>>> { "version": "0.8.0", "generator": "vzlogger", "data": [ { "uuid": "180a",
>>>> "last": 0, "interval": -1, "protocol": "sml" }, { "uuid": "180b", "last":
>>>> 0, "interval": -1, "protocol": "sml" }, { "uuid": "180c", "last": 0,
>>>> "interval": -1, "protocol": "sml&quo
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Das ist aber in der Wiki-Dokumentation der vzlogger-Parameter so explizit
nicht dokumentiert. Dann wäre es ein nützliches Feature-Request von mir :-)
Viele Grüße
Am So., 3. Nov. 2019 um 10:51 Uhr schrieb Frank Richter <
frank.richte...@gmail.com>:
> "duplicates" ist nur fürs "volkszaehler"-API implementiert.
>
> Grüße
> Frank
>
> Winfried Peters schrieb am So., 3. Nov. 2019,
> 10:14:
>
>> Ich werde ein Issue aufmachen - und wenn ich schon mal dabei bin, auch
>> eins für den Parameter "duplicates", der auch nicht funktioniert.
>>
>> Viele Grüße
>>
>> Am Sa., 2. Nov. 2019 um 22:52 Uhr schrieb Andreas Götz > >:
>>
>>> Machst Du ein Issue auf? Das sollte so nicht sein...
>>>
>>> Viele Grüße,
>>> Andreas
>>>
>>> Am 02.11.2019 um 21:11 schrieb Winfried Peters <
>>> winfried.pet...@gmail.com>:
>>>
>>>
>>> Das war's. Mit voll qualifiziertem Identifier "1-0:1.8.0" funktioniert
>>> es, mit "1.8.0" oder den Alias "Counter" nicht. ts=0 war nicht die Ursache.
>>> Es geht auch ohne Timestamp.
>>>
>>> Anscheinend sind die Protokolle D0 und sml für HTTPd etwas
>>> unterschiedlich implementiert: Bei "D0" funktioniert "1.8.0", bei sml
>>> nicht. Ebenso funktionieren bei sml die Aliase nicht, obwohl das die
>>> vzlogger-Hilfe sagt und in den Beispiel-Konfiguration auch angegeben ist.
>>>
>>> Nochmal vielen Dank für den entscheidenden Tipp.
>>>
>>> Viele Grüße
>>>
>>> Am Sa., 2. Nov. 2019 um 17:52 Uhr schrieb Frank Richter <
>>> frank.richte...@gmail.com>:
>>>
>>>> Hast du's (nochmal) mit vollständigen Identifiern (z.B. "1-0:1.8.0")
>>>> versucht? Ansonsten sieht die Config für mich gut aus.
>>>>
>>>> Grüße
>>>> Frank
>>>>
>>>> Winfried Peters schrieb am Sa., 2. Nov.
>>>> 2019, 17:26:
>>>>
>>>>> So, ich bin jetzt ein paar Schritte weiter gekommen, aber immer noch
>>>>> ohne Erfolg. Die von vzlogger geparsten sml-Daten werden immer noch nicht
>>>>> über den HTTPd-Server ausgegeben.
>>>>>
>>>>> Ich habe über die PIN meines DWS74-Zählers auf den erweiterten
>>>>> Datensatz umgestellt.
>>>>> Ich habe vzlogger mit der aktuellen Version 0.8.0 compiliert,
>>>>> installiert, für meinen sml-Zähler konfiguriert und gestartet.
>>>>> Die sml-Daten meines Zählers kommen in vzlogger an. Im verbose 15-Log
>>>>> sehe ich die geparsten Werte des Zählers als Readings, jetzt auch mit
>>>>> Timestamp ts, der über den Parameter "use_local_time" geliefert wird.
>>>>> Mir fehlen im Log die Hinweise, dass für jeden der Channel ein
>>>>> Logging-Thread gestartet wurde (Start logging thread for null-api. Running
>>>>> as daemon: yes) und die Readings auf die Queue gestellt wurden
>>>>> (Adding reading to queue..).
>>>>> Sonst ist das Log aus meiner Sicht unauffällig.
>>>>>
>>>>> So sehe ich im Browser die Daten des HTTPD-Servers:
>>>>>
>>>>> { "version": "0.8.0", "generator": "vzlogger", "data": [ { "uuid":
>>>>> "180a", "last": 0, "interval": -1, "protocol": "sml" }, { "uuid": "180b",
>>>>> "last": 0, "interval": -1, "protocol": "sml" }, { "uuid": "180c", "last":
>>>>> 0, "interval": -1, "protocol": "sml" } ] }
>>>>>
>>>>> Die Readings müssten dort für jeden Channel als Tupel mit Timestamp
>>>>> und Value erscheinen. Es sind aber keine Tupel da.
>>>>>
>>>>> Hier der Logauszug:
>>>>>
>>>>> [Nov 02 15:55:39][main] vzlogger v0.8.0 based on
>>>>> heads/master-0-g3c4ef603cb from Sun, 18 Aug 2019 09:36:53 +0200 started.
>>>>>
>>>>> [Nov 02 15:55:39][mtr0] Creating new meter with protocol sml.
>>>>>
>>>>> [Nov 02 15:55:39][mtr0] Meter configured, enabled.
>>>>>
>>>>> [Nov 02 15:55:39] New meter initialized (protocol=sml)
>>>>>
>>>>> [Nov 02 15:55:39] Configure channel.
>>>>>
>>>
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Ich werde ein Issue aufmachen - und wenn ich schon mal dabei bin, auch eins
für den Parameter "duplicates", der auch nicht funktioniert.
Viele Grüße
Am Sa., 2. Nov. 2019 um 22:52 Uhr schrieb Andreas Götz :
> Machst Du ein Issue auf? Das sollte so nicht sein...
>
> Viele Grüße,
> Andreas
>
> Am 02.11.2019 um 21:11 schrieb Winfried Peters >:
>
>
> Das war's. Mit voll qualifiziertem Identifier "1-0:1.8.0" funktioniert es,
> mit "1.8.0" oder den Alias "Counter" nicht. ts=0 war nicht die Ursache. Es
> geht auch ohne Timestamp.
>
> Anscheinend sind die Protokolle D0 und sml für HTTPd etwas unterschiedlich
> implementiert: Bei "D0" funktioniert "1.8.0", bei sml nicht. Ebenso
> funktionieren bei sml die Aliase nicht, obwohl das die vzlogger-Hilfe sagt
> und in den Beispiel-Konfiguration auch angegeben ist.
>
> Nochmal vielen Dank für den entscheidenden Tipp.
>
> Viele Grüße
>
> Am Sa., 2. Nov. 2019 um 17:52 Uhr schrieb Frank Richter <
> frank.richte...@gmail.com>:
>
>> Hast du's (nochmal) mit vollständigen Identifiern (z.B. "1-0:1.8.0")
>> versucht? Ansonsten sieht die Config für mich gut aus.
>>
>> Grüße
>> Frank
>>
>> Winfried Peters schrieb am Sa., 2. Nov.
>> 2019, 17:26:
>>
>>> So, ich bin jetzt ein paar Schritte weiter gekommen, aber immer noch
>>> ohne Erfolg. Die von vzlogger geparsten sml-Daten werden immer noch nicht
>>> über den HTTPd-Server ausgegeben.
>>>
>>> Ich habe über die PIN meines DWS74-Zählers auf den erweiterten Datensatz
>>> umgestellt.
>>> Ich habe vzlogger mit der aktuellen Version 0.8.0 compiliert,
>>> installiert, für meinen sml-Zähler konfiguriert und gestartet.
>>> Die sml-Daten meines Zählers kommen in vzlogger an. Im verbose 15-Log
>>> sehe ich die geparsten Werte des Zählers als Readings, jetzt auch mit
>>> Timestamp ts, der über den Parameter "use_local_time" geliefert wird.
>>> Mir fehlen im Log die Hinweise, dass für jeden der Channel ein
>>> Logging-Thread gestartet wurde (Start logging thread for null-api. Running
>>> as daemon: yes) und die Readings auf die Queue gestellt wurden (Adding
>>> reading to queue..).
>>> Sonst ist das Log aus meiner Sicht unauffällig.
>>>
>>> So sehe ich im Browser die Daten des HTTPD-Servers:
>>>
>>> { "version": "0.8.0", "generator": "vzlogger", "data": [ { "uuid": "180a",
>>> "last": 0, "interval": -1, "protocol": "sml" }, { "uuid": "180b", "last":
>>> 0, "interval": -1, "protocol": "sml" }, { "uuid": "180c", "last": 0,
>>> "interval": -1, "protocol": "sml" } ] }
>>>
>>> Die Readings müssten dort für jeden Channel als Tupel mit Timestamp und
>>> Value erscheinen. Es sind aber keine Tupel da.
>>>
>>> Hier der Logauszug:
>>>
>>> [Nov 02 15:55:39][main] vzlogger v0.8.0 based on
>>> heads/master-0-g3c4ef603cb from Sun, 18 Aug 2019 09:36:53 +0200 started.
>>>
>>> [Nov 02 15:55:39][mtr0] Creating new meter with protocol sml.
>>>
>>> [Nov 02 15:55:39][mtr0] Meter configured, enabled.
>>>
>>> [Nov 02 15:55:39] New meter initialized (protocol=sml)
>>>
>>> [Nov 02 15:55:39] Configure channel.
>>>
>>> [Nov 02 15:55:39][chn0] New channel initialized (uuid=... api=null
>>> id=1.8.0)
>>>
>>> [Nov 02 15:55:39] Configure channel.
>>>
>>> [Nov 02 15:55:39][chn1] New channel initialized (uuid=... api=null
>>> id=1.25)
>>>
>>> [Nov 02 15:55:39] Configure channel.
>>>
>>> [Nov 02 15:55:39][chn2] New channel initialized (uuid=... api=null
>>> id=2.8.0)
>>>
>>> [Nov 02 15:55:39] Have 1 meters.
>>>
>>> [Nov 02 15:55:39][main] log level is 15
>>>
>>> [Nov 02 15:55:39][main] daemon=1, local=1
>>>
>>> [Nov 02 15:55:39] Daemonize process...
>>>
>>> [Nov 02 15:55:39] Opened logfile /var/log/vzlogger.log
>>>
>>> [Nov 02 15:55:39][push] No pushDataServer defined.
>>>
>>> [Nov 02 15:55:39][] ===> Start meters
>>>
>>> [Nov 02 15:55:39][mtr0] Meter connection established
>>>
>>> [Nov 02 15:55:39][mtr0] Meter thread started
>>>
>>> [Nov 02
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Das war's. Mit voll qualifiziertem Identifier "1-0:1.8.0" funktioniert es,
mit "1.8.0" oder den Alias "Counter" nicht. ts=0 war nicht die Ursache. Es
geht auch ohne Timestamp.
Anscheinend sind die Protokolle D0 und sml für HTTPd etwas unterschiedlich
implementiert: Bei "D0" funktioniert "1.8.0", bei sml nicht. Ebenso
funktionieren bei sml die Aliase nicht, obwohl das die vzlogger-Hilfe sagt
und in den Beispiel-Konfiguration auch angegeben ist.
Nochmal vielen Dank für den entscheidenden Tipp.
Viele Grüße
Am Sa., 2. Nov. 2019 um 17:52 Uhr schrieb Frank Richter <
frank.richte...@gmail.com>:
> Hast du's (nochmal) mit vollständigen Identifiern (z.B. "1-0:1.8.0")
> versucht? Ansonsten sieht die Config für mich gut aus.
>
> Grüße
> Frank
>
> Winfried Peters schrieb am Sa., 2. Nov. 2019,
> 17:26:
>
>> So, ich bin jetzt ein paar Schritte weiter gekommen, aber immer noch ohne
>> Erfolg. Die von vzlogger geparsten sml-Daten werden immer noch nicht über
>> den HTTPd-Server ausgegeben.
>>
>> Ich habe über die PIN meines DWS74-Zählers auf den erweiterten Datensatz
>> umgestellt.
>> Ich habe vzlogger mit der aktuellen Version 0.8.0 compiliert,
>> installiert, für meinen sml-Zähler konfiguriert und gestartet.
>> Die sml-Daten meines Zählers kommen in vzlogger an. Im verbose 15-Log
>> sehe ich die geparsten Werte des Zählers als Readings, jetzt auch mit
>> Timestamp ts, der über den Parameter "use_local_time" geliefert wird.
>> Mir fehlen im Log die Hinweise, dass für jeden der Channel ein
>> Logging-Thread gestartet wurde (Start logging thread for null-api. Running
>> as daemon: yes) und die Readings auf die Queue gestellt wurden (Adding
>> reading to queue..).
>> Sonst ist das Log aus meiner Sicht unauffällig.
>>
>> So sehe ich im Browser die Daten des HTTPD-Servers:
>>
>> { "version": "0.8.0", "generator": "vzlogger", "data": [ { "uuid": "180a",
>> "last": 0, "interval": -1, "protocol": "sml" }, { "uuid": "180b", "last": 0,
>> "interval": -1, "protocol": "sml" }, { "uuid": "180c", "last": 0,
>> "interval": -1, "protocol": "sml" } ] }
>>
>> Die Readings müssten dort für jeden Channel als Tupel mit Timestamp und
>> Value erscheinen. Es sind aber keine Tupel da.
>>
>> Hier der Logauszug:
>>
>> [Nov 02 15:55:39][main] vzlogger v0.8.0 based on
>> heads/master-0-g3c4ef603cb from Sun, 18 Aug 2019 09:36:53 +0200 started.
>>
>> [Nov 02 15:55:39][mtr0] Creating new meter with protocol sml.
>>
>> [Nov 02 15:55:39][mtr0] Meter configured, enabled.
>>
>> [Nov 02 15:55:39] New meter initialized (protocol=sml)
>>
>> [Nov 02 15:55:39] Configure channel.
>>
>> [Nov 02 15:55:39][chn0] New channel initialized (uuid=... api=null
>> id=1.8.0)
>>
>> [Nov 02 15:55:39] Configure channel.
>>
>> [Nov 02 15:55:39][chn1] New channel initialized (uuid=... api=null
>> id=1.25)
>>
>> [Nov 02 15:55:39] Configure channel.
>>
>> [Nov 02 15:55:39][chn2] New channel initialized (uuid=... api=null
>> id=2.8.0)
>>
>> [Nov 02 15:55:39] Have 1 meters.
>>
>> [Nov 02 15:55:39][main] log level is 15
>>
>> [Nov 02 15:55:39][main] daemon=1, local=1
>>
>> [Nov 02 15:55:39] Daemonize process...
>>
>> [Nov 02 15:55:39] Opened logfile /var/log/vzlogger.log
>>
>> [Nov 02 15:55:39][push] No pushDataServer defined.
>>
>> [Nov 02 15:55:39][] ===> Start meters
>>
>> [Nov 02 15:55:39][mtr0] Meter connection established
>>
>> [Nov 02 15:55:39][mtr0] Meter thread started
>>
>> [Nov 02 15:55:39][mtr0] Meter is opened. Starting channels.
>>
>> [Nov 02 15:55:39][chn0] Logging thread started
>>
>> [Nov 02 15:55:39][chn1] Logging thread started
>>
>> [Nov 02 15:55:39][chn2] Logging thread started
>>
>> [Nov 02 15:55:39][http] Starting local interface HTTPd on port 8080
>>
>> [Nov 02 15:55:39][] Startup done.
>>
>> [Nov 02 15:55:39][chn1] Start logging thread for null-api. Running as
>> daemon: yes
>>
>> [Nov 02 15:55:39][chn1] Using null api- meter data available via local
>> httpd if enabled.
>>
>> [Nov 02 15:55:39][chn2] Start logging thread for null-api. Running as
>> daemon: yes
>>
>> [Nov 02 15:55:39][chn2] Using null api- m
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
.log",
"retry": 30,// http retry delay in seconds
// Build-in HTTP server
"local": {
"enabled": true,
"port": 8080,
"index": true,
"timeout": 30,
"buffer": 3600
},
// Meter configuration
"meters": [
// sml meter (Strom)
{
"enabled": true,
"protocol": "sml",
"device": "/dev/ttyUSB0",
"baudrate": 9600,
"parity": "8n1",
"use_local_time": true,
"skip": false,
"channels": [
{
"uuid": "180a",
"identifier": "counter", // 1.8.1 Zaehlerstand
Wirkleistung 1-0:1.8.255*255
"api": "null",
"duplicates": 0
},
{
"uuid": "180b",
"identifier": "1.25",// 1.25 Momentanleistung
"api": "null",
"duplicates": 0
},
{
"uuid": "180c",
"identifier": "counter-out", // 2.8.1 Zaehlerstand Lieferg.
1-0:2.8.255*255
"api": "null",
"duplicates": 0
}
]
}
]
}
Hat jemand noch eine Idee, was falsch sein könnte?
Viele Grüße
Am Mi., 30. Okt. 2019 um 14:43 Uhr schrieb Winfried Peters <
winfried.pet...@gmail.com>:
> Die PIN wird mir vom Netzbetreiber zugeschickt. Dann hoffe ich mal, dass
> mit der hohen Auflösung der Timestamp mitkommt.
>
> Viele Grüße
>
> Am Mi., 30. Okt. 2019 um 11:32 Uhr schrieb Frank Richter <
> frank.richte...@gmail.com>:
>
>> Aus Zählerständen in ganzen kWh lässt sich die Leistung auch nicht
>> sinnvoll ableiten, deswegen würde ich mich zuallererst mal um die
>> Beschaffung der PIN und die Freischaltung der höheren Auflösung kümmern.
>>
>> DZG ist glaub ich schonmal mit einer problematischen SML-Implementierung
>> aufgefallen.
>>
>> Grüße
>> Frank
>>
>> Winfried Peters schrieb am Mi., 30. Okt.
>> 2019, 10:44:
>>
>>> Es ist ein Zähler von DZG vom Typ DWS7412.2T. Er pusht periodisch jede
>>> Sekunde ein Telegramm in SML 1.05-SML-frame Version 1, 9600 Bd, 8-N-1.
>>> Über die DZG Software "DZG Meter View" kann ich die Daten auslesen. Das
>>> Programm kann auch die Leistungen über die Zeit in einem Diagramm
>>> darstellen. Das Diagramm bleibt aber leer. Was zu der Vermutung führt, dass
>>> keine Zeitstempel übertragen werden, so wie es vzlogger ja auch ausweist.
>>> Ich habe eine Anfrage an DZG gestellt, ob das ein Fehler in der verbauten
>>> Firmware ist.
>>>
>>> Viele Grüße
>>>
>>>
>>> Am Di., 29. Okt. 2019 um 23:02 Uhr schrieb Frank Richter <
>>> frank.richte...@gmail.com>:
>>>
>>>> Von welchem Zählertyp reden wir eigentlich?
>>>>
>>>> Grüße
>>>> Frank
>>>>
>>>> Am Di., 29. Okt. 2019 um 21:17 Uhr schrieb Winfried Peters <
>>>> winfried.pet...@gmail.com>:
>>>>
>>>>> Ich habe Daniels Konfigurationsvorschläge (identfier 1.8.0 und 2.8.0 )
>>>>> getestet , mit dem gleichen (negativen) Ergebnis.
>>>>> count und count-out sind übrigens von vzlogger unterstützte
>>>>> OBIS-Aliase, die funktionieren (siehe vzlogger -h).
>>>>> use_local_time kann ich leider in meiner alten vzlogger-Version nicht
>>>>> nutzen.
>>>>> Konfigurationsfehler sehe ich bisher nicht und meine These, bei ts=0
>>>>> keine Werte-Tupelübergabe an HTTPd, hat bisher auch noch keiner widerlegt.
>>>>>
>>>>> Viele Grüße
>>>>>
>>>>> Am Di., 29. Okt. 2019 um 20:41 Uhr schrieb Stefan Bauer <
>>>>> s...@stefan-bauer.net>:
>>>>>
>>>>>> Nein, am Timestamp Wirtes nich liegen, sondern an der falschen
>>>>>> Konfiguration, wie Daniel schon in seinem ersten Post geschrieben hat...
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>> Von meinem iPad gesendet
>>>>>>
>>>>>> Am 29.10.2019 um 20:39 schrieb Winfried Peters <
>>>>>> winfried.pet...@gmail.com>:
>>>>>>
>>>>>>
>>>>>> Ich brauch den Timestamp nicht, aber vielleicht HTTPd. Mein Problem
>>>>>> ist, dass keine SML-Werte-Tupel an HTTPd übergeben werden un
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Die PIN wird mir vom Netzbetreiber zugeschickt. Dann hoffe ich mal, dass mit der hohen Auflösung der Timestamp mitkommt. Viele Grüße Am Mi., 30. Okt. 2019 um 11:32 Uhr schrieb Frank Richter < frank.richte...@gmail.com>: > Aus Zählerständen in ganzen kWh lässt sich die Leistung auch nicht > sinnvoll ableiten, deswegen würde ich mich zuallererst mal um die > Beschaffung der PIN und die Freischaltung der höheren Auflösung kümmern. > > DZG ist glaub ich schonmal mit einer problematischen SML-Implementierung > aufgefallen. > > Grüße > Frank > > Winfried Peters schrieb am Mi., 30. Okt. > 2019, 10:44: > >> Es ist ein Zähler von DZG vom Typ DWS7412.2T. Er pusht periodisch jede >> Sekunde ein Telegramm in SML 1.05-SML-frame Version 1, 9600 Bd, 8-N-1. >> Über die DZG Software "DZG Meter View" kann ich die Daten auslesen. Das >> Programm kann auch die Leistungen über die Zeit in einem Diagramm >> darstellen. Das Diagramm bleibt aber leer. Was zu der Vermutung führt, dass >> keine Zeitstempel übertragen werden, so wie es vzlogger ja auch ausweist. >> Ich habe eine Anfrage an DZG gestellt, ob das ein Fehler in der verbauten >> Firmware ist. >> >> Viele Grüße >> >> >> Am Di., 29. Okt. 2019 um 23:02 Uhr schrieb Frank Richter < >> frank.richte...@gmail.com>: >> >>> Von welchem Zählertyp reden wir eigentlich? >>> >>> Grüße >>> Frank >>> >>> Am Di., 29. Okt. 2019 um 21:17 Uhr schrieb Winfried Peters < >>> winfried.pet...@gmail.com>: >>> >>>> Ich habe Daniels Konfigurationsvorschläge (identfier 1.8.0 und 2.8.0 ) >>>> getestet , mit dem gleichen (negativen) Ergebnis. >>>> count und count-out sind übrigens von vzlogger unterstützte >>>> OBIS-Aliase, die funktionieren (siehe vzlogger -h). >>>> use_local_time kann ich leider in meiner alten vzlogger-Version nicht >>>> nutzen. >>>> Konfigurationsfehler sehe ich bisher nicht und meine These, bei ts=0 >>>> keine Werte-Tupelübergabe an HTTPd, hat bisher auch noch keiner widerlegt. >>>> >>>> Viele Grüße >>>> >>>> Am Di., 29. Okt. 2019 um 20:41 Uhr schrieb Stefan Bauer < >>>> s...@stefan-bauer.net>: >>>> >>>>> Nein, am Timestamp Wirtes nich liegen, sondern an der falschen >>>>> Konfiguration, wie Daniel schon in seinem ersten Post geschrieben hat... >>>>> >>>>> Stefan >>>>> >>>>> Von meinem iPad gesendet >>>>> >>>>> Am 29.10.2019 um 20:39 schrieb Winfried Peters < >>>>> winfried.pet...@gmail.com>: >>>>> >>>>> >>>>> Ich brauch den Timestamp nicht, aber vielleicht HTTPd. Mein Problem >>>>> ist, dass keine SML-Werte-Tupel an HTTPd übergeben werden und ich sie >>>>> demnach nicht abfragen kann. >>>>> Ich stelle nur Vermutungen über mögliche Ursachen an. Mir fällt im Log >>>>> auf, dass Werte mit Timestamp an HTTPd übergeben werden, Werte mit ts=0 >>>>> nicht. >>>>> Also könnte der fehlende Timestamp eine Ursache sein, die ich leider >>>>> nicht mit dem use_local_time überprüfen kann. >>>>> >>>>> Viele Grüße >>>>> >>>>> Am Di., 29. Okt. 2019 um 19:57 Uhr schrieb Frank Richter < >>>>> frank.richte...@gmail.com>: >>>>> >>>>>> Brauchst du den Timestamp denn unbedingt, wenn du die Daten eh nur >>>>>> vom httpd abholst? >>>>>> >>>>>> Am Di., 29. Okt. 2019 um 19:37 Uhr schrieb Winfried Peters < >>>>>> winfried.pet...@gmail.com>: >>>>>> >>>>>>> Ojeh, gerade das wollte ich mir nicht antun. Ich hatte vor einigen >>>>>>> Monaten schon mal einen Anlauf gemacht, ein Cross-Compile für Udo's >>>>>>> YPORT+-Logger durchzuführen. Habe den Versuch aber aufgegeben (es ist >>>>>>> mir >>>>>>> nicht gelungen Dependencies, z.B. zu libsml, aufzulösen). Udo hatte mir >>>>>>> vor >>>>>>> ein paar Jahren schon mal mit einem neuen Image aus der Patsche >>>>>>> geholfen. >>>>>>> Ich hatte Udo angeschrieben. Aber er scheint nicht mehr aktiv zu sein. >>>>>>> >>>>>>> use_local_time funktioniert nicht, hatte ich gerade getestet. Jetzt >>>>>>> weiss ich auch warum. >>>>>>> >>>>>>> Dann bleiben mir noch zwei Optionen: >>>>>>> - ich schaffe mir einen Rasberry Pi an und bringe dort die aktuelle >>>>>>> vzlogger-Version drauf >>>>>>> - oder ich versuche mich nochmal am Cross-Compile. >>>>>>> >>>>>>> Viele Grüße >>>>>>> >>>>>>> Am Di., 29. Okt. 2019 um 19:02 Uhr schrieb Frank Richter < >>>>>>> frank.richte...@gmail.com>: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Am Di., 29. Okt. 2019 um 14:06 Uhr schrieb Daniel Lauckner < >>>>>>>> v...@jahp.de>: >>>>>>>> >>>>>>>>> Und für SML-Zähler die beim timestamp murksen gibts die Option >>>>>>>>> "use_local_time" >>>>>>>>> >>>>>>>>> https://wiki.volkszaehler.org/software/controller/vzlogger/vzlogger_conf_parameter?s[]=use_local_time#sml >>>>>>>> >>>>>>>> >>>>>>>> allerdings noch nicht in 0.6.0. Da wirst du neu compilieren müssen. >>>>>>>> >>>>>>>> Grüße >>>>>>>> Frank >>>>>>>> >>>>>>>
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Es ist ein Zähler von DZG vom Typ DWS7412.2T. Er pusht periodisch jede Sekunde ein Telegramm in SML 1.05-SML-frame Version 1, 9600 Bd, 8-N-1. Über die DZG Software "DZG Meter View" kann ich die Daten auslesen. Das Programm kann auch die Leistungen über die Zeit in einem Diagramm darstellen. Das Diagramm bleibt aber leer. Was zu der Vermutung führt, dass keine Zeitstempel übertragen werden, so wie es vzlogger ja auch ausweist. Ich habe eine Anfrage an DZG gestellt, ob das ein Fehler in der verbauten Firmware ist. Viele Grüße Am Di., 29. Okt. 2019 um 23:02 Uhr schrieb Frank Richter < frank.richte...@gmail.com>: > Von welchem Zählertyp reden wir eigentlich? > > Grüße > Frank > > Am Di., 29. Okt. 2019 um 21:17 Uhr schrieb Winfried Peters < > winfried.pet...@gmail.com>: > >> Ich habe Daniels Konfigurationsvorschläge (identfier 1.8.0 und 2.8.0 ) >> getestet , mit dem gleichen (negativen) Ergebnis. >> count und count-out sind übrigens von vzlogger unterstützte OBIS-Aliase, >> die funktionieren (siehe vzlogger -h). >> use_local_time kann ich leider in meiner alten vzlogger-Version nicht >> nutzen. >> Konfigurationsfehler sehe ich bisher nicht und meine These, bei ts=0 >> keine Werte-Tupelübergabe an HTTPd, hat bisher auch noch keiner widerlegt. >> >> Viele Grüße >> >> Am Di., 29. Okt. 2019 um 20:41 Uhr schrieb Stefan Bauer < >> s...@stefan-bauer.net>: >> >>> Nein, am Timestamp Wirtes nich liegen, sondern an der falschen >>> Konfiguration, wie Daniel schon in seinem ersten Post geschrieben hat... >>> >>> Stefan >>> >>> Von meinem iPad gesendet >>> >>> Am 29.10.2019 um 20:39 schrieb Winfried Peters < >>> winfried.pet...@gmail.com>: >>> >>> >>> Ich brauch den Timestamp nicht, aber vielleicht HTTPd. Mein Problem ist, >>> dass keine SML-Werte-Tupel an HTTPd übergeben werden und ich sie demnach >>> nicht abfragen kann. >>> Ich stelle nur Vermutungen über mögliche Ursachen an. Mir fällt im Log >>> auf, dass Werte mit Timestamp an HTTPd übergeben werden, Werte mit ts=0 >>> nicht. >>> Also könnte der fehlende Timestamp eine Ursache sein, die ich leider >>> nicht mit dem use_local_time überprüfen kann. >>> >>> Viele Grüße >>> >>> Am Di., 29. Okt. 2019 um 19:57 Uhr schrieb Frank Richter < >>> frank.richte...@gmail.com>: >>> >>>> Brauchst du den Timestamp denn unbedingt, wenn du die Daten eh nur vom >>>> httpd abholst? >>>> >>>> Am Di., 29. Okt. 2019 um 19:37 Uhr schrieb Winfried Peters < >>>> winfried.pet...@gmail.com>: >>>> >>>>> Ojeh, gerade das wollte ich mir nicht antun. Ich hatte vor einigen >>>>> Monaten schon mal einen Anlauf gemacht, ein Cross-Compile für Udo's >>>>> YPORT+-Logger durchzuführen. Habe den Versuch aber aufgegeben (es ist mir >>>>> nicht gelungen Dependencies, z.B. zu libsml, aufzulösen). Udo hatte mir >>>>> vor >>>>> ein paar Jahren schon mal mit einem neuen Image aus der Patsche geholfen. >>>>> Ich hatte Udo angeschrieben. Aber er scheint nicht mehr aktiv zu sein. >>>>> >>>>> use_local_time funktioniert nicht, hatte ich gerade getestet. Jetzt >>>>> weiss ich auch warum. >>>>> >>>>> Dann bleiben mir noch zwei Optionen: >>>>> - ich schaffe mir einen Rasberry Pi an und bringe dort die aktuelle >>>>> vzlogger-Version drauf >>>>> - oder ich versuche mich nochmal am Cross-Compile. >>>>> >>>>> Viele Grüße >>>>> >>>>> Am Di., 29. Okt. 2019 um 19:02 Uhr schrieb Frank Richter < >>>>> frank.richte...@gmail.com>: >>>>> >>>>>> Hi, >>>>>> >>>>>> Am Di., 29. Okt. 2019 um 14:06 Uhr schrieb Daniel Lauckner < >>>>>> v...@jahp.de>: >>>>>> >>>>>>> Und für SML-Zähler die beim timestamp murksen gibts die Option >>>>>>> "use_local_time" >>>>>>> >>>>>>> https://wiki.volkszaehler.org/software/controller/vzlogger/vzlogger_conf_parameter?s[]=use_local_time#sml >>>>>> >>>>>> >>>>>> allerdings noch nicht in 0.6.0. Da wirst du neu compilieren müssen. >>>>>> >>>>>> Grüße >>>>>> Frank >>>>>> >>>>>
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Ich habe Daniels Konfigurationsvorschläge (identfier 1.8.0 und 2.8.0 ) getestet , mit dem gleichen (negativen) Ergebnis. count und count-out sind übrigens von vzlogger unterstützte OBIS-Aliase, die funktionieren (siehe vzlogger -h). use_local_time kann ich leider in meiner alten vzlogger-Version nicht nutzen. Konfigurationsfehler sehe ich bisher nicht und meine These, bei ts=0 keine Werte-Tupelübergabe an HTTPd, hat bisher auch noch keiner widerlegt. Viele Grüße Am Di., 29. Okt. 2019 um 20:41 Uhr schrieb Stefan Bauer < s...@stefan-bauer.net>: > Nein, am Timestamp Wirtes nich liegen, sondern an der falschen > Konfiguration, wie Daniel schon in seinem ersten Post geschrieben hat... > > Stefan > > Von meinem iPad gesendet > > Am 29.10.2019 um 20:39 schrieb Winfried Peters >: > > > Ich brauch den Timestamp nicht, aber vielleicht HTTPd. Mein Problem ist, > dass keine SML-Werte-Tupel an HTTPd übergeben werden und ich sie demnach > nicht abfragen kann. > Ich stelle nur Vermutungen über mögliche Ursachen an. Mir fällt im Log > auf, dass Werte mit Timestamp an HTTPd übergeben werden, Werte mit ts=0 > nicht. > Also könnte der fehlende Timestamp eine Ursache sein, die ich leider nicht > mit dem use_local_time überprüfen kann. > > Viele Grüße > > Am Di., 29. Okt. 2019 um 19:57 Uhr schrieb Frank Richter < > frank.richte...@gmail.com>: > >> Brauchst du den Timestamp denn unbedingt, wenn du die Daten eh nur vom >> httpd abholst? >> >> Am Di., 29. Okt. 2019 um 19:37 Uhr schrieb Winfried Peters < >> winfried.pet...@gmail.com>: >> >>> Ojeh, gerade das wollte ich mir nicht antun. Ich hatte vor einigen >>> Monaten schon mal einen Anlauf gemacht, ein Cross-Compile für Udo's >>> YPORT+-Logger durchzuführen. Habe den Versuch aber aufgegeben (es ist mir >>> nicht gelungen Dependencies, z.B. zu libsml, aufzulösen). Udo hatte mir vor >>> ein paar Jahren schon mal mit einem neuen Image aus der Patsche geholfen. >>> Ich hatte Udo angeschrieben. Aber er scheint nicht mehr aktiv zu sein. >>> >>> use_local_time funktioniert nicht, hatte ich gerade getestet. Jetzt >>> weiss ich auch warum. >>> >>> Dann bleiben mir noch zwei Optionen: >>> - ich schaffe mir einen Rasberry Pi an und bringe dort die aktuelle >>> vzlogger-Version drauf >>> - oder ich versuche mich nochmal am Cross-Compile. >>> >>> Viele Grüße >>> >>> Am Di., 29. Okt. 2019 um 19:02 Uhr schrieb Frank Richter < >>> frank.richte...@gmail.com>: >>> >>>> Hi, >>>> >>>> Am Di., 29. Okt. 2019 um 14:06 Uhr schrieb Daniel Lauckner >>> >: >>>> >>>>> Und für SML-Zähler die beim timestamp murksen gibts die Option >>>>> "use_local_time" >>>>> >>>>> https://wiki.volkszaehler.org/software/controller/vzlogger/vzlogger_conf_parameter?s[]=use_local_time#sml >>>> >>>> >>>> allerdings noch nicht in 0.6.0. Da wirst du neu compilieren müssen. >>>> >>>> Grüße >>>> Frank >>>> >>>
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Ich brauch den Timestamp nicht, aber vielleicht HTTPd. Mein Problem ist, dass keine SML-Werte-Tupel an HTTPd übergeben werden und ich sie demnach nicht abfragen kann. Ich stelle nur Vermutungen über mögliche Ursachen an. Mir fällt im Log auf, dass Werte mit Timestamp an HTTPd übergeben werden, Werte mit ts=0 nicht. Also könnte der fehlende Timestamp eine Ursache sein, die ich leider nicht mit dem use_local_time überprüfen kann. Viele Grüße Am Di., 29. Okt. 2019 um 19:57 Uhr schrieb Frank Richter < frank.richte...@gmail.com>: > Brauchst du den Timestamp denn unbedingt, wenn du die Daten eh nur vom > httpd abholst? > > Am Di., 29. Okt. 2019 um 19:37 Uhr schrieb Winfried Peters < > winfried.pet...@gmail.com>: > >> Ojeh, gerade das wollte ich mir nicht antun. Ich hatte vor einigen >> Monaten schon mal einen Anlauf gemacht, ein Cross-Compile für Udo's >> YPORT+-Logger durchzuführen. Habe den Versuch aber aufgegeben (es ist mir >> nicht gelungen Dependencies, z.B. zu libsml, aufzulösen). Udo hatte mir vor >> ein paar Jahren schon mal mit einem neuen Image aus der Patsche geholfen. >> Ich hatte Udo angeschrieben. Aber er scheint nicht mehr aktiv zu sein. >> >> use_local_time funktioniert nicht, hatte ich gerade getestet. Jetzt weiss >> ich auch warum. >> >> Dann bleiben mir noch zwei Optionen: >> - ich schaffe mir einen Rasberry Pi an und bringe dort die aktuelle >> vzlogger-Version drauf >> - oder ich versuche mich nochmal am Cross-Compile. >> >> Viele Grüße >> >> Am Di., 29. Okt. 2019 um 19:02 Uhr schrieb Frank Richter < >> frank.richte...@gmail.com>: >> >>> Hi, >>> >>> Am Di., 29. Okt. 2019 um 14:06 Uhr schrieb Daniel Lauckner : >>> >>>> Und für SML-Zähler die beim timestamp murksen gibts die Option >>>> "use_local_time" >>>> >>>> https://wiki.volkszaehler.org/software/controller/vzlogger/vzlogger_conf_parameter?s[]=use_local_time#sml >>> >>> >>> allerdings noch nicht in 0.6.0. Da wirst du neu compilieren müssen. >>> >>> Grüße >>> Frank >>> >>
Re: [vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Ojeh, gerade das wollte ich mir nicht antun. Ich hatte vor einigen Monaten schon mal einen Anlauf gemacht, ein Cross-Compile für Udo's YPORT+-Logger durchzuführen. Habe den Versuch aber aufgegeben (es ist mir nicht gelungen Dependencies, z.B. zu libsml, aufzulösen). Udo hatte mir vor ein paar Jahren schon mal mit einem neuen Image aus der Patsche geholfen. Ich hatte Udo angeschrieben. Aber er scheint nicht mehr aktiv zu sein. use_local_time funktioniert nicht, hatte ich gerade getestet. Jetzt weiss ich auch warum. Dann bleiben mir noch zwei Optionen: - ich schaffe mir einen Rasberry Pi an und bringe dort die aktuelle vzlogger-Version drauf - oder ich versuche mich nochmal am Cross-Compile. Viele Grüße Am Di., 29. Okt. 2019 um 19:02 Uhr schrieb Frank Richter < frank.richte...@gmail.com>: > Hi, > > Am Di., 29. Okt. 2019 um 14:06 Uhr schrieb Daniel Lauckner : > >> Und für SML-Zähler die beim timestamp murksen gibts die Option >> "use_local_time" >> >> https://wiki.volkszaehler.org/software/controller/vzlogger/vzlogger_conf_parameter?s[]=use_local_time#sml > > > allerdings noch nicht in 0.6.0. Da wirst du neu compilieren müssen. > > Grüße > Frank >
[vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server
Hallo,
ich habe einen neuen Zweirichtungsstromzähler. Den alten Zähler konnte ich
problemlos über vzlogger mit dem d0-Protokoll und den HTTP-Server-Modus
auslesen.
Der neue Zähler gibt seine Daten als sml aus. vzlogger decodiert auch die
Daten. Hier ein Log-Auszug mit einem sml-meter [mtr0] und einem s0-meter
[mtr1]:
Oct 29 09:17:08][mtr0] Got 2 new readings from meter:
[Oct 29 09:17:08][mtr0] Reading:
id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255 value=53000.00 ts=0
[Oct 29 09:17:08][mtr0] Reading:
id=1-0:2.8.0*255/ObisIdentifier:1-0:2.8.0*255 value=13000.00 ts=0
[Oct 29 09:17:08][s0] Reading S0 - returning 4 readings (n=0 n_neg = 0)
[Oct 29 09:17:08][mtr1] Got 4 new readings from meter:
[Oct 29 09:17:08][mtr1] Reading: id=Power/StringIdentifier: value=0.00
ts=1572337028942
[Oct 29 09:17:08][mtr1] Reading: id=Impulse/StringIdentifier: value=0.00
ts=1572337028942
[Oct 29 09:17:08][mtr1] Reading: id=Power_neg/StringIdentifier: value=0.00
ts=1572337028942
[Oct 29 09:17:08][mtr1] Reading: id=Impulse_neg/StringIdentifier:
value=0.00 ts=1572337028942
[Oct 29 09:17:08][chn2] Adding reading to queue (value=0.00
ts=1572337028942)
[Oct 29 09:17:08][chn3] Adding reading to queue (value=0.00
ts=1572337028942)
[Oct 29 09:17:08][S0] MeterS0:HWIF_GPIO:first poll returned 0
Der Auszug zeigt, dass zwar Readings vom mtr1 korrekt decodiert werden
(value=53000.00
und value=13000.00), aber nicht wie die S0 (mtr1)-Werte in die Queue
gestellt werden ( Adding reading to queue ...) und damit nicht an den
HTTP-Server weitergereicht werden?
Ausserdem fällt auf, dass der Timestamp ts=0 ist!
Ich sehe den sml-meter auch im Browser, aber keine Werte-Tupel. Hier der
JSON-Auszug:
{ "version": "0.6.0", "generator": "vzlogger", "data": [ { "uuid":
"180a", "last": 0, "interval": -1, "protocol": "sml" }, { "uuid":
"180c", "last": 0, "interval": -1, "protocol": "sml" }, { "uuid":
"121e", "last": 1572339709909, "interval": -1, "protocol": "s0",
"tuples": [ [ 1572339562898, 0 ]
Hier meine vzlogger Konfig (ohne die S0-meter-Definitionen):
// vzlogger.conf with sml (Strom)
"daemon": true,
"verbosity": 15,
"log": "/var/log/vzlogger.log",
"retry": 30,// http retry delay in seconds
// Build-in HTTP server
"local": {
"enabled": true,
"port": 8080,
"index": true,
"timeout": 30,
"buffer": 3600
},
// Meter configuration
"meters": [
// sml meter (Strom)
{
"enabled": true,
"protocol": "sml",
"device": "/dev/ttyUSB0",
"baudrate": 9600,
"parity": "8n1",
"skip": false,
"channels": [
{
"uuid": "180a",
"identifier": "counter", // 1.8.1 Zaehlerstand
Wirkleistung 1-0:1.8.255*255
"api": "null",
"duplicates": 0
},
{
"uuid": "180c",
"identifier": "counter-out", // 2.8.1 Zaehlerstand Lieferg.
1-0:2.8.255*255
"api": "null",
"duplicates": 0
}
]
},
]
}
vzlogger läuft bei mir auf OpenWrt in v0.6.0.
Hat jemand eine Idee, wo der Fehler liegt?
Viele Grüße
Re: [vz-users] Hall Sensor für Wasserzähler von Diehl
Hallo, ich registriere mit einem induktiven Näherungsschalter, über die Metallscheibe meines Wasserzählers platziert, die Impulse. Den Schalter gibt es für kleines Geld im Netz ( https://picclick.de/Induktiver-N%C3%A4herungsschalter-N%C3%A4herungssensor-LJ12A3-4-Z-BX-Three-Wire-Schlie%C3%9Fer-192365455405.html ) Viele Grüße Winfried Am 24. November 2017 um 10:29 schrieb Christian Schnellrieder < schnellrieder...@gmail.com>: > Hallo. > > Ich hab hier einen Wasserzähler von Diehl den ich gerne auslesen möchte. > Der Zähler selbst hat zwar ein wireless M Bus Modul... aber nach einiger > recherche im Internet sehe ich da keine Möglichkeit. > > Im Sichtbereich ist aber eine Metall Scheibe mit einen Magneten. Ich > vermute mal das das M Bus Modul einfach nur die "Impulse" zählt. > Ich hab jetzt mal versucht mit einem "Schalter (SS441A)" einen Impuls zu > lesen. War aber leider negativ. Ich denke mal der Magnet ist zuweit weg vom > Glas (geschätzt 5-6mm) > > Also würde ich gerne das mit einen "linear" Sensor testen. > > Hat jemand Erfahrungen mit Hall Sensoren und kann mir jemand eine Type > empfehlen der zu diesem Einsatzgebiet gut passt? > Der Pi hat ja leider keinen analogen Eingang. Ich glaub jetzt mal: Ich > brauch hier einen AD Wandler. Vielleicht hat auch hier jemand einen Tipp > für mich welche Type hier am einfachsten zu verwenden ist. > > > Grüße, > Christian > -- > > Von meinem Smartphone versendet >
Re: [vz-users] vzlogger-Leseprobleme mit SmartMeter EMH-ITZ
> Aber wie hast Du das gemacht- nur anders positioniert? Ich habe im Gummiring der D0-Schnittstelle meines Zählers eine mattschwarze Schablone mit zwei Löschern für die IR-Dioden eingepasst. Damit wurde das helle Gehäuse abgedeckt und die Reflexionen waren verschwunden. > Und warum ist das nicht auch bei HTerm aufgetreten??? Bei HTerm ist es auch aufgetreten. Hier die ersten drei Zeilen der HTerm-Aufzeichnung: /?420818! /EMH4\@--ITZ-G0038E F.F()0.0.0(00420818) Die erste Zeile ist die vzlogger-Pullsequenz, die als Reflexion zurückgekommen ist. Danach folgt die Zählerbezeichnung und das Datentelegramm. Viele Grüße Winfried Am 26. November 2016 um 22:34 schrieb Andreas Götz : > Super! Aber wie hast Du das gemacht- nur anders positioniert? Und warum > ist das nicht auch bei HTerm aufgetreten??? > > Viele Grüße, Andreas > > Am 26.11.2016 um 17:44 schrieb Winfried Peters >: > > Hallo zusammen, > > mein Problem ist gelöst! > > Udo hatte mir den entscheidenden Hinweis gegeben. Ich hatte Eingangs ein > Echo meines Zählers beschrieben. Im d0-Dump kann man es auch gut sehen. > Dieses Echo war eine Reflexion meines hellen Zählergehäuses. Das hat > vzlogger regelmäßig zu Beginn einer Pullsequenz ins Stolpern gebracht. Ich > habe die Reflexion beseitigt. Jetzt habe ich keine Fehler mehr im Verbose 0 > Log. vzlogger arbeitet wie erwartet. > > Ich danke allen, die sich hier eingebracht haben. > > Viele Grüße > Winfried > > Am 22. November 2016 um 22:31 schrieb Winfried Peters < > winfried.pet...@gmail.com>: > >> Hallo Andreas, >> >> ich habe eine HTerm-Sequenz aufgezeichnet und als Raw- sowie Hex-Datei >> angehängt. >> >> Hier mein in den Spalten ASCII, HTerm und vzlogger aufbereiteter >> Vergleich: >> >> ASCIIHTerm (ab dem 1. Pullversuch) vzlogger >> (d0-24.txt, ab dem 11. Pullversuch) >> >> --- >> /?420818!2F3F343230383138210D0A >> 2f3f343230383138210d0a >> /EMH4\@--ITZ-G0038E 2F454D48345C402D2D49545A2D4730303338450D0A 0a0a >> 2f454d48345c001a1012203020002238450a0a >> F.F()02462E46283030303030303030290D0A >> 02462e46283030303030303030290a0a >> >>- Zum einem fällt auf, dass vzlogger carriage return/line feed 0x0D >>0x0A in 0x0a 0xa umsetzt. >>- Zum anderen wird mein Zähleridentifier @--ITZ-G0038E von vzlogger >>nicht korrekt decodiert. Das ist nicht nur in der hier dokumentierten >>d0-Konfiguration so, sonder in allen bisher von mir getesteten >>Konfigurationsvarianten. >>- HTerm gibt gleich nach der 1. Aufforderung das Datentelegramm >>komplett aus. >>- vzlogger benötigt 11 Pullsequenzen, bis das Datentelegramm erkannt >>wird. >> >> Viele Grüße >> Winfried >> >> Am 22. November 2016 um 09:04 schrieb Andreas Götz : >> >>> Moin, >>> >>> Ich kenne mich mit dem ganzen seriellen Kram ja nicht wirklich aus, aber >>> wäre es nicht möglich das d0 Log vom vzlogger aus dem ersten Post mit dem >>> Binary Log aus HTerm nebeneinander zu legen? Z.B. ab Senden der Pullsequenz? >>> >>> Damit sollte sich doch rauskriegen lassen ob vzlogger falsch liest oder >>> falsch decodiert? >>> >>> @Winfried: dafür bräuchte es dann auch einen Dump aus HTerm? >>> >>> Viele Grüße, Andreas >>> >>> > Am 20.11.2016 um 20:41 schrieb Daniel Lauckner : >>> > >>> > Hallo Andreas, >>> > >>> > >>> > am Sonntag, 20. November 2016 um 18:55 hast du geschrieben: >>> >> ...und ist der so gut wie der von Hterm? >>> > >>> > Soweit ich den Dump interpretiere sind da massive Fehler drin. >>> > >>> > >>> > mfg Daniel >>> > >>> >> >> >
Re: [vz-users] vzlogger-Leseprobleme mit SmartMeter EMH-ITZ
Hallo zusammen, mein Problem ist gelöst! Udo hatte mir den entscheidenden Hinweis gegeben. Ich hatte Eingangs ein Echo meines Zählers beschrieben. Im d0-Dump kann man es auch gut sehen. Dieses Echo war eine Reflexion meines hellen Zählergehäuses. Das hat vzlogger regelmäßig zu Beginn einer Pullsequenz ins Stolpern gebracht. Ich habe die Reflexion beseitigt. Jetzt habe ich keine Fehler mehr im Verbose 0 Log. vzlogger arbeitet wie erwartet. Ich danke allen, die sich hier eingebracht haben. Viele Grüße Winfried Am 22. November 2016 um 22:31 schrieb Winfried Peters < winfried.pet...@gmail.com>: > Hallo Andreas, > > ich habe eine HTerm-Sequenz aufgezeichnet und als Raw- sowie Hex-Datei > angehängt. > > Hier mein in den Spalten ASCII, HTerm und vzlogger aufbereiteter Vergleich: > > ASCIIHTerm (ab dem 1. Pullversuch) vzlogger > (d0-24.txt, ab dem 11. Pullversuch) > > --- > /?420818!2F3F343230383138210D0A > 2f3f343230383138210d0a > /EMH4\@--ITZ-G0038E 2F454D48345C402D2D49545A2D4730303338450D0A 0a0a > 2f454d48345c001a1012203020002238450a0a > F.F()02462E46283030303030303030290D0A > 02462e46283030303030303030290a0a > >- Zum einem fällt auf, dass vzlogger carriage return/line feed 0x0D >0x0A in 0x0a 0xa umsetzt. >- Zum anderen wird mein Zähleridentifier @--ITZ-G0038E von vzlogger >nicht korrekt decodiert. Das ist nicht nur in der hier dokumentierten >d0-Konfiguration so, sonder in allen bisher von mir getesteten >Konfigurationsvarianten. >- HTerm gibt gleich nach der 1. Aufforderung das Datentelegramm >komplett aus. >- vzlogger benötigt 11 Pullsequenzen, bis das Datentelegramm erkannt >wird. > > Viele Grüße > Winfried > > Am 22. November 2016 um 09:04 schrieb Andreas Götz : > >> Moin, >> >> Ich kenne mich mit dem ganzen seriellen Kram ja nicht wirklich aus, aber >> wäre es nicht möglich das d0 Log vom vzlogger aus dem ersten Post mit dem >> Binary Log aus HTerm nebeneinander zu legen? Z.B. ab Senden der Pullsequenz? >> >> Damit sollte sich doch rauskriegen lassen ob vzlogger falsch liest oder >> falsch decodiert? >> >> @Winfried: dafür bräuchte es dann auch einen Dump aus HTerm? >> >> Viele Grüße, Andreas >> >> > Am 20.11.2016 um 20:41 schrieb Daniel Lauckner : >> > >> > Hallo Andreas, >> > >> > >> > am Sonntag, 20. November 2016 um 18:55 hast du geschrieben: >> >> ...und ist der so gut wie der von Hterm? >> > >> > Soweit ich den Dump interpretiere sind da massive Fehler drin. >> > >> > >> > mfg Daniel >> > >> > >
Re: [vz-users] vzlogger-Leseprobleme mit SmartMeter EMH-ITZ
Hallo Andreas, ich habe eine HTerm-Sequenz aufgezeichnet und als Raw- sowie Hex-Datei angehängt. Hier mein in den Spalten ASCII, HTerm und vzlogger aufbereiteter Vergleich: ASCIIHTerm (ab dem 1. Pullversuch) vzlogger (d0-24.txt, ab dem 11. Pullversuch) --- /?420818!2F3F343230383138210D0A 2f3f343230383138210d0a /EMH4\@--ITZ-G0038E 2F454D48345C402D2D49545A2D4730303338450D0A 0a0a 2f454d48345c001a1012203020002238450a0a F.F()02462E46283030303030303030290D0A 02462e46283030303030303030290a0a - Zum einem fällt auf, dass vzlogger carriage return/line feed 0x0D 0x0A in 0x0a 0xa umsetzt. - Zum anderen wird mein Zähleridentifier @--ITZ-G0038E von vzlogger nicht korrekt decodiert. Das ist nicht nur in der hier dokumentierten d0-Konfiguration so, sonder in allen bisher von mir getesteten Konfigurationsvarianten. - HTerm gibt gleich nach der 1. Aufforderung das Datentelegramm komplett aus. - vzlogger benötigt 11 Pullsequenzen, bis das Datentelegramm erkannt wird. Viele Grüße Winfried Am 22. November 2016 um 09:04 schrieb Andreas Götz : > Moin, > > Ich kenne mich mit dem ganzen seriellen Kram ja nicht wirklich aus, aber > wäre es nicht möglich das d0 Log vom vzlogger aus dem ersten Post mit dem > Binary Log aus HTerm nebeneinander zu legen? Z.B. ab Senden der Pullsequenz? > > Damit sollte sich doch rauskriegen lassen ob vzlogger falsch liest oder > falsch decodiert? > > @Winfried: dafür bräuchte es dann auch einen Dump aus HTerm? > > Viele Grüße, Andreas > > > Am 20.11.2016 um 20:41 schrieb Daniel Lauckner : > > > > Hallo Andreas, > > > > > > am Sonntag, 20. November 2016 um 18:55 hast du geschrieben: > >> ...und ist der so gut wie der von Hterm? > > > > Soweit ich den Dump interpretiere sind da massive Fehler drin. > > > > > > mfg Daniel > > > output_2016-11-22_21-17-00-raw.log Description: Binary data output_2016-11-22_21-17-00-hex.log Description: Binary data
Re: [vz-users] vzlogger-Leseprobleme mit SmartMeter EMH-ITZ
Dann reden wir von unterschiedlichen Dumps. HTerm liefert mir die Rohdaten, wie sie vom Lesekopf übertragen werden. In vzlogger kenne ich nur den Parameter "dump_file", der einen speziellen vzlogger-d0-Dump ausgibt. Den habe ich angehängt. Wie kann ich mit vzlogger einen Rohdaten-Dump erzeugen? Viele Grüße Winfried Am 20. November 2016 um 18:55 schrieb Andreas Götz : > ...und ist der so gut wie der von Hterm? > > Am 20.11.2016 um 18:32 schrieb Winfried Peters >: > > Ich hatte in meiner 1. Mail einen Dump (Datei d0-24.txt) angehängt. > > Viele Grüße > Winfried > > Am 20. November 2016 um 17:43 schrieb Andreas Götz : > >> M.e. Kann vzlogger alle Daten dumpen. Dann wäre das der erste Schritt um >> zu schauen ob die ebenfalls sauber aussehen? >> >> Viele Grüße, Andreas >> >> Am 20.11.2016 um 16:51 schrieb Winfried Peters > >: >> >> Hallo Daniel, >> >> das ist ein USB-IR-Schreib-Lesekopf von Udo. Die Lesekopfposition wurde >> schon variiert. Udo hatte mir auch einen neuen Lesekopf zugeschickt, da der >> Verdacht auf einen Hardwarefehler nahelag. Aber das Ergebnis war das >> Gleiche. HMterm liefert übrigens ein sauberes Zählertelegramm. >> >> Ich setze die vzlogger-Version 0.6.0 ein. >> >> Viele Grüße >> Winfried >> >> >> Am 20. November 2016 um 14:52 schrieb Daniel Lauckner : >> >>> Hallo Winfried, >>> >>> >>> am Sonntag, 20. November 2016 um 14:10 hast du geschrieben: >>> > Trotz weiterer Erkenntnisse und Optimierungsversuche ist es mir bis >>> > heute nicht gelungen das Zählertelegramm ohne Fehlermeldungen zu >>> > lesen. Ich bekomme pro Lesezyklus fünf bis acht "binary >>> > character"-Fehlereinträge im Log. >>> >>> Hast du auch mal die Postion des Lesekopfes verändert? >>> Was ist es für ein Lesekopf? >>> >>> Sieht für mich nach Lesefehlern aus. >>> >>> >>> mfg Daniel >>> >>> >> >
Re: [vz-users] vzlogger-Leseprobleme mit SmartMeter EMH-ITZ
Ich hatte in meiner 1. Mail einen Dump (Datei d0-24.txt) angehängt. Viele Grüße Winfried Am 20. November 2016 um 17:43 schrieb Andreas Götz : > M.e. Kann vzlogger alle Daten dumpen. Dann wäre das der erste Schritt um > zu schauen ob die ebenfalls sauber aussehen? > > Viele Grüße, Andreas > > Am 20.11.2016 um 16:51 schrieb Winfried Peters >: > > Hallo Daniel, > > das ist ein USB-IR-Schreib-Lesekopf von Udo. Die Lesekopfposition wurde > schon variiert. Udo hatte mir auch einen neuen Lesekopf zugeschickt, da der > Verdacht auf einen Hardwarefehler nahelag. Aber das Ergebnis war das > Gleiche. HMterm liefert übrigens ein sauberes Zählertelegramm. > > Ich setze die vzlogger-Version 0.6.0 ein. > > Viele Grüße > Winfried > > > Am 20. November 2016 um 14:52 schrieb Daniel Lauckner : > >> Hallo Winfried, >> >> >> am Sonntag, 20. November 2016 um 14:10 hast du geschrieben: >> > Trotz weiterer Erkenntnisse und Optimierungsversuche ist es mir bis >> > heute nicht gelungen das Zählertelegramm ohne Fehlermeldungen zu >> > lesen. Ich bekomme pro Lesezyklus fünf bis acht "binary >> > character"-Fehlereinträge im Log. >> >> Hast du auch mal die Postion des Lesekopfes verändert? >> Was ist es für ein Lesekopf? >> >> Sieht für mich nach Lesefehlern aus. >> >> >> mfg Daniel >> >> >
Re: [vz-users] vzlogger-Leseprobleme mit SmartMeter EMH-ITZ
Hallo Daniel, das ist ein USB-IR-Schreib-Lesekopf von Udo. Die Lesekopfposition wurde schon variiert. Udo hatte mir auch einen neuen Lesekopf zugeschickt, da der Verdacht auf einen Hardwarefehler nahelag. Aber das Ergebnis war das Gleiche. HMterm liefert übrigens ein sauberes Zählertelegramm. Ich setze die vzlogger-Version 0.6.0 ein. Viele Grüße Winfried Am 20. November 2016 um 14:52 schrieb Daniel Lauckner : > Hallo Winfried, > > > am Sonntag, 20. November 2016 um 14:10 hast du geschrieben: > > Trotz weiterer Erkenntnisse und Optimierungsversuche ist es mir bis > > heute nicht gelungen das Zählertelegramm ohne Fehlermeldungen zu > > lesen. Ich bekomme pro Lesezyklus fünf bis acht "binary > > character"-Fehlereinträge im Log. > > Hast du auch mal die Postion des Lesekopfes verändert? > Was ist es für ein Lesekopf? > > Sieht für mich nach Lesefehlern aus. > > > mfg Daniel > >
[vz-users] vzlogger-Leseprobleme mit SmartMeter EMH-ITZ
Hallo, ich hatte hier in dieser Runde im Januar diesen Jahres mein Ausleseproblem mit meinem smarten Drehstromzähler geschildert. Ich hatte dann das Issue #233 aufgemacht und dann wieder geschlossen, nachdem ich eine vzlogger-Konfiguration gefunden hatte, die mir meine gewünschten Werte lieferte. Trotz weiterer Erkenntnisse und Optimierungsversuche ist es mir bis heute nicht gelungen das Zählertelegramm ohne Fehlermeldungen zu lesen. Ich bekomme pro Lesezyklus fünf bis acht "binary character"-Fehlereinträge im Log. Das Log wird dann, auch bei verbosity 0, über die Zeit sehr groß. Da ich inzwischen sehr viele vzlogger-Konfigurationsvarianten getestet habe, komme ich zum Schluss, dass vzlogger meinen Zähler nicht korrekt parsen kann. Ich hoffe mit Eurer Hilfe den Grund dafür zu finden. Allgemeine Infos zum Zähler: - Mein SmartMeter ist ein EMH-ITZ mit der Bezeichnung "ITZ W1E8-00-STK-D3--N50/K" - Der Zähler sendet über die optische D0-Datenschnittstelle das OBIS-Protokoll - Laut Netzbetreiber ist der Zähler angeblich fest auf 4800 Bd eingestellt - Der Zähler ist ein sog. Pull-Zähler, d.h. er sendet nur auf Anforderung ein Datentelegramm - Die Anforderungssequenz erfordert zwingend die Eigentumsnummer 420818: /?420818! - Der Zähler gibt grundsätzlich eine Eingabe als Antwort sofort wieder zurück (Echo) Meine bisherigen Konfigurationserkenntnisse: - Ich kann den Zähler mit Übertragungsraten von 300 Bd bis 9600 Bd erfolgreich auslesen (über die Parameter "ackseq" und "baudrate_read"). Mit der Übertragungrate 300 Bd werden aber die wenigsten Fehler produziert, d.h damit wächst mein Log am langsamsten. - Ohne „baudrate_change_delay" oder mit „baudrate_change_delay" = 0 werden keine Daten ausgegeben. Die bisher optimale Umschaltzeit „baudrate_change_delay" für die Umstellung auf die Auslesegeschwindigkeit ist 300ms, auch wenn, wie in meiner aktuelle Konfiguration, bei eingestellten 300 Bd nicht umgeschaltet werden muss. - Die Parameter "interval", "aggtime", "aggmode", "baudrate_read" und "ackseq" sind bei einer Übertragungsrate von 300 Bd nicht notwendig. - Bei 300 Bd dauert ein kompletter Lesezyklus, das Zählertelegramm besteht aus über hundert Datensätzen, ca. 91 Sekunden. Nun zu meinem Poblem: Dass vzlogger nicht ganz sauber den Datenstrom parst, sehe ich in den binary character-Fehlern bei jedem Telegrammdurchlauf. Nach in der Regel drei Pullsequenzen erkennt vzlogger den Zähler, zumindest teilweise, und parst das vollständige Telegramm. 5 bis 8 Character kann er in der Anfangssequenz nicht erkennen. Das führt zu binary character Fehlern. So sehen meine Zählerrohdaten aus (mit Kommentaren rechts): /?420818! Antwort Pullsequenz mit Eigentumsnummer /EMH4\@--ITZ-G0038E Zählerbezeichnung F.F()0.0.0(00420818)Eigentumsnummer 0.0.1(02256230) 0.1.0(65) 0.1.2*65(016010100) Datum der jeweiligen Monatsspeicherung 0.1.2*64(015120100) Hier der Log-Ausschnitt (verbosity 15) nach einer Pullsequenz: [Nov 19 20:07:45][d0] sending pullsequenz send (len:11 is:11). [Nov 19 20:07:45][d0] > binary character '0' [Nov 19 20:07:45][d0] > binary character '1a' [Nov 19 20:07:45][d0] > binary character '10' [Nov 19 20:07:45][d0] > binary character '12' [Nov 19 20:07:45][d0] > binary character '0' [Nov 19 20:07:45][d0] > binary character '0' [Nov 19 20:07:46][d0] > binary character '2' [Nov 19 20:07:46][d0] Pull answer (vendor=EMH, baudrate=4, identification=\ 0 8E) [Nov 19 20:07:49][d0] DEBUG OBIS_CODE byte ^B hex= 2 [Nov 19 20:07:49][d0] DEBUG OBIS_CODE byte F hex= 46 [Nov 19 20:07:49][d0] DEBUG OBIS_CODE byte . hex= 2E [Nov 19 20:07:49][d0] DEBUG OBIS_CODE byte F hex= 46 [Nov 19 20:07:49][d0] DEBUG OBIS_CODE byte ( hex= 28 [Nov 19 20:07:49][d0] DEBUG VALUE byte= 0 hex= 30 [Nov 19 20:07:49][d0] DEBUG VALUE byte= 0 hex= 30 [Nov 19 20:07:49][d0] DEBUG VALUE byte= 0 hex= 30 [Nov 19 20:07:49][d0] DEBUG VALUE byte= 0 hex= 30 [Nov 19 20:07:49][d0] DEBUG VALUE byte= 0 hex= 30 [Nov 19 20:07:49][d0] DEBUG VALUE byte= 0 hex= 30 [Nov 19 20:07:49][d0] DEBUG VALUE byte= 0 hex= 30 [Nov 19 20:07:49][d0] DEBUG VALUE byte= 0 hex= 30 [Nov 19 20:07:49][d0] DEBUG VALUE byte= ) hex= 29 [Nov 19 20:07:49][d0] Parsed reading (OBIS code=F.F, value=, unit=) Die binary character-Fehler nach der Pullsequenz stehen auch im vebosity 0-Log. vzlogger liest in der Pull answer den Vendor EMH und die Baudrate 4 korrekt. identification wird regelmäßig nicht erkannt. Im Anhang habe ich den zugehörigen D0-Dump "d0-24.txt" gestellt. Wie oben beschrieben kann ich die Übertragungsrate zwar auf einen höheren Wert einstellen, aber dann bekomme ich im vebosity 0-Log hunderte Fehler "Too much data for obis_code (byte=0x0)", bis irgendwann wieder OBIS-Codes erkannt werden. Hier meine aktuelle D0-Konfiguration: "meters": [
[vz-users] Probleme mit der Baudraten-Umstellung eines D0-Drehstromzählers
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 0d 0a /?420818! > 54.695868362s ( 0 ms) 01 00 63 05 2d 2d 49 54 5a 2d 47 30 30 33 38 41 c --ITZ-G0038A 0a 02 36 42 0b 43 0b 6a 0a 02 46 2e 46 28 30 30 6B C j F.F(00 --- Ende d0-dump--
Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
OK, ich werde dafür ein neues Issue aufmachen.
Das Issue #233 werde ich schließen, da ich jetzt Daten bekomme.
Nach vielen Versuchen habe ich jetzt eine halbwegs stabile Konfiguration
gefunden, die mindestens 3 Zählertelegramme hintereinander fehlerfrei
verarbeitet.
Ich fasse meine bisherigen Erkenntnisse zusammen:
Mein Zähler verlangt ein Passwort und 4800 Bd. Nach der erfolgreichen
Pullsequenz sendet der Zähler sofort das komplette Telegramm. Ein ackseq
ist deswegen nicht notwendig und würde die Übertragung stoppen. Nach ca. 92
s ist die Telegrammübertragung beendet und die nächste Sequenz wird
gestartet. Das Telegramm wird nur ausgewetet, wenn die Zähleridentifikation
mit /EMH4 am Telegrammanfang vorhanden ist. Das konnte ich am saubersten
mit "wait_sync": "end" und "baudrate_change_delay": 300 erreichen. Das 1.
Telegramm ist komplett mit der Antwortnachricht der Pullsequenz, die
Folgetelegramme werden am Anfang um ein paar Bytes abgeschnitten, ist aber
unschädlich, solange die Zahleridentifikation vorhanden ist. Die
Übertragung erfolgt immer nur in 300 Bd.
Das Optimum wäre, wenn die Umschaltung auf 4800 Bd gelänge und die
Telegramme von Anfang an gelesen werden. Dann kann ich sicher sein, dass
keine Daten verloren gehen.
Vielleicht hat ja jemand noch eine Idee.
Hier meine aktuelle vzlogger.conf:
{
"retry": 0,
"daemon": true,
"verbosity": 15,
"log": "/var/log/vzlogger.log",
"local": {
"enabled": true,
"port": 8080,
"index": true,
"timeout": 0,
"buffer": 600
},
// Meter configuration
"meters": [
{
"enabled": true,
"allowskip": false,
"channels": [
{
"uuid": "180a",
"identifier": "1.8.1",
"api": "null",
"duplicates": 0
}
],
"protocol": "d0",
"device": "/dev/ttyUSB0",
"pullseq": "2F3F343230383138210D0A",
"baudrate": 300,
"baudrate_read": 4800,
"parity": "7e1",
"wait_sync": "end",
"read_timeout": 94,
"baudrate_change_delay": 300
}
]
}
Für Analysezwecke hänge ich hänge noch die Dump-Datei an.
Viele Grüße
Am 17. Januar 2016 um 08:40 schrieb Andreas Götz :
> Mach gerne ein issue für jeden falsch erklärten Parameter auf.
>
> Viele Grüße, Andreas
>
> Am 17.01.2016 um 01:16 schrieb Winfried Peters >:
>
> Ok, es war schon spät. Ich konnte die Bedeutung von "wait_sync" im
> Config-Editor nachlesen.
>
> Verwirrend ist, dass die Parameterbeschreibungen im Config-Editor
> <http://volkszaehler.github.io/vzlogger/> und der Muster.conf zum Teil
> nicht übereinstimmen, wie z.B. read_timeout.
>
> Viele Grüße
>
> Am 17. Januar 2016 um 00:52 schrieb Winfried Peters <
> winfried.pet...@gmail.com>:
>
>> Hallo,
>>
>> im Ausschlussverfahren habe ich Schritt für Schritt Parameter aus der
>> conf herausgenommen. Erkenntnis: Ohne den Parameter "wait_sync": "off"
>> geht garnichts.
>>
>> Ein versuchsweises "wait_sync": "on" führt zum Parsingfehler: Failed to
>> parse configuration due to: Invalid wait_sync
>>
>> Ist der Parameter irgendwo dokumentiert bzw. kann mir jemand die
>> Bedeutung nennen?
>>
>> Viele Grüße
>>
>> Am 16. Januar 2016 um 22:39 schrieb Winfried Peters <
>> winfried.pet...@gmail.com>:
>>
>>> > Dann mach die mal gößer.
>>>
>>> Ich habe es ausgetestet: Erfolg habe ich nur im Bereich 100 bis 150. Das
>>> beste Ergebnis ist mit "baudrate_change_delay": 100.
>>>
>>> Ich habe auch mal bei "read_timeout": 50 Daten bekommen. Das war aber
>>> nicht reproduzierbar.
>>> Lasse ich "ackseq": "063034300d0a" weg, kommen auch keine Daten, obwohl
>>> bei den erfolgreichen Versuchenl für mich nicht erkennbar auf 4800 Baud
>>> umgeschaltet wird.
>>>
>>> Bisheriges Fazit: Die Kommunikation ruckelt noch, aber es kommen Daten
>>> an.
>>>
>>> Viele Grüße
>>>
>>>
>>>
>>> Am 16. Januar 2016 um 19:07 schrieb Udo1 :
>>>
>>>>
>>>> Am 16.01.2016 um 18:52 schrieb Winfried Peters:
>>>>
>>>>> "baudrate_change_delay": 100
>>>>>
>>>> Dann mach die mal gößer.
>>>>
>>>> Gruß
>>>> Udo
>>>>
>>
Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
Ok, es war schon spät. Ich konnte die Bedeutung von "wait_sync" im Config-Editor nachlesen. Verwirrend ist, dass die Parameterbeschreibungen im Config-Editor <http://volkszaehler.github.io/vzlogger/> und der Muster.conf zum Teil nicht übereinstimmen, wie z.B. read_timeout. Viele Grüße Am 17. Januar 2016 um 00:52 schrieb Winfried Peters < winfried.pet...@gmail.com>: > Hallo, > > im Ausschlussverfahren habe ich Schritt für Schritt Parameter aus der conf > herausgenommen. Erkenntnis: Ohne den Parameter "wait_sync": "off" geht > garnichts. > > Ein versuchsweises "wait_sync": "on" führt zum Parsingfehler: Failed to > parse configuration due to: Invalid wait_sync > > Ist der Parameter irgendwo dokumentiert bzw. kann mir jemand die > Bedeutung nennen? > > Viele Grüße > > Am 16. Januar 2016 um 22:39 schrieb Winfried Peters < > winfried.pet...@gmail.com>: > >> > Dann mach die mal gößer. >> >> Ich habe es ausgetestet: Erfolg habe ich nur im Bereich 100 bis 150. Das >> beste Ergebnis ist mit "baudrate_change_delay": 100. >> >> Ich habe auch mal bei "read_timeout": 50 Daten bekommen. Das war aber >> nicht reproduzierbar. >> Lasse ich "ackseq": "063034300d0a" weg, kommen auch keine Daten, obwohl >> bei den erfolgreichen Versuchenl für mich nicht erkennbar auf 4800 Baud >> umgeschaltet wird. >> >> Bisheriges Fazit: Die Kommunikation ruckelt noch, aber es kommen Daten an. >> >> Viele Grüße >> >> >> >> Am 16. Januar 2016 um 19:07 schrieb Udo1 : >> >>> >>> Am 16.01.2016 um 18:52 schrieb Winfried Peters: >>> >>>> "baudrate_change_delay": 100 >>>> >>> Dann mach die mal gößer. >>> >>> Gruß >>> Udo >>> >> >> >
Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
Hallo, im Ausschlussverfahren habe ich Schritt für Schritt Parameter aus der conf herausgenommen. Erkenntnis: Ohne den Parameter "wait_sync": "off" geht garnichts. Ein versuchsweises "wait_sync": "on" führt zum Parsingfehler: Failed to parse configuration due to: Invalid wait_sync Ist der Parameter irgendwo dokumentiert bzw. kann mir jemand die Bedeutung nennen? Viele Grüße Am 16. Januar 2016 um 22:39 schrieb Winfried Peters < winfried.pet...@gmail.com>: > > Dann mach die mal gößer. > > Ich habe es ausgetestet: Erfolg habe ich nur im Bereich 100 bis 150. Das > beste Ergebnis ist mit "baudrate_change_delay": 100. > > Ich habe auch mal bei "read_timeout": 50 Daten bekommen. Das war aber > nicht reproduzierbar. > Lasse ich "ackseq": "063034300d0a" weg, kommen auch keine Daten, obwohl > bei den erfolgreichen Versuchenl für mich nicht erkennbar auf 4800 Baud > umgeschaltet wird. > > Bisheriges Fazit: Die Kommunikation ruckelt noch, aber es kommen Daten an. > > Viele Grüße > > > > Am 16. Januar 2016 um 19:07 schrieb Udo1 : > >> >> Am 16.01.2016 um 18:52 schrieb Winfried Peters: >> >>> "baudrate_change_delay": 100 >>> >> Dann mach die mal gößer. >> >> Gruß >> Udo >> > >
Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
> Dann mach die mal gößer. Ich habe es ausgetestet: Erfolg habe ich nur im Bereich 100 bis 150. Das beste Ergebnis ist mit "baudrate_change_delay": 100. Ich habe auch mal bei "read_timeout": 50 Daten bekommen. Das war aber nicht reproduzierbar. Lasse ich "ackseq": "063034300d0a" weg, kommen auch keine Daten, obwohl bei den erfolgreichen Versuchenl für mich nicht erkennbar auf 4800 Baud umgeschaltet wird. Bisheriges Fazit: Die Kommunikation ruckelt noch, aber es kommen Daten an. Viele Grüße Am 16. Januar 2016 um 19:07 schrieb Udo1 : > > Am 16.01.2016 um 18:52 schrieb Winfried Peters: > >> "baudrate_change_delay": 100 >> > Dann mach die mal gößer. > > Gruß > Udo >
Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
Deinen Vorschlag habe ich als Tesfall 49 ausprobiert. Leider negativ. Es
werden wieder ein paar Bytes am Anfang der Zählernachricht verschluckt. Das
führt dazu, dass keine Daten in der API ankommen. Der Zähler bleibt bei 300
Baud (92 s Ausgabedauer). Ohne baudrate_read funktioniert es, allerdings
nur mit 300 Baud.
Es gibt anscheinend Probleme beim Aushandeln der Baudrate. Dabei
verschluckt sich vzlogger noch, mit dem Effekt, dass keine Daten ankommen.
Verstehen tue ich es noch nicht.
Viele Grüße
Am 16. Januar 2016 um 18:32 schrieb Udo1 :
> Am 16.01.2016 um 18:09 schrieb Winfried Peters:
>
>> Mir ist auch nicht klar, ob ich "baudrate_read": 4800 setzen muss, wenn
>> ich den Zähler auffordere, in dieser Baudrate zu senden ("ackseq":
>> "063034300d0a").
>>
> Dazu müsste deine vzlogger.conf so aussehen:
>
> {
> "retry": 0,
> "daemon": true,
> "verbosity": 0,
> "log": "/var/log/vzlogger.log",
> "local": {
> "enabled": true,
> "port": 8080,
> "index": true,
> "timeout": 0,
> "buffer": 0
> },
> "meters": [
> {
> "enabled": true,
> "allowskip": false,
> "interval": -1,
> "aggtime": -1,
> "aggfixedinterval": false,
> "channels": [
> {
> "uuid": "180a",
> "identifier": "1.8.1",
> "api": "null",
> "aggmode": "none",
> }
> ],
> "protocol": "d0",
> "device": "/dev/ttyUSB0",
> "pullseq": "2F3F343230383138210D0A",
> "ackseq": "063034300d0a",
> "baudrate": 300,
> "baudrate_read": 4800,
> "parity": "7e1",
> "read_timeout": 100,
> "baudrate_change_delay": 100
> }
> ]
> }
>
> Wobei du mit read_timeout noch variieren kannst.
>
> Gruß
> Udo
>
Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
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 : > 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 : > >> 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] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
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 : > 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 >
Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
ndor=wS▒▒!Jan 16 ,
baudrate=, identification=)
[Jan 16 09:50:05][mtr0] Got 0 new readings from meter:
[Jan 16 09:50:05][chn0] Buffer dump (size=0): {}
[Jan 16 09:50:05][d0] sending pullsequenz send (len:11 is:11).
[Jan 16 09:50:06][d0] Read package with 0 tuples (vendor=wS▒▒!Jan 16 ,
baudrate=, identification=)
[Jan 16 09:50:06][mtr0] Got 0 new readings from meter:
[Jan 16 09:50:06][chn0] Buffer dump (size=0): {}
[Jan 16 09:50:06][d0] sending pullsequenz send (len:11 is:11).
[Jan 16 09:50:06] MapContainer::quit terminating on signal 15.
[Jan 16 09:50:06] Closing connections to terminate
[Jan 16 09:50:06][main] MeterMap::cancel entered...
[Jan 16 09:50:06][main] MeterMap::cancel wait for readingthread
[Jan 16 09:50:06][main] MeterMap::cancel wait for meter::close
[Jan 16 09:50:06][main] MeterMap::cancel finished.
[Jan 16 09:50:06][main] MapContainer::quit finished.
Viele Grüße
Am 15. Januar 2016 um 21:59 schrieb Winfried Peters <
winfried.pet...@gmail.com>:
> Hallo,
>
> ja, kenne ich. Ich habe schon vieles durchdekliniert und geprüft. Komme
> jetzt aber nicht mehr weiter.
> Ich kann noch meinen vzlogger-Versionsstand 0.5.1 nachreichen.
>
> Viele Grüße
>
> Am 15. Januar 2016 um 21:43 schrieb Andreas Götz :
>
>> Wiki howto/debug kennst Du?
>>
>> Viele Grüße, Andreas
>>
>> > Am 15.01.2016 um 18:55 schrieb Winfried Peters <
>> winfried.pet...@gmail.com>:
>> >
>> > Hallo VZ-Gemeinde,
>> >
>> > ich habe endlich meinen Drehstromzähler, ein EMH-ITZ aus dem Jahr 2010,
>> mit der richtigen Pullsequenz zum Sprechen gebracht. Das Programm HTerm als
>> auch ein "cat /dev/ttyUSB0" zeigen mir ein komplettes Zählertelegramm. Die
>> Übertragung dauert in der Regel ca. 90 Sekunden (mit 300 Baud). Udo's Tipps
>> waren da sehr hilfreich. Die Diskussion mit Udo möchte ich hier nun in der
>> VZ-Community fortführen.
>> >
>> > Mein Problem ist, dass keine Daten in der vzlogger-api, in meinem Fall
>> die httpd-api, ankommen. Das vzlogger.log registriert keine readings, die
>> vom meter in die queue gestellt werden. Interessanterweise führt der
>> d0-Dump-File (die Datei d0.txt habe ich angehängt) das übermittelte
>> Zählertelegramm auf.
>> >
>> > vzlogger wurde mit "vzlogger -c vzlogger.conf -l" gestartet.
>> >
>> > Mein Zähler übermittelt die Daten wie folgt (Auszug):
>> > .
>> > 1.8.0*52(019189.68*kWh)
>> > 1.8.0*51(018778.01*kWh)
>> > 1.8.1(024514.26*kWh)
>> > 1.8.1*65(024336.08*kWh)
>> > 1.8.1*64(023939.30*kWh)
>> > .
>> >
>> > Mich interessiert der Zählerstand Tarif 1 (1.8.1). Mir ist afgefallen,
>> dass mein Zählerdaten nicht der aktuellen OBIS-Definition entsprechen. Es
>> müsste 1-0:1.8.1 oder 1-1:1.8.1 heissen.
>> >
>> > Kann mir jemand sagen ob vzlogger "identifier": "1.8.1" verarbeiten
>> kann, wenn das Zählertelegramm die Daten so liefert?
>> >
>> > Oder liegt die Ursache noch woanders?
>> >
>> > Hier meine vzlogger.conf:
>> > {
>> > "retry": 0,
>> > "daemon": true,
>> > "verbosity": 15,
>> > "log": "/var/log/vzlogger.log",
>> > "local": {
>> > "enabled": true,
>> > "port": 8080,
>> > "index": true,
>> > "timeout": 0,
>> > "buffer": 600
>> > },
>> > // Meter configuration
>> > "meters": [
>> >{
>> > // D0 meter (Strom)
>> > "enabled": true, // disabled meters will be
>> ignored (default)
>> > "allowskip": false, // errors when opening
>> meter may be ignored if enabled
>> > "protocol": "d0", // meter protocol, see
>> 'vzlogger -h' for full list
>> > "device": "/dev/ttyUSB0", // meter device
>> > "parity": "7e1", // Serial parity, 7e1 or 8n1
>> > "wait_sync": "off",
>> > "baudrate": 300, // Serial baud rate,
>> typically 9600 or 300
>> > "pullseq": "2F3F343230383138210D0A", // Pull sequence in 'hex'
>> > "read_timeout": 100, // optional, default 10s.
>> Timeout value in secs between single bytes received from de
>> > "dump_file": "/var/log/d0-31.txt",// detailed log file for
>> all received/transmitted data (optional)
>> > "baudrate_change_delay": 400, // optional, default none.
>> Delay value in ms after ACKSEQ send before baudrate change
>> > "interval": 10, // Wartezeit in Sekunden
>> bis neue Werte in die middleware ..bertragen werden
>> > "channels": [
>> >{
>> > "uuid": "180a",
>> > "identifier": "1.8.1",// OBIS identifier Active Power
>> Counter Tarif 1
>> > "api": "null",// without middleware
>> > "aggmode": "none",// aggregation mode:
>> aggregate meter readings during interval
>> > "duplicates": 0 // duplicate handling,
>> default 0 (send duplicate values)
>> >}
>> > ]
>> > }
>> > ]
>> > }
>> >
>> > Viele Grüße
>> > Winfried
>> >
>> >
>> >
>>
>
>
Re: [vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
Hallo,
ja, kenne ich. Ich habe schon vieles durchdekliniert und geprüft. Komme
jetzt aber nicht mehr weiter.
Ich kann noch meinen vzlogger-Versionsstand 0.5.1 nachreichen.
Viele Grüße
Am 15. Januar 2016 um 21:43 schrieb Andreas Götz :
> Wiki howto/debug kennst Du?
>
> Viele Grüße, Andreas
>
> > Am 15.01.2016 um 18:55 schrieb Winfried Peters <
> winfried.pet...@gmail.com>:
> >
> > Hallo VZ-Gemeinde,
> >
> > ich habe endlich meinen Drehstromzähler, ein EMH-ITZ aus dem Jahr 2010,
> mit der richtigen Pullsequenz zum Sprechen gebracht. Das Programm HTerm als
> auch ein "cat /dev/ttyUSB0" zeigen mir ein komplettes Zählertelegramm. Die
> Übertragung dauert in der Regel ca. 90 Sekunden (mit 300 Baud). Udo's Tipps
> waren da sehr hilfreich. Die Diskussion mit Udo möchte ich hier nun in der
> VZ-Community fortführen.
> >
> > Mein Problem ist, dass keine Daten in der vzlogger-api, in meinem Fall
> die httpd-api, ankommen. Das vzlogger.log registriert keine readings, die
> vom meter in die queue gestellt werden. Interessanterweise führt der
> d0-Dump-File (die Datei d0.txt habe ich angehängt) das übermittelte
> Zählertelegramm auf.
> >
> > vzlogger wurde mit "vzlogger -c vzlogger.conf -l" gestartet.
> >
> > Mein Zähler übermittelt die Daten wie folgt (Auszug):
> > .
> > 1.8.0*52(019189.68*kWh)
> > 1.8.0*51(018778.01*kWh)
> > 1.8.1(024514.26*kWh)
> > 1.8.1*65(024336.08*kWh)
> > 1.8.1*64(023939.30*kWh)
> > .
> >
> > Mich interessiert der Zählerstand Tarif 1 (1.8.1). Mir ist afgefallen,
> dass mein Zählerdaten nicht der aktuellen OBIS-Definition entsprechen. Es
> müsste 1-0:1.8.1 oder 1-1:1.8.1 heissen.
> >
> > Kann mir jemand sagen ob vzlogger "identifier": "1.8.1" verarbeiten
> kann, wenn das Zählertelegramm die Daten so liefert?
> >
> > Oder liegt die Ursache noch woanders?
> >
> > Hier meine vzlogger.conf:
> > {
> > "retry": 0,
> > "daemon": true,
> > "verbosity": 15,
> > "log": "/var/log/vzlogger.log",
> > "local": {
> > "enabled": true,
> > "port": 8080,
> > "index": true,
> > "timeout": 0,
> > "buffer": 600
> > },
> > // Meter configuration
> > "meters": [
> >{
> > // D0 meter (Strom)
> > "enabled": true, // disabled meters will be
> ignored (default)
> > "allowskip": false, // errors when opening meter
> may be ignored if enabled
> > "protocol": "d0", // meter protocol, see
> 'vzlogger -h' for full list
> > "device": "/dev/ttyUSB0", // meter device
> > "parity": "7e1", // Serial parity, 7e1 or 8n1
> > "wait_sync": "off",
> > "baudrate": 300, // Serial baud rate,
> typically 9600 or 300
> > "pullseq": "2F3F343230383138210D0A", // Pull sequence in 'hex'
> > "read_timeout": 100, // optional, default 10s.
> Timeout value in secs between single bytes received from de
> > "dump_file": "/var/log/d0-31.txt",// detailed log file for all
> received/transmitted data (optional)
> > "baudrate_change_delay": 400, // optional, default none.
> Delay value in ms after ACKSEQ send before baudrate change
> > "interval": 10, // Wartezeit in Sekunden bis
> neue Werte in die middleware ..bertragen werden
> > "channels": [
> >{
> > "uuid": "180a",
> > "identifier": "1.8.1",// OBIS identifier Active Power
> Counter Tarif 1
> > "api": "null",// without middleware
> > "aggmode": "none",// aggregation mode:
> aggregate meter readings during interval
> > "duplicates": 0 // duplicate handling,
> default 0 (send duplicate values)
> >}
> > ]
> > }
> > ]
> > }
> >
> > Viele Grüße
> > Winfried
> >
> >
> >
>
[vz-users] Daten aus d0-Zählertelegramm werden nicht an die vzlogger-APIs übertragen
Hallo VZ-Gemeinde,
ich habe endlich meinen Drehstromzähler, ein EMH-ITZ aus dem Jahr 2010, mit
der richtigen Pullsequenz zum Sprechen gebracht. Das Programm HTerm als
auch ein "cat /dev/ttyUSB0" zeigen mir ein komplettes Zählertelegramm. Die
Übertragung dauert in der Regel ca. 90 Sekunden (mit 300 Baud). Udo's Tipps
waren da sehr hilfreich. Die Diskussion mit Udo möchte ich hier nun in der
VZ-Community fortführen.
Mein Problem ist, dass keine Daten in der vzlogger-api, in meinem Fall die
httpd-api, ankommen. Das vzlogger.log registriert keine readings, die vom
meter in die queue gestellt werden. Interessanterweise führt der
d0-Dump-File (die Datei d0.txt habe ich angehängt) das übermittelte
Zählertelegramm auf.
vzlogger wurde mit "vzlogger -c vzlogger.conf -l" gestartet.
Mein Zähler übermittelt die Daten wie folgt (Auszug):
.
1.8.0*52(019189.68*kWh)
1.8.0*51(018778.01*kWh)
1.8.1(024514.26*kWh)
1.8.1*65(024336.08*kWh)
1.8.1*64(023939.30*kWh)
.
Mich interessiert der Zählerstand Tarif 1 (1.8.1). Mir ist afgefallen, dass
mein Zählerdaten nicht der aktuellen OBIS-Definition entsprechen. Es müsste
1-0:1.8.1 oder 1-1:1.8.1 heissen.
Kann mir jemand sagen ob vzlogger "identifier": "1.8.1" verarbeiten kann,
wenn das Zählertelegramm die Daten so liefert?
Oder liegt die Ursache noch woanders?
Hier meine vzlogger.conf:
{
"retry": 0,
"daemon": true,
"verbosity": 15,
"log": "/var/log/vzlogger.log",
"local": {
"enabled": true,
"port": 8080,
"index": true,
"timeout": 0,
"buffer": 600
},
// Meter configuration
"meters": [
{
// D0 meter (Strom)
"enabled": true, // disabled meters will be
ignored (default)
"allowskip": false, // errors when opening meter
may be ignored if enabled
"protocol": "d0", // meter protocol, see
'vzlogger -h' for full list
"device": "/dev/ttyUSB0", // meter device
"parity": "7e1", // Serial parity, 7e1 or 8n1
"wait_sync": "off",
"baudrate": 300, // Serial baud rate, typically
9600 or 300
"pullseq": "2F3F343230383138210D0A", // Pull sequence in 'hex'
"read_timeout": 100, // optional, default 10s.
Timeout value in secs between single bytes received from de
"dump_file": "/var/log/d0-31.txt",// detailed log file for all
received/transmitted data (optional)
"baudrate_change_delay": 400, // optional, default none.
Delay value in ms after ACKSEQ send before baudrate change
"interval": 10, // Wartezeit in Sekunden bis
neue Werte in die middleware ..bertragen werden
"channels": [
{
"uuid": "180a",
"identifier": "1.8.1",// OBIS identifier Active Power
Counter Tarif 1
"api": "null",// without middleware
"aggmode": "none",// aggregation mode: aggregate
meter readings during interval
"duplicates": 0 // duplicate handling, default
0 (send duplicate values)
}
]
}
]
}
Viele Grüße
Winfried
# 30.248389870s ( 0 ms) opened
# 30.313143535s (65 ms) read
# 30.313202210s ( 0 ms) TCIOFLUSH and cfsetiospeed
< 30.313338180s ( 0 ms)
2f 3f 34 32 30 38 31 38 21 0d 0a /?420818!
> 30.320580660s ( 7 ms)
20 35 22 20 30 08 0c 0c 01 00 02 2a 52 5b 57 685" 0 *R[Wh
29 0a 0a 31 2e 38 2e 31 2a 35 31 28 30 31 38 37 ) 1.8.1*51(0187
37 31 2e 39 39 2a 6b 57 68 29 0a 0a 31 2e 38 2e 71.99*kWh) 1.8.
32 28 30 30 30 30 30 32 2(02
# 32.188827065s ( 1868 ms) timeout!
# 92.195325175s ( 60007 ms) read
# 92.195391080s ( 0 ms) TCIOFLUSH and cfsetiospeed
< 92.195524010s ( 0 ms)
2f 3f 34 32 30 38 31 38 21 0d 0a /?420818!
> 92.228295520s (33 ms)
2f 3f 34 32 30 38 31 38 21/?420818!
# 52.498633220s ( 60270 ms) read
# 52.498695945s ( 0 ms) TCIOFLUSH and cfsetiospeed
< 52.498815515s ( 0 ms)
2f 3f 34 32 30 38 31 38 21 0d 0a /?420818!
> 52.512279615s (14 ms)
0a 21 !
# 12.547625860s ( 60035 ms) read
# 12.547693620s ( 0 ms) TCIOFLUSH and cfsetiospeed
< 12.547828075s ( 0 ms)
2f 3f 34 32 30 38 31 38 21 0d 0a /?420818!
> 12.579293565s (32 ms)
2f 3f 34 32 30 38 31 38 21/?420818!
# 72.848670921s ( 60269 ms) read
# 72.848734514s ( 0 ms) TCIOFLUSH and cfsetiospeed
< 72.848863815s ( 0 ms)
2f 3f 34 32 30 38 31 38 21 0d 0a /?420818!
> 73.319947073s ( 471 ms)
4c 28 73 42 73 12 53 2b 12 43 02 02 02 02 02 12 L(sBs S+ C
73 02 02 52 5b 57 68 29 0a 0a 31 2e 38
Re: [vz-users] S0-Werte aggregieren nur mit "aggfixedinterval": true
Hallo,
> aggtime wird ignoriert wenn aggfixedinterval nicht gesetzt ist
Was bedeutet "nicht gesetzt"? aggfixedinerval = false oder nicht definiert?
Was ist der Defaultwert, wenn nicht definiert?
Viele Grüße
Am 11. Januar 2016 um 10:48 schrieb Andreas Goetz :
> Hallo Zusammen,
>
> nachdem die Diskussion sich ein wenig off topic um aggfixed Interval
> drehte hier als Reminder nochmal das Kernproblem: aggtime wird ignoriert
> wenn aggfixedinterval nicht gesetzt ist (
> https://github.com/volkszaehler/vzlogger/issues/231).
>
> @Jens: jetzt bräuchten wir Deine Hilfe- siehe Fragen von Matthias.
>
> Viele Grüße,
> Andreas
>
>
> 2016-01-08 21:06 GMT+01:00 Matthias Behr :
>
>> Bitte mal verbose auf 15 umstellen und den Log schicken.
>>
>> Bemerkung: die einzelnen Meter sind untereinander nicht synchronisiert.
>> D.h. die aggtime kann sich zwischen den schon ändern. Nur Channels eines
>> Meter werden synchonisiert.
>>
>> Aber wenn ich dich richtige verstehe, bekommst du vereinzelt immer Meter,
>> die aggtime ignorieren. Das wäre auch ein klarer Fehler.
>>
>> Und ja, bitte Fehler/Log zu dem Fall, wo send_zero nach 4 Min abbricht,
>> bzw. Loggen aufhört. Und warum gibt es keine Besserung? Die Sprünge müssen
>> dann nur noch normale (bei wenigen Impulsen) Digitialisierungseffekte sein,
>> die aber unvermeidbar sind, oder?
>>
>> Am 08.01.2016 um 08:44 schrieb Jens :
>>
>> Hallo Andreas,
>>
>> ich hab den "send_zero" versuchsweise auf true gesetzt. Leider bringt das
>> keine Besserung, der vzlogger verabschiedet sich dann auch irgendwann bei
>> mir. Habt dann wieder rausgenommen.
>>
>> Was mir aber noch aufgefallen ist (ich weiß, das ist jetzt wieder sowas
>> nichtkonkretes, womit man schwer etwas anfangen kann, aber es ist dennoch
>> vorhanden). Meine S0-Zähler sind alle GLEICH konfiguriert. Jedoch zählt
>> behandelt vzlogger die erstaunlicherweise unterschiedlich - und das auch
>> nach dem Start des Raspi’s nicht vorhersehbar, welcher Zähler nun richtig
>> und falsch loggt. Hier ein Beispiel: S00_Gesamt logt korrekt alle 30
>> Sekunden, der S01_Haus loggt nach eintreffenden Impulsen unabhängig von der
>> eingestellten Aggregationszeit. Die original Configdatei liegt anbei (hab
>> nur die UUID’s rausgenommen). Die Temperaturen über 1wire werden mit dem
>> vzlogger wunderbar gemäß dem Zeitplan verarbeitet.
>>
>> Viele Grüße Jens
>>
>>
>>
>>
>> Dann mal den vzlogger gestoppt und neu gestartet und das Bild sieht so
>> aus. Jetzt loggen auf einmal alle richtig im 30 Sekunden-Intervall.
>>
>>
>>
>>
>> Am 07.01.2016 um 20:36 schrieb Matthias Behr :
>>
>> Hallo,
>>
>> kannst du mal folgende Kombination testen:
>> aggfixedinterval = false // das sollte man eher nicht verwenden,
>> beschreibe später noch mal, warum nicht.
>> dafür:
>> send_zero:true // mit aggmode willst du ja alle z.B. 30s einen
>> Datenpunkt, auch wenn der Null ist, oder?
>>
>> Damit sollten die Effekte, die du beobachtest weg sein.
>>
>>
>> Am 06.01.2016 um 20:29 schrieb Jens :
>>
>> Hallo Zusammen,
>>
>> ich logge einige S0 Zähler und seit zwei Wochen mit dem vzlogger. Ich
>> möchte, dass nur alle 30 Sekunden ein Eintrag in die Datenbank geschrieben
>> wird. Dafür nutze ich den Parameter „aggtime" auf 30. Das klappt auch,
>> allerdings muss man den Parameter "aggfixedinterval" auf true setzen.
>> Andernfalls werden die Daten gemäß dem Original-Impuls in die Datenbank
>> geschrieben und aggtime wird ignoriert. Leider werden bei aktiviertem
>> „aggfixedinterval“ die Werte nicht interpoliert, was zu kleinen
>> Sägezahnmustern im Frontend führen kann - gerade bei kleinen Lasten.
>>
>> Hier ein Screenshot mit und ohne aggfixedinterval
>>
>>
>>
>> Meine Knotig, nur bis zum ersten S0-Zähler, die anderen sind gleich bis
>> auf die UUID
>> {
>> "retry": 0,
>> "daemon": true,
>> "verbosity": 0,
>> "log": "/var/log/vzlogger.log",
>> "local": {
>> "enabled": false,
>> "port": 8080,
>> "index": true,
>> "timeout": 0,
>> "buffer": 0
>> },
>> "push": [
>> {
>> "url": "http://127.0.0.1:5582";
>> }
>> ],
>> "meters": [
>> // Sensor 1
>> {
>> "enabled": true,
>> "allowskip": false,
>> "interval": -1,
>> "aggtime": 30,
>> "aggfixedinterval": true,
>> "channels": [
>> {
>> "uuid": „das-ist-meine-Kanal-UUID",
>> "identifier": "Impulse",
>> "api": "volkszaehler",
>> "middleware": "http://127.0.0.1/middleware.php";,
>> "aggmode": "SUM",
>> "duplicates": 0
>> }
>> ],
>> "protocol": "s0",
>> "gpio": 4,
>> "resolution": 1000,
>> "configureGPIO": true,
>> "debounce_delay": 0
>> },
>> // Sensor 2
>> … weitere Sensoren
>>
>>
>> Gruß
>>
>> Matthias
>>
>>
>>
>> Gruß
>>
>> Matthias
>>
>>
>
Re: [vz-users] vzlogger liefert zu viele Werte für einen Reed-Kontakt-Impuls
Hallo Udo, ok, dann hoffe ich auf ein baldiges Firmeware-Update :-) Viele Grüße Am 2. Januar 2016 um 23:03 schrieb Udo1 : > Hallo Winfried, > > Am 02.01.2016 um 22:37 schrieb Winfried Peters: > >> Kann auf dem YPORT+ ein manueller vzlogger-Update durchgeführt werden, >> wie es in der vzlogger-Installationsanleitung < >> http://wiki.volkszaehler.org/software/controller/vzlogger/installation_cpp-version> >> beschrieben ist >> > Nein, geht nicht. > > Muss erst mit der OpenWrt-Umgebung neu gebaut werden. > > Gruß > Udo >
Re: [vz-users] vzlogger liefert zu viele Werte für einen Reed-Kontakt-Impuls
Hallo Udo, das oben beschriebene Verhalten wurde inzwischen als Bug #222 <https://github.com/volkszaehler/vzlogger/issues/222> identifiziert und in der Version 0.4.9 gefixed. Ich möchte gerne die korrigierte vzlogger-Version auf meinem YPORT+ haben. Kann auf dem YPORT+ ein manueller vzlogger-Update durchgeführt werden, wie es in der vzlogger-Installationsanleitung <http://wiki.volkszaehler.org/software/controller/vzlogger/installation_cpp-version> beschrieben ist oder bin ich auf ein YPORT+ Firmwareupdate angewiesen? Viele Grüße Winfried Am 31. Dezember 2015 um 09:13 schrieb Udo1 : > Hallo Winfried, > > Am 30.12.2015 um 23:52 schrieb Winfried Peters: > >> sieht meine Ideallösung so aus, dass jeweils beim Schliessen und beim >> Öffnen ein Impuls registriert wird. >> > Dürfte nicht funktionieren, da die S0-Eingänge der Erweiterung nur auf das > Schließen des Kontaktes reagieren (mit eingebauter Hardware-Entprellung von > 20ms). Ein zusätzliches 'debounce_delay ' kann das Entprellen natürlich > noch unterstützen. > > "secretKey": "", >> "type": "device", >> "scaler": 0, >>"gpio_dir": -1, >>"nonblocking_delay": 10 >>"device": "", >> > Kannst du auch aus der vzlogger.conf löschen, da keine Funktion in deiner > Config. > > "verbosity": 15, >> > Solltest du auf '5' oder '0' setzen, wenn alles funktioniert. Sonst wird > die Datei zu groß. Gegebenenfalls zwischendurch mal die Datei löschen. > > Was steht jetzt in der vzlogger.log? > > Gruß > Udo > >
Re: [vz-users] vzlogger liefert zu viele Werte für einen Reed-Kontakt-Impuls
Hallo Andreas,
ja, alle Werte lassen sich als reading auch im Log nachweisen. Ich hatte
das Log der Testreihe meiner vorherigen Mail angefügt.
Viele Grüße
Am 31. Dezember 2015 um 16:50 schrieb Andreas Götz :
> Hi,
>
> Am 31.12.2015 um 12:44 schrieb Winfried Peters >:
>
> Hallo Udo,
>
> danke für die Info. Gut zu wissen, dass die YPORT+-Erweiterung eine
> HW-Entprellung hat und nur das Schliessen-Ereignis zählt. Das macht die
> Logik zur Auswertung einfacher, wenn denn vzlogger das tut, was ich nach
> meinem Verständnis erwarte.
>
> Ich kann die Beobachtung von Marius bestätigen, dass beim
> vzlogger-neustart grundsätzlich immer ein Datensatz geschrieben wird.
> Hier der HTTPd-Output:
> { "version": "0.4.8", "generator": "vzlogger", "data": [ { "uuid": "120",
> "last": 1451557637945, "interval": -1, "protocol": "s0", "tuples": [ [
> 1451557637945, 1 ] ] } ] }
>
> Lässt sich das auch im vzlogger log nachvollziehen? Local httpd ist
> nochmal ne ganz andere Geschichte.
>
> Viele Grüße, Andreas
>
>
> Ich habe meine vzlogger-Konfiguration um die überflüssige Parameter
> bereinigt und ein kleine Testreihe mit unterschiedlichen
> debounce_delay-Werten gefahren. Ausgangsfall ist der direkte Anschluss des
> Relais am S0-Port und ein kurzer Auslöser (Schliessen und Öffnen kleier
> 0.5s). Das Ergebnis habe ich dieser Tabelle zusammengefasst:
>
> |+++---+---+|
> |Nr. | debounce_delay | Anzahl | zeitl.| Tupel | Zähler |
> ||| Tupel |Abstand| Werte ||
> |+++---+---+|
> | 1 |0 |2 | 1s | 2|2 | 4|
> | 2 | 1000 |2 | 1s | 1|1 | 2|
> | 3 | 2000 |2 | 2s | 1|1 | 2|
> | 2 | 4000 |2 | 4s | 1|1 | 2|
> | 2 | 6000 |2 | 6s | 1|1 | 2|
> | 2 | 8000 |2 | 8s | 1|1 | 2|
> | 2 |1 |2 | 10s | 1|1 | 2|
> |+++---+---+|
>
> Hier die HTTPd-Outputs dazu:
> 0: { "version": "0.4.8", "generator": "vzlogger", "data": [ { "uuid":
> "120", "last": 1451557772126, "interval": -1, "protocol": "s0", "tuples": [
> [ 1451557771445, 2 ], [ 1451557772126, 2 ] ] } ] }
> 1000 : { "version": "0.4.8", "generator": "vzlogger", "data": [ { "uuid":
> "120", "last": 1451557939197, "interval": -1, "protocol": "s0", "tuples": [
> [ 1451557938196, 1 ], [ 1451557939197, 1 ] ] } ] }
> 2000: { "version": "0.4.8", "generator": "vzlogger", "data": [ { "uuid":
> "120", "last": 1451558092102, "interval": -1, "protocol": "s0", "tuples": [
> [ 1451558090101, 1 ], [ 1451558092102, 1 ] ] } ] }
> 4000: { "version": "0.4.8", "generator": "vzlogger", "data": [ { "uuid":
> "120", "last": 1451558235665, "interval": -1, "protocol": "s0", "tuples": [
> [ 1451558231665, 1 ], [ 1451558235665, 1 ] ] } ] }
> 6000: { "version": "0.4.8", "generator": "vzlogger", "data": [ { "uuid":
> "120", "last": 1451558387882, "interval": -1, "protocol": "s0", "tuples": [
> [ 1451558381882, 1 ], [ 1451558387882, 1 ] ] } ] }
> 8000: { "version": "0.4.8", "generator": "vzlogger", "data": [ { "uuid":
> "120", "last": 1451558519265, "interval": -1, "protocol": "s0", "tuples": [
> [ 1451558511265, 1 ], [ 1451558519265, 1 ] ] } ] }
> 1: { "version": "0.4.8", "generator": "vzlogger", "data": [ { "uuid":
> "120", "last": 1451558704481, "interval": -1, "protocol": "s0", "tuples": [
> [ 1451558694481, 1 ], [ 1451558704481,
>
> Bei keiner Einstellung bekomme ich als Ergebnis bei einem Impuls nur einen
> Zähler.Auch nicht bei debounce_delay = 0. vzlogger schiebt grundsätzlich
> einen zweiten Datensatz im zeitlichen Abstand von debounce_delay hinterher.
> Ich hatte den vzlogger-Parameter &quo
Re: [vz-users] vzlogger liefert zu viele Werte für einen Reed-Kontakt-Impuls
. Ich hänge die
vzlogger.log als Datei an.
{
"retry": 0,
"daemon": true,
"verbosity": 10,
"log": "/var/log/vzlogger.log",
"local": {
"enabled": true,
"port": 8080,
"index": true,
"timeout": 0,
"buffer": 60
},
"meters": [
{
"enabled": true,
"allowskip": false,
"interval": -1,
"aggtime": -1,
"aggfixedinterval": false,
"channels": [
{
"uuid": "120",
"identifier": "Impulse",
"api": "null",
"aggmode": "none"
// "duplicates": 0
}
],
"protocol": "s0",
"gpio": 20,
"configureGPIO": true,
"resolution": 1,
"send_zero": false,
"debounce_delay": 1
}
]
}
So, das war's für dieses Jahr. Ich hoffe, ich bekomme meine Zähler im
nächsten Jahr zum Laufen.
Viele Grüße und einen Guten Rutsch ins Neue Jahr
Winfried
Am 31. Dezember 2015 um 09:13 schrieb Udo1 :
> Hallo Winfried,
>
> Am 30.12.2015 um 23:52 schrieb Winfried Peters:
>
>> sieht meine Ideallösung so aus, dass jeweils beim Schliessen und beim
>> Öffnen ein Impuls registriert wird.
>>
> Dürfte nicht funktionieren, da die S0-Eingänge der Erweiterung nur auf das
> Schließen des Kontaktes reagieren (mit eingebauter Hardware-Entprellung von
> 20ms). Ein zusätzliches 'debounce_delay ' kann das Entprellen natürlich
> noch unterstützen.
>
> "secretKey": "",
>> "type": "device",
>> "scaler": 0,
>>"gpio_dir": -1,
>>"nonblocking_delay": 10
>>"device": "",
>>
> Kannst du auch aus der vzlogger.conf löschen, da keine Funktion in deiner
> Config.
>
> "verbosity": 15,
>>
> Solltest du auf '5' oder '0' setzen, wenn alles funktioniert. Sonst wird
> die Datei zu groß. Gegebenenfalls zwischendurch mal die Datei löschen.
>
> Was steht jetzt in der vzlogger.log?
>
> Gruß
> Udo
>
>
vzlogger.log
Description: Binary data
[vz-users] vzlogger liefert zu viele Werte für einen Reed-Kontakt-Impuls
Hallo,
ich bin neu hier. Nachdem Udo mir schon ein paar Tipps gegeben hat, möchte
ich mein aktuelles vzlogger-Problem hier schildern.
Ich möchte meinen Gaszähler über den eingebauten Magneten und einen
Reed-Kontakt auslesen. Ich stehe vor der Herausforderung über saubere
Zählimpulse zu einer korrekten Zählung zu kommen. Die Auswertung soll über
die HTTPd-Schnittstelle in Fhem erfolgen (keine Volkzaehler-Middleware und
Frontend). Die optimale Lösung habe ich noch nicht gefunden bzw. bin ich
auf Ungereimtheiten im vzlogger gestossen.
Ich hoffe, jemand hast den ein oder anderen Hinweis für mich.
Hier meine Überlegungen:
- Mein Gaszähler liefert bei einer Umdrehung (entspricht 0,001 m³) einen
Magnetimpuls. Für eine Umdrehung werden vermutlich minimal ca. 20 Sekunden
bei voller Leistung benötigt.
- Der Impuls erfolgt beim Nulldurchgang der 1000er-Nachkommastelle.
- Der Reedkontakt prellt beim Schliessen und prellt beim Öffnen
- Der Reedkontakt bleibt bei kontinuierlicher Abnahme je nach Leistung
ca. 0,6 bis mehrere Sekunden geschlossen
- Bleibt der Gaszähler im Nulldurchgang stehen, kann der Reedkontakt
über Stunden und Tage geschlossen bleiben, solange, bis die Heizung wieder
startet.
Um auch den letzten Fall im obigen Szenario abzudecken, sieht meine
Ideallösung so aus, dass jeweils beim Schliessen und beim Öffnen ein Impuls
registriert wird. Bei der Auswertung teile ich später die Impulse durch 2.
Mit dieser Regel sollte eine maximale Ablesegenauigkeit erreicht werden.
Soweit zur Theorie. Zur Umsetzung:
- Der Reedkontakt ist direkt mit den S0-Eingängen der YPORT+_Erweiterung
von Udo verbunden.
- Die Signalerfassung erfolgt über vzlogger (v0.4.8) mit protocol S0 und
identifier Impulse (komplette Config siehe unten).
- Das Entprellen soll vzlogger mit dem Parameter debounce_delay
erledigen.
- Mit debounce_delay = 500 sollte nach meinem Verständnis das Entprellen
unterdrückt werden.
Das sind meine Testergebnisse mit meinem Testaufbau (aufgeführt sind immer
nur die erzeugten Datentupel des HTTPd-Outputs):
Entprellen mit debounce_delay = 500:
- erster Impuls < 0.5s: [ 1451463068203, 2 ], [ 1451463069203, 1 ]
> 3 Zähler
- zweiter Impuls < 0.5s:[ 1451463068203, 2 ], [ 1451463069203, 1 ]
> 3 Zähler
- dritter Impuls < 0.5s: [ 1451463086203, 1 ], [ 1451463091203, 1
], [ 1451463092203, 1 ]> 3 Zähler
- Impuls mit 3s Halten: [ 1451463345203, 1 ], [ 1451463346203, 1 ], [
1451463351203, 1 ], [ 1451463352203, 1 ] > erzeug 2 + 2 = 4 Zähler (beim
Schließen und Öffnen jeweils 2!)
Hier fällt auf, dass bei einem Impuls immer zwei Datentupel mit exakt 1
Sekunde Abstand geliefert werden. Der erste Tupel liefert den Wert 2, also
2 Impulse. Meine Erwartungshaltung ist pro Impuls ein Datentupel mit dem
Wert 1. Erhöhe ich debounce_delay auf 1000, wird immer der Wert 1,
ausgegeben.
Weitere Tests ergaben, dass bei kurzen Impulsen und bei Werten von
debounce_delay von 0 bis 1000 immer zwei bis drei Datentupel im Abstand von
einer Sekunde erzeugt werden. Bei debounce_delay 2000 oder 4000 erfolgen
die Ausgaben im Abstand von 2 bzw. 4 Sekunden.
Ich habe für dieses Verhalten keine plausible Erklärung.
Hier meine vzlogger.conf:
{
"retry": 0,
"daemon": true,
"verbosity": 15,
"log": "/var/log/vzlogger.log",
"local": {
"enabled": true,
"port": 8080,
"index": true,
"timeout": 0,
"buffer": 120
},
"meters": [
{
"enabled": true,
"allowskip": false,
"interval": -1,
"aggtime": -1,
"aggfixedinterval": false,
"channels": [
{
"uuid": "120",
"identifier": "Impulse",
"api": "null",
"middleware": "",
"secretKey": "",
"type": "device",
"scaler": 0,
"aggmode": "none",
"duplicates": 0
}
],
"protocol": "s0",
"device": "",
"gpio": 20,
"gpio_dir": -1,
"configureGPIO": true,
"resolution": 1,
"send_zero": false,
"debounce_delay": 500,
"nonblocking_delay": 10
}
]
}
