<div dir="ltr">Guten Tag, <div><br></div><div>ich habe den Pi2 mit der kleinen Erweiterung. Daran angeschlossen diesen Reed-Sensor (<a href="http://www.reichelt.de/Reedrelais-Magnete/MK-471B/3/index.html?ACTION=3&GROUPID=3291&ARTICLE=27681&SEARCH=MK%20471B&OFFSET=500&WKID=0&" target="_blank">http://www.reichelt.de/Reedrelais-Magnete/MK-471B/3/index.html?ACTION=3&GROUPID=3291&ARTICLE=27681&SEARCH=MK%20471B&OFFSET=500&WKID=0&</a>). </div><div><br></div><div>Problem: Das C-Programm erkennt keine (bzw. nur fehlerhaft) Änderung am Device /sys/class/gpio/gpio17/value<br><br></div><div>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. <br></div><div><br></div><div>Den s0vz Dienst habe ich wie hier beschrieben eingerichtet. (<a href="https://github.com/w3llschmidt/s0vz" target="_blank">https://github.com/w3llschmidt/s0vz</a>) 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. <br></div><div><br></div><div>Nur um sicher zu gehen, dass ich nichts falsch konfiguriert habe, hier alle involvierten Dateien: </div><div><br></div><div>/etc/s0vz.cfg: <a href="http://pastebin.com/hPjz4YwG" target="_blank">http://pastebin.com/hPjz4YwG</a> </div><div>(Die Beispieldatei hat ein Semikolon am Ende der GPIO0 Zeile. Vermutlich ein Fehler)</div><div>(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.)</div><div><br></div><div>s0vz.c: <a href="http://pastebin.com/zGQ07b7t" target="_blank">http://pastebin.com/zGQ07b7t</a> (Mit Debug Ausgaben)</div><div><br></div><div>s0vz (init Skript): <a href="http://pastebin.com/tkD9C8gn" target="_blank">http://pastebin.com/tkD9C8gn</a> (Läuft testhalber unter dem Benutzer root)</div><div><br></div><div>/etc/rc.local: <a href="http://pastebin.com/zGxd5aeG" target="_blank">http://pastebin.com/zGxd5aeG</a></div><div><br></div><div>/etc/init.d/rc.local: <a href="http://pastebin.com/MLM8Vz0u" target="_blank">http://pastebin.com/MLM8Vz0u</a> </div><div><br></div><div>Beim Start des s0vz Dienstes wird folgendes in die log-Datei /var/log/syslog geschrieben: <a href="http://pastebin.com/nGVK4GbS" target="_blank">http://pastebin.com/nGVK4GbS</a> </div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div><div>/sys/class/gpio# ls -l</div><div>insgesamt 0</div><div>-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 export</div><div>lrwxrwxrwx 1 root gpio    0 Mai  6 20:59 gpio17 -> ../../devices/soc/3f200000.gpio/gpio/gpio17</div><div>lrwxrwxrwx 1 root gpio    0 Mai  6 20:59 gpio18 -> ../../devices/soc/3f200000.gpio/gpio/gpio18</div><div>lrwxrwxrwx 1 root gpio    0 Jan  1  1970 gpiochip0 -> ../../devices/soc/3f200000.gpio/gpio/gpiochip0</div><div>-rwxrwx--- 1 root gpio 4096 Jan  1  1970 unexport</div></div><div><br></div><div><div>/sys/class/gpio/gpio17# ls -l</div><div>insgesamt 0</div><div>-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 active_low</div><div>lrwxrwxrwx 1 root gpio    0 Mai  6 20:59 device -> ../../../3f200000.gpio</div><div>-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 direction</div><div>-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 edge</div><div>drwxrwx--- 2 root gpio    0 Mai  6 20:59 power</div><div>lrwxrwxrwx 1 root gpio    0 Mai  6 20:59 subsystem -> ../../../../../class/gpio</div><div>-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 uevent</div><div>-rwxrwx--- 1 root gpio 4096 Mai  6 20:59 value</div></div><div><br></div><div><br></div><div><div>cat active_low: 0</div><div>cat direction: in</div><div>cat edge: rising</div><div>cat value: 1</div></div><div><br></div><div>Es verwundert mich nun, warum value immer auf 1 steht. <br></div><div>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. <br></div><div>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. <br><br></div><div>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: <a href="http://pastebin.com/rUEgBfD2">http://pastebin.com/rUEgBfD2</a> <br><br></div><div>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: <a href="http://pastebin.com/VzejhPGK">http://pastebin.com/VzejhPGK</a>) 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. <br><br></div><div>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. <br>Ü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. <br><br></div><div>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. <br><br></div><div>Nun meine Fragen auf den Punkt gebracht: <br></div><div>1. Wie kann ich mit Linux mitteln eine Statusänderung erfassen? <br></div><div>2. Wie erkennt das C-Programm die Änderung und warum hört das Programm nach einer value Änderung nicht mehr auf Daten zu schreiben? <br><br></div><div>Vielen Dank für Eure Unterstützung<br></div><div>Gruß<br></div><div>Alexander<br></div><div><br></div><div><br></div><div><br></div></div>