-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Silvercrest (LIDL) 284705 remote controlled sockets #66
Comments
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:
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. For reference, here are the values:
So,
|
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.
So, the same 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:
And the middle bit patterns:
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, for remoteId 0x5:
And the middle bit patterns:
|
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:
The text was updated successfully, but these errors were encountered: