Information
Der Zugriff über die Schnittstelle sysfs-gpio (/sys/class/gpio/export) wird ab Bookworm nicht mehr unterstützt.
Die neue Methode arbeitet mit gpiod Tools (debian paket) oder pinctrl (Raspberry Pi OS Tool).
Weitere Informationen z.B. hier: https://pi-buch.info/gpio-reloaded-ii-bash/
oder hier https://www.acmesystems.it/gpiod
Mit dem neuen release "Bookworm" ist offensichtlich eine Menge geändert worden, das kann einen Umzug ganz schön behindern.
Mein erster Versuch einer FHEM-Modernisierung scheiterte daran, daß der Displaytreiber für das Mini-Display von Locutus' add-on board nicht zur Mitarbeit zu bewegen war.
Bin mal gepannt, was sich sonst noch so alles verändert hat... ???
mein Test System ist schon länger auf Bookworm, ich habe das Image von OctoPI drauf.
GPIO war nie ein Problem.
ABER: heute mal wieder OS und FHEM Update gemacht und siehe da, GPIO Meldungen im Log:
erst kommt das hier für jeden in FHEM definierten GPIO
2024.04.26 11:32:25 1: Can't open file: GPIO_IN_04, active_low
2024.04.26 11:32:25 1: Can't open file: GPIO_IN_04, edge
dannach noch das hier auch 1x pro definiertem GPIO:
2024.04.26 11:34:15 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/51_RPI_GPIO.pm line 272, <$fh> line 501.
soweit ich es in FHEM testen kann funktionieren die GPIOs aber.
da momentan nichts angeschlossen ist kann ich es nicht auf Hardware Basis testen, das hole ich nächste Woche nach.
Wollte die Info nur mal hier ergänzen. Das ganze scheint durch ein OS Update zu kommen dass im März bzw April verteilt wurde.
mein letztes Update war ca. am 1.3.
Der Zugriff auf die GPIOs über /sys/class/gpio/ funktioniert auch in Bookworm noch.
Allerdings hat /sys/class/gpio inzwischen wohl den Status deprecated bekommen.
Daher kann es gut sein, das es in näherer Zukunft entfernt wird.
Lediglich beim Pi5 hat sich die Nummerierung im Vergleich zu den Vorgängern geändert:
https://forum.fhem.de/index.php?msg=1312147
Ich wäre vorsichtig mit der Aussage "in näherer Zukunft", ich meine der Grund für meine Nachricht war ein aktuelles debian für den Pi, wo die Funktion schon raus war. https://forum.fhem.de/index.php?topic=137496.0
Und wie ich es verstanden habe, ist es eine Kernelfunktion. Es kann also bei jedem Update plötzlich rausfliegen. Das Ende (deprecated) wurde 2015 (inzwischen) angekündigt und vielleicht ist nach 10 Jahren endgültig Schluss? 2025 kommt schneller als man denkt.
Ich würde jetzt nicht fummeln und ignorieren - geht doch noch - sondern umstellen auf supportete Schnittstellen. ;)
Also ist es beim aktuellen Debian schon entfernt worden?
Ich habe bisher immer nur das Raspberry OS verwendet. Da wurde es demnach noch mit reingenommen.
Fummeln muss man ja nicht groß, mit dem richtigen OS geht es ja. 8)
Allerdings muss ich dir rechtgeben das es so nicht bleiben kann. Wer weiß wie lange es Raspberry OS noch beibehält und andere Einplaninenrechner könnten bereits außen vor sein.
Könnte gpiod (gpioget, gpioset, pinctrl...) eine Lösung sein?
Gibt es noch andere Möglichkeiten die man sich ansehen sollte?
Ich würde schon gern auf etwas Nachhaltiges setzen wenn ich das Modul umbaue.
So nahe untersucht habe ich das ja nicht. Aber in einem aktuellen debian für den Pi (auch für mich ein ungewöhnliches OS) war sysfs-gpio nicht mehr drin und mit gpiod hat die Aktivierung von Pin17 funktioniert. Ich habe nur ein bisschen gelesen und mag da keine strategische Aussage treffen ;)
Moinsen zusammen,
eben hat sich meine SD Karte verabschiedet und ich musste den Pi3 für die Terrarien neu aufsetzen. Rasperian (aktuelle Version Bookworm) heruntergeladen, auf die SD übertrage, FHEM installiert,... Alles soweit gut, bis auf dass ich die RPI_GPIO's nicht schalten konnte.
Anstatt hier ins Forum zu schauen, habe ich mich auf die Suche gemacht und bin hier über die Ursache des Problems gestolpert: https://www.thegoodpenguin.co.uk/blog/stop-using-sys-class-gpio-its-deprecated/ (https://www.thegoodpenguin.co.uk/blog/stop-using-sys-class-gpio-its-deprecated/)
Wie ihr schon geschrieben habt, ist unter dem Kernel 6.6 der Zugriff auf die GPIO's nicht mehr über sysfs möglich. Entsprechend funktioniert das FHEM Modul RPI_GPIO nicht mehr unter Bookworm (6.6er Kernel).
Da ich nur 7 GPIO-Ausgänge zu schalten habe, habe ich mir kurzerhand eine kleine Funktion gebastelt und in ein Modul gepackt:
sub set_GPIO($$) {
my ( $myPort, $myEvent ) = @_;
my $mytimestamp = int(time());
if ($myEvent eq "on") {
system("gpioset","gpiochip0",$myPort."=1");
Log 1,"---> " .localtime($mytimestamp)." GPIO-Port: ". $myPort." --> Event: on";
} else {
system("gpioset","gpiochip0",$myPort."=0");
Log 1,"---> " .localtime($mytimestamp)." GPIO-Port: ". $myPort." --> Event: on";
}
}
Auf die 7 RPI_GPIO's habe ich mir dann als Pflaster ein Notify gelegt, welches die Funktion aufruft:
define n_TerraLampe_GPIO_13 notify TerraLampe:.* {set_GPIO(13,$EVENT)}
Ich weiß, dass ist keine saubere und dauerhafte Lösung, aber so braucht meine Tochter sich keine akuten Sorgem mehr um ihre Tiere machen ;) . Die RPI_GPIO-Devices habe ich erst einmal unverändert gelassen. Wenn ich das Device nun triggere, dann erscheint zwar eine Meldung im Log...:
2024.05.06 13:50:00 1: Can't open file: TerraLampe, value ... Diese werde ich erst einmal ignorieren.
@klausw: Unter dem oben genannten Link gibt es auch einen Link zu einer Auflistung von verschiedenen Subsystem-Treibern für den GPIO Zugriff. Das könnte für dich interessant sein: https://www.kernel.org/doc/html/v4.17/driver-api/gpio/drivers-on-gpio.html (https://www.kernel.org/doc/html/v4.17/driver-api/gpio/drivers-on-gpio.html)
Vielleicht hilft der Workaround ja dem Einem oder Anderen...
LG
Die Logmeldung könntest Du wegbekommen, in dem Du die Devices zu Dummys migrierst ....