Early Access: Damper Multiplexing

Subversion contains code that allows to control more than one physical damper per zone.

Configuration Guide had been updated accordingly (see Damper Controllers 7/8).

Early Access: Screen Sizes

Pressing + or - on the keyboard will now cycle the Swing GUI through all screen sizes officially supported by Android. Just in case.

Available from Subversion.

DZ 3.3.1 "Housekeeping" Release Is Out

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

Changes since 3.3-INTERFACE

• Critical fix: BalancingDamperController was broken - "off by opposite", works now;
• Bugfix: dampers will now stay open when the HVAC unit is not running, like it was supposed to be to begin with;
• Servos can now be calibrated and reversed, see detailed instructions in Configuration Guide.

Servomaster 0.8.2.2 released

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

CHANGES

This is a maintenance release. No significant changes other than finally removing all System.*.println and adjusting log levels to avoid scaring unsuspecting users with transition controller completions.

Early Access: Servo Calibration

Every servo is different, same goes for servo controllers.

Subversion now contains code that allows you to

• Reverse the servo movement if your mechanical design requires it;
• Provide servo min/max range calibration for controllers that support it;
• Provide limit calibration for controllers that don't.

Configuration Guide will be updated with instructions shortly, for now, take a look at DamperFactory source code and use Spring IoC techniques to configure calibration entities.

Hardware: SheevaPlug

Just bought the SheevaPlug development kit from Globalscale. Will start working on putting DZ3 on it as soon as it arrives (estimate wait is 2-3 weeks).

Feedback from people that have used this device indicates that it is not really usable without external hard drive (either network mount or external USB), you may want to keep that in mind if you decide to follow suit.

On the other hand, changes that are planned for DZ will make disk unnecessary, so you may want to hold that off if running DZ is the only thing you are planning to buy this device for.

Bonus feature for external USB drive would be to find an enclosure that is able to report the disk temperature via smartctl or hddtemp - if you find one, please let me know.

DZ3 Configuration Walkthrough

Beware: this is an experiment, and work in progress (I'm writing the presentation as you're reading it). Just following the "release early, release often" policy to maximize the chance of getting useful feedback in time.



UPDATE: Restriction on minimal font size in your browser will affect the presentation view in the small window - maximizing it will fix the issue.

UPDATE: Permanent location for the configuration guide (this one and subsequent): http://www.homeclimatecontrol.com/configuration-guide

The Competition: iComfort™

The Zone Control Blog posted a reference to iComfort™ Communicating Thermostat.

This is the most comprehensive Web application that I've seen so far. There is a demo you can play with (follow the link, there's a username and password for the demo).

The demo vividly reminds me of my experience working with Google Checkout API. Don't know what it is today, but back when I was working with it the callback deadline was 3 seconds.

Three seconds.

You blow the deadline, you don't exist for the Checkout engine, and your customer pays default shipping rate, not the shipping rate that applies to the product you're selling. Oversize product? Extra heavy product? Your problem, you blew the deadline. Go away, you don't exist.

Call me arrogant, and don't forget to throw rocks at me and stick it to my face when the DZ Web application is up and running.

FAQ: minimal sensor hardware

Q: What is the minimal set of sensor hardware do I need to run DZ on?

A: With some luck, you already have it. Look for a DZ entity called ShellSensor, it will allow you to use information provided by lm_sensors or hddtemp to feed the rest of DZ on.

DZ 3.3 "Interface" Release Is Out

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

How To Activate The Interface

This is the configuration snippet that makes it happen:

<bean id="console"
     class="net.sf.dz3.view.swing.Console"
     init-method="show">
 <constructor-arg index="0" type="java.util.Set">
   <set>
     <ref bean="(your-thermostats-here)" />
   </set>
 </constructor-arg>
</bean>

Right now, only thermostats are supported. Later, all sorts of entities will be supported along with thermostats - just like it's been happening with loggers and JMX instrumentation.

How To Make Sense Out Of It

There's quite a few things that you see there.

• There are six zones configured;
• You're looking at the leftmost;
• The name of this zone is "Bedroom"
• Current temperature is 19.6°C - it'll be too cold if it was in Fahrenheit;
• Setpoint is 20°C;
• This zone is configured in heating mode - setpoint font is red;
• Schedule will not affect this zone's setpoint - this is what the lock icon is indicating, also the orange vertical stripe on this zone's bar on top;
• This zone is not voting (more about it below) - this is what the stop icon is indicating, also the dark red vertical stripe on this zone's bar on the top;
• Second and third zones from the left are also on hold (orange vertical stripe);
• Second and third zones from the left are not only on hold, but are also off (bar icons are not green but gray);
  
• Fourth from the left zone is not voting, just like the first;
• Fourth from the left zone is outside of tolerance, a.k.a. "calling" (the bar is yellow, not green);
• Rightmost zone's sensor is faulty (the bar on top is dark red).

Background will also change depending on current operating mode, whether the HVAC unit is working, and where exactly the current zone is within the tolerance limits, but one picture is worth a thousand words - you'll see what I'm talking about when you watch it work.

Fair warning: the background behavior will change in future releases, don't get used to it too much.

How To Control It

The only way to control the application at this time is with keyboard shortcuts:

• Left/Right arrows change the currently selected zone;
• Up/Down arrows change the setpoint for the currently selected zone;
• H puts the zone on hold or takes it off it;
• V toggles voting status;
• O toggles the zone on and off;
• C and F toggle display between Celsius and Fahrenheit for all zones.
  

What Is "Voting"?

Simplest explanation is this: you won't want to turn on the HVAC because the temperature in your walk-in closet is too high/low, but if the HVAC already working, it'll be nice to have the temperature in the closet decent enough before it stops. A good reason to have a non-voting zone in the first place is that it is by implication a dump zone.

Look At The Bars Again

Upon close consideration, you might notice that each zone bar has a level indicator. It shows where within te tolerance limit each zone is, so you will have a good understanding how your whole house feels just by looking at this contraption.

One of reasons this is done this way is an observation on how people behave given dull thermostat reaction to slowly changing conditions (this haunts everyone in mid-season): sometimes it takes hours for your thermostat to realize that the temperature's been a hairdrop from triggering the HVAC all along. And what unhappy people do is start pressing buttons hoping to coax their thermostat to make something happen - even if it was already about to do that anyway. And of course, then they complain that now it's too cold or hot, and have to "fix" thermostat settings again.

With this display being there, they will hopefully see what the system is about to do and, knowing that, will have less inclination to fiddle with it, upsetting the balance.

Credits

Silk icon set by Mark James was used in this release.

The Competition: X300™

A representative of an interesting product family.

I don't quite understand the rationale for feature set selection - the device supports

• Eternet connector (very nice),
• relays (very nice),
  
• email alerts (that I can understand),
• Modbus/TCP (that's an impressive industrial protocol, but I don't remeber any home automation application that suports it),
• SNMP (same as Modbus),
• BASIC interpreter (why would anyone want that today???),
• but just 8 sensors. Eight? While using DS18B20, implying 1-Wire, which is potentially unlimited? You're kidding. I'd say this is a deal breaker.

Tihs device smells of an identity crisis to me - ask yourself a question, who is the consumer of this device? Too heavily loaded with industrial features for consumer market, too limited hardware for industrial. Or maybe the overall state of affairs in industrial applications is more grim than I thought.



This is the only device to date (that I have found so far) that has a mobile application. Or, should I say, has a picture of an application running on an iPhone - App Store search yielded no results, and there were no application links that I could find.

Early Access: Usable GUI Again

Subversion contains code for still ugly GUI that can do three things right:

• Display the zone name, current temperature and setpoint for the selected zone;
• Flip back and forth through zones (left/right arrows);
• Change setpoint for the currently selected zone (up/down arrows).

There are also subtle visual cues to what the system is currently doing, and there will be more and more as time goes by.

