Autor Thema: [workaround] Keine Funktion GPIO/WiringPI mit Kernel 4.9.28 v7 !!!  (Gelesen 1906 mal)

Offline Frank_Huber

  • Hero Member
  • *****
  • Beiträge: 3320
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
« Letzte Änderung: 11 Februar 2019, 09:53:57 von Frank_Huber »

Offline Frank_Huber

  • Hero Member
  • *****
  • Beiträge: 3320
Antw:GPIO Fehlverhalten nach Raspian und FHEM Update
« Antwort #1 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

« Letzte Änderung: 30 Juni 2017, 13:46:40 von Frank_Huber »

Offline Frank_Huber

  • Hero Member
  • *****
  • Beiträge: 3320
Antw:GPIO Fehlverhalten nach Raspian und FHEM Update
« Antwort #2 am: 30 Juni 2017, 13:56:19 »
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

Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 5479
Antw:GPIO Fehlverhalten nach Raspian und FHEM Update
« Antwort #3 am: 30 Juni 2017, 13:58:52 »
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)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline Intruder1956

  • Sr. Member
  • ****
  • Beiträge: 579
  • Auch wenn man Älter wird, kann man besser werden
Antw:GPIO Fehlverhalten nach Raspian und FHEM Update
« Antwort #4 am: 30 Juni 2017, 14:00:00 »
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
Zotac CI547 32GB RAM 500GB SSD,ESXI 6.5, VM-Fhem5.8, VM-ioBroker, Cul 868Mhz;Cul 433Mhz = Busware, LGW, HM-MOD-RPI-PCB, Uniroll, IT YCR-100 TMT2100,ITR-1500, LD382 mit Wifilight, ESA 2000 + SENSOR WZ SET,FS20 TFK, HM-Sec-SC, HM-CC-RT-DN,PCA301,

Offline Frank_Huber

  • Hero Member
  • *****
  • Beiträge: 3320
Antw:GPIO Fehlverhalten nach Raspian und FHEM Update
« Antwort #5 am: 30 Juni 2017, 14:15:00 »
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
« Letzte Änderung: 30 Juni 2017, 14:20:26 von Frank_Huber »

Offline Frank_Huber

  • Hero Member
  • *****
  • Beiträge: 3320
Antw:GPIO Fehlverhalten nach Raspian und FHEM Update
« Antwort #6 am: 30 Juni 2017, 14:34:48 »
mach grad kernel downgrade auf 4.4
hoffe das bringt was...

Offline Intruder1956

  • Sr. Member
  • ****
  • Beiträge: 579
  • Auch wenn man Älter wird, kann man besser werden
Antw:GPIO Fehlverhalten nach Raspian und FHEM Update
« Antwort #7 am: 30 Juni 2017, 14:36:53 »
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
Zotac CI547 32GB RAM 500GB SSD,ESXI 6.5, VM-Fhem5.8, VM-ioBroker, Cul 868Mhz;Cul 433Mhz = Busware, LGW, HM-MOD-RPI-PCB, Uniroll, IT YCR-100 TMT2100,ITR-1500, LD382 mit Wifilight, ESA 2000 + SENSOR WZ SET,FS20 TFK, HM-Sec-SC, HM-CC-RT-DN,PCA301,

Offline Frank_Huber

  • Hero Member
  • *****
  • Beiträge: 3320
Antw:GPIO Fehlverhalten nach Raspian und FHEM Update
« Antwort #8 am: 30 Juni 2017, 14:41:19 »
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...



Offline Patrik.S

  • Jr. Member
  • **
  • Beiträge: 90
Die GPIO's werden bei Dir direkt oder über die PiFace Erweiterung angesprochen?

Zitat
wild 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; done
Und 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.
Zitat
Try 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


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

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


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.

 

decade-submarginal