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 <cpui...@gmail.com>:
> 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
> >:
>
>> 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>
>> 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
>> >:
>>
>>> 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 <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>:
>>>>>
>>>>>> 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 <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>:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>
>
