Wednesday, September 15, 2010

Emme: The Vaporware of 2010? [Update: Yes]

Emme was discovered in December 2009, slated for release in April 2010, then delayed until July, then until August.

It's now the middle of September, but the registration page still lists August as the availability target.


Maybe all it is is a market research tool? Too many things seem to be stuffed into one body, thus violating "do one thing, do it well" principle.

Especially interesting is the claim about, quote,

patented algorithms to identify most individual appliances and electrical devices, giving you insight into your energy use that to this point was unavailable.
Show me the money, or I call it snake oil.

And I still can't find my hat after it's been blown away by a promise of supporting whole three wireless sensors.

UPDATE (January 1 2011): registration page still lists August 2010 as availability date. I guess they gave up.

UPDATE (January 21 2011): the date on the registration page is gone, and it claims now that "Emme products are available nationwide through our extensive dealer network". Oh well. Let's see now how long will it take them to materialize. With three wireless sensors.

Tuesday, August 24, 2010

DZ 3.6.3 Release Is Out

Changes since 3.6.2

  • Fixed the Cold Start bug;
  • Improved XBee device handling upon late arrivals.

Dilbert Creator Weighs In

Scott Adams wrote an article called How I (Almost) Saved the Earth.

If you care to read and see through the usual Dilbert language, there are quite a few good advices on what and how to do (and not to do).

(Image: Wall Street Journal)

Monday, August 23, 2010

Correction: HVAC Controller Setup

"HVAC Controllers" section of the Configuration Guide was missing a slide - thanks to KF for pointing that out.


Friday, August 20, 2010

So what is it that you *really* wanted, but were afraid to ask?

Google has just released yet another useful tool - the public version of their Product Ideas.
Here's an experimental form I created for us all:

What do you need that we don't do?
Missing a feature? Something doesn't work right? Don't like something? Speak up. 'Cause if we can't hear you, we can't make you comfortable. Which is the reason we're here for.

Wednesday, August 18, 2010

SO Override HOWTO

Since I started eating my own dog food (but more about that later), I've met with the same problem many of other DZ users already have: the fact that system is not quite that accessible. Easy to control, yes, but not accessible. You can't just push a button passing by the thermostat in the hallway.

And the worst situation you may find yourself in is when you're asleep or away, and someone in the house wants things warmer or colder. Oh no, you don't want that (yeah, and that tooth had to be removed anyway).

But there is a solution.


Granted, totally ugly, but totally dependable.

How It Works

When you connect the relay board, you connect it not directly to HVAC cable or the unit itself, but as a piggyback to an existing thermostat. Let's consider RTH7500 (above) as an example.

Determine Wiring Scheme

