This plugin lets Indigo name and use various devices made by Global Caché. In particular, it supports the GC-100 and iTach network hardware, and the GC-IRL and GC-IRE serial infrared receivers. This is enough to both send and receive Consumer Infrared (CIR) signals using pure Indigo plugin commands and events.

You need to have the requisite kind of hardware, of course. Note that I don't have any relay or LED-dimmer devices or cables, and thus that part of the GC-100 and iTach functionality remains unimplemented for now.

This is the most complicated of the plugins I have made so far, and is undoubtedly riddled with bugs that have cunningly evaded me so far. Do let me know how it goes for you.

Download from http://www.cynic.org/indigo/plugins. Use the "About..." menu item for a (preliminary) help page. Let me know if you have any questions.

This looks awesome. However, I'm having a few problems getting it to work.

I really like how this plugin probes the GC to discover the module capabilities. Unfortunately, the GC-100 I have is really ancient and its firmware doesn't support a couple of command the plugin makes: get_IR and get_SERIAL. Here is a modified version of gcnet.py's _calldown() method that works with my GC-100, and I believe it should still work fine with newer versions of the firmware (it still calls get_IR and get_SERIAL for newer fw versions):

Code: Select all

   def _calldown(self, ctx, data=None):
      """ Unified GCNet callback driver. """
      if ctx.state is not None:
         indigo.server.log("received state: " + str(ctx.state))
      if data is not None:
         indigo.server.log(" received data: " + str(data))

      if ctx.error:
         return self.callout(ctx)
      if ctx.state == 'error':
         if self.type is None:                  # this one was on purpose
            if data == "14":
               self.type = "GC-100"            # it's a GC-100 of some kind
               self._errors = ERRORS_GC_100
               self._irqueue = deque()            # unified IR queue (one per netdev)
            elif data == "001":
               self.type = "iTach"               # it's an iTach of some kind
               self._errors = ERRORS_ITACH
               self._irqueue = None            # per-device IR queue
               self.can_learn = True            # supports learning mode
            else:
               # neither GC-100 nor iTach. Fill in blanks here...
               self.callout(Error("Unknown GC-100-like device (returned error %s)" % data))
               return
            self.command('getversion,0')         # get board version
            self._probe_count = 0               # start counting devices in flight
            self.command('getdevices')            # start device enumeration
            self._probe_queue = []
         else:
            # unexpected error. Report it upstream
            source = int(data)
            self.callout_error(DeviceError(source, self._errors[source]))
      elif ctx.state == 'device':                  # device enumeration ("2,3 IR")
         dev, _, r = data.partition(',')
         cnt, _, type = r.partition(' ')
         if dev == "0":                        # iTach network device
            self.network = type
         for addr in range(1, int(cnt)+1):
            self._probe_count += 1               # record device probe in flight
            self._probe_queue.append((type, dev, addr)) # queue specific probe
      elif ctx.state == 'IR':                     # 2:1,function
         addr, type = data.split(',', 1)
         if type == "SENSOR" or type == "SENSOR_NOTIFY":
            self._create_dev(Sensor, addr, type)   # configured for input
         elif type == "LED_LIGHTING":
            self._create_dev(LEDLight, addr, type)   # configured for LED dimmer driving
         else:
            self._create_dev(IREmitter, addr, type)   # configured as IR emitter
      elif ctx.state == 'SERIAL':                  # 2:1,serial parameters
         addr, type = data.split(',', 1)
         self._create_dev(Serial, addr, type)
      elif ctx.state == 'devices done':            # device list complete
         major, minor = self.version.split('-', 1)
         for cmd_tuple in self._probe_queue:
            (type, dev, addr) = cmd_tuple
            if type == 'RELAY':
               self._create_dev(Relay, "%s:%s" % (dev, addr), None)
            elif float(major) <= 2.4:
               # Really old firmware versions (not sure of exact version, but
               # definitely earlier than 2.5) do not support get_SERIAL
               # or get_IR commands. For get_SERIAL we have enough information
               # to construct from the getdevices enumeration. For get_IR
               # we just presume all addresses on the module are set to IR
               # emitting and not sensor inputing -- we could make this smarter
               # by sending getstate messages (which are supported) and if we
               # get back a state reply we know it is a sensor versus an IR
               # will return an error 13.
               if type == 'SERIAL':
                  self._create_dev(Serial, "%s:%s" % (dev, addr), None)
               elif type == 'IR':
                  self._create_dev(IREmitter, "%s:%s" % (dev, addr), "IR")
