Pulse, Reloaded

Once upon a time, there was an overheating video card. It begat the Pulse project, the hardware health monitor. Later, overheating house begat DIY Zoning, and since its inception, Pulse started to wither away into oblivion - a few years later I marked its status on SourceForge as "inactive", and today, there's not even a web page for it.

However, recent emergence of Android changed a lot. For a long time, lack of hardware support for DZ was a showstopper - nobody wants a zoning system that needs a computer in order to operate it. Smartphone, however, is a completely different deal.

Almost exactly a year ago I started planning for it. A month ago, I got my hands on the hardware. Today, I can say with confidence that G1 can deliver, and it does make sense to implement a control system with a mobile interface based on Android platform.

One of the lessons of DIY Zoning development was that it is a bad idea to have a monolithic system - I had to split it up three or four times before I was happy with the distributed features of the whole system. Not to repeat the same mistake, the application will be more generic than just a zoning system controller.

Hence, hereby the relaunch of the Pulse project is announced.

It'll be a short while before the feature set is established, the project site is again complete with content, and version control system will have the code - I just don't want to release half-baked barely functioning code prematurely, it is still in the works. It's just that privately expressed interest towards the project exceeded the critical mass recently, and I thought you folks would like to know what I'm working on.

Stay tuned.

One Size Fits All, or Reflections on EPA guidelines

So here cometh a fresh pair of thermostats (Honeywell RTH7500 and RiteTemp GPMG8085C), both equipped with default schedules taken from EnergyStar ® Program Requirements for Programmable Thermostats: Partner Commitments (look for Table 2: Acceptable Setpoint Times and Temperature Settings). It was summer, and the default settings were too cold for us, so we changed them.

But the defaults for the heating season were left in place.

Now that the heating season is here, and it is eventually getting quite cold outside, several interesting things are popping up.

First of all, let's take a look at default EPA compliant settings.

Wake: 6AM, 70°F.
Day: 8AM, 62°F.
Evening: 6PM, 70°F.
Sleep: 10PM, 62°F.

Then, let's go back and read the long rant about whether you should shut off your A/C or leave it running.

Then, let's take a look at the temperature spread for the schedule above. 8°F.

That's quite a lot.

The very reason I've started thinking about writing this article is that one of my units (Lennox split), being perfectly capable in cooling mode, seems to either hit the balance point, or otherwise severely degrade its performance, when the ambient temperature drops lower than about 45°F - and, as a result, it is unable to bring the zone it serves from 62°F to 70°F in two hours.

Even worse the temperature actually drops to about 65°F by 6AM, and it barely makes it to 68°F by 8AM - forget 62 to 70.

While this is definitely quite uncool, it also points out another fact that is not on the surface: the unit works at the top of its efficiency curve. It doesn't cycle, it spends initial 10-20 minutes approaching the design efficiency and stays there.

That was the positive, now, another negative - since it serves two rooms, one of which is about five times size the other - guess what, by the end of the two hour run the smaller room is HOT. Balancing the dampers manually will not help since it'll shoot the balance for other conditions - like, the evening, when the ambient temperature is significantly higher and the runtime of the unit is very short in comparison.

So, what's the point?

