I've been looking at how easily common 433MHz home automation devices can be hooked up to centralize gathering data and control. The main thing with home automation is to be able to control things and this is my first look at that. In this case a STATUS Remote control socket (RCS-K09).

Apparently identical (or perhaps just similar) devices are also sold under the name "EcoSavers" and there are a load more. The protocol looks similar to what is used for "Duwi EMW200R" as investigated by others on the web. It's not guaranteed that what I have here fits your sockets as there seems to be several similar looking sockets, even with the same model number, which have different protocols. It's completely possible that this is generic white-label hardware and different vendors add their own firmware to it.

One thing to note with these types of devices is there is negligible security - you are broadcasting the signal used to control it and with a sensitive receiver it could be captured some way off and used to control your devices from outside. Probably just annoying if it's a light or the stereo, but beware of allowing anything potentially hazardous (ie. heaters, cookers etc.) to be connected to these types of sockets.

Intelligence gathering

This time round there's not a lot of info to go on, but here's what we know about this device so far:

• It powers up (yes, that means after a power failure also) in learning mode - basically it wants to see some packet it recognizes to learn an ID from. I don't know if that's just the 1-4 addresses from the remote, or if it goes further than that (ie. each remote has it's own ID as well as the button addresses). It will learn from both an On and an Off command.
• I noticed it gets slightly warm when left idle. It measures ~1W of power consumption... many things I have don't even register on this meter so best to check if it will be an improvement before you use this for reducing standby power

Baseband Signal

With my cheap 433MHz modules from eBay  hooked them up to a sound card as a quick & dirty recording mechanism, the signal looks like this:

This is a far more crude structure than the Owl Energy Monitor I looked at before. It is using simple Pulse Width for different data states with the result that the overall DC lever varies all over the place as the mark-space isn't consistent. This is far from a good approach when it comes to data integrity and add to that there is no integrity checking in this, expect the occasional corruption.

Additionally this means that some other devices transmitting on 433MHz can trick this plug into thinking codes have been sent (Update: the Imagintronix temperature sensor does just this if the socket is powered on - starts up in learning mode), it will learn from the temperature sensor transmitting and then that will switch the socket. The socket is clearly not validating what is receives hence could learn and respond to stray signals. As mentioned before, these devices are not safe for use with anything that could be hazardous and after a power glitch could pick up signals and do just about anything, not to mention the ease with which someone malicious could control them.

We see a familiar pattern here:

1. Preamble - this gets the receiver settled and synced to the incoming symbol rate. In this cases 4 narrow pulses, though worth considering the initial one or two may get mangled by receivers settling etc.
2. Sync pattern - this is a deliberate change in the data from the preamble to sync where the start of complete bits (and bytes) are. Typically this will be done by transmitting 0x55, 0xaa or similar... looks like perhaps more 0xa in this case... just a nybble
3. Data - this is where the actual information to be transferred is
4. This is the bit that changes with different buttons on the remote. That suggests that the rest is probably ID(s) of some sort (vendor, particular remote etc.)
5. The single pulse at the end seems to be an anomaly - it doesn't exist on the last transmission, however now confirmed is that without this (either 0 or 1) the plug fails to respond

After a bit of coding I've got a decoder for this.

Data Structure

The data structure is trivial - 3 bytes, plus an apparently spurious single bit on it's own. What I believe at this point:

• The preamble & sync are effectively 0xa0 assuming LSB first (see in a bit)
• The last 3 bits appear to be the button address (1-4) except, inverted. They are LSB first. Again the numbering is a bit weird - 0, 1, 2, 4... go figure!
• The 4th-last bit is the On/Off flag
• "All Off" transmits address 0x7 (all bits set - after inverting to "normal") with the On/Off flag 1 (On!)... again, I don't know why
• Without some experimenting and/or another remote I can't tell if the data before (effectively 13 bits)
• Without some experimenting I don't know if the final bit on it's own is in fact a deliberate stop-bit or just an anomaly. I suspect an anomaly as it's not there in the final packet of a sequence.
• There is no error checking

Next Steps

At this point I'm investigating easy approaches to building a transmitter/receiver that I can use for generating test signals and easily decoding multiple protocols. Currently I'm looking at cheap USB PIC based modules which could use the internal timer to do run-length encoding of incoming signals and pre-load sequences for 0 / 1 data and buffer ~32 byte packets for transmission. Probably the easiest interface to a PC would be USB-Serial which would allow easy experimenting.