The Receiver

 The spotlight has a self learning receiver which can be programmed to a number of transmitters, the supplied remote control or the NetHomeServer for example. It is this receiver we are after.

Ok, time to take it apart. Below the surface is a nice little circuit board. You can see the antenna to the right and the LED:s in the middle. When I flip the circuit board it becomes more interesting.

To the right are the HF receiver parts. I guess the lower right and the far left circuits are some kind of power drivers for the LED:s and the top right is probably the receiver signal decoder. There is one connection that looks like a good candidate for being the decoded on/off-signal.

I have scraped off the coating on it to be able to solder a connector there (at the blue arrow). Measuring the voltage there shows that the level is close to 0 when the light is off and about 90% of full voltage when the lights are on. Ok – we have a receiver! Now all that is left is to remove the LED:s and remove the board from the housing.

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.

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.

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.