Hallo Alex


mein Problem hat sich in der Zwischenzeit gelöst…

Noch nicht ganz.

Ich habe es nun mal mit einem “normalen” GPIO mit internen Pull-Down-Widerstand 
versucht, also so wie Du. Allerdings musste ich letzteren softwaremässig 
einschalten, mit „gpio -g mode 21 down“ im rc.local. Das Programm „gpio“ ist 
Teil des nachladbaren Paketes „wiringpi“. Ohne das hat es nicht funktioniert, 
im Sourcecode des vzloggers habe ich auch nicht sehen können, dass 
„configureGPIO“ den internen Pull-Down konfiguriert. Es kann aber sein, dass er 
bei manchen GPIOs standardmässig aktiviert ist.

Ich habe den PullDown nicht extra aktiviert, sondern in der vzlogger.conf mit :


      "protocol": "s0",
      "gpio": 23,
     "gpio_dir": -1,
      "configureGPIO": true,
      "send_zero": false,
      "debounce_delay": 0



eingeschaltet. Den Code habe ich mir nicht angeschaut, davon habe ich keine 
Ahnung, deshalb vermute ich. Das auf den Pi ein Pull Widerstand standardmäßig 
aktiviert ist, widerspricht meinen  Erfahrungen.

Nun habe ich keine Fehlimpulse mehr. Allerdings bin ich mir nicht sicher, ob 
das an der Schaltung liegt, und/oder an einem nun komplett anderen Verhalten 
des vzloggers.

Ich denke das Ergebnis zählt.

Ursprünglich (also in der Schaltung mit dem Pull-Up und einem bis auf die 
Unterbrechungen ja dauerhaft hohen Pegel am GPIO) hatte ich ein debounce_delay 
von 700 eingestellt, obwohl der Cyble ja ein elektronischer Kontakt ist. Wurde 
hier in dieser Liste mal von einem anderen Benutzer des Cyble so als notwendig 
dokumentiert.

Nach deiner Beschreibung hat der Ausgang keine vorgaben für die Polarität. Das 
funktioniert eigentlich nur mit einen mechanischen Kontakt. Die billigste und 
kleinste Lösung ist ein Reedkondakt(Relais), und die Prellen immer (davon habe 
ich Ahnung). "Elektronisch" ist Vermutlich die Erkennung des Verbrauchs und 
Erzeugung des Impulses.  

Die Impulse vom Cyble kamen regelmässig (das war nie das Problem) und der 
vzlogger hat jede „1“ auch an die Datenbank geschickt. Jetzt, mit 3,3V gegen 
GPIO mit Pull-Down ist letzterer ja, solange kein Impuls eintrifft, auf GND. 
Damit fiel schonmal der eine (logisch ja falsche) einmalige „Einschaltimpuls“ 
beim Starten des vzloggers weg. Soweit gut.

Ich denke dieses "falsche" verhalten ist den Programmieren bewusst und sie 
reagieren nur auf Flanken nach den Einschalten.

Allerdings hat der vzlogger nun auch die regelmässig und richtig kommenden 
„1“en des Cyble  zwar im Debug angezeigt, aber nicht mehr an die DB geschickt. 
Ich habe dann mal testweise das debounce_delay auf 0 gesetzt. Nun sah man 
plötzlich nicht nur einen Impuls vom Sensor, sondern jedesmal 2, zeitgleich. 
Das war wohl mal der Grund für das debounce_delay.

Diesen Verhalten solltest du noch Nachgehen. 

Der Vzlogger aber hat daraus Power und Impulse gemacht, also wie bei einem 
E-Zähler, und (entsprechend meiner Config) natürlich nur den Impuls (einen!) 
geloggt und auch per curl auch an die DB gesendet. Entweder haben Entwickler 
des Cyble und Programmierer des vzloggers mehr gemein als man denkt – oder 
vielleicht ist genau dieses Verhalten für das Protokoll als Standard definiert.

Der vzlogger ist ausschließlich für die Erfassung und Übertragung an die 
Middleware zuständig. Die Auswertung-Interpretation erfolg im Frontend. Ob 
Strom, Gas, Wasser oder sonst etwas ist egal. "S0" bedeutet digitale Impulse 
für verbrauchte Menge/Arbeit. Aus Arbeit und Zeit wird die Leistung errechnet. 
Das ist Physik, die haben wir alle gemeinsam.

Auf jeden Fall funktioniert es so.

Wenn der 1. Impulse fehlt funktioniert es noch nicht richtig.

Es scheint dass der Vzlogger eine Impulsmindestlänge für analoge Impulsgeber 
(Reed) und bei digitalen einen zweifachen Impuls vorraussetzt.

Der Pi kann nur digital, und ja: "debounce_delay".

Und vielleicht siebt genau das die eventuell ja noch vorhandenen Störimpulse 
aus, die diese Vorgaben nicht erfüllen…

Eher nicht, ich vermute das "debounce_delay" noch nicht passt.

Ohne Angaben zum Impulse im Datenblatt deines Cyble, oder eine Auswertung mit 
Oszi, hilft nur experimentieren mit der delayzeit. 0 ist definitiv zu wenig, 
dein jetziger Wert scheinbar zu hoch. 



Viel Spaß beim experimentieren.



Thomas

Antwort per Email an