[vz-dev] S0Meter Daten falsch?

[Thomas Gentsch]

Hallo allerseits,
kurzer update, allerdings nicht wirklich erhellend ... was mich insb nervös macht, ist sowas:
$ tail -f /var/log/vzlogger.log | grep -e mtr2 -e gp18
...
[Apr 27 17:43:16.516][gp18] MeterS0:HWIF_GPIO:first poll returned 1 (FD 6, PRI: 2)
[Apr 27 17:43:16.517][gp18] MeterS0:HWIF_GPIO:status: read on FD 6 ok: 1
[Apr 27 17:43:16.522][gp18] MeterS0:HWIF_GPIO:first poll returned 1 (FD 6, PRI: 2)
[Apr 27 17:43:16.523][gp18] MeterS0:HWIF_GPIO:status: read on FD 6 ok: 1
[Apr 27 17:43:16.526][gp18] MeterS0:HWIF_GPIO:first poll returned 1 (FD 6, PRI: 2)
[Apr 27 17:43:16.526][gp18] MeterS0:HWIF_GPIO:status: read on FD 6 ok: 1
[Apr 27 17:43:16.528][gp18] MeterS0:HWIF_GPIO:first poll returned 1 (FD 6, PRI: 2)
[Apr 27 17:43:16.529][gp18] MeterS0:HWIF_GPIO:status: read on FD 6 ok: 0
[Apr 27 17:43:17.459][mtr2] Got 2 new readings from meter:
[Apr 27 17:43:17.460][mtr2] Reading: id=Power/StringIdentifier: value=1086.96 ts=1588002196528
[Apr 27 17:43:17.462][mtr2] Reading: id=Impulse/StringIdentifier: value=3.00 ts=1588002196528
...

Wie kann es sein, dass poll() mehrmals mit 1 getriggert wird (doppeltes read() hin oder her), d.h. es hat gar kein Statuswechsel stattgefunden.
Es sei denn, da war eine extrem kurzer Ausschlag und zu dem Zeitpunkt des pread() war schon wieder 1.

Das kann nicht durch ein "echtes" Verhalten der Wasseruhr kommen, aber ich habe noch eine andere Idee: Zwischen dem Abtast-Optokoppler und der
restlichen Schaltung ist etwa 1m 3er-Draht, weder geschirmt noch verdrillt. Evtl kann man sich da irgendwelche Störsignale einfangen?

Interessant, dass sowas aehnliches beim Gas auch passiert (nur Reed-Kontakt + Pull-Up Widerstand), ab+zu werden Impulse gezaehlt, obwohl 100% sicher
den ganzen Tag kein Gasverbrauch. Die Frage ist nur, wo die Fehler reinkommen - "ueber den Draht" oder in der Verarbeitung im RPi (falsche
Interrupts).

Meinen ursprunglichen Verdacht mit dem doppelten pread() wuerde ich hiermit zurueckziehen :-) Fraglich ob, noetig, aber wohl auch nicht schädlich.

Also:
- ich bau geschirmtes Kabel ein
- weiss jemand eine andere Moeglichkeit, die GPIO-Aktivitaet moeglichst nah an der Hardware zu loggen?
- wie sind sonst die Erfahrungen: Es kommen zwar immer schoene Graphen raus, aber sind die Werte auch exakt?

1000 Dank + viele Gruesse!
  Thomas

On Sun, 2020-04-26 at 22:23 +0200, rgb at nord-com.net wrote:
> Moin!
> 
> > 
> > Duerfe eigentlich egal sein, ob H-L oder L-H - kommen ja immer gleich viele
> > ueber den Tag
> Nach meiner Erfahrung ist das nicht egal. Wenn man "configure_GPIO" benutzt wird die Flanke auf "rising" und "active_low" auf 0 gesetzt. Und es ist
> schon ein Unterschied, ob man beliebig lange Pausen auszuwerten versucht (was fehleranfällig ist) oder wirklich die zeitlich begrenzten (positiven)
> Impulse, siehe meinen Beitrag unter https://www.mail-archive.com/volkszaehler-users@demo.volkszaehler.org/msg10574.html
> 
> > 
> > Kommt drauf an, wie man den GPIO konfiguriert (so mein Verstaendnis),
> > vzlogger kann offenbar Beides: H/L oder L/H
> Im Zweifelsfall müsstest Du "active_low" manuell oder im Sourcecode auf 1 setzen, dann würde es umgekehrt auch funktionieren.
>  
> > 
> > > 
> > > ist das
> > > debouce_delay länger als die Pause wird die steigende Flanke womöglich
> > > komplett weggefiltert.
> > 
> > Kontrolliere ich auch nochmal - habe gar kein debounce-delay, dachte, das waer dann 0. 
> Nein, das entspricht dann einem Wert von 30. Bei meinem Gaszähler-Lesekopf (einem Cyble-Sensor V2, der elektronisch aufbereitete Impulse abgibt)
> funktioniert es nur mit 0, dann allerdings wie ein Uhrwerk.
> 
> Gruss,
> Alex
> 
-- 
 ........................................................
 Thomas Gentsch
 e-mail: tg at e-tge.de
 ........................................................
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20200428/0767616b/attachment.sig>