[vz-users] Cyble Sensor an Raspberry - vzlogger - Problem gelöst
rgb at nord-com.net
rgb at nord-com.net
Sat Dec 7 10:38:11 CET 2019
Hallo Thomas,
Ich glaube wir haben da ein bisschen aneinander vorbeigeredet…
Mit der „alten“ Schaltung, also GPIO3 mit Pull-Up, Cyble gegen Ground:
- gab es beim Starten des vzloggers immer einen (Fehl-)Impuls (da der Level des GPIO ja bereits high war?)
- Hatte ich ein debounce_delay von 700 und je einen Impuls vom Cyble
- dieser Impuls und auch alle Störimpulse wurden vom vzlogger weiter an die DB geschickt
Mit der jetzigen Schaltung mit GPIO21 mit Pull-Down, Cyble gegen 3,3V:
- gibt es diesen ersten Impuls beim Starten des vzloggers nicht mehr (was ja richtig ist)
- hat es mit einem debounce_delay nicht funktioniert, die korrekt kommenden einzelne Impulse wurden im Debug angezeigt, aber nicht an die DB übermittelt (zu kurz?)
- mit debounce_delay=0 kommen zwei Impulse, davon wird nur einer geloggt
- Störimpulse treten nicht mehr auf oder werden nicht geloggt.
[Dec 07 09:48:16][S0] MeterS0:HWIF_GPIO:first poll returned 0
[Dec 07 09:48:16][S0] MeterS0:HWIF_GPIO:first poll returned 1
[Dec 07 09:48:16][S0] MeterS0:HWIF_GPIO:first poll returned 1
[Dec 07 09:48:16][s0] Reading S0 - returning 2 readings (n=1 n_neg = 0)
[Dec 07 09:48:16][mtr0] Got 2 new readings from meter:
[Dec 07 09:48:16][mtr0] Reading: id=Power/StringIdentifier: value=118.54 ts=1575708496489
[Dec 07 09:48:16][mtr0] Reading: id=Impulse/StringIdentifier: value=1.00 ts=1575708496489
[Dec 07 09:48:16][chn0] Adding reading to queue (value=1.00 ts=1575708496489)
[Dec 07 09:48:16][chn0] ==> number of tuples: 1
Wie Du siehst macht es der Vzlogger aus irgendeinem Grund richtig, trotz der 2 geloggten Impulse wird nur einer in die DB geschrieben, d.h. es kommt exakt das richtige an. Drehe ich das debounce_delay soweit auf dass nur ein Impuls „durchkommt“, erfolgt kein Schreibvorgang.
Mein Vzlogger.conf sieht aus wie folgt:
"protocol": "s0",
"enabled": true,
"skip": false,
"allowskip": false,
"interval": -1,
"aggtime": -1,
"aggfixedinterval": false,
"gpio": 21,
"gpio_dir": -1,
"configureGPIO": true,
"send_zero": false,
"debounce_delay": 0,
"channel": {
"identifier": "Impulse”
[ … ]
Nach meinem Verständnis macht configureGPIO folgendes:
- den GPIO exportieren
- ihn auf Eingang setzen
- das Edge auf Rising
- active_low auf 0
if (_configureGPIO) {
fd = ::open("/sys/class/gpio/export",O_WRONLY);
if (fd<0) throw vz::VZException("open export failed");
name.clear();
name.append(std::to_string(_gpiopin));
name.append("\n");
res=write(fd,name.c_str(), name.length()+1); // is the trailing zero really needed?
if ((name.length()+1)!=res) throw vz::VZException("export failed");
::close(fd);
} else return false; // doesn't exist and we shall not configure
if (_configureGPIO) {
name.clear();
name.append("/sys/class/gpio/gpio");
name.append(std::to_string(_gpiopin));
name.append("/direction");
fd = ::open(name.c_str(), O_WRONLY);
if (fd<0) throw vz::VZException("open direction failed");
res=::write(fd,"in\n",3);
if (3!=res) throw vz::VZException("set direction failed");
if (::close(fd)<0) throw vz::VZException("set direction failed");
name.clear();
name.append("/sys/class/gpio/gpio");
name.append(std::to_string(_gpiopin));
name.append("/edge");
fd = ::open(name.c_str(), O_WRONLY);
if (fd<0) throw vz::VZException("open edge failed");
res=::write(fd,"rising\n",7);
if (7!=res) throw vz::VZException("set edge failed");
if (::close(fd)<0) throw vz::VZException("set edge failed");
name.clear();
name.append("/sys/class/gpio/gpio");
name.append(std::to_string(_gpiopin));
name.append("/active_low");
fd = ::open(name.c_str(), O_WRONLY);
if (fd<0) throw vz::VZException("open active_low failed");
res=::write(fd,"0\n",2);
if (2!=res) throw vz::VZException("set active_low failed");
if (::close(fd)<0) throw vz::VZException("set active_low failed");
}
Es mag sein dass der Pull-Down anderswo gesetzt wird, ich überblicke ja nicht den ganzen Code. Mit „gpio –g mode 21 down“ im rc.local funktioniert es auf jeden Fall für mich.
Ich schicke Dir gerne das Datenblatt des Cyble, dazu bräuchte ich allerdings Deine Email-Adresse, die Datei ist zu gross für die Liste.
Gruss,
Alex
From: volkszaehler-users [mailto:volkszaehler-users-bounces at demo.volkszaehler.org] On Behalf Of Thomas Höpfner
Sent: Saturday, December 07, 2019 6:49 AM
To: volkszaehler.org - users; 'volkszaehler.org - users'
Subject: Re: [vz-users] Cyble Sensor an Raspberry - vzlogger - Problem gelöst
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20191207/6bc08532/attachment-0001.html>
More information about the volkszaehler-users
mailing list