Forget Me Not :  eLDERmon Protocol


In my last post I talked about decoding the protocol used by a commercial device



Link to other posts
Forget Me Not : eLDERmon Intro
Forget Me Not :  eLDERmon  Electrical
Forget Me Not :  eLDERmon  Outlets
Forget Me Not : eLDERmon Planning
Forget Me Not : eLDERmon Parts 1
Forget Me Not :  eLDERmon  Sponsor Parts
Forget Me Not : eLDERmon Hardware Hacking
Forget Me Not : eLDERmon GNUplot
Forget Me Not: eLDERmon Protocol
Forget Me Not : eLDERmon Hardware Hacking #2
Forget Me Not : eLDERmon Hardware Hacking #3
Forget Me Not : eLDERmon OpenHAB


This post I want to discuss what a protocol is and decide on what I will use.


What is a Protocol

The simple explanation is a defined method of communicating.

Protocol Definition.PNG

A good example is a phone conversation.

Caller dials numberPhone rings
Listen for ringing tonePickup phone
Ringing stops listen for voiceAnswer "Hello xyz here" (or whatever)
Reply "Hello its here is ...def... there"Reply "I'll pass you to him"
wait until ...def... comes to the phone"hello ...def... here"
engage in conversation/Ask questionengage in conversation/Answer question
At conversation end say "Goodbye"acknowledge "goodbye"
Hangup phoneHangup phone


Without knowing it, both parties are engaging in one type of 'conversation protocol'.



Protocol Features

This version could be defined as half duplex, since one party talks and the other listens.

It is also a flexible/lose protocol since there is no timing, and the length of the data (ie the conversation) is not limited.

The entire exchange could be seconds, minutes or hours long, so other callers rely on the engaged tone when attempting to call.


The "conversation protocol" also includes error checking where one party may not hear or understand the conversation and ask for it to be repeated.

This even extends to during the conversation when there is no reply, .... often there is a question "Are you still there?".



In order for computers or machines to communicate (pass data) the MTM protocol needs to be a little tighter than our 'conversation protocol'.


We might want to know if there are errors received, and so the receiving end needs to check the data.

These protocols include a Check Bit or a CRC. Cyclic redundancy check - Wikipedia, the free encyclopedia


Other protocols include encryption to prevent unwanted eavesdropping on the data.

EnOcean's protocol  includes the ability to encrypt the data.


EnOcean protocols are described here.


You will notice that the protocol includes measures to avoid collision, and the graph shows the reliability over other types of transmissions.



The serial communication from a module to Host is extensively described here.

Knowledge Base - Support for Integration of  Energy Harvesting Wireless Modules | EnOcean - Support



Simple Protocol

For manually operated devices, most of the anti-collision and checking is performed by the 'organic controller' (ie the person pressing the button).

If the device doesn't react, then you press the button again (usually harder), and then you check the batteries in the remote, etc.


The RF Switched Outlets use a simple 24 bit code and rely on the user checking the outlet responded to the appropriate button ie ON or OFF.

When we use a micro controller to send the ON or OFF, you repeat it to ensure at least one of xx attempts works.


For my RF Switched Outlets, you can :-

  • Manually operate them
  • Press a button on the remote
  • or the system can control them.


I want something that will send a 'status' whenever it is changed.

I have plenty of power for responding, but since other sensors might be competing for the same frequency, some thought or 'rules' should be applied to reduce collisions.



Status Transmission

I need to use a receiver to listen for the 'status' message, and it makes sense that this is used to listen for the user pressing a button on the remote control.

It is therefore necessary to delay the status response until this code has been completed.


By using the same protocol, then I can simplify the received data, and simply treat it as if someone pressed the remote button.


Normally the controller can't see if the outlet is ON or OFF and simply repeats the code xx times to ensure it operates.

Using the status response I know the outlet is ON (or OFF), and I don't need to repeat it, which reduces the RF floating around, and therefore collision potential.


Using the status detection, if I don't get the status changing after xx attempts I can flag the Outlet as faulty or unresponsive (maybe someone switched off the power), and take the appropriate action.


This could be considered as an ACK (Acknowledgement) where the receiver acknowledges the message was received.



Status Code

Since the Watts Clever units have no code switch, they are programmed using the RF signal.

I need to use fixed codes for the 'status' code and it needs to be programmed before they are placed inside the units.


Because the protocol is very simple with no error checking, I need to ensure a single bit missing doesn't result in another Outlet being turned ON.

It is therefore important to use a different group or set of the 24 bits for my 'status' code.


3 SOFF13998162110101011001100001010010
3 LOFF13998163110101011001100001010011
2 SOFF13998164110101011001100001010100
2 LOFF13998165110101011001100001010101
1 SOFF13998166110101011001100001010110
1 LOFF13998167110101011001100001010111
3 SON13998170110101011001100001011010
3 LON13998171110101011001100001011011
2 SON13998172110101011001100001011100
2 LON13998173110101011001100001011101
1 SON13998174110101011001100001011110
1 LON13998175110101011001100001011111
4 SOFF13998176110101011001100001100000
4 LOFF13998177110101011001100001100001
5 SOFF13998178110101011001100001100010
5 LOFF13998179110101011001100001100011
6 SOFF13998180110101011001100001100100
6 LOFF13998181110101011001100001100101
7 SOFF13998182110101011001100001100110
7 LOFF13998183110101011001100001100111
4 SON13998184110101011001100001101000
4 LON13998185110101011001100001101001
5 SON13998186110101011001100001101010
5 LON13998187110101011001100001101011
6 SON13998188110101011001100001101100
6 LON13998189110101011001100001101101
7 SON13998190110101011001100001101110
7 LON13998191110101011001100001101111
8 SOFF13998192110101011001100001110000
8 LOFF13998193110101011001100001110001
9 SOFF13998194110101011001100001110010
9 LOFF13998195110101011001100001110011
10 SOFF13998196110101011001100001110100
10 LOFF13998197110101011001100001110101
11 SOFF13998198110101011001100001110110
11 LOFF13998199110101011001100001110111
8 SON13998200110101011001100001111000
8 LON13998201110101011001100001111001
9 SON13998202110101011001100001111010
9 LON13998203110101011001100001111011
10 SON13998204110101011001100001111100
10 LON13998205110101011001100001111101
11 SON13998206110101011001100001111110
11 LON13998207110101011001100001111111


This is the codes for my outlets, and Bit 21 is used to send the ON or OFF state.

This means that you just need to store the address of the Outlet, and add 8 to turn in ON.


Bit 1-18 all remain the same, and they may be used as a synchronization or framing, so if I use bits 14-17 for my 'status address', I should be fine.


Obviously trying it before execution would be useful, so that's the next step, and then construct the hardware.