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.