# OR:
#                  self._create_dev(Sensor, "%s:%s" % (dev, addr), "SENSOR")
#
# OR:
#   Could send getstate to determine sensor versus IR, but will require
#   some additional ctx.state handling...
#
#                  time.sleep(PROBE_DELAY)            # don't overwhelm the hardware
#                  self.command("getstate,%s:%d" % (dev, addr)) # issue specific probe
            else:
               time.sleep(PROBE_DELAY)            # don't overwhelm the hardware
               self.command("get_%s,%s:%d" % cmd_tuple) # issue specific probe
         self._probe_queue = []
      elif ctx.state == 'version':
         self.version = data                     # board version
      elif ctx.state == 'start learning':            # enter learning mode
         self._learning = True
         self.callout('learning', True)
      elif ctx.state == 'stop learning':            # exit learning mode
         self._learning = False
         self.callout('learning', False)
      elif ctx.state == 'learned':               # IR signal learned
         self.callout('learned', self._iTach_learned_event(data))
      elif ctx.state == 'reply':                  # any other reply
         (cmd, addr, args) = data.split(',', 2)
         if self.devmap and addr in self.devmap:
            self.devmap[addr]._calldown(ctx, cmd, args)
         else:
            self.callout(Error("Unconsumed event", data))


(I can email you the file if you would like)

However, I am still not able to get IR commands sent out consistently. First, here is some logging showing the device activating and becoming available correctly (note I added some additional comm logging):

Code: Select all

  Starting plugin "Cynical Caché 0.9.1"
  Plugin "Cynical Caché" connected
  Plugin "Cynical Caché 0.9.1" started
  Cynical Caché                   mapping device "cyn-gc100" 22857726(gcnet)
  Cynical Caché                   cyn-gc100 starting
  Cynical Caché                   cyn-gc100 connecting to network device 192.168.1.183
  Cynical Caché                   mapping device "cyn-gc100-emitter 5:1" 1298719808(iremitter)
  Cynical Caché                   cyn-gc100-emitter 5:1 starting
  Cynical Caché                   plugin starting asyn operation
  Cynical Caché                   using no IR database
  Cynical Caché                   SENDING: mumblefrotz
  Cynical Caché                   RCVD state: error
  Cynical Caché                    RCVD data: 14
  Cynical Caché                   SENDING: getversion,0
  Cynical Caché                   SENDING: getdevices
  Cynical Caché                   RCVD state: version
  Cynical Caché                    RCVD data: 2.4-12
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 1,1 SERIAL
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 2,1 SERIAL
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 3,3 RELAY
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 4,3 IR
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 5,3 IR
  Cynical Caché                   RCVD state: devices done
  Cynical Caché                    RCVD data:
  Cynical Caché                   cyn-gc100 ready with 11 device(s)
  Cynical Caché                   cyn-gc100-emitter 5:1 host device cyn-gc100 now available
  Cynical Caché                   cyn-gc100-emitter 5:1 is now ready

I then set up an action to Send IR Signal "<NEC:74b2/2E>". When executed I think it works the first time, but subsequent requests fail. It looks like the "completeir" response is losing the 'c'? Note the device state queue count is stuck above 0.

Code: Select all

  Action Group                    cyn-gc100 IR blast
  Cynical Caché                   send <NEC:74b2/2f> to <irdev.IREmitter object at 0x2f96ef0> repeating 0
  Cynical Caché                   sending sendir,5:1,2,38000,1,1,342,170,22,21,22,63,22,21,22,21,22,63,...,22,63,23,2200
  Cynical Caché                   received state: reply
  Cynical Caché                    received data: ompleteir,5:1,2
  Action Group                    cyn-gc100 IR blast
  Cynical Caché                   send <NEC:74b2/2f> to <irdev.IREmitter object at 0x2f96ef0> repeating 0
  Action Group                    cyn-gc100 IR blast
  Cynical Caché                   send <NEC:74b2/2f> to <irdev.IREmitter object at 0x2f96ef0> repeating 0
  Action Group                    cyn-gc100 IR blast
  Cynical Caché                   send <NEC:74b2/2f> to <irdev.IREmitter object at 0x2f96ef0> repeating 0
  Action Group                    cyn-gc100 IR blast
  Cynical Caché                   send <NEC:74b2/2f> to <irdev.IREmitter object at 0x2f96ef0> repeating 0


