Difference between revisions of "GlobalCache GC-100"

Latest revision as of 23:25, 24 January 2012

GC 100

GC100 is a network-capable device which allows you to add remote control (and other input device) connectivity. The Device had an update (from firmware version 3.0) that makes it work with DHCP and will be added in the subnet of LinuxMCE automatically. So the newer/updated versions are plug and play, the earlier versions need to be added manual as described in this page.

It includes:

• serial ports
• Infrared sensors (inputs) and outputs
• one or more relays

The remote control data is then able to be sent over an Ethernet (TCP/IP) network through the Ethernet port, without the requirement of a connection to a specific PC.

For more details about the product check the Global Cache manufacturer web site.

Demo videos:

• http://www.youtube.com/watch?v=qig0pESNzyY
• http://www.youtube.com/watch?v=DsSHxn0YS2Y
• http://www.youtube.com/watch?v=58bQd0szCj8

Send IR codes

LinuxMCE implementation of GC100 assumes that in device tree we'll have children and the messages are actually addressed to them instead of GC100 itself.

So when you are sending "ON" to TV controlled by GC100, the message is routed to the GC100, it finds infrared code for "ON" for that specific TV, sends a command to gc100 to send a specific infrared sequence, which will blink IR sender connected to specific port, and the TV will turn on.

The only two commands that GC100 implements itself are : CMD_Send_Code used to test which IR is suitable for your equipment and CMD_Learn_IR used to learn new IR codes.

Learn IR codes

The learning device is actually unrelated to GC100. It may be plugged into one of GC100's serial ports (don't forget to set them to 9600 bps), or in regular serial port, just be sure you specified right port in GC100 device data.

There are several other devices that support learning of infrared codes : IRTrans, Tira, USB_UIRT.

Learning is done from web page. When clicking "Learn" gc100 will start a thread that will try to get data from the port. If nothing is received in 30 seconds the thread will die. The page will continue to refresh trying to see if anything was added, but after 30 seconds it's useless.

Sensors

The gc100 jacks are by default configured as IR transmitters, but they can be configured to function as sensors. The sensors are, in their most basic form, two wires connected to a jack plug. When you cross them, a "sensor tripped" event is emitted. I am not currently aware of how this is supposed to function, who will intercept the event and how will it react to it. One idea for using a sensor is attaching a doorbell button to it, which, when pressed, will notify you in some way.

You must go into the gc100's web panel and set the input jack to 'sensor w/ auto notify' to use an i/r jack for a sensor.

How to

Install old version

The old version device is not quite plug&play. You have to perform a factory reset and to add it from orbiter ("Add GC100" button). LMCE will temporarily change its internal network and look for the gc100 at its factory default of 192.168.1.70, change the configuration of the GC100, and the core then goes back to its regular network settings. Note that this will almost certainly fail if your exernal IP on the core is in the 192.168.1 network! The script will then install needed software and after that it should say that device is ready to use (don't forget to quickreload).

Complete Manual Install old version

NOTE: Perform those steps if automation installation is not working! In 2.0.0.44 Gc-100 can be installed from the Orbiter by pressing the button 'Add GC100' but the device should have factory IP!

Factory reset the GC100. Connect it with a crossover cable to your pc. Change the ip address of your pc to the same network. Expl.: 192.168.1.101. Take a webbrowser and go to http://192.168.1.70.

Make two changes:

1. Serial: Change it to 4800/8/1/N (If you would like to connect a CM11 to it), 2. Network: Change it to your Network, outside of the pluto DHCP range.

Take a note of the MAC address of your GC100

In the pluto admin:

1. Add a new device. Choose the GC100 template 2. Edit the new device 3. Enter your IP Adress 4. Enter the MAC Address of your GC100. Example: 00:0c:11:22:33:44

Now reload everything.

Before the first use

• Insert proper wires in relays, devices in serial ports, IR LEDs and/or sensors.
• Go to device's webpage and set proper inputs/outputs, baud rates and so on.
• Add child devices in LinuxMCE-admin webpage and set proper device data to match the wiring.

This should do it.

Known Problems

MAC detection

--Nite man 06:03, 25 January 2008 (PST) To solve the MAC detection problem replace the function get_gc100mac() in the script /usr/pluto/bin/gc100-conf.pl by new one below:

sub get_gc100mac {
   my($mac, $page, $ret);

   `curl http://192.168.1.70/Commands.cgi -o gc100mac1 --silent`;
   `curl http://192.168.1.101/Commands.cgi -o gc100mac2 --silent`;

   open FILE, "gc100mac1";
   $ret = read FILE, $page, -s "gc100mac1";
   close FILE;

   unless($page) {
       open FILE, "gc100mac2";
       $ret = read FILE, $page, -s "gc100mac2";
       close FILE;
   }

   ($mac) = $page =~ /((?:[\dA-F]{2}-){5}[\dA-F]{2})/i;

   if($mac) {
       $mac =~ tr/\-/\:/;
       loggc("Mac Found $mac\n");
       system "rm -f gc100mac1 gc100mac2";
       return $mac;
   } else { exit 1 }

}

or apply that [gc100-conf.pl.patch]

Currently the support for the gc100 in LinuxMCE is broken, at least for some models or firmware versions. The /usr/pluto/bin/gc100-conf.pl script is for some reason unable to determine the gc100's MAC Adress after it has been reset to factory defaults. As a result it is only half configured and not added to the system properly.

The only known workaround [1] [2] at this time is to manually edit the perl script, and hardcode the MAC address of your gc100. In short, find this line in the script:

sub get_gc100mac {

Then insert this line immediately following it (replace 00:00:00:00:00:00 with the adress of your gc100):

return "00:00:00:00:00:00";

As a result it should look something like this now:

        exit(4);
  }
} 
    
