rf433 code for ELRO Flamingo home devices (FA500)

Is there the possibility the 'curious' section is a Rolling Code?

This has a good explanation of a car door or garage style controller that uses a Rolling Code Remote Entry.

What do you think?

Cheers, Rob

Edit: Sorry I did not mean that the codes rolled on every press. That has been shown not to be so, but I was thinking the 'curious' section have some how been obfuscated by a cryptographic algorithm so it scrambles the bits beyond simple human (I am a great example) pattern recognition?

Thanks for the interesting links

The goal of rolling key process is no to be captured (I admit that I don't understand why because 256 times later, a captured code would work) but in our case, if you capture a key you just have to reproduce it and it works. We might also build a device that tries all the codes for a specific button (the curious part is only 16 bits, and there are 4 solutions to switch the plug, so it's only 65536/4 = 16384 codes to try).

This two files :
http://skory.z-net.hu/alkatresz/PT2262_1.pdf (many timing stuffs comparable to our plugs)
http://www.ti.com/lit/ds/slws011d/slws011d.pdf (about the rolling codes)
but none explain how to "decode" what has been received

About the link you provided (in which I found the second above link), I'm wondering why rolling key systems would be so robust to hacker replication. It seems you just have to record enough frames (let's hide a scanner for a long time or have access to the emitter) to be able to unlock the receiver.

The reason why is that that 16 bit or 16384 combinations are traveled though in defined pathways where the algorithm visits any particular number maybe a number of times, but depending on where it is in the algorithm sequence will certainly branch off to non sequential (pseudo random) numbers. So while there may only be 16 bits and hence 16384 combinations, if there is a distinct 'pathway' but a secret pathway, sequencing through the 16384 points then it makes it much harder to guess what sequence point is next if only one point is 'sniffed'.

