Archive for the ‘Domotics’ Category

Performance versus Beauty

Wednesday, April 6th, 2011

I believe programming is an art. Just like an artisan creates an artifact, when I program I develop… and item. Although intangible (most of the time), it normally has a visual form (the application’s HMI, or Human-Machine Interface). This visual aspect should be coherent with the rest of the product, admirable, intriguing, exquisite.

Designing a good User Interface is an art in itself, one that should “connect” with the intangible part of the “machine”. When they blend, they can really amaze, entertain, inform, in a simple, natural (yet powerful) way.

My home automation is badly needing love in this area. The intangible part is coming along very well, but I really need to dedicate myself to the User Interface. I’ve made sure it is functionally quick to respond and simple to extend, but I’ve delayed the visual design a bit too much. I think I’m in a point where functionality is at a very interesting level, and as soon as I finish the element I’m working on (the air admission system, including an earth-air heat exchanger) I’ll shift to design.

I’m aiming at simplicity and usability, something not trivial to achieve when your system crosses a certain sofistication threshold.

…jumps over the lazy dog!

Thursday, February 17th, 2011

There is one part of the HMI system I did in a somewhat “lazy” way. I’m creating display objects (JFrames, charts) in memory for each of the display elements. While this ends up being a nice tradeoff between memory and speed (changing between elements is near-instantaneous), I should probably reduce the memory footprint of the HMI application.

Then again, this version has quite a lot going on (charts, threads, etc), and I should probably leave it alone and develop an alternate, slimmed-down version (to run on embedded and tablet machines). Without charts or Swing widgets, pure raster graphics, like a game. After all, I won’t need charts on every element in every control point of the home automation. Most of the time I just want an overview of the house, give some commands, check out the results, and be done with it. Quickly. If I must analyse something, the historic screen is a very capable tool.

Next up, is creating a simple, yet good Web-based interface, or at least a simple dashboard. Check out this project’s web interface, it’s really cool!

And while I’m at it, create a version of the server app without the JFrame… and a socket I can connect to to send commands (Start/Stop).

The quick brown fox…

Thursday, February 10th, 2011

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.

Onwards! 🙂

My house is growing up

Monday, February 7th, 2011

My super-secret project advances pretty well! Ok, so my home automation project is not that super secret anymore, but the progress is definitely there.

The network of nodes is working perfectely, lighting and blinds control is 100% done in terms of logic (I still need to prettify these elements visually), as are the temperature sensors. The sensors still need some low-pass-filtering, because the noise is a bit harsh for the logic I need the nodes to execute in “Emergency Mode”.

Yes. Emergency Mode. When the control machine is offline, the home automation keeps on going. The nodes, when not talked to for a few seconds, take control of their critical systems. Lights, blinds and climate control keep on going in a basic way, so that you still can control your house. You loose special control routines, like turning on lights based on motion sensing, opening blinds to harvest the sun’s heat in winter, blind positioning, earth tubes house air intake, etc, but the basic funcionality is always there.

In the beggining, this emergency mode was the mode the home automation was running in, every day. Now the control “server” is online, the system is accessible remotely, and complex control can easily be achieved.

The climate control system is now coming along nicely, including control of radiant floor valves via temperature sensors, solar hot water tank (with solid fuel boiler support), and earth tubes for the house air intake (with direct exterior air alternative).

The roadmap includes the complete security system (that is presently working but via a very quick and dirty hack, needs reimplementing) with volumetric and periferic sensors, the botanic manager (gardens, vegetable growing, fruit trees, greenhouse, etc), and meteorology center. There are a couple of very advanced (and useful) features planned, but that will be a surprise… 🙂

Stay tuned for more info!

System choices for Home Automation

Friday, November 27th, 2009

I’m studying the hardware and software for my Home Automation project, namely for the server and clients of the SCADA system. I won’t use Windows for these systems, because I need something that I can trust (and immune to viruses/trojans/attacks), and in the end it gets expensive. MacOS X and Linux comply (better at least) with that, and it’s relatively easy to find good, cheaper systems they run on.

But I’m studying how I can include Amiga-based systems on my project. The reasons for choosing an alternative system are simple:

* Lower power consumption, good for the environment.
* Supports smaller, innovative companies, good for the economy.
* Really small, efficient and fast operating systems.
* Secure (different from mainstream OSs, unexploited).
* Virus immune.
* Usually cheaper than a Windows system (the OS is payed separately, and usually needs better, more expensive hardware to perform well).

I won’t deny that the Amiga had a big impact on my life, during my childhood… a lot of what I know now was learned on an Amiga, and the Amiga community surely influenced many of my (good) choices in life. Including it’s spirit in my project can only bring good things!

As of now, my options boil down to this:

AmigaOS 4
Expensive system (~700€).
Dedicated hardware (ACube‘s SAM440ep motherboard).
Hardware available commercially today.
Good performance.
Low power consumption.
Good operating system support of the hardware.
Has SDL.
Good future perspective.
Developer: Hyperion.

Reasonable system cost (~300€).
Dedicated hardware (Genesi stuff), with support for some obsolete PowerPC G4 Macs (MacMini).
Hardware not really available, as of now only runs on obsolete systems (Efika/Pegasos/Radeon). Will certainly support the new Genesi Smarttop and Smartbook.
Good performance.
Low power consumption.
Good operating system support of the hardware (on the Efika/Pegasos at least).
Has SDL.
Good future perspective.
Developer: the MorphOS team.

AROS (Icaros Desktop)
Cheaper system (iMica: ~250€).
Generic hardware.
Hardware available, but limited operating system support of the hardware (targets old x86 hardware), although the iMica is available, and can be used to give value to old computers with lower power consumption.
Good performance.
Low power consumption.
Has SDL.
Uncertain future perspective, since it is developed by the community, with no commercial company backup (although this sometimes means nothing).
Developer: AROS community.

Normal system cost (MacMini Intel: ~500€).
Dedicated hardware (Apple stuff).
Hardware available commercially today.
Best performance.
Low power consumption (30W).
Good operating system support of the hardware.
Has SDL.
Good future perspective.
Developer: Apple.

Linux (DSL, Ubuntu, PuppyLinux, …)
Cheaper system (~300€).
Generic hardware.
Hardware available commercially today, and can also be used to give value to old hardware.
Good/Best performance.
Low power consumption (40W).
Good operating system support of the hardware.
Has SDL.
Good future perspective.
Developer: the Linux community.

Preliminary observations
It’s not easy to choose the OS by reading these facts. I took a look at AROS, but I’m yet to see AmigaOS 4.1 or MorphOS running, and using the OS is an important part for me. Also, I have to make a bit of development on the three and see wich one feels better.

My emotional side tells me AmigaOS might be the way to go, but it seems to cost more than a Mac or Linux system. From this simple comparison AROS is the best value and MorphOS (assuming it will run on the MX Open Client “Smarttop” from Genesi) is as strong a candidate… I’m eager to try them out, and I’m sure testing sessions will be lots of fun! 😉