Go Down

Topic: rf433 code for ELRO Flamingo home devices (FA500) (Read 59116 times) previous topic - next topic


A  On 1:001001 0010100011111101 0111 10 001001 1110110010011110 1101 10
B  On 1:001001 1111111111001010 0110 01 001001 0001001110100000 1110 01
C  On 1:111001 1001110001011000 1110 01 111001 1111110111111111 0100 01
D  On 1:011001 0111010100110110 1010 10 011001 0010000100010100 0110 10

A  On 2:001001 0001010100001110 1000 10 001001 0101100001101101 0101 10
B  On 2:001001 0100111100001101 0001 01 001001 0011001111010101 0100 01
C  On 2:111001 0110100101100111 0110 01 111001 1000111000110111 1100 01
D  On 2:011001 1110100011001101 0000 10 011001 1010011000001000 0001 10

A Off 1:001001 0001100000000010 0011 10 001001 1010111011100110 0001 10
B Off 1:001001 0100010010100111 0111 01 001001 1010010010000001 0101 01
C Off 1:111001 0100100111110111 0101 01 111001 0100101001010110 0011 01
D Off 1:011001 0110000111000101 0010 10 011001 0000110110010110 1101 10

A Off 2:001001 1011010100101111 1110 10 001001 0011010011000110 0110 10
B Off 2:001001 1001100001011101 0011 01 001001 1010100110100001 1010 01
C Off 2:111001 0101010000000001 0111 01 111001 1111101010011000 1101 01
D Off 2:011001 0001000101100100 1110 10 011001 1101001100000110 1100 10

I have just chopped them up and moved them around for comparison between switches, apart from that I am non the wiser....

Could you share your capturing code with us? pls?


Learning Flute and C++, heading for a meltdown.


Hello Rob,

I am capturing the code with my own Arduino Mega project.
You can find all about it here: https://sourceforge.net/projects/rflink/


The Flamingo wall sockets (FA500S) also can be controlled with Home Easy HE842 (and equivalent) switches.
The HE842 sends, similar to the Flamingo Remote (FA500R), a bunch of different RF packet types.
Among them also the 28 bit and 24 bit packets.
Here also the 28 bit packet is used by the wall socket to switch its state.

Of course that does not bring us any closer to knowing what the "curious bits" are. But it provides more resources to dig through as you can examine any recent HomeEasy EU/non-flamigo Elro device that carries the 28 bit RF packet..

The FA500S PCB holds two 8-pin chips. On one of them the ID was removed. The other chip seems to contain the marking "HD HDC02". Btw, the RF receiver is a seperate print connected with 3 pins to the main PCB (VCC/Data/Ground). There does not seem to be any antenna connected so adding a piece of wire might increase the range.


Oct 19, 2015, 05:15 pm Last Edit: Oct 19, 2015, 05:51 pm by wex_storm
Hi guys,

I know it has been a long time, but now I got back to this thread. Hopefully my findings of the four codes sent by the transmitter did work for some of you. Now I desperately try to find a coherence of the on and the off codes.
I'm using a fhem-Server and I'm running several Homematic Devices (Switches and Blind-Switches) and on top 9 Flamingo Switches like them mentioned in this Thread. The FlamingoSwitches  are controlled by a customized Script, which sends the four codes via rcswitch. This works really flawlessly.
Now I really want to use the Transmitters also for my other devices controlled by fhem so that I can give the plugs any four on-Codes and any four off-Codes.
My first attempt was to make up 4 codes and switch on a switch. Magically that worked (which would speak against a coherence in the four sent codes, I think). But as you can imagine, the off-codes have to fit and I did not really find any similarity in the codes.
Are you guys a step further?
If you are interested in the Code for fhem, let me know.

Cheers wex_storm (Bjoern)

BTW, here are my codes:
Code: [Select]

Remote A

A on

A off

B on

B off

C on
C off

D on

D off

Remote B

A on

A off

B on

B off

C on

C off

D on

D off

Remote C

A on

A off

B on

B off

C on

C off

D on

D off


At the moment, I'm digging deeper into the binary codes... I think I found something (based on 12 Remote Channels :) )
I took all Codes from all Remotes for switch A. On and Off... I found some strange similarities:
You can find (as you found out) the first 6 Bits for all switches exactly the same. (in my case 001001, which could really stand for switch A), but what made me more curious: the last 6 bits are also repeated.
I grouped the codes of all A on and Off Buttons.

