[curlymo]

Can you post the full concept of this protocol somewhere?

[neevedr]

http://pastebin.com/9YUvur7z

It's a edit of conradRSLSwitch

[curlymo]

Start by making the:

Code:

conrad_rsl_switch->pulse = 2;

4 or 5.

[neevedr]

That is changing al lot

Code:

conradRSLSwParseBinary: 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

But i need more help.

Code:

    conrad_rsl_switch->pulse = 4;
    conrad_rsl_switch->rawlen = 50;
    conrad_rsl_switch->lsb = 2;
    conrad_rsl_switch->binlen = 12;

Is this correct or valid? How do i know if this is correct?
The one's and zero's are making me grazy.

[wo_rasp]

I have finished the Tx part on the quigg_switch pilight protocol modul for the GT-7000 remote controller to operate the GT-FSi-04a switches. The protocol got integrated into the development branch on the pilight GIT repository.

Total frame length is 42 pulses, including footer.
Timing created by quigg_switch:
SYNC: 720
BIT-0: 720 - 1200
BIT-1: 1200 - 720
BIT-X: either BIT-0 or BIT-1
FOOTER: 4080

Protocol Frame:
1 SYNC
1 BIT-1 - Start
5 BIT-X - DEVICE_ID for the GT-7000 (You can pair the GT-FSi-04a with any DEVICE_ID using the Learning button on the GT-FSi-04a)
6 BIT-0 - DEVICE_ID2 ( ? - currently statically initialized with zeros)
2 BIT-X - SWITCH_UNIT_ID (Buttons 1 to 4 on the GT-7000)
1 BIT-X - ALL (BIT-1 if ALL Key on the GT-7000 is pressed, in addition SWITCH-ID is 2 BIT-1)
1 BIT-X - ON/OFF (BIT-0 is OFF, BIT-1 is ON)
1 BIT-X - SWITCH_UNIT_ID Dimmer (BIT-0 if Dimmer Button not pressed)
1 BIT-0 - unknown
1 BIT-X - Algorithm unknown, either BIT-0 or BIT-1, depending on SWITCH_UNIT_ID used
1 BIT-X - Odd Parity (excluding SYNC and FOOTER Pulse)
1 FOOTER

protocol_plslen_add(quigg_switch, 120);
quigg_switch->pulse = 5;
quigg_switch->rawlen = 42;
quigg_switch->binlen = 21;

Current status:
Tx:
The Tx part is working, including the pilight Web Interface. Currently i have defined:
id - to enter the DEVICE_ID
unit - to enter the SWITCH_UNIT_ID
on - turn switch on (in Dimmer mode down)
off - turn switch off (in Dimmer mode up)
all - turn all units associated with the DEVICE_ID on or off

Example for configuration in /etc/pilight/config.json:
{
"location": {
"name": "name of room",
"device": {
"name": "Control Switch xy",
"protocol": [ "quigg_switch" ],
"id": [{
"id": 12,
"unit": 1
}],
"state": "off",
"gui-readonly": 0
}
}
}

CLI:
The GT-FSI-04a switch has a learning mode button.
You need to configure the DEVICE_ID and the SWITCH_UNIT_ID
In the example configuration above, DEVICE_ID is 12 and SWITCH_UNIT_ID is 1

The GT-7000 handheld remote control defaults to id 12 after batteries are inserted.
The following command
"pilight-send -p quigg_switch -id 12 -u 1 -t"
is the equivalent of pressing the "ON Button 2" on the GT-7000 remote controller.

Press the learning button on the switch and issue a command with pilight-send to pair a switch with pilight.
valid codes are:
id: 1 ... 31
unit: 0 .... 4 ( The switch GT-FSI-04a ignores unit: 4, i assume it implements dimmer functionality).

Rx:
The LPF V2.0 is dropping the first 8 pulses of the GT-7000 protocol. I will created a message with my analysis attached in the appropriate section of this forum.
Without LPF i experience a lot of interferences.
The learning algorithm of the GT-FSi-04a works with the existing Tx code.
The receiving part is only required for analysis of the DEVICE ID used.
If the GT-7000 handheld shall be used together with pilight i use the following two workarounds until a new LPF version is around:
1) The GT-7000 defaults to a standard DEVICE-ID (Binary 01100) after the batteries are inserted.
2) I connect pilight directly to the 433 MHz receiver and analyse the RAW output for the DEVICE ID in use (Pulse 4 to 13 after the long footer pulse: short-long is 0, long-short is 1).

