The Competition: Johnson Controls & IBM

Press release: IBM, Johnson Controls partner on green buildings

No further comments at this time.

Hardware: GuruPlug: coming soon, thanks to you

Thanks to donations, the GuruPlug Server - PLUS has just been pre-ordered and is expected to be shipped at the beginning of April.

To The Benefactors

Thank you.

Because of your generosity and good will, everyone will now will have the benefit of having a prepackaged solution when the time comes.

Every dollar donated on hardware I can tinker with transforms in innumerable hours saved by everyone that is planning to use it, for the path had been already paved and you don't have to make mistakes I did. In addition, it is difficult to underestimate the value of confidence that you get when you see your hardware on the supported list.

Meanwhile

DZ is still accepting donations - there are expensive devices on the horizon many users expressed interest in, in particular, wireless sensors and stepper motors and controllers.

This Is What We Are Here For

To reinforce the point made in the previous post - we are here to fix it.

The whole point of this project (among other useful things like actually controlling your hardware) is to make everything visible.

You will find out details about the hidden life of your house and your HVAC equipment you never suspected of. We'll be here to help you make sense of the overwhelming stream of data you have no idea of the meaning of, and don't care much about - but the things you do care about (home comfort and energy savings) will be delivered, in a tangible and verifiable form.

That's Why We Don't Like Them

Pet peeves, you say...

There is a comment on You will never buy a good HVAC unit. Deal with it post, stating, among other things:

Air filters should be changed each month

You see, I have a problem with that. Not with the notion of changing filters or doing scheduled maintenance, no. With unjustified arbitrary rules and inexact statements.

A month, you say? Why a month? Why not two? Why not a week?

• Did you take into account my location and season? (currently, HVAC runs for less than an hour a day, and it's going to stay this way for a month or two, after which time it'll run almost constantly)
• Did you take into account special circumstances? (some people have several big hairy pets in the house, some have none, some have carpets, some wood or tile, some keeps their windows open, some don't)
• What filters are you talking about? (there are dime-a-piece run of the mill cheap filters, and there are expensive (and constricting) allergy filters, not even speaking of electrostatic filters that are completely different animals altogether)
• Why didn't you mentioned that most contemporary thermostats have filter usage counters and signal you when to replace the filter (this usually gets ignored because nobody is looking at thermostats, but still, it's there)

Now, I understand your difficulties in explaining the art of maintenance to, should I say, non-enlightened customer base, but the general state of residential HVAC is so pathetic, it's not even funny anymore. Today, when people are carrying distributed computers in their pockets, we are talking about "every month" and "proper"?

So what's missing?

In one word,

QUANTIFICATION

You can't improve (nor service, for that matter) what you can't measure. You either overstress and overcharge the customer, or do an inadequate job. In neither of those cases the customer is going to like you too much, especially when they find out that, ahem, you don't really know what you're doing. Not because you're dumb or unprofessional, but simply because you don't have adequate tools to measure what you need to measure. Which brings us all the way to the title of this article.

Us and Them

Who is "Us"? Consumers, consequently, customers (sooner or later).

Who is "Them"? Anyone for hire to fix the problem.

Basic problem? Distrust. The issue of "reputable" specialists was already beaten to death, with no satisfactory solution in sight. But there is one way out which, for many reasons (not the least of them is a gross inability of HVAC equipment manufacturers to keep pace with the evolution of consumer electronics and computers) has not yet been explored:

Remove The Need To Trust

Again, we run into the same concept: quantification. Prove to me that you need to replace the filter. Prove to me that the charge is right. Make your actions verifiable. And we'll part ways, both of us happy - me because you made me confident that you did the job right, and you with the satisfaction from a job well done (and, definitely even more important for you, long term returning customer and a source of more revenue - a happy customer brings more customers).

And God forbid you ever say to me "Now let's pray it works".

Early Access: Economizer

Subversion contains code that allows to run an economizer (or control motorized blinds or windows, or just turn on a fan). Configuration Guide has instructions on configuring it. Console currently does not change rendering based on whether the economizer is active or not, but this feature is planned for the next release.

Do You Need An Economizer?

HVAC specialists and salesmen of all calibers were pushing economizers onto the population since they've been invented, with close to zero success. Don't know about you, but I haven't met a single person in my life that uses it, and believe me, I'm asking just about everyone I meet.

There is a very good reason for that - it is difficult to make an average person to part with quite significant sum of money unless they're convinced it's for their good. And you absolutely can't convince anyone without cold, hard numbers in your hands. And, surprisingly, the art of HVAC sales and installation is very far from numbers.

