[RinusW]

Please use the version that comes with pilight V5. Although this version won't dimm the 7008AS, this requires the latest release from the development branch.

Yes, I should update my repository on a regular base. But I didn't, so I'm talking about V4.
As far as I know, the 7008AS switches do not have a dim function. And the manual of the GT-7000 remote, that can be found here http://www.gt-support.de/files/IM_GT-700...SI-04a.pdf, indicates that the “dim key”doesn't have a real function.

The problem you describe is related to the short footer length, which is only 4000µS with the pilight driver you use. For the learning mode of the switches, the footer length has to be at least twice as long. The actual pulse duration for a short pulse can vary between appr. 620µS and 950µS. The current release uses 700µS and 1400µS and for sending of data a footer length of 23000µS (the GT-7000 uses 81192µS).

Sorry, I forgot to say that I was looking at the pulses produced by the remote control unit and not by the sender of pilight. Some other numbers measured with my scope: the pulse sequence has a duration of 41,5 ms and a repetition time of 122,5 ms, which means that the footer is 81 ms. Since the pulse sequence always has 21 short and 20 long pulses, and when we assume that a long pulse is twice as width as a short pulse, the duration of 61 short pulses therefore is equal to 41,5 ms. This gives 680,3 us for a short pulse and 1360,7 us for a long pulse. But probably 700 and 1400 us will work fine too.

You are correct, the parity bit covers Bit 13 to 19 only, but in my logic it is an even Parity Bit.
I will check into the odd parity bit issue, as my GT-FSi-04a will work without parity bit and the GT-7000 handheld seems to use al 12 bits as an id. Your finding with the Gray code is correct.

If you agree that bit 1..11 are the actual device-id bits and bit 12 is an odd-parity bit over the bits 1..12 (i.e. the device-id bits) then it is correct that the last bit (bit 20) is an even parity bit over bits 13..20. And since bits 1..12 have an odd parity, this is the same as saying that bit 20 is an odd parity bit over all bits 1..20.
My GT-7008AS switches will not switch reliable when not both parity bits are correct. So the effective id-range of these switches is 11 bits or 0..2047.

I have a question regarding the fifth button row.
I have called it dimm, as it seems to implement the dimm functionality and is always active for the last switch-unit used, i.e. if you turned unit 2 on the dimm button will send pulses to unit 2 to be interpreted as either
"dimm-down" or "dimm-up".
The current version of the quigg_switch protocol driver does not remember which unit was used last, thus you need to add the unit when using the dimm functionality (In opposite to the GT-7000, with pilight you do not need to send a turn on/off command first before using the dimm button).

I didn't study the function of the so-called dim key, and I didn't implement any special functionality in my 7008 protocol either, because the GT-7008AS switch doesn't have a dim function, and doesn't react when pressing this key. And according to the manual mentioned earlier the GT-FSI-4a should not either.

The GT-7000 is using the other bits as well, it just takes some time to get to that point, just press the "Neuer Code" button for 1 minute or 2..... and it uses it as one bit block.

I agree that the mode parameter isn't needed. I will remove it from my implementation and use only the 11 bit id-addressing format.

I am really struggling with the footerlength issue we have discussed so far, can you please have a brief review on my latest pull request and give me a hint what i am not doing right with regards to adding additional pulses. In principle the code works, but reaction time is sluggish.

The problem i currently face is the fact that a real switch will react within 4 pulses, whereas pilight requires at least a pulse stream of 500mS or more.

My measurements showed that the remote control GT-7000 repeats the command only after 122 ms. This is a repetition frequency of 8 per second. 4 pulses is then equal to 500 ms.
My advice is: make sure that both parity bits are correct. Only then the switch will work in a reliable way. I can operate my switch from pilight with just a single pulsetrain, i.e. no repetition at all.

Keep up the good work
regards

(BTW, I like writing these kind of programs, and puzzling to see what is going wrong. So I don't mind that I missed the new release )