If I telnet to my GC-100 and copy/paste the exact above sendir command, it works correctly (I see a full completeir reply):

Code: Select all

sendir,5:1,2,38000,1,1,342,170,22,21,22,63,22,21,22,21,22,63,22,...,22,63,23,2200
completeir,5:1,2

Next, note that I'm seeing it get into a bad state. This might be related to the failure above. Sometimes when I request the same action above (or the clearIR action) I get these:

Code: Select all

  Action Group                    cyn-gc100 IR blast
  Cynical Caché Error             ignoring sendIR for unready device cyn-gc100-emitter 5:1
  Action Group                    cyn-gc100 IR blast
  Cynical Caché Error             ignoring sendIR for unready device cyn-gc100-emitter 5:1
  Action Group                    cyn-gc100 IR clear
  Cynical Caché Error             ignoring clearIR for unready device cyn-gc100-emitter 5:1
  Action Group                    cyn-gc100 IR clear
  Cynical Caché Error             ignoring clearIR for unready device cyn-gc100-emitter 5:1
  Action Group                    cyn-gc100 IR clear
  Cynical Caché Error             ignoring clearIR for unready device cyn-gc100-emitter 5:1


Starting and stopping the plugin, or enable/disabling the devices doesn't help. Instead I have to go into the Send IR action and edit the IR string. Strange.

I really like how this plugin probes the GC to discover the module capabilities. Unfortunately, the GC-100 I have is really ancient and its firmware doesn't support a couple of command the plugin makes[...]

The only devices I've got to test with are the ones I bought in the last year, so I'll have a hard time dealing with old firmware behaviors. Thanks for contributing.

(I can email you the file if you would like)

Please do; it's a lot less error-prone.

However, I am still not able to get IR commands sent out consistently. First, here is some logging showing the device activating and becoming available correctly (note I added some additional comm logging):

Here is a trick: Open the plugin preferences, and in the Debug modules: field enter "ir". That will enable the

Code: Select all

if DEBUG: DEBUG(whatever)

sections in the ir module, which includes logging all incoming and outgoing GC traffic, as well as some IR queue logging. (This works with any module that has a DEBUG global variable initialized to None; particularly asyn.)

Sure looks like something is eating the "c" in "completeir". I've noticed that the GC equipment needs the occasional strategic delay to function. When you're getting the "ignoring...for unready" message, what is the state of the emitter device? (The message means that the device has faulted.) When you disable and re-enable the device, what state do you end up in?

I don't currently have any timeout/recovery processing in that plugin, because my GC boxes have been rock-solid. Let me see what I can cook up for the next version.

Cheers
-- perry

I may have found the place that eats your "c". In your hacked-up version of my plugin, replace the input_scan array with this version:

Code: Select all

   input_scan = asyn.scan.Regex([
      (r'unknowncommand (\d+)\r', "error"),
      (r'ERR_\d+:\d+,(\d+)\r', "error"),
      (r'device,(.*?)\r', "device"),
      (r'endlistdevices()\r', "devices done"),
      (r'version,\d+,(.*?)\r', "version"),
      (r'IR,(.*?)\r', "IR"),
      (r'SERIAL,(.*?)\r', "SERIAL"),
      (r'IR Learner Enabled()\r', "start learning"),
      (r'IR Learner Disabled()\r', "stop learning"),
      (r'sendir,(.*?)\r', "learned"), # actually ends in \r\n...
      (r'\n', None),               # ... so eat that
      (r'(.*?)\r', "reply"),         # anything else
   ])


Then see if you get complete "completeir" responses.

I'm trying to get some answers out of Global Caché about their firmware versions, and am a bit leery trying to support a wide range of versions. You do know that you can just send your old box in and they'll upgrade the firmware for free, right?

Cheers
-- perry

Perry The Cynic wrote:

(I can email you the file if you would like)

Please do; it's a lot less error-prone.

Sounds good -- I'll email it to you in a few minutes.

Here is a trick: Open the plugin preferences, and in the Debug modules: field enter "ir".

When I do that for "ir" it finds the module but no debug hook:

Code: Select all

  Cynical Caché Error             module ir has no internal debug hook