New features would be available via keystrokes. Feel free to try all keys on the keyboard, you're unlikely to break something and you'll see what's happening. There's a good time that by the time you read this, hold, voting, off and Fahrenheit vs. Celsius switches will be already implemented.

No mouse interaction other than gestures (drag left, right, up and down) and possibly a right click menu will be provided. It is planned that all major features will be available via single key press - or there will be advanced interface for the feature that will not be a part of the GUI.

Saturation Limit, Configuration Testing and Other Disasters

This is what happens when you forget to specify the saturation limit. P=-1, I=-0.0000002, D=0, no saturation limit is specified. Oops...

Wonder how many hours it'll take to get back in shape - no big deal, since HVAC is not controlled by DZ at this time, tit's just working as a testbed at this location. But a runaway condition like that on real hardware would have cost you a pretty dime, and possibly damaged hardware.

A saturation limit of, say, 3 would've fixed the situation.

Which brings up a question - how do you test configuration changes without jeopardizing very expensive hardware? The answer is trivial - you clone control elements of the configuration, use elements that havbe been tried and found correct to control the hardware, and use untested elements for monitoring only. Yes, there will be differentces between real behavior and tested behavior later due to the fact that control outputs from elements out of feedback loop (actual hardware control) are ignored, but you will at least get a rough idea of how they will perform.

The Competition: Advanced Temperature Control

Doesn't quite look in the same weight category as DZ, but it is. DZ, despite being all primitive and DIYy, is limited only by hardware. Give it commercial class hardware - get commercial class performance.

Just give me a second to finish the UI, all right? :)

Speaking of which, they have a nice touch screen as well.

(Image: Control4)


UPDATE (2012/02/22): All links are gone. Cursory search on their site doesn't produce anything close to original results, so I've decided to just leave them as is, for those with enough time to investigate. Oh, and by the way, DZ has a shiny UI now as well.

DZ 3.2.2 "Humidor" Release Is Out

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

IMPROVEMENTS

Added ability to use a humidity sensor based on com.dalsemi.onewire.container.HumidityContainer to operate a humidifier and/or dehumidifier.

This is a snippet of configuration that makes it work:

<bean id="device_factory"
     class="net.sf.dz3.device.sensor.impl.onewire.OwapiDeviceFactory"
     init-method="start">
<constructor-arg index="0" value="/dev/ttyUSB0" />
<constructor-arg index="1" value="regular" />
</bean>

<bean id="humidity_sensor-6500000055FF1A26"
     factory-bean="device_factory"
     factory-method="getHumiditySensor">
<constructor-arg value="6500000055FF1A26" />
</bean>

The humidity_sensor-6500000055FF1A26 bean is further used to feed te thermostat bean that is, however, not controlling the heating or cooling device, but a humidifier or dehumidifier instead - the control chain is identical.

UPDATE: It was reported that there is at least one humidity sensor reported as a temperature sensor - the HT3-R1-A board. In this case, you don't even need to change the factory-method attribute.

DZ3 As A LEGO Construction Set

Q: Can I use DZ3 to run a humidifier?

A: Yes.

Q: Can I do it so the humidifier runs only when the furnace is on?

A: Yes, but some tinkering with relays is necessary today.

Q: But it is not documented!!!

A: So what? There's a thousand things that DZ3 is supposed to do when it is done and finished, most of them unpublished for this or that reason (sometimes as simple as "I didn't get to writing about that yet").

The architecture was intentionally created as generic, transparent and extensible and as possible, and if you want to do something that hasn't yet been documented as "released", sometimes all you have to do is to take a second look at components that are already available.

So, back to the original question, how do you run DZ as a humidifier? You use the OwapiDeviceFactory with getHumiditySensor (I don't remember if I even implemented it yet, but even if I didn't, it's a no-brainer change - look at how getTemperatureSensor is implemented. In any case, it'll be in within a couple of days for sure UPDATE: fixed). Then you feed the output of that sensor into a virtual thermostat - but with the setpoint being a humidity, not temperature. The rest of the chain is obvious - just like with heating and cooling, only this time the output device is the humidifier.

Q: Can I use DZ3 to run a dehumidifier?

A: Yes, invert P and I components of the thermostat PID controller.

Not Quite Competition: What Other Geeks Do

A pretty long article comes with the picture. The device resolves as Programmable Communicating Thermostat. Just like with ENV-VST-C, California Title 24 is mentioned.

They call the interface simple, but I think it recembles the DZ1 interface (scroll down a bit to find it, it has an unmistakably mainframe feel to it).

Whereas other manufacturers loudly proclaim "money saving features" with pretty vague claims of "up to" "if used correctly", I have a gut feeling that this device does indeed have an emphasis on actual energy conservation.

(Image: Physorg)

The Competition: ecobee

Pretty interesting feature set, including Internet access. Features are well documented, with video presentations. Site navigation is pretty crowded, though, be careful not to miss important links just below the green header.

Terms of sale call for advanced law degree, which makes me a bit nervous.

(Image: ecobee)

The Competition: Emme

Allegedly coming April July August 2010, reservation is encouraged.

Favorite quote (emphasis mine):

Three wireless temperature sensors...

(Image: Emme)

The Competition: ENV-VST-C

Apparently, doesn't support zoning per se. On the other hand, lots of interesting features, and pretty complete documentation. Along with other interesting things.

Some things in it are hilarious, though - I'm still waiting for feedback from a HVAC expert on some of them, will publish conclusions when I get it back.

In any case, merits thorough investigation. I don't think you can buy it though - let me know if you learn otherwise.

(Image: AMX)

New Label: Competition

Lately, I'm finding quite a few new designs that weren't around last time when DIY Zoning was in active development. Keeping the traditions of full disclosure, I'm planning to publish links to products and/or product reviews that are in direct competition to DZ - let's face it, not everyone is a DIY type, but everyone needs to stay cool (or warm, pick your poison).

So, there: http://diy-zoning.blogspot.com/search/label/competition.

The Competition: Honeywell Prestige HD

The best things to do with competition are to know them and to respect them.

Here's what our competition is, sort of:



Go read the Honeywell Touchscreen Thermostat and Portable Remote Review and keep in mind that there is a subtle distinction between Prestige HD and Prestige SD (about a hundred dollars or so).

Then go do some shopping (zoning system not included) and hopefully come back - if not today, then in a few weeks or months when the GUI (and other unannounced bells and whistles) is back to its former glory and beyond, for the price of Prestige with comparable feature set is steep indeed.

By the way, DZ is going to look nothing like Prestige :)

UPDATE: This is what it looks like. This is what it looks like :)

Favorite quote from the Homeowner Brochure (emphasis mine):

You can even name each of your zones on the Portable Comfort Control by having your contractor customize it with more than 60 different naming options - upstairs, master bedroom, office - even wine cellar and home theater!

(Image Credit: Gizmodo.com)

Early Access: Swing GUI Back From The Dead

Subversion contains code for extremely ugly GUI that is able to do one thing: display current and setpoint temperature for all configured zones, and change color depending on whether DZ is configured for cooling and heating mode and whether the zone is calling.

Ugly or not, it sure beats using JMX to see the current temperature and setpoints.

Here's a configuration snippet that makes this happen:

<bean id="console" class="net.sf.dz3.view.swing.Console"
     init-method="show">
<constructor-arg index="0" type="java.util.Set">
 <set>
   <ref bean="thermostat-6500000055FF1A26" />
   <ref bean="thermostat-0500080021C9B810" />
 </set>
</constructor-arg>
</bean>

Not just thermostats may be added, but any DZ objects - if they can't be displayed, they will be simply ignored with an error message in the log.

Next Step

Providing controls to change the setpoint, of course. Working on it.

Note on Register Mechanical Design

I've just been told by one of DZ users that his design uses about 90° of servo motion to move from totally open to totally closed position. My kneejerk reaction was -

Design your registers so 180° of servo travel is necessary to move the damper from fully closed to fully open position.

