Auto discovery is great, and even better if the discovery provides detailed information like some device type id - then when a user created a device you could discover it's traits and adjust the UI accordingly - # of ir ports, mapping what each does, etc.
Seems like there are a couple of approaches here (in terms of device discovery and definition by your plugin):
- Create a single device type that covers all GC devices. Then, when the user creates a new device, you would show a pop up with all the available devices on the network. The user selects the right one, and all the fields in the config UI adjust accordingly. The advantage is that the user doesn't need to select anything upfront. The downside is that the config UI could get really complex for you to manage - there'd be a LOT of visible and enabled bindings depending on the type of device selected by the user to cover all possible device options.
- Create a device type per GC device. The user would create a new device of a particular type and the config dialog would show only the devices of that type that are available on the network (you'd filter based on type). The advantage is that each device would have it's own device config UI which would make your life easier in terms of building it. The disadvantage is that not only would the user need to select the right type, but also if GC comes out with a new device you'd need to rev the plugin.
I think I'd lean towards the second option UNLESS the discovery protocol allowed you to get ALL details about a particular device: the # and types of ports, what each one can do (i.e. only some ports can support blasters, some others may be either ir emitters or sensor inputs, etc). If you could get all that information from the discovery protocol, then I would probably go with option #1 and just bite the bullet and build the complex config ui.
As for what to do when a device becomes unavailable (network issues, etc), what I do in iTunes is have the playState updated to "unavailable" when iTunes goes away. The plugin continues to retry the connection to iTunes in that case until it comes back. When it does come back the playState and other states get updated and the device chugs merrily along. I suspect something similar would be useful for you - although there may be situations where you might want to just disable the device (in the iTunes plugin I have a fall through case that will disable the device - it's pretty much reserved for programming errors but it could be used in other exceptional cases as well).
Mostly, though, I'd stick with some state that represents the overall health of the device. Then the user could optionally trigger off that state to perform some actions when things go wrong. For device states, you can specify one state which will show up in the "State" column of the device table - that's probably the best one to put there so it's fairly simple to see what a device's state is.
In a future version of the API (after v1 is released with Indigo 5) we may add some kind of standard error/fault state that would trigger visual changes in the UI and fire triggers.
State changes don't need to be queued since your plugin controls when to update states - the server will always accept state changes for plugin-owned devices. I think the general idea is that when your plugin gets notified that a device has been enabled (after creation, at plugin startup, etc), then it should proceed to update the states on the server based on reality.
I don't believe a plugin should EVER automatically create or delete anything - that's inevitably going to lead to lots of confusion.
). What's Best Practice for dealing with this? I assume device objects shouldn't just be removed, but they'll be inoperable while the connection (and/or its device) is down. Are there ways to communicate this to Indigo? How should we show this in the device UI? Any suggestions on how to represent "the device through which we talk to this device is gone"? (See "topology" on another thread.) Is there any support for queueing up state changes, or for automatic resynchronization once the device "returns"? Should we bother?