EDIT:
Kernel 4.9.28 v7 hat ein Problem mit WiringPI.
lässt sich auch über Google finden.
Workaround:
Kernel downgrade auf 4.4 mit sudo rpi-update 2ca627126e49c152beb1bf7abd7122ce076dcc65
Mahlzeit,
Habe heute meine 4 Instanzen mit Updates versorgt.
Raspbian: apt-get update, apt-get dist-upgrade, sudo apt-get clean
FHEM: update
dannach unter Raspbian: sudo reboot.
So, miot dem Reboot haben auf allen 4 Raspberries die GPIOs anfangen zu spinnen.
sind alle unkontrolliert auf active.
Ergebnis waren wild fahrende Rollos und wild schaltende Lampen.
Gibt es mit aktuellen Systemen bekannte Probleme mit GPIOs?
Was kann ich wie analysieren?
Da alle 4 begonnen haben mit dem Update zu spinnen denke ich stark dass es am Update liegt.
Hat jemand eine Ahnung oder Idee woran es hängt und wie ich es lösen kann?
Hab die GPIOs mit externen Pull Up versorgt. keine Schalter betätigt da niemand zuahuse und trotzdem waren die GPIO pinlevel down.
Hilfe!
Grüße
Frank
Nachtrag. Hab jetzt über VPN 3 der 4 raspberries runtergefahren.
Über Kamera sehe ich jetzt immernoch einen Aussen-Strahler am flackern. obwohl der RPI runtergefahren ist...
Bin grad echt ratlos. muss mir das nachher zuhause genauer ansehen.
Logfile Extrakt:
2017.06.30 13:08:20 1: Can't open file: GPIO_IN_04_Kino, active_low
2017.06.30 13:08:25 1: Can't open file: GPIO_IN_05_Werkstatt, active_low
2017.06.30 13:08:30 1: Can't open file: GPIO_IN_06_HSA, active_low
2017.06.30 13:08:35 1: Can't open file: GPIO_IN_07_Flur_KG, active_low
2017.06.30 13:08:40 1: Can't open file: GPIO_IN_08_Lager, active_low
2017.06.30 13:08:45 1: Can't open file: GPIO_IN_09_Heizung, active_low
2017.06.30 13:08:52 1: Can't open file: GPIO_IN_10_GMA_Rauch, active_low
2017.06.30 13:08:57 1: Can't open file: GPIO_IN_11_GMA_CO, active_low
2017.06.30 13:09:02 1: Can't open file: GPIO_IN_12, active_low
2017.06.30 13:09:07 1: Can't open file: GPIO_IN_13, active_low
2017.06.30 13:09:12 1: Can't open file: GPIO_IN_14, active_low
2017.06.30 13:09:17 1: Can't open file: GPIO_IN_15, active_low
Zitat von: Frank_Huber am 30 Juni 2017, 13:43:27
Nachtrag. Hab jetzt über VPN 3 der 4 raspberries runtergefahren.
Über Kamera sehe ich jetzt immernoch einen Aussen-Strahler am flackern. obwohl der RPI runtergefahren ist...
Bin grad echt ratlos. muss mir das nachher zuhause genauer ansehen.
Logfile Extrakt:
2017.06.30 13:08:20 1: Can't open file: GPIO_IN_04_Kino, active_low
2017.06.30 13:08:25 1: Can't open file: GPIO_IN_05_Werkstatt, active_low
2017.06.30 13:08:30 1: Can't open file: GPIO_IN_06_HSA, active_low
2017.06.30 13:08:35 1: Can't open file: GPIO_IN_07_Flur_KG, active_low
2017.06.30 13:08:40 1: Can't open file: GPIO_IN_08_Lager, active_low
2017.06.30 13:08:45 1: Can't open file: GPIO_IN_09_Heizung, active_low
2017.06.30 13:08:52 1: Can't open file: GPIO_IN_10_GMA_Rauch, active_low
2017.06.30 13:08:57 1: Can't open file: GPIO_IN_11_GMA_CO, active_low
2017.06.30 13:09:02 1: Can't open file: GPIO_IN_12, active_low
2017.06.30 13:09:07 1: Can't open file: GPIO_IN_13, active_low
2017.06.30 13:09:12 1: Can't open file: GPIO_IN_14, active_low
2017.06.30 13:09:17 1: Can't open file: GPIO_IN_15, active_low
So wie es aussieht sind nur GPIO Eingänge betroffen
Hast Du "damals" an den Berechtigungen für GPIO "rumgefummelt"? Dieses könnte durchs Ubuntu-update "gelöscht" worden sein
- Ich hoffe, Du hast Dir angeguckt, was upgedatet werden sollte?
- Beim nächsten mal, mit EINEM Testen ... wenn O.K. dann erst komplett ausrollen (am besten beim Unwichtigsten)
kann es sein das durch das dist-update evtl. Gpio deaktiviert wurde.
evtl. mal raspi config schauen
P8 Remote GPIO Enable/Disable remote access to GPIO pins
nur ein gedanke
Gruß Werner
Rechte habe ich geprüft, die passen.
die raspi-config sieht verändert aus.
da heist es jetzt GPIO Freigabe über netzwerk!?
Murphys law. Hab bisher immer erst einen hochgezogen und dann den Rest. Das hat noch nie Probleme bereitet, jetzt alle auf einmal und klar. jetzt gibts Probleme...
Rechte sehen gut aus:
root@huber-pi-kg:/sys/class/gpio# ls -l
insgesamt 0
-rwxrwx--- 1 root gpio 4096 Jun 30 14:16 export
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio10 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio10
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio11 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio11
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio12 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio12
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio13 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio13
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio14 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio14
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio15 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio15
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio16 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio16
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio17 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio18 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio19 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio19
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio20 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio20
lrwxrwxrwx 1 root gpio 0 Jun 30 14:15 gpio21 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio21
lrwxrwxrwx 1 root gpio 0 Jun 30 14:15 gpio22 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio22
lrwxrwxrwx 1 root gpio 0 Jun 30 14:15 gpio23 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Jun 30 14:15 gpio24 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio24
lrwxrwxrwx 1 root gpio 0 Jun 30 14:15 gpio25 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio25
lrwxrwxrwx 1 root gpio 0 Jun 30 14:15 gpio26 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio26
lrwxrwxrwx 1 root gpio 0 Jun 30 14:15 gpio27 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio27
lrwxrwxrwx 1 root gpio 0 Jun 30 14:13 gpio4 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio4
lrwxrwxrwx 1 root gpio 0 Jun 30 14:13 gpio5 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio5
lrwxrwxrwx 1 root gpio 0 Jun 30 14:13 gpio6 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio6
lrwxrwxrwx 1 root gpio 0 Jun 30 14:13 gpio7 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio7
lrwxrwxrwx 1 root gpio 0 Jun 30 14:13 gpio8 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio8
lrwxrwxrwx 1 root gpio 0 Jun 30 14:14 gpio9 -> ../../devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio9
WiringPI ist version 2.4.4
Kernel ist version 4.9.28 v7
mach grad kernel downgrade auf 4.4
hoffe das bringt was...
es könnte auch am WiringPi liegen.
Ich meine mich erinnern zu können das ich vor ca. 2-3 Wochen eine S.USV eingebunden habe und dabei Probleme hatte.
WiringPi läuft nicht mit dem neuen Kernel > hatte ich bei Google gefunden
Darum habe ich meine S.USV ohne WiringPi installiert und funktioniert
Gruß Werner
und viel Erfolg
mit kernel 4.4 läuft alles.
werd dann erstmal alle Kernel downgraden und dann testen.
WiringPI sollte ja gar nicht mehr notwendig sein.
Das wird aber erst alles auf dem Test-Raspi vollzogen.
nochmal brauch ich das nicht wie heute...
Die GPIO's werden bei Dir direkt oder über die PiFace Erweiterung angesprochen?
Zitatwild fahrende Rollos und wild schaltende Lampen.
kommt mir indirekt bekannt vor.
Meine seit langem stabile Lösung, wobei ich aber eben auch eine PiFace Erweiterung nutze, ist das Setzen des "tri" Modus der PiFace Input Pins.
In der init.d/fhem mache ich dazu direkt vor dem FHEM Start:
# für alle PiFace Inputs, den internen Pullup Widerstand aktivieren um einen stabilen Eingang zu bekommen
# ToDo: verschieben des gpio -x... Kommandos an eine andere Boot Stelle. Muss aber für und vor dem Fhem Start gemacht werden
for i in `seq 200 207`; do sudo gpio -x mcp23s17:200:0:0 mode $i tri; done
# normaler Start
perl fhem.pl fhem.cfg
Warum mache ich das?
Ein gpio -P readall hatte bei mir mit dem PiFace ein Flakern/Tooglen der Inputs gezeigt, obwohl nichts angeschlossen oder geschaltet war.
Davon waren die Pins 200 - 206 betroffen, aber nie der Pin 207.
In der Shell hatte ich diese Dauerschleife ausgeführt
while (true); do clear; gpio -p readall; sleep 1; doneUnd die Ausgabe zeigte immer mal eine "1" auf den genannten Input-Pins
+------+---------+--------+
| Pin | Digital | Analog |
+------+---------+--------+
| 200 | 1 | 0 |
| 201 | 1 | 0 |
| 202 | 1 | 0 |
| 203 | 1 | 0 |
| 204 | 1 | 0 |
| 205 | 1 | 0 |
| 206 | 0 | 0 |
| 207 | 0 | 0 |
| 208 | 0 | 0 |
| 209 | 0 | 0 |
| 210 | 0 | 0 |
| 211 | 0 | 0 |
| 212 | 0 | 0 |
| 213 | 0 | 0 |
| 214 | 0 | 0 |
| 215 | 0 | 0 |
+------+---------+--------+
+------+---------+--------+
| Pin | Digital | Analog |
+------+---------+--------+
| 200 | 0 | 0 |
| 201 | 0 | 0 |
| 202 | 1 | 0 |
| 203 | 1 | 0 |
| 204 | 1 | 0 |
| 205 | 1 | 0 |
| 206 | 0 | 0 |
| 207 | 0 | 0 |
| 208 | 0 | 0 |
| 209 | 0 | 0 |
| 210 | 0 | 0 |
| 211 | 0 | 0 |
| 212 | 0 | 0 |
| 213 | 0 | 0 |
| 214 | 0 | 0 |
| 215 | 0 | 0 |
+------+---------+--------+
+------+---------+--------+
| Pin | Digital | Analog |
+------+---------+--------+
| 200 | 0 | 0 |
| 201 | 0 | 0 |
| 202 | 0 | 0 |
| 203 | 0 | 0 |
| 204 | 0 | 0 |
| 205 | 0 | 0 |
| 206 | 0 | 0 |
| 207 | 0 | 0 |
| 208 | 0 | 0 |
| 209 | 0 | 0 |
| 210 | 0 | 0 |
| 211 | 0 | 0 |
| 212 | 0 | 0 |
| 213 | 0 | 0 |
| 214 | 0 | 0 |
| 215 | 0 | 0 |
+------+---------+--------+
Ja, aber warum setze ich diesen Modus und es hilft?
Weil der Entwickler mir das auf meine Anfrage hin als Tipp geraten hatte.
ZitatTry setting the internal pull-ups as this isn't done in the setup code.
Wozu brauche ich das?
Ich habe an meinen Inputs ganz simple Wassermelder realisiert, indem der Input gegen GND auf low zieht, sobald die zwei Kontakte durch Wasser verbunden werden.
Siehe https://forum.fhem.de/index.php/topic,50427.msg421780.html (https://forum.fhem.de/index.php/topic,50427.msg421780.html)
Ich habe nun seit dem Mai 2017 einen 4.9'er Kernel drauf und mind. seit dem 20.06. den 4.9.28-v7 und weiterhin keine Probleme mit meinen GPIO Inputs.
Der WiringPI Entwickler hat im Dezember wegen des 4.9 Kernel ein Update gemacht auf die Version 2.44
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=167934&start=200#p1144459 (https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=167934&start=200#p1144459)
Das einzige was ich tatsächlich auf einem der weiteren PIs noch zusätzlich updaten musste, wegen einer anderen Anwendung, war die erwähnte Pi4J Libary für eine Webanwendung mit dem aktuellen Snapshot 1.2 zu erneuern, siehe https://github.com/Pi4J/pi4j/issues/349 (https://github.com/Pi4J/pi4j/issues/349)
Zumindest mit der Dauerschleife für gpio -p readall könntest Du überprüfen, was deine Inputs für ein High/Low Level denken zu haben.