I am now going to break a core rule when building a system. I am going to pick a tool before I have written my use cases. I can get away with it since I have written a complete home automation system. However, as a rule even then I would rather focus on features, feature sets and use cases before formulating architecture and choosing technology.
So what technologies and tools should be used to build an automation system that could handle a home like this? Let’s review the salient facts:
- Reliable
- Performant
- Dynamic User Interface
- Multiple Control Systems
- Extensible
Now a lot of people would say use LAMP (Linux, Apache, MySQL, and PHP). After all Linux architecture is cheap and reliable. The problem in my opinion is the development tools suck. And well PHP may be great for web pages but as a control system we need something a little faster. That leaves a couple of options Java or .Net.
Now you might say how neither one is going to be performant enough. However, I would say that either is more than fast enough. In fact, the devices are the limiting factor not the PC or a PC based control system.
Here is a real life example. The system I did for Intuitive Homes was written to run on Win2k backend with various clients including XP touch panels. The architecture originally was Flash front end talking to a socket server written in C#. The socket server translated commands from Flash into web service calls and forwarded any status changes to the Flash client.
Click image to enlarge.
To turn a light from a touch panel:
- Touch Button
- Flash builds command to turn off light
- Flash Sends command and now ready to accept new command
- Socket Server receives command
- Socket Server interprets command
- Makes call to web service
- Web method figures out what control system adapter to pass actual method implementation
- Premise adapter gets light using MiniBroker
- Premise adapter tells light to turn off
- Premise script sees light change and build message for MSMQ
- Premise script sends message to MSMQ
- MSMQ Router reads new message
- MSMQ Router puts message on event log queue and socket server queue
- MSMQ at its leisure reads the event log queue and posts event into database
- Socket Server receives message from queue
- Interprets message header and sends message to subscribed clients
- Flash client receives message and changes light state to on or off
Without going into too much detail that is a lot of code and communication going on. This occurs within a second. In fact some subsystems could not process commands as fast as we could spew them out. So for example using Lutron HomeWorks and RadioRA the lights across a retrofitted home took almost a minute to turn completely off due to command latency across 4 RadioRA systems. That is a lot of light!
So my point is most modern semi-compiled languages (Java, C#, VB.Net and VB) are going to be more than fast enough. I would give the advantage to C# and VB.Net since you can pre-JIT the code. So there is no performance hit for JITing.
In addition, the new version of .Net (2.0) with language extensions like generics and improved performance makes it ideal. Add on top of that Visual Studio which has to be the most productive IDE I have used and HAS can be built fairly quickly.
Another item to look at is Flash. I would replace it. With today’s browser improvements and AJAX the notion of a completely dynamic runtime UI is possible. The UI renders will send a tailored UI that runs in the browser making Web Service calls using HTTPClient. This will allow for a dynamic low resource demands on the server without the need to write a custom socket server which could be a source of failure. IIS is pretty robust after years of development. In addition with Atlas coming out and AJAX.Net available it should be much easier to write a UI since Flash is really not a programming tool.
And if you do not think Windows is reliable then use Mono and Linux. So with .Net I get the best of all worlds: productive IDE, reliable modern language and framework, and cross platform support.
