Code repository has been migrated to Subversion

SVN repository (including all historical commits, tags and branches) is now active.
CVS repository will no longer be used - but still available for archival purposes.

Who Needs A Thermostat?

I've been pondering about this question for a long, long time - starting in about 2001 when the only way to control DZ available was a debug panel, and last time in an essay about SWMBO Compliance Certification (Squeezebox is still a good candidate), but it seems that there's been a new development that might if not put an end to the fruitless search, then significantly widen the options available.

I'm talking about Android.

It remains to be seen how viable the platform is and how many hardware manufactures will jump on the bandwagon. But for now - having worked on different Google APIs (Checkout and Calendar in particular) I can say that it's sure going to be a hell of a fun ride, and I'm about to get busy installing the Android SDK and tinkering with it to see how well can a user interface for a HVAC system work on a cell phone.

Now, who needs a thermostat on the wall, really?

SketchUp + HVAC-CALC, part 3

(part 1)
(part 2)

Now, Official Google SketchUp blog reports that the beta version is available for download.

Hurry before they change their mind.

Google Calendar as external scheduler for DZ???

Just thinking aloud - would using Google Calendar API be a gross overkill or actually a smart idea?

Let me see...

• Unlimited number of zones supported...
• Unlimited number of periods scheduled...
• Arbitrarily flexible scheduling - you want 5+2? We have it. You want 5+1+1? We have it. You want 7-Day? we have it, too.
• Accessible from Internet...
• Accessible from your mobile phone...
  
• Relatively nice and user friendly user interface...
• They even work on improving it while you sleep...

Actually, this may not be such a bad idea at all.

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.