NetHomeServer

2011-06-05T20:17:00.002+02:00

So, after some down time in the project, I have started looking into the code again. I have finally installed Sonar on the build server - and it dug up quite a few skeletons from the old parts of the code. I have spent a few days refactoring some of the central classes that really needed looking into.

I also got some unexpected - but very appreciated help, Christian Aune Thomassen has updated my CUL-firmware to support CUL V3 - thanks Christian!

Sun rising over NetHomeServer

2010-11-09T21:49:00.003+01:00

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!!

NexaFire

2010-11-03T20:33:00.002+01:00

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

2010-10-25T21:41:00.003+02:00

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

2010-10-09T13:10:00.003+02:00

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

2010-10-04T19:38:00.004+02:00

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.

New WEB GUI

2010-09-20T20:33:00.004+02:00

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

2010-08-29T01:00:00.001+02:00

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

2010-08-14T10:57:00.002+02:00

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

2010-08-01T11:51:00.002+02:00

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.

2010-07-19T19:35:00.001+02:00

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 127.0.0.1 8005

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

Java sampler problems

2010-06-06T22:41:00.002+02:00

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

2010-05-27T22:25:00.004+02:00

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

2010-04-26T20:14:00.000+02:00

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.

CUL on MAC

2010-04-22T21:08:00.002+02:00

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

2010-04-14T23:19:00.001+02:00

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

2010-03-21T15:15:00.003+01:00

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

2010-03-17T19:54:00.001+01:00

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

2010-03-14T12:11:00.002+01:00

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.

MAC OS X

2010-02-24T22:46:00.001+01:00

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

2010-02-01T20:03:00.001+01:00

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!

2009-11-21T21:24:00.002+01:00

This is SO frustrating. I spent the day rewriting the CUL firmware so it sends the USB data more directly via the hardware, bypassing the higher level USB print functions. To no use it seems. The received pulse lengths still vary way too much, so the USB overhead was not the problem. The problem seems to be worse for short pulses, which makes CUL useless for at least the NexaL protocol.

I may have to release CUL-support with only sending enabled, I think it will only annoy people if I include reception and it works bad...

This feels like a lot of time wasted.

2009-11-19T21:47:00.002+01:00

Ok, still no real luck in getting a better reception from the CUL-stick. I have exposed some of the radio parameters of the receiver circuit in the Protocol Analyzer settings, so I can try different settings easier, but I have not managed to get very much better signal.
The only theory I have left is that the USB sending routines spend too much time in interrupt disabled mode so it disturbs the interrupt driven sampling. So the last thing I will try is to bypass the higher level sending functions and program closer to the metal of the CPU to send the data. If does not work, I think I will give up the CUL for reception.

2009-09-08T20:37:00.005+02:00

Ok, I have finally finished the Pulse Length Distribution View in the ProtocolAnalyzer. It's like a spectrum analyzer for the pulse lengths of a signal. It's really useful when determining the lengths and tolerances for pulses in a decoder.

It also shows the current problems I have with the CUL-receiver. The two pictures are from the same signal (Nexa). The top one is collected with the CUL-stick and the one below via the AudioSampler via an UPM-receiver. The signal received with CUL is all over the place. I still don't know what the problem really is. There seems to be a big variation in the received pulse lengths from the CUL-Stick.

Sending

2009-09-01T22:54:00.001+02:00

I finally think I cracked the sending problem! It was not a timing problem, it was the transmitter circuit that was in a bad state due to wrong initializing. Now the protocol encoders seem to work with the CUL-Device (at least X10 and Nexa which I have tried).

Almost there

2009-08-31T22:27:00.001+02:00

Ok, I have finally managed to control the lights (X10) via the CUL-device and NetHomeServer. There seems to be some kind of timing problem when sending the data to the device. I am not sure what the problem is, but it might be the "command framwork" I am using that cannot handle high data rates. I might have to have some kind of acknowledge sceme from the CUL-device to slow down the transmission.

CUL-Transmission

2009-08-27T22:01:00.005+02:00

I am currently working with adding support for the CUL-Transceiver ( BusWare ) for NetHomeServer and ProtocolAnalyzer. Unfortunately this also means writing firmware for the stick. I just finished first version of firmware which can both receive and transmit.

The low level interface to the transceiver is a serial port, so to test it I connect with HyperTeminal and Type:
A03E81388
This adds a pulse to the transmit buffer with the length 03E8 (=1000 uS) and a space of 1388 (=5000 uS)
Then I type:
S05
Which sends the transmit buffer 5 times. This gave the above result from the ProtocolAnalyzer (connected to an UPM-Receiver)
It works!!! Currently no error checking, so there is work left to do, but now I will write the NetHomeServer-port so I can test sending real protocol messages!