nach deinstallation und Installation mit openhabian-config hat homegear immerhoin mal funktioniert. Nachdem BlueNode nicht funktioniert hat (nach login http://openhabian:2001/node-blue/signin.php kam nichts mehr) habe ich einen Rebbot gemacht und danach war homegear wieder kaputt.
Das Verzeichnis /var/run/homegear/ hat auch nur eine Datei homegear-management.pid und es fehlen die links zu den Sockets.
Was kann da schief laufen?
Genau das ist auch mein Problem 
Hat jemand vielleicht eine Antwort?
Ich habe dasselbe Problem, siehe https://forum.homegear.eu/t/verzeichnis-für-sockets-nach-reboot-manuell-anlegen/3567/6
Es scheint hier ein Problem mit openhabian vorzuliegen. Wenn ich es richtig lese - ohne eigene Erfahrung mit openhabian - ist an der Verzeichnisstruktur und den Berechtigungen irgendwas geändert worden womit homegear nicht klar kommt.
Habr ihr beim Betreuer von openhabian mal nachgefragt? @sathya, kannst du etwas sagen woran es liegen kann?
Ich hatte hier im openHABian Forum einmal nachgefragt. Bisher leider ohne Erfolg. Vielleicht helfen euch ja die Tipps? Ihr könnt ja mal berichten
Siehe hier: https://community.openhab.org/t/faulty-homegear-installation-over-openhabian-config/102765
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.
Also: service stoppen (sudo systemctl stop homegear), alles in /run/homegear/ löschen, service wieder starten.
homegear-Console nicht mehr als root starten, sondern als User openhabian.
Und mal die ganzen Dateien unterhalb /etc/homegear überprüfen, ob sie von der group homegear gelesen werden dürfen bzw. die Directories ob das x-Bit für die Gruppe gesetzt ist.
Auch mal /etc/systemd/system/homegear.service überprüfen daß dort (aus dem Kopf) User=homegear, Group=homegear, RuntimeDirectory=homegear und auch RuntimeDirectoryMode=0755 gesetzt sind.
EDIT: es gibt zwei Service-Dateien homegear.service, auf Debian einmal eine in /etc/systemd/system/, die aus openHABian stammt, und einmal die aus dem pkg in /lib/systemd/system/.
Die in /etc von openHABian hat Vorrang.
Interessant. Klingt, logisch, vielen Dank. Das werde mal demnächst durchführen, wenn ich etwas Zeit habe. Im Moment läuft mein System aber sehr gut, da lebe ich damit, dass ich die Konsole mit sudo starte. Keine Ahnung wo ich her hatte, dass das so soll.
Ich habe mal spasseshalber gegoogelt, sudo homegear -r liefert 2 Seiten Ergebnisse, homegear -r liefert 4. Da die sudo-Variante ja in der Anderen enthalten ist, meint die eine Hälfte mit, die Andere ohne sudo. 
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.