Custom Search

Friday, February 4, 2011

Programming aspects of configuring universal remotes

Let's be clear - by "remote", I mean the handheld plastic (usually) devices that come with pretty much every bit of A/V gear you can buy now (my last car stereo came with one) to control the gear from across the room using some kind of I/R code. At first glance, there wouldn't seem to be much programming involved with these things, but they can be surprisingly deep. So lets look at the different types, as more and more of a the skills programmers need get involved in getting them configured.

Universal remotes

All these do is replicate - or try to replicate - the buttons from existing remotes, letting you switch between the type being emulated. These are the very simplest universal remotest, and - with a few exceptions - offer nothing that feels like programming.

The exception are the jp1 remotes. From the outside, this are indistinguishable from other remotes in this group. Inside the battery compartment - or possibly inside the remote once you open it up - you find a jp1 header, which can be used to reprogram the remote from scratch. Beyond assigning commands to buttons, you can load new executable code for the microcontroller in the remote. That makes these the most programmable of all remotes - but they also require the most programming skills to program, with the level varying depending on how fancy you want to get.

Macro remotes

These are just universal remotes with a couple of extra buttons added that can be programmed to replay a sequence of buttons - a macro. The standard usage examples are to turn on all your devices at once, or to turn them all off. Programming them usually involves a finger dance o
n the buttons of the remote, with little or no feedback as to the correctness of what you're doing. While setting these up isn't quite the mental work of real programming, the blind finger dance makes setting these up properly some of the most difficult programming I've ever done, because everything else has much better tools.

Some versions will allow macros to be placed on more than just macro keys, in extreme cases reserving only a few meta buttons like the one that starts the macro programming process.

Some jp1 remotes are in this category.

Learning remotes

These add another set of buttons, which can learn ir commands from other remotes. This allows the user to add device commands that weren't in the remotes library, or even add entire devices that weren't in the library, making them much closer to "universal" than devices without this feature.

The programming techniques tend to be the same as the macro remotes. Most of them allow learning to most buttons. Some older learning remotes didn't include libraries of other remotes, but any you can find today should have such a library. Most of them also have some sort of macro facility. Again, some of the remotes in this category are JP1 remotes.

Some of these remotes support - probably unintentionally - a facility know as "mini macros". These are just multiple ir commands learned as a single command. At least one recent remote has gone so far as to make learning ir commands the macro facility, which makes programming macros more painful that most, and limits macros to just issuing ir commands, not controlling the state of the remote.

These begin to present more interesting programming problems - at least from the UI standpoint. While the better ones have soft buttons - say besides an LCD - that let you change the button label, or even a touch-screen so you can change them all - buttons are typically in short supply. So when programming them, you need to figure out how to assign functionality to existing buttons in a manner you'll remember when you are using the device.

Device-mode remotes

The defining feature of all the categories up to this point is that they are about remote buttons. To issue a command to a device, you have to have it on a button. The commands you can issue come from buttons on an original device remote.

The thing is, most A/V gear made these days has many more commands than you can get to from the remote. For example, whereas your remote may have a command to toggle power on and off, the device probably also understands commands to explicitly turn the power on and off. Likewise, where the remote has a single button to go to "the next input" on an A/V receiver or TV set, there are probably commands to go directly to a specific input. Ditto for pretty much any feature with multiple selections a device might have. Remotes typically don't need these buttons, since if you're sitting in front of the device you can see what state it's in and goes to, and stop when you get to the right one.

If you're programming a macro, you don't have that feedback, which makes the direct commands much more useful. Programming a "power everything off" macro with just the power toggle commands risks turning things back on. Having real power off commands solves that. Writing a macro to power on the TV and DVD player and select the DVD player is much easier if you have a command to select the DVD input on the TV instead of just a command to go to the next input, which requires knowing which input is currently selected on the TV to get right.

What gives them their name is that they distinguish between device modes, which exists to hold device commands, and use modes, which are the only ones the user will normally use once the remote has been properly programmed.

The device modes will have all the commands a device understands (which means they're the only universal remotes I've encountered where I really can throw the original remotes in a drawer and forget them). Typically, it'll have all of the commands for the family of devices at the time the remote was released or last updated, meaning they probably have a lot of commands that don't even make sense for your device, like switching to non-existent inputs. Given that large number of commands, you'll not be surprised to hear that all these remotes have soft buttons so they can display those commands. Device modes are also the modes that can learn new ir commands (which are, of course, associated with the device). These act as a library of commands available to the programmer when they start programming buttons for the use modes.

The only such remotes you're likely to have heard of is the Logitech Harmony line. The rest are noticeably more expensive, and typically sold to professional installers who will charge for programming them. The macro languages in many of them (but not the Harmony) have grown into real programming languages, with variables, conditional statements, loops, subroutines, and all the other paraphernalia beloved of programmers. The company selling them may only be willing to sell you one if you've got an employee who's attended and passed their class on programming them.

The Harmony remotes manage to provide an amazing amount of flexibility with just macros. Part of this comes because the software for configuring them knows about A/V systems: that you need a source for the signal, which may goes through one or more switches, and finally to output devices for audio and/or video. So the first step in setting up a use page (which the Harmony remotes call Activities) is to tell it what devices are used, and how they are connected. This provides basic on and off macros that run when you start or change activities on the remote. You can customize each of these with further commands to any device participating in the activity. Each activity has it's own set of macros, which can play device commands but not other macros. Then each button can be assigned either a device command or a macro.

A DRY Remote

My problem with the Harmony - and every other remote I've run into - is that you wind up repeat yourself for different use pages. For example, if you'd like the play button to turn off the lights for all your media players, each of those needs to be set up individually. You can't set up a macro that turns off the light and then runs the local play command, whatever that might be.

I think a don't repeat yourself solution to this that's usable by non-programmers is possible if you do what Harmony did and leverage the fact that all usable configurations are similar. Start by setting up standard roles for the devices in an activity - source, audio amp, video display. Now provide a global macro facility that can use either those roles or real devices (for light controllers, etc.). These should simply skip any commands from devices or commands that aren't available. This does depend on the various devices that can fill a role sharing command names - at least for the common commands. But that seems to be the case for most devices.