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’.
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?
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?
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 Improvements14 | 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.
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.
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:
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
Connected to Homegear (version 0.7.48-3324).
When i do “Upgrade System” from openhabian-config, no newer Version from homegear will installed.
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.
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.
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.
I had already carried out this experiment. Openhabian 3 completely new flashed on SD card and then directly installed Homegear via the Nightly Build. After that i tried all tips and hints with authorizations and further. Unfortunately, this did not lead to success either.
Thanks alot. This was the only thing acutally did the trick.
Seems to be actually an openhabian problem.
I was able to get it working fine ( tested some reboots) with this configuration added to my sudo crontab -e. I hope some lucky people find this