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 <winfried.pet...@gmail.com> 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 <cpui...@gmail.com > <mailto:cpui...@gmail.com>>: > 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 <winfried.pet...@gmail.com >> <mailto:winfried.pet...@gmail.com>> 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 <cpui...@gmail.com >> <mailto:cpui...@gmail.com>>: >> 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 >>> <mailto: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 <mailto: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 <winfried.pet...@gmail.com >>> <mailto:winfried.pet...@gmail.com>> 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- meter data available via local >>> httpd if enabled. >>> [Nov 02 15:55:39][mtr0] Number of readers: 32 >>> [Nov 02 15:55:39][mtr0] Config.daemon: 1 >>> [Nov 02 15:55:39][mtr0] Config.local: 1 >>> [Nov 02 15:55:39][chn0] Start logging thread for null-api. Running as >>> daemon: yes >>> [Nov 02 15:55:39][chn0] Using null api- meter data available via local >>> httpd if enabled. >>> [Nov 02 15:55:40][mtr0] Got 3 new readings from meter: >>> [Nov 02 15:55:40][mtr0] Reading: >>> id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255 value=87463.90 >>> ts=1572706540671 >>> [Nov 02 15:55:40][mtr0] Reading: >>> id=1-0:2.8.0*255/ObisIdentifier:1-0:2.8.0*255 value=20243.10 >>> ts=1572706540671 >>> [Nov 02 15:55:40][mtr0] Reading: >>> id=1-0:16.7.0*255/ObisIdentifier:1-0:16.7.0*255 value=341.01 >>> ts=1572706540671 >>> [Nov 02 15:55:41][mtr0] Got 3 new readings from meter: >>> [Nov 02 15:55:41][mtr0] Reading: >>> id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255 value=87464.00 >>> ts=1572706541683 >>> [Nov 02 15:55:41][mtr0] Reading: >>> id=1-0:2.8.0*255/ObisIdentifier:1-0:2.8.0*255 value=20243.10 >>> ts=1572706541683 >>> [Nov 02 15:55:41][mtr0] Reading: >>> id=1-0:16.7.0*255/ObisIdentifier:1-0:16.7.0*255 value=343.63 >>> ts=1572706541683 >>> [Nov 02 15:55:42][mtr0] Got 3 new readings from meter: >>> [Nov 02 15:55:42][mtr0] Reading: >>> id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255 value=87464.10 >>> ts=1572706542691 >>> [Nov 02 15:55:42][mtr0] Reading: >>> id=1-0:2.8.0*255/ObisIdentifier:1-0:2.8.0*255 value=20243.10 >>> ts=1572706542691 >>> [Nov 02 15:55:42][mtr0] Reading: >>> id=1-0:16.7.0*255/ObisIdentifier:1-0:16.7.0*255 value=337.48 >>> ts=1572706542691 >>> .... >>> >>> Hier meine vzlogger-sml-conf: >>> // 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", >>> "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 <mailto: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 <mailto: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 <winfried.pet...@gmail.com >>> <mailto:winfried.pet...@gmail.com>> 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 <mailto: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 <mailto: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 <mailto: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 >>>> <mailto: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 <mailto: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 <mailto: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 <mailto:frank.richte...@gmail.com>>: >>>> Hi, >>>> >>>> Am Di., 29. Okt. 2019 um 14:06 Uhr schrieb Daniel Lauckner <v...@jahp.de >>>> <mailto: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 >>>> >>>> <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 >
