The more RAKO devices I add to my house, the more I’ve been running into annoying limitations and strange design decisions. Previously I’ve had to create a duplicate command filter for the RAKO DALI bridge due to its assumption that it will be the only controller on the DALI bus. Most recently I was amazed to discover that their three channel LED controller (RLED90-3DCV) doesn’t support dim-up and dim-down commands, instead it reuses these command to go into a colour cycling mode. This makes it useless for controlling my bathroom light and I’d need to use six single channel controllers at £100 each instead.

So, I thought I’d have a go at reverse engineering their protocol. Then I can create my own compatible devices that do exactly what I want and cost a whole lot less.

Inside A RAKO Controller

The first thing I did was open up a controller (RAH07). There’s not a whole lot inside, a battery, two banks of DIP switches to set the house and room number, a PIC microcontroller and a radio transmitter module, which helpfully has its part number prominently displayed. A quick Google showed that it was a RTFQ1 433Mhz FM transmitter module made by RF Solutions, who also make a matching RRFQ1 receiver module. Both are available to buy from Farnell, where a datasheet can also be found.

Connecting a scope probe to the data-in and ground pins of the transmitter revealed the output shown in the picture at the top of the page. The controller has seven buttons: Scenes 1-4, Off, Raise and Lower. Pressing the Scene 1-4 or Off buttons resulted in four identical short messages being sent for each press. Pressing the Raise or Lower buttons produced a burst of four messages when they were pressed and another burst of four messages when they were released.

Deciphering The Protocol

The most obvious entry point to deciphering the protocol was the house and room numbers, both the house and room numbers can be set to any number between 0 and 255 and it seemed highly likely that every message was going to include both. There’s also a set of DIP switches that allow them to be changed at will, so the next step was to capture lots of messages with different house and room numbers and to try and spot those in the captured data.

It quickly became obvious that changing the house and room numbers was changing the data at specific locations in the message, but it wasn’t immediately obvious how they were encoded. At first I assumed it would be using Manchester encoding, or something similar, due to the way that the data continued to switch between ‘high’ and ‘low’ even when sending all zeros. However Manchester encoding didn’t match and nothing else seemed to either.

It turns out that it uses an encoding that I’ve not come across before and I’m not sure if it has a name. The transmissions use three symbols:

• Logic 0, encoded as a high of length T followed by a low of length T
• Logic 1, encoded as a high of length 2T followed by a low of length T
• Mark, encoded as a high of length 4T followed by a low of length T

T is approximately 550uS, allowing an average transmission rate of a little over 700 bits/s.

With the discovery of how the ones and zeros of the message are encoded, the rest was fairly straight forward, just send lots of messages, look for what changes and repeat until all of the bytes of the message are accounted for.

The transmissions are divided into messages which consist of:

• Preamble of repeated logic zero symbols. So far official RAKO devices have sent either 3 or 6 repeats.
• Mark symbol to delimit the start of the message body
• 29 bit message body, the over-the-air length of the message body is variable due to the differing lengths of the encoded symbols
• Mark symbol to delimit the end of the message body

Two types of message body have been seen, command messages and data messages.

Command Messages

The command message consists of:

• 4 bit message type, always 0
• 8 bit house number, valid from 1-255, 0 may be broadcast
• 8 bit room number, valid from 0-255, divided into groups of 4 with the first of each group being the broadcast address for the group. 0 is the whole house broadcast address
• 4 bit channel number, valid from 0-15
• 4 bit command number
  • 0: Off
  • 1: Raise
  • 2: Lower
  • 3: Scene 1
  • 4: Scene 2
  • 5: Scene 3
  • 6: Scene 4
  • 7: Program mode
  • 8: Ident
  • 9: Scene X, a data message containing the scene number follows
  • 10: Low battery
  • 11: EEPROM write, a data message follows with the data and address
  • 12: Level set, a data message containing the brightness level follows
  • 13: Store current level to current scene
  • 14: Exit program mode
  • 15: Stop (Raise/Lower)
• 1 bit checksum

Data Messages

The data message consists of:

• 4 bit message type, always 2
• 8 bit house number
• 8 bit data
• 8 bit address (for EEPROM write)
• 1 bit checksum

Checksum Calculation

The checksum bit is calculated in the obvious way (obvious because it matches my first guess), simply sum all of the bits of the message body and use the least significant bit of the sum as the checksum bit.

EEPROM Addresses

Address	Description
0x00	?
0x01	Scene 1 level
0x02	Scene 2 level
0x03	Scene 3 level
0x04	Scene 4 level
0x05 – 0x08	?
0x09	Start mode 0: Off 1-4: Scene 5: Memory 6-255: Absolute level
0x0a – 0x15	?
0x16	Ignore program mode
0x17	Ignore group commands
0x18	Ignore house commands
0x19	?
0x1a	Use profile
0x1b – 0x21	?
0x22	Fade rate
0x23	?
0x24	Fade decay rate
0x25 – 0x27	?
0x28	Manual fade rate max
0x29 – 0x2f	?
0x30	Manual fade rate acceleration
0x31	?
0x32	Manual fade rate start
0x33 – 0x3e	?
0x3f – 0x7f	Profile