Any thoughts on device dependencies?

I'm starting in on a plugin for my A/V processor. It has separate serial command sets for main, zone2, and zone3, which can all operate independently of each other including power on/off. Given this system architecture, I was thinking it would make sense to have separate Indigo devices for each zone.

That said, there are a bunch of system setup commands like input naming that apply to all the zones. I could glop them into the Main device, in which case users would be expected to set up a Main for general use and then have the ability to create devices for zone2 and/or zone3 if they use those features too.

But then if the user deletes the Main device, things would get kind of weird.

One possible solution would be for Indigo to know that the zone2 and zone3 devices were dependencies of the Main device, so deleting the Main would delete the zones too along with actions utilizing the main device, etc.

Does this sound anything like a reasonable plugin architecture, or should I be making a single massive device encompassing all the functions of the processor?

If you have just one physical device put the common parameters into config
Then each subsystem is a new device


Sent from my iPhone using Tapatalk

Does this sound anything like a reasonable plugin architecture, or should I be making a single massive device encompassing all the functions of the processor?

That's an interesting question. I'm not sure what I'd land on, but one thing I think I'd try is to set it up with one device with sub-devices for each channel. Take a look at the Device Factory example in the Indigo Plugin SDK. IIRC, if a user attempts to delete any related device in Indigo, they will be warned that all related devices will also be deleted (keeping things neat).

If you have just one physical device put the common parameters into config

That thought occurred to me too. The drawback is an Indigo instance could only talk to one processor. Probably not a big deal, but I'd prefer to avoid it if I can -- this is plan B.

That's an interesting question. I'm not sure what I'd land on.

I was half-hoping somebody would tell me "no that's crazy, don't do that"

Thanks for the pointer on the device factory. I'll play with that and see how it feels for my application.

To Matt and Jay: A protected device class would be cool.
I had the same issue and decided to move the common parts to config / menus


Sent from my iPhone using Tapatalk

... Thanks for the pointer on the device factory. I'll play with that and see how it feels for my application.

This thread may be help (or may not ): Creating device groups without using DeviceFactory UI

Related post: Indigo 7 v7.0.0 Released - section on Group management additions

[jay (support)]

To Matt and Jay: A protected device class would be cool.

Please elaborate.

in some of my plugins there is a hierarchy of common data.

level one: common for all==> config
level two: each device type has 50% of props in common, would be good to set them once only
level three: details for each device

Current solution have sections in config
- common
- one for each device type (level2) ..
this can get lengthy.


would be cool:
create a device, set level 2 props, the next device inherits those props. If any of these props gets changed all devices of this type inherit those props.

One could do this in the plugin ... to copy those level 2 props across all devices of that type.. but really difficult for beginners.

Karl

Is it a bug or a feature that I can't put a "serialport" field in the configUI of a deviceFactory?

Error (client) runConfigDialog() caught exception: PAXDialogControllerError -- Fields must contain a valid 'type' attribute: textfield, menu, checkbox, list, separator, label, button.

[matt (support)]

level one: common for all==> config
level two: each device type has 50% of props in common, would be good to set them once only
level three: details for each device

Got it, and I agree there is often a lot of common base behaviors / properties / UI shared across a lot of devices. I experience that with Z-Wave devices frequently, and end up with a lot of duplicated UI and functionality.

[matt (support)]

Is it a bug or a feature that I can't put a "serialport" field in the configUI of a deviceFactory?

Error (client) runConfigDialog() caught exception: PAXDialogControllerError -- Fields must contain a valid 'type' attribute: textfield, menu, checkbox, list, separator, label, button.

Bug. I'm looking into fixing it for a future build.

[matt (support)]

Is it a bug or a feature that I can't put a "serialport" field in the configUI of a deviceFactory?

Error (client) runConfigDialog() caught exception: PAXDialogControllerError -- Fields must contain a valid 'type' attribute: textfield, menu, checkbox, list, separator, label, button.

Bug. I'm looking into fixing it for a future build.

In the mean time, as a workaround you can use the following XML Field elements in your ConfigUI instead:

Code: Select all

   <Field type="textfield" id="_FIELDID_uiAddress" hidden="true">
      <!-- hidden field used to hold UI value of device's UI address column -->
   </Field>
   <Field type="label" id="_FIELDID_serialPortLabel">
      <Label>Select the local serial port or remote serial server:</Label>
   </Field>
   <Field type="menu" id="_FIELDID_serialConnType" defaultValue="local">
      <Label>Connection Type:</Label>
      <List>
         <Option value="local">Local (physical)</Option>
         <Option value="netSocket">Network Socket</Option>
         <Option value="netRfc2217">Network RFC-2217</Option>
      </List>
   </Field>
   <Field type="menu" id="_FIELDID_serialPortLocal" visibleBindingId="_FIELDID_serialConnType" visibleBindingValue="local">
      <Label>Serial Port:</Label>
      <List class="indigo.serialPorts" filter="indigo.ignoreBluetooth" />
   </Field>
   <Field type="textfield" id="_FIELDID_serialPortNetSocket" visibleBindingId="_FIELDID_serialConnType" visibleBindingValue="netSocket" defaultValue="socket://">
      <Label>Socket Address:</Label>
   </Field>
   <Field type="textfield" id="_FIELDID_serialPortNetRfc2217" visibleBindingId="_FIELDID_serialConnType" visibleBindingValue="netRfc2217" defaultValue="rfc2217://">
      <Label>RFC-2217 Address:</Label>
   </Field>

Replace all instances of "FIELDID" above with the ID you were using for the serialport Field originally.

Thanks, I got the workaround working -- but it's not really so simple as supporting serialPorts in deviceFactory.

What I wound up doing is copying all the serial port fields into my "master" device in closedDeviceFactoryUi() and copying them back to the FactoryUIValues in getDeviceFactoryUiValues(). Additionally, I'm copying the uiAddress into all the sub-devices so they display useful information in the "address" column.

So far I'm happy with how this UI is shaping up. Right now I'm working on getting the input config into the Factory window too, since that applies to all the devices. My backup plan is to ask the user to specify a processor model, but what I'd really like to do is query the processor firmware version with the "continue" button and populate all the device characteristics automatically.

This may be OT, but I thought I'd come back and post a simple plugin example on one way to programmatically create grouped devices. The device factory SDK example shows how to create grouped devices through user input and my goal was to show how it can be done when you don't want the user to create the devices themselves.

This is an incredibly basic example that does little more than creation (for example, no error trapping). Hope it's helpful.

Grouped Device Plugin Example

[jay (support)]

So far I'm happy with how this UI is shaping up. Right now I'm working on getting the input config into the Factory window too, since that applies to all the devices. My backup plan is to ask the user to specify a processor model, but what I'd really like to do is query the processor firmware version with the "continue" button and populate all the device characteristics automatically.

Sounds reasonable. One thought would be to hide the config fields until the user hits the Continue button (I think I'd use a slightly different name, maybe Query, Confirm, or even Test Connection) and only show the config fields once you query the device and figure out what kind it is and what options to show. You should also catch in the validation method that the button was never clicked and show an appropriate error (unless you want have a reasonable set of defaults).

Another thought: if there's some way to dynamically detect what sub-devices are available, I'd recommend using a Menu field type rather than separate fields. This might keep you from having to release a new plugin if a new device is released with a different set of sub-devices than you anticipated (something I would like to do in the Yamaha plugin for input selection if it is/were possible for instance).