JP1 Remotes

Graham, can you add this one too, if it's not there already (UEI executor 01C8 for both Denon and Denon-K)?
http://www.hifi-remote.com/forums/viewtopic.php?t=15225

Thanks

Here are additional entries for protocols.ini. In all, 11 entries are either corrected or added, including two that have recently been mentioned in this thread.

I did not include an entry for Lutron 00E7. UEI has generated 3 different 00E7 executors with 2/1, 3/2, and 4/2 fixed/command bytes. Our protocols.ini entry is a custom executor, which is much shorter than the UEI 4/2 one. BTW, it does not appear that any variant info has been included in RDF files for remotes which have the 00E7 executor.

The UEI 4/2 executor has support for more Lutron components (like shades) than our homemade executor, offers some sort of toggling behavior, can provide different repeat behaviors, etc. I think it will require a new or augmented Lutron translator before it can be put into protocols.ini. I may be able to make some progress on it tomorrow night.

I've just started playing with Test 7 and I noticed that I can't download from the remote after doing a 981 factory reset. I've tried this with both my arrx18g and my arrx15g. In both cases, it just tries to download until I close rmir. If I add even one device, they both download without problems. I like to start with a squeaky clean image before I start adding upgrades. I suppose I can create one device on the remote, download from the remote, and delete the device. I assume the result would be equivalent. But, this used to work with Alpha21e so I thought I'd mention it.

StephenR0 wrote:I've just started playing with Test 7 and I noticed that I can't download from the remote after doing a 981 factory reset. I've tried this with both my arrx18g and my arrx15g.

Thanks for letting me know. I will look into it. However, do be aware that you cannot add built-in devices to XSight remotes with RMIR, as the remote creates an upgrade for each built-in device that you set up and RMIR does not have the data required to do that. You need to add the device with the remote itself. RMIR then allows you to edit everything to do with that device, just as for an upgrade that you have created or loaded with RMIR.

The only time you need to start with a squeaky clean remote is if all your devices are to be upgrades created from scratch or loaded from .rmdu files. The notes on the General page explain this. However, this should be possible so the inability to download after a factory reset is a bug that I need to fix.

mathdon wrote: The only time you need to start with a squeaky clean remote is if all your devices are to be upgrades created from scratch or loaded from .rmdu files.

Yes, that's how I do it. I always create upgrades from the original remotes. That seems to give me the most control.

Test 7 now updated to RMIR v2.03 Alpha 22 Test 8. Please note that there are further minor changes to the RDFs in the zip package, and that it also includes a revised protocols.ini to meet the suggestions made in earlier posts.

Stephen, please try this. It should have resolved the bug you reported. I believe the ARRX15G and ARRX18G are clones of the XSIght Color and Touch, but I don't know the USB PID values for them. I presume you are making the appropriate changes to the Color and Touch RDFs in the zip file to use with your remotes. Could you please let me know the PID values so that I can include specific RDFs in the next version.

I have made two other amendments to protocols.ini to meet other issues. I have added a version name JP1 to the Lutron protocol PID=00E7 and similarly JP1BA to the Boston Acoustics protocol PID=0046. These are both home-made executors that cannot be present in a UEI remote, and PID=0046 in any case is officially the pid for the Apex 1100W protocol, hence the addition of BA for the Boston Acoustics executor. I hope these amendments are uncontroversial.

Hi, Graham. I tried the new version and it downloads from a 981 reset just fine. You may be already aware of this, but the ARRX18G has a usb pid of 8005. I've been copying the USB8001 (XSight Touch URC-8603).rdf file and naming it USB8005 (XSight Touch ARRX18G).rdf which seems to work. I did not have to do this for the ARRX15G. It appears as pid 8002, so the Xsight Color rdf seems to work.

I've been starting to build the upload to the remote from my various upgrades. I did run into one thing so far. When I create a new device in RMIR and open an rdmu file that I created in RemoteMaster with all the buttons assigned, all the button assignments are gone. Now, I didn't create this rdmu from scratch with the latest version. But I did edit it with the latest version and save it. If I'm doing something wrong with this work flow, just let me know.

In addition, I noticed that all the KeyGID entries are null when I open the rdmu from RMIR. In RemoteMaster, I had them all zero. I'm not sure what that field does, so it may not be important. Can you help me understand how to use that field?

A day late and a dollar short......
Here is a candidate for a PID 00E7:4 protocols.ini entry as well as a revised LutronTranslator. I've included RemoteMaster.jar which is identical to Test8, but with the revised Lutrontranslator.

This is supposed to support the UEI 00E7 executor which employs 4 fixed data bytes and 2 command bytes. I've only tested it with a ARRX12G (similar to Xsight Plus) remote. The executor allows one to choose 3 groups of OBCs (16 values of the OBC in each group) in conjunction with a single device. It additionally has a facility to send two signals in which the second signal has bit 1 flipped from the first. Or, it can send one of such a pair, but toggle between the two signals on each press of the button. Setup code (Home Auto) 0597 uses this facility to implement a Power Toggle function. It also seems to send Power Off followed by Power On when invoking the soft function Power On.