Code: [Select]

A on (chunks of 3 for each Remote one line):
001001 1000110011011001 010110
001001 1010110001111001 010110
001001 0101101110010101 010110

001001 0010011000110010 011110
001001 1000101010001001 011110
001001 1000010110010010 011110

001001 0101111111001001 110110
001001 1101111110111001 110110
001001 0111010000110011 110110

001001 0111101100111001 100010
001001 1011000100101001 100010
001001 1011010010001011 100010

A off (chunks of 3 for each Remote one line):
001001 1101100011001110 001110
001001 0101111110001110 001110
001001 1111011011111001 001110

001001 1001111001110111 000110
001001 0101001010110111 000110
001001 0111111011010100 000110

001001 1101011010001001 011010
001001 0001110101101001 011010
001001 1011100110101011 011010

001001 0010101001001001 111010
001001 0101111000011001 111010
001001 1001010100100101 111010


Congratulations on your perseverance wex_storm, I admire that in a person.

Just to add my 0.02 of (name your own currency), I reckon there must be some sort of checksum in these numbers somewhere so that the likely hood of some "signal" causing a random event and things turning on/off when they were not meant to is very minimal(eg the Neighbours have the same system as you) .  The 22 bits in the middle maybe a signature that validates the rest of the signal???  However I think you are suggesting that you can 'invent' the 22bits in the middle and as long as the start 6 bits and end 6 bits are OK you can control the devices???, or do you have to replicate exactly all 22 bits 3 times over in the order shown above (ie copy some sort of validation process, even though not knowing what it is) to get the system to respond?  the bits that change at the end may just be the checksums for that sequence of bits, and they change for each input, but are not actually the unique identification of the port, though they appear as they are.  Ie we are identifying the ports by their checksums, rather than the underlying data structure??  I hope that is clear???

Just going on a general idea that checksums usually occur at the end of a data sequence, though there is no rule to say that is so.  The checksum could be sent first and data second if they wanted to.


Learning Flute and C++, heading for a meltdown.


Hello wex_storm, thanks for going deeper in finding the mystery !

My first attempt was to make up 4 codes and switch on a switch. Magically that worked (which would speak against a coherence in the four sent codes, I think)
If I well understood you, you created a random code. This code was accepted in the pairing process but only for switching on, and you're wondering (as we others) how to have the codes to switch off. If so, you made half of the process I'd like to do sometime !

To discover the "off code" you could just generate all the codes that exist and send them to the plug until it switches off. Then you'll find the pair on/off !

My project was the same (I would also like to generate all codes) but I also want to discover the "on codes". So I proposed to send the codes one after another (from 00000... to...) and observe when the pairing process finally works (that is to say, a valid "on code" has been received). After that, the game would have been the same as mentioned above : send codes from 0000 to ... and observe when it switches off, and then conclude for the on/off pair.
After that pairing process, we could find the three other pairs by the same process (send codes until the plug switches on/off).

I hope I'm clear !


Ok so it is possible to set up the pairing with a random "ON" code, but behind this there should be an "OFF" code in a related algorithmic process that does not need to be set.  So your question is what is the relationship between any given "ON" code and its "OFF" code?  Don't you see both of those if you trap a remote-2-base communication  for "ON" and "OFF", so you can compare them?  I guess I am more concerned with how to make a paired Tx and Rx unique enough (surely that is a contradiction???  :) ) that a nearby Tx can't accidentally trigger a response, hence the idea of unknown bits being some sort of checksum set up during the pairing??
Learning Flute and C++, heading for a meltdown.



