Hi, Berkinet! Sorry to drag you over here.
berkinet wrote:On the other hand, I would think a plugin like the Cynical Behaviors plugin could look to see if a given device supported some usable state to use for it's own purposes. In the case of the ad2usb Zone device, onOffState is supported and should provide the necessary state change to use as an input trigger. In this case, a plugin writer would need only assure that their devices supported onOffState.
I'm a big fan of using the standard device types whenever it's at all reasonable, because it allows
composition of devices. For example, in my
Cynical Lutron plugin, window blinds are technically
dimmer devices; not because they've anything to do with light, but because that lets any user add them to virtual Device Groups and have them work. That's not to say that you shouldn't add all kinds of
additional functionality to your devices -
Cyncical Lutron blinds have their own custom move actions and states, but they
also respond to standard dimmer controls and report standard dimmer state to integrate better with Indigo.
Consider yourself proselytized to this point of view. I think that in the long run, making standard-supporting devices that can be cleanly composed makes all our plugins work better together.
Now I
could change my filter to accept any device with an
onOffState state, hook state change notifications, and hope for the best. It'll probably work fine with the ad2usb device. The downside is that it'll
also show light switches and dimmers that really aren't meant to be sensors because they also have onOffStates, and so my users will have to scroll through this thicket of devices, most of which
obviously (to them) don't make sense in a sensor slot. The sad truth is that
onOffState is grossly overloaded and can mean, depending on circumstances, either
sensor state or
last commanded output state, with no way to tell without looking at the device type (and "custom" doesn't help here).
I'd love for Indigo to have an extensible protocol support facility. For example, an I/O-Linc could say "I'm a relay and a sensor." But in the concrete case of an alarm sensor, how is this not a sensor? Shouldn't it
look and feel like one? I'm not just preaching here; the alarm sensors in
Cynical Honey are, in fact, sensor devices for exactly this reason. (That's also why this was never a problem for me, though half of my zone sensors are, in fact, alarm system sensors.)
Making the coding change in the Cynical Behaviors plugin (if it can be done) would also make a lot of sense since it would be much less work to change one plugin than several.
In the short run, this may be true. But you're basically saying "any plugin should just accept all my devices and try to make the combination work." I'm pretty sure that doesn't scale without explicit support from Indigo to do the match-making. And the only match-making facility I see today is the device type and the associated behavior (command/device) promises...
Anything shiny and new coming in that area in Indigo 7? Unofficially speaking, of course?
Cheers
-- perry