Find the manual for your thermostat (here's a link to RTH7500 manual). Find the diagram for your specific installation (mine is on page 10, "Connect wires: Heat Pump").

Thus, you now know what wires to connect. For the example above I needed red, orange, yellow and green.
Careful! your HVAC installer may have used different colors, you have to look at the markings, not at the wire color!
Get yourself a piece of thermostat cable, or just find appropriate wires.

Connect the relay board

Red wire is the common wire, connect it to all "common" contacts. Connect other wires as appropriate.


There are two common thermostat connection schemes - (white and yellow) vs. (yellow or white and orange) or (yellow or white and blue). Orange and blue wires are mode selectors - you need to know which exactly is the scheme your thermostat uses. For example, RTH7500 uses yellow plus orange ("energize to cool") and I connected it to NC contacts, since most of the year the thermostat is in cooling mode. Your mileage may vary.

Congratulations, you're done

So how does all this help you? Simple.

First of all, you set the thermostat much higher (assuming cooling mode) than it is necessary (if you take a look at the big picture, you'll see that the thermostat is set to 90°F) and set it to permanent hold. Then when you're not around and there is a desperate need to change settings, all that needs to be done is
  • Press the "Use Schedule" button (or the equivalent);
  • (optional) Disconnect the power to the relay board.
Added benefit is that whenever anyone is compelled to do so, the home climate will return to abominable state it was before, and the temptation will disappear for a long time.

PS: I am working on a more permanent solution, right now.

Monday, August 16, 2010

DZ 3.6.2 Release Is Out

Changes since 3.6.1

This is a maintenance release.
  • Many objects' reflections in JMX are now less cryptic and more usable;
  • XBeeDeviceFactory now properly reflects in JMX;
  • XBee deices not present at startup will now be discovered as they arrive;
  • XBee sensors departing will be discovered within a specified timeout and corrective action will be taken.

Monday, August 9, 2010

Honeywell RTH7500: Long Term Verdict

Surprisingly, the most annoying feature of this thermostat turned out to be lack of programmable hysteresis, a.k.a. deadband.

This particular one, installed in this particular location, allows runtimes as short as three bleeping minutes - whereas the time required to get into more or less efficient operating mode is no less than about five minutes for furnaces and about fifteen minutes for an A/C or a heatpump.

Likewise, there is no minimum run time protection (sometimes called short cycling protection).

In other words, this thermostat will make your unit work much less efficiently than it is designed to, and the only way to prevent that is to put the thermostat in a place where the temperature changes very, very slowly - like a closet or a thermally insulated box. Which is not quite that practical.

So, thumbs down, no go.

Likewise, if I ever have to select a thermostat again, I will pay particular attention to presence of programmable hysteresis and minimum run time.

Friday, August 6, 2010

DZ 3.6.1 Release Is Out

Changes since 3.6

New Features

Thursday, August 5, 2010

Early Access: XBee Analog Sensors

Subversion contains the driver for XBee ZB based temperature, humidity, pressure and any other imaginable kinds of analog sensors. Scaling is also supported, so different hardware sensors can be used.

Read the article on making the wireless sensor for more details on sensor design. Configuration guide is coming soon (there are caveats, hint: take a look at ConvertingSensor).

Saturday, July 31, 2010

Around The World

View DZ Installations in a larger map

Since project inception in 2001, quite a few people installed DZ in their houses. Somehow, I didn't think of visualizing the community until very recently - but now I'm working on rectifying the situation.

Above is the map of known DZ installations, updated with new information as it comes. For all you know, there may be someone next door to you that can help you with the process, should you require assistance.

DZ 3.6 Release Is Out

Changes since 3.5.3

New Features

DZ 3.6 Release Is Out

Changes since 3.5.3

New Features

Friday, July 30, 2010

Teaser: XBee Wireless Temperature Sensor

XBee wireless temperature sensor

Above: XB24-ZB with four TMP36 analog temperature sensors connected to XBee's analog inputs.

The reason four sensors are connected is: comparison and statistical analysis.

It remains to be seen how good or bad analog readings are, and how easy it is to compensate for these imperfections in software.


This design is based on a similar one, with a few minor differences:
  • TMP36 is used instead of LM34 (the only reason being that I had some spares laying around). Obviously, the result calculation is different. Wide selection of similar sensors (TMP35, TMP37, LM35), result would be just about the same, save for value recalculation;
  • Incidentally, this allowed to get rid of the voltage regulator because whereas LM34 requires +5V to +30V power, TMP36 is fine from +2.7V to +5.5V, hence, the same 3.3V power can be used to feed both XBee and TMP36;
  • Caveat is, at +70°C TMP36 output voltage reaches maximum allowable voltage for ZB series ADC, 1.2V. I don't think it's a problem because the intended usage is indoor temperature measurement, if your indoor temperature reaches +70°C, you'll have bigger problems to worry than a possibly damaged XBee. But keep this in mind if you're planning to use these sensors to monitor a temperature of, say, a water heater or air coming out from the furnace;
  • 330Ohm resistor added to ASSOC LED to restrict the LED's operating current (might want to use 1K and higher if your LED is too bright for you).

More to come.

Thursday, July 29, 2010


Now that XBee is supported, let's see how to make it work.

Bill of Materials

I would highly recommend to buy an extra XBee radio and an adapter if you have never worked with XBees before - it'll save you a lot of grief because you'll be able to monitor the network status activity. You see, the relay shield doesn't come with network status and activity lights, so unfortunately, you'll be flying blind and will have to re-plug XBee modules into adapter every time you're not sure what is going on.

Hence, recommended quantities are - three XBee modules, two adapters and one relay shield (add extra XBee module + relay shield pairs if you have more than one HVAC unit, one pair per unit) - starting at $110.80 before shipping.

Minimum quantities - two XBee modules, one adapter and one relay shield ($73.90 before shipping).
Before you say that's expensive, think how much you will spend breaking walls to wire cables, then patching them back, texturing and painting. Not even talking about time spent on all that exciting work.
Keep in mind that some suppliers have high lead times - I've seen as high as two weeks.


Note that the power supply is not included into the bill of materials. The relay shield requires 9V DC power - you either might have one handy already, buy a cheap one wherever you fancy, or just use a 9V battery (the relay shield has screw on contacts for that). I don't know yet how long the relay shield is going to last on a battery with normal HVAC usage pattern, will find out and report.


Countless XBee tutorials exist, so I'm going to skip this part - suffice to say, get your XBees lined up and talking to each other.

DZ specific XBee setup

You need to flash one XBee module (the one on the adapter) with the Coordinator API firmware (when you get familiar with X-CTU software, this will become self-explanatory). Make sure you read the module configuration and flash correct firmware. After you flash API firmware, it won't be possible to use a dumb terminal to control the XBee anymore (limitation of ZB series), so make sure you're done with setting up communications correctly before you do that - like I said, extra XBee and an adapter will help a lot from here on.
IMPORTANT: Make sure you set AP=2 and write changes. The reason for this is that xbee-api library used for low level communications doesn't work with AP=1, and fails to report when AP=1, or forcibly change the module state to AP=2.

Baud Rates

Don't bother changing the port speed from default 9600 baud. DZ is more than happy with that speed, but if you change it, you might run into trouble remembering what it is next time you try to connect to XBee via an adapter.

DZ Configuration

XBee devices are configured in exactly the same way as 1-Wire devices: using a device factory. Here's a snippet that will produce a working switch (0013A200.4062AC98 is the 64 bit hardware address of my XBee module plugged into the relay shield, substitute it with yours):
<bean id="device_factory"
<constructor-arg index="0" value="/dev/ttyUSB0"/>
<bean id="switch_0013A200.4062AC98_0"
<constructor-arg value="0013A200.4062AC98:D0"/>
There are four channels on the relay board used. Channel numbers are printed on the silk screen (look at the data sheet if in doubt).
NOTE: Relays are marked COM1 to COM4, but channels to access them correspond to actual XBee channels - D0 to D3. This is done so that all XBee digital outputs can be controlled - D0 to D8, and P0 to P3.

Congratulations, you're done

From here on, things are just as usual - use the reference to switch_0013A200.4062AC98_0 as you would have with a 1-Wire based device.

UPDATE: Adjusted description to match the improved channel addressing.

UPDATE: This article describes the switch setup, see the Teaser: XBee Wireless Temperature Sensor for information about sensor setup.

Early Access: Going Wireless with XBee

Don't want to break your walls to wire cables? Newsflash: you don't have to anymore.

Subversion contains the driver for XBee ZB based switches (sensor drivers are underway). As usual, if you can read source code and configure a Spring IoC container, you will have no trouble utilizing it. Configuration of an XBee device is just like the configuration of a 1-Wire device (start with the device factory... and so on and so forth).


As usual, wide range of devices is supported, but the specific hardware drivers were written on is:
The device connected to the computer must have the Coordinator API firmware with AP=2. Relay shield is equipped with Router AT firmware XBee, but most probably End Device AT firmware will work, too - as well as API firmware of both kinds.

No custom firmware is required on XBee devices.

More to come.

Saturday, July 24, 2010

DZ 3.5.3 Release Is Out

This is a maintenance release.

Changes since 3.5.2

Major Bugfixes

Minor Bugfixes

  • ServoDamper will now reverse properly.

New Features

  • Added NullSwitch to allow actuator mocks (as well as using existing HVAC drivers to run less complex devices);
  • Added SingleSwitchDevice (experimental);
  • Added economizer abstraction and simple implementation;
  • Added resource usage counter abstractions and simple implementation;
  • Started integration with Sonatype Maven repository;
  • Added unified connector framework and HTTP connector;
  • Verified compatibility with 8CIO8-R1-A 8 Channel I/O (8 Relay Version), should also work with 8CIO4-R1-A 8 Channel I/O (4 Relay Version);
  • Verified compatibility with 6CMH1-R3-A 6 Channel Master Hub;
  • Added configuration switch to disable damper crawling (for slow serial servo controllers);
  • Added configuration switch to enable workaround for deadlocks (happens with some 1-Wire device containers not yet thoroughly tested).

Thursday, July 15, 2010

DZ Temperature Sensor HOWTO

In order to make DZ tick, you need sensors. Preferably lots of sensors. This article will show you how to make them in a very quick, cheap, and quite inconspicuous way.

Bill of Materials

  • A DS1820 family sensor (any variant will do: DS18B20, DS18S20, DS1822, DS1920)
  • CAT5 RJ-45 connectors, dime a dozen anywhere including your local Fry's
  • Bulk CAT5 cable
  • Heat shrink tubing
  • Marker tape of your choice


Beyond obvious,
  • RJ-45 Crimp Tool
  • Heat Gun

Step 1: Strip & Crimp

Step 1: strip

Crimp the RJ-45 connector onto the end of a piece of CAT5 cable using T568-B pinout.

Measure 3" from the end of the jack, cut the cable. Measure 2" from the end of the cable, strip the insulation, remove the extra thread.
You can try to cut the cable shorter - the reason I didn't want to do it is I didn't want to risk activating the heat shrink by soldering. YMMV.

Step 2: cut extra wires

There are two possible choices:
  1. Make the sensor completely compatible with Hobby Boards wiring scheme (data sheet gone with Hobby Boards sold and website defunct) (careful, they use T568-A and not T56-B);
  2. Extend wiring in order to provide an ability to create an electrical bus configuration on star physical configuration.
In any case, cut the brown pair and white+orange, you won't need them.

Hobby Boards Pinout

You would want this pinout if you're plugging the sensor directly into a Hobby Boards device, or into a socket that is daisy chained to the next run. Or, if this is the last sensor in the "electrical bus, physical star" configuration.

Hobby Boards compatible sensor
  • White+Blue (pin 5): GND (see DS1820 data sheet)
  • Blue (pin 4): DQ
  • Orange (pin 2, not pin 6!!!): Vdd
I left the green pair hanging not to waste the jack, the cable and, most importantly, time spent on crimping, for the case when I'll need to convert this layout into DZ layout (it's pretty simple to cut the heat shrink tubing).

DZ Pinout

You would want this if you're plugging the sensor into a socket that is wired to a patch panel and you want to patch the return to the next run.

Step 2: wire. Look closely at notes, it's not what it seems!
  • White+Blue, White+Green (pin 5): GND
  • Blue + Green (pin 4): DQ
  • Orange (pin 2, not pin 6!!!): Vdd

Step 3: Solder and Insulate

Step 3: solderStep 4: cover

Congratulations, you're done


If you look closely (click to see the big picture), you'll see that cables are marked - blue strip for Hobby Boards pinout, blue and green for DZ pinout.

WARNING: Never plug a DZ sensor into a socket with Hobby Boards pinout!

It may be even SO compatible

Close upNow find it

The result is not that visible at all, honestly.

The Missing Link: Where does it go?

So where are all these sensors plugged into? Answer is, RJ-45 sockets wired to a patch panel, which is, in turn, wired to a punchdown block DZ hardware is connected to. But that's a different story for a different time.

<Stay tuned>

Wednesday, July 14, 2010

Ceiling Fans, Caught Red Handed

Remember, I was telling you not to turn them on?

Well, now they've been caught in action - take a look (clickable):

Be my guest, turn it on

The fan was turned on at 10:29 and turned off at 10:35.

In other words, every time you feel tempted to turn your ceiling fan on, stop and think whether you want the short term relief because of air circulation and long term loss because of extra heat that it generates, or the other way around.

I suggest you just turn the thermostat down a bit.

Tuesday, July 13, 2010

Early Access: Resource Usage Counter

Ever wanted to find out how many hours did your HVAC actually work? Keep forgetting to replace the filter? Well, here's your cure -

Subversion contains the implementation of the resource usage counter. As usual, if you can read source code (FileUsageCounter is probably the one you're looking for) and configure a Spring IoC container, you will have no trouble utilizing it.

Resource usage counters are DataSinks and can count whatever is DataSource<Double>.

Also, they are DataSource<Double> themselves and can be fed into data loggers - you'll easily see when exactly did your HVAC equipment work.

Saturday, July 10, 2010

How much?

Q: How much will it cost to get the system up without bells and whistles?

Wednesday, May 12, 2010

The Competition: ecobee, materialized

ecobee, previously reported, now has materialized at Jackson Systems.

Jackson Systems is shy to list the price openly (you're required to log in, LOL), but Froogle reports the price starting at $337.99. Vote with your dollars.

(Image credit Jackson Systems)

Friday, February 19, 2010

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.


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.

Wednesday, February 17, 2010

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,
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".

Monday, February 15, 2010

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.

Sunday, February 14, 2010

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.

Winter Day In Arizona

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>

Friday, February 12, 2010

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 && \
cd /usr/local/src && \
unzip /tmp/
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.

Wednesday, February 10, 2010

What Google doesn't get about All This Buzz... 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.

Tuesday, February 9, 2010

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.

Sunday, February 7, 2010

DZ 3.5.2 Release Is Out

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.

Thursday, February 4, 2010

DZ 3.5.1 Release Is Out

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.

Tuesday, February 2, 2010

DZ 3.5 "Deja Vu" Release Is Out

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.


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.

Monday, February 1, 2010

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.

Saturday, January 30, 2010

Coming Up: Calendar Integration

You could see some pretty definite hints here, now it's coming to life. So, what exactly is it?

Generic Schedule Updater

ScheduleUpdater interface in dz3-scheduler module provides the interface, and AbstractScheduleUpdater provides the most generic baseline for implementing any back end integration. Want to store your schedule in a flat file? Be my guest. Want to read it off IRC? Anytime.

The updater is injected into the scheduler, so you're pretty much free in what and how you do it. That is, in case if you're not happy with the concrete implementation that will be a part of the release.

Google Calendar Integration

Just like it was planned, DZ will read the schedule from the the calendar of the account of your choice. Both Google and Google Apps accounts are supported, as well as pulling schedule details off any public calendars that you've subscribed to. Basic connectivity has already been implemented, details will be ironed out between now and next release.

Thursday, January 28, 2010

DZ 3.4.1 "Scheduler-Console" Release Is Out

Changes since 3.4

  • Current period is now displayed at the console;
  • If the settings for a zone were altered against those specified for the period, a visible mark appears;
  • Pressing 'S' will make the system follow the schedule again.

Configuration Changes Necessary

Scheduler bean needs to be injected into the console bean, just like other elements - see configuration guide for details.

A telltale sign that you forgot to do that would be absence of period information displayed despite scheduler working normally (can be verified by logs and charts generated).

Early Access: Period Display and "Back to Schedule"

Subversion contains code that allows to display the currently running period on the console. Also, pressing 'S' will now revert thermostat settings back to current period settings if they were altered (and there's a visible indicator for that, too).

Tuesday, January 26, 2010

DZ 3.4 "Scheduler-Barebones" Release Is Out

Changes since 3.3.2

Ability to change thermostat settings based on a schedule. Following settings can be changed:
No user interface is provided, the schedule can be set via configuration file only and cannot be changed during runtime - the focus of this release is to provide a stable and usable feature. Correctness of scheduler operation can for now be verified with data loggers - see configuration guide for details.

And this is how to configure the schedule for now:

The next major release will provide scheduling functionality with Google Calendar being the user interface. Details are described in FAQ: How Schedule Periods Work. Functionality provided by this release will be used as a bootstrap, default or fallback implementation.

* This feature is configurable, but not yet activated

Monday, January 25, 2010

"Cold Start" Bug

(Bug report courtesy of TK)


On DZ startup, all zones immediately go to yellow, but the HVAC never starts.


Bring all calling (yellow) zones to "green" state by changing setpoints, then put setpoints back at the desired value. Even simpler, flip all calling zones off, then on again. The HVAC will start as expected.


Since the bug pops up rarely (there's no need to reboot DZ every now and then, it appears to be rock stable now) , symptoms are immediately obvious, and there is a very simple workaround, the priority is now being set to low.

However, note that a newcomer will be a probable victim of this but: an hour of fiddling with thermostat wires to connect the DZ actuator will easily put the house into a state that will make this bug fire.

But then again, whoever gets to that stage is probably stable enough to be unaffected by such a simple issue :)

Friday, January 22, 2010

FAQ: How Schedule Periods Work

(IMPORTANT: Google calendar has a bug which makes all "forever" recurring events to last for just two years. If the calendar looks empty, scroll the example back to November 2017 to see the actual complex schedule breakdown).

Period scheduling already looks very similar to what is displayed below, and it will look even more like so as wrinkles are ironed out:

Clicking on the calendar button will request to add this calendar to your list of calendars (if you already have a Google account and are logged in) , or present you with Google authentication page. Adding a calendar is a reversible action - you can always remove it later (go to Settings/Calendars and click on Unsubscribe).

The only benefit of adding the calendar to your list is a nice full screen view of the schedule.

In any case, don't forget to click on individual event descriptions to find out how things work (this doesn't require being logged in). Note that the embedded view is scrollable.

Keep in mind that the link is live, and the content will change as details are sorted out.

At this point it is expected that each zone will have its own calendar, to reduce clutter. Moreover, it is currently expected that cooling and heating schedules will be represented by two sets of calendars, with the same purpose - you can easily select and deselect individual calendars, but it'll be a mess if you have more than one set of settings in the same calendar.

Thursday, January 21, 2010

SheevaPlug Update


Here's the timeline of events, for those that are thinking of getting the device:

  • December 17th - ordered the device;
  • January 14th - sent a polite request for status;
  • January 15th - they said they shipped it;
  • January 19th - they shipped it;
  • Jan 21th - it arrived.
Granted, there was a Christmas rush in between, but I guess this is what you realistically have to plan for, give or take.

Wednesday, January 20, 2010

Early Access: Scheduler

Subversion contains code that allows to change zone settings based on schedule. If you can read source code (dz3-scheduler is the module to look at) and configure a Spring IoC container, you will have no trouble utilizing it.

Test cases will give you a good idea how to put a schedule together.

Friday, January 15, 2010

jukebox-jmx presentation

External forces made me put together a short introduction to jukebox-jmx - below. Please remember that this is not a tutorial, but an introduction. If you do need a tutorial, The "Comments" link is right there, below this post.

UPDATE: Permissions fixed.

Wednesday, January 6, 2010

FAQ: "Off" Zones

Q: What does it mean when the zone is "off"?

A: It means that the system will not care about the temperature in thos zone at all, other than recording it if it is configured to do so.

Q: How do the dampers behave in the zone that is off?

A: The dampers will stay open when the HVAC unit is off, to give other systems (forced ventilation, humidifiers, dehumidifiers) chance to work without obstruction. The dampers will stay closed when the HVAC unit is running, unless there is a need to dump excess static pressure, in which case they will open barely enough to provide that.

Use Cases

  • You don't need your bedroom at day, you may safely shut it off.
  • You don't need anything other than the bedroom at night, you may safely shut it off.
Warning: Currently, "off" means "off", and there is no minimum temperature override for heating mode to prevent your pipes from bursting. If there is such a chance, lowering the setpoint to minimum allowable is the way to go. In the future, this override will be introduced.

FAQ: Non-Voting Zones

Q: What does it mean when the zone is made "non-voting"?

A: It means that the zone will not cause the HVAC unit to turn on, if it is the first zone to be calling for heating or cooling. Otherwise, it will behave exactly like it normally does - once the HVAC unit is running, this zone will be satisfied, even if it is the last one to be satisfied.

Keep in mind that zone's voting status is subject to schedule - a zone can be voting in one period and non-voting in another.

Use Cases

Good Case

This feature was originally intended to be used with small spaces like closets and bathrooms, which can overheat or cool down very quickly and cause HVAC unit to turn on and off unnecessarily often ("short cycling") - this is bad on the HVAC unit life, efficiency (it is "warming up" for 5 to 20 minutes, depending on the nature (A/C, heat pump, furnace, electric) and implementation), and electric or gas bill.

If the zone you set to non-voting status is satisfied before other zones are, it is a right thing to do.

Bad Case

This feature is not intended to take care of big rooms for the period when they are not occupied. This can be taken care by either setting those zones to "off" status, or lowering the setpoint (for heating) or raising it (for cooling).

If the zone you set to non-voting status still demands cool or heat after other zones are already satisfied, you're misusing the feature.

Tuesday, January 5, 2010

DZ 3.3.2 "Leakplug" Release Is Out

Changes since 3.3.1

  • (cosmetic, UI) Pressing +/- on the keyboard will now cycle through all available Android screen sizes (in pixels);
  • (fault tolerance) Hardware will now go into "power off" state upon DZ process termination;
  • (JMX) Individual dampers can now be monitored via JMX;
  • (hardware driver) One logical damper can now control multiple physical dampers (more than one register/damper per zone);
  • (optimization) 1-Wire and servo controller drivers now use less heap memory in favor of local variables = less garbage collection chatter;
  • (bugfix) On/off zone switch wors as designed now;
  • (bugfix) Voting zone switch works as designed now;
  • (bugfix) All zones must now be satisfied before the HVAC run ends, not just the one that initiated th run and the ones that happened to enter "calling" state before the first zone was satisfied;
  • (critical bugfix) Removed a memory leak in 1-Wire driver code;
  • (critical bugfix) Removed a memory leak in Servomaster code.

Servomaster released


  • Minor: Parallax family driver code was optimized to reduce garbage collection chatter;
  • Major: Plugged a memory leak causing Servomaster to blow DZ out of memory. This leak was occurring every time the transition controller was being engaged. Root cause of the leak was the missing NDC.remove() at the end of the thread life.

Sunday, January 3, 2010

Memory Leak Hunt: Aftermath

Q: How much memory does DZ need to run?

A: Within JVM, less than 6MB of heap memory and about 19MB of non-heap, total 25MB - that is with all the features turned on, including JMX and console. Take a look at the picture below.

-Xms4m -Xmx4m

At the same time, JVM takes 177MB virtual memory, 57MB resident, and 10MB shared.

Q: How are you planning to prevent memory leaks in the future?

A: Starting with the next release (3.3.2), DZ JVM will be artificially constrained (-Xms4m -Xmx4m) to make sure that if it blows out of memory, it does it very fast and the leak can be identified and reported immediately.

Q: Will it affect system performance?

A: A little bit, you probably shouldn't care. Garbage collection will be happening once every few minutes instead of once every few hours. After you've ran DZ for a few hours (a day for most paranoid) in minimal configuration, you can safely remove the restriction - instructions will be provided within dz-runner script. Keep in mind, though, that amount of memory that JVM is taking out of the system may be higher if you do that, now, that may affect the system performance.

Q: How did you find the leak?

A: It was a trivial sequence of jmap and jhat runs (details at Monitoring and Managing Java SE 6 Platform Applications). In addition, some small and frequent memory allocations in OWAPI were replaced with local variables, to reduce garbage collection chatter.

Q: You're saying the leak is gone, but I keep getting OutOfMemoryException!

A: Possible. Leak free status was verified for DZ core, 1-Wire sensor driver, and Parallax servo controller driver running on Sun's JDK 1.6.0_17 under Ubuntu 9.10. First thing you need to do is to submit a detailed report including your hardware and platform details. jmap file (see the above link) right after the start and some time before the OutOfMemoryException will be much appreciated.

Friday, January 1, 2010

Early Access: Memory Leaks Plugged

Two major memory leaks were plugged this week:

  • One in dz3-owapi module (related to the fact that OWAPI code was instantiating device containers on every browse() (that'll be about once a minute);
  • One in Servomaster transition controller code (NDC.remove() wasn't called at the end of the thread life).
Code is available in Subversion (make sure you get both DZ and Servomaster updates.

Release will follow shortly.