Lidl sockets basic

[renekliment]

This adds support for remotely controlled sockets branded as SilverCrest, sold in Lidl stores.
The code is derived from the codes on an Arduino Forum page. All credits for figuring out the protocol and writing example codes go to those people ( Collie147, Poopi ).

There are a couple potential issues / weird things about this, but it shouldn't pose a problem for merging:

1. The codes (the values) from the remote are decoded correctly, but flagged as protocol 3. However, the actual protocol is different and transmission of those codes to the sockets doesn't work (thus this PR). I think we can stick with the current detection - people just have to make sure they set the proper protocol when transmitting - they can't rely on the information told by the ReceiveDemo_Advanced.
2. The protocol actually consists of two subprotocols (4 and 5 in the code). The original RC just sends the message using protocol 4 and then protocol 5. However, using just one of those works also, so there seems to be no need for a major rewrite of the library to do this. People can now choose either of those or they can make a helper function that does something like setprotocol(4) send(code) setProtocol(5) send(code), we don't have to do that in the library.
3. The RC rotates 4 codes for each button. Sending any of those codes works every time, so if the user wants to rotate those codes, they can again do it externally.

I believe these things are meant for better durability of the transmission, but it works for me regardless and it can be implemented by the user as mentioned above.

This PR is also derived from my previous patch and it also conflicts with an earlier PR by mattvenn. I can update this PR if the other one is merged first.

Thank you for your potential comments and consideration.

[fingolfin]

@renekliment If you have time, it would be great if you could add information about your sockets on https://github.com/sui77/rc-switch/wiki/List_KnownDevices

[ASDBigmac]

The protocol issue with Protocol 4/5 being detected as Protocol 3 also counts for the sockets sold by Aldi Süd End of 2015 branded EasyHome (Globaltronics GT-9000 + GT-FSI-07)

[renekliment]

@fingolfin Sure, done. Sorry for the delay - your comment just got lost in the flood of GH notifications.

[fingolfin]

Actually, I just realized that protocols 3 and 5 perhaps are the same afterall!

The reason sending did not work was that the sync pulse was not quite right for protocol 3 in the past: it was { 1, 71 }; but this did not work for me, so I measured what the remote sends, and based on that, changed it to { 30, 71 }

So now we have this:

    { 100, { 30, 71 }, {  4, 11 }, {  9,  6 } },    // protocol 3
...
    { 500, {  6, 14 }, {  1,  2 }, {  2,  1 } },    // protocol 5

If you change things to a uniform base unit of 100us, we get:

    { 100, { 30, 71 }, {  4, 11 }, {  9,  6 } },    // protocol 3
    { 100, { 30, 70 }, {  5, 10 }, { 10,  5 } },    // protocol 5

Note how close the values are. Indeed, close enough that the fuzzy matching implemented in rc-switch ignores it.

As a result, my remote which sends using protocol 3, regularly is detected as protocol 5 instead. But based on raw timings, I know it is really using the assymetric protocol 5.

And you know, it's a Brennenstuhl, sending 4 rotating codes; using any of those, however, works fine... Sounds familiar? :-).

So, in conclusion, I now wonder how you came up with the values for protocol 5. Did you perform measurements? Do you still have the raw timings? Perhaps protocol 3 (in the current, revised form) now works for you, too, and we can get rid of protocol 5 again? (Or makes it an alias for protocol 3, for backwards compatibility.)

[renekliment]

Sorry @fingolfin for the late answer - once again your message got lost in the notification flood - I have to do something about it. I don't have really time to test, but I guess your assumption is right. As mentioned in the PR message, I used custom codes from Arduino forum (link above) for putting this PR together. As you can see, there are multiple values used, based either on precise measuring or a guess more-less:

#define SHORT_DELAY 373
#define LONG_DELAY  (3*SHORT_DELAY)
#define TOTAL_DELAY (SHORT_DELAY + LONG_DELAY)
#define SYNC_DELAY  (6*SHORT_DELAY)
#define EXTRALONG_DELAY (3*LONG_DELAY)

and

#define SHORT_DELAY       380
#define NORMAL_DELAY      500
#define SIGNAL_DELAY     1500
#define SYNC_DELAY       2650
#define EXTRASHORT_DELAY 3000
#define EXTRA_DELAY     10000

I can't remember exactly which value means what and how I deciphered the values for rc-switch since it's two protocols combined and I don't wanna study the two sketches right now, but you get the idea. It's also totally possible I rounded off some numbers, which I hope I didn't do, but I honestly can't remember. See the two codes if you need further details :-)

Thank you.

[fingolfin]

@renekliment No need to be sorry, and thank you very much for your reply. I'll try to keep track of this on #53.

[2afs]

Hi. I am locking for a solution to send codes like a GT-3000 (Globaltronics) from EASY HOME. Receiver is GT-FSI-10. The codes I got using RFSniffer with 433Utils pushing the ON Button "C" was rolling code "16188814", "15998142", "16181630", "16501550". Unfortunately sending the codes does not have any effect.....
Can somone help me? Many thanks in advance.

[Ebiroll]

Hello. Thanks for your help here. I also reversed the Lidl sockens basis and found this thread. I wrote an article about how to do it in case someone would need it. https://olof-astrand.medium.com/hacking-wireless-sockets-like-a-noob-b57d4b4812d5 However my remote used different tidnings conpared to the one explained described here, but the same protocol.