Ich habe gerade alles gepurged, was es gab. Und danach noch einmal die einzelnen Verzeichnisse nach homegear durchsucht und den Rest manuell gelöscht.
Nach einem Neustart und der neuen, sauberen Installation über config-openhabian, kommt nach der Installation dieses Fenster, in dem explizit erwähnt wird, dass man die homegear-console über “sudo homegear -r” starten soll 
soll man nicht, demnächst sagt auch das Fenster das nicht mehr
Alles klar 
Ich kann nun “homegear -r” starten und auch “familie select 0” ausführen. Jedoch kann ich mich nicht pairen.
Ein Blick in die homegear.err zeigt folgendes:
07/31/20 13:59:51.238 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:00:21.239 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:00:22.265 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:00:24.267 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:00:54.268 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:00:55.292 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:00:57.294 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:01:27.294 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:01:28.315 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:01:30.317 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:02:00.317 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:02:01.341 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:02:03.343 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:02:33.343 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:02:34.368 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:02:36.370 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:03:06.370 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:03:07.396 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:03:09.398 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:03:39.398 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:03:40.428 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:03:42.430 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:04:12.430 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:04:13.452 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:04:15.454 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:04:45.454 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:04:46.480 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:04:48.482 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:05:18.483 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
07/31/20 14:05:19.511 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
07/31/20 14:05:21.525 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device "hm-mod-rpi-pcb": Unable to retrieve path.
07/31/20 14:05:51.525 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.
Wie komme ich nun hier weiter?
Der Prozess/Service läuft jedenfalls.
Ach und zur Info: das lief bei mir schonmal alles einwandfrei. Habe nur mein 3 Jahre altes System einmal komplett neu und frisch aufgesetzt. Damit ist jedenfalls zumindest die Hardware als Fehlerquelle auszuschließen.
Auch bei mir lief OpenHAB 2.5.4 mit Homegear stabil. Nun dachte ich es sei mal wieder Zeit für ein Update, zumal nur 0.0.3 Versionsprung kein Ungemach dieser Größenordnung erahnen ließ.
Homegear lässt sich nun als ‘homegear -r’ starten und antwortet. Auch der HomematicManager zeigt alle Geräte an.
Allerdings sehe ich im /var/log/homegear/homegear.err ein Kommunikationsproblem:
“Module HomeMatic BidCoS: HM-MOD-RPI-PCB “My-HM-MOD-RPI-PCB”: Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void BidCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device “hm-mod-rpi-pcb”: Unable to retrieve path.”
In dem Chaos der unterschiedlichsten Anleitungen habe ich mir mal aufgeschrieben, dass
“ls -l /dev/serial1” den Wert “/dev/serial1 -> ttyS0” zurückgeben soll.
Aber “ls: cannot access ‘/dev/serial1’: No such file or directory” sagt, nix serial1 vorhanden.
Braucht es serial1 noch?
Nach vielen Installationsversuchen und Stunden des Probierens komme ich zum Schluss, dass mit einer Veränderung des OpenHABian Linux GPIO Zugriffe anders funktionieren. Leider habe ich kein Image mehr, das noch funktioniert, weil gleich beim Installieren ein Update drüber läuft. Sehr ärgerlich.
Ich habe ein Buster Image openhabian-pi-raspbian-201908050414-gitca0976f-crc6a66b5a1.img.xz und ein Strech Image openhabianpi-raspbian-201804031720-gitdba76f6-crc9e93c3eb.img.xz probiert. Jedes Mal lande ich nach der Installation bei openHAB 2.5.7-1 (Release Build).
sudo openhabian-config
Install Homegear in Optional Components
WICHTIG: Apply Improvements -> Fix Permissions (otherwise Could not connect to socket. Error: No such file or directory for homegear -r)
Anpassungen an vier Dateien /etc/homegear/families/ `homematicbidcos.conf, /boot/config.txt, /boot/cmdline.txt und /etc/udev/rules.d/99-com.rules wie hier
https://doc.homegear.eu/homegear-homematicbidcos/configuration.html beschrieben.
Reboot
Module HomeMatic BidCoS: HM-MOD-RPI-PCB “My-HM-MOD-RPI-PCB”: Error in file PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp line 969 in function void idCoS::Hm_Mod_Rpi_Pcb::doInit(): Failed to open value file for GPIO with index 1 and device “hm-mod-rpi-pcb”: Unable to retrieve path.
Im Source Code https://github.com/Homegear/Homegear-HomeMaticBidCoS/blob/master/src/PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp
openGPIO(1, false);
setGPIO(1, false);
std::this_thread::sleep_for(std::chrono::milliseconds(100));
setGPIO(1, true);
closeGPIO(1);
Da scheint der Zugriff auf GPIO im Raspi nicht freigegeben zu sein. Beschreibung liegt hier /boot/overlays/README.
Vielleicht in /boot/config.txt? Hat jemand eine Idee, was korrigiert werden muss?
Jetzt habe ich eine Lösung gefunden, die bei mir funktioniert.
GPIO18 war nicht unter /sys/class/gpio sichtbar, somit zeigt
ls -l /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18
auch keine Einträge.
Mit dieser Sequenz habe ich GPIO18 angelegt und nach einem Reboot funktioniert wieder alles. Hilfreich war http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_GPIO_Shell.html
Obwohl ein paar Fehlermeldungen noch immer im Homegear-Logfile auftauchen.
sudo su
echo “18” > /sys/class/gpio/export
echo “out” > /sys/class/gpio/gpio18/direction
echo “0” > /sys/class/gpio/gpio18/value
chown homegear:homegear /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18/direction
chown homegear:homegear /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18/edge
chown homegear:homegear /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18/value
Bei vorherigen Installationen (bis OpenHABian 2.5.4) hat es einfach funktioniert: hassle-free.
Was ist die Ursache dafür, dass ich das von Hand nachtragen muss?
Wie ich z.T. bereits im openHAB-Forum geantwortet habe, sind in diesem Post gleich mehrere Dinge bedenklich und bedürfen einer Richtigstellung, weil das keineswegs zur Nachahmung empfohlen ist.
Zunächst einmal: wenn du von einem 3 Jahre alten System kommst, dann ist es arg naiv zu erwarten daß bei dem dabei erfolgenden Wechsel auf eine neuere Basis-Betriebssystem-Version keine Änderungen nötig sind.
Mit der openHAB- oder openHABian-Version hat das noch nicht einmal etwas zu tun. Über Änderungen aller dieser drei muß man sich im Vorfeld eines Upgrades natürlich gründlich informieren.
Zweitens hast du da anscheinend schon vor 3 Jahren konzeptionell etwas in den falschen Hals gekriegt und willst dies nun weiterführen, nämlich den direkten Zugriff auf RPi-GPIOs von homegear aus.
Du willst also quasi den openHAB-Server mit openHABian/Raspbian als OS als Aktor missbrauchen.
Das ist aus verschiedenen Gründen keine gute Idee, u.a. weil es die Betriebsstabilität gefährdet.
Vor allem in Kombination mit openHAB ist es aber gänzlich abzulehnen. Wenn du openHAB fährst, dann mußt du auch auf alle Hardware via openHAB zugreifen (also per GPIO binding, wenn’s denn unbedingt sein soll) und nicht direkt per homegear.
Und bei allen guten Absichten die du sicherlich mit diesem Post verfolgst, ist drittens auch dein Workaround ist eine schlechte Idee, weil sie den regulären Zugriff anderer Un*x-User wie z.B. dem openhab-User auf GPIOs verhindert. Wenn überhaupt solltest du dem homegear-User Mitgliedschaft in einer Un*x-Gruppe hinzufügen, die schon Schreibrechte auf die Devices hat.
Kannst du für dich gern so handhaben, aber der Direkt-Zugriff auf GPIOs bleibt ein kaputtes Konzept.
Poste das also bitte nicht als Lösung zur Nachahmung.
Hallo @harabeck, und @mstormi
habe leider selbiges Problem. ist meine Erstinbetriebnahme von homegear auf einem frischen openhab image mit direkter installation von homegear aus openhabian-config (inkl. fixes)
wollte es erst auf einem sauberen System testen bevor ich es in meine Produktivumgebung umziehe.
Der Workaround scheint bei mir leider auch nicht zu funktionieren.
Was wäre denn dann der korrekte Weg? Wo wird das Thema denn noch gerade diskutiert?
Homegear in die entsprechende Gruppe aufzunehmen klingt plausibel…
Schon mal Danke für eure Posts.
Schrieb ich doch: benutz das openHAB GPIO binding anstelle die über homegear steuern zu wollen.
Workarounds sind workarounds, keine Lösungen.
Hallo, ich bin neu in der Community und nur durch dieses Thema im Forum gelandet. Komme von Openhab.
Mich beschäftigt das Thema Homegear und Openhabian + HM-MOD-RPI-PCB schon eine ganze Weile und es gab bisher keine Lösung. Auf meiner “alten” Openhabian installation lief dies auch alles ohne Probleme. Wollte nun auf den RPI4 umziehen. Hänge nun beim beschriebenen Problem.
Danke für diese Hinweise @harabeck . Mit den beschriebenen Kommandos für die Berechtigungen hat das bei mir nun auch funktioniert. Folgende Befehle habe ich ausgeführt.
sudo echo "18" > /sys/class/gpio/export
sudo echo "out" > /sys/class/gpio/gpio18/direction
sudo echo "0" > /sys/class/gpio/gpio18/value
sudo chown homegear:homegear /sys/devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio18/direction
sudo chown homegear:homegear /sys/devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio18/edge
sudo chown homegear:homegear /sys/devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio18/value
sudo systemctl restart homegear
Danach hat das pairen nun endlich funktioniert. 
Leider muss das nach jedem Neustart erneut definiert werden.
Ich habe keine wirkliche Ahnung was dies für folgende Systeme bedeutet oder ob es Beeinträchtigungen geben wird. Aber da ich keine weiteren GPIO´s nutzen werde, ist es okay das homegear diese Rechte alleinig besitzt.
Wie schon @mstormi rwähnt hat, ist dies sicherlich keine wirkliche Lösung für alle User. Hoffentlich wird das openhabian-image noch so konfiguriert das dies wieder ohne Umwege möglich ist einen HM-MOD anzubinden.
Danke für eure Arbeit.
Ja aber das Problem besteht hier doch darin, dass homegear hier die Kontrolle über die Pins benötigt um eine angeschlossene Hardware steuern zu können. Nach meinem Verständnis ermöglicht das GPIO Binding mir das Ansteuern der Pins. Ein “Übertragen” der Kontrolle an homegear ist hier nicht vorgesehen.
Das beobachtete Verhalten ist (zumindest bei mir), dass homegear nicht startet weil es keine Kontrolle über den Pin hat und deswegen die eingestellte Defaultschnittstelle nicht initialisieren kann.
Bin wie beschrieben auch neu bei homegear weil ich jetzt Komponenten von ELV benutzen möchte. Nach meinem Verständnis laufen openhab und homegear parallel und man kann von openhab über homegear auf die smart-home hardware zugreifen.
Würde das angedeutete vorgehen den GPIO den so frühzeitig “in Besitz nehmen”, dass homegear sauber durchstartet?
Das starten von homegear scheitert schon recht früh im bootprozess
dmesg | grep homegear
liefert:
[ 5.550370] systemd[1]: /etc/systemd/system/homegear-management.service:8: RuntimeDirectory= path is absolute, ignoring: /run/homegear
Oder liegt das Missverständnis hier bei mir?
Vielen Dank im Voraus für die Geduld.
Ich kenne das Modul nicht und weiß darum auch nicht warum es nötig sein soll das über einen Pin anzusteuern.
Aber wenn man homegear auf openHABian zusammen mit openHAB benutzt ist natürlich openHAB der Controller aller HW und auch der GPIOs. Da darf dann auch niemand reinpfuschen sondern muß sich openHAB “unterordnen”, sonst gibt das früher oder später Probleme.
Früher lief homegear als root und hat das einfach gemacht. Da es jetzt sinnvoller als eigener Benutzer “homegear” läuft, funktioniert das nicht mehr bzw. man muß diesem Benutzer die Rechte einräumen.
Das macht man aber bitteschön richtigerweise nicht mit einem chown homegear, das ist ja eine mit openHAB inkompatible Holzhammermethode.
Besser sollte man chgrp gpio machen. Da sowohl die User openhab und homegear beide Mitglied dieser Gruppe sind können anschließend beide auf die GPIOs zugreifen.
Das ist lediglich eine Meldung die nichts darüber aussagt ob homegear läuft.
Hallo mstormi,
danke dir für die Zeit und Geduld mit uns hier.
Magst du (um dieses Thema vielleicht abschließen zu können) bitte einmal ausführlich erklären, was man aktuell zu tun hat, um homegear zum Laufen zu bewegen?
Option a) Letztes stable openHABian image
Option b) Die aktuelle openHABian Alpha 1.6
Und dazu direkt die Frage: sollte man direkt nocheinmal neustarten mit der Alpha? Oder gibt es einen Workaround für Option a)?
Sorry nein ich habe aktuell zu viele Baustellen.
homegear allein sollte funktionieren. Ob du das alte image nimmst und ein dist-upgrade auf buster machst oder gleich das neue nimmst sollte egal sein.
Das mit diesem Funkmodul ist separat zu betrachten, aber da ich keines habe kann ich das auch nicht ausprobieren und genauer beschreiben. Die device-Files sollten chgrp gpio gesetzt werden.
Hallo @mstormi,
Nein, damit erzeugst du genau das Problem. Denn dann läuft die Console ja als root und hinterläßt Dateien die nur für root schreib/löschbar sind wie z.B. den o.g. Socket.
sudo -u homegear homegear -r wäre der korrekte Befehl. sudo homegear -r macht aber nichts kaputt, legt keine Dateien als root an und kann einigermaßen gefahrlos ausgeführt werden (so gefahrlos das Arbeiten als root halt ist).
Kannst du für dich gern so handhaben, aber der Direkt-Zugriff auf GPIOs bleibt ein kaputtes Konzept.
Poste das also bitte nicht als Lösung zur Nachahmung.
Das ist so nicht korrekt. Warum ist das Konzept kaputt? Ich finde auch, dass sich diskutieren lässt, ob Homegear und OpenHAB zusammen auf einem System laufen sollten. Aber: Homegear weiß nichts von OpenHAB und muss auch ohne funktionieren. An dieser Stelle wird der GPIO-Zugriff benötigt, um das Modul zu resetten. Es ließe sich an dieser Stelle auch per vorgelagertem Bashskript lösen. Aber ist das die bessere Lösung? Wo liegt das Sicherheitsproblem? Ist der Zugriff gefährlicher, als auf UART? An anderer Stelle ist der Zugriff sogar zwingend erforderlich, nämlich bei Verwendung von Geräten, welche per Interrupt Ereignisse signalisieren (im BidCoS-Modul z. B. der CC1101). Wie soll es an dieser Stelle anders als über den Direktzugriff funktionieren? Ich bin offen für Diskussionen. Uns ist wichtig, dass Homegear sicher ist.
Viele Grüße
Sathya
Nachtrag: homegear -r als Benutzer wird nur dann funktionieren, wenn der aktuelle Benutzer in der Gruppe homegear ist.
Zu dem Zeitpunkt hatte der Kollege die Hintergründe nicht vernünftig erklärt und ich ging davon aus daß er den GPIO von homegear aus ansteuern wollte und irgendein HM-Aktor daran hängt.
Das wäre dann eine Ansteuerung eines Aktors komplett an openHAB vorbei gewesen und das Konzept ist (wäre) kaputt.
Nachdem ich mir die Infos zusammengesucht habe habe ich verstanden daß ihr das Ding nicht als Aktor sondern als CUL-Alternative benutzt. Zwar bin ich auch da der Meinung daß man nicht einfach auf (aus RPi-Sicht gesharete, da kann auch was anderes dranhängen !) Pins gehen sollte und vernünftige Hardware sich ausschliesslich über eine serielle Schnittstelle ansteuern läßt, aber ich steh’ mit so manchem eq-3 Konzept auf Kriegsfuss.
Wenn’s nicht anders geht dann macht halt den Direktzugriff. Security muss man dann aber über device-Rechte erzwingen, daher mein Hinweis auf chgrp gpio (und homegear in die Gruppe gpio aufnehmen).
Hallo @mstormi,
UART mag ich ebenfalls am liebsten 
. Hier ist es aber nicht ungewöhnlich, dass Geräte zumindest einen Reset-PIN haben, welcher per GPIO angesteuert werden will (und wenn es nur das Ziehen auf Low/High ist). Das ist kein Konzept nur von eQ-3. Sehr viele Lowlevel-Hardware braucht zusätzliche GPIOs - leider auch viele UART-Geräte. Mir wäre es ebenfalls lieb, wenn sich auf die GPIOs verzichten ließe . Ganz besonders werden GPIOs von I²C- und SPI-Modulen benötigt (in diesem Fall für Interrupts). Bei letzteren wäre sonst ein rechenintensives Polling notwendig.
Security muss man dann aber über device-Rechte erzwingen, daher mein Hinweis auf
chgrp gpio(und homegear in die Gruppegpioaufnehmen).
Ja, das ist der korrekte Weg.
Viele Grüße
Sathya
Ich habe den Eindruck, das Problem mit den GPIO18 wird nicht in Openhab gelöst werden. Also habe ich jetzt eine Lösung für mich gefunden, die ich hier veröffentlichen möchte, weil das Problem Raspberry PI3 oder 4 mit HM-MOD-RPI-PCB nicht nur mich plagt, sondern wohl alle, die ihr Openhab aktualisieren.
/etc/init.d/raspi-config
am Ende des start) Block vor ;; diese Zeilen einfügen
echo “18” > /sys/class/gpio/export
echo “out” > /sys/class/gpio/gpio18/direction
echo “0” > /sys/class/gpio/gpio18/value
chown homegear:homegear /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18/direction
chown homegear:homegear /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18/edge
chown homegear:homegear /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio18/value
Dann funktioniert alles auch nach einem Stromausfall wieder.
Diesem Eindruck möchte ich doch sehr widersprechen. Abgesehen davon daß du die Software openHAB fälschlicherweise mit dem Betriebssystem openHABian in einen Topf wirfst, ist das was du hier postest fast dasselbe was ich dir bereits hier, im OH-Forum und auf Github als Lösung nahegelegt habe zu tun: nämlich die access rights des/der GPIO device-Files dem User homegear zugängig zu machen.
Warum du das trotz dreimaligem Hinweis nicht einfach gemacht hast bleibt mir rätselhaft.
Deine o.g. Lösung hat allerdings Nebenwirkungen, dererwegen ich das nicht zur Nachahmung empfehlen würde: ein chown homegear ermöglicht es dem homegear User, darauf zu schreiben, richtig. Aber gleichzeitig verunmöglicht es auch jedem anderen User, darauf zuzugreifen, beispielsweise dem openhab User. D.h. mit diesen Befehlen machst du z.B. die Nutzung des GPIO bindings in openHAB kaputt, ausserdem hält sie vermutlich nur bis zum nächsten Update des homegear-Packages.
Jeder wie er mag, aber man sollte sich dem zumindest bewusst sein ehe man es implementiert.
PS: benutz beim Posten bitte richtige Anführungszeichen und code fences