Lidl sockets basic #11

Merged
merged 3 commits into from Dec 8, 2015

Conversation

Projects
None yet
4 participants
@renekliment
Contributor

renekliment commented Nov 23, 2015

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.

sui77 added a commit that referenced this pull request Dec 8, 2015

@sui77 sui77 merged commit 94d25fc into sui77:master Dec 8, 2015

@renekliment renekliment deleted the renekliment:lidl-sockets-basic branch Dec 23, 2015

@fingolfin

This comment has been minimized.

Show comment
Hide comment
@fingolfin

fingolfin Jan 7, 2016

Collaborator

@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

Collaborator

fingolfin commented Jan 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ASDBigmac

ASDBigmac Jan 17, 2016

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)

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

This comment has been minimized.

Show comment
Hide comment
@renekliment

renekliment Jan 19, 2016

Contributor

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

Contributor

renekliment commented Jan 19, 2016

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

@fingolfin

This comment has been minimized.

Show comment
Hide comment
@fingolfin

fingolfin May 5, 2016

Collaborator

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

Collaborator

fingolfin commented May 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@renekliment

renekliment May 23, 2016

Contributor

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.

Contributor

renekliment commented May 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fingolfin

fingolfin May 23, 2016

Collaborator

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

Collaborator

fingolfin commented May 23, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment