Compiling homegear on a raspiII

The desctiption for compiling in the wiki seems to describe compiling the older monolythical homegear and not the new modular version.

I tried to guess how to compile but failed.

What I did was:

  • download and extract Homegear, lib-homegear-base, Homegear-HomeMaticBidCoS and Homegear-HomeMaticBidCoS
  • confugre, make, make install of lib-homegear-base
  • confugre, make of lib-homegear-base Homegear-HomeMaticBidCoS whicht then fails

Question 1:
What is the right order to compile and install the modules?

Question 2:
How do the modules find references to their other parts? Is it sufficient to install the different parts or do I need to tell configure the path to them?

Cu,
Markus

Hello Markus,

I definitely need to update the Wiki…

You need one package from the Homegear repository: libphp7-homegear. That is probably the reason for your compilation error. Just install it using “apt-get” after adding the Homegear repository.

  1. Only if you want to compile Homegear by yourself: libphp7-homegear
  2. libhomegear-base (required by all other parts)
  3. Homegear
  4. Modules

It is sufficient to install libphp7-homegear and libhomegear-base. The make script puts all necessary files into directories where the other parts can find them.

Cheers,

Sathya

I added

to /etc/apt/sources.list.d/homegear.list
but apt-get install libphp7-homegear does not work (cannot find package).

I am using a “plain” Raspbian Wheezy.

Regards,

-oli-

The package seems to be php7-homegear-dev:

apt-get install php7-homegear-dev

Thanks!

apt-get install php7-homegear-devworked for me.

Now, I needed to regenerate the “configure” Scripts with aclocal && autoheader && automake --add-missing && autoconf (in each of the module directories) as “install-sh” was not found.
Now I do:

cd libhomegear-base ./configure make sudo make install cd ../Homegear ./configure make cd ../Homegear-HomaticBidCoS ./configure make which fails because of the include directive

So I replaced it with

#include "homegear-base/BaseLib.h" by using

find \( -name \*.cpp -or -name \*.h \) -print0 | xargs -0 sed -i.bak -e's#../homegear-base/#homegear-base/#g'

I will continue to report on my attempts to compile Homegear…

Regards,

-oli-

Hey,

Hups :blush:. True.

Did you manage to compile it now? I replaced all “…/homegear-base” now, too. That was the old directory. I didn’t notice, because for some reason compilation works here…

Cheers,

Sathya

Yes. And it’s up and running, but only because I disconnected the connection between CC1101 and GPIO during start up. :frowning:

I left config (all under /etc/homegear/) and DB like it was from my previous Homegear installation with apt-get (and replaced the homegear binary and the modules).

Now during startup I get:

11/09/15 21:59:53.336 Error: Failed to export GPIO with index 2 for device "cc1100": GPIO not defined in physicel devices' settings.
11/09/15 21:59:53.336 Error: Failed to export GPIO with index 2 for device "cc1100": GPIO not defined in physicel devices' settings.
11/09/15 21:59:53.338 Error: Could not setup GPIO for device cc1100: GPIO path for index 2 is not set.
11/09/15 21:59:53.338 Error: Could not setup GPIO for device cc1100: GPIO path for index 2 is not set.
11/09/15 21:59:53.339 Failed to set direction for GPIO with index "2": GPIO not defined in physicel devices' settings.
11/09/15 21:59:53.339 Failed to set direction for GPIO with index "2": GPIO not defined in physicel devices' settings.

Has the format of the config files (especially physicalinterfaces.conf) changed?

I am using the Pollin module with this configuration:

#######################################
########## TI CC1101 Module  ##########
#######################################

# The device family this interface is for
[HomeMaticBidCoS]

# 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, cuno, hmcfglan, hmlgw
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 = 0

## The GPIO GDO0 or GDO2 is connected to. Specify which GDO to use above.
gpio1 = 18

Any hints?

Regards,

-oli-

Hey oli,

my mistake. I indeed changed the physicalinterfaces.conf, because we added support for the TI CC1190. I will fix that tomorrow. For the time being set “gpio2 = ANY_FREE_GPIO” and “txPowerSetting = 0xC2”. That should work.

Cheers,

Sathya

Hi Sathya,

adding the 2 lines to physicalinterfaces.conf made the errors disappear. Thank you!

