• 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 GT-1000
If you enable the stable apt repository of pilight you will be able to install libunwind, that's why it's required.
Am I right that the protocol you have developed is picking codes from a set that is hard coded in the protocol? If so, I will not recommend this to my neighbours, because there is a risk that they will use the same codes as I. Or am I wrong?

I made a protocol myself that uses the actual 0's and 1's of the remote, converted to decimal (see post #4 in this thread of december 23), which is working fine for all 8 of my QUIG-GT1000 switches.
Oke, I did that. installed libunwind and libpcap
I compiled and build the latest development. Had to change a few things in my source, but everything build well.

But then, things don work. I give a pilight-send command, I see the command in the daemon, I see my json message in the daemon, but I don't see any raw code in the daemon. And, even more important: I don't see any 433 MHz activity on my scope. So, apparently the transmitter doesn't get any signals. What am I overlooking?

This is not only my protocol. Other protocols do neither lead to any 433 MHz activity. The hardware.json file seems ok. (sender:0 receiver: 1) or did that change?
The whole configuration structure got changed. Again, read the nightly documentation and visit all nightly threads.
This holds for all switch protocols in pilight. One need to support all RC's (group-id's), so the protocol can be used by all owners of a Quigg switch. But if your neighbor has an RC with a different group-id, then they use a different set of codes. What is selected randomly, is the middle part (16 bit) of the whole 24 bit code. The other 8 bits depend on the group-id and switch-id used.

But then, there are only 16 different RC's (16 different group-id's). So there is always the possibility that your neighbor get an RC with the same id. Older Quigg RC's got the possibility to change their group-id in such a case. The GT-1000 does not. The nice thing then is that pilight allows you to choose a different id, and use your switches independent of your remote.
Big Grin 
Oke, I should have read some more info :-) . Created a new config.json file, and got everything running. But then the pilight-deamon seems not very stable. After a few pilight-send commands I can see in the debug mode that the daemon stops updating the switch status (at least doesn't produce that message any more) and then doesn't accept any more send commands. But since I don't have the possibility to debug this any further, I assume the problem is not in my implementation.
I will commit therefore my .c and .h files together with the changed CMakeConfig and CMakeLists file and it is up to you what to do with it.

Thanks for your explanation. I assumed that the group id wasn't only in the first four bits, but that part of it was hidden in the middle bits. I just couldn't believe that there were just 16 possible group id's, but apparently that is the case. Also I didn't realize that you cannot change the id yourself with the GT-1000 remote.

Knowing all this, I will probaly drop my own QUIGG GT-1000 protocol and start using yours. I see that yours is now in the pilight development branch and I will test it with my switches soon.

I tried to compile the Quigg GT-1000 protocol, but I get these errors:

root@raspi2:/home/pi/pilight#  gcc -fPIC -shared libs/protocols/quigg_gt1000.c -Ilibs/pilight -Ilibs/config -o quigg_gt1000.so -DMODULE=1
libs/protocols/quigg_gt1000.c:391:27: warning: ‘struct module_t’ declared inside parameter list [enabled by default]
libs/protocols/quigg_gt1000.c: In function ‘compatibility’:
libs/protocols/quigg_gt1000.c:392:8: error: dereferencing pointer to incomplete type
libs/protocols/quigg_gt1000.c:393:8: error: dereferencing pointer to incomplete type
libs/protocols/quigg_gt1000.c:394:8: error: dereferencing pointer to incomplete type
libs/protocols/quigg_gt1000.c:395:8: error: dereferencing pointer to incomplete type

After a fresh install, my Quigg GT-1000 switches are all working with your protocol now, so I no longer need my own (perfectly working, but less user friendly) protocol for these switches.

Thanks for the good work!
Thank you for letting me know. I's always nice to know that the result of my work is appreciated. But more is coming regarding these switches. So, keep an eye on this thread.
@RinusW, can you describe the protocol the best you can on the wiki. If all (stable) protocols are done, i can check yet another step for releasing v6.

Possibly Related Threads...
Thread Author Replies Views Last Post
  QUIGG GT9000 (Globaltronics/ALDI) NeoFlo 140 81,048 01-07-2020, 04:03 PM
Last Post: aP7D1CKD
  [Solved] Quigg GT-1000 leaving transmitter ON VrahoK 11 1,071 12-22-2019, 12:17 AM
Last Post: VrahoK
  Brennenstuhl RCR CE1 1011 with QUIGG GT9000 Protocol scootermacro 1 711 06-27-2019, 06:20 PM
Last Post: scootermacro
  quigg gt7000 Dimmer wchristi 11 9,300 04-30-2015, 09:25 AM
Last Post: wo_rasp
  Quigg Screens curlymo 6 4,650 01-31-2015, 07:33 PM
Last Post: curlymo
  QUIGG (Globaltronics/ALDI) neevedr 49 38,150 01-12-2015, 10:01 AM
Last Post: wo_rasp
  Kaku PAT-103 / PAR-1000 davem 0 2,428 04-20-2014, 10:51 PM
Last Post: davem
  Alecto WS-1000 koffie 1 2,394 12-30-2013, 10:19 PM
Last Post: curlymo
  [Fully Supported] IT PA3-1000 nett_flanders 55 26,301 09-11-2013, 04:42 PM
Last Post: Bram

Forum Jump:

Browsing: 1 Guest(s)