I don't think now that these remotes do rolling codes (or their code would change on each key press and would not be static as you have shown), but to use my experience with the Oregon Scientific Weather Station, the sensors send out a signal that is nibble (4bit) based, but each nibble has the significance of the bits reversed. So the Tx sends a 4 bit number where the ABCD is normally decimal weighted 1,2,4,8 whereas when this is reversed for each nibble where we swap the significance to DCBA and we weight the numbers as 8,4,2,1 suddenly the bytes can be seen to represent the data on the LCD console.
So once the nibble boundaries are determined, and the reversal of significance is applied to each byte, the weather data is observable. Numbers become recognisable in either BCD (eg humidity) or pure binary +conversion maths (eg windspeed). Until this processing is applied the bit pattern is just a meaningless jumble. (I would like to give kudos to whoever worked this out for my weather station, but I just don't know exactly who figured it out!!!) Plus the Checksum works on nibbles not bytes.

The other possibility is that there is also a checksum or cyclic redundancy involved where the integrity of the bit pattern is tested for by the receiver. I think one of the contributors above said that sending a single burst of a bit pattern was sufficient to trigger a response. If that is the case then my previous comments about repeating 4 times to validate it are wrong, and the burst of 4 times would be just hoping that at least one got through (am I right here?). But it also points to some other means of validating a successful transmission occurring so that erroneous transmissions can be eliminated. Fairly important when switching things connected to the mains power!!!

It maybe the case that the 'curious' bit satisfies some validity checking algorithm and does not have much else to do with the switching data. So while you are cloning transmitters successfully, it maybe as much as you can do to manually determine codes for each separate one purchased. So the learning mode maybe just something put in place to assign an earlier factory randomisation of transmitters, ie to create the uniqueness of the association of the Tx's to multiple Rx's, with no other generality involved. That is each Tx is sent out with a "unique" random 16bit number, or what ever number of bits, that does not change in a transmission, but they take the chance that the very close neighbours don't have the same number??? So for 16bits by 16bits = 1 in 268,435,456 chance of sharing the same number??? Reasonable odds in a capitalistic world??

However if there is a checksum or CRC of say 4 bits then that reduces the number of combinations of 16 bits being checked to 12 (4096 combos? chance of neighbours sharing =16,777,216). There is no free lunch, but still pretty good.

I hope this helps and stimulates some brilliant inspiration on someone else's part!!

Rob

Thanx for sharing your thoughts.

I just played around to cross-check some theories.

  1. Just 1 of the 4 codes is enough to teach-in the switch.
    --> The switch automatically recognizes the remaining 3 ON of the same button codes without having seen 'em.
    --> The switch automatically recognizes the 4 correct OFF codes.

  2. The switch is able to listen to more than one button. I repeated the teach sequence for all buttons A-D.
    Then the switch could be turned off and on by any of those.
    --> More than one code is stored in the switch (if required).

  3. The switch can be teached to listen to any other remote control
    --> There is no factory side pairing.

  4. Clearing the teached codes only succeeds using the remote control that was used when teaching the switch.

I think this is not a rolling code based on large lists of data with secret paths and such stuff. The device is simply too cheap for storing large data.
If you just need any of the 4 ON codes to know the other 3 ON codes AND the 4 OFF codes then this should be a kind of algorithm that is able to decode in any direction:

lets imagine you have 4 ON codes (only the curious 16 bit)

A ON
0x1001
0x1002
0x1003 (<- you know only this code but you are able to calculate the rest)
0x1004

and the corresponding 4 OFF codes

A OFF
0x2001
0x2002
0x2003
0x2004

If the switch sees 0x1003 during the teach in process, then the switch is able to
predict the other codes 0x1001, 0x1002, 0x1004 and even the OFF codes
0x2001, 0x2002, 0x2003, 0x2004. But this also works for any of the remaining 3 ON codes.

It could be a kind of symmetric chiffre algorithm that delivers the remaining codes based on just 1 input code. To keep the code simple this could also be a kind of filter operation with XOR and shift operators...

BUT:
why should someone send 4 different codes per button when one is enough for switching?

To respond to the last question first, I think the extra codes are designed to operate either alternative or legacy receivers as well. For example the same chipset in the Tx could interact with a very different Rx in a garage door or gate control using the 'other codes', without having to reprogram a whole new remotes. Just package up the chip with a new plastic coat and we may never realise that it is the same remote, unless it is analysed as you have done. What else does that company (or the chipset manufacturer) make that is RF controlled, I wonder?

I agree with everything above. Just to further explain (sorry about the longish post, a bad habit of mine being a now retired teacher) I agree the coding system for the switches appears simple enough and I am happy with your explanation of how 1 key can set the other 3. What I am suggesting is the 'curious' bits are a permanent (not rolling) unique factory number randomly chosen so it is very unlikely that a batch of remotes would ever have the same 'curious' bits and hence the same signature that is learned by the switches. (My weather station has an 8bit rolling code that is freshly chosen every time the power is lost, eg changing batteries, the sensor must then be re-registered with the base station, grrrr. But it does mean there is a 1/256 chance of another sensor belong to someone else interfering. This would not be unacceptable for controlling power switching in a house, but acceptable for low cost weather stations.)

However I think I am right in saying - someone above tested the switching by just sending the one pattern, and only sent it once, and it still worked? If that is true then I would guess there is some error checking code in the 'curious' bits. If not, then it is possible the same pattern has to be received say at least 3 times (out of the 4, or all 4) to be considered valid, in which case there would be little need for a checksum concept in the 'curious' bits.

Another thought is if the number (eg 1-4 switches) assigned to the signal the power switch (is apparently attached to the end of the bit packet) it would need to be incorporated into the preceding 'curious' bits if it was to act as an error checking system, otherwise it would not work.

Either way, if I was designing a receiver to listen to the remote I would just accept the whole pattern as a given, put any further diagnosis aside, program the Rx to learn the pattern, and then listen for at least 3 identical packets and use that as the validity check. Pretty crude, but I reckon it would be ok.

Cheers, Rob

why should someone send 4 different codes per button when one is enough for switching?

Good question ! As mentioned above, for other systems the codes are sent 6 times for enough redundancy. Here we just have four codes. Maybe the designer considered one code might not work for any RF reason and that would be a great idea not to persist in sending the same one. This is quite complicated for this poor reason, I admit.

To respond to the last question first, I think the extra codes are designed to operate either alternative or legacy receivers as well.

There are two things to consider :

  • my remote sends 3 types of codes (not HK's which only send the first type) : 4 times the first type, 6 times the second, 6 times the third. We are here discussing about the first type of code. The others codes may indeed be designed to operate with other devices
  • considering the first type of code, each button is associated to 4 different "curious parts". If the "extra codes" you're mentioning are the 3 apparently-usefulness-codes, then it would mean your remote works one time every four pushes.

What I am suggesting is the 'curious' bits are a permanent (not rolling) unique factory number randomly chosen

This bits are permanent in the remote (even if you remove the battery).
This code may have been generated randomly in factory but it has to be "curiously-associated" to 7 other codes (3 on, 4 off) through an algorithm we'd like to understand.
If the 8 codes of two buttons are indeed generated randomly (no correlation between them), then it implies every receiver knows all the remotes that could exist. A single remote would mean to be able to store 8(buttons)x4(codes)x16(bits)=512Bytes. I don't know how many different remotes the factory would like to implement, but I guess it will soon be a huge memory. However, today memory costs nothing...

However I think I am right in saying - someone above tested the switching by just sending the one pattern, and only sent it once, and it still worked?

I did not test it personally, but you're right. Sending on of the 4 codes associated to one button, whatever the codes sent before and whatever the code used for the pairing process, will turn the switch.

the same pattern has to be received say at least 3 times (out of the 4, or all 4) to be considered valid, in which case there would be little need for a checksum concept in the 'curious' bits.

I think it's this philosophy here !

Either way, if I was designing a receiver to listen to the remote I would just accept the whole pattern as a given, put any further diagnosis aside, program the Rx to learn the pattern, and then listen for at least 3 identical packets and use that as the validity check. Pretty crude, but I reckon it would be ok.

Yes, it's what I'm doing despite of understanding our famous algorithm. But it would be so interesting to understand and to program something cleverer :slight_smile:

ATB

It seem like we agree 100%. The 'curious' bits are indeed enticing morsels of technology, but if just random assignments, to give each remote an identity then trying to crack it maybe superfluous, however if that was the approach mankind to every unsolved technological problem we would still be sitting in dark, dank caves eating woolly mammoths roasted on an open fire.

I think there is a clever bit of programming to be revealed here, but we will probably be unable to crash through at this stage. I think if you put it aside and let a few things settle out while you concentrate on the other parts of the project, something might gel and the answer will hit you on the head like the proverbial falling apple!! I often would tell my students I would have to forget some question they had asked me, usually a problem in their programs, before working it out later on. It was ten times harder in class, but once I had gone home and relaxed it was a whole lot easier. I used to say "We have done enough today I will talk to you tomorrow about it". (My most infuriating bit of problem solving was a processor board my student had beautifully soldered together that was really unreliable, in fact would barely work at all. I checked very joint, component and track probably 10 times over 3 weeks, tried all sorts of things. We had made 40-50 of the boards and they were well tested. Turned out he had put a battery in reverse and instead of getting 6V to run it off it had 4.5V-1.5=3V!! How simple, but stumbled on it at home, quietly, quietly... the language afterwards was not!)

These bits are permanent in the remote (even if you remove the battery).
This code may have been generated randomly in factory but it has to be "curiously-associated" to 7 other codes (3 on, 4 off) through an algorithm we'd like to understand.
If the 8 codes of two buttons are indeed generated randomly (no correlation between them), then it implies every receiver knows all the remotes that could exist. A single remote would mean to be able to store 8(buttons)x4(codes)x16(bits)=512Bytes. I don't know how many different remotes the factory would like to implement, but I guess it will soon be a huge memory. However, today memory costs nothing...

All the Remote factory would need to do would be make list of the numbers they had issued and make sure they did not use the same one twice. If they used a pseudo random number generator, they would only need to know how far through the list they were for the next remote. This number I would suggest is hidden in the 'curious' bits and relate to a checksum, but as it is static and they oblige us with repeating it 4 times, I think a very good project can be made without worrying about any hidden codes (even if they do exist). (Someone coming from a totally different viewpoint may crack it for us?)

I really like your excellent project as switching mains voltages is always a difficult task and if these manufacturers have created cheap little boxes that conveniently do it all for us then that is a real bonus and combining it with thoroughly researched Arduino technology (as you have now done) is a great outcome. I will now patiently await news of the apple!!! ;D

We could also have fun in cracking all the codes that works. To do so, we could just generate all combinations and see if the plug switches.
Something "sad" is that the plugs first have to be paired. It's just a bit longer.
All of this could easily be done by :

  • switching the receiver chip power. It is in pairing process.
  • sending it a code (start with the first one...). It doesn't even need any remote, just connect an MCU to it.
  • trying to switch it again with the same code and also try the 65535 others. Record when it works.
  • do it again

Hum, will I do it... later maybe !

I thought about nearly the same procedure, but it seems to take very long time.
Maybe I will try to pair the switches with 0x0000 or 0xffff for the curious part in the middle.
If it is possible to use this code for pairing then the resulting 3 other codes will hopfully
point into the right direction ...

True !
Looking forward to hear back from your experiment :slight_smile:

Agreed, excellent! :wink:
Even the just first 16, $0000-$00010 could be interesting. If the ELRO switch turned on a spare 5V phone adapter that the Arduino detects, could you could just leave it running and log any discovered "switching" results?

I have also been working on this little challenge :slight_smile:
Here are my findings:

I have measured the signal with an Ikalogic analyser.
I see 3 different waveforms coming fro mthe remote control.

Method 1: 28Bit code
Method 2: Automatic Code learning (AC) KAKU compatible code
Method 3: 24Bit manchester code resulting in a final 12 bit code

Method 2 and 3 are straight forward and easy to replicate.
Indeed the remote is able to control different kind of devices.
As mentioned, the FA500S (Switch) only responds to the first signal which is the one we are interested in.

For clarity:
FA500S Flamingo Switch
FA500DSS Flamingo Dimmer
FA500WD Flamingo Outdoor
FA500R Flamingo Remote Control

I agree with most of the findings posted earlier, like that there is probably some base number like address/button number that is twisted into the magic numbers.
I did a bit of number crunching with the info from the thread and a set I have here.
However, I always seem to get stuck. For sure when adding data from this thread into the calculation mix.

After some more digging I found the following PCB markings on the FA500R's: (can be seen through the battery door)
50027.01B FLF-130105
KT50039.01A FLF-13-06-03 Chip marking: S007V0.1
KT50040.01A FLF-13-06-04 No marking on the chip
there might be more.

If one assumes that the first code is always the same code (for a single RC) and the order of the four codes is also always the same then there could be some base value that is -for example- shifted with the "curious" part. However, it is possible that the different PCB versions use slightly different "tricks" to form the curious part. So perhaps we need to first work with results from the same PCB versions to rule out version differences.

My remote control 1:
KT50040.01A FLF-13-06-04
Lot No 08SA14

My remote control 2:
KT50040.01A FLF-13-06-04
Lot No 11SA13

Mine seem to be of the same type.

One more, PCB: KT50040.01A FLF-13-06-04
A On:
001001 0010100011111101 0111 10
001001 1110110010011110 1101 10
001001 0001010100001110 1000 10
001001 0101100001101101 0101 10

A Off:
001001 0001100000000010 0011 10
001001 1010111011100110 0001 10
001001 1011010100101111 1110 10
001001 0011010011000110 0110 10

B On:
001001 1111111111001010 0110 01
001001 0001001110100000 1110 01
001001 0100111100001101 0001 01
001001 0011001111010101 0100 01

B Off:
001001 0100010010100111 0111 01
001001 1010010010000001 0101 01
001001 1001100001011101 0011 01
001001 1010100110100001 1010 01

C On:
111001 1001110001011000 1110 01
111001 1111110111111111 0100 01
111001 0110100101100111 0110 01
111001 1000111000110111 1100 01

C Off:
111001 0100100111110111 0101 01
111001 0100101001010110 0011 01
111001 0101010000000001 0111 01
111001 1111101010011000 1101 01

D On:
011001 0111010100110110 1010 10
011001 0010000100010100 0110 10
011001 1110100011001101 0000 10
011001 1010011000001000 0001 10

D Off:
011001 0110000111000101 0010 10
011001 0000110110010110 1101 10
011001 0001000101100100 1110 10
011001 1101001100000110 1100 10

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?

Rob

Hello Rob,

I am capturing the code with my own Arduino Mega project.
You can find all about it here: RFLink download | SourceForge.net

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.

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:

Remote A

A on
0010010010011000110010011110
0010010101111111001001110110
0010010111101100111001100010
0010011000110011011001010110

A off
0010011001111001110111000110
0010010010101001001001111010
0010011101011010001001011010
0010011101100011001110001110

B on
0010011101011111101011111001
0010011010011111010011000101
0010011010011000100010010001
0010011011100001011110011001

B off
0010010001011001000111001101
0010011100110011001111101001
0010010101111001011000011101
0010011101001011101110010101


C on
1110010100001000111101011001
1110010110101011110101110001
1110011100001010100111111001
1110011010100110000100010001
C off
1110010010010111001011110101
1110011011110001001100010101
1110011100000110100001001101
1110010000110110111100011101

D on
0110010011101000000111101010
0110010110001000010000011010
0110011101110111000011000010
0110011110111110111011000110

D off
0110011000111000011011001010
0110010111000000001010110110
0110010000111000101110111010
0110010001100111000100110010


Remote B

A on
0010011010110001111001010110
0010011000010110010010011110
0010011101111110111001110110
0010011011000100101001100010

A off
0010010101111110001110001110
0010010101001010110111000110
0010010101111000011001111010
0010010001110101101001011010

B on
0010010101011011011110011001
0010010111011001011011111001
0010010001001011000011000101
0010011111011110110010010001

B off
0010011100010010111000011101
0010011110101110011110010101
0010011001101100010111001101
0010010011010100001111101001

C on
1110011000000001100111111001
1110010101100101110100010001
1110011010111100101101011001
1110010000001011010101110001

C off
1110011111000010010001001101
1110010001000000011100011101
1110010011110011011011110101
1110011011010010011100010101

D on
0110011100100110100000011010
0110010101000111010011000010
0110010100010101111011000110
0110010100010011000111101010

D off
0110010000111001101010110110
0110010110011010101110111010
0110010111100100110100110010
0110011011110000001011001010


Remote C

A on
0010011011010010001011100010
0010010101101110010101010110
0010011000101010001001011110
0010010111010000110011110110

A off
0010011011100110101011011010
0010011111011011111001001110
0010010111111011010100000110
0010011001010100100101111010


B on
0010010100010011011001010001
0010010101001100110101011001
0010011111110011110011111001
0010010111110001000101000101

B off
0010010101011011000101101001
0010011011110000010000011101
0010011111001010010000010101
0010010001111111110100001101

C on
1110011011001111111111110001
1110010001111011110001111001
1110010101010001111010010001
1110010111100100101111011001

C off
1110011111000110010110010101
1110010110100100011011001101
1110011011111101010101011101
1110010010000001101100110101

D on
0110011101111000010010101010
0110010000001100010001011010
0110010010101000011010000010
0110011001100000100001000110


D off
0110011000110010000011001010
0110011101110001010010110110
0110011010100111011101111010
0110010000011111001011110010

At the moment, I'm digging deeper into the binary codes... I think I found something (based on 12 Remote Channels :slight_smile: )
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.

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.

Cheers!