That does not exist if you properly installed via openHABian.
As you have modified the default yourself you need to fix it yourself, too.
You must not simply copy-in something that worked elsewhere. That’s not how Linux services work.
And as I said you need to fix /etc/homegear to be readable for the homegear user.
Last line is bad (you need upper case D and M)
That does not exist if you properly installed via openHABian.
As you have modified the default yourself you need to fix it yourself, too.
You must not simply copy-in something that worked elsewhere. That’s not how Linux services work.
Sorry I dont understand. I surely just installed through openhabian-config. Or what do you mean?
Can I just start the installation through openhabian-config again? To “clean” reinstall homegear if something went wrong?
No you must have done something else, restored a backup, manually started homegear as root, whatever. I don’t know.
No.
You could use apt-get purge homegear and double-check all places that it’s gone.
(I don’t know what these are, /etc/homegear and /var/log/homegear and /lib/system/system/homegear* but possibly more).
Use openHABian to install again but first switch to master branch if you have not done so yet.
And if you then restore anything from a backup or the like, you will have the same problems again as that overwrites correctly setup files/dirs so don’t do that.
A clean installation on an openhabian image does not work either 
Also it seems like I am not the only one with that problem. And it does not seem to be “my fault” I guess
Look at that thread (german)–> https://forum.homegear.eu/t/openhabian-homegear-fehler-could-not-connect-to-socket-permission-denied/3609/10
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?
This is an international forum so please use English.
Open another thread rather than to follow up on someone’s that is about a different issue.
Also follow the other rules in How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community
On your issue, if I understand correctly, you want to control your Pi’s GPIOs through homegear directly but running openHABian ?
While that might have worked in the past or not, the root cause of your problem is that you use a conceptually wrong approach. You’re apparently coming from the HM/homegear world, but openHABian is built to support openHAB, not homegear as the controller.
If you wanted to use the RPI as an acutator, i.e. control GPIO directly, you would need to use a GPIO openHAB binding.
GPIO access from OH(ian) has been unchanged in a long time so I believe it’s still working fine.
Adding homegear user to a UNIX group that has write access to GPIO devices will probably do the trick, but as I said your concept is broken and not supported in openHAB(ian).
Then in the first place you should be reading and responding to my post. But you ignored what I said there.
You must not try to setup homegear to control GPIOs. Or, if you want to do that, at least don’t use openHABian and ask for help in an openHABian forum where experts tell you this is a wrong, unsupported setup.
In what component, and what do you mean by “GPIO setup procedure”?
Stretch is ancient so lots of things changed since that was current.
What changed most recently is that homegear now runs as an ordinary user in openHABian thus no longer has access to device files.
Second, that’s what your “workaround” changes, but that’s a very bad move as it’ll exclude other users such as the openhab user from accessing GPIOs.
Please retract your “solution” as that’ll break proper usage in openHAB.
Well, I installed openHAB some years ago and just pressed the update button and this stopped working with homegear Homematic BidCos. And I am not alone as you can see in the forum here and homegear.eu.
Since I do not fully understand what is meant with GPIO openHAB binding, I tried that different approach.
I have also installed the V1.5 Buster Image openhabian-pi-raspbian-201908050414-gitca0976f-crc6a66b5a1.img.xz
sudo adduser homegear gpio
The user homegear' is already a member of gpio’.
I suppose that the GPIO binding is already installed. Additionally I installed it in the PaperGUI http://eh33:8080/paperui/index.html#/configuration/bindings
The only thing that make Stretch as well as Buster work for my setup is the old way. I am just a user, not a programmer, so any help is greatly appreciated.
It was unclear to me why you would want homegear to control GPIOs as that’s a broken concept.
After reading up in the homegear forum I think what you really want is to run a RF controller module inside the openHAB server, connected to that GPIO.
Now any properly programmed software to access a RF device would use a proper device driver and communicate over a serial interface rather than use a GPIO, and access to the serial interface would be governed by the UN*X rights system.
This is how homegear AND openHAB works with a CUL and how you should set things up with your RF module as well.
Long story short, you must not give (user) ownership of the serial or GPIO device file(s) to homegear but change them to be group owned by gpio and make it group-writable. Any user to be a member of that group will then be able to access (“openhab” and “homegear” both are members of gpio).
Having changed the access rights is an important improvement. I still wonder how we get the issue with homegear running in openHAB and getting access to BidCos RF Module resolved.
The BidCos RF Module is simply connected to the UART (RX - GPIO15, TX - GPIO14) which is provided by dtoverlay=miniuart-bt in /boot/config.txt
and the RST - GPIO18. The GPIO18 causes all the trouble. By the way the BidCos RF module is sold as extension for Raspberry Pi by Homematic, so it is not something exotic.
I tried “sudo addgroup homegear gpio” but it homegear is already member of gpio.
Is another way to access GPIO in homegear required to get openHAB compliant?
Does the homegear team know about that?
Hi,
I have opened an new thread, but I believe I have exactly the same problem. Is there now an good solution that homegear will export the reset GPIO from the RF module to be able to get this working during startup?
best regards René
Hey,
I had the same problem a couple weeks ago with the new openhabian 3 release and the CC1101 module. The simplest solution I could find was to execute echo "24" > /sys/class/gpio/export (maybe its a different pin for you) during start with a crontab. For details look at step 4.
For completeness, I wrote down all the steps I needed to get the CC1101 running with homegear und openHab 3. However, if you are using another module, you might need to make some changes in step 2 to 4, but I think the most important part is about exporting the reset pin at startup, which should be the same:
Install homgear via sudo openhabian-config. Then execute 10 | Apply Improvements 14 | Fix Permissions.
Uncomment #dtparam=spi=on in /boot/config.txt.
Uncomment the lines in /etc/homegear/families/homematicbidcos.conf below ########## TI CC1101 Module ########## the following way:
## The device family this interface is for
[TI CC1101 Module]
## Specify an unique id here to identify this device in Homegear
id = My-CC1101
## When default is set to "true" Homegear will assign this device
## to new peers.
default = true
## Options: cul, cc1100, coc, cunx, hmcfglan, hmlgw, hm-mod-rpi-pcb, homegeargateway
deviceType = cc1100
device = /dev/spidev0.0
## Default: responseDelay = 95
## Should be "95" for CUL or COC, "100" for TI CC1101 and "60" for HM-CFG-LAN or HM-LGW
responseDelay = 100
## The interrupt pin to use. "0" for GDO0 or "2" for GDO2.
## You only need to connect one of them. Specify the GPIO
## you connected the interrupt pin to below.
interruptPin = 2
## The GPIO GDO0 or GDO2 is connected to. Specify which GDO to use above.
gpio1 = 24
If you prefer to use GDO0 and pin 25, change the numbers accordingly.
Use crontab -e to open the cron task list and add the line @reboot echo "24" > /sys/class/gpio/export (or change to the pin number you need). Safe and shutdown the system with sudo shutdown -h now.
Disconnect power. If you haven’t done it already, connect SPI pins of the CC1101 with the ones of the RPi. Connect homematicbidcos.conf the CC1011 pin GDO2(GDO0) with RPi GPIO pin 24(25).
Reconnect power to the RPi.
I don’t know if its 100% guaranteed that the cron task will be executed before the start of homegear, but during the testing I did so far, it always worked.
Hi,
thanks for your advice. That will work for sure. I have tested Yesterday the official homegear image with the same setup for the busware CCD. Here the gpios are exported as configured in the homematicbidcos.conf during startup of the homegear service. Somehow the service is not able to do this in the openhabian image. From my point of view the best way would be to fix this in the openhabian as it was also working in the openhabian stretch image which i was using before.
Until now I receive teh following failure because the needed GPIO17 and GPIO18 are not exported.
01/24/21 15:21:21.119 Module HomeMatic BidCoS: COC “My-CCD2”: Error in file PhysicalInterfaces/COC.cpp line 183 in function virtual void BidCoS::COC::startListening(): Failed to open value file for GPIO with index 2 and device “coc”: Unable to retrieve path.
best regards René
Hi all,
I’m desperate right now and can’t get it with all the hints and tips. I can’t get openhabian3 to work with homgear on a raspberry 4.
Before I post all my attempts and further information, I might post a question in advance.
If I flash the openhabian image on the sd card and then install homegear via openhabian-config under optional components, then homgear -r initialy works.
But version 7 … of homegear is installed. That’s why I used this script manually for an update:
wget -O /tmp/InstallNightly.sh https://downloads.homegear.eu/InstallNightly.sh && bash /tmp/InstallNightly.sh
Was that a mistake?
How do I manage to install the current 8 … version of homegear via openhabian-config?
Very dear thanks
Greetings
Christian
Check the repo, if it looks like this it should install homegear 8.
openhabian@openhab:~ $ cat /etc/apt/sources.list.d/homegear.list
deb https://apt.homegear.eu/Raspbian/ buster/
openhabian@openhabian:/ $ cat /etc/apt/sources.list.d/homegear.list
deb https://apt.homegear.eu/Raspbian/ buster/
It looks good for me.
but actually an old versrion 7 is installed
homegear -r
Connected to Homegear (version 0.7.48-3324).
When i do “Upgrade System” from openhabian-config, no newer Version from homegear will installed.
sudo openhabian-config
2021-02-24_09:26:46_CET [openHABian] Checking for root privileges… OK
2021-02-24_09:26:46_CET [openHABian] Loading configuration file ‘/etc/openhabian.conf’… OK
2021-02-24_09:26:46_CET [openHABian] openHABian configuration tool version: [main]patchday-20210118-1221(c1919f7)
2021-02-24_09:26:47_CET [openHABian] Checking for changes in origin branch main… OK
2021-02-24_09:26:48_CET [openHABian] Switching to branch main… OK
2021-02-24_09:27:28_CET [openHABian] Updating Linux package information… OK
Reading package lists… DoneHABian] Updating repositories and upgrading installed packages…
Building dependency tree
Reading state information… Done
Calculating upgrade… Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
OK
that is the latest/greatest version that is available in the repo.
You can go directly to https://apt.homegear.eu/Raspbian/buster/ and check it.
Right, I was mistaken because I had the nightly 0.8 on my dev machine I used to look it up so thought it originated from the repo.
So you cannot install 0.8 via openhabian-config unless that becomes part of the official repo.
You can reinstall the latest stable 0.7 via apt-get install --reinstall homegear.
Ok, i understand.
Then my plan will probably not work. I currently have homegear version 8 … running on a raspi 3 with openhabian 2.5.
Now I wanted to install openhabian 3 on a Raspi 4 from scratch with homegear 8 … that I can take over my data from the raspi 3 with a backup and restore for homegear.
I’ve tried many things in the meantime. But even with all the information and tips, I don’t find a way to get openhabian 3 to run on a Raspberry 4 with the nightly build from Homegear with version 8.
I would be really interested if someone has this running in combination.
Raspberry Pi4 B 4GB with the latest openhabian 3 version and homegear 8 …
I can’t get Homgear to work in that combination.
First: I do not have homegear so my answer is more from theoretical point of view …
As far as I understand your description you installed version 7 via repo and then you installed version 8 from the nightly builds.
They might interfere. This is why I think you bettter deinstall version 7 before installing version 8.