Homegear with COC

Is there any experience, if homegear is working with the COC extension on the RasPi? It’s accessible over a serial interface like the CUL but is not an USB stick, but an extension board connected to the RasPi GPIO header (busware.de/tiki-index.php?page=COC).

I struggle to get it working. The firmware of the COC is successfully flashed (LED on COC is flashing with 1Hz).
Then I tried to startup homegear and got an error log entry, that CUL on ttyACM0 can not be connected. Changed that to ttyAMA0 and homegear starts without any further error (at least in the log).
When I now try to pair a device with the CLI to homegear, I don’t get any peers listed.

Any help or experience exchange is very appreciated.

Hey,

I have a COC somewhere here, until now I just never used or tested it with Homegear. In general it should work or it should be easy to implement it. I will check it out tomorrow and come back to you.

Cheers,

Sathya

ok, I added support for the COC to Homegear now.

In the beginning there were some problems with my COC though. I think either because of an electrical short between the Raspberry Pi and the COC (maybe where the COC touches the Micro USB port?) or because there was a loose connection on one of the header pins. So before you do anything, check if your COC works fine:

[ul]
[li] Install minicom:

[li] Reset/boot the COC:

if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi echo out > /sys/class/gpio/gpio17/direction echo out > /sys/class/gpio/gpio18/direction echo 1 > /sys/class/gpio/gpio18/value echo 0 > /sys/class/gpio/gpio17/value sleep 1 echo 1 > /sys/class/gpio/gpio17/value sleep 1[/li]
[li] Run:

[li] Now if you enter “V” (case sensitive) and press return you should see the version number of your COC:

[li] Enter “X21” press return, enter “Ar” and again press return (both commands are case sensitive again). Now press a key on a HomeMatic remote or enable pairing mode on a HomeMatic device to generate some BidCoS traffic. You should see something like this:

A0D02A0411C584C04584C011F21400E A0E02800204584C1C584C0101C800D301 A1475845E24B13E0000009A40060044F3035908E5FE00
If you see garbage (like “ÿÿÿÿÿÿÿÿÿÿÿ”), something is wrong with your COC.[/li][/ul]

Ok, when your COC is working fine, do the following:
[ul]
[li] Purge the old Homegear version, because it doesn’t support the COC:

[li] Download the testing version of Homegear and install it:

wget http://homegear.eu/downloads/homegear_0.3.0-2_armhf.deb dpkg -i homegear_0.3.0-2_armhf.deb[/li]
[li] Modify the file “physicaldevices.conf”: Comment out the “CUL” part and uncomment the COC part.[/li]
[li] Restart Homegear:

Please tell me, if it works.

Minicom tests were successfull. But after updating, changing the conf file and restarting homegear I have the following entries in the error log:

02/06/14 22:27:11.668 Error in file PhysicalDevices/PhysicalDevice.cpp line 305 in function virtual void Phy
sicalDevices::PhysicalDevice::getGPIOPath(uint32_t): Could not open directory "/sys/class/gpio/.
02/06/14 22:27:11.669 Error in file PhysicalDevices/PhysicalDevice.cpp line 231 in function virtual void Phy
sicalDevices::PhysicalDevice::openGPIO(uint32_t, bool): Failed to open value file for GPIO with index 2 and
device “coc”: Unable to retrieve path.
02/06/14 22:27:11.670 Failed to set GPIO with index “2”: Device not open.
02/06/14 22:27:11.671 Error in file PhysicalDevices/PhysicalDevice.cpp line 305 in function virtual void Phy
sicalDevices::PhysicalDevice::getGPIOPath(uint32_t): Could not open directory "/sys/class/gpio/.
02/06/14 22:27:11.671 Error in file PhysicalDevices/PhysicalDevice.cpp line 231 in function virtual void Phy
sicalDevices::PhysicalDevice::openGPIO(uint32_t, bool): Failed to open value file for GPIO with index 1 and
device “coc”: Unable to retrieve path.
02/06/14 22:27:11.672 Failed to set GPIO with index “1”: Device not open.
02/06/14 22:27:12.673 Failed to set GPIO with index “1”: Device not open.

That sounds like a permission problem, no big deal :wink:.

[ul]
[li] First check if your file “/etc/init.d/homegear” has an entry like “$DAEMON -c $CONFIGPATH -s $RUNASUSER $RUNASGROUP”. Not that for some reason the old init file didn’t get purged when you removed the old Homegear version.[/li]
[li] Then post me the output of

ls -l / | grep sys ls -l /sys | grep class ls -l /sys/class/ | grep gpio ls -l /sys/class/gpio
You can probably fix the problem by executing the following commands, but save the output first, because I want to fix the permissions from within Homegear in the future and for that I need to know, what’s wrong exactly:

chmod 755 /sys chmod 755 /sys/class chmod 755 /sys/class/gpio[/li][/ul]