[RinusW]

I own several Quiqq switches of the type GT-7008AS that can be controlled by the remote controller GT-7000. So apparently the GT-7008AS are somewhat compatible with the GT-FSi-04a switches. The GT-7008AS switches are self-learning switches too. They can be learned to listen to any id and unit code that the remote produces. So, I decided to give the quigg_switch protocol a try to control my switches. At first this seemed to work, i.e. the default value id=12 worked well with the 4 different unit codes. But when I tried other id values, it was quite obvious that for some id values the implemented protocol didn't work at all. Switches refused to accept the transmitted code, even in the learning mode. Therefore I decided to investigate these switches somewhat further.

So I started with my receiver module, coupled to my digital scope, looking at the pulses that came out of the receiver. The first thing I noticed is that the pulse width varies somewhat, and that the short pulses usually are somewhat shorter than the 700 us used in the current protocol implementation. And that the long pulses clearly are longer than the 1200 us. Based on my measurements I decided to use a short pulse width of 680 us and a long one of 1320 us. The ratio therefore is closer to 2:1 than in the current implementation. But this alone didn't solve the problems controlling the switches.

As second step I decided to investigate the meaning of the bits in the protocol frame a bit further. Although the frame construction seems as described in the previous posting (a very good job, btw), the meaning of too many bits stayed unexplained. So I decided to write a special version of the protocol, I called it quigg_raw, that enabled me to specify the frame as a binary bitstring. So to switch on switch id=12, unit=3 I would specify the bit string “1 01100 000000 01 01000 0”. The used spaces improve the readability by grouping functional bits. (Btw a json string without any spaces as input gives an error message. Is this a bug?)

Anyway, by experimenting with this quigg_raw protocol I was able to confirm the function of most bits in the frame. Most, but not all. Especially the 6 zero bits after the id-field were intriguing. The implementation seemed suggesting that the device id could be repeated here. When I tried this, switch control improved a lot. Combinations of id and unit code that didn't work, now seems to work well. But the switches first had to learn this new code. To make clear what I mean, an example. Repeating the code for id=12 in the earlier example leads to the bit string: “1 01100 01100 0 01 01000 0”. But then a switch, programmed to listen to this code, works well, but refuses to work with the remote control that also sends codes with id=12. And switches programmed to react to commands with id=12 don't do anything when receiving the bit string.

Some more experiments confirmed my suspicions. The first 12 bits form in fact a single device-id field, and the last bit of these 12 bits is an odd parity bit over the whole id field. So actually, the switches recognize 11 active bits for the id, giving the id a range from 0 to 2047. And this explains why some id's simply didn't work. The parity over the id field was not correct and probably therefore the overall parity was not either.

In fact, the first half of the protocol frame should be specified as:
1 SYNC - high pulse (mark) of 680 us. Is in fact a start pulse, not part of the frame
11 BIT-X - device_id, range 0 .. 2047
1 BIT-X - odd parity over the previous 11 bits
2 BIT-X - switch_unit in Gray code, i.e. 00, 10, 11, 01 for unit 0,1,2,3
last 6 bits (excluding footer) as explained in the previous post.

So, the next step is a protocol implementation based on these findings. Since I can confirm only the correct functioning for the Quigg GT-7008AS switches I called it the quigg_7008 protocol. I have added an optional mode parameter to the protocol. In default mode, the protocol uses the coding scheme for the id conform the remote control. Especially the first bit always is 1, the next 5 bits contains the id, the next 5 bits are always 0, and the last bit of the id-field is the odd parity bit. In the extended mode all 11 bits are used to encode the id, msb first. This means id=12 in the default mode is the same as id=1408 in the extended mode.

The implementation works, and solved the problems I had when using the original code. Of course I would be glad to share my implementations (both quigg_raw and quigg_7008) with you, but it is not clear for me how I can do that. Of course I can upload a zip file with the source code, but then you have to know what to do to add a new protocol to the pilight system. And that is not a trivial thing to do, although not difficult either.

[curlymo]

Yes, please post it, so i can release it as a module and wo_rasp can have a look at it as well.

