[vz-users] vzlogger liefert zu viele Werte für einen Reed-Kontakt-Impuls

Fri Jan 1 15:09:30 CET 2016

erledigt.
#222

Am 1. Januar 2016 um 14:41 schrieb Andreas Götz <cpuidle at gmail.com>:

> Hi,
>
> Seid ihr beide so nett und erstellt bei github/vzlogger ein Issue
> (vzlogger erzeugt 2ten Impuls nach Ablauf von debounce_delay bei Verwendung
> von GPIO)? Beide logs bitte rein. Hier wirds zu unübersichtlich, ich blicke
> jedenfalls zwischen den 100en Mails nicht mehr vollständig durch :O
>
> Viele Grüße und ebenfalls ein Frohes Neues,
> Andreas
>
> Am 01.01.2016 um 12:01 schrieb Marius Tarlowski <marius at tarlowski.de>:
>
> Ebenfalls in meinem Fall, log habe ich auch angehängt gestern.
>
> Frohes neues übrigens :-)
>
> Mfg, Marius
> Am 01.01.2016 11:55 schrieb "Winfried Peters" <winfried.peters at gmail.com>:
>
>> 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 <cpuidle at gmail.com>:
>>
>>> Hi,
>>>
>>> Am 31.12.2015 um 12:44 schrieb Winfried Peters <
>>> winfried.peters at gmail.com>:
>>>
>>> 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 |    10000       |    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 ] ] } ] }
>>> 10000: { "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 "duplicates" im
>>> Verdacht. Der würde das Verhalten ansatzweise erklären. In der editor-Doku
>>> steht: default 0 (send duplicate values), >0 = send duplicate values only
>>> each <duplicates> seconds. Activate only for abs. counter values
>>> (Zaehlerstaende) and not for impulses! Wenn ich das richtig interpretiere,
>>> werden bei duplicates = 0 "doppelte" Werte gesendet, sollte aber für den
>>> Impuls-Modus nicht relevant sein. Aber ob der Parameter definiert ist oder
>>> nicht, hat keinen Einfluss auf die Ergebnisse.
>>>
>>> Wenn ich einen HW- und Konfigurationsfehler ausschließe, muss es sich um
>>> einen Bug oder ein Verständnisproblem handeln.
>>>
>>> Hier meine aktuelle vzlogger.conf, mit der die Testversuche mit
>>> unterschiedlichen debounce_delay-Werten gefahren wurden. 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": 10000
>>>     }
>>>   ]
>>> }
>>>
>>> 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 <udo1 at gmx.net>:
>>>
>>>> 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": 100000
>>>>>            "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>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20160101/83fb141e/attachment.html>