Controlling Diskstation via openHAB

While building my Smart Home system I figured I might as well attach my Diskstation DS212 to the controls so I can turn it on and off at will. To make this work, I used the exec binding, the network health binding and the WOL binding combined into one neat little Switch:

Switch DS212 "DiskStation DS212" (Network) {
 nh="192.168.0.19", 
 exec="OFF:plink root@192.168.0.19 -pw password poweroff", 
 wol="192.168.0.255#00:11:32:0F:7F:2C" }

The corresponding sitemap entry look like this then:

Frame label="Network" {
 Switch item=DS212
}
z-wave_logo

Home Smart Home – Day 2

After a day of experimentation with openHAB I finally decided to first build a prototype system, rather than cutting real wires and putting the actors in between. This is what my prototype looks like:

IMG_20141110_230439

I must say it was in fact a good idea to start this way. The actors did not work yesterday for whatever reason, but after giving them a day to relax now and restarting my rPI they now work just fine. No more messages droppped no nothing. Maybe I will eventually figure out what the problem was, who knows.

On a different note, I tried out HomeGenie today as an alternative to openHAB and will give it a try. It seems a bit more intuitive and easier to setup. I do wonder if it also matches the openHAB capabilities and versatility. More updates soon.

z-wave_logo

Home Smart Home

End of last week I finally ordered the first few components to start my Smart-Home project. I am basing my setup on Z-Wave because I like the fact that it is an open standard plus there is a USB-controller I can plug into my RaspberryPI.

I’ve now ordered the following components to get started. The goal is to automate illumination of our driveway plus yard:

The ZStick goes straight into my Raspberry and that then runs openHAB. I am already positvely impressed by what openHAB can do. Configuring the binding is also straight forward so far – I have only attached the PIR sensor to trigger virtual light. I do hope to find the time to wire my two switch actors to the outdoor lighting this weekend. I’ll post some pictures as work progresses.

My new PC

After some five years I finally decided it was time to say goodbye to my old desktop PC, an old Intel Core2Quad Q9550  with 8GB RAM and an somewhat ancient Sapphire Radeon HD4870.  I abandoned all components except my two SSDs; one Intel 320 (120GB) and one Samsung SSD 840 PRO (256GB). This also means that I replaced my Antec P180 with a new enclsoure.

Goals for the new system were primarily performance combined with low noise emissions.  Five years ago, when I was building my old system, it was much more complicated to get a decent system at low noise levels. However, this has become a very easy feat recently, thanks to many great cases and low-noise cooling systems being available. It seems that the computer industry is finally picking up on that trend.

Now, finally, for the components I’ve put into the new system.

I have not run any benchmarks yet, as I am still waiting for the Windows 8.1 installation to finish. That is quite a time consuming process when you have to start from a Windows 8 installation disk and work your way through all the updates.

The system is very silent when running Windows, though. The Nanoxia Deep Silence 5 is an excellent case with excellent cable management plus the components I chose all feature low-noise fans, so I would think that this helped a lot. I’ll see how it performs under load.

New blogging engine

Finally, after a year of almost no activity, I have updated my blog with new software. I used to run WordPress for the past seven or so years but finally decided it was time for something new. As of today, I am running on Pelican, a Python-based static website generator. This means good-bye to the php-based dynamic colution. I hope this will give this blog some more security. Comments will be via Disqus for the moment, for want of a better alternative. I still plan to eventually migrate to completely static comments, but
for now Disqus will do.

Also, you might notice that the theme I use looks a lot like the one from Octopress. This is because I use the fabolous Pelican Octopress theme by Maurizio Sambati. I don’t use Octopress itself at the moment because I still have a hard time working with Ruby on Windows. Also, Pelican easily supports reStructured Text out of the box which I do in fact like better than Markdown (and have used it more often).

My new setup includes some more nifty technical details.

