[darkcheater]

I tried to program one of my switches to your codes from post #5 but the switch didn't want to learn your code

[dominik.]

Hi NeoFlo,

your ON/OFF raw codes work with my switches. Even if I program the switch with my remote, I can switch them on and off with your raw codes as well.

Can you let me know how you got those? If I use my remote with pilight-debug I never receive those.

Would be great if we could find a solution for the GT9000 and implement them as a protocol

[dominik.]

Hi,
I just managed to reverse engineer some parts of the protocol based on the raw codes on the first page of the thread:

Code:

    Systemcode    ON/OFF            ON/OFF    ID
ON-1-NEW    10001    110100101010            011    0000
OFF-1-NEW    10001    000001101110            010    0000
ON-2-NEW    10001    110100101010            011    0100
OFF-2-NEW    10001    000001101110            010    0100
ON-3-NEW    10001    110100101010            011    1100
OFF-3-NEW    10001    000001101110            010    1100
ON-4-NEW    10001    110100101010            011    1000
OFF-4-NEW    10001    000001101110            010    1000

I'm not sure about the middle ON/OFF part, any ideas?

Changing the system code and/or ID works for me.

[dominik.]

Update...current status based on only ONE systemcode:

Code:

_        Systemcode  on/off  0  on/off   0   on/off   101   on/off   1001   on/off     ID
ON-1   10001            11      0   1        0      0       101      0      1001     1        0000
OFF-1  10001            00      0   0        0      1       101      1      1001     0        0000

Quite sure about the ID
Pretty unsure what the on/off things are inbetween. There could be some parity bits, but I have no ideas currently. Moreover the 101 and 1001 could have something to do with the systemcode as well.

If I change the systemcode to 11111 switch OFF doesn't work, unfortunately ON works (or at least the programming). Any ideas?

[dominik.]

No one interested in that topic?? As far as I know this are the cheapest wireless sockets on the market, therefore I'm wondering that really nobody is interested.

[stuntteam]

It looks like encrypted data..

[dominik.]

It looks like encrypted data..

I'm not sure if such a cheap wireless set would encrypt data? If so, I shouldn't be able to change the systemcode I assume.

[stuntteam]

Yeah.. not sure.. that was based on your 24 bit code.
Cheap remotes like unitec, mumbi, flamino all use scrambling so that is not weird at all.

How do you convert from the pulse values.. being 48 pulses that all could have 4 possible states..to a 24 bit code?
Well, not 4 states.. it seems less.. but i guess a test would be needed to see if there is a difference between for example a 1000 or 800 pulse to the socket

[dominik.]

I converted them by the usual syntax:
everything below 700 => 500
everything above 700 => 1000

500 1000 => 0
1000 500 => 1

It seems to be independent of the pulse. I'm currently sending only 500 and 999 and it works.

[stuntteam]

Ok, it seems odd that they use 4 different timing values and that these really just boil down to a high/low sequence.
Anyway.. if the socket does not mind then it is great!

However, following your logic and some log data I got..
10110 111100100100 001 1100 1 on
10111 100110011100 010 1100 1 off
This does not seem to fit into your systemcode/on/off/id plan

It looks much more like the 4 bits-16bits-4bits patterns like seen on Unitec/Silvercrest codes used on the BAT/Brennenstuhl sets.
These codes are in fact not 4/16/4 bits patterns but real 24 bit codes that need to be descrambled to get the proper system code etc.

Of course that only applies if there is really no issue with a difference in timing.. thus if the socket does not mind that 2*208 equals 3*208 and 4*208 equals 5*208

If only I had a set to hang to the logic analyser..