After a few attempts to get my Z-Wave network to work reliably I finally decided to maybe try something else for the outdoor lights. The Z-Wave setup did not have the range to cover my driveway and yard, unfortunately.
Now, I decided to go with the HomeMatic. That really worked like a charm from day one. My current setup now looks like illustrated on the following picture.
I use three HomeMatic Actors to switch the five lamps in my yard and driveway (2+2+1). The HomeMatic motion detector is used to measure lumincance as well and switches on the lights when it gets dark permanently. At nine o’clock it then goes into motion detector mode and only switches the lights on if motion is detected. In the morning, I also turn on the lights at seven or so and turn t hem off when it gets too bright or after nine o’clock, whichever comes first.
The Z-Wave Plugin Switch control a chain of lights at the moment. Once winter is over I will find other uses for it. Finally, the WALLC-S is used to turn on the lights outside manually and I am planning on installing the AEO_MULTISENS as a secondary motion detector at some point.
Control of course happens through my OpenHAB installation on my RaspberyPI that is now equipped with a Z-Wave Plus controller and also acts as the central control unit for the HomeMatic devices through a CCU2.
Finally a working setup – now off to the next advenctures in home automation. Automatic roller shutters probably. Or finally installation a tablet-based control unit in my living room. Or probably both
Since I bought a new Z-Wave controller recently (ZME_UZB which support Z-Wave PLUS) I was now facing an issue there I needed to remove a device from my old controller (ZME_Z-StickC). However, I did not have the old controller available.
Including Z-Wave devices that are already registered with another Z-Wave network does not work immediately. The device needs to be factory reset first.
Resetting the device is easy also without the original controller, once you know how:
Simply use ANYcontroller and put into EXCLUSION mode. Afterwards, follow the instructions for exclusion of your device (e.g. tripple-click one of the buttons on my switch).
After that, the device is excluded (from its original network, although another controller triggered the exclude) and thus reset to factory defaults. Once that has happened inclusion works again.
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