Atlas OCAP 3033 w/extender and protocol 00 42

[jimdunn]

Doh.

Obviously - the remote only sees one protocol 00 42.

So it will overrule it if you upload a protocol upgrade - and then devices/upgrades using the built in protocol will fail.

AlternatePID is a cool way round this - but you need a "pool" of unused PIDs to take your values from if you're not going to cause more conflicts.

Is there a list of used/unused PIDs ?

I guess we're always going to be open to UEI creating protocols on PIDs we thought were "unused" and upsetting the applecart.

Can't see a way out of that, when you're downstream from those decisions.

[The Robman]

many of the PIDs used for the really old hacked protocols where chosen because they were gaps in the sequence of UEI executors found in the handful of remotes that we had in the early days (ie, the 15-1994, URC-7800, ReplayTV remote and a few others).

I would like to see us move away from using these PIDs, especially as UEI has started to re-use them. There's always going to be the potential for overlap, but if we use PIDs like $01E? and $01F? for home made executors, they should be a lot easier to identify and I think less likely to overlap with UEI executors.

[jimdunn]

Sounds like a plan.

Would you convert the old ones (probably too hard)

Or just convert when they "stick their head up" like this one did
(easier to implement)

At least it would be a defined plan for future protocol IDs.

[gfb107]

So, who's going to pick the new PID (or Alternate PID) for Panasonic Multi-Device (Hacked)?

I'm slightly concerned that changing the PID may cause problems determining the correct protocol when loading pre-PID-change IR/RMIR files, and especially when downloading from a remote.

[mr_d_p_gumby]

This presents another problem: the PID Conflict.

This has been cropping up quite often of late as UEI has begun using lots of "new" PIDs in the recent remotes. The AlternatePID approach already exists in RM & KM, and will serve as a work-around as Greg says, at least in the short term. Historically, we have always deferred to UEI's use of PID numbers, and I don't think it is a great idea to start adding ":UEI" variants to the RDF. I agree with Robman that we should change our "hacked" PID number instead.

In the latest KM version, I took this a step further and always allow the user to manually input a PID whenever KM detects that it is using a resident PID number for an upgraded protocol (whether or not it is using the standard or alternate PID). I don't consider this to be a perfect solution, but at least it gives the user the ability to circumvent this problem until we come up with a better way to deal with it.

[- who exactly is the RDF librarian?

A good question. WagonMaster tried to take over for Nils, but at the moment no one is in charge of the RDF files. To say that they need updating would be an understatement!

So, who's going to pick the new PID (or Alternate PID) for Panasonic Multi-Device (Hacked)?

According to my records 01E0, 01E2, 01E8, 01EA, 01ED, 01F2, 01F9, 01FB and 01FF are currently used by UEI. So mayber pick 01E1?

[3FG]

It seems to me that the first thing to decide is if there is any practical need for a hacked protocol or "manual settings" protocol. I suspect that in many cases these custom protocols have been superceded as the IR signal has become better understood or more popular. I think it is superior to convert existing upgrades to more standard executors whenever possible.

It may be better to let RM/KM fail so that the user or the community is forced to bring an upgrade up to date.

[vickyg2003]

In the latest KM version, I took this a step further and always allow the user to manually input a PID whenever KM detects that it is using a resident PID number for an upgraded protocol (whether or not it is using the standard or alternate PID). I don't consider this to be a perfect solution, but at least it gives the user the ability to circumvent this problem until we come up with a better way to deal with it.

I stumbled into this the other day, and just didn't know that this option hadn't always been there. I liked it very much.

[xnappo]

[- who exactly is the RDF librarian?

A good question. WagonMaster tried to take over for Nils, but at the moment no one is in charge of the RDF files. To say that they need updating would be an understatement!

Hmm. Is it a horrible idea to put them under revision control in the ControlRemote repository?

xnappo

[The Robman]

It seems to me that the first thing to decide is if there is any practical need for a hacked protocol or "manual settings" protocol. I suspect that in many cases these custom protocols have been superceded as the IR signal has become better understood or more popular. I think it is superior to convert existing upgrades to more standard executors whenever possible.

That's fine for old home made executors that have indeed been superseded by newer UEI executors, but what about ...

a) new protocols that are discovered for which there is no executor
b) old protocols for which UEI never did write an executor (or we never discovered it)
c) cases where the UEI executor sucks and we decide to write a better one?

[gfb107]

Hmm. Is it a horrible idea to put them under revision control in the ControlRemote repository?

xnappo

I think it's an excellent idea.

[gfb107]

According to my records 01E0, 01E2, 01E8, 01EA, 01ED, 01F2, 01F9, 01FB and 01FF are currently used by UEI. So mayber pick 01E1?

01E1 it is.

[xnappo]

If we think we know that a given protocol is one of 'ours' - can we somehow have RM-IR/IR just assign an unused protocol number (in the user's setup) to it?

xnappo