OUCH! This Is Not Design

This is a kind of engineering I'm trying to avoid: Window A/C Keeps Car Cool.

Feel free to peruse the Digg article for trivial criticism.

Meanwhile, instead of joining the crowd in bashing the guy (totally deserved, I must say) I'll try to be constructive and talk a little about why I claim DZ is not a hack like that.

First of all, two projects (let's call the other one The Window Hack, TWH for short, from now on) solve different tasks, though on surface they may seem to solve the same - inadequate cooling.

TWH is supposed to solve the problem of a HVAC unit, perfectly good by design, but poor by execution, that keeps breaking and sucking money. In other words, it addresses the problem of financial delinquency. With many side effects, not the least of which are the aggravation of outbound cash flow (air drag => $$$ for extra gas) and consumer safety (imagine where that box flies in case of a collision, or if it is simply torn off by the air stream at 70mph).

DZ, on the other hand, is aimed at solving a problem of inadequate HVAC design. Moreover, it solves it in a scalable way that allows to start getting immediate improvements with very little investment, and keep investing into hardware and getting tangible benefits all the way up to the sky.

First of all, you can just install the sensor network and stop right there. Analysis of what you will see may just as well allow you to make adjustments to your home infrastructure in order to bring it to your home comfort requirements.

Then, you can run DZ in passive mode and never touch the HVAC - gives the skittish ones their piece of mind and improvements in home comfort.

Or, you can just go all the way and reap the benefits.

In any case, amount of improvements you get is proportional to your invesment - would it be your time or your money.

Breaking it down to components -

You can start with adding a $10 R/C servo and little labor to get a simplistic motorized register. Like I was saying before, this solution was good enough to work for two years without any necessity to improve it.

Or, you can go for an industrial grade modulating damper - the first Google hit for such a thing that has a price listed puts it at $180.01. I suspect that the actual price will be significantly higher - usually, you have to log in to see the price, and I'm afraid that not everybody would be able to even get an account, it may be restricted to certain audience. Consequently, even that price, whatever it is, is subject to markups all the way up before you are told the final figure.

But if you want to use an industrial grade damper with DZ and can afford it - be my guest, it is not only possible, but accounted for in the system architecture. Oh, and you can have a mixed set of dampers at the same time, so you don't have to spend all that money at the same time.

Same is true for the HVAC unit - DZ can work with a crappy 30 year old HVAC (and, in fact, it did for two years) and allow you to extract significant home comfort improvements even out of that monster. But if you cough up some cash and install a state of art, multistage, variable speed unit (that'll cost you somewhere north of $10,000) - it will happily recognize the features available and will allow you to squeeze even more use out of that.

Bottom line: you get what you paid for. But, you can spend a cent at a time here and there and keep getting returns on what you spend with even minor investments - you don't need to get a loan in the bank to make that happen.

Short Take: Fractal Design

For years (I think, starting somewhere in 2000), I've been fighting my delusions of grandeur when explaining the concept of fractal design to people - I thought that obviously somebody must've thought of something this simple way before I did, and, hence, it is a common concept that I heard of somewhere and subliminally decided that I coined the term.

Apparently, not quite. Despite the fact that Google search for fractal design and fractal architecture returns more than enough matches, my patience was exhausted well before I could find anything similar to what I had in mind.

So let me put the stake in the ground, then, and introduce a definition:

Fractal Design: design pattern characterized by approximately same level of complexity at any level of abstraction.

It is a counterpoint to God Object (a.k.a. Blob), Interface Bloat, Spaghetti Code, abused Ravioli Code , Big Ball Of Mud and possibly other Antipatterns.

Starts making sense in context of Complexity Management, which, in turn, is not very well defined in the software engineering domain (this nice essay is just about the only article connecting the two), though, apparently, is widely accepted and practiced in business.

Hardware Architecture: Centralized vs. Distributed

Hardware and software are the ying and yang of what modern appliances strive to be. Evolution and oscillations of the software part of DZ is tightly coupled to choices hardware offers.

At all times, cost was the predominant factor. $99 temperature sensor is not a valid choice for someone who is most likely using a mechanical thermostat, but $3 chip probably is.

So what that it doesn't have a nice box - rich and poor are affected by extreme temperatures in strikingly similar ways, and if you can't afford to cover the chip, and you had to staple the cables to the walls instead of paying couple of thousand dollars to the crew that hides them into the walls, so be it. At least, you're comfortable now.

Same goes for professionally installed dampers vs. DIY registers.

So all right, it is clear enough that $3 chip doesn't have a human interface. All the control was initially being provided through the debug console - sure, it was limited to whoever had the password and the inclination to fiddle with it, the rest of the family had it by the way of voicing opinions and complaining (which, surprisingly, ceased pretty soon after the system was activated).

But it is crystal clear that this solution doesn't stand a chance in the long run - in order to pass the SWMBO Compliance Certification, the system must have at least rudimentary controls in each zone (provided the zone is used often enough; it is unlikely that a server room is going to require much intervention often).

Which presents quite a few interesting options.

Rudimentary controls may or may not be terminally dumb.

The dumbest possible control will include a display (two 7-segment LED is just fine) and two buttons (which actually give you more than two possible inputs: you can use "both buttons depressed" as a signal to change the control context). Plain 7-segment LEDs, though, cross the border between "cheap as in inexpensive" and "cheap as in obnoxious" - a graphical LCD won't be that expensive today, especially given the fact that it will constitute just a fraction of the total cost.

Now, what difference does it make if you have two buttons or eight? Granted, two buttons is 4 times cheaper (by themselves), but again, much less so, given the infrastructure considerations: first of all, having 8 soft keys gives you unlimited flexibility for all practical considerations, second, they won't be that much more expensive compared to the total cost.

Does the sensor have to be in the same box as the LCD and the buttons? It depends. First of all, the box has to be located where it is convenient to access it - most probably, next to the light switch. But the sensor has to be located where the actual temperature has to be measured, and that is where the complaining person is - in the bed, at the coach, next to the oven, you name it. On the other hand, the complaining persons lived with a single thermostat for all their life, so even the sensor that is in the box is already going to be an improvement. Another consideration is that this case requires less wiring (assuming it's wired; wireless solutions are a whole different can of worms).

Yet another component is the servo controller. Historically, servo controllers were always centralized - one controller, bunch of wires, servo boosters and capacitors at each servo, good enough.

Later, Nic van der Walt provided schematics for distributed 1-Wire servo controller, which would support bang/bang dampers with no problems at all, and modulating dampers that will be quite noisy - latency of 1-Wire protocol with the bunch of sensors on it is insufficient to provide software controlled quiet transition.

Today, there are chips with PWM supported in hardware, and if they have enough brains to support even the simplest quiet transition possible, then you have the distributed servo controller right there and then.

Considerations above assumed we're ignoring existing 24V dampers (which are mostly bang-bang, and regardless of whether they are or not, they're well beyond the approved spending limit for the audience) and using R/C servos to control the dampers, as shown here.

This just about concludes the story. There are three major topics left uncovered - the HVAC actuators, hardware interface selection, and making all the gadgets wireless - but the article is getting too long, so stay tuned.

Software Architecture: Centralized vs. Distributed

Evolution of software moves in mysterious ways. Especially if you're not the one contemplating it, but the one making it happen. Hindsight is always 20/20, and now that I'm looking back at the way DZ evolved, I'm seeing that I was merely trodding the same path as countless others - namely, coming all the way from monolithic single host software design to modular distributed.

Just as dinosaurs became extinct, DZ ceased to be a monolith even before it become public - the first GPL'd version was already split in several parts able to talk to each other via TCP/IP, and the parts were linked together in a modular container driven architecture.

Further down the road, the project started shedding more pieces as better versions of them arrived elsewhere (scheduler would be one example). It also became clear that as computers become smaller and cheaper, the day will come when it would be not only possible, but beneficial to utilize multiple computers for a task that could be perfectly done by just one - just for the very reason of having a particular computer in a convenient place for connecting hardware.

Most prominent examples would be -

• An HTPC which has to reside in a rigidly defined place, next to the rest of AV equipment;
• A wireless router that is a focal point of wireless and Ethernet connectivity;
• A workstation, which by itself provides several relevant data streams (CPU temperature, motherboard temperature, hard drive temperature).

Which makes distributed communications difficult to underestimate. Initially, it was just about protocols, now, it's getting all about application interoperability and plugins (Cacti, Munin, Nagios, Mister House to name a few).

Stay tuned.