Unfortunatly the entriss in the error log remain. The init script was purged and I changed the permissions as proposed.
Here is the required output (before I changed permissions):
pi@raspberrypi ~ $ ls -l / | grep sys
dr-xr-xr-x 12 root root 0 Jan 1 1970 sys
pi@raspberrypi ~ $ ls -l /sys | grep class
drwxr-xr-x 38 root root 0 Feb 5 22:11 class
pi@raspberrypi ~ $ ls -l /sys/class/ | grep gpio
drwxrwx— 2 root gpio 0 Feb 6 22:27 gpio
pi@raspberrypi ~ $ ls -l /sys/class/gpio
insgesamt 0
-rwxrwx— 1 root gpio 4096 Feb 5 22:11 export
lrwxrwxrwx 1 root gpio 0 Feb 6 22:27 gpio17 -> …/…/devices/virtual/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Feb 6 22:27 gpio18 -> …/…/devices/virtual/gpio/gpio18
lrwxrwxrwx 1 root gpio 0 Feb 5 22:11 gpio23 -> …/…/devices/virtual/gpio/gpio23
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> …/…/devices/virtual/gpio/gpiochip0
-rwxrwx— 1 root gpio 4096 Jan 1 1970 unexport

ok, the permissions on “/sys/class/gpio” were wrong. The output now should be:

ls -l /sys/class/ | grep gpio drwxr-xr-x 2 root gpio 0 Feb 6 22:27 gpio

I forgot the permissions on /sys/devices. Please again send me the output of:

ls -l /sys | grep devices ls -l /sys/devices | grep virtual ls -l /sys/devices/virtual | grep gpio

Then do the following:

chmod 755 /sys/devices chmod 755 /sys/devices/virtual chmod 755 /sys/devices/virtual/gpio

Restart your Raspberry Pi, because the GPIOs need to be exported again. Then check, if it works. If not, post the output of:

ls -l /sys/devices/virtual/gpio ls -l /sys/devices/virtual/gpio/gpio17 ls -l /sys/devices/virtual/gpio/gpio18

I hope, it works now :wink:.

In the newest Homegear version I’m adding the user “homegear” to the group “gpio”, when it exists. That should solve your problem for other people in the future :wink: .

I tried to adjust the permissions as you described, but after reboot the permissions were gone again. I investigated a bit and found the following two udev rules:
/lib/udev/rules.d/60-python-pifacecommon.rules
/lib/udev/rules.d/60-python3-pifacecommon.rules
with this statements:

KERNEL=="spidev*", GROUP="spi", MODE="0660" SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/ devices/virtual/gpio'"
After I changed the permission from 770 to 777, it worked. 775 was not sufficient. I guess with your change to add user homegear to group gpio, my changes will not be neccessary.

Great that you could fix it and good that you found the udev rules :wink:! Still funny though, that 775 didn’t work, because Homegear sets the permissions for all the files, it needs write access to. For that only read access to the directory is necessary.
Do you use the default Raspbian image from raspberrypi.org? Then I will try to check it out myself :wink:.

Yes, it’s the standard image:

pi@raspberrypi ~ $ uname -a Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux

Many thanks for your support. I can now pair my devices to homegear. My next chanllenge is now, to get it working w/ openHAB.

For that, please update to 0.3.0-3! Otherwise events are not working with openHAB (I just fixed it yesterday). Enjoy playing around :wink:.

Hi Sathya,

I’m using a Raspberry Pi with the COC Extension too. Now I installed the current version of Homegear (0.4.2) and modified the physical devices.conf file for the COC.

The current situation is:

After booting the Raspberry, there are the following output in the home gear.err file:

03/12/14 23:51:57.315 Couldn't open COC device "/dev/ttyAMA0": Permission denied
03/12/14 23:51:57.316 Critical: At least one of the physical devices could not b
e opened... Exiting...

The COC device’s LED is not blinking.

Restarting the Homegear service produces the following output.

[ ok ] Stopping Homegear: homegear.                                                                       [....] Starting Homegear: homegear03/12/14 23:54:58.793 Loading RPC server settings from /etc/homegear/rpcservers.conf
03/12/14 23:54:58.810 Loading RPC client settings from /etc/homegear/rpcclients.conf
. ok

Now the COC Extensions LED is blinking :slight_smile:

Do you have an idea what’s the problem here?

Hey Heiko,

what are the permissions on /dev/ttyAMA0 (run “ls -l /dev/ttyAMA0”) after starting Homegear? Is version 0.4.2 the first version of Homegear you installed or did you update from an old version? Please post the content of your physicaldevices.conf.
This should be easily fixed :wink:.

Cheers,

Sathya

Edit: Did you remove /dev/ttyAMA0 from /etc/inittab and /boot/cmdline.txt (see here: http://busware.de/tiki-index.php?page=COC_Installation#System)?

Thanks for you quick answer.

After booting the Raspberry the command ls -l /dev/ttyAMA0 outputs:

It was the first installation of 0.4.2 I did, but up to now I did not remove anything from /etc/inittab and /boot/cmdline.txt
I also did not flash the firmware of the COC, because I don’t know if it’s necessary.

Heiko

Now after following the instructions from http://busware.de/tiki-index.php?page=COC_Installation#System the COC LED is blinking every second and there is no more error message in the homegear.err file after rebooting.

Thanks again.

Is it necessary to flash the COC Firmware?

Great that it works now :slight_smile:! I’m not sure, if a firmware is flashed by default. But even if it is, I would compile and flash the current trunk version from sourceforge.net (http://sourceforge.net/p/culfw/code/HEAD/tree/). Only with the current trunk version you can use the new wireless firmware update.

You can see if the COC works by executing “tail -f /var/log/homegear/homegear.log”. Every received BidCoS packet should be logged.

If you have any more questions, don’t hesitate to ask :wink:.

Cheers,

Sathya