Best Practices for a multiple gateway/multiple device plugin

What about multiple-gateway scenarios? Concretely, I'm looking at a plugin to drive Global Caché boxes. You can have any number of them, and each of them may have multiple devices (serial, IR emitter, sensor, ...) attached to them. So I need a configuration nexus for each box, for each device on each box, and potentially for whatever is plugged into those serial ports.

Essentially, your current design calls for plugins to be singletons, so I can't use (just) the plugin settings to configure all the GC boxes. (At least not with the UI as it exists today - I need trees.) Are you okay with creating Indigo "devices" that aren't really devices but rather interfaces, and exist as "devices" only so I an attach configuration data to them? Or how else do you suggest I do this?

Do you have any suggestion on how to model topology (connections between devices)? Specifically, there will be a device type for Audio/Video Receivers (AVRs). How do you suggest I express "this AVR device is plugged into that serial port of this GC box"? (Much of this cannot be auto-discovered; the user or installer has to set it.)

Cheers
-- perry

[jay (support)]

I would think that each GC box would be it's own device (with it's own configuration of connection properties, inputs, outputs, etc). We kept the GC boxes in mind while designing the API since IR/AV control is a big request from users. It's on our list to develop a plugin to one of these vendor's devices (probably either GC or IRTrans) but we won't be doing it before Indigo 5 GM and it would probably take a couple of months after that if we decided it was the next highest thing on the list (which I'm not sure it is). So having someone else build a GC plugin would be great!

I'll discuss more in your other thread what I think I would do in terms of configuration.

The one problem there is with those boxes (and boxes like them) is the serial port. In v1 of the API, we don't have a way for developers to create plugin-defined serial ports. So, the serial port on the GC box can't be populated (by Indigo) into the list of available serial ports for other plugins to use. We will look at this in a future version of the API. I'm not sure if any of those vendors provide virtual comm port redirectors for Mac OS X or if they support whatever that standard is (I forget it's designation) but if so then it should be possible to set up the box in the OS (outside of Indigo) as just another serial port that can be used by any plugin for any purpose (just like any other serial port).

I would think that each GC box would be it's own device (with it's own configuration of connection properties, inputs, outputs, etc). We kept the GC boxes in mind while designing the API since IR/AV control is a big request from users. It's on our list to develop a plugin to one of these vendor's devices (probably either GC or IRTrans) but we won't be doing it before Indigo 5 GM and it would probably take a couple of months after that if we decided it was the next highest thing on the list (which I'm not sure it is). So having someone else build a GC plugin would be great!

Okay, I'll give it a shot. This is a "spare time" project for me, so I'm not promising anything yet.

I have working Python code to find, scan, and drive GC-100s and their serial ports and IR emitters, including learning codes through GC-IRL and GC-IRE sensors, and a simple IR code library and database. Also some prototype cherrypy code to make buttons that send IR codes. I made all that a few months ago to teach myself Python. It's not integrated with Indigo, of course. That's the new part.

Now that we have the ability to create a GC plugin, have we reattacked with Global Cache themselves to help with development on a plugin? Seems to me that they make the best IR hardware around and have the potential to extend their market to include all the Indigo customers with just a little work on integration. Matt/Jay, any contacts with these guys?

[jay (support)]

We're focused on getting Indigo 5.0 out. Once that's done, then we'll take some time to gauge the plugin landscape (see who's working on what) and then start approaching some of the hardware vendors.