Open source cross platform automation app

jfath

New Member
I wanted to switch to Linux on my home automation PC and AV server, but needed an application like Girder to tie everything together. I wasn't able to find something I liked, so I've been developing my own. It currently runs on Linux and Windows.

http://iox.sourceforge.net/

I have an Insteon dev kit on order and wondered if anyone knows of sample Linux source I might use as a base for the plugin?

Thanks.

jfath
 
Cool! Looks like a very nice start.

I have GPL'd code at http://www.bobsplace.com/ilinks/ that you can look at. It uses a kernel level driver to send/receive bytes to the USB version of the INSTEON PLC. However, I tried to make it so that the actual INSTEON message handling code is well separated from the basic communication layer. There is code there to build my applications using libusb instead of the kernel driver but it's a lot slower using libusb.
 
I don't know anything about this stuff but wouldn't MisterHouse count as open source and cross platform? (I think it is written in PERL)
 
bpwwer
Thanks, Bob! Your code will be very helpful. Nice looking app too.

upstatemike
Yes, MisterHouse qualifies as open source and cross platform. I found other
solutions, but nothing I *liked*. Purely personal preference. I'm not a big
fan of Perl and I wanted something with a Girder look and feel.

jfath
 
jfath said:
I'm not a big fan of Perl and I wanted something with a Girder look and feel.

jfath
Cool. I can't make heads or tails of MisterHouse but your app looks pretty usable. Is there a generic ASCII interface for rules based on text input?
 
upstatemike
The interface for ASCII input would depend on where the text comes from. There is a serial plugin that can be used to trigger events based on arbitrary text on a serial port. There's also a TCP/IP plugin that can trigger on arbitrary text received on a socket.

If you just want to type an event string and send it, the TCPComm plugin includes an application called ioxevent that will send any text you want to type to IOX as an event string.

If you had something else in mind, drop me an email and let me know what you'd like to see. I'm working on plugins for Insteon, IRTrans, and Windows messages at the moment, but I'm interested in what else people want/need.

Jerry
 
I think Virtual Weather Station support is a "no brainer" for any HA software package. All you need to do is designate the location of the .csv file. then go out once per second and parse out the individual values and load them into variables in your system. Intant support for most any brand of weather station and lets you trigger off things like high wnd levels or high humidity.
 
jfath said:
I'm working on plugins for Insteon, IRTrans, and Windows messages at the moment, but I'm interested in what else people want/need.
Great job, I currently use Misterhouse and while I fully believe that you can do almost anything with it, the learning curve is very steep. It's for that reason that I tried HouseBot, but missed the Linux platform and have since decided to stick with Misterhosue and work on developing my own package. Mine has similar goals to yours, although you are much further along than I as I'm still in the conceptual phase. Mine is/was primarily going to be Python based with c++ and/or mono modules for hardware interfaces. Some project objectives are listed below:
  • Code in Python mainly and C++ where necessary (drivers, etc.)
  • AXAX techniques for the web-based interface.
  • xAP, xPL
  • CQC/MainLobby/Housebot/Xlobby style interface for some touchpad eye-candy - but it would have to be Linux/BSD-based (maybe tk or mono here). Would probably start using Xlobby and xAP/xPL while developing a *nix-based solution
  • A web service the exposes the HA system for connecting the above user interfaces and any others that might come along
  • Linux (Probably Ubuntu) for development but had also thought about *BSD for its insane stability.
  • “Real†database backend (MYSQL, Postgres)
  • X-10 support (thinking WiSH)
  • Insteon support (Neil Cherry's driver when complete)
  • 1-wire (thinking OWFS)
  • Generic hardware-based I/O boards (SeaLevel, HobbyBoards, etc)
  • Interrupt driven interfaces (polling/event based is okay in user-land)
  • Threaded (must-have)
  • Modular (Python’s an easy fit here)
  • Distributable (One machine for everything or spread out among multiple, user’s choice)
All of that being said; Are you considering any type of scripting support for your app (Python, Perl, Ruby, etc.)? I'd also like to hear your (and anyone else’s) thoughts on the list above

Terry
 
Terry,

Thanks for the input. You've obviously put a lot of thought into your design. I agree with many/most of your goals, but I've made some compromises to ease development and meet my cross platform goal.

My application already has an embedded Lua interpreter. It is currently only used for evaluating conditional branch statements within rules, but my to-do list includes exposing the interpreter through a plugin. This will actually be fairly trivial and should be included in the next major update within a few weeks.

I also did some work on another SourceForge project called wxScript which provides a consistent scripting interface from a C++ app to Python, Perl, Lua, UnderC, and CINT. I plan to provide Python and Perl scripting capabilities using wxScript, but that may be a little further down the road.

Jerry
 
Back
Top