• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register

QUIGG (Globaltronics/ALDI)
(06-12-2014, 03:51 PM)RinusW Wrote: 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.
With the 7008AD and the GT-FSi-04d ithis button the two buttons in row 5 activate the dimmer within these switches.
(06-12-2014, 03:51 PM)RinusW Wrote: 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.
The values are the same then the ones i have measured. My switches here will work with short pulses in the range of 620 to 950µS and the learning mode requires a minimum pulse length of appr. 6000µS.

(06-12-2014, 03:51 PM)RinusW Wrote: 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.
Actually, at least with my GT-7000 and an 7008AD switch i do not. I can not confirm the following binary strings for the ID:
1011 0000 0000 - initial value, the GT-7000 is actually incrementing that value in the following manner:
0111 0000 0000, 1111 0000 0000, 0000 1000 0000 .... until 1111 1111 1111
and than it rolls over ( i do not know if it starts at 0000 0000 0000, as i did not catch the exact roll over)
The following is an output from my current protocol driver to turn Unit 1 off:
id: 1537 unit code: 1 all: 0 state: 0 dimm: 0 parity: 0
011000000001 10 0 0 0 01 0

(06-12-2014, 03:51 PM)RinusW Wrote: 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-FSi-4d manual mentions it.

(06-12-2014, 03:51 PM)RinusW Wrote: 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.
As said before any footer above 6000 does work for me on the real switch, the problme here is the way pilight operates, it relies on a "footer to short pulse duration" relation to determine the protocol type.

I'll keep the Wiki updated with any new findings.
Quote:it relies on a "footer to short pulse duration" relation to determine the protocol type.
You keep repeating this while it just isn't true. It doesn't rely on any relationship.
I agree with curlymo. I simply specify a footer length of 80920 us in my implementation, and that works.
Then, since I don't have any switch with dimmer functionality, I can only comment on the behavior of the GT-7008AS switches as I experience it. And I can only repeat that in my experience these switches work reliably only when I take both parity bits into consideration.
The example you give with id=1537 actually would work because the binary representation is 0110 0000 0001 which is also an 11 bit number with odd parity bit. I would then use id =768.
Here are the actual binary command strings transmitted for the on and off command:
on: 0110 0000 0001 10 010011
off: 0110 0000 0001 10 000010
So for the off command the last parity bit is indeed 0, which is an even parity over the last 8 bit, or an odd parity over all the bits.
So, a better example would be one with id= 1536 = 0110 0000 0000
In my situation the switch reacts in learning mode to this code, but not afterwards anymore. This is what I mean with reliable.
You are right!!
The id field is 12 bits without parity, and the last bit of the bitstring is the even parity over the last 8 bit, including the parity bit itself.
I realised that I had to adapt my raw protocol implementation to be able to test this. My original implementation automatically generated an odd parity over the whole bitstring, which of course is not the same as an even parity over the last 8 bit.
Anyway I changed my implementations and my switches work reliable, also for id = 1536.
You did a good job!
Time for implementations Wink
(06-15-2014, 11:06 PM)curlymo Wrote: Time for implementations Wink
I have updated the quigg_switch protocol to be fully compliant with your footer and pulse handling, im currently debugging the details using various system setups (networked - not networked).
Same applies for the ninjablock driver.
Were? The pull-request hasn't changed?
No, it has not. I guess that due to the pull request #106 not being closed it remained active with all the comments integrated and committed afterwards. It should not be a problem, as i kept the repo synchronized with the upstream pilight development repo.
(06-16-2014, 04:02 PM)curlymo Wrote: Were? The pull-request hasn't changed?
No it did not.
I have separated the switch on/off and dimm up/down function for dimmable QUIGG switches into two protocols:
SWITCH: ON/OFF turns the switch with id-x and unit-y on or off.
SCREEN: UP/DOWN incrases/decreases the voltage output on dimmable quigg switches with id-x and unit-y like the 7008AD or GT-FSi-04d in 16 steps. Non dimmable switches like the GT-FSI-04a, ignore that command.
I have added error checking, so the SWITCH driver will not pass on any received messages with dimm content and the SCREEN driver will not pass on any received messages without dimm content. This has the side effect, that you can dimm down a device, but the switch status will remain ON and you can brighten up a device but the switch status will remain OFF.
The dimmable QUIGG devices do not support setting a dim-level directly, nor do they report a dim-level back.
I have tested a DIMMER version, but that won't work with the current GUI, the reason is the usage of ON, OFF, and STATE, i do need a separate UP, DOWN, and STATE condition for the dimm property.
hey guys,

first of all a big thanks to curlymo for creating this pilight thing here. pretty awesome work!

but now back to topic, i tried to control my GT-7008AD(2008) Aldi (Globaltronics) Receivers. The Sender is a GT-7000

So i got everything up and running.
Using the Latest Devolopment pilight version 5.0.119-gde922e4

So i got my receiver hooked up on the rpi, so it receives input from the GT-7000 like this:
"message": {
"id": 576,
"unit": 0,
"state": "on"
"origin": "receiver",
"protocol": "quigg_switch",
"uuid": "0000-00-00-61-4502d4",
"repeats": 1

Everythin fine so far.

But when i try to send this ID and UNIT with "pilight-send -p quigg_switch -i 576 -u 0 -t" the switch does not receive anything.

I switched channels with the reset button. Plugged the sender from 3,3V to 5V - hooked up a 17,3cm Antenna. NO SUCCESS AT ALL

Now my last resort is to buy the same 433Sender again (i bought this one http://www.amazon.de/gp/product/B00ATZV5EQ/) maybe its defect?

Anybody got these GT-7008AD(2008) working - i mean if the GT-7000Protocol is emulated and understood, it should work eh?

thanks for reading and ANY suggestion.


Attached Files Thumbnail(s)

Possibly Related Threads...
Thread Author Replies Views Last Post
  Quigg GT-1000 maartenh 55 41,498 07-28-2020, 03:21 PM
Last Post: pgScorpio
  QUIGG GT9000 (Globaltronics/ALDI) NeoFlo 140 105,565 01-07-2020, 04:03 PM
Last Post: aP7D1CKD
  [Solved] Quigg GT-1000 leaving transmitter ON VrahoK 11 2,989 12-22-2019, 12:17 AM
Last Post: VrahoK
  Brennenstuhl RCR CE1 1011 with QUIGG GT9000 Protocol scootermacro 1 1,431 06-27-2019, 06:20 PM
Last Post: scootermacro
  Weather Station Globaltronics GT-WT-01 Prutsky 13 11,442 04-09-2018, 07:34 PM
Last Post: NevelS
  quigg gt7000 Dimmer wchristi 11 11,281 04-30-2015, 09:25 AM
Last Post: wo_rasp
  Quigg Screens curlymo 6 5,883 01-31-2015, 07:33 PM
Last Post: curlymo

Forum Jump:

Browsing: 1 Guest(s)