After successfully decoding the Everflourish home automation controls, and integrating that with a DIY Android app, I thought it was time to expand the system. I picked up a new set of switches and remote, however, this was a different brand, Swedish Nexa, and thus a slightly different code. So, time do go through the RF decoding again, and adjust my RF remote source code.

I found two people working with this system, taking different approaches to controlling it from the Arudino. The author of the arduinocoder seems to interface through the remote, while Sebastian Nilsson had success with the HomeEasy project. I was tempted to use that code, however, as I was also interested in analysing the raw data, I brought out my DIY "oscilloscope" instead.

Since this home-made RF-to-audio device is something I thought I'd use in the future as well, I took the RF receiver off the breadboard, and soldered it onto a mini PCB, as seen in the pictures above. While working with RF components, I always find myself coming back to winavr's and Dave Houston's blog on how to wire this together. Unfortunately, the receiver was a bit more sensitive to the voltage level than I had expected, so taking 4.5 or 6 V from my power brick did not work. Instead, I used an Arduino, or a small 5V converter.

After this was done and plugged in, I found myself in Linux audio problems. Between two HDMI video cards, one external USB audio source, and the onboard audio port, it has gotten rather difficult to find the correct knob to turn to make sure the correct input is not muted, or too low. Here I found the application pavucontrol to very useful, as it clearly displays which devices and ports are available, and which applications output sound. (yum install pavucontrol). In Audacity, the input source was simply "default", while recording in mono.
Remember to NOT stick any home made equipment into the microphone port; use line-in instead.

Part of the wire message from one of the buttons on the remote can be seen above. Compared to the Everflourish system, it looks a bit more dragged out and the edges are not so clear cut. There's probably a few reasons for that: The resistors I used between the RF receiver and audio line were slightly different (this time 47k and 100k, vs. 100 Ohm and 1k in the previous). Also, the power source played a small role. Finally, the message is different, and in particular, the timings of wave is shorter; see below for details.

wire_bits=`cat $file | grep label.*title | cut -d '"' -f 6 | tr -d '\n' | sed "s/\([01]\{2\}\)/\1 /g"`
data_bits=`echo $wire_bits | sed "s/01/0/g" | sed "s/10/1/g"`
data_bytes_bin=`echo $data_bits | tr -d ' ' | sed "s/\([01]\{8\}\)/\1 /g"`
data_bytes_hex=`echo $data_bytes_bin | tr ' ' '\n' | while read b; do echo "obase=16; ibase=2; $b" | bc; done | tr '\n' ' '`
echo -e " $wire_bits \n $data_bits \n $data_bytes_bin \n $data_bytes_hex"

The snippet above extracts the labels from the Audacity XML project file and groups every wire bit, so the correspond to one data bit. A 01 on the wire is a 0, and a 10 is 1. This is a typical Manchester code. Next, the data bits are grouped into bytes, and finally expressed in hex. It then becomes clear how the message is structured: The 26 first (most significant) bits are a unique "house" or "remote control" code; the last four bits are the button ID; the 27th bit is a group flag, and the following (28th) is the the on/off bit. See also the documentation from the HomeEasy project below for further details.


01 01 10 01 01 01 10 10 10 10 10 10 01 01 10 10 10 10 10 01 10 10 01 10 10 01 01 10 01 01 01 10
0 0 1 0 0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 0 1 1 0 1 1 0 0 1 0 0 0 1
00100011 11110011 11101101 10010001
23 F3 ED 91

The data is encoded on the wire (aerial) as a Manchester code.

A latch of 275us high, 2675us low is sent before the data.
There is a gap of 10ms between each message.

0 = holding the line high for 275us then low for 275us.
1 = holding the line high for 275us then low for 1225us.

The timings seem to vary quite noticeably between devices. HE300 devices have a
low for about 1300us for a 1 whereas HE303 devices seem to have a low of about
1100us. If this script does not detect your signals try relaxing the timing
conditions.

Each actual bit of data is encoded as two bits on the wire as:
Data 0 = Wire 01
Data 1 = Wire 10

The actual message is 32 bits of data (64 wire bits):
bits 0-25: the group code - a 26bit number assigned to controllers.
bit 26: group flag
bit 27: on/off flag
bits 28-31: the device code - a 4bit number.

Once that was all clear, I just had to modify my transmitter code, which is connected over serial to my computer, and takes switch commands from my mobile phone. In the future, I will probably move to use an Ethernet shield, or possibly Bluetooth. There has been some problems with the connection to the Arudino, and also in sending the RF signals to the switches. In the new code, I've added quite a lot of extra redundancy, repeating the same command many times to makes sure it is received by the switch.

I've split the code into a library which can send commands to the Everflourish and Nexa systems, and the main sketch which takes commands from serial. There's probably a few things to improve on, so feel free to send me comments or patches.

The code is released under GPL 3, or later version.