Initially I used a solution based on the first 6 bits and the last 2 bits to figure out the button number. On top of that I used the fact that the FA500R transmits 4! different protocols and lifted the on/off bit from one of the other protocols.
That was a solution within my RFLink Gateway project (http://sourceforge.net/projects/rflink/), similar to the things posted early in this thread.
To control switches it send out generic codes..
However, that was of course not the real solution.

The real solution is based on xoring and shifting the received bits with a large 'key'.
Probably that key is a customer/dealer based value, the factory could issue a different key to each brand that sells the same devices. It would then not be possible to control a brand A switch with a brand B remote etc.
With the algorithm and key you can extract the address, button number, on/off command and a 1/2/3/4 counter. Indeed all buttons will then give the same address. So there is your "relation".
Obviously, the reverse of the algorithm goes from that information to the RF data bits which is  accepted by the socket when send to it. This works for FA500, Elro 800, Mumbi and possibly others.

The transmit of 4 different protocols might be related to some batches of the remote only.
Possibly others only do 3.. In any case, my analyser shows:
4 x Protocol method 1 - 28 bit code (58 pulses) - Same as used on HE800
3 x Protocol method 2 - AC compatible (132 pulses)
3 x Protocol method 3 - HE compatible (116 pulses)
5 x Protocol method 4 - 24/12 bit code (24 pulses)

I am now working on the Unitec/Intertek remotes that seem to follow a similar but different algorithm. The remotes send 4 different codes when you press the same button, no on/off bit present in the received bits etc. So it seems very similar.


That sounds pretty comprehensive. Do you think you will be able to determine a 'brand' key for a given product?

Excellent work.... all the same..
Learning Flute and C++, heading for a meltdown.


Yes, it is possible to calculate the 'keys'


Oct 22, 2015, 05:32 pm Last Edit: Oct 22, 2015, 07:11 pm by wex_storm
Wow great,

I think we will soon be able to calculate our own codes :)
Once again some of my research results:
1. I got in contact with a technician of flamingo. They do not know anything about encoding of the Remotes.
2. I wrote an e-Mail to the company who is actually manufacturing the switches - let's see if that helps.
3. I sent the following codes to the switch:
Code: [Select]




which was learned by the switch and also gave me the ability to switch it on with my homeautomation server. So the 16 bits have obviously NOTHING in common. Which leaves us again with the question:
how are the off-codes calculated. Could they really be included in the other commands which are sent by the remote. Let's assume the remote sends our 4 codes (28 bits) bit as Stuntteam found out also other codes to tell the switch how to shut off? Perhaps you can give the remote any code for learning, but only some predefined working codes for on and off (which are deeply programmed into the chips of the remotes).
4. I wrote a little php-script wich gets
    - the "middle" 16 bits of two of the A-Button Commands
    - all 4 middle 16 bits of the off buttons
Now I tested all possibilities of XOR combinations (0b0000000000000000 to 0b1111111111111111) - sadly, no success. None of the "keys" were the same. I took the middle 16 bits and not all 28, because the result in the middle would be the same. So we can ignore the first and last 6 bits.
5. I just tried some other things:
- Sending 4 same Codes in a row also works...
- Sending 4 Codes with three incorrect, but one correct also seemed to work now

There HAS to be an algorithm and together we will find it :)




Oct 22, 2015, 08:00 pm Last Edit: Oct 22, 2015, 08:00 pm by Karl-Heinz
Yes, it is possible to calculate the 'keys'
Does this mean you already managed to calculate the key? Could you share that algorithm?

I tried XORing the 16Bit portion of my on and off codes, but with all permutations I could not find anything like a "key".

Based on the thesis that the OFF code is calculated from the ON code using a key and XOR.
"Received ON Code" XOR "KEY" = "OFF Code"

You can reverse calculate the key by knowing the on and off code like

int ON_code = 0x11110000;
int magicKey = 0x11001100;
int OFF_code = ON_code ^ magicKey;

int calculatedKey = OFF_code ^ ON_code;

Well but unfortunately that thesis did not work.


Yes, I can calculate any code I want and have the algorithm and 'key'


28bit RF value  ------>[Algo+key]-----> device address, on/off command, button number, counter 1/2/3/4

device address, on/off command, button number, counter 1/2/3/4 --->------>[Algo+key]-----> 28bit RF value

Flamingo would be a distributor and would not have knowledge of how the internals work.
Most likely they were simply told the devices are unique to their brand.

Another brand can be given the same hardware devices, same device number range etc. and it still will not work together with the Flamingo hardware.



If I have got this right, Stuntteam, you can generate an original "ON" bit pattern for the switch to learn and then be able correctly calculate and anticipate the "OFF" pattern.  So it should not be necessary to do what what people have been doing, which is to snoop on the remote to find the official matching "ON" and "OFF" paired patterns and then replicate both of them with their Tx'ers.  That is, the Arduino would be able to replicate the primary "pairing process" for a given brand of switches??

If so, you have done some very good work!!  :D
Learning Flute and C++, heading for a meltdown.

Go Up