RMIR Xsight Support
Moderator: Moderators
Test 9 now updated to RMIR v2.03 Alpha 22 Test 10. This should resolve the latest bug found by Stephen, which was as I suspected caused by a variable being uninitialized when there were no devices in the existing setup. Many thanks, Stephen, for all your bug reports. They have been a great help in my debugging.
As I mentioned in an earlier post, I have now taken the opportunity to hide two table columns that are really only of interest during development. These are the KeyGID column of the Functions tab of the Device Upgrade Editor, and also the Serial column of the Macro tab of the main RMIR window. It is possible that this change has a bug with unintended consequences but I think I have tested it pretty well. Do report anything that seems untoward with the displays, though.
Dave, many thanks for the explanation of Lutron. I was aware of the Gray code stuff, in fact I think it was me that discovered it in this post, but not the rest of the detail about the fixed data. I see now how there can be an invalid byte. In principle it seems that this could be other than the 4th one, or could even be two of the last three bytes. The FixedDataMask value would not cope with these situations, but if they don't occur in any UEI setup code at present then perhaps we need not bother with them.
As I mentioned in an earlier post, I have now taken the opportunity to hide two table columns that are really only of interest during development. These are the KeyGID column of the Functions tab of the Device Upgrade Editor, and also the Serial column of the Macro tab of the main RMIR window. It is possible that this change has a bug with unintended consequences but I think I have tested it pretty well. Do report anything that seems untoward with the displays, though.
Dave, many thanks for the explanation of Lutron. I was aware of the Gray code stuff, in fact I think it was me that discovered it in this post, but not the rest of the detail about the fixed data. I see now how there can be an invalid byte. In principle it seems that this could be other than the 4th one, or could even be two of the last three bytes. The FixedDataMask value would not cope with these situations, but if they don't occur in any UEI setup code at present then perhaps we need not bother with them.
Graham
Hi, Graham. That worked just fine. I have run into a couple of things, though. Here's my current situation. I'd like to have the power button turn on and off the television, no matter what device is currently selected. The television is set up to use CEC to turn on and off the home theater receiver. The rest of my devices don't really turn off gracefully, so I leave them on. It appears that the television power function is available to assign in the RMIR device upgrade editor. But when I edit one of the non-television devices to assign the television power function to that power button, I can't get it to turn the television on and off when I'm in that device mode. I've checked it with captureir and the remote doesn't seem to be sending anything when I use the power button in that non-television device mode. I suspect that I should be using activities for this kind of functionality, but I haven't gotten that far yet. If I'm misunderstanding how this should work, let me know.
The other thing that I noticed is that the process of assigning buttons that belong to other devices in the device upgrade editor has some strangeness. I'm having trouble seeing a reliable pattern, but on the layout tab when I'm trying to assign functions from other devices, it seems to have trouble switching the functions on the right to the currently selected device in the drop down list. If you play with that, you might see it more clearly. If I can give you something repeatable at some point, I will.
The other thing that I noticed is that the process of assigning buttons that belong to other devices in the device upgrade editor has some strangeness. I'm having trouble seeing a reliable pattern, but on the layout tab when I'm trying to assign functions from other devices, it seems to have trouble switching the functions on the right to the currently selected device in the drop down list. If you play with that, you might see it more clearly. If I can give you something repeatable at some point, I will.
No, you are not misunderstanding how it should work. You should not need activities to do it, it should work exactly as you describe. If I haven't replied further by the time you read this, please post a .rmir file of your setup (including the non-functioning TV power assignment) so that I can see exactly what you are seeing. It may be nothing to do with your particular setup, but it is always best to post the setup you are having issues with, just in case something is device-specific.StephenR0 wrote:I suspect that I should be using activities for this kind of functionality, but I haven't gotten that far yet. If I'm misunderstanding how this should work, let me know.
EDIT: I will need to see your setup file. I have just tried an experiment, starting with your factory reset .rmir file with your TV from your .rmdu file, both of which you posted earlier. I used the remote to add two further devices, a Denon DVD with no function on the Power button and an LG Satellite with an existing function on the Power button. I then used RMIR to put the TV Power function on the Power button for the other two devices and tested the result with an IR Widget and IRScope. The Power button sent identical signals for all three devices, Panasonic protocol with Device=128.0, OBC=61. I can go no further without seeing exactly what the setup is in your remote.
Graham
I somehow missed that thread, and instead took the information about Lutron from DecodeIR.html. I suspected you had worked out the protocol because the description includes the phase "also called, more descriptively, the reflected-binary code", which I think only a mathematician would write.mathdon wrote: Dave, many thanks for the explanation of Lutron. I was aware of the Gray code stuff, in fact I think it was me that discovered it in this post, but not the rest of the detail about the fixed data. I see now how there can be an invalid byte. In principle it seems that this could be other than the 4th one, or could even be two of the last three bytes. The FixedDataMask value would not cope with these situations, but if they don't occur in any UEI setup code at present then perhaps we need not bother with them.
I notice that you've changed the name of the RDF for the ARRX12G to Xsight Plus ARRX12G. Do you think that the Xsight Plus and the ARRX12G both have PID 8011? My guess is that these two remotes will have different executors and setup codes.
Here's a link to the rmir file:
http://www.hifi-remote.com/forums/dload ... e_id=12510
You may notice that the HTPC upgrades are odd. I'm trying to use a flirc to get around issues with MCE and ir shine that I get off my plasma television. Apparently the frequency of the MCE signals is unfortunately similar to what the television puts out. So the HTPC upgrades are artificially constructed for training the flirc. There are two of them because I also use something called Netflix Viewer which needs a different set of keyboard commands which the flirc can emulate. Please, let me know if you have any questions.
http://www.hifi-remote.com/forums/dload ... e_id=12510
You may notice that the HTPC upgrades are odd. I'm trying to use a flirc to get around issues with MCE and ir shine that I get off my plasma television. Apparently the frequency of the MCE signals is unfortunately similar to what the television puts out. So the HTPC upgrades are artificially constructed for training the flirc. There are two of them because I also use something called Netflix Viewer which needs a different set of keyboard commands which the flirc can emulate. Please, let me know if you have any questions.
No, I don't think they have the same PID but I think we should have a fuller name for the ARRX12G. Stephen has given the ARRX18G the fuller name "XSight Touch ARRX18G" and I noted that Amazon sells the ARRX12G under the full name "Acoustic Research ARRX12G XSight Plus 12-Device Universal Remote Control" so I thought that name would be OK. But perhaps having XSight Plus in both names is misleading?3FG wrote:I notice that you've changed the name of the RDF for the ARRX12G to Xsight Plus ARRX12G. Do you think that the Xsight Plus and the ARRX12G both have PID 8011? My guess is that these two remotes will have different executors and setup codes.
BTW Amazon says it is discontinued by the manufacturer. Is that true? The European XSight Plus is still available from OFA.
Graham
The distribution of retail UEI remotes in the US is a mess. Audiovox has been the US distributor, but they are a holding company that includes the (once-proud) RCA and Acoustic Research brands. The higher end remotes were sold under the AR brand, while the others are sold under the RCA brand. AR has not listed any remote controls on their website for a couple of years, although one can find them on the Support page. I infer that OneForAll is now re-establishing itself in the US; the new OARUSB04G that I have is labeled OneFOrAll on the front, although the FCC logo says RCA.
I doubt that any of the Xsight series remotes are actually being manufactured; I think they are just selling off existing stock. The Xsight Touch seems to be no longer available from OFA.
I think it is fine to list all of these remotes as Xsights. I'm inclined, however, to leave the "Plus" out of the name for the ARRX12G, because I suppose that the actual Xsight Plus will have different executors and setup codes. It's not too bad if they have different PIDs, but if the PIDs are the same asking a user to choose between a Xsight Plus and a Xsight Plus may be confusing.
I doubt that any of the Xsight series remotes are actually being manufactured; I think they are just selling off existing stock. The Xsight Touch seems to be no longer available from OFA.
I think it is fine to list all of these remotes as Xsights. I'm inclined, however, to leave the "Plus" out of the name for the ARRX12G, because I suppose that the actual Xsight Plus will have different executors and setup codes. It's not too bad if they have different PIDs, but if the PIDs are the same asking a user to choose between a Xsight Plus and a Xsight Plus may be confusing.
Hi All,
Unfortunately still having problems.
I opened my previously working image with the 'Rob' lights protocol and deleted it.
I then setup a device using the built-in Lutron device - which works fine after adding manually via the remote.
Then I tried to add the UEI Lutron upgrade to my image - the protocol is correctly identified - but and it cannot be added to the setup.
This was using the Alpha10 jars/protocol.ini/RDFs.
See here:
http://www.hifi-remote.com/forums/dload ... e_id=12512
This includes the official UEI upgrade and the my RMIR file. Note that I*did * move some buttons around - not sure if that would cause a problem.
xnappo
Unfortunately still having problems.
I opened my previously working image with the 'Rob' lights protocol and deleted it.
I then setup a device using the built-in Lutron device - which works fine after adding manually via the remote.
Then I tried to add the UEI Lutron upgrade to my image - the protocol is correctly identified - but and it cannot be added to the setup.
This was using the Alpha10 jars/protocol.ini/RDFs.
See here:
http://www.hifi-remote.com/forums/dload ... e_id=12512
This includes the official UEI upgrade and the my RMIR file. Note that I*did * move some buttons around - not sure if that would cause a problem.
xnappo
Chris,
The file xsight_20140326c.rmir is already broken even before trying to add UEI_Lutron.rmdu. The Devices tab shows setup codes 1052, 2001, and 1056. But the General tab shows, on the first time it is entered, 1052, 1052, and 2001. After editing the two Cable devices, the setup codes are shown correctly, but then editing the Vizio device causes the first Cable entry (1052) to turn red.
In my experience with the Xisght ARRX12G, once a RMIR file is messed up in this way it is necessary to start over. It may be sufficient to save each device as a RMDU file and then start from a reset remote, or perhaps after just deleting the devices from the image.
The file xsight_20140326c.rmir is already broken even before trying to add UEI_Lutron.rmdu. The Devices tab shows setup codes 1052, 2001, and 1056. But the General tab shows, on the first time it is entered, 1052, 1052, and 2001. After editing the two Cable devices, the setup codes are shown correctly, but then editing the Vizio device causes the first Cable entry (1052) to turn red.
In my experience with the Xisght ARRX12G, once a RMIR file is messed up in this way it is necessary to start over. It may be sufficient to save each device as a RMDU file and then start from a reset remote, or perhaps after just deleting the devices from the image.
Test 10 now updated to RMIR v2.03 Alpha 22 Test 11.
3FG, I've had another go at producing acceptable names for the XSight RDFs. I've also assumed that xnappo's XSight Color is the ARRX15G, not the European OfA XSight Color and made that change accordingly. It means that when loading a .rmir file you will be told there is no exact match and will offer you a list of XSights. There is no change of content to the RDFs, other than the name line, so you don't have to use the new ones if you don't want to. Are you happy with these names?
Stephen, your case is rather puzzling. I see why the power buttons on the non-TV devices don't work. Four bytes of data are FF instead of 00. If you load your .rmir file into Test 10 and look at the Raw Data tab, you will see that around address 1900 there are four bytes 00 in bold. This is because the loading process has corrected them. If you upload your .rmir file into your remote, you should find that it works as intended.
As to why those bytes are wrong, I can only guess. I have gone carefully through the code used by the Buttons and Layout tabs to assign functions to buttons and have found one issue that could cause the dreaded Null Pointer Exception. Once that happens, the behaviour of RMIR can become erratic. I can only assume that this happened and that it is also the cause of the problems you have had with switching devices in the Buttons and Layout tabs.
I have corrected this. I then loaded your .rmir file, deleted the assignments to the non-TV power buttons and saved it as a new .rmir file. I then loaded that file and re-made the assignments to mimic what you will have done. I uploaded the result to my Touch without a further save and load cycle and it worked as intended. This may, of course, not mean that I have resolved the issue, just that it didn't occur for me, but it is the best I can do. Please let me know how you get on with this version.
Edit: Stephen, if you still have problems, save a .rmir file and then close RMIR. Post for me both the .rmir file and the rmaster.err file that you should find in the RMIR installation folder. That has additional information that may help me find what is going wrong.
3FG, I've had another go at producing acceptable names for the XSight RDFs. I've also assumed that xnappo's XSight Color is the ARRX15G, not the European OfA XSight Color and made that change accordingly. It means that when loading a .rmir file you will be told there is no exact match and will offer you a list of XSights. There is no change of content to the RDFs, other than the name line, so you don't have to use the new ones if you don't want to. Are you happy with these names?
Stephen, your case is rather puzzling. I see why the power buttons on the non-TV devices don't work. Four bytes of data are FF instead of 00. If you load your .rmir file into Test 10 and look at the Raw Data tab, you will see that around address 1900 there are four bytes 00 in bold. This is because the loading process has corrected them. If you upload your .rmir file into your remote, you should find that it works as intended.
As to why those bytes are wrong, I can only guess. I have gone carefully through the code used by the Buttons and Layout tabs to assign functions to buttons and have found one issue that could cause the dreaded Null Pointer Exception. Once that happens, the behaviour of RMIR can become erratic. I can only assume that this happened and that it is also the cause of the problems you have had with switching devices in the Buttons and Layout tabs.
I have corrected this. I then loaded your .rmir file, deleted the assignments to the non-TV power buttons and saved it as a new .rmir file. I then loaded that file and re-made the assignments to mimic what you will have done. I uploaded the result to my Touch without a further save and load cycle and it worked as intended. This may, of course, not mean that I have resolved the issue, just that it didn't occur for me, but it is the best I can do. Please let me know how you get on with this version.
Edit: Stephen, if you still have problems, save a .rmir file and then close RMIR. Post for me both the .rmir file and the rmaster.err file that you should find in the RMIR installation folder. That has additional information that may help me find what is going wrong.
Graham
The names look very good to me. I suppose that your comment "It means that when loading a rmir file you will be told there is no exact match and will offer you a list of XSights" refers to the presumably transient issue that rmir files which were saved with a now obsolete RDF file will cause the choice to be offered.
With the ARRX12G, when I use the Buttons tab to assign functions, RMIR offers the possibility to choose a different Device as the source of the function. I don't know what this is intended to do. In Test11 (the only version I've checked) the UI suggests that I have been able to assign functions from another device, but if I upload and then immediately download the assignments from the additional device are gone. What is supposed to happen?
With the ARRX12G, when I use the Buttons tab to assign functions, RMIR offers the possibility to choose a different Device as the source of the function. I don't know what this is intended to do. In Test11 (the only version I've checked) the UI suggests that I have been able to assign functions from another device, but if I upload and then immediately download the assignments from the additional device are gone. What is supposed to happen?
It's supposed to be the XSight version of a key move. This must be a bug. I know Test 11 fixes one bug in Test 10 but I think it has introduced another that I need to look into. You might try an earlier version if you have one; Test 5 is still available, to see if it works OK in that. I've no time to look into this now, and may not have for the next few days.3FG wrote:With the ARRX12G, when I use the Buttons tab to assign functions, RMIR offers the possibility to choose a different Device as the source of the function. I don't know what this is intended to do. In Test11 (the only version I've checked) the UI suggests that I have been able to assign functions from another device, but if I upload and then immediately download the assignments from the additional device are gone. What is supposed to happen?
Graham