In your home, when you touch a button, you expect the associated lamp to light immediately. For example, if you open the door to your basement, you need light right now to go down the stairs safely. Waiting a couple of seconds for the lamp to light is not expected, nor desirable. After all, the most basic and primitive lighting controls work directly on the power source, and act immediately, so when you have a state-of-the-art home automation system installed you expect the very same performance.
But, from a developer point-of-view, when you have a network of almost 20 nodes, you need to pay close attention to your data paths if you want to achieve lightning-fast response times. I’m working on the near-realtime domain, but I need to be as close as possible to real-time.
So, I’ve been finetuning my home automation’s data subsystem. I think is it of the utmost importance that the controls feel immediate, quick and nimble. And the physical controls (wall buttons) need to behave real-time, or very, very close to it. The HMI (geared towards touch panel use) needs to behave accordingly, and flow at least as fast as your mind can move your finger. That’s why I’ve developed my home automation’s HMI to be that fast.
Usability is a heavily studied subject, but a historically highly neglected one (although nowadays things seem to be improving). Thankfully I’ve had some training on the subject (and I must thank my University teacher that introduced my to the art, she was inspiring), and you can be sure it won’t be neglected.
I’ve had to tweak the data gatherer thread on the server application, adapt the nodes’ firmware, and scatter data polling in the time domain. Talking in numbers, I reached a half-second (median) response time in the physical control buttons, which seems to be perfectly acceptable. This performance is on a 500Mhz AMD K6-III CPU, 196MB RAM, still running under Windows XP. The final target machine will outperform this test-bed in every aspect (and it will not normally run Windows, but a very light Linux distro, AmigaOS, or MacOS X), so I’m quite happy with the results so far.
Obviously, I have a plan B to accelerate this even further if needs be. It involves bypassing each nodes’ polling overhead, by centralizing data in the header node and fetching in one go (asynchronously). Heck, I even have a plan C to respond in the minimum time possible, involving a full duplex protocol on the header node. Plan C will eventually get implemented (once I sort out the asynchronous communication arbitration between nodes), since it is the best way to do it.