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:
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:
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.
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.
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.
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.
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
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:
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
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
To acomplish this on the command line, you simply need to tell Maven to
ignore test failures
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
More on the culprits and solutions I have to follow shortly.
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.