Protocol ID conflicts with a built-in protocol. Explanation?

[chico_woodhill]

Hi - Doing some work that has me using the NEC 4DEV Yamaha Combo protocol.

I get this message at the bottom of the Device Upgrade Editor:

"Protocol ID conflicts with a built-in protocol. To use both this and the built-in protocol in device upgrades, this one needs to be given an Alternate PID."

Not sure what to do with the alternate PID. Can I just create a random one?

It seems to work with my remote, and I'm not sure what the message means exactly and/or if I should be concerned.

Can someone explain this, and tell me if there's a quick fix to make it better?

Thanks...

(JP1 still rocks, even though nobody seems to know what a remote is anymore...'Why don't you just pull out your phone and go through 6 menus to change the channel....?' )

[mathdon]

The message means what it says. The NEC 4DEV Yamaha Combo protocol is one created by the JP1 forum. We gave it the PID of 011A, the same as that of the official NEC 2DEV Combo protocol but distinguished from it by a variant name of JP1. The message means that your remote has this official protocol built in. Since the remote itself knows nothing about protocol names or even about variant names (which are something we invented), it identifies a protocol only by its PID and RMIR prevents you from uploading a protocol upgrade that would clash with a built-in PID.

You have two ways to proceed. You can give the Yamaha Combo an alternate PID, which indeed can be anything you choose. Most modern remotes can handle values up to 0FFF, though I don't think UEI has yet gone beyond 02FF with its official ones. You can check which values are built in to the remote by looking at the [Protocols] section of the RDF.

If you do this then you would, if you wished, be able to have upgrades that use the NEC 2DEV Combo and the NEC 4DEV Yamaha Combo both present at the same time in your remote. However, if you know that you will never want to use the NEC 2DEV Combo then you have a simpler choice, the quick fix that you ask for. This is to edit the RDF and delete 011A from the [Protocols] section. RMIR will then not know that there is a built-in protocol with this PID and so will upload your upgrade. You would, of course, have to repeat this edit every time you upgraded to a new version of RMIR.

The remote is happy with a protocol upgrade having the same PID as a built-in one, it simply means that there is no way to access the built-in one in a device upgrade. Alternate PIDs were invented to avoid the need to edit the RDF and also to allow both to be used at once, but I'm afraid they do cause confusion such as you have experienced.

[chico_woodhill]

Thanks for the detailed and straightforward reply. Makes sense to me.

This is the part that didn't make sense to me until your reply (I couldn't guess why this wasn't automatically handled in the program):

Alternate PIDs were invented to avoid the need to edit the RDF and also to allow both to be used at once, but I'm afraid they do cause confusion such as you have experienced.

...but your answer clears that up for me.

All's well and working. Thanks again.