Go Down

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

robwlakes

                 
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






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

Stuntteam

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/



Stuntteam

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.


wex_storm

#48
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
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

wex_storm

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

robwlakes

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!

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

renard-ad

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

Quote
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 !

robwlakes

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.

Stuntteam

Hi,

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.


robwlakes

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.

Stuntteam

Yes, it is possible to calculate the 'keys'

wex_storm

#56
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]

1110010000000000000000110001
1110010000000000000000111001
1110010000000000000000010001
1110010000000000000000011001

and

0000000000000000000000000000
0000000000000000000000000001
0000000000000000000000000010
0000000000000000000000000011

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 :)

Cheers,

   Bjoern

Karl-Heinz

#57
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.

Stuntteam

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

Simplified:

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.



                               


robwlakes

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