Compiling Altsteon to run on Raspberry Pi

Other Devices & Integrations More Home Control
#1

I just downloaded the source code from SF to the raspberry pi and I keep getting this error:

config.status: error: cannot find input file: `Makefile.in'

I did a “touch Makefile.in” and it is successful, but the make does not work.

Can someone help me out to get this compiled on the rapsberry pi?

#2

Incase anyone else runs into this, I figured it out. I needed to have automake.

So the steps would be:

Make sure you can compile and build:

sudo apt-get update sudo apt-get install build-essential sudo apt-get install automake sudo apt-get install git

Get the code:

git clone git://git.code.sf.net/p/altsteon/code altsteon-code

Compile the code:

cd altsteon-code/ cd altsteon-daemon/ automake --add-missing ./configure make make install

At that point, the altsteon binaries are installed and executable.

When you execute on a separate system make sure to use the -r flag. I did not have to specify a port inside of vera, just the ip address of the raspberry pi.

#3

I have a number of Pis around doing simple stuff and love them. Out of curiosity, what would be the advantage of running Altsteon on the Pi vs on the Vera?

I like the idea of a semi-self contained box (i.e. running Altsteon on the vera), but curious if there is a performance consequence and that’s why the Pi idea was being pursued.

Gerry

#4

The best reason for running on the pi vs vera is you can make changes, and then compile it yourself to test.

Cross-compiling for Vera isn’t as easy. I did all the steps necessary, and no dice.

#5

Gerry,

I had some performance issues and felt like taking load off of the vera would be good. Since I had the raspberry already running, I thought it would be a good thing to utilize.

Adam

#6

I’m getting the same error, but did not get it to compile on my ubuntu server.

I ran the commands you suggested, installing automake and ran:

automake --add-missing ./configure make

I get a warning on automake about version differences, then a warning about depreciated functions. ./configure throws no errors, but there is nothing to make…

Any help would be appreciated.

Full console:

~/altsteon-code/altsteon-daemon$ automake --add-missing configure.ac:6: error: version mismatch. This is Automake 1.14.1, configure.ac:6: but the definition used by this AM_INIT_AUTOMAKE configure.ac:6: comes from Automake 1.11.6. You should recreate configure.ac:6: aclocal.m4 with aclocal and run automake again. configure.ac:6: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged. configure.ac:6: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead, configure.ac:6: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files. ~/altsteon-code/altsteon-daemon$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for g++... g++ checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of g++... gcc3 checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for unistd.h... (cached) yes checking for size_t... yes checking for memset... yes checking for socket... yes checking for strdup... yes checking for strstr... yes configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating src/tests/Makefile config.status: creating tools/Makefile config.status: creating tools/cli/Makefile config.status: executing depfiles commands ~/altsteon-code/altsteon-daemon$ make make: *** No targets. Stop.

#7

Of course, as soon as I post this message, I figured it out. I had to run aclocal, then all was as instructed.

#8

Can you provide what you ran? I will add it to the post above.

#9

aclocal
automake --add-missing
./configure
make
make install

#10

So do you use Vera to control the devices and scenes with Insteon products or is there a separate interface that you have to access on the Pi? I’m using that Vera Insteon on the Edge, but with only one USB port I wouldn’t mind off-loading it to a Pi, but wasn’t sure how to manage multiple controllers.

#11

Not totally following your sentence, but I think you are saying that you are using Vera’s implementation of Insteon? If so, Altsteon has not worked for me on the Edge. If you have gotten it working, I’d like to know how, but in the meantime, I use a Vera Lite with UI5 and it talks to the Raspberry Pi. I use vera to control the devices from Altsteon.

Has Altsteon worked for anyone else?

#12

I know there were some problems with Altsteon causing UI7 to restart. Has anyone tried running the Altsteon binaries on a Raspberry Pi with UI7?

I just got my hands on a Raspberry PI so I’ll give it a try this week.

#13

Did you get it working?

That is how I tried getting it to work and it isn’t the binarys that are an issue. It is the plugins that are an issue.

#14

[quote=“airedale, post:2, topic:181643”]Incase anyone else runs into this, I figured it out. I needed to have automake.

So the steps would be:

Make sure you can compile and build:

sudo apt-get update sudo apt-get install build-essential sudo apt-get install automake sudo apt-get install git

Get the code:

git clone git://git.code.sf.net/p/altsteon/code altsteon-code

Compile the code:

cd altsteon-code/ cd altsteon-daemon/ automake --add-missing ./configure make make install

At that point, the altsteon binaries are installed and executable.

When you execute on a separate system make sure to use the -r flag. I did not have to specify a port inside of vera, just the ip address of the raspberry pi.[/quote]

Ok, this helped a lot. I had to run “make install” as su because it didn’t have permission to write to /usr/local/sbin.

Then you have to run “altsteon -r” to allow remote connections from the Vera, I spun my wheels on that for a few minutes too. (even though you pointed that out, I missed it)

I’m still on UI5 right now and it works fine with the PI. I have another Vera that I’m going to install UI7 on and see if it works.

#15

Glad it helped! Let us know if you get it working on UI7.

#16

I did get it working on ui7, see my other post :slight_smile:

http://forum.micasaverde.com/index.php/topic,31199.0.html

#17

Sweet!

#18

Did you get a chance to try it? I was hoping that someone else could confirm my results.