I spent a lot of time (wasted, really) on the LutronTranslator trying to find a way to gracefully handle setup code 1239. It has fixed data 7D 1D 22 00, and this last 00 is not a valid encoding for the Lutron IR protocol. It's not a problem for UEI, since they don't use this byte, but I can't find a way to read this setup code into RMIR, have it be recognized as Lutron Official, and still have a functioning RMIR. RMIR tries to identify each upgrade it reads in, and the fixed data for 1239 isn't valid. So RMIR rejects Lutron Official as the correct identity of the executor and uses instead a generic 00E7 PID. I don't see a way for a user to correlate the displayed results with the parameters used by Lutron Official.

I would appreciate anyone with knowledge of Lutron equipment giving this a try.

3FG wrote:Here is a candidate for a PID 00E7:4 protocols.ini entry as well as a revised LutronTranslator.

All remotes with S3C8+, S3F8, HCS08 and MAXQ processors that support the Lutron protocol support the version with 4 fixed and 2 command bytes, so I suggest that we call this simply PID 00E7 with no variant name. That will keep all the RDFs for those remotes valid without alteration. We could use 00E7:old for any earlier version if still needed.

3FG wrote:I spent a lot of time (wasted, really) on the LutronTranslator trying to find a way to gracefully handle setup code 1239. It has fixed data 7D 1D 22 00, and this last 00 is not a valid encoding for the Lutron IR protocol.

I don't understand this. Surely the Lutron Official protocol is the executor used by UEI, as I presume we don't have inside knowledge of what Lutron OEM products use. So I don't see how fixed data used by UEI can be invalid. I'm also puzzled by the statement that UEI doesn't use the 4th fixed byte. Does this mean that the Lutron Official executor doesn't use it? If so, why is its value relevant? If I understood this better, I might be able to help with the setup code 1239 issue.

StephenR0 wrote:I did not have to do this for the ARRX15G. It appears as pid 8002, so the Xsight Color rdf seems to work.

Stephen, was there a misprint in your post? You say the PID is 8002 for the ARRX15G but the Color RDF uses 8004. I don't have an XSight Color, only the Lite and Touch, so the PID for the Color is that provided by xnappo. Being in the USA I suspect this is actually the ARRX15G and not the European XSight Color. Xnappo, could you confirm this? If so, I will re-name the RDF and would be pleased if anyone knows the PID for the European XSight Color.

StephenR0 wrote:In addition, I noticed that all the KeyGID entries are null when I open the rdmu from RMIR. In RemoteMaster, I had them all zero. I'm not sure what that field does, so it may not be important. Can you help me understand how to use that field?

The conversion from zero to null is a bug. What this field actually does is something of a mystery. It appears to be a global identifier for functions (not keys, as the name implies) used within EZ-RC. The remote appears to make no use of it, and if values are changed with RMIR and the result uploaded to EZ-RC, it still causes no problems. I suspect it is only used when EZ-RC first assigns a function to a key, and why its value is stored in the remote is unknown. I am thinking of hiding it when this version of RMIR gets closer to general release, but I have left it visible at present in case any significance crops up in users' experiments. Leaving it at the RMIR default of zero seems to cause no problems that I have seen.

*** EDIT ***
3FG, as I don't understand the Lutron problem with setup code 1239, this may be irrelevant but here is a possible solution. Are you aware that there is a parameter FixedDataMask that you can put into a protocols.ini entry? For example, if you follow your FixedData entry thus:
then RMIR will only check the first three bytes when testing for a matching protocol.

Test 8 now updated to RMIR v2.03 Alpha 22 Test 9. This includes a new protocols.ini and also a specific RDF for the ARRX18G.

Dave (3FG), as I suggested in my post above, I have incorporated your revised Lutron translator in RMIR and your Lutron Official protocol in protocols.ini but without a variant name. I have also added to it the line
The RDFs are unchanged from those of Test 8, leaving protocol 00E7 as it was. By doing a factory reset on my Touch and setting the region to North America, I was able to add a device with Home Auto setup code 1239. This now shows as Lutron Official. If you open the Device Editor, the Fixed Data shows as 7D 1D 22 11, so the final 00 has been changed and on upload this new value will go into the remote. From what you have said, however, I understand that should make no difference. It shows the device parameters as Device=80 and the three groups as 4, 9, 0. I have no idea if that is correct.

Stephen, I could not reproduce the behaviour you reported, but in looking for it I did find a bug affecting the Buttons tab of RM (as distinct from RMIR) that caused a Null Pointer Exception if you loaded a .rmdu file for an XSight. After such an exception, lots can go wrong, unpredictably. I've fixed that and now all seems well with my testing. Please give it a try. If you still have problems, please post the .rmdu file concerned and a .rmir file of the setup into which you were trying to load it. The zero to null problem may have been caused by the same bug, as I can't make it happen now but I have done nothing specifically to fix it.

