What core features do you want in HA software?

[garbled]

I've begun writing a home automation system from scratch, which will be released in open source form for UNIX.  At least initially, it will be very much a "power-user" type system, with no GUI, but a framework for people to write thier own control code.  It will also be the basis for my own home automation system, so I'm building it hand-in-hand with my hardware install.
 
Along those lines, I have lots of ideas of how I want to use it, and the things I want it to do, but I'd really like to know what things other people want thier ha software to do.  I'm less interested in "nice" features, like GUI, or ease of use, and more interested in how you want the devices to react to eachother or people.
 
I would really love to hear some thoughts from people about that.  Is there a specific way you wish one device could react to another, or a situation?  Do you have an existing HA setup that you think is pretty slick, and could describe how some of the devices operate/react to situations?  I'm kind of looking for an idea dump, just so I can try to cover more use-cases than my own in the initial design.  I'd hate to finish it and discover that it's only useful to me.
 
Tim

 

[BraveSirRobbin]

Not to discourage you, but I think you will find this endeavor is a lot more involved if you want to design it for the masses.
 
You are not going to concentrate on the GUI; but, this is one of the most important features in implementing a HA system, especially if a WAF is involved!
 
Also, a phone interface is a must as well.
 
The other problem is in the massive amount of hardware that is in use.  I know for my system I need the following hardware to be operational with my system:
 
Elk M1 (with E-Net Interface)
Ocelot (with input and output expansion modules)
Davis Weather Station
X-10
Z-Wave
PH Anderson Analog to DIgital Converter
NetCallerID Device
WGL 800 RF Receiver
 
Others will have items such as:
Russound, Nuvo, others music/audio distribution hardare
Insteon and UPB interfaces
Caddx and others security systems
SageTV interface
Sprinkler Controllers (WGL, etc...)
One-Wire Sensors
Power Monitoring (Brultech, etc...)
 
And these are off the top of my head.
 
But, to answer your question, the home automation software I currently use (HomeSeer) lets me do integration such as:
 
Voice announcements for calls coming in (plus send an email) and events such as garbage night (will keep announcing on the half hour past 7:30 PM until is 'sees' the side gate open, noting that I indeed took the can out to the street).
 
Don't water the lawn if the wind speed is to high, also provide a log of on/off times per zone (others will want a wetness sensor for logic with their controllers)
 
Email a front door camera snapshot when the doorbell rings.
 
Turn on indoor cameras on an alarm condition
 
Close garage door and lock front gate if opened when armed in stay mode.
 
Automatically close garage door if armed in stay after so many minutes pass by and the door is still opened (flash lights on and chirp siren before actually closing the door also for a warning)
 
Brighten the side house light when the side garage door is opened and dim when closed if dusk.
 
Washer and dryer monitor announcements.
 
Other forum members are doing some additional cool events that are more complicated than the above as well.
 
I would love to incorporate graphs of various analog events as well such as humidity, temperature, eventually want power monitoring etc...

 

[garbled]

I don't think I want to really design it for the masses.  What I want is to build kind of a power-user system, where people willing to "roll thier own" don't have to roll nearly as much as I am doing.  I'm horrible at making GUI's and almost equally horrible at using them.
 
The list you provided is great.  Those kind of interactions are exactly what I'm looking for.  It really helps me to see real world examples, so I can think about how my system would handle them.  Even if I don't have the hardware, the engine needs to be able to react appropriately if the drivers were to be written.
 
How do you do washer/dryer monitoring?  Monitor the load on the circuit?

 

[BraveSirRobbin]

How do you do washer/dryer monitoring?  Monitor the load on the circuit?

 
Look to our portal on many ways to do this (here are a few example links below).  We also have a LOT of How-To guides on other items of interest for the HA DIY as well!
 
http://cocoontech.com/forums/page/articles/_/tutorials/home-automation-tutorials/how-to-monitor-the-status-of-your-appliances-using-current-sensors-r58
 