For ease of deployment, I have devised a workflow that is based on RhodeCode and Jenkins. I have setup a RhodeCode instance on my local server where I store the source to my blog. At the moment I use Mercurial to manage the versions. Furthermore, I have a Jenkins installation on the same server that pulls from the RhodeCode instance, builds the blog contents and publishes the result here afterwards. To avoid frequently polling on Mercurial, I have also installed a trigger in Mercurial (or RhodeCode respectively) that triggers the rebuild of the blog. The following figure gives an overview.

new publishing workflow

Now, this might seem like a bit of overhead on the setup side, but I had a lot of fun automating it this way. Technically I could just as well pusblish the blog from my personal PC everytime, but I found that to be an unworthy alternative ;)

What to do if biber stops working on MacOS X

Yesterday evening I ran into a bit of a problem when I tried building my latex document that uses biblatex/biber. For some reason, biber would not generate any output but fail with

Olivers-MacBook-Air:~ porten$ biber
data source /var/folders/5c/y7ssnfgj2fz1fnx1gz_z7ng80000gn/T/par-porten/cache-5a7f3069e2a4d51fd3557003fc55ec74c554c947//inc/lib/Biber/LaTeX/recode_data.xml not found in .
Compilation failed in require at Biber/Utils.pm line 21.
BEGIN failed--compilation aborted at Biber/Utils.pm line 21.
Compilation failed in require at Biber/Internals.pm line 8.
BEGIN failed--compilation aborted at Biber/Internals.pm line 8.
Compilation failed in require at (eval 22) line 2.
    ...propagated at /opt/local/lib/perl5/5.14.1/base.pm line 94.
BEGIN failed--compilation aborted at Biber.pm line 5.
Compilation failed in require at script/biber-darwin line 20.
BEGIN failed--compilation aborted at script/biber-darwin line 20.

Now, what fixes this is simply deleting the par cache:

sudo rm -rf /var/folders/5c/y7ssnfgj2fz1fnx1gz_z7ng80000gn/T/par-porten/

Sources:

Running WindowTester Pro from Maven/Tycho

Running SWTBot tests as part of your maven/tycho build cycle is rather
well documented and pretty straight forward (see for example the
sonatype docs). Doing so with a WindowTester Pro recorded test is
not – but then again it is pretty straigt forward as well.

There are just two things that you need to change from the SWTBot tests
pom.xml (as presented in the sonatype docs):

  • have useUIThread = true
  • add a dependecy to com.windowtester.runtime.feature.group to pull
    in platform specific plugins

You will also need to tell maven/tycho where to find the latter feature,
of course, by adding
http://dl.google.com/eclipse/inst/windowtester/beta/3.7 to your
repositories.

A sample pom.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
  xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelversion>4.0.0</modelversion>
  <parent>
    <artifactid>de.van_porten.vrest.build</artifactid>
    <groupid>de.van_porten</groupid>
    <version>0.0.1-SNAPSHOT</version>
    <relativepath>../de.van_porten.vrest.build</relativepath>
  </parent>
  <groupid>de.van_porten</groupid>
  <artifactid>de.van_porten.vrest.tests.recorded</artifactid>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>eclipse-test-plugin</packaging>

  <repositories>
    <repository>
      <id>windowtester</id>
      <layout>p2</layout>
      <url>http://dl.google.com/eclipse/inst/windowtester/beta/3.7</url>
    </repository>
  </repositories>

  <build>
    <plugins>
      <plugin>
        <groupid>org.eclipse.tycho</groupid>
        <artifactid>tycho-surefire-plugin</artifactid>
        <version>${tycho-version}</version>

        <configuration>
          <testsuite>de.van_porten.vrest.tests.recorded</testsuite>
          <testclass>de.van_porten.vrest.tests.recorded.AllTests</testclass>

          <useuiharness>true</useuiharness>
          <useuithread>true</useuithread>
          <!-- use our product and application to launch the tests -->
          <product>de.van_porten.vrest.bundle.product</product>
          <application>org.eclipse.ui.ide.workbench</application>

          <dependencies>
            <dependency>
              <type>p2-installable-unit</type>
              <artifactid>com.windowtester.runtime.feature.group</artifactid>
              <version>0.0.0</version>
            </dependency>
          </dependencies>
        </configuration>

      </plugin>
    </plugins>
  </build>


  <profiles>
    <profile>
      <id>osx</id>
      <activation>
        <property>
          <name>java.vendor.url</name>
          <value>http://www.apple.com/</value>
        </property>
      </activation>
      <build>
        <pluginmanagement>
          <plugins>
            <plugin>
              <groupid>org.eclipse.tycho</groupid>
              <artifactid>tycho-surefire-plugin</artifactid>
              <version>${tycho-version}</version>
              <configuration>
                <argline>-XstartOnFirstThread</argline>
              </configuration>
            </plugin>
          </plugins>
        </pluginmanagement>
      </build>
    </profile>
  </profiles>