Primary reason for this is that the torque required from the servo is proportionally less, hence, less stress, longer usable life and quieter operation - servos are becoming to growl as the load goes up, and as their age goes up.

There are several things you need to keep in mind when you're designing products using servos.

Servo range of motion

All servos, being analog devices, are different. Normally, servos are supposed to work with PWM control signal being between 200μsec and 2000μsec, but there are instances that can go as low as 160μsec and as high as 2300μsec.

Servo controller signal range

Not all servo controllers are created equal, either. Some of them support advanced range limiting and calibration options, some of them are incapable of producing anything other than a predefined range of signals with no calibration options whatsoever - the only calibration option would be to design the device in such a way that the servo travel is artificially limited, and later use software controlled range limiting to make things work properly.

Hardware vs. Software

DZ3 will support both range limit and calibration within coming weeks (DZ2 supported it already, and it's just a matter of porting it over), so your hardware (both servos and controllers) is the only limitation for your design.

On the picture: existing register designed to utilize 180° of servo travel.

FAQ: Switch Between Heating & Cooling

Q: How do I switch DZ into heating or cooling mode?

A: For cooling, values of P and I for the PID controller associated with the thermostat have to be positive, for heating, negative.

IMPORTANT: Make sure that P and I values for all thermostats are on the same side, and that they are synchronized with the operation of the actual HVAC device, or you will have a runaway condition in zones that are on the wrong side. In other words, your HVAC will run forever.

Q: Why is it so complicated?

A: Because it makes things much, much simpler in the bigger picture, the time for which hasn't come yet - but I'm working on it.

Q: Are you ever going to make it so normal people can use it?

A: Yes.

FAQ: Thermostat Sensitivity

Q: Default thermostat settings cause too much of a temperature swing, how do I make my thermostat more sensitive?

A: You increase the value of P for the PID controller associated with this thermostat. Default value of P (1.0) corresponds to a deadband from 1°C below the setpoint to 1°C above. Increasing P to 2 will cause that to change to a range from 0.5°C below the setpoint to 0.5°C above.

Likewise, if you want to dumb down your thermostat because the HVAC switches on and off too often, you need to decrease the value of P. However, be careful, for short cycling (the HVAC term for this phenomenon) may have different causes - but you'll be able to easily see the cause for them on charts DZ generates.

Q: Will there be a UI control for that?

A: Yes.

DZ 3.2.1 Maintenance Release

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

BUGFIXES

• Race condition was preventing normal initialization of Parallax and possibly other serial servo controllers;
• NaN damper position was being generated in BalancingDamperController, passed down to dampers and accepted by them under some circumstances.

IMPROVEMENTS

• OwapiDeviceFactory now reports devices present on 1-Wire bus via JMX;
• Damper controllers now support JMX insrumentation.

DZ 3.2 "Barebones" Release Is Out

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

CHANGES since 3.1-PASSIVE

Most important change: you can control your HVAC equipment again.

• Fixed JMX control - only monitoring was possible before, complete control is possible now for attributes exposed;
• Improved JMX representation - composite objects are now rendered correctly;
• Ported HVAC equipment control logic from DZ1 code base.

CONFIGURATION

Blog format doesn't play well with XML excerpts, and as configuration is becoming more and more complex, it becomes more and more difficult to post it here. I'm currently writing the DZ3 configuration guide, and when it is ready, it'll be posted at DIY Zoning Project site, and this post will be updated to reflect the actual page.

Having said that, let me emphasize that this is an experimental release with many known bugts and even more unknown. Hence,

BIG RED WARNING

Just like it says here: YOU MUST UNDERSTAND THE CONSEQUENCES AND TAKE RESPONSIBILITY. THIS IS YOUR EQUIPMENT. IF YOU DO IT, YOU'RE ON YOUR OWN. IF IT BREAKS, YOU KEEP BOTH PIECES.

NEXT RELEASE

There are several possible directions where development efforts may be directed, and your voice counts. Please take a look at the poll on your right, and choose the option that suits you best. For now, here's an extended description of these directions.

Interface

Right now, this project is in a geek-only mode - Spring configuration is needed to boot it, JMX is the only way to control it. A GUI is much needed, with three distinctly different versions possible:

• GUI-Swing
• GUI-Web
• GUI-Android

GUI-iPhone was also requested, but I neither have the iPhone itself, nor tany inclination whatsoever to do anything about it. If you do, welcome to the club, let's talk.

Configurator

Some day, it would be possible to have a visual, drag and drop PnP configurator for DZ. However, given the ratio of time it takes to learn how to configure it with Spring XML file (when the tutorials are done, that is) to the time it will stay up, chances of a Configurator materializing are slim. Nevertheless, the option is still available.

Distributed Operation

If you have several computers or other devices that can report their thermal state over TCP/IP, this option would be tempting. This is also very useful for integrating DZ with other home automation projects (MisterHouse comes immediately to mind).

Housekeeping

Like I said, Barebones is an experimental release. Of course, obvious bugs and/or improvements are already logged and being worked on, but again, priority matters, so this option is up. By the way, bug tracker is available, though right now it's still littered with DZ1 artifacts.

Something else?

Did I forget anything? Let me know.

Jukebox 6.1 is out

WHERE TO GET IT

• SourceForge downloads;
• Google Code downloads;
• Subversion repository, the best place. Go for jukebox-master subtree.
  

WHAT'S NEW?

JMX setAttribute() and setAttributes() is now supported.

Quite embarrassing - I thought I implemented JMX mutators all along when I was releasing 6.0, this is even mentioned in release notes. Now it works for real.

servomaster-serial 0.8.2.1 released

CHANGES

Fixed constructor visibility for Parallax serial controller - it wasn't possible to instantiate it via Spring before. If you're not using Parallax servo controller, or not using it with DZ or Spring, you don't need this.

DOWNLOADS

Available from SourceForge and Google Code.

DZ3 FAQ: Everything in Celsius?

Q: Why is everything in C°?
A: To avoid a disaster like this.

Q: Will I be able to specify setpoints and see display and monitoring data in F°?
A: Yes, the user interface will take care of this. Default units will be determined by where you are, you're likely to never notice anything.

Development Tools: IntelliJ IDEA

This is a reminder, for those who didn't know or forgot: IntelliJ IDEA, which you normally have to pay for, also provides an Open Source License, for which you have to qualify.

According to the license terms (at the time of writing, emphasis is mine),

"Licensee" means an open source development group specified in the License Certificate.

If you think you are planning to contribute, please contact me for licensing details.

Configuration Change Required

If you're using a Subversion snapshot of the code and keeping it up to date, you'll have to change the configuration for 1-Wire device factory:

• Was: net.sf.dz3.device.sensor.impl.onewire.DeviceFactory
• Now: net.sf.dz3.device.sensor.impl.onewire.OwapiDeviceFactory

Power Can Violate Your Privacy, Too

Remember I've been telling you not to publish your temperature graphs on Internet for years? All right, with DZ you have a choice to publish or not to publish, but not so with your power company.


Here's the article: Experts: Smart grid poses privacy risks

Well, here's my take on it: if you wanna get, you wanna give. Want to save a penny, gotta let them know what you're doing. Privacy is dead - regrettable, but a fact. You're back to village life, where everyone knows everything about everyone. Just on a new level, that's all.

<via /.>

DZ3: Running Without Dampers

When I heard this idea for the first time, I though - wait, it doesn't make sense, what's the gain? Then it dawned on me - the showstopper has just been removed.

What is stopping *you* from installing this system in your house? Most probably, the idea about ugly wires all over, and/or expensive wiring and wall repairs that will have to follow.

Now, what do you need to do if you run this system *without* dampers connected? Install as many wireless sensors as you wish or can afford, and a small control unit (like this, for example) somewhere in the mechanical room where your HVAC unit is installed. You don't even have to disconnect the existing thermostat and deal with te wall repairs. Now, let's consider both sides of the coin.

DISADVANTAGES

You won't be able to optimize the behavior of more than one zone at the same time. It's just like the good old thermostat that you carry in your pocket, and the house follows you. Hence, no energy conservation. But, this is a trade off, and if you calculate ROI, it may turn out that possible savings in electric bill vs. cost of wiring may break even many years from now.

BENEFITS

• You can improve thermal behavior of your house instantly. Using different setpoints, zone shutoffs and zone voting settings (see detailed explanation here), you can have the desired temperature where you are, not where the thermostat is.
• You don't have to destroy your walls doing wiring and deal with repairs and dust.
• You will be able to collect monitoring data that will allow you to better assess what exactly do you need to do with your house in order to improve its thermal behavior.
  

So there, pick your poison.

(Idea credit: DC)

DZ NextGen Seeded: Home Climate Control

If you set your goals ridiculously high and it’s a failure, you will fail above everyone else’s success.

-- James Cameron, director of Terminator and Titanic, from The New Yorker

From the very beginning, one of DZ's goals was to make temperature zoning solutions accessible to the general population. That never happened. One of the reasons for that is that the niche it occupied is very narrow, and people don't even look into the dusty corner of the Web where the opening to this niche is.

#1 on search for temperature zoning, you say? So what, they say? Who cares?

And they're right, for in order to be looking into this niche you will have to have already investigated quite a bit, and already know words "zoning", and "hvac", and that's not what was supposed to happen. The person in need was supposed to find this project right away, and be able to use it right away.

That didn't happen, either. When you ask a geek for a result, you get a result only a geek can use.

So the next crusade, starting today, is to fix these two things: first, make this project easier to find, second, make it actually usable to people that have nothing but money in the pocket, and not too much money by that, either. Rich or poor, everyone deserves to live in comfort, and let's try to make that happen.

Here comes, http://homeclimatecontrol.com/.

Not much there now, but it takes time to build everything. Stay tuned.

DZ 3.1 "Passive" Release Is Out

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

CHANGES since 3.0-INSTRUMENTATION

• Integrated Servomaster again (see dz3-servomaster module);
• Passive Mode operation is possible again after a long while;
• Another round of 1-Wire driver code refactoring, streamlined bus operation, fixed several race conditions;
• Replaced hardcoded RxTx dependency with the reference to Maven Central Repository.

Unlike last time, there are no instructions to configure servo controllers along with the rest of the system, it is not possible to run it without detailed understanding of how to configure the whole system. However, this blog contains more than enough information on that - under /label/configuration. If this turns out to be insufficient, join the mailing list and start asking questions.

NEXT RELEASE

3.2-BAREBONES, for real this time. I hope. As soon as that relay board makes it here.

Servomaster 0.8.2 released

This is a maintenance update for 0.8.1.

CHANGES

• servomaster-serial: now uses RxTx dependency available from Maven Central Repository, you don't have to manually install it (though you do have to take care of platform libraries, that'll come later);
• servomaster-usb: now allows Phidget Quad Servo to be instantiated by Spring Framework (DZ3 dz-servomaster requires it).

