Open obones opened 3 years ago
Ok, unpluggin one socket does not change the number of debug packets seen by the RFLink, so I believe they are part of the message sent by the remote
Here is the signal as seen with a logic analyzer plugged on the RXB6 output pin:
It seems there is a prologue for the 4 frames but none for the very first one.
This repository is sending messages to similar remotes: https://github.com/Mr-Codesaur/SilverCrest_433Mhz_Sockets-Arduino/blob/master/SilverCrest_Sockets.h
It shows what I have also found by myself, the message is 24 bits long, and the above trace shows it 8 times. The first 4 are with a short time base, while the 4 last are with a longer time base. But basically, the way it works is a preamble (Short high, very long low) followed by 24 combinations of either Long High / Short Low or Short High / Long Low giving 1 or 0 as the bit value.
Pressing the same remote button however gives 4 different possible values. For instance, for the On button on row A, we get this:
value | byte 2 | byte 1 | byte 0 |
---|---|---|---|
bf756c | 10111111 | 01110101 | 01101100 |
b7441c | 10110111 | 01000100 | 00011100 |
bd9c5c | 10111101 | 10011100 | 01011100 |
be3aac | 10111110 | 00111010 | 10101100 |
And comparing with other buttons, we get to understand that the first 4 bits are always the same, the last 4 bits define which button is pressed and never change among the 4 possible values. But the remaining 16 bits are changing and I cannot yet spot the place where it says On or Off
For reference, here are the values:
A->On | A->Off | B->On | B->Off | C->On | C->Off | D->On | D->Off | Master->On | Master->Off |
---|---|---|---|---|---|---|---|---|---|
bf756c | b20e7c | b6af35 | b16bc5 | b5212e | be3aae | bae247 | bc1707 | b9d882 | bd9c52 |
b7441c | b5212c | b453f5 | b3b995 | b9d88e | bf756e | b16bc7 | b6af37 | b52122 | b74412 |
bd9c5c | b9d88c | b0f6e5 | bb8dd5 | b8c0be | b7441e | b3b997 | b453f7 | b20e72 | bf7562 |
be3aac | b8c0bc | bc1705 | bae245 | b20e7e | bd9c5e | bb8dd7 | b0f6e7 | b8c0b2 | be3aa2 |
So, b
is the constant part at the beginning, most likely a remote id
And the buttons have the following code in the last 4 bits:
A | B | C | D | Master |
---|---|---|---|---|
c | 5 | e | 7 | 2 |
When we look at the middle 16 bits, we see that the patterns are used either for an On or an Off command, depending on the button. The truth table is like this:
On | Off | |
---|---|---|
f756 | A | C Master |
7441
d9c5
e3aa
20e7 | C
Master | A
5212
9d88
8c0b
6af3 | B | D
453f
0f6e
c170
16bc | D | B
3b99
b8dd
ae24
So, the same b8dd
code is either an On or a Off depending on the button being pressed. Interestingly, this inversion of meaning is given by the value of bit 1 inside the button Id.
If we split the command values in two arrays of 8 values containing the On or Off values, bit 0 inside the button Id tells us in which part of the truth table we must be looking for.
After experimenting, the sockets react to any of the four possible values, it does not have to be the next one in the series everytime, so clearly no rolling code here.
This means it is possible to create a very simple plugin for this.
I've been looking at why RFLink32 on a Sonoff RF Bridge doesn't seem to work with my Silvercrest 284705 remotes/sockets, and it looks like the middle bit patterns and button IDs change with different remoteIds. So there may be 16 different sets of bit patterns:
So, for remoteId 0xD:
A | B | C | D | Master |
---|---|---|---|---|
0 | 4 | C | 2 | A |
And the middle bit patterns:
On | Off | |
---|---|---|
cd63 | A C B | D Master |
f7b4 | ||
b4f7 | ||
4ceb | ||
ae81 | D Master | A C B |
8159 | ||
782a | ||
9292 |
Note there only seem to be 8 possible codes on this remote, not the 16 you had, which I think makes sense because all the remote buttons are even...
Adding those 8 codes to the relevant On/Off tables makes it possible to receive codes, transmitting is obviously a little more fiddly, without having all 16 possible remotes I'm not clear on how we'd determine what the possible middle bits are...For now I've simply bodged the Tx code to always use codeIndex of 9 if the remoteId is d
It looks like the second bit of buttonId is still determining whether the codes on/off meaning should be inverted.
I actually have bought a second set of remote controlled sockets from LIDL and while they share the same structure, they do not have the same middle two bytes as the one in this PR, nor the same as yours. So there must definitely be a rule as to how to compute those two bytes, but I'm yet to find out which one. Considering the size, it could well be a CRC16 from two other bytes : a constant and a counter that goes from 0 to 3 for instance, along maybe with another bit that says "master command". One way to figure that out would be to test for all possible CRC16 values from all possible values in one or two bytes. I have in my never ending to do list an item to use reveng to do just this, I'm just lacking the time to do so...
So, for remoteId 0x5:
A | B | C | D | Master |
---|---|---|---|---|
0 | 4 | C | 2 | A |
And the middle bit patterns:
On | Off | |
---|---|---|
fa1b | A C B | D Master |
3da3 | ||
0254 | ||
8c27 | ||
6e41 | D Master | A C B |
1bb9 | ||
a3fa | ||
c002 |
Hello,
I have a set of 4 remote controlled sockets from Silvercrest, which IAN is 284705. The remote has 4 pairs for each socket plus one "master" pair that controls them all.
Using the debug mode, I was able to get pulses when each button is pressed. Basically, there is one long frame followed by four shorter frames. Maybe those four shorter frames are a reply by each socket. In any case, here is the dump:
The original RFLink claims to support them, but it does not appear in this fork. How can I help to analyze these messages?
Just in case, here are photos of the remote: