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

[Winfried Peters]

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": 100000
    }
  ]
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20151230/ccaba923/attachment.html>