DOWNLOADS

Available from SourceForge and Google Code.

DZ3 FAQ: My servos growl and jump!

Q: I've used R/C servos to control my registers/dampers, just as you said, together with controllers that you told me to, but the servos growl even when they don't move!

A: Three causes are possible (ordered by probability):

• Power is insufficient at the register/damper location, wiring is too weak. Run a 16 gauge speaker wire to it, and put a 470μF electrolytic capacitor from ground to power at each servo, this worked for me.
• Register/damper is too tight for the servo you used. Either loosen it up mechanically and lubricate well, or use a higher torque servo.
• Servo is getting old. Old setup I used to run 2001 to 2003 had no problems, but the same servos I used back then growl today, even though they haven't been used for last five years.

Q: Servos are jerking and generally misbehaving, why?

A: Control signal is too weak, servo doesn't recognize it as such anymore. Google up a "servo booster" (there are too many around to recommend anything specific) and install it at servo.

DZ3 Configuration: 1-Wire Sensors

Being too excited about the fact that OWAPI code started working again, I forgot to mention how to configure it for use with not just loggers, but to actually do something useful. Here:

<bean id="device_factory"
     class="net.sf.dz3.device.sensor.impl.onewire.DeviceFactory"
     init-method="start">
<constructor-arg index="0" value="/dev/ttyUSB0"/>    
<constructor-arg index="1" value="regular"/>    
</bean>

<bean id="temperature_sensor-6500000055FF1A26"
factory-bean="device_factory"
factory-method="getTemperatureSensor">
<constructor-arg value="6500000055FF1A26"/>
</bean>

The temperature_sensor-6500000055FF1A26 bean can be used in further configuration as usual.

NOTE: If you're inclined to fiddle with configuration before the GUI configurator is out, you might just as well get familiar with Spring Framework, if you aren't already. A powerful tool. All you need for now is the IoC container configuration.

"Passive Mode": Early Access

As of now, Phidget Quad Servo controller is happily shuffling a servo on my desk, controlled by the code that you can get from Subversion trunk. This is what you have to add to the configuration in order to enable it:

    <bean id="damper_factory" class="net.sf.dz3.device.actuator.servomaster.DamperFactory">
 <constructor-arg index="0" value="net.sf.servomaster.device.impl.usb.phidget.QuadServoController"/>
 <constructor-arg index="1" value="00515"/>    
  </bean>

  <bean id="damper-quad_servo0"
   factory-bean="damper_factory"
   factory-method="getDamper">
   <constructor-arg index="0" value="USB Bus Powered Servo"/>
   <constructor-arg index="1" value="0"/>
  </bean>

Other servo controllers will be supported as well. Please answer the poll questions (on your right) to let me know which drivers I have to take care of first.

As of right now, DZ3 is completely capable of supporting the passive mode. I'm not going to release the code just yet, until all prerequisites for Barebones are satisfied.

Next Release: Barebones

WHAT'S IN?

Essential things that didn't make it into Instrumentation release, namely:

1. Servo controller integration (see Servomaster);
2. 1-Wire switch based HVAC driver.

This release will allow to run the complete system (including HVAC unit control) with single mode operation (either heating or cooling), no schedule, and no GUI (thermostat setpoints controlled via JMX).

WHEN?

I expect the code to be finished within a week - servo controller first (so the whole system can be run in passive mode), then HVAC driver.

However, I'm yet to acquire a relay board (all I have now is raw DS2406 switches driving LEDs), so some tweaking may occur afterwords, when it is actually connected - besides, it's not a good time to conduct real life experiments at my location now, there is no heating nor cooling required until, I believe, middle of December.

UPDATE (2009/11/12): 8 channel I/O 8 relay board is in the mail.
UPDATE (2009/11/16): I lied. Next release is 3.1-PASSIVE.

DZ3 Instrumentation Release is out

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

Don't forget to read release notes.

DZ3 Instrumentation Release: Tagged in Subversion

Source is ready for consumption, available from Subversion repository with the root being https://diy-zoning.svn.sourceforge.net/svnroot/diy-zoning/tags/3.0-INSTRUMENTATION.

Packed archive will be available for download shortly.

Please check the release notes.

UPDATE: released.

DZ3 Instrumentation Release: What's In, What's Not

Any large working system has inevitably evolved from a small working system.

-- Source lost in time

WHAT'S IN

• 1-Wire Sensors. Temperature and humidity for now;
• Shell Sensor. If you can extract information from your hardware via shell script, this is what you use to make it available to DZ;
• Thermostat;
• Zone Controller;
• HVAC Unit abstraction;
• Damper Controller for bang-bang dampers;
• Damper Controller for modulating dampers;
• Complete data logging for every measurement point in between, including hysteresis and PID controllers inside of thermostat;
• JMX instrumentation (quite comprehensive) and control (limited for now).