Not so here.



Image above (click to enlarge) represents 22 hours of indoor and outdoor temperature for February 14 2010. Here's a summary:

• For 18 hours, heating is required;
• For 7.5 hours, outdoor temperature is above indoor temperature while indoor temperature is below the setpoint;
• That is a whopping 39%. Thirty nine percent.

So what do you think now?

When does it make sense

The wider is your daily temperature range, the more are the chances that you will gain a very significant financial benefit from running an economizer (keep in mind that it is cheaper to run it tan to run a heater or A/C - it is essentially a fan).

It also makes a lot of sense if you're running a home office (computers generate a lot of heat), have a home theater (TVs and amplifiers generate a lot of heat, so do people watching the movies and listening to the music), and, of course, if you have a kitchen. Wait, don't you have a kitchen?

Though so.

How to see it for yourself

Everyone's location, climate and conditions are different, and you need to use your data in order to make a decision on whether you do or don't need an economizer.

For now, you'll have to exercise some amount of RRDGraph magic - you already ave all the data necessary (prvided you have the outdoor temperature sensor, of course).

But wait, there's more...

<to be continued>

Hardware: GuruPlug

Why, oh why I didn't wait two months and bought the SheevaPlug?

Oh well, can't wait forever.

Ballpark: it seems to me that this box fixes multiple problems that SheevaPlug had (hope they fixed the dreaded hald(8) segfault), and the increase in price is roughly equal to a price of a standalone USB wireless card, even without a USB hub, which makes buying Sheevaplug a waste of money.

However, not all is in vain - there's been a lot of work done on DZ code base in order to make it fit into 512MB RAM, and SheevaPlug is a good playground for GuruPlug.

Meanwhile, DZ is accepting donations - I simply cannot afford to purchase all the hardware it can be run on in order to check compatibility and make it work seamlessly. Direct hardware donations are even more appreciated.

UPDATE: pre-oredered, thanks to user donations.

(via Hack A Day)

FAQ: Getting Google Calendar Dependencies

In order to successfully build dz3-scheduler-gcal, you need some extra dependencies, and in order to run it, you need some more (both come from gdata-java-client library). Following are the steps to make them available (implies wget(1) installed on your system):

cd /tmp && \
wget http://gdata-java-client.googlecode.com/files/gdata-src.java-1.40.2.zip && \
cd /usr/local/src && \
unzip /tmp/gdata-src.java-1.40.2.zip

The /usr/local/src location is hardcoded into dz3-scheduler-gcal/pom.xml, change it if it doesn't work for you.

1.40.2 was the latest version available at the time the development of dz3-schedule-gcal was finalized, feel free to replace it with the latest available - but make sure individual dependency version numbers match.

Why So Ugly?

Because gdata-java-client hasn't been made available to the Maven Central Repository yet.

If you want to make it happen and know how to do it, please do so. If you find out that dependencies in question are already in the central repository by the time you read this, please let me know.

What Google doesn't get about All This Buzz...

...is a simple fact that people are many personas in one.

The Me fixing my cars has nothing to do and wants nothing to do with The Me working for That Big Company, nor The Me obsessed with climate control, nor The Me talking strange tongues, nor The Me playing the sax or doing whatever else.

What's worse, they conflict.

Their areas of interest and social circles are barely, if at all, connected, and quite often information leaking from one circle to another would cause major embarrassment, if not more severe consequences.

Not even talking about the simple fact that a friend of my friend is not necessarily a friend of mine.

It's not even the "nothing to hide" argument, its a simple fact that multiple personas of me are standing in each other's way, and treading on each other's feet, and are annoying each other when they are trying to do something.

Give me multiple personas I can control (without resorting to having multiple accounts, which is a major inconvenience).

Give me privacy controls so I can prevent bleeding of facts from one sphere of interest to another.

Give me a way to separate them.

Then I'll be happy.

I don't see that hapening anytiume soon, though., so for now I'll just buckle up and see if am willing to subject myself to all these voices talking in my headmail all at once.

UPDATE: See? What'd I tell ya? Posted it in the wrong blog. Ah, the hell with it, let it stay here as a lesson. Crossposted to where it belongs.

Going International

Not that DZ's been restricted to a single territory (there were several installations across US, an installation in London had been known to exist, some work had been happening in South Africa, recently there was a wave of visitors from Czech Republic) - but now there's a point of presence in Hungary. With documentation in Hungarian, no less. This is the first non-English site that I know of.

