Menu
Index

Contact
LinkedIn
GitHub
Atom Feed
Comments Atom Feed



Tweet

Similar Articles

06/12/2013 18:30
Owl Energy Monitor Protocol (CMR119)
19/04/2014 09:42
PICing up 433MHz Signals for OSS Home Automation - Part 6
07/12/2013 14:13
STATUS Remote Control Socket Protocol (RCS-K09/RCT-08)
08/06/2014 10:30
PICing up 433MHz Signals for OSS Home Automation - Part 7
15/12/2013 10:34
PICing up 433MHz Signals for OSS Home Automation - Part 1
21/06/2014 22:10
PICing up 433MHz Signals for OSS Home Automation - Part 8

Recent Articles

23/04/2017 14:21
Raspberry Pi SD Card Test
07/04/2017 10:54
DNS Firewall (blackhole malicious, like Pi-hole) with bind9
28/03/2017 13:07
Kubernetes to learn Part 4
23/03/2017 16:09
Kubernetes to learn Part 3
21/03/2017 15:18
Kubernetes to learn Part 2

Glen Pitt-Pladdy :: Blog

energenie Remote Control Socket Protocol (ENER002)

Although there is very little information available before purchase on may of these devices this one seemed to be a little better presented than most so I gave it a go. These seem to only be sold in sets of 3 with a 4+ALL remote control.

energenie ENER002 Remote Control Socket

I'm not a fan of the finish of the plastic - the surface is marked around features in the plastic (presumably where it released from the mould) and the surface texture is... well, there hardly is any, and in places none. It smacks of cheap injection moulding.

These are not held together by screws like all other devices I've had but instead seem to either be clipped or ultrasonically welded together... difficult to say without breaking the casing apart, but I suspect it's clipped which would likely be cheaper to make.

The one obvious advantage of these over other devices I've looked at is that they are learning (ie. you teach them what to respond to) and vitally, they remember their code when power is removed, unlike the STATUS socket which powers up in learning mode and learns from transmissions from other devices like temperature sensors. To program them hold the green button down for 5 seconds and they go into learning mode. Normally this is an on/off toggle which is another advantage these have over many sockets (manual control).

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 keeps it's memory when powered down
  • Holding down the green button puts it 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.
  • Unlike the STATUS Socket these don't seem to get warm nor register on my power meter so their claims of 0.3W standby seems plausible

Baseband Signal

Once again my USB 433MHz transceiver with the Generic Logging plug-in is useful for storing any unrecognized transmissions to a file. From there it's rather easy to get it into a spreadsheet for graphing and analysis.

energenie ENER002 Remote Control Socket BaseBand

Well.... here we go again. Same encoding scheme as the STATUS Socket, same number of bits, just slightly different timing and data structure. Likely all the same flaws, vulnerabilities etc. With DC blocking the threshold could shift all over so not an ideal encoding scheme.

'0' pulses are ~320us, '1' pulses are ~1020us and the overall period is fixed at ~1400us with 10ms gaps between packets. That means with DC blocking that the threshold can shift within about 20% of the limits.

Data Structure

I configured the existing PulseWidth decoder class and captured the output from each of the buttons as well as power cycling to remote repeatedly to check if there were any rolling codes (none!). After confirming the structure and writing a decoder, I wrote the encoder and confirmed if any parts of the code are fixed for the product (none!).

The data structure is as follows:

  • No preamble, no sync - it's vital data from the first pulse!
  • The first 20 bits are a fixed ID. These will be learned by the plug no matter what is transmitted.
  • The next 3 bits are Address 0-3 (LSB first), but inverted so 111 as transmitted is button 1, 011 as transmitted is button 2, 101 as transmitted is button 3, 001 as transmitted is button 4, and importantly, 110 as transmitted is the ALL button. The address is learned.
  • There is 1 bit for on/off
  • There is 1 stop bit which is required but the value is ignored
  • Note that there is no error checking or any form of validation which is a risk - any bit corrupted could result in a different address, turning on instead of off, or vise-verse

As before, this is not safe to be used for any potentially harmful devices as it could be decoded and read with little effort for malicious purposes.

So, there you have it. Yet another device with a protocol that is not robust and is at risk of corruption.

Comments:

Jeroen Image  10/05/2015 11:46 :: Jeroen

I got my hands on a set called EuroDomest which uses the same "protocol". There we some very minor differences though in the Address bits. I am not entirely sure if you meant "LSB first" in the sense that the LSB is transmidded first IN TIME, but that was certainly not the case here The last nibble was encoded like this (bits shown in time sequence from bit 20 to 23):
1 on  -> F (1111)
1 off -> E (1110)
2 on  -> D (1101)
2 off -> C (1100)
3 on  -> B (1011)
3 off -> A (1010)
4 on  -> 7 (0111)
4 off -> 6 (0110)
A on  -> 2 (0010)
A off -> 1 (0001)
Notice the difference for button 4 and the weird encoding for "all".

Glen Pitt-Pladdy Image  10/05/2015 13:46 :: Glen Pitt-Pladdy

Yes, LSB first means first in time. It would not surprise me if a bunch of minor software variations are kicking about. I've seen this with some of the other devices where the same plastic case may contain have a different protocol, or different looking device use a very similar protocol to another. In some cases there is no way to tell from the protocol and I've got to decode it as multiple devices then guess from the decoded data which one makes the most sense. Many of these devices are sold under completely different brands.

There may only be a small number of manufacturers doing variations for different branding/marketing organizations and by having slightly different software/protocols it discourages mixing up devices from different "brands" even if it's the same designer/manufacturer.

Aidan Killian Image  23/08/2016 22:02 :: Aidan Killian

I have a four Energenie (green) plugs with their Energenie remote control.
I also have an ENER314-RT (which I love) with another two green plugs.
Everything works well but I was wondering if you could advise how to map the 4 digit code printed on the remote control to the 20 bit fixed ID of the data structure as I want to control some of the plugs both with the remote control and the ENER314-RT.
Cheers, Aidan

Glen Pitt-Pladdy Image  24/08/2016 20:58 :: Glen Pitt-Pladdy

Like I did here, you'll need to rely on whatever documentation/support you can find and reverse engineer the rest. This work is just the stuff I've done for my own needs.

Dave Image  13/07/2017 22:12 :: Dave

I had exactly the same situation of needing to learn my remote handset code and magaged it this way (brute force):

https://github.com/whaleygeek/pyenergenie/issues/81#issuecomment-313512879

Dave




Are you human? (reduces spam)
Note: Identity details will be stored in a cookie. Posts may not appear immediately