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.
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.
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:
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 .
[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:
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 .
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 ! 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 .
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
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 .
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.
Great that it works now ! 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 .
.