Perry The Cynic wrote:I may have found the place that eats your "c". In your hacked-up version of my plugin...

Bingo. That was it. It now works correctly:

Code: Select all

  Action Group                    cyn-gc100 IR blast
  Cynical Caché                   send <NEC:74b2/2e> to <irdev.IREmitter object at 0x2f96e90> repeating 0
  Cynical Caché                   SENDING: sendir,5:2,2,38000,1,1,342,170,22,21,22,63,22,21,22,21,22,63...,63,23,2200
  Cynical Caché                   RCVD state: reply
  Cynical Caché                    RCVD data: completeir,5:2,2
  Action Group                    cyn-gc100 IR blast
  Cynical Caché                   send <NEC:74b2/2e> to <irdev.IREmitter object at 0x2f96e90> repeating 0
  Cynical Caché                   SENDING: sendir,5:2,2,38000,1,1,342,170,22,21,22,63,22,21,22,21,22,63...,63,23,2200
  Cynical Caché                   RCVD state: reply
  Cynical Caché                    RCVD data: completeir,5:2,3


However, I'm still seeing the other issue where it gets into a bad state and fails:

Code: Select all

  Action Group                    cyn-gc100 IR blast
  Cynical Caché Error             ignoring sendIR for unready device cyn-gc100-emitter 5:1
  Action Group                    cyn-gc100 IR blast
  Cynical Caché Error             ignoring sendIR for unready device cyn-gc100-emitter 5:1
  Action Group                    cyn-gc100 IR blast
  Cynical Caché Error             ignoring sendIR for unready device cyn-gc100-emitter 5:1


Steps that work on this end for reproducing the problem:
(update: I can also reproduce the problem just by stopping and restarting the server)

1) Disable Indigo Communication (right-click on) the main GC Network Device. The device and its children devices correctly all transition to the unavailable state.

2) Re-Enable Communication on the main GC Network Device. The device and its children device correctly all transition back to the ready state:

Code: Select all

  Cynical Caché                   cyn-gc100 starting
  Cynical Caché                   cyn-gc100-emitter 5:1 reset
  Cynical Caché                   cyn-gc100 connecting to network device 192.168.1.183
  Cynical Caché                   SENDING: mumblefrotz
  Cynical Caché                   RCVD state: error
  Cynical Caché                    RCVD data: 14
  Cynical Caché                   SENDING: getversion,0
  Cynical Caché                   SENDING: getdevices
  Cynical Caché                   RCVD state: version
  Cynical Caché                    RCVD data: 2.4-12
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 1,1 SERIAL
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 2,1 SERIAL
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 3,3 RELAY
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 4,3 IR
  Cynical Caché                   RCVD state: device
  Cynical Caché                    RCVD data: 5,3 IR
  Cynical Caché                   RCVD state: devices done
  Cynical Caché                    RCVD data:
  Cynical Caché                   cyn-gc100 ready with 11 device(s)
  Cynical Caché                   cyn-gc100-emitter 5:1 host device cyn-gc100 now available
  Cynical Caché                   cyn-gc100-emitter 5:1 is now ready


At this point everything looks good, but when I then try to send the IR signal I get the "ignoring sendIR for unready device cyn-gc100-emitter 5:1" error. The strange part is that if I open the Action (not the device), press Edit Action Settings..., then Save back out of both dialogs everything is healed and it works correctly.

Perry The Cynic wrote:I'm trying to get some answers out of Global Caché about their firmware versions, and am a bit leery trying to support a wide range of versions. You do know that you can just send your old box in and they'll upgrade the firmware for free, right?

Yeah, I've been meaning to ship it off to them. I wouldn't worry about it too much, but I would appreciate it if you could include the changes I'm emailing since that seems to get it working pretty well at least for basic IR blasting. I have an old GC-100 spec I'll email you that shows the capabilities of the version I have. I didn't look at the IR receiving / learning side, but for basic operation and IR emitting the only thing missing were the get_IR and get_SERIAL calls that I modified to be skipped for older firmware versions.

Another topic: are you ready to share your plans for the experimental IR database functionality? I'm definitely interested to hear about it.

When I do that for "ir" it finds the module but no debug hook:

Sorry about that. I was looking at an internal debug build when I said that. The released ir module doesn't have the debug hook.

Bingo. That was it. It now works correctly:

