JP1 Remotes

mathdon · Posted: Sat Jun 05, 2010 4:52 pm Post subject: Homemade executors

Split from here:
http://www.hifi-remote.com/forums/viewtopic.php?t=12235

The Robman · Posted: Sat Jun 05, 2010 5:38 pm Post subject:

If it were up to me, I would add all of them to protocols.ini as $01FF and then have logic in IR that would watch out for clashes where someone tries to add a 2nd $01FF upgrade and when it happens, reduce the PID to $01FE or $01FD, etc.

Btw, those of you that are helping out with this effort, when you're done with your batch of upgrades, could you zip them together and load the zip file up somewhere as that will save me the effort of downloading all the individual files myself.

Also, you may notice that some of the files don't have proper line breaks in them. There are 2 ways you can deal with this. The first is to open all the files using Wordpad, rather than Notepad, and then save the file after you open it. Alternatively, if you prefer to open the files using Notepad, you can cut & paste the contents into Wordpad (which will fix the line breaks) and then cut & paste the contents back into Notepad.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mathdon · Posted: Sun Jun 06, 2010 4:13 am Post subject:

The Robman · Posted: Sun Jun 06, 2010 8:49 am Post subject:

Mark Pierson · Posted: Sun Jun 06, 2010 9:52 am Post subject:

On the subject of user-created PID's, maybe some sort of "place-holder" PID syntax can be implemented. For example, a device and/or protocol upgrade can specify a PID of "FFFF" and then IR can auto-assign any PID that's not resident in the remote. This would be similar to what we did in KM with the ability to create "generic" Key Moves that aren't assigned to a device until processed in IR.

On the subject of this thread, I applaud the efforts of all. I tried doing something similar way back in the Yahoo days and gave up rather quickly. I also tried to come up with a way to ensure PID/dev settings became part of the file name when saving from KM but it never materialized.

I'm not sure if there's any flexibility with the File Section database, but maybe PID and Dev Settings fields can be added and filled in when a user uploads a file?
_________________
Mark

mathdon · Posted: Sun Jun 06, 2010 11:37 am Post subject:

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

We already have have a way to distinguish between protocols that have the same PID: the VariantName.

IR and KM are completely unaware of the VariantName, but obviously RM and RMIR use it.

I think we are quickly coming to the point where the integration of RMIR is becoming essential to the future of our JP1 tools.

We should, as a community, embrace RMIR as the future of JP1, and resist the temptation to enhance IR and KM to deal with these growing issues. They've been great tools that have been the foundation of the JP1 world, but the fact that they are separate tools will forever limit how far they can go.

Graham has made valuable enhancements and additions to IR, and it is a much better tool now than it was when he joined our community. He's been a wonderful addition to our community.

But just think where RMIR could be now if he had put his considerable effort and talents into helping get feature parity with IR. RMIR would now be far more than IR could ever hope to be.

I'll get back off my soap box now.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

The Robman · Posted: Sun Jun 06, 2010 1:36 pm Post subject:

The variant name is used to identify different versions of an executor that produce the same protocol, but maybe have additional features or work as a combo protocol, etc. It's not intended to be used as a way to support executors for completely different protocols that just happen to use the same PID.

So, regardless of whether the logic changes occur in RMIR or IR, I think there needs to be logic changes none the less to handle this.

Even if it's not done for the purpose of handling homemade executors, we will eventually need to do it in order to support older and newer remotes because newer remotes do not have the 2047 setup code limit nor the $01FF PID limit. UEI has already started producing setup codes with numbers over 2047 and executors with PIDs over $01FF. So our tools will need to be able to reduce either the setup or PID when someone selects an upgrade that uses them but wants to install the upgrade in an older remote.

I think the solution that I proposed earlier would work both for these cases and the homemade executors.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

mathdon · Posted: Tue Jun 08, 2010 7:43 am Post subject:

Rob, I don't understand how your proposal would work in practice. Device and protocol upgrades are separate actions. Suppose you start with an upgrade in RM that uses a PID of $01FF. That value is in both the device and protocol upgrades and provides the link between them. You add the device upgrade in IR.exe to a remote that already has a $01FF protocol. Does the PID in the device upgrade change at that point, or does it wait for the protocol upgrade? However I try to work it, I cannot find any way in which the device and protocol upgrades both finish up with the same changed PID.

