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!
2011-06-05
2010-11-09
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!!
2010-11-03
NexaFire
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.
2010-10-25
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.
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.
2010-10-09
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.
2010-10-04
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.
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.
2010-09-20
New WEB GUI
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!
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!
Subscribe to:
Comments (Atom)