Glad to hear that. It'll be fixed in 0.9.3.

However, I'm still seeing the other issue where it gets into a bad state and fails: [...]

I might know what's biting you. If I'm right, it's actually fixed in 0.9.2 (but that doesn't have the pre-3.0 GC-100 fix in it). If you feel like assembling a Franken-plugin, copy cyin/attr.py over from 0.9.2, or just retrofit your callback changes to 0.9.2.

Yeah, I've been meaning to ship it off to them. I wouldn't worry about it too much, but I would appreciate it if you could include the changes I'm emailing since that seems to get it working pretty well at least for basic IR blasting.

I'll see what I can do. I have to be careful; the same code paths need to work for iTachs of various kinds, and they're just similar enough to be dangerous.

Cheers
-- perry

Perry The Cynic wrote:If you feel like assembling a Franken-plugin, copy cyin/attr.py over from 0.9.2, or just retrofit your callback changes to 0.9.2.

Yep, that seems to fix the problem. It is working great now.

I have to be careful; the same code paths need to work for iTachs of various kinds, and they're just similar enough to be dangerous.

I just emailed you a correction that checks for iTach versus GC-100s.

Now available: version 1.0.0b1. The "Send IR Signal" action has a "Learn" button, and all "Learn" buttons time out harmlessly (in 9.5 seconds) if you don't manage to get off a recognizable signal in time. (This limitation is imposed by Indigo itself.) GC-100s with firmware versions before 3.0 now can be used, albeit with reduced functionality - you are still encouraged to send yours in to Global Caché to have them upgraded (for free).

This is a release candidate.

Cheers
-- perry

Has anyone got this working with the IP2IR device?

Bob

Has anyone got this working with the IP2IR device?

It seems to work with the WF2IR (the WiFi version) that I have. What exactly is not working for you?

Cheers
-- perry

I'm trying to use the new Learn button inside the Action UI but I get the "no learning device configured" error. This is with an iTach and its tiny pinhole IR receiver on the back, so I have not defined an Indigo learning device but was hoping it might still work.

I'm trying to use the new Learn button inside the Action UI but I get the "no learning device configured" error. This is with an iTach and its tiny pinhole IR receiver on the back, so I have not defined an Indigo learning device but was hoping it might still work.

You need to go into the plugin preferences and set the device to use for learning. It's not terribly intuitive, but it ought to work. (Whether the learning itself actually works is a different question; the iTach sensor is fiddly at best. But the "no learning device configured" error means you didn't set one.)

Cheers
-- perry

Ah, yes. I do remember seeing that now in the plugin config dialog. I hadn't defined my device yet, so it wasn't selectable then I forgot about it.

I'm still not able to get learning to work. I'm now getting this error instead (only after the IR command is sent to the sensor):

Code: Select all

Cynical Caché Error             living iTach learning aborted: TypeError('int argument required',)

FYI, this is an older iTach that I recently upgraded to the latest firmware (710-1001-05).

A couple of other thoughts:

1) As you mentioned earlier, we need a better way for the UI to enter learning mode and not timeout so quickly.

2) Can you add a Test or Send button next to the Learn button that sends whatever code is currently in the UI?

Perry The Cynic wrote:
It seems to work with the WF2IR (the WiFi version) that I have. What exactly is not working for you?

Cheers
-- perry

Thanks for your reply.

We haven't yet purchased the IP2IR.

We will be getting a TRT_Sandmartin DVB-3033 satellite receiver, and wish to control it remotely across the Internet. One of the software apps that was recommended to me by GC, is Indigo 5. I'd prefer to have an OS X app to set it up. Perceptive Automation wrote to me: "There are two 3rd party plugins for Indigo 5 that control the GC devices (here and here) - I'd just confirm with those developers by posting questions on those forums that their plugins work with that specific iTach."

One of them, the "the Global Cache Plugin": viewtopic.php?f=24&t=7403 says it will have future support for IP2IR. I posted to that forum thread about an ETA; no word back.

Other notes I have:

Global Cache has an iHelp Setup Utility. I've downloaded an OS X version of this app.

I have very limited access to the room the receiver will be placed in. It will be in a different subnet than the one we control it from. Initially, however, I can set it up in my office, then move it to it's production location.

I want to find out if Indigo 5 will work with the IP2IR. Otherwise, I may have to buy a Windows app. Thanks.

Bob