I'm sure many of us are writing plugins for AV devices. I know I'll be shortly writing one for the Denon AVR-3312CI I just bought (Hail, Amazon! ). While the command languages are annoyingly distinct, there's a lot of common features to AV receivers - they have volume controls and can be muted; they all let you switch between inputs; they can be powered on and off; etc.

Do you have any suggestions on how to come up with regular UI and action sets, so that a script can tell a receiver to mute without having to know exactly which type of receiver it is? You're offering this, sort of, for a few Insteon-like device types (switches, thermostats), but how about things that are outside the Insteon space? How about something that doesn't require you to do work for each new type of shared device functionality?

Any plans? Any suggestions in the meantime? Should us plugin writers get together to form Secret Cabals that agree to common action sets and UIs?

Cheers
-- perry

Good question.

There isn't a good way to do this currently, but let's start by defining a minimal set of states and actions that will likely be useful across AV devices. We can this use this as a basis for when we do add an AV native device to Indigo from which plugins can subclass (like thermos, sprinklers, dimmers, etc.) . I'm not sure when that will happen, but it will be more likely to happen sooner if we have it spec'd out first.

Common AV device states:

Code: Select all

onState (also used by dimmer/relay devices)
volumeLevel (integer)
currentInputVal (integer)
currentInputName (string, may not be used)
currentChannelVal (integer)
currentChannelName (string, may not be used)
playState (bool or maybe enum: stop/play/pause/record/FF/RW?)
pipState (bool)
displayBrightness (integer)
displayText (string)

And of course we would need the actions to modify all those states (turn on, turn off, toggle, vol +, vol -, set volume (absolute), ch +, ch -, set channel, change input, play/pause/stop/ff/rw, turn on PIP, turn off PIP, toggle PIP, set display brightness).

Other useful actions might include: jump forward (30 seconds), jump backward (30 seconds), revert to previous channel.

Other thoughts? I don't want to include too much that is likely to be device specific (and thus provided in the plugin), but I'm sure there are other common states/actions I didn't list above.

The iTunes plugin has some of those actions (increase and decrease volume) as well as some actions and states that are applicable to any player type device. It is my intention to eventually define a media player type of device with standard properties and controls for exactly the same reason. Getting more people involved with defining the standard features is a good idea.

I'm not positive one size fits all when it comes to AV devices BTW - it may be better to have players, amplifiers, etc., perhaps with a common base class...

Seems like there are some groupings of functionality:

Volume (up, down, mute)
Player (play state, track, album, episode, etc.)
Channel (tv channel, radio station, applications (like on the Apple TV for instance))
Source (inputs, etc)
Projection (display brightness, pipState, etc.)

Devices may have some combination of these of course - and I'm definitely NOT recommending multiple inheritance. But perhaps we can come up with a hierarchy that would cover 80-90% of the devices out there and anything else may just have states/actions that aren't used.

Off the top of my head...

Perhaps the addition of a "displayString" state to the states already proposed by Matt? Many devices (especially receivers) output the content of their front panel display to whole-home audio integration systems in some format or other.

Yep -- added to my list of states above (as displayText).

Volume (up, down, mute)

Different devices use different numbers for volume. The closest to an industry convention is that maximum rated output is zero (dB), with negative values indicating more quiet. Though some devices then have "overdrive" positive numbers (where they conveniently exceed their distortion specs to blow out your eardrums ). If I had to propose a convention, it's -100 for the lowest setting and 0 for the nominal top; mapped to dB if the device understands those, or arbitrarily mapped somehow if it doesn't.

Definitely separate mute/unmute/toggle mute commands. Toggles are the bane of the home control programmer.

Some devices have multiple mute states (they move active->half mute->full mute->active). I've got a TV like that; it's pretty annoying. I'm not sure we want to deal with that.

Cheers
-- perry

There's also the interesting issue of control synergy. (Yes, I just made that up.) Sitting in my living room, I control the volume by talking to my AV receiver, but the picture by talking to my TV and the channel by talking to my TiVO. That's conceptually one device, but practically it's three that cooperate (usually badly) to provide the illusion of unified control. If we create a single AV device template but don't address this synergy effect, I'll end up with three mostly-empty Indigo AV devices that need to talk to each other (for power, source switching, etc.) to make practical sense.

Can't say that I have a snazzy answer to that one. Anyone got something?

Cheers
-- perry

@perry: I think the answer to both your posts is essentially the same thing. Standardization. In order for multiple devices with different "languages" to communicate, plug-ins will need to convert the data from the device for which they are made to a standard value used by all Indigo AV plugins. I get the impression that's what Matt and Jay were alluding to.

@perry: I think the answer to both your posts is essentially the same thing. Standardization. In order for multiple devices with different "languages" to communicate, plug-ins will need to convert the data from the device for which they are made to a standard value used by all Indigo AV plugins.

Indeed. I was proposing a specific standardization of "volume" (-100 .. 0dB, best mapping effort).

My second post asks how we can standardize connections between devices acting as a whole. Obviously standardizing state value measures and meanings is helpful. But we also need a means to provide for some kind of "fusion" between devices, in situations where the particular cooperation depends on each homeowner's setup. I was hoping someone's already done some thinking about this...

Cheers
-- perry

Perry The Cynic wrote:Indeed. I was proposing a specific standardization of "volume" (-100 .. 0dB, best mapping effort).

That value makes sense, though one might want to allow for those cases where the device "overdrives" the output at positive dB values (I know my Pioneer VSX-1021 will go to +12 dB gain on the output, though you'd never really WANT to do that).

Perry The Cynic wrote:But we also need a means to provide for some kind of "fusion" between devices, in situations where the particular cooperation depends on each homeowner's setup. I was hoping someone's already done some thinking about this...

Gotcha. It seems as though Indigo's built-in device state change triggers and variable change triggers would provide most of the means necessary to accomplish this "fusion" of devices. At least, that's how I currently keep all my AV devices controlled within Indigo.

Just a thought on this - based om my experience of trying to unify large multinational companies (forget it) - what about a 2 way learning protocol (preferably network based). Coms would look like "hi denon AVR 3312 I'm a controller - what is your max, min and normal volume commands". " hi controller - 3AFF, 3A00 and 3A09"

You get what I mean. If every device did that Perry could write one plug in that could ask and be answered for every device and requirement.