Sun rising over NetHomeServer

A couple of weeks ago I, started thinking about finally adding a timer that is controlled by the sunrise/sunset, but I realized I just did not have the time. The day after(!) Peter called and said he had found a Java API for getting sunrise/sunset, and that he wanted to write a HomeItem for this.

I guess it is the shorter days that made us think about this at the same time. After a short design session about how to specify the times Peter started working – and now he has finished the coolest HomeItem in a long time: DayLiteTimer!

For each day of the week, you can specify multiple times when the connected lamp shall be activated like: 08:00-10:00,17:00-21:00.

You can also refer to sunrise [R] or sunset [S] like: 08:00-[R],[S-00:30]-21:00, where [S-00:30] means 30 minutes before sunset.

It is also possible to specify a time interval, where the timer will take a random time within the interval: <15:00-17:00>-<23:00-00:20> meaning the lamp will turn on sometime between 15:00 and 17:00 and turn off sometime between 23:00 and 00:20.

It is also possible to combine all: <06:30-07:00>-<08:00-09:00>/[R+01:00] meaning that the lamp will turn on between 06:30 and 07:00 and turn off between 08:00 and 09:00 or at one hour after sunrise, whichever comes first. If one hour after sunrise occurs before the start time, the lamp will not turn on at all. DayLiteTimer is now available in the Nightly Build. Thanks Peter!!



So, now I have completed (and refactored) the NexaSmokeAlarm-item. I added the ability to actually trigger the alarm via the NexaSmokeAlarm-item too. I also added a "self learn"-function for the address of the smoke detector. Each detector have its own unique address, and by activating the "learn mode" on the home item and then manually triggering the alarm by pushing the test button on the smoke detector, the NexaSmokeAlarm-item learns the address from the alarm.
The protocol decoder/encoder and the NexaSmokeAlarm-item are available in the nightly build. One cation - never rely on NetHomeServer for performing any real fire alarm functions. The smoke detectors provide the real alarm, the NetHomeServer can simply provide additional features when the alarm goes off.


Speed Record

I have now a new personal development speed record. One of the more active NetHomeServer users (Walter) had bought a pair of smoke detectors with wireless connection (one goes off -> both goes off) which uses the standard 433.92MHz band. He sent me a raw dump of how the protocol RF signal looks (as a ProtocolAnalyzer .jir-file). It proved to be a pretty simple 3 byte space length encoded protocol which simply sends an address of the smoke detector.

And on the standard development time window (between supper and the late news) I managed to implement a protocol decoder for the protocol, test it and build new versions of ProtocolAnalyzer and NetHomeServer which supports the protocol - and which actually worked directly when Walter tested them!

Ok, ok, I know I am bragging now, but this was actually part of the goals with NetHomeServer - to have a framework where it is possible and easy to implement in small increments. To be honest, It took another evening to implement the unit test and the HomeItem which uses the protocol.

So now the nightly builds of NetHomeServer supports the new protocol "NexaFire" and there is a new Item called "NexaSmokeDetector" which can invoke commands when it receives a fire alarm via RF.


Rising Sun

Now I have added support for a new remote switch on request from a user. Here it is sold under the name "Rising Sun" and it is sold as a set of three plug in switches and a remote (for around 10 EUR). The protocol is yet a variation of the ArcTech based (like Nexa). The system supports four switches per "channel" and four different channels.

The odd thing is that the remote actually supports multiple keys pressed simultaneously. The NetHome decoder handles this, but it sort of assigns its own button-values to the different combinations.

The Decoder is called "RisingSun" and is available in the nightly build now.


Home made hardware

One of the nice things about NetHomeServer is that it is relatively easy to build your own low cost hardware to control radio and IR devices for home automation via the speaker output of the computer. You can also receive messages via the microphone input. NetHomeServer has encoders which can encode and decode a lot of protocols over the audio channel.

To my surprise I get questions from people that have designed such interfaces. I didn't think there were so many hardware designers out there! I have now collected a few such designs that I have made and some that users has sent to me on a new hardware page. So if you are one of those who have built a nice interface to NetHomeServer (or ProtocolAnalyzer), mail me some pictures and I will publish them too on the HW pages.



The weakest spot of NetHomeServer is probably currently the GUI. The current WEB GUI works for configuration, but to be honest – it is kind of geeky (See Link).