mathdon wrote: Stephen, was there a misprint in your post? You say the PID is 8002 for the ARRX15G but the Color RDF uses 8004.

Of course, you are correct. I checked again to make sure and it does appear as 8004. Sorry.

I'll try the new version and see if my buttons stay assigned. I'll update when I have more experience. Thanks.

I've tested the new version some. To be clear, here are the steps that I'm following:

1. From a clean image from the remote (ARRX18G), on the devices tab in RMIR, I select "new" and name the device when prompted.

2. In the Device Upgrade Editor that pops up, I open my saved rmdu file. Everything looks good. My button assignments are there now and the KeyGID field is zero and not null anymore.

3. I select "ok", but that seems to be ignored. I see no other message. It just won't save it. But I can cancel, which leaves no added device.

I believe I've seen something similar before with Alpha21e. In that case, I was able to create the device with ezrc. Then I could edit that device, open my rmdu, and save it from there. I believe I could have created the device in the remote as well, but I didn't try that. Again, if there's something wrong with my work flow, let me know.

Stephen, please post the .rmdu file you are trying to load. I take it that by a clean image in step 1, you mean the remote after a factory reset. If you mean anything else, please also post a .rmir file of the setup. There is nothing wrong with your workflow. I have not come across the OK button being ignored, so would like to see the precise files you are working with.

You might also like to check the following. First, set up a device, any device, using the remote (not EZ-RC). Download that to RMIR and then try loading your .rmdu file. It might be a problem with loading a .rmdu file when there are no other devices set up. I can't see why that might happen, but it is possible. I don't have time at the moment to do that experiment myself (it is bed-time here ). I would like to have your .rmdu file to experiment with if I have time to look at this tomorrow.

I've uploaded the relevant files in a zip here:

http://www.hifi-remote.com/forums/dload ... e_id=12506

I tried the experiment that you suggested. From a 981 reset ARRX18G, I created a simple Panasonic television device and saved it to an rmdu file. Then I loaded the rmir image of a 981 reset ARRX18G and tried to create the device in the manner I described above. I had the same experience. Selecting "ok" would not save the device. Then I downloaded from the remote with that Panasonic television device, edited that device, and opened the rmdu that I created from scratch. I had no problem selecting "ok" and saving it. I've included the blank rmir file and the two rmdu files. The one named Panasonic TV is the simple one and the other one is my upgrade created from scratch. Whatever it is seems quite repeatable.

Graham,
No, I wasn't aware of FixedDataMask. As you've already shown, it takes care of the problem, and I glad that we have this feature. I also agree that we can use 00E7 to designate the Lutron Official executor.

Here's a long-winded explanation of the Lutron IR protocol, and how the UEI executor can have invalid data.

The Lutron IR protocol is unusual. It is has a serial form with 8 start bits (ones) and 4 stop bits (zeros). The raw data is 1 byte of device and 1 byte of command, but these 16 bits are first transformed into 24 bits before being sent by IR. The most common device number is 0xFF, and many commands are in the range 0x40 to 0x4F or 0x90 to 0x95. Here I will show the encoding of 0xFF 0x91.

1111 1111 1001 0001
1111 1111 1001 0001 10 append two parity bits calculated for for the odd and even numbered bits separately
111 111 111 001 000 110 split into 6 octal digits
100 100 100 001 000 101 Change to Gray encoding for the 6 digits
1000 1000 1000 0010 0001 1011 Append a bit to each Gray encoded octal digit to yield a hex digit with odd parity

Hence the payload is 88 82 1B. If instead we use 0xFF and 0x40, then the payload is 88 BD 12
The 1st byte is completely determined by the device number, but the 2nd and 3rd bytes are dependent on both device and OBC. Additionally, the requirement that each hex digit have odd parity means that only 1/4 of the 256 possible values for each payload byte is valid. The others are invalid because at least one hex digit will have even parity.

The Lutron Official executor uses 4 bytes of fixed data. The first fixed byte is the first byte of the payload. Fixed bytes 2 to 4 are each candidates to be the second byte of the payload, and are selected by bits 0 and 1 of the second command byte. For a given second payload byte, only 16 OBC values are possible, so having 3 possible second payload bytes allows access to 3 groups of OBC values. The first command byte is the third byte of the payload. Bits 6 and 7 of the second command byte specify the toggle/dual signal behavior.

Setup code 1239 has fixed data 7D 1D 22 00. 7D corresponds to device 80, 1D permits OBC values between 64 and 79 (OBCgrp 4). 22 permits OBCs between 144 and 159 (OBCgrp 9). But 00 doesn't have the correct parity and can't be inverted. 1239 only sends IR signals in the range 64-79 and 144-159, so the selector bits never point to the invalid 00 and the invalid fixed data isn't a problem for UEI. The Lutron Translator converts the invalid byte into a raw octal of 0, which re-converts to fixed data of 11. As Graham has pointed out, using FixedDataMask allows RMIR to recognize Lutron Official, even though the fixed data is invalid.