WHAT'S NOT

Unfortunately, some essential stuff -

• Servo controller integration;
• HVAC Unit driver;
• GUI;
• Scheduler

And some not so essential -

• DAC & Core talking over TCP;
• Obviously, sensor discovery over LAN;
• xAP, xPL loggers (try, they most probably work, but I haven't checked).

Reason for this is that I wanted to clean up issues accumulated over years, and make sure that the system is completely transparent, can be monitored, and bugs can be seen visually (and most of them are). So the net result of this effort, so far, is a working stable system with no actual outputs (other than data loggers). You can watch it, but you can't touch it.

SO HOW IS IT USEFUL?

Well, if you've never had DZ installed because it was too complex to install and configure, the day of Instrumentation Release is your lucky day. What is already done is a turnkey acceptance of all the sensor network with no configuration beyond 1-Wire adapter port name necessary. Hang the sensors on the wall, start DZ3 and watch your house's thermal behavior in gory details.

If you do already have some variant of DZ installed and connected to actuators, then hold off for a short while, the good stuff is coming.

WHAT'S NEXT?

Exactly what is missing from this release:

• Servo controller integration;
• HVAC Unit driver;
• JMX instrumentation allowing to actually control the thermostat setpoints.

GUI and scheduler ports are still on a back burner for now, the priority is a stable and working system, not a nice looking system.

UPDATE: released.

DZ3 Instrumentation Release: Early Access

1-Wire sensor access works in the Subversion code, go for trunk/dz3-master directory tree.

Here's a simple configuration file to have a turnkey logger for all of your existing 1-Wire sensor network, with JMX instrumentation to boot:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
          http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
         
   <bean id="device_factory" class="net.sf.dz3.device.sensor.impl.onewire.DeviceFactory" init-method="start">
 <constructor-arg index="0" value="/dev/ttyUSB0"/>    
 <constructor-arg index="1" value="regular"/>    
   </bean>

<!-- Loggers -->
<bean id="rrdtool" class="java.io.File">
 <constructor-arg type="java.lang.String" value="/usr/bin/rrdtool"/>
</bean>
<bean id="rrdbase_onewire" class="java.io.File">
 <constructor-arg type="java.lang.String" value="./rrd-onewire"/>
</bean>
<bean id="rrdlogger_onewire" class="net.sf.jukebox.datastream.logger.impl.rrd.RrdLogger" init-method="start">
 <constructor-arg index="0" type="java.util.Set">
  <set>
   <ref bean="device_factory"/>
  </set>
 </constructor-arg>
 <constructor-arg index="1" type="java.io.File" ref="rrdbase_onewire"/>
 <constructor-arg index="2" type="java.io.File" ref="rrdtool"/>
</bean>

<!-- JMX configuration -->
<bean id="jmx-wrapper" class="net.sf.jukebox.jmx.JmxWrapper">
 <constructor-arg index="0" type="java.util.Set">
  <set>
   <ref bean="device_factory"/>
  </set>
 </constructor-arg>
</bean>
</beans>

Just watch the paths, that's all.

Instrumentation Release itself will be finalized either late tonight, or tomorrow. The difference between now and then is that the path from DeviceFactory to TemperatureSensor is currently broken. The rest of the system (if configured) will work, except for the actual physical control - actuators haven't been ported yet.

UPDATE: release source is tagged in Subversion. The path in question has been created, obviously.

Jukebox 6.0 is out

The venerable Jukebox just had a major uplift, 6.0.

WHERE TO GET IT

• SourceForge downloads;
• Google Code downloads;
• Subversion repository, the best place. Go for jukebox-master subtree.
  

WHAT'S NEW?

Lots.

Build: Maven based, at long last.

Configuration: self-aware object model is being eventually retired in favor of dependency injection (I know this is long overdue, but hey, how often Jukebox is released? Projects based on it usually just work and don't require uplifts). Jukebox entities are now mostly Spring ready.

jukebox-datastream: Pulled in from DIY Zoning, it has become way too common to afford to keep it contained there. Works with any kind of signal now.

jukebox-jmx: All you have to do in order to expose a method for JMX instrumentation now is to add a @JmxAttribute annotation. Works just like JavaBeans, on both accessor and mutator methods. Word of warning, this is based on JDK 1.6 JMX, not JDK 1.5 JMX - it will not work there. And oh, by the way, you can use it independently from the rest of Jukebox.

jukebox-fsm: Implementation of a Finite State Machine based on generics. 'nuff said.

The rest of Jukebox hasn't changed much, except for rigorous JDK 1.6 compliance uplift and testing.

DZ3 FAQ: Tests break on my system!

DZ3 tests at this point may often be host specific and work only on the host DZ3 is being developed on. If a specific test breaks on your box, you have two options:

• Modify the test to fit your system. The problem is often caused a different path (for example, /dev/ttyS0 instead of /dev/ttyUSB0). If it is bigger than that, simply removing the test will help.
• Skip tests altogether by running mvn install -Dmaven.test.skip instead of mvn install.

If you think the test shouldn't break, please send me the diff(1), if any, between the original test and yours, and output from the test run, so I can investigate your problem and fix it.

Servomaster 0.8.1 released

This is a bugfix release for 0.8-UNDEAD.

CHANGES

• Fixed Parallax family range/min and range/max;
• Updated driver release notes.

DOWNLOADS

Available from SourceForge and Google Code.

OWAPI Refactoring, Round 2

I've done it once already. Haven't seen the code for a while, and when I looked at it again, I didn't like what I saw.

This is not going to be a lengthy process, just a quick walkthrough with a primary purpose to bring the OWAPI code base up to DZ3 coding standards.

DZ2 code base used OWAPI 1.00 as a base, and this is exactly what is being refactored further. Since that time, a new release came out, OWAPI 1.10. It doesn't look like changes between 1.00 and 1.10 are significant as far as DZ is concerned, and don't really care at this time, for there are reasons that look tangible enough to me:

• Primary goal at this time is to release the complete working installation of DZ3 as soon as possible;
• It looks like enthusiasm for 1-Wire sensor networks is dwinding;
• OWPAI 1.10 still doesn't support the 1-Wire USB Adapter under Linux, and my workstation already doesn't have a serial port;
• New sensor networ standards are coming out, and 1-Wire is just one of them.

If it turns out that there's a significant demand for features offered by OWAPI 1.10, well, there's always a diff(1) and patch(1).

Bump: Green Dryer

There's been a comment on Green Dryer post that y'all might like:

You can find a nice version of this along with a custom base that raises the height of the dryer at:

http://www.heat-helper.com/

Thanks, Owen. Good timing, too - winter is coming.

First thing I would be concerned about before you reach for your wallet, though, is the smell that will get in if you're using scented sheets in your dryer. It is not really noticeable inside of the house, but I can tell you that if you walk down the street when someone's dryer is working, you can smell it from over a hundred feet away.

An easy test for that would be to move your drier away from the wall, disconnect the air hose and turn it on like you usually do - you'll know right away whether you'd be willing to tolerate that smell in the house or not.

Another consideration is that there will be some heat dissipation that you don't need during hot summer months. Relatively easy to deal with - it's not that big of a deal to reach behind the dryer and reconnect the hose directly to the dryer vent, especially keeping in mind that you have to clean that space couple of times a year anyway.

If that's the case, though, then I wonder why not just simply disconnect the hose from the dryer and let it be.

And, last but not least, the amount of lint and debris that comes out of the dryer is significant even with the stock dryer filter in place and cleaned before each run - if you're allergic, you might think twice about directing exhaust air into the house.

Servomaster 0.8-UNDEAD released

Fighting software rot is a difficult business.

To make DZ3 operational, Servomaster uplift was necessary.

CHANGES

• Accommodated a less painful build tool (the project is now Maven2 compliant, like the rest of DZ3 and its dependencies);
• Split the project into three parts: abstractions (servomaster-common), serial (servomaster-serial) and USB (servomaster-usb). Serial and USB packages require the common package to build, but are independent from each other;
• Replaced ugly System.*.println with log4j (been done elsewhere long time ago, but wasn't really necessary in Servomaster because it just worked);
• Package names are now net.sf.servomaster.*, for consistency, and to ensure the break away from the old code base.
  

HOW TO MAKE IT WORK

Get the necessary modules from the Subversion repository.

servomaster-common requires zero involvement (other than having Maven, or, even better, Eclipse Galileo installed).

For servomaster-serial you'll need RxTx 2.1.7. RxTx used to be a pain point, but right now (on Ubuntu 9.04 and 9.10) it's a matter of executing

sudo apt-get install librxtx-java

and you're good to go (POM file points where the library is).

I didn't get my hands on installing this part on Fedora yet, will update this page as soon as I do (by the way, your feedback is welcome).

For servomaster-usb, you'll need javax.usb. Roles flipped, now this is the pain point - there's no automated way to get it installed, get to the site and follow instructions. However, instructons are more or less painless, and once you get it there, it won't require much interaction. Make sure you match te POM file content with actual jar file name - JSR80 jar file is the only one you need to build, but you'll need all three to make it work.

DZ3: JMX Instrumentation and Control

If you update the DZ runner shell script to its current form (just add -Dcom.sun.management.jmxremote to Java command line), you can use JConsole to monitor and control DZ3. This is what it looks like (click to enlarge):



And this is how to make it happen (see previous examples for context):

<!-- JMX configuration -->
<bean id="jmx-wrapper" class="net.sf.jukebox.jmx.JmxWrapper">
  <constructor-arg index="0" type="java.util.Set">
    <set>
      <ref bean="temperature_sensor-6EE055000000"/>
      <ref bean="temperature_sensor-cpu1"/>
      <ref bean="temperature_sensor-cpu2"/>
      <ref bean="temperature_sensor-mobo"/>
      <ref bean="temperature_sensor-sda"/>
      <ref bean="temperature_sensor-sdb"/>
      
      <ref bean="rrdlogger_sensors"/>
      <ref bean="rrdlogger_thermostats"/>
      <ref bean="rrdlogger_dampers"/>
    </set>
  </constructor-arg>
</bean>

Not all entities are JMX enabled at this time. Adding one to the configuration won't do any harm, but you'll get a warning message in the log.

It's worth mentioning that you need to add DZ3 classes to JConsole's classpath in order to get complex entities like DataSample<Double> rendered by JConsole, like this:

${JAVA_HOME}/bin/jconsole \
-J-Djava.class.path=${JAVA_HOME}/lib/jconsole.jar:\
${JAVA_HOME}/lib/tools.jar:$CLASSPATH

where CLASSPATH is the same that is used in DZ3 Runner.

The recommended value of I...

...is 0.0000002.

Don't ask.

You'll know what it is about when you get to it.

DZ3 Data Logger: Splitters

Some entities (thermostat, PID controller that is a part of it, zone controller to name a few) produce signal that is more complicated than DataSample<Double>, which is just about as complex as DataLogger can accept.

In order to break down complex signals to simple components, splitters exist. Here's how you can configure one (irrelevant beans omitted):

<bean id="thermostat-6EE055000000" class="net.sf.dz3.device.model.impl.ThermostatModel">
   <constructor-arg type="java.lang.String" value="1-Wire 6EE055000000"/>
   <constructor-arg type="net.sf.dz3.device.sensor.TemperatureSensor" ref="temperature_sensor-6EE055000000"/>
   <constructor-arg type="net.sf.dz3.controller.pid.AbstractPidController" ref="pid_controller_6EE055000000"/>
</bean>
<bean id="splitter-thermostat-6EE055000000" class="net.sf.dz3.device.model.impl.ThermostatSignalSplitter">
   <constructor-arg index="0" ref="thermostat-6EE055000000"/>
</bean>
<bean id="rrdlogger_thermostats" class="net.sf.jukebox.datastream.logger.impl.rrd.RrdLogger" init-method="start">
   <constructor-arg index="0" type="java.util.Set">
       <set>
           <ref bean="splitter-thermostat-6EE055000000"/>
       </set>
   </constructor-arg>
   <constructor-arg index="1" type="java.io.File" ref="rrdbase_thermostats"/>
   <constructor-arg index="2" type="java.io.File" ref="rrdtool"/>
</bean>

The above example will make the rrdlogger_thermostats data logger automatically subscrube to all signals that are produced by thermostat-6EE055000000 and create a channel for each of them (in this particular case, they will be named "1-Wire 6EE055000000" and "1-Wire 6EE055000000.calling").

IMPORTANT: Make sure you don't create the controller you're trying to monitor with scope="prototype" - you will end up with a new instance, not connected to anything and not doing anything till the end of time. Goes without saying that you can not reuse controller instances for different entities - you will have to create diferent instances with diffent bean IDs.

Splitters for other complex entities will be written as need arises - keep your eye on the code base. One good way to do that is to subscibe to commits RSS feed.

DZ3 Data Logger: Logging *Everything*

During DZ2 development it became clear tat there's no such thing as too much instrumentation data. Hence, DZ3 was architected in such a way that any object that produces DataSample<E extends Number> can have their data logged.

Here's an example how you can log temperature sensor data (this has been added to the bottom of this example):

<!-- Loggers -->
<bean id="rrdbase" class="java.io.File">
       <!-- This is the path in the file system. If in doubt, make it absolute --/>
       <constructor-arg type="java.lang.String" value="./rrd"/>
</bean>
<bean id="rrdtool" class="java.io.File">
       <constructor-arg type="java.lang.String" value="/usr/bin/rrdtool"/>
</bean>
<bean id="rrdlogger" class="net.sf.jukebox.datastream.logger.impl.rrd.RrdLogger" init-method="start">
       <constructor-arg index="0" type="java.util.Set">
               <set>
                       <ref bean="temperature_sensor-6EE055000000"/>
                       <ref bean="temperature_sensor-cpu1"/>
                       <ref bean="temperature_sensor-cpu2"/>
                       <ref bean="temperature_sensor-mobo"/>
                       <ref bean="temperature_sensor-sda"/>
                       <ref bean="temperature_sensor-sdb"/>
               </set>
       </constructor-arg>
       <constructor-arg index="1" type="java.io.File" ref="rrdbase"/>
       <constructor-arg index="2" type="java.io.File" ref="rrdtool"/>
</bean>

And here's the data that it produced during its first 3 hours of operation:



UPDATE (2009/11/08): Added comment to rrdbean constructor argument - thanks to David for clarification.

DZ3 Configuration: Teaser

DZ3 is about to start working as a forced ventilation controller for a computer located in a closed, but ventilated compartment under a staircase. Picture on the left is of the computer itself (fan assembly is visible in the background). Picture on the right is of the fan assembly that provides ventilation (by the way, not loud at all).



And below is the configuration that reads three lm_sensors supported sensors and one 1-Wire sensor (mapped to the file system by owfs-fs) and feeds the data to the rest of the system. If you want to see it, copy & paste somewhere else - there's no way to make it readable here.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <!-- Sensors -->
    <bean id="temperature_sensor-6EE055000000" class="net.sf.dz3.device.sensor.impl.ShellSensor" init-method="start">
        <constructor-arg index="0" value="6EE055000000"/>
        <constructor-arg index="1" value="1000"/>
        <constructor-arg index="2" value="/bin/cat /mnt/onewire/28.6EE055000000/temperature12|tr -s ' '"/>
    </bean>
    <bean id="temperature_sensor-cpu1" class="net.sf.dz3.device.sensor.impl.ShellSensor" init-method="start">
        <constructor-arg index="0" value="cpu1"/>
        <constructor-arg index="1" value="1000"/>
        <constructor-arg index="2" value="/usr/bin/sensors|grep Int|tr -s ' '|cut -f 3 -d ' '|tr -d '+°C'"/>
    </bean>
    <bean id="temperature_sensor-cpu2" class="net.sf.dz3.device.sensor.impl.ShellSensor" init-method="start">
        <constructor-arg index="0" value="cpu2"/>
        <constructor-arg index="1" value="1000"/>
        <constructor-arg index="2" value="/usr/bin/sensors|grep AMD|tr -s ' '|cut -f 3 -d ' '|tr -d '+°C'"/>
    </bean>
    <bean id="temperature_sensor-mobo" class="net.sf.dz3.device.sensor.impl.ShellSensor" init-method="start">
        <constructor-arg index="0" value="mobo"/>
        <constructor-arg index="1" value="1000"/>
        <constructor-arg index="2" value="/usr/bin/sensors|grep M/B|tr -s ' '|cut -f 3 -d ' '|tr -d '+°C'"/>
    </bean>

    <!-- Thermostats -->
    <bean id="pid_controller_6EE055000000" class="net.sf.dz3.controller.pid.SimplePidController" scope="prototype">
        <constructor-arg index="0" value="22.5"/>
        <constructor-arg index="1" value="1"/>
        <constructor-arg index="2" value="0"/>
        <constructor-arg index="3" value="0"/>
        <constructor-arg index="4" value="0"/>
    </bean>
    <bean id="thermostat-6EE055000000" class="net.sf.dz3.device.model.impl.ThermostatModel">
        <constructor-arg type="java.lang.String" value="1-Wire 6EE055000000"/>
        <constructor-arg type="net.sf.dz3.device.sensor.TemperatureSensor" ref="temperature_sensor-6EE055000000"/>
        <constructor-arg type="net.sf.dz3.controller.pid.AbstractPidController" ref="pid_controller_6EE055000000"/>
    </bean>

    <bean id="pid_controller_cpu1" class="net.sf.dz3.controller.pid.SimplePidController" scope="prototype">
        <constructor-arg index="0" value="56"/>
        <constructor-arg index="1" value="1"/>
        <constructor-arg index="2" value="0"/>
        <constructor-arg index="3" value="0"/>
        <constructor-arg index="4" value="0"/>
    </bean>
    <bean id="thermostat-cpu1" class="net.sf.dz3.device.model.impl.ThermostatModel">
        <constructor-arg type="java.lang.String" value="CPU1"/>
        <constructor-arg type="net.sf.dz3.device.sensor.TemperatureSensor" ref="temperature_sensor-cpu1"/>
        <constructor-arg type="net.sf.dz3.controller.pid.AbstractPidController" ref="pid_controller_cpu1"/>
    </bean>

    <bean id="pid_controller_cpu2" class="net.sf.dz3.controller.pid.SimplePidController" scope="prototype">
        <constructor-arg index="0" value="44"/>
        <constructor-arg index="1" value="1"/>
        <constructor-arg index="2" value="0"/>
        <constructor-arg index="3" value="0"/>
        <constructor-arg index="4" value="0"/>
    </bean>
    <bean id="thermostat-cpu2" class="net.sf.dz3.device.model.impl.ThermostatModel">
        <constructor-arg type="java.lang.String" value="CPU2"/>
        <constructor-arg type="net.sf.dz3.device.sensor.TemperatureSensor" ref="temperature_sensor-cpu2"/>
        <constructor-arg type="net.sf.dz3.controller.pid.AbstractPidController" ref="pid_controller_cpu2"/>
    </bean>

    <bean id="pid_controller_mobo" class="net.sf.dz3.controller.pid.SimplePidController" scope="prototype">
        <constructor-arg index="0" value="38"/>
        <constructor-arg index="1" value="1"/>
        <constructor-arg index="2" value="0"/>
        <constructor-arg index="3" value="0"/>
        <constructor-arg index="4" value="0"/>
    </bean>
    <bean id="thermostat-mobo" class="net.sf.dz3.device.model.impl.ThermostatModel">
        <constructor-arg type="java.lang.String" value="Motherboard"/>
        <constructor-arg type="net.sf.dz3.device.sensor.TemperatureSensor" ref="temperature_sensor-mobo"/>
        <constructor-arg type="net.sf.dz3.controller.pid.AbstractPidController" ref="pid_controller_mobo"/>
    </bean>

    <!-- Dampers: None for now -->

    <!-- Zone Controllers -->
    <bean id="zone_controller-mx" class="net.sf.dz3.device.model.impl.SimpleZoneController">
        <constructor-arg type="java.util.Set">
            <set>
                <ref bean="thermostat-6EE055000000"/>
                <ref bean="thermostat-cpu1"/>
                <ref bean="thermostat-cpu2"/>
                <ref bean="thermostat-mobo"/>
            </set>
        </constructor-arg>
    </bean>

    <!-- HVAC Units -->
    <bean id="unit-mx" class="net.sf.dz3.device.model.impl.UnitModel">
        <constructor-arg type="java.lang.String" value="mx"/>
        <constructor-arg type="net.sf.dz3.device.model.ZoneController" ref="zone_controller-mx"/>
    </bean>

    <!-- Damper Controllers: None for now -->

</beans>

DZ3 Configuration, Part 1

This is a simplified representation of how things are connected in DZ3:



Every entity can act as a signal producer, and as a signal consumer. Exceptions are temperature sensors that can only be producers, and dampers that can only be consumers (unless there's instrumentation feedback).

Temperature Sensor

• Consumes nothing
• Produces Temperature

Thermostat

• Consumes Temperature
• Produces Zone Demand
• Has 1:1 relation with the Damper
  

Zone Controller

• Consumes Zone Demand
• Produces Total Demand

HVAC Unit

• Consumes Total Demand
• Produces Running

Damper Controller

• Consumes Zone Demand, Running
• Produces Damper Position
• Has to be aware about Thermostat:Damper relations
  

Damper

• Consumes Damper Position
• Produces nothing
• Has a 1:1 relation with the Thermostat
  

Data Logger

• Consumes everything

HOW TO PUT IT ALL TOGETHER

At this moment, the DZ3 container is based upon Spring Framework. If you are familiar with Spring, then a quick look at the sample configuration will tell you everything you need to know (provided you're somewhat familiar with the the code base).

If not, stay tuned.

UPDATE: Configuration Guide is now available.

DZ3 Runner

Release early, release often

-- ESR

There is no established place for shell components of DZ3 yet, so, for lack of a better place, here's a script that will run a valid DZ3 code base that you've just built on any Unix system (watch long lines):

#! /bin/sh

LIBDIR=${HOME}/.m2/repository

COMMONS_LOGGING=${LIBDIR}/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
LOG4J=${LIBDIR}/log4j/log4j/1.2.15/log4j-1.2.15.jar
SPRING=${LIBDIR}/org/springframework/spring/2.5.6/spring-2.5.6.jar

DZ=${LIBDIR}/net/sf/dz3
DZ_VERSION=3.0

JUKEBOX=${LIBDIR}/net/sf/jukebox
JUKEBOX_VERSION=6.0-RC2

# Reverse order, so inheriting classes have a priority (good for configuration)

export CLASSPATH="./${your_configuration_directory}:\
${DZ}/dz3-model/${DZ_VERSION}/dz3-model-${DZ_VERSION}.jar:\
${DZ}/dz3-common/${DZ_VERSION}/dz3-common-${DZ_VERSION}.jar:\
${DZ}/dz3-sensors/${DZ_VERSION}/dz3-sensors-${DZ_VERSION}.jar:\
${DZ}/dz3-spring/${DZ_VERSION}/dz3-spring-${DZ_VERSION}.jar:\
${JUKEBOX}/jukebox-common/${JUKEBOX_VERSION}/jukebox-common-${JUKEBOX_VERSION}.jar:\
${JUKEBOX}/jukebox-datastream/${JUKEBOX_VERSION}/jukebox-datastream-${JUKEBOX_VERSION}.jar:\
${JUKEBOX}/jukebox-jmx/${JUKEBOX_VERSION}/jukebox-jmx-${JUKEBOX_VERSION}.jar:\
${JUKEBOX}/jukebox-sem/${JUKEBOX_VERSION}/jukebox-sem-${JUKEBOX_VERSION}.jar:\
${JUKEBOX}/jukebox-service/${JUKEBOX_VERSION}/jukebox-service-${JUKEBOX_VERSION}.jar:\
${COMMONS_LOGGING}:\
${LOG4J}:\
${SPRING}"

#echo $CLASSPATH

# Remember that arguments on the command line are relative to the root of CLASSPATH
# -Dcom.sun.management.jmxremote is needed to allow accessing DZ with JMX management tools
$JAVA_HOME/bin/java \
-Dcom.sun.management.jmxremote \
-cp $CLASSPATH \
net.sf.dz3.runtime.Container $*

COMING UP

Runtime configuration

DZ3 Quickstart

(This post is sticky, will be updated as DZ3 codebase grows, and will eventually be migrated to the main site when DZ3 is sufficiently mature)

Below is what you have to do to have DZ3 code base installed on your system. It goes without saying that having a working installation of JDK 1.6 is a prerequisite. I distrust any implementation other than Sun's, but it's been many years since I've tried anything else, YMMV. (Update: found an article describing how to install Sun Java on Ubuntu).

You may want to copy and paste it into a shell scropt and see what happens when you run it. Watch long lines.

NOTE: You need to have Google Calendar dependencies on file system in order to build everything. Either follow simple instructions, or remove or comment out the dz3-schedule-gcal module from dz3-master/pom.xml.

Fedora 10+

#! /bin/sh

yum install maven2
yum install svn
cd ${your_development_directory}
svn co \
https://jukebox4.svn.sourceforge.net/svnroot/jukebox4/trunk/jukebox-master \
jukebox-master
(cd jukebox-master && mvn install)
svn co \
https://servomaster.svn.sourceforge.net/svnroot/servomaster/trunk/servomaster-common \
servomaster-common
(cd servomaster-common && mvn install)
svn co \
https://diy-zoning.svn.sourceforge.net/svnroot/diy-zoning/trunk/dz3-master \
dz3-master
cd dz3-master
# This test will most probably fail on your box because it is system specific
rm dz3-sensors/src/test/java/net/sf/dz3/device/sensor/impl/ShellSensorTest.java
mvn install

You're done. DZ3 codebase is installed on your box.

NOTE: installed. In order to connect servo controller based actuators you will also need to build servomaster-serial or servomaster-usb (depending on your hardware) which need to be checked out and built separately - but this is beyond the "quickstart".

Ubuntu 9.04

The only difference with the above is that instead of executing

yum install maven2
yum install svn

you execute

sudo apt-get install maven2
sudo apt-get install subversion

Mac OS X

(to the best of my understanding of explanations of a Mac expert):

1. Install Development packet, it'll give you Subversion, among other things
   
2. Install macports
3. Run "port install maven2"

The rest should work like it does on Unix (theoretically, at least).

Update: I'm told that both Maven and Subversion are preinstalled on Mac OS X starting with version 10.5.

Windows

You're on your own here. The only advice I can give is to use TortoiseSVN and download and install Maven manually. And of course, shell scripts won't work - unless you're running Cygwin, but if that's the case, then you don't need my advice.

UPDATING CODE BASE

The only thing you have to do is to execute svn update followed by mvn clean install in jukebox-master and dz3-master directories. Don't forget to kill the shell sensor test case, or modify it to suit your system - should be trivial. Something like this:

#! /bin/sh

cd ${your_development_directory}
(cd jukebox-master && svn update && mvn clean install)
cd dz3-master
svn update
rm dz3-sensors/src/test/java/net/sf/dz3/device/sensor/impl/ShellSensorTest.java
mvn clean install

COMING UP

DZ3 invocation and runtime configuration.

Google's Energy Monitor... Not? Why?

(From Adafruit): Google PowerMeter is still closed.

Hey! Up there! I want it. And you want me to want it. Open it.

PS: Official letter of request for participation sent to Google PowerMeter team was ignored. Not even so much as an automated email confirmation. Regrettable.

Echoes: AC2

Found AC2 project while performing site cleanup.

Looks like course assignment, may or may not contain anything useful (will have to analyze in depth later).

Has non-zero entertainment value, quote: "I'm going to try to write something. Even if I have to make up shit."

Good thing about this project is that since it is hosted on Google Code, it will not slide into oblivion like ECVS did.

DZ3 Seeded

Program complexity grows until it exceeds the capacity of the programmer who must maintain it.

-- Seventh Law of Computer Programming

DZ2: FAIL

Let's face it, DZ2 was a fizzle. It never lived up to expectations, and was a half-pregnant, never finished abomination, raising little more than contempt.

I did hear the criticism, it's just that the complexity of the project exceeded either available time, or motivation, or attention span.

Since the last material change to the project (and I'm afraid I'll have to admit that it was 0.1p7dev3, almost exactly five years ago) I've met quite a few smart people and learned quite a few harsh lessons. Hopefully, became smarter, and definitely became more concise (hope you'll see a welcome change in the size of the code that implements the same functionality now).

WHAT BROUGHT DZ2 DOWN

• DZ was never thoroughly tested. Tests were never formal, it was a hit and miss process. Bugs existed in the code for years with no definite fix;
• Hardware integration was always a pain. There was a necessity to maintain the OWAPI, and bend over to RxTx;
• Initial installation and configuration was always a pain;
• There were too many "wow" features in the project;
• It eventually crumbled under its own complexity.

WHAT I AM DOING ABOUT IT

• All the code in the project will be continually verified with unit tests;
• Code base will be strictly divided into hardware and platform independent components, and those that are hardware or platform dependent;
  
• Each component will have its own, proper for its nature, deployment model (in particular, Maven is used for Java code);
• Implication is, there'll be less Java, hence, less integration pain. I sincerely hope to retire OWAPI and RxTx this time;
• One good thing stays, project subsystems will keep talking to each other over IP;
• Third party integration becomes ever more important, beginning with xAP/xPL and going further to whatever is the protocol du jour;
• Visualization becomes a separate subsystem. Current idea is to use jukebox-datastream architecture (which grew up from original DZ code) and deploy the server side on Google App Engine (and use their visualization API to look at the data);
• Scheduling becomes a separate subsystem, quite possibly based on Google Calendar API;
• Mobile integration is critical. Smart phones have become a reality, and they are much more [swmbo] acceptable as UI devices than your workstation. I'll take care of Android implementation, but the API will be open.

HOW YOU CAN HELP

• Please remember all your incidents and report them, no matter in how vague a way. I would probably be able to put my finger on it, and come up with a test case - and you'll be able to confirm the test case and the fix (case in point: A/C keeps running even though all registers are already closed);
• If you're up to some code review, this may be a good time to start, while it is still fresh and small. SourceForge project page now has an RSS Feed for Subversion updates much better than mailing lists that were (still are) massively spammed;
• If you have any suggestions regarding implementing hardware dependent components, you're more than welcome to voice them here. Implementations using compatible protocols are even more welcome.

CONCLUSION

Is this a total rewrite? Hell no. I've realized early on that the project has to be very modular, and what is happening now is more like hardening of individual components, though based on a different framework. It remains to be seen how different it will be - hopefully not much. (UPDATE: It seems that the new code base is significantly (three to five times) lighter than the old one)

WHERE IS THE NEW CODE BASE?

dz3-master is the root of the new code base, give it a try. jukebox-master is the only prerequisite that is not available from a public Maven repository, so getting the code base to build should be a breeze (compared to old, autoconf/automake based way.

Oh, by the way, on any platform now.

---

[The above is a refactoring of the original message that is available at the diy-zoning-general mailing list archive]