So, I am currently working on the next generation of WEB GUI. WEB development is not one of my strong points, so the development goes painfully slow. The new GUI is more oriented towards operating the devices than configuration. There are two main views where the Items are presented, one classic “map”-view where the devices are represented on an image. The controls for each Item “pop up” as a small semi transparent window when the mouse moves over the device. See below:

The other view is a more strict portlet style view, where Items are organized after the room they are located in. See:

I intended the portlet view to be the main GUI and added the map view more for demo or show. The funny thing is that when I have tried them at home for a couple of weeks, I tend to use the map view most, it feels more natural to really point at the location than to remember what I called each lamp. The development is still very much work in progress, but now it works enough for me to try it in real use. One truth remains – GUI development is hard!


Dim Nexa to absolute level

I recently got the information that the Nexa dimmers (with learning code) can actually dim to absolute levels! This makes them useful for real in home automation when you can tell a lamp to dim to 75% for example instead of just dimming up and down in steps. The function is “hidden” in the protocol and I don’t even think their own equipment can use it! I can’t however take any credit for the discovery; it was the guys at Telldus who had figured it out. Well, I have added this support to NetHome now, so there is a new Item called NexaLCDimmer, which support dimming to four different configurable levels. It is not in the official release yet, but it is in the nightly build on the download page.

Another thing I have recently realized is that Nexa are really just rebranding this product in Sweden. Even in Sweden the same product is also sold by another company under the name “Proove”. It would be interesting to know which brand names are used in other countries. I am for example almost sure that the ELRO Home Easy-system sold in Germany is the same, it would be interesting if someone could confirm this.


Waveman support

I have now added support for Waveman devices in NetHomeServer. Waveman sell remote controlled switches which use the 433.92MHz RF band. I got a request for the support of that protocol, and he could send samples of how the protocol looked. It proved to be almost identical to Nexa, only the off-signal differs. This in now available in the nightly builds. I have added a WavemanLamp-item and encoder/decoder for the protocol.


NetHomeServer 0.9 released

Finally – NetHomeServer 0.9 is released! Most functions have been available for quite a while in the nightly builds, but I haven’t taken the time to document the stuff good enough for releasing. But now it’s done. The release notes can be found at: http://wiki.nethome.nu/doku.php/nethomeserver_release09. The highlights are: CUL-support, IR-Support with PowerMid and MAC OSX-support. There are also a lot of other new Items that are finally documented and released.


Low activity during summer… I have started using a wireless numeric keyboard as an extra remote for controlling the lamps in my living room. I use the xbindkeys-tool in Linux to catch the key presses and with that I use the NetCat-program (nc) to send commands to an UDPCommandPort in the NetHomeServer. The shell command to toggle the reading lamp at my sofa becomes:

echo "call,SofaRead,toggle" | nc -u 8005

I use UDP to avoid the overhead of setting up a TCP-connection first.


Java sampler problems

The last couple of weeks have not been very productive. I started getting feedback that the audio based reception in NetHomeServer had started to hang for some users using Windows. It seems this behavior started with one of the latest Java updates. So I have spent a couple of weeks trying to hunt down this problem. To make things worse this behavior does not occur in any of my environments (One Linux and two Windows). Fortunately I have been getting great help from Walter Krämbring and David Näslund, who have received and tested numerous versions helping me to hunt down the problem. Thanks David and thanks Walter! I think I am almost there now finding a solution, but I am not sure yet. My impression is that the Java sound system is not the most reliable part of the environment. If anyone else has seen the problem that a TargetDataLine stops working after a couple of hours or that Java refuses to open a new TargetDataLine once the old one is closed, I would be glad to hear any suggestions on how to get around those problems – my current solutions are quite ugly…


Protocol Analyzer 1.1

Finally, Protocol Analyzer 1.1 is released! It contains a lot of goodies like the Pulse distribution view, Pulse re-anayzing and CUL support – see the release notes for all details. A big thanks to the beta testers for test and feedback! The release now also includes a manual for the program.


Bad reception