sub get_gc100mac {
  
  return "00:00:00:00:00:00";
  
  `curl http://192.168.1.70/Commands.cgi -o gc100mac1 --silent`;
  `curl http://192.168.1.101/Commands.cgi -o gc100mac2 --silent`;
  open(FILE,"gc100mac1");
  @data1 = <FILE>;
  close(FILE);

Reset the gc100 to factory defaults if necessary and you should be able to add it from an orbiter as described above.

Another possible workaround might be described on the Plutohome wiki for the gc100, under Complete Manual Install.

Firmware versions known to be affected:

• 2.4-06 (GC100-06)

Serial Port

Previous problems in the gc100-serial-bridge.sh script were fixed in 0710 beta4.

The GC100 serial port needs to be setup for 4800 bauds.

In some cases the gc100 may respond with "configuration is locked". If that happens, you need to re-configure the gc100 manually from factory defaults. In the /usr/pluto/bin/gc100-conf.pl, modify the wget call in the "sub configure_webgc" function to add parameter "Y=0" which means "do not lock config":

sub configure_webgc {
   $local_ip = shift;
   system("wget -q -T 3 --read-timeout=4 -t 1 \"http://192.168.1.70/commands.cgi?2=$local_ip&3=255.255.255.0&4=$gw&Y=0&7=submit\"");
   system("wget -q -T 3 --read-timeout=4 -t 1 \"http://192.168.1.101/commands.cgi?2=$local_ip&3=255.255.255.0&4=$gw&Y=0&7=submit\"");

} or if you do it all manually from the command line:

wget -q -T 3 --read-timeout=4 -t 1 "http://192.168.1.70/commands.cgi?2=192.168.80.23&3=255.255.255.0&4=192.168.80.1&Y=0&7=submit"

and adapt to the desired IP address.

You can now edit the port speed with the browser. If your browser hangs when you submit, you can use this the following wget call instead:

wget -q -T 3 --read-timeout=4 -t 1 "http://192.168.80.23/serial.cgi?C=1&B=5&F=0&A=submit"

Implementation details

In gc100.cpp there is a lot of code for format conversion and other stuff. Practically it's not a big deal it receives a command, find a proper IR sequence and sends it to gc100.

Operating the relays, IR transmitters, and sensors

The gc100 software architecture uses two threads to communicate with the gc100 regarding relays, IR transmitters and sensors, one for sending messages (SocketThread) and one for receiving (EventThread). The reason for this is that the gc100 protocol isn't completely a request-reply protocol, even if it seems like that at first. The gc100 can initiate a transmission when a sensor is tripped, enough to break the request-reply paradigm. The program was designed to treat the communication as asynchronous. Messages are sent to the device without expecting a reply, and the replies are treated as independent events and state change reports, without linking a request to a reply in the program logic (except for the initialization phase).