• One should carefully examine defaults;
• You can't get away without actually zoning the house - unless you want to shuffle everything all the day or suffer;
• It would *really* pay back to come up with an idea to figure out to anticipate the *actual* performance of the unit for varying circumstances and make the system issue recommendations to you about what you should do in any particular case;
• Which would imply the knowledge base and rule engines to analyze input and figure out dependencies (homework: see Google's statements how having access to massive amounts of data helps to figure out the trends and make correct decisions);
• It would help to share data between installations (see how Valve managed to make Half Life 2 the most playable game for the same hardware utilizing statistics) and applying some brains;
  

Damn! DZ is going enterprise.

Hmm... Turned out not quite the way I started it - but oh well, I'll just leave it at that.

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.

The Dual Nightmare

There is an ongoing heated discussion among homeowners and HVAC professionals about what solution to the problem of properly balancing the house is better - zoning the house, or having multiple units installed. There are all kinds of arguments on both sides.

The proponents of zoning are usually saying that it would be silly to use one switch to turn on or off all the lights in the whole house, whereas the opponents are pointing out that it is silly to pump the amount of air intended for all ducts together through one.

The opponents of zoning are usually saying that it is more reliable to have two simple HVAC units than it is to have one complicated HVAC unit and one complicated zoning system, whereas the proponents are pointing out that maybe HVAC professionals may be simply out of their depth and are trying to cover that up by silly arguments.

The opponents of zoning are saying that having two units is an adequate solution to the balancing problem and point out to the fact that existing commercial zoning systems are rarely extending "affordable" options beyond four zones, to which I say they are completely nuts and give the room (read: zone) count for three quite average houses that I've lived in: roughly 11 zones in Iowa farmhouse (2 levels, 4 bedrooms, full basement), 14 zones in one house in Arizona (3 levels, 4 bedrooms, game room, library) and 13 zones in the house I live in now (2 levels, 3 bedrooms). Oh, I do include bathrooms, too.

But I digress.

Sometimes you just have two units - for example, when you simply buy the house with them installed - it would be silly to rip them out, wouldn't it? So one just has to deal with it...

Whereas having two units is certainly nice, it is by no means a guarantee of any improvement whatsoever. Like it was pointed out before, all your luck depends on having the job done right.

Sometimes your luck is improved by the fact that the house was designed with heat exchange physics in mind (little heat transfer between floors, narrow staircases).

Sometimes it is degraded by the fact that aesthetic considerations took priority over common sense - wide open floor plans with walls being mostly glass, rooms spanning several floors vertically, and different floor count in different parts of the house.

Which is exactly the situation I have to deal with right now. The north side of the house (1 floor, 2 rooms + 2 bathrooms) is served by a nice powerful variable speed high SEER Lennox split unit. The south side (2 floors, 4 rooms + bathroom + kitchen + laundry room) is served by a puny rooftop Trane and a set of drinking straws they called ducts.

So let me skip the rant about how unthoughtful that was, and get directly to describing various interactions between two units that may happen. Let's assume for simplicity that we're talking about cooling season behavior.

Unhappy Load Meter

If both units kick in at the same time, and you are on a load controlled electrical billing plan, you're not gonna be happy. Neither is your electrical company, but that's a completely different story for a different time.

Cold Spots

It may happen that both units serve the same room[s], directly or indirectly, and the room has enough or more than enough supply and return capacity, and neither of the thermostats is in it. If both units kick in at the same time, the room will get uncomfortably cold.

Hot Spots

It may happen that the cold air supplied by unit A drags down the temperature at the thermostat controlling unit B. In this case, it will not get unhappy and cause unit B to switch on until unit A is off. Which will cause the rooms normally served by unit B to become uncomfortably hot.

The Skew

To add insult to injury, it is quite possible that the layout described above also makes unit A serve, at least partially, the zone that is supposed to be served by unit B - and in this case, unit A will keep running and running, possibly not even catching up with demand - and it will not get any help from unit B because the effect described above robbed unit B of necessary control input and is preventing it from switching on. You end up with one unit trying to do the work of two, for which it is clearly undersized. To further aggravate the situation, it is possible that the overworked unit will go beyond its normal design range, and then you have a dead unit (ask me how I know).

For more than one floor, The Skew is rather a rule than an exception.

Ask yourself a question, don't you always have to set the thermostat downstairs a couple of degrees lower than upstairs, otherwise it feels hot and stuffy? The scenario above explains it vividly. All there is is a leak of cold air from upstairs through the staircase (or a tall room) that causes the thermostat downstairs to make the unit stay off.

Catch-22

To prevent The Skew (further defined as one of the units working significantly longer than the other), you need to carefully balance the thermostats in such a way that the race never starts. This will usually mean that you will have one of the thermostat set below the comfort level, and the other above. Also, this is going to cost you, because the difference between "comfortable" and "balanced" positions of thermostats is going to make a significant contribution to your electric bill. Also, it robs you of comfort. Also, it will make you fiddle with controls all the time, unless you have monitoring set up, in which case you'll just spend half of the time fiddling.

It would be interesting to know what side of argument described at the beginning of the article you are now...