http://cocoontech.com/forums/page/articles/_/tutorials/home-automation-tutorials/how-to-monitor-the-status-of-a-device-using-its-status-light-r37
 
http://cocoontech.com/forums/page/articles/_/tutorials/home-automation-tutorials/how-to-monitor-a-washers-cycle-r14
 
http://cocoontech.com/forums/page/articles/_/tutorials/home-automation-tutorials/how-to-remotely-monitor-an-appliance-r406
 
http://cocoontech.com/forums/page/articles/_/tutorials/home-automation-tutorials/how-to-monitor-the-status-of-an-appliance-using-x-10-r11
 
TUTORIALS
 
GUIDES

 

[roussell]

I don't mean to discourage you, but what not contribute to one of the on-going projects like openremote or domotiga or one of the others? These are two examples of robust frameworks that mostly suffer from lack of interfaces and contributors. IMHO It seems as though efforts spent in this space would be best suited focusing on bolstering already strong contenders rather than more fragmentation.

 

[garbled]

I actually spent quite awhile looking for one that would suit my needs, as I would much rather start from a working base, than go at it from scratch.  However, most of the ones I looked at were either not as open source as I would like them to be, or were written in some language I don't know, so I couldn't do anything with them anyhow.
 
openremote looks pretty slick, but it's written in Java, and I am not a fan of java.
domotiga actually looks *really* nice, but it's written in some crazy visual basic thing.
misterhouse has a ton of features really, and it's close, but the whole thing is published as this giant tarball of hacks.   I could probably get it working for what I want, but I suspect it would take me the same amount of time to figure it out, as it would for me to write one from scratch.
There was one on the cocoontech site named aziz or something, that actually looked *really* good, but the author doesn't publish the code anywhere, and wouldn't respond to any emails about it.
 
The thing about contributing to opensource is, you actually have to know the language the program is written in.   Lots of people probably won't like the language I wrote mine in, but those are the ones I like, so thats how it goes. 

 

[roussell]

So what language are you going to use?

 

[garbled]

The core engine is written in C.  The drivers for each device (insteon, one wire, etc) can be written in any language.  I'll probably write most of the drivers that I implement in C, because it's easier for me.
 
The core engine basically talks to separate processes, or "collectors", for each device or set of devices.  The collectors handle dealing with the device, and the core engine tells them what to do, and they tell the core what happened.  If you want to write special code for a device, you just write an external script/program/whatever and the core engine will call it.  So for example, if you wanted to write something like "if the temperature in room A is >82 degrees, turn on fan X", you can write that handler in any language you want, make it an executable, and the core engine will call it, and just do whatever it said to do.
 
My idea, is that the core engine is pretty simple, so most users/developers would never need to actually touch the code for it.  They can just write handling scripts and driver/collectors in whatever language pleases them.  It solves some problems, and creates others.  If you like writing in python, thats great, write your handlers in python.  However, if an existing handler you want to modify is written in C, you are kinda stuck dealing with it, or writing a new one.  It's basically meant to be rediculously customizable to whatever your personal preferences are, assuming you are willing to write the code for it.  Want a mysql backend?  Write one, and tell the core about it.

 

[Dean Roddey]

The gotcha with that sort of scheme is that, one day, you'll decide it's time to do V2, and you'll want to fix all the things you didn't get right first time out due to lack of experience slash foresight slash time. But, because of the looseness of the system, and the fact that anyone can extend it in any way, you may find that you have created a giant house of cards that cannot be changed significantly without bring it down. The tighter it is, and the more the means of extension is restricted, though it may seem like a bad thing now, long term you'll thank yourself because it'll bring the 'points of contact' down to a vastly small range that can be dealt with more reasonably. If you don't do that, you'll likely either end up stuck or dragging an enormous ball of evolutionary baggage behind you that just gets bigger and bigger. It's all of the problems of a large, multi-developer project, without hardly any of the tight controls and coordination that help keep it manageable over time.
 
Anyhoo, just a warning from your future...