[vz-users] s0vz - keine Wertänderung und Endlosschleife im s0vz Dienst

[Alexander]

Guten Tag,

ich habe den Pi2 mit der kleinen Erweiterung. Daran angeschlossen diesen
Reed-Sensor (
http://www.reichelt.de/Reedrelais-Magnete/MK-471B/3/index.html?ACTION=3&GROUPID=3291&ARTICLE=27681&SEARCH=MK%20471B&OFFSET=500&WKID=0&
).

Problem: Das C-Programm erkennt keine (bzw. nur fehlerhaft) Änderung am
Device /sys/class/gpio/gpio17/value

Ich habe schon einige Diskussionen zu diesem Thema gelesen, aber keine kam
zu einem wirklichen Ergebnis. Aus meiner Sicht habe ich nun recht viel
versucht zu analysieren und stelle in diesem Beitrag möglichst viele
Informationen zur Verfügung.

Den s0vz Dienst habe ich wie hier beschrieben eingerichtet. (
https://github.com/w3llschmidt/s0vz) Erst später habe ich gelesen, dass die
Angaben in der rc.local angepasst werden müssen, da sich die GPIO Belegung
geändert hat. Bei der kleinen Erweiterung dürfte dies jedoch keinen
Einfluss haben, da s0/0 auf GPIO17 und s0/1 an GPIO18 geht. Die weiteren
GPIO's interessieren bei der kleinen Erweiterung nicht.

Nur um sicher zu gehen, dass ich nichts falsch konfiguriert habe, hier alle
involvierten Dateien:

/etc/s0vz.cfg: http://pastebin.com/hPjz4YwG
(Die Beispieldatei hat ein Semikolon am Ende der GPIO0 Zeile. Vermutlich
ein Fehler)
(Ob als vzserver 127.0.0.1, localhost, <hostname> oder eigene IP scheint
egal zu sein. Beim Start des Diestes wird ein Wert in die DB geschrieben.
Dies bestätigt, dass grundsätzlich die Verbindung zur Middleware
funktioniert.)

s0vz.c: http://pastebin.com/zGQ07b7t (Mit Debug Ausgaben)

s0vz (init Skript): http://pastebin.com/tkD9C8gn (Läuft testhalber unter
dem Benutzer root)

/etc/rc.local: http://pastebin.com/zGxd5aeG

/etc/init.d/rc.local: http://pastebin.com/MLM8Vz0u

Beim Start des s0vz Dienstes wird folgendes in die log-Datei
/var/log/syslog geschrieben: http://pastebin.com/nGVK4GbS
Ob dies ein Bug oder Feature ist, dass beim Start für jede UUID ein Wert in
die DB geschrieben wird weiß ich nicht, aber es ist ein guter Test, ob die
Verbindung zur Middleware funktioniert.

Ich vermute das Problem nun beim Auslesen des aktuellen Status der s0
Schnittstelle. Beim Systemstart wird die rc.local aufgerufen und dadurch
werden Schnittstellen zu den s0 Eingängen erstellt.

Unter dem Pfad /sys/class/gpio/ finden sich zunächst nur die Dateien export
und unexport. Durch den Ausführung von "echo 17 > /sys/class/gpio/export"
wird eine Schnittstelle zum GPIO17 geschaltet, also der s0/0 Schnittstelle
auf der kleinen Erweiterung. Es gibt nun den Pfad /sys/class/gpio/gpio17.

/sys/class/gpio# ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 export
lrwxrwxrwx 1 root gpio    0 Mai  6 20:59 gpio17 ->
../../devices/soc/3f200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root gpio    0 Mai  6 20:59 gpio18 ->
../../devices/soc/3f200000.gpio/gpio/gpio18
lrwxrwxrwx 1 root gpio    0 Jan  1  1970 gpiochip0 ->
../../devices/soc/3f200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jan  1  1970 unexport

/sys/class/gpio/gpio17# ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 active_low
lrwxrwxrwx 1 root gpio    0 Mai  6 20:59 device -> ../../../3f200000.gpio
-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 direction
-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 edge
drwxrwx--- 2 root gpio    0 Mai  6 20:59 power
lrwxrwxrwx 1 root gpio    0 Mai  6 20:59 subsystem ->
../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 uevent
-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 value


cat active_low: 0
cat direction: in
cat edge: rising
cat value: 1

Es verwundert mich nun, warum value immer auf 1 steht.
Zunächst wollte ich herausfinden, wann und ob sich der Wert value ändert.
Ich habe also gpio17/value und gpio18/value mit einem tail -f und watch -n1
cat value beobachtet und an dem s0/0 einen Magnet an den Reed-Sensor
gehalten und außerdem die beiden s0/1 Anschlüsse kurzgeschlossen. Die value
Information bleibt immer auf 1.
Nun habe ich mit einem echo 1 > active_low den Status invertiert. Nun steht
value auf 0 und bleibt auch egal was ich mache auf 0.

Das C-Programm s0vz.c scheint jedoch eine Änderung am Device zu erkennen.
Starte ich den Dienst über /etc/init.d/s0vz start wird folgendes in
/var/log/syslog geschrieben: http://pastebin.com/rUEgBfD2

Halte ich nun kurz einen Magneten vor den Reed-Sensor flippt das Skript
völlig aus. Jede Sekunde werden dutzende Requests an die Middleware
geschickt. (Auszug aus der syslog: http://pastebin.com/VzejhPGK) Genau das
selbe passiert, wenn ich die Leitungen am s0/1 kurzschließe, nur dass dann
die andere UUID im GET-Request eingetragen wird. Der s0vz Prozess sorgt
dann für fast 100 % CPU Auslastung.

Nun dachte ich, dass das C-Programm eventuell auf den value 1 triggert. Da
der Wert dauerhaft auf 1 ist, fängt das Programm noch nicht mit der
Erfassung an. Nun werden die Kontakte kurzgeschlossen, der Wert wechselt
kurzzeitig auf 0 und wieder auf 1. Dies nimmt das Programm zum Anlass
leider unendlich viele Werte zu dokumentieren.
Über echo 1 > active_low habe ich nun den value invertiert. Ich dachte mir,
dass wenn kein Kurzschluss besteht der Wert auf 0 steht und wenn der Magnet
des Gaszählers vorbei kommt, der Wert kurz auf 1 wechselt. Leider zeigt
sich genau das selbe Verhalten. Ein kurzer Kurzschluss und das s0vz
Programm hört nicht mehr auf Werte zur Middleware zu schicken.

Ich habe daraufhin probiert herauszufinden, wie das C-Programm den Status
versucht zu erfassen. Das Programm muss ja die Änderung erfassen und darf
nicht einfach nur z.B. jede Sekunden den Status erfragen. Ansonsten würden
sich ja Fehler ergeben, wenn beispielsweise der Magnet des Gaszählers genau
über dem Sensor zum stehen kommt.

Nun meine Fragen auf den Punkt gebracht:
1. Wie kann ich mit Linux mitteln eine Statusänderung erfassen?
2. Wie erkennt das C-Programm die Änderung und warum hört das Programm nach
einer value Änderung nicht mehr auf Daten zu schreiben?

Vielen Dank für Eure Unterstützung
Gruß
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150507/f45b533d/attachment.html>