[vz-users] vzlogger-Problem mit sml-Protokoll und HTTP-Server

[Winfried Peters]

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.richter83 at 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.peters at 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 <
>> spam at 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.peters at 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.richter83 at 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.peters at 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.richter83 at gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Di., 29. Okt. 2019 um 14:06 Uhr schrieb Daniel Lauckner <
>>>>>> vz at 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
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20191030/c7b5a461/attachment.html>