</project>

Running Tycho in Jenkins/Hudson

When I first started running my Tycho/Maven build of my visual editor in
Jenkins the build would always fail if a single test failed. That was
mainly because the Maven build would run the surefire test automatically
but cancel the build if there were any failures in them. In turn, this
would not keep artifacts from being generated and thus not create a new
snapshot release. To make matters worse, my tests are not that stable
yet – running them on Linux sometimes fails for no reason whatsoever,
leading to yet another broken build.

Now, this is obviously not what you (or Jenkins, for that matter) would
expect to happen. What I wanted and what I guess you would normally want
is for the build to pass but for Jenkins to mark the build as
"unstable".

To acomplish this on the command line, you simply need to tell Maven to
ignore test failures

mvn clean install -Dmaven.test.failure.ignore=true

With Jenkins, this is equally straight forward:

image0

Now Jenkins acts nicely and reports unstable builds while still
producing all artifacts.

vRest maven build finally working

I finally managed to get the Maven-based build of my Eclipse-based
graphical editor to work – including unit and swtbot-ui tests:

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] de.van_porten.vrest.build ......................... SUCCESS [0.077s]
[INFO] de.van_porten.vrest.target-platform ............... SUCCESS [0.112s]
[INFO] de.van_porten.vrest.core .......................... SUCCESS [2.842s]
[INFO] de.van_porten.vrest.core.edit ..................... SUCCESS [0.869s]
[INFO] de.van_porten.vrest.core.editor ................... SUCCESS [0.829s]
[INFO] de.van_porten.vrest.bundle ........................ SUCCESS [0.105s]
[INFO] de.van_porten.vrest.help .......................... SUCCESS [0.076s]
[INFO] de.van_porten.vrest.ui ............................ SUCCESS [1.387s]
[INFO] de.van_porten.vrest.ui.properties ................. SUCCESS [3.650s]
[INFO] de.van_porten.vrest.feature ....................... SUCCESS [0.113s]
[INFO] de.van_porten.vrest ............................... SUCCESS [1:08.099s]
[INFO] de.van_porten.vrest.tests.core .................... SUCCESS [4.087s]
[INFO] de.van_porten.vrest.tests.ui ...................... SUCCESS [13.315s]
[INFO] de.van_porten.vrest.p2-repository ................. SUCCESS [2.498s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3:02.410s
[INFO] Finished at: Sat Nov 26 22:22:30 CET 2011
[INFO] Final Memory: 97M/231M
[INFO] ------------------------------------------------------------------------

I’ll push to Jenkins now and see if the continous build and test also
works there. Cross your fingers.

The one thing that is bugging me is an oddness with my target platform
defintion that for some reason doesn’t want to resolve
org.apache.batik.* properly – once I switch target to the development
platform everything works as expected. But I will figure that one out
eventually ..

More on the culprits and solutions I have to follow shortly.

CUnit-to-JUnit transform now on BitBucket

One of the most visited blog entries on this blog probably is my article
on transforming CUnit results to JUnit results: CUnit Tests in
Hudson
. There I write about how to use xsltproc to transform the
output of CUnit to be processed by Hudson/Jenkins.

Now, I decided to put the file on BitBucket to maybe consolidate the
contributions or changes others are making. I welcome everybody to make
contributions to the transform there.

The link to the BitBucket project is:
https://bitbucket.org/mcdeck/cunit-to-junit

Software Architect