If that can be solved, consider the following. I buy a new AV Amp that has three zones. Control for the different zones uses the same protocol but different device numbers. That protocol is a JP1 homemade one. I use RM to create three setup codes, one for each zone, which I intend to use with one device button on my remote through device multiplexing (that is irrelevant, but you might say that no-one would want to take up three of their device buttons for one piece of equipment). I now need to make three device upgrades and one protocol upgrade, and want to finish up with all of them having the same PID that has been changed from $01FF. What automated mechanism can achieve that?

It seems to me that to make your idea of automated adjustments workable, extensive software changes would be needed, covering at least RM, RMIR, KM and IR.exe in a coordinated fashion. However, the PID assigned to a protocol upgrade can already easily be changed manually in IR.exe, though the PID used in a device upgrade cannot. By far the simplest software modification would be just to provide a way to change, in IR.exe, the PID that is referenced by a device upgrade and then to leave the user to make changes when necessary. There would need to be some instructions provided for users, but that is a small matter compared to a major software overhaul.
_________________
Graham

The Robman · Posted: Tue Jun 08, 2010 8:50 am Post subject:

A while back I suggested that me enhance the format of the device and protocol upgrades so that when a device needs both, they can be presented to the user as a single block of code. For example, instead of this...

Upgrade Code 0 = 2A 6A (VCR/0618)
11 28 41 5E F3 FF FF 7F BF
End

Upgrade protocol 0 = 01 11 (S3C80)
43 8D 31 8B 15 CA 5D 08 08 01 21 01 06 01 21 03
31 D4 FD 11 A7 08 B7 08 02 08 E4 05 07 56 07 F0
08 06 60 C0 56 C0 0F 44 C0 07 8D 01 33
End

the user could be presented with something like this...

Upgrade Combo 0 = 2A 6A (VCR/0618)
11 28 41 5E F3 FF FF 7F BF
Upgrade protocol 0 = 01 11 (S3C80)
43 8D 31 8B 15 CA 5D 08 08 01 21 01 06 01 21 03
31 D4 FD 11 A7 08 B7 08 02 08 E4 05 07 56 07 F0
08 06 60 C0 56 C0 0F 44 C0 07 8D 01 33
End

My original reason for asking for this was to help avoid the situations where newbies forget to copy the protocol code, but it would also be needed if we were to adopt my proposal for handling homemade executors.

For this to work, IR would need to be clever enough to know when an executor is already in the memory, so if the user tries to add the same executor twice, using the above method, the second copy would not be added.

Back to the example of homemade executors that are all called $01FF, when the user goes to add the 2nd $01FF combo upgrade, where the original was re-named to $01FE by IR, IR would first recognize that this is a homemade upgrade and it would recognize that there's already a $01FF executor in memory, so it would then compare the executor code that is being added with the executor code called $01FF. If it matches, it would use $01FF for the device upgrade and it would not add a 2nd copy of the executor. If it didn't match, it would then compare the executor code with the $01FE executor and if it matches, it would use $01FE for the device upgrade and it would not add a 2nd copy of the executor. If it doesn't match any of the $01Fx executors, it would then add a new $01Fx executor (called $01FD in this case) and use that PID for the device upgrade.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

RMIR already considers the protocol upgrade to be part of the device upgrade that uses it.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

The Robman · Posted: Tue Jun 08, 2010 9:27 am Post subject:

xnappo · Expert Joined: 30 Dec 2003 Posts: 861

The Robman · Posted: Tue Jun 08, 2010 9:46 am Post subject:

Just keep in mind that, the more you require the end user to think for themselves, the more difficult you make it for newbies to use JP1. Things that are really simple for us experts are not so simple for people that only use JP1 once every 2 or 3 years when they get a new piece of equipment.

Almost every newbie has forgotten to copy the protocol upgrade over at some point, which is why I asked for the combo upgrade format. Asking them now to manage protocol ids will be too much for some people.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

vickyg2003 · Posted: Tue Jun 08, 2010 9:47 am Post subject:

Call me dense here, but I don't understand why all of our homemade protocols need to be included in protocols INI, since manual settings can be included in the rdmu or km text file.

I REALLY like the way Mike handled this, by allowing the PID to be specified in KM. It works and its not restrictive at all. It might not be all that "newbie friendly" but I'm finding some of the "newbie friendly" but how many newbies are going to be using TWO custom protocols?

I find the restricitions in our software to be more restrictive than the actual remote when it comes to tapping into new possibilities.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.