While fixing the transmission on CUL, I discovered that changing the data-rate settings on the CC1101-chip changed the behavior on the reception side as well. I don’t quite understand why, since I do not use any of the built in decoding features. But it awakened my hope of getting the reception to work. So I tried increasing the data rate setting to 10KBaud. The result was that it could now decode the fast pulses of the NexaL-protocol, but no other, slower protocol now worked. The signals of them now were drowned in noise instead. Deep sigh. I will have to release without support for reception.



The work with the CUL transmitter progresses. The Pronto Encoder now supports both the one time burst sequence and the repeated burst sequence of the Pronto Code, which are often used by IR protocols.
We have now also tested the CUL-support on MAC (Both a MAC Book Pro and a MacMini) and verified that it works.


Sending IR with CUL

I finally had a positive breakthrough with the CUL-stick. It has been working fine for sending to all supported protocols on the 433MHz band for controlling switches. But this band is also used for IR-extension devices such as the PowerMid, which is used to transmit IR remote control signals via radio. If I could tap in to their protocol, the CUL-stick could also be used as a generic IR-transmitter via a PowerMid! And now I finally got that to work. By modulating the mark pulses with 40KHz, the signal is received by the PowerMid receiver and sent as IR signals! This makes the CUL stick kind of a Swiss army knife of home control – both light switches and any IR remote controlled device can be managed!


Automatic Build

Now I have finally managed to get a complete tool chain for continuous automated builds of the NetHomeServer. I have been using Subversion, JUnit and Eclipse for quite a while, but always been building and running the JUnit tests from Eclipse. Now I have completed the tool chain with ant-scripts to do the builds and tests and finally Hudson to actually perform the builds and tests automatically every night. Hudson was a new experience for me, and quite a pleasant one. Hudson is a relatively new open source tool for automated builds and it was very easy to set up and configure on my Ubuntu-server. A really nice touch is that it can automatically download and install the Java-JDK:s and Ant-versions you need.

There is however one little detail that is very poorly documented, and that is how you configure the local URL-path when you run it as a daemon. You need to change it so it is not directly under the root-url in order to be able to access it via an Apache proxy (for example to http://myserver:8080/hudson). This is done by editing “/etc/default/Hudson” and adding the argument “--prefix=/hudson” in the HUDSON_ARGS-variable. It’s these little annoying things that take up 90% of the time when you are installing new stuff.

The automatic build are now transferred to the download page every night together with the test report for that build. The builds are made from the current state of the trunk, so they may be unstable and contain unfinished functions – but they are fresh :-).


More eyes

I have now lured another developer into the project ;-). Peter is a professional WEB-developer and has already begun on a very interesting new function in the HomeManager, I hope to be able to report more when the implementation progresses…

It is always good to get a fresh pair of eyes on the code. Peter immediately started harassing me about the unorganized package structure and the unfinished ant build scripts – and of course he is right. It is easy to get lazy when you are the only one roaming around in the code. So I have spent some time on house-cleaning the code now and it has improved the quality and readability. Thanks Peter.


Beta Testing Analyzer

The ProtocolAnalyzer 1.1 is finally ready for beta testing. I am aiming for supporting Windows, Linux and Mac OS X in this release. A group of active users have agreed to help me with the testing, and they have now started using it (and started giving feedback).

I have tried to find users that cover the main areas of OS and hardware like Windows, Linux, Mac, UPM-based samplers and CUL-transceiver.



I am now working on a new release of the Analyzer. My goal is to include support for MAC OS X in this release, and I am currently getting help in solving the problems that surface in that OS. The old Java promise “Write once – run everywhere” is not entirely true… There are still some problems with both SWT and the sound samplings. Hopefully we will have these problems solved soon so beta testing can begin.

I have also discovered that the hardware modification of the UPM-thermometer does not work well with some USB-sound cards. I have received good feedback and alternative connections from users (thanks Walter) and I will update the descriptions on the site.


UPM Checksum

A while ago I discovered four extra bits in the UPM temperature RF protocol. Two of the bits are sequence counters which simply adds one for each message in the three message bursts sent by the sensors. The other two bits seemed to be some kind of checksum. I have had some reports of people getting bad readings sometimes, so I finally took the time to figure the checksum out. After a bit of experimenting and analyzing, I finally managed to decode it: Bit 0 is all even bits in the message XOR:ed together and bit 1 is all the odd bits. So now bad messages will not be reported from the receiver any more!