Drum roll,

Házvezérlés saját kezűleg.

English-speaking folks might be interested in reading it via Google Translate or any other automated translator - there are interesting things there. In particular, I liked the munin plugin - been thinking of writing it, but never got time to do it.

DZ 3.5.2 Release Is Out

• Download from SourceForge
• Download from Google Code
• Download from Ohloh
  
• Get source code from Subversion

Changes since 3.5.1

This is a maintenance release.

• RrdLogger will now log absolute path instead of relative, to make it easier to fix problems with initial configuration;
• TemperatureSensor and HumiditySensor abstractions, initially separate due to mental inertia caused by following the DalSemi OWAPI model, are now merged into an AnalogSensor - with a significant reduction in code base. All the code handling them was essentially the same save for method names and entity types;
• Side effect, Thermostat can take any AnalogSensor as signal input.

This release fixes a bug that prevented the Humidor release from working with 1-Wire humidity sensors that reported themselves as humidity containers.

DZ 3.5.1 Release Is Out

• Download from SourceForge
• Download from Google Code
• Get source code from Subversion

Changes since 3.5

Fixed a bug in Google Calendar Schedule Updater causing period times not ending on the hour mark improperly calculated.

There are no other changes, you don't need to bother if you're not using Google Calendar schedule integration.

DZ 3.5 "Deja Vu" Release Is Out

• Download from SourceForge
• Download from Google Code
• Get source code from Subversion

Changes since 3.4.1

• It is now possible to use Google Calendar as a source for your thermostat schedule;
• Schedule Updater API is now available, you can integrate DZ's schedule with any other schedule source for which API is available.

Read FAQ: How Schedule Periods Work to learn how to set your own schedule (and you can use the calendar shared from the article as an example), and Configuration Guide to learn how to configure the updater.

Why "Deja Vu"?

This release concludes the "reboot" of DZ code base, started on October 14 2009 (read DZ3 Seeded for more details). Functionality of DZ3 today is more or less the same as it was at 0.1p7dev3 (that's September 2004 all right), but with quite a few distinctive differences that can be briefly summarized as:

• Improved usability;
• Improved stability;
• Improved documentation.

That's all an average user needs to know, but if you're willing to peek under the hood, then here's a longer list:

• DZ3 is rock solid. Unlike DZ2 where bugfixes were mostly afterthoughts, every questionable piece of code is wrapped into test cases, and whenever there is a problem, more test cases are written to pinpoint it;
• Reliability has gone up, footprint has gone down. DZ3 runs with JVM heap restricted to four megabytes of RAM, with uptimes measured in weeks - and that is only because the development is happening at such a pace that it is worth to upgrade and restart;
  
• DZ1 architecture grew out of monolithic proprietary code that was never published, DZ2 architecture was never finished, DZ3 architecture is everything DZ2 ever wanted to be - on top of almost ten years of experience not only with DZ, but with a lot of other things related and not so related to it;
• DZ3 code base is transparent to instrumentation. You can chart any data point in between, and see and control all live components via JMX;
• Thanks to instrumentation that is now available, DZ3 is free from resource leaks;
• Initial configuration that was always a pain in DZ2 is now documented. Proprietary XML configuration was replaced with Spring IoC Container and looks now like LEGO for adults;
• User Interface now actually passes "a moron in a hurry" certification and is usable by mere mortals, unlike the Sci-Fi contraption of DZ2;
  
• Editable and persistent schedule is available, at long last.

To cut this long list short, DZ3 has reached the point where I always wanted it to be - it just works.

What's Next?

To put it simply,

• Further scaling down of hardware requirements;
• Further optimization and reducing the load on DZ3 host device;
  
• Web integration;
• Mobile device integration.

Stay tuned. Meanwhile, enjoy.

Credits

Tomasz Korwel was most helpful in making it happen, I don't think DZ3 would be as smooth and reliable as it is without his active feedback and participation.

Early Access: Google Calendar Integration

Subversion contains code that allows to pull your schedule off your Google or Google Apps calendar.

As usual, if you can read source code (dz3-scheduler-gcal is the module to look at) and configure a Spring IoC container, you will have no trouble utilizing it.

Put Your Tinfoil Hat Away

For the paranoid out there: you don't have to write your precious authentication credentials into the configuration in plaintext - you can skip them from the configuration altogether and provide them to the runtime environment via JMX.