However, the version I compiled does not fix my initial problem (activating interrupt pin after disabling the 135kHz Signal on GDO0).
More on this issue (soon) on the original thread here.

BUT you should rethink which generated artifacts of the autoconf toolchain you submit to the repository.
As already written, the configure scripts didn’t word out-of-the-box (i.e. out of the github repo), so I needed to regenerate them (aclocal && autoheader && automake --add-missing && autoconf).
This results in that I cannot pull from your Github repo because the changes that took place on the source tree (either by the autoconf/automake stuff or by gcc dependency generation):

Updating 9e73df0..700b4b0
error: Your local changes to the following files would be overwritten by merge:
        Makefile
        config.h
        config.status
        configure
        homegear-miscellaneous/src/.deps/Factory.Plo
        homegear-miscellaneous/src/.deps/GD.Plo
        homegear-miscellaneous/src/.deps/MiscDevice.Plo
        homegear-miscellaneous/src/.deps/MiscPeer.Plo
        homegear-miscellaneous/src/.deps/Miscellaneous.Plo
        homegear-miscellaneous/src/LogicalDevices/.deps/MiscCentral.Plo
        homegear-miscellaneous/src/Makefile
        homegear-miscellaneous/src/Makefile.in
        libtool
        src/.deps/main.Po
        src/CLI/.deps/CLIClient.Po
        src/CLI/.deps/CLIServer.Po
        src/Database/.deps/SQLite3.Po
        src/Events/.deps/EventHandler.Po
        src/GD/.deps/GD.Po
        src/MQTT/.deps/Mqtt.Po
        src/MQTT/.deps/MqttSettings.Po
        src/Makefile
        src/Makefile.in
        src/RPC/.deps/Auth.Po
        src/RPC/.deps/Client.Po
        src/RPC/.deps/ClientSettings.Po
        src/RPC/.deps/RPCMethod.Po
        src/RPC/.deps/RPCMethods.Po
        src/RPC/.deps/RPCServer.Po
        src/RPC/.deps/RemoteRpcServer.Po
        src/RPC/.deps/RpcClient.Po
        src/RPC/.deps/Server.Po
        src/RPC/.deps/Webserver.Po
        src/ScriptEngine/.deps/libscriptengine_a-PhpEvents.Po
        src/ScriptEngine/.deps/libscriptengine_a-PhpVariableConverter.Po
        src/ScriptEngine/.deps/libscriptengine_a-ScriptEngine.Po
        src/ScriptEngine/.deps/libscriptengine_a-php_sapi.Po
        src/Systems/.deps/DatabaseController.Po
        src/Systems/.deps/FamilyController.Po
        src/Systems/.deps/PhysicalInterfaces.Po
        src/UPnP/.deps/UPnP.Po
        src/User/.deps/User.Po
Please, commit your changes or stash them before you can merge.
Aborting

Unfortunately I cannot provide you good knowledge of autoconf/automake (there may be better build tools available today, like cmake), but I think it is common among open source projects that you supply a configure script that runs without missing local files (like install-sh) and there are no generated artifacts like dependencies generated by gcc, Makefiles generated by configure script etc. in the repository’s source tree.

What do you think about it?

Regards,

-oli-

Hey Oli,

Very true… I removed all automatically generated autotools files and added “autogen.sh”. What do you think now?

Regards,

Sathya

It seems to work, but it is not recommended (by the authors of autoconf/automake)
a) to run ./configure from autogen.sh (see e.g. https://www.sourceware.org/autobook/autobook/autobook_43.html),
b) to call the script “autogen.sh” (they prefer “bootstrap”, see e.g. https://www.gnu.org/software/automake/faq/autotools-faq.html#What-does-_002e_002fbootstrap-or-_002e_002fautogen_002esh-do_003f),
c) to use autoreconf due to the missing “–add-missing” option (see e.g. https://www.sourceware.org/autobook/autobook/autobook_43.html).

As far as I understand the “autotools philosophy” the autogen.sh or bootstrap script should prepare everything to enable someone who uses the source distribution to run the configure script.

Regards,

-oli-

Hey Oli,

thanks for reading into this :slight_smile:! I will change the name from autogen.sh to bootstrap then :wink:, remove the configure and won’t use autoreconf.

Cheers,

Sathya

Edit: For the time being I will keep autogen.sh AND bootstrap until I recreated the Docker build images. When the new images are online I will remove autogen.sh.