[wo_rasp]

I own several Quiqq switches of the type GT-7008AS ....
At first this seemed to work, i.e. the default value id=12 worked well with the 4 different unit codes. But when I tried other id values, it was quite obvious that for some id values the implemented protocol didn't work at all.
...

This is correct, my original assumption was wrong that the id field is only covering 0....31. 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.
Please drop me a PM and i will mail you a compiled zipped pilight directory.

So I started with my receiver module, coupled to my digital scope, looking at the pulses that came out of the receiver. The first thing I noticed is that the pulse width varies somewhat, and that the short pulses usually are somewhat shorter than the 700 us used in the current protocol implementation.
And that the long pulses clearly are longer than the 1200 us. Based on my measurements I decided to use a short pulse width of 680 us and a long one of 1320 us. The ratio therefore is closer to 2:1 than in the current implementation. But this alone didn't solve the problems controlling the switches.

The problem you decribe 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).

As second step I decided to investigate the meaning of the bits in the protocol frame a bit further. Although the frame construction seems as described in the previous posting (a very good job, btw), the meaning of too many bits stayed unexplained. .......

I am currently in a discussion with curlymo on what should be included in the protocol driver and what should not. The GT-7008AS seems to work a bit different than other devices, i am guessing here a little bit, as i am waiting for a GT-7008AS to be shipped as a spare part and i have engineered the protocol from the GT-7000 handheld transmitter, but i am sure that my interpretation is quite right.

Please use the following link to read all the details on the current status:
http://wiki.pilight.org/doku.php/quigg?rev=1402011621
I can not fully explain Bit 18 and 19, i simply handle them the same way the GT-7000 does.

The first 12 bits form in fact a single device-id field, and the last bit of these 12 bits is an odd parity bit over the whole id field. So actually, the switches recognize 11 active bits for the id, giving the id a range from 0 to 2047. And this explains why some id's simply didn't work. The parity over the id field was not correct and probably therefore the overall parity was not either.

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.

So, the next step is a protocol implementation based on these findings. ....

The development version of the quigg_switch protocol V5 is updated and available from the git repository.

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

pilight-send -u quigg-send -id 2816 -u 2 -t (turn unit-switch 2 on)
pilight-send -p quigg_switch -id 2816 -u 2 -d -t (for dimm down)
pilight-send -p quigg_switch -id 2816 -u 2 -d -f (for dimm up)

(The current quigg_switch version is using the id bits in reverse order, the previous id=12 is now id=2816, but again, i will look into the parity issue as well)

Especially the first bit always is 1, the next 5 bits contains the id, the next 5 bits are always 0, and the last bit of the id-field is the odd parity bit.

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.

---

Yes, please post it, so i can release it as a module and wo_rasp can have a look at it as well.

Please see my previous posting.
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.

[RinusW]

First of all I will post my implementations. And later on I will react to the latest posting of wo_rasp. But for now, I can assure you that my 7008AS switches all react within 4 repeats of the command string.

Some other remarks related to my implementations:
- I like to specify the number of repeats in the protocol instead of in the setttings file. This is the reason for the option "repeats" on the command line.
- When pressing any key, the remote control repeats the command every 122,5 ms. This means a pause of 81 ms. And I implemented this pause for the length of the footer.
- The bit string for the raw protocol implementation should contain at least 1 space (a json string wants this) and exactly 19 bits. The trailing parity bit is calculated and is not included in the bit string
- A typical use of the raw protocol is, where id=1010 and unit=0

Code:

pilight-send -p quigg_raw -c "0 11111 10010 0 00 01000"

- The equivalent command for the quigg_7008 protocol is

Code:

pilight-send -p quigg_7008 -i 1010 -u 0 -t -m 1

- For the quigg_7008 protocol implementation I found it easier to convert the command first into a binary bit string, and convert that string into Mark-Spaces. I choose to define my own global array bincode for this purpose, and not use the protocol-structure element quigg_7008->code[]
- For debug purposes, in the quigg_7008 implementation I included the binary code string in the json message. This is of course not a vital piece of the implementation.
- Of course, the mode option is not mandatory. An implementation with only the extended mode is no problem. I could do that quite easily.
- I didn't do anything about the receiving part of the protocol. This is, because I only want to control my switches and not use my remote for other purposes.

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