JP1 Remotes Wiki - User contributions [en]

Building the Arduino Interface for older remotes

2023-08-29T11:04:27Z

Davecs: /* The drawing */

==Background==

When it was discovered that you could connect a computer to a UEI One For All remote that had 6 pins available inside the battery cover, it was possible to make a lead which connected via the printer port on your computer. As time went on, UEI changed the type of interface behind those six pins, which required a different interface. We called the original interface "JP1", because some of the remotes had that printed on the circuit board on which the 6 pins were mounted. The new interfaces were called JP1.1, JP1.2, and so on. We tend to call them JP1.x because although they are quite different from each other, they all work through the same USB interface. We've described that interface in this wiki. *[[JP1 Cables]]

As more and more printers used USB ports, computers came without the old printer port. This caused a problem for those of us trying to control the old JP1 interface. For a while, there was a dongle that sat between the JP1.x cable and the old type JP1 remotes, but this is no longer available. The best way to connect your old JP1 remote to your computer is by making an interface based on the Arduino Nano (with an Atmel 328P chip). This method has been known for a long time, but I found the ASCII art diagrams confusing and intimidating. Then someone posted a drawing on the forum which made it look much easier, so I had a go. And I was able to pull some very old remotes out of retirement!

==The drawing==

This is based on the drawing that was posted, with some alterations I made, in order to make it easier still!

[[Image:Arduino-wiring3.jpg]]

The Arduino Nano comes with a strip of pins matching the holes down each side, plus a 3x2 connector matching the 6 holes on the right-hand edge of the Nano as shown. They can be supplied soldered in or loose as part of the Nano. If they are soldered in, you have no soldering to do. If not, you can break off the pins you actually need. Break off two together, plus two singles. You can put a strip of pins through all the holes from D12 to TX1, and put the pair and one of the singles in A4, A5 and GND on the opposite side. This will enable the board to keep still while you put a small bit of solder on the pins to attach them. You can then connect the other pin to the GND on the other side in the same way.

The other thing you need is a pack of female-to-female Dupont-type jumper wires. They normally come in mixed colours in packs of 40. You may also be able to get hold of a 3x2 Dupont connector. They're cheap enough, but you often have to buy them in bulk. It's possible to superglue the single Dupont housings together to make a 3x2 connector. As my board came unsoldered, I used the 3x2 pin block to hold the single housings together while I glued them. You can do this if the pin block is soldered to the Arduino board, but be careful not to glue the connectors to the board!!

[[Image:IMG_20230826_155004_334_1.jpg|300px|thumb|left|Pins 2, 4 and 6]] [[Image:IMG_20230826_155015_490_1.jpg|396px|thumb|right|Pins 5, 3 and 1]]

You will need 5 wires from your pack of jumper wires. I used one each of White, Black, Blue, Green and Mauve. I put a tiny drop of superglue on the back of one end of the white wire, and stuck the back of the other end to it. Then carefully stuck the black and blue wires to that, finally sticking the mauve and green wires. The little exposed bits of metal on the sides are where you can clip and unclip the wires, so make sure they are on the outside. Alternately, if you have a 3x2 Dupont connector, you just unclip the wires from the single terminals and push them into the 3x2 connector. Whichever method you use, it should look like these pictures.

You can see where I have stuck a small piece of a label to mark the end with Pins 1&2.

Now the other ends of the wires can simply be pressed onto the pins on the board. Connect blue wire to A4, green to A5, and the mauve and black to the two GNDs (it doesn't matter which way round as they are connected internally on the Arduino Nano).

[[Image:IMG_20230828_180255_634.jpg|500px|thumb|center|Wires connected to Arduino board]]

=Uploading the Sketch file to the Arduino=

The Arduino project and its program are open-source, so is available free, but this does mean that there can be different builds. The sketch file you need to upload is in the RMIR folders when you download a new version and unzip it. The folder is JP1EEPROMSupport, subfolder JP1_Arduino, and the filename is JP1_Arduino.ino. The program, simply called "arduino", can be downloaded for Windows and Mac. For Linux users it may be in the repository of your distribution. On its menu bar, under Tools, you have to select the type of Arduino you are using. On one build I have, you have to select your board from a long list, the correct one being "Atmel atmega328p Xplained mini". On another build, there is a shorter list where you select "Arduino Nano", then separately select the processor "ATmega328P". There are two alternatives for this, but if you select the wrong one, the program just won't upload your sketch file and you can try the other one! Use the usual "File > Open" to open the sketch file, then the Right Arrow icon on the bar underneath the menus to upload your sketch. Your sketch will remain uploaded so this is a one-off.

I'm sure that by now you can't wait to get connected to your old JP1 remote so ... enjoy!

Building the Arduino Interface for older remotes

2023-08-28T22:45:22Z

Davecs: /* Background */

==Background==

When it was discovered that you could connect a computer to a UEI One For All remote that had 6 pins available inside the battery cover, it was possible to make a lead which connected via the printer port on your computer. As time went on, UEI changed the type of interface behind those six pins, which required a different interface. We called the original interface "JP1", because some of the remotes had that printed on the circuit board on which the 6 pins were mounted. The new interfaces were called JP1.1, JP1.2, and so on. We tend to call them JP1.x because although they are quite different from each other, they all work through the same USB interface. We've described that interface in this wiki. *[[JP1 Cables]]

As more and more printers used USB ports, computers came without the old printer port. This caused a problem for those of us trying to control the old JP1 interface. For a while, there was a dongle that sat between the JP1.x cable and the old type JP1 remotes, but this is no longer available. The best way to connect your old JP1 remote to your computer is by making an interface based on the Arduino Nano (with an Atmel 328P chip). This method has been known for a long time, but I found the ASCII art diagrams confusing and intimidating. Then someone posted a drawing on the forum which made it look much easier, so I had a go. And I was able to pull some very old remotes out of retirement!

==The drawing==

This is based on the drawing that was posted, with some alterations I made, in order to make it easier still!

[[Image:Arduino-wiring3.jpg]]

The Arduino Nano comes with a strip of pins matching the holes down each side, plus a 3x2 connector matching the 6 holes on the right-hand edge of the Nano as shown. They can be supplied soldered in or loose as part of the Nano. If they are soldered in, you have no soldering to do. If not, you can break off the pins you actually need. Break off two together, plus two singles. You can put a strip of pins through all the holes from D12 to TX1, and put the pair and one of the singles in A4, A5 and GND on the opposite side. This will enable the board to keep still while you put a small bit of solder on the pins to attach them. You can then connect the other pin to the GND on the other side in the same way.

The other thing you need is a pack of female-to-female Dupont-type jumper wires. They normally come in mixed colours in packs of 40. You may also be able to get hold of a 3x2 Dupont connector. They're cheap enough, but you often have to buy them in bulk. It's possible to superglue the single Dupont housings together to make a 3x2 connector. As my board came unsoldered, I used the 3x2 pin block to hold the single housings together while I glued them. You can do this if the pin block is soldered to the Arduino board, but be careful not to glue the connectors to the board!!

[[Image:IMG_20230826_155004_334_1.jpg|300px|thumb|left|Pins 2, 4 and 6]] [[Image:IMG_20230826_155015_490_1.jpg|400px|thumb|right|Pins 5, 3 and 1]]

You will need 5 wires from your pack of jumper wires. I used one each of White, Black, Blue, Green and Mauve. I put a tiny drop of superglue on the back of one end of the white wire, and stuck the back of the other end to it. Then carefully stuck the black and blue wires to that, finally sticking the mauve and green wires. The little exposed bits of metal on the sides are where you can clip and unclip the wires, so make sure they are on the outside. Alternately, if you have a 3x2 Dupont connector, you just unclip the wires from the single terminals and push them into the 3x2 connector. Whichever method you use, it should look like these pictures.

You can see where I have stuck a small piece of a label to mark the end with Pins 1&2.

Now the other ends of the wires can simply be pressed onto the pins on the board. Connect blue wire to A4, green to A5, and the mauve and black to the two GNDs (it doesn't matter which way round as they are connected internally on the Arduino Nano).

[[Image:IMG_20230828_180255_634.jpg|500px|thumb|center|Wires connected to Arduino board]]

=Uploading the Sketch file to the Arduino=

The Arduino project and its program are open-source, so is available free, but this does mean that there can be different builds. The sketch file you need to upload is in the RMIR folders when you download a new version and unzip it. The folder is JP1EEPROMSupport, subfolder JP1_Arduino, and the filename is JP1_Arduino.ino. The program, simply called "arduino", can be downloaded for Windows and Mac. For Linux users it may be in the repository of your distribution. On its menu bar, under Tools, you have to select the type of Arduino you are using. On one build I have, you have to select your board from a long list, the correct one being "Atmel atmega328p Xplained mini". On another build, there is a shorter list where you select "Arduino Nano", then separately select the processor "ATmega328P". There are two alternatives for this, but if you select the wrong one, the program just won't upload your sketch file and you can try the other one! Use the usual "File > Open" to open the sketch file, then the Right Arrow icon on the bar underneath the menus to upload your sketch. Your sketch will remain uploaded so this is a one-off.

I'm sure that by now you can't wait to get connected to your old JP1 remote so ... enjoy!

Building the Arduino Interface for older remotes

2023-08-28T22:20:52Z

Davecs: /* Background */

==Background==

When it was discovered that you could connect a computer to a UEI One For All remote that had 6 pins available inside the battery cover, it was possible to make a lead which connected via the printer port on your computer. As time went on, UEI changed the type of interface behind those six pins, which required a different interface. We called the original interface "JP1", because some of the remotes had that printed on the circuit board on which the 6 pins were mounted. The new interfaces were called JP1.1, JP1.2, and so on. We tend to call them JP1.x because although they are quite different from each other, they all work through the same USB interface. We've described that interface in this wiki. *[[JP1 Cables]]

As more and more printers used USB ports, computers came without the old printer port. This caused a problem for those of us trying to control the old JP1 interface. For a while, there was a dongle that sat between the JP1.x cable and the old type JP1 remotes, but this is no longer available. The best way to connect your old JP1 remote to your computer is by making an interface based on the Arduino Nano (with an Atmel 328P chip). This method has been known for a long time, but I found the diagrams confusing and intimidating. Then someone posted a drawing on the forum which made it look much easier, so I had a go. And I was able to pull some very old remotes out of retirement!

==The drawing==

This is based on the drawing that was posted, with some alterations I made, in order to make it easier still!

[[Image:Arduino-wiring3.jpg]]

The Arduino Nano comes with a strip of pins matching the holes down each side, plus a 3x2 connector matching the 6 holes on the right-hand edge of the Nano as shown. They can be supplied soldered in or loose as part of the Nano. If they are soldered in, you have no soldering to do. If not, you can break off the pins you actually need. Break off two together, plus two singles. You can put a strip of pins through all the holes from D12 to TX1, and put the pair and one of the singles in A4, A5 and GND on the opposite side. This will enable the board to keep still while you put a small bit of solder on the pins to attach them. You can then connect the other pin to the GND on the other side in the same way.

The other thing you need is a pack of female-to-female Dupont-type jumper wires. They normally come in mixed colours in packs of 40. You may also be able to get hold of a 3x2 Dupont connector. They're cheap enough, but you often have to buy them in bulk. It's possible to superglue the single Dupont housings together to make a 3x2 connector. As my board came unsoldered, I used the 3x2 pin block to hold the single housings together while I glued them. You can do this if the pin block is soldered to the Arduino board, but be careful not to glue the connectors to the board!!

[[Image:IMG_20230826_155004_334_1.jpg|300px|thumb|left|Pins 2, 4 and 6]] [[Image:IMG_20230826_155015_490_1.jpg|400px|thumb|right|Pins 5, 3 and 1]]

You will need 5 wires from your pack of jumper wires. I used one each of White, Black, Blue, Green and Mauve. I put a tiny drop of superglue on the back of one end of the white wire, and stuck the back of the other end to it. Then carefully stuck the black and blue wires to that, finally sticking the mauve and green wires. The little exposed bits of metal on the sides are where you can clip and unclip the wires, so make sure they are on the outside. Alternately, if you have a 3x2 Dupont connector, you just unclip the wires from the single terminals and push them into the 3x2 connector. Whichever method you use, it should look like these pictures.

You can see where I have stuck a small piece of a label to mark the end with Pins 1&2.

Now the other ends of the wires can simply be pressed onto the pins on the board. Connect blue wire to A4, green to A5, and the mauve and black to the two GNDs (it doesn't matter which way round as they are connected internally on the Arduino Nano).

[[Image:IMG_20230828_180255_634.jpg|500px|thumb|center|Wires connected to Arduino board]]

=Uploading the Sketch file to the Arduino=

The Arduino project and its program are open-source, so is available free, but this does mean that there can be different builds. The sketch file you need to upload is in the RMIR folders when you download a new version and unzip it. The folder is JP1EEPROMSupport, subfolder JP1_Arduino, and the filename is JP1_Arduino.ino. The program, simply called "arduino", can be downloaded for Windows and Mac. For Linux users it may be in the repository of your distribution. On its menu bar, under Tools, you have to select the type of Arduino you are using. On one build I have, you have to select your board from a long list, the correct one being "Atmel atmega328p Xplained mini". On another build, there is a shorter list where you select "Arduino Nano", then separately select the processor "ATmega328P". There are two alternatives for this, but if you select the wrong one, the program just won't upload your sketch file and you can try the other one! Use the usual "File > Open" to open the sketch file, then the Right Arrow icon on the bar underneath the menus to upload your sketch. Your sketch will remain uploaded so this is a one-off.

I'm sure that by now you can't wait to get connected to your old JP1 remote so ... enjoy!

Building the Arduino Interface for older remotes

2023-08-28T22:19:51Z

Davecs: /* Background */

==Background==

When it was discovered that you could connect a computer to a UEI One For All remote that had 6 pins available inside the battery cover, it was possible to make a lead which connected via the printer port on your computer. As time went on, UEI changed the type of interface behind those six pins, which required a different interface. We called the original interface "JP1", because some of the remotes had that printed on the circuit board on which the 6 pins were mounted. The new interfaces were called JP1.1, JP1.2, and so on. We tend to call them JP1.x because although they are quite different from each other, they all work through the same USB interface. We've described that interface in this wiki. *[[JP1 Cables]]

As more and more printers used USB ports, computers came without the old printer port. This caused a problem for those of us trying to control the old JP1 interface. For a while, there was a dongle that sat between the JP1.x cable and the old type JP1 remotes, but this is no longer available. The best way to connect your old JP1 remote to your computer is by making an interface based on the Arduino Nano. This method has been known for a long time, but I found the diagrams confusing and intimidating. Then someone posted a drawing on the forum which made it look much easier, so I had a go. And I was able to pull some very old remotes out of retirement!

==The drawing==

This is based on the drawing that was posted, with some alterations I made, in order to make it easier still!

[[Image:Arduino-wiring3.jpg]]

The Arduino Nano comes with a strip of pins matching the holes down each side, plus a 3x2 connector matching the 6 holes on the right-hand edge of the Nano as shown. They can be supplied soldered in or loose as part of the Nano. If they are soldered in, you have no soldering to do. If not, you can break off the pins you actually need. Break off two together, plus two singles. You can put a strip of pins through all the holes from D12 to TX1, and put the pair and one of the singles in A4, A5 and GND on the opposite side. This will enable the board to keep still while you put a small bit of solder on the pins to attach them. You can then connect the other pin to the GND on the other side in the same way.

The other thing you need is a pack of female-to-female Dupont-type jumper wires. They normally come in mixed colours in packs of 40. You may also be able to get hold of a 3x2 Dupont connector. They're cheap enough, but you often have to buy them in bulk. It's possible to superglue the single Dupont housings together to make a 3x2 connector. As my board came unsoldered, I used the 3x2 pin block to hold the single housings together while I glued them. You can do this if the pin block is soldered to the Arduino board, but be careful not to glue the connectors to the board!!

[[Image:IMG_20230826_155004_334_1.jpg|300px|thumb|left|Pins 2, 4 and 6]] [[Image:IMG_20230826_155015_490_1.jpg|400px|thumb|right|Pins 5, 3 and 1]]

You will need 5 wires from your pack of jumper wires. I used one each of White, Black, Blue, Green and Mauve. I put a tiny drop of superglue on the back of one end of the white wire, and stuck the back of the other end to it. Then carefully stuck the black and blue wires to that, finally sticking the mauve and green wires. The little exposed bits of metal on the sides are where you can clip and unclip the wires, so make sure they are on the outside. Alternately, if you have a 3x2 Dupont connector, you just unclip the wires from the single terminals and push them into the 3x2 connector. Whichever method you use, it should look like these pictures.

You can see where I have stuck a small piece of a label to mark the end with Pins 1&2.

Now the other ends of the wires can simply be pressed onto the pins on the board. Connect blue wire to A4, green to A5, and the mauve and black to the two GNDs (it doesn't matter which way round as they are connected internally on the Arduino Nano).

[[Image:IMG_20230828_180255_634.jpg|500px|thumb|center|Wires connected to Arduino board]]

=Uploading the Sketch file to the Arduino=

The Arduino project and its program are open-source, so is available free, but this does mean that there can be different builds. The sketch file you need to upload is in the RMIR folders when you download a new version and unzip it. The folder is JP1EEPROMSupport, subfolder JP1_Arduino, and the filename is JP1_Arduino.ino. The program, simply called "arduino", can be downloaded for Windows and Mac. For Linux users it may be in the repository of your distribution. On its menu bar, under Tools, you have to select the type of Arduino you are using. On one build I have, you have to select your board from a long list, the correct one being "Atmel atmega328p Xplained mini". On another build, there is a shorter list where you select "Arduino Nano", then separately select the processor "ATmega328P". There are two alternatives for this, but if you select the wrong one, the program just won't upload your sketch file and you can try the other one! Use the usual "File > Open" to open the sketch file, then the Right Arrow icon on the bar underneath the menus to upload your sketch. Your sketch will remain uploaded so this is a one-off.

I'm sure that by now you can't wait to get connected to your old JP1 remote so ... enjoy!

Main Page

2023-08-28T22:18:25Z

Davecs: /* JP1 Guides */

''(Back to [http://www.hifi-remote.com/forums JP1 Forums])'' 
Welcome to the JP1 community Wiki site. A collaborative website relative to the JP1 community to which anyone can contribute!

'''PLEASE NOTE:''' The Wiki section of this website has a different account system than the Forums, so please don't try to log onto the Wiki using your JP1 account id. If you wish to contribute, please see the [[Main Page#Note to new Wiki users|Note to new Wiki users]] below, and one of us will create a Wiki account for you.

==JP1 Guides==
*[[JP1_Introduction|Introduction to JP1]]
*[[The History of the JP1 Project]]
*[[JP1 - Just How Easy Is It?]]
*[[The WHAT and WHY of JP1]]
*[[Creating A Better Upgrade]]
*[[JP1 Cables]]
*[[Building the Arduino Interface for older remotes]]
*[[Hacking JP1 Remotes]]
*[[Extenders (an FAQ)]]
*[[Infrared Signals]]
*[[How to use RIDgen]]
*[[IrScrutinizer Guide]]
*[[ToadTog]]
*[[Getting started with Xsight and Nevo]]
*[[Xsight_Disassembly]]
*[[Importing Foreign IR Remotes in RemoteMaster]]
*[[Using URC6440 and OARUSB04G Remotes with Linux]]

==Manuals==
*[[Remote Master Manual]] (not complete)
*[[IR Help]]
*[[Protocol Builder]]
*[[IR Scope and IR Widget User's Guide]]
*[[DecodeIR]]
*[[AIRWidget and IRScope Operating Instructions]]
*[[The 3660 family|The 3660 family of remotes]]
*[[INT-422|Programming an INT-422-4 Remote]]

==General Remote Guides==
*[[Manual Programming - 9xx Commands]]
*[[Manual Programming - Sky Remotes]]
*[[Master Reset Instructions]]
*[[Modem Upgrade Procedure]]
*[[The Correct Learning Procedure]]
*[[RemoteChart]]

==[[Slingbox]]==
*[[How to Install a Custom Remote onto the Slingbox]]
*[[Customising the Remote Image on your Slingplayer]]
*[[How to Create Custom Remote Controls and use them on your Slingbox]]

==Resources==
*[[IRP Notation]]
*[[DecodeIR]]
*[[Working With Pronto Hex]]
*[[JP1 versus Harmony]]
*[[Technical Documents]]
*[[Glossary]]
*[http://www.hifi-remote.com/forums JP1 Forums]
*[http://www.hifi-remote.com/forums/dload.php JP1 Files]
*[http://www.hifi-remote.com/jp1/lookup JP1 Lookup Tool]
*[https://www.youtube.com/watch?v=ubrq9Pr3Y1Y&list=PLXmyroJbN9CAxc6vADS4iiXQT3fp0c-Iq JP1 "How To" Videos]

==References==
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2367 Lutron Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9545 Onkyo Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=508 Pioneer Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=383 Sanyo Projector Master List]
*[http://www.hifi-remote.com/sony/ Sony Master List]
*[http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9582 Yamaha Master List]

==Note to new Wiki users==
Due to the incredibly high number of spam accounts being created on this wiki, we have been forced to disable the New Account feature. If you wish to contribute to the wiki, please contact any of the following via the main JP1 Forum:
[http://www.hifi-remote.com/forums/profile.php?mode=viewprofile&u=2 Rob],
[http://www.hifi-remote.com/forums/profile.php?mode=viewprofile&u=1350 Vicky],
[http://www.hifi-remote.com/forums/profile.php?mode=viewprofile&u=13357 3FG],
[http://www.hifi-remote.com/forums/profile.php?mode=viewprofile&u=823 xnappo],
[http://www.hifi-remote.com/forums/profile.php?mode=viewprofile&u=343 mdavej].

Building the Arduino Interface for older remotes

2023-08-28T22:17:13Z

Davecs: /* Building the Arduino Interface for older remotes */

==Background==

When it was discovered that you could connect a computer to a UEI One For All remote that had 6 pins available inside the battery cover, it was possible to make a lead which connected via the printer port on your computer. As time went on, UEI changed the type of interface behind those six pins, which required a different interface. We called the original interface "JP1", because some of the remotes had that printed on the circuit board on which the 6 pins were mounted. The new interfaces were called JP1.1, JP1.2, and so on. We tend to call them JP1.x because although they are quite different from each other, they all work through the same USB interface. We've described that interface in this wiki. *[[JP1 Cables]]

As more and more printers used USB ports, computers came without the old printer port. This caused a problem for those of us trying to control the old JP1 interface. For a while, there was a dongle that sat between the FTDI cable and the old type JP1 remotes, but this is no longer available. The best way to connect your old JP1 remote to your computer is by making an interface based on the Arduino Nano. This method has been known for a long time, but I found the diagrams confusing and intimidating. Then someone posted a drawing on the forum which made it look much easier, so I had a go. And I was able to pull some very old remotes out of retirement!

==The drawing==

This is based on the drawing that was posted, with some alterations I made, in order to make it easier still!

[[Image:Arduino-wiring3.jpg]]

The Arduino Nano comes with a strip of pins matching the holes down each side, plus a 3x2 connector matching the 6 holes on the right-hand edge of the Nano as shown. They can be supplied soldered in or loose as part of the Nano. If they are soldered in, you have no soldering to do. If not, you can break off the pins you actually need. Break off two together, plus two singles. You can put a strip of pins through all the holes from D12 to TX1, and put the pair and one of the singles in A4, A5 and GND on the opposite side. This will enable the board to keep still while you put a small bit of solder on the pins to attach them. You can then connect the other pin to the GND on the other side in the same way.

The other thing you need is a pack of female-to-female Dupont-type jumper wires. They normally come in mixed colours in packs of 40. You may also be able to get hold of a 3x2 Dupont connector. They're cheap enough, but you often have to buy them in bulk. It's possible to superglue the single Dupont housings together to make a 3x2 connector. As my board came unsoldered, I used the 3x2 pin block to hold the single housings together while I glued them. You can do this if the pin block is soldered to the Arduino board, but be careful not to glue the connectors to the board!!

[[Image:IMG_20230826_155004_334_1.jpg|300px|thumb|left|Pins 2, 4 and 6]] [[Image:IMG_20230826_155015_490_1.jpg|400px|thumb|right|Pins 5, 3 and 1]]

You will need 5 wires from your pack of jumper wires. I used one each of White, Black, Blue, Green and Mauve. I put a tiny drop of superglue on the back of one end of the white wire, and stuck the back of the other end to it. Then carefully stuck the black and blue wires to that, finally sticking the mauve and green wires. The little exposed bits of metal on the sides are where you can clip and unclip the wires, so make sure they are on the outside. Alternately, if you have a 3x2 Dupont connector, you just unclip the wires from the single terminals and push them into the 3x2 connector. Whichever method you use, it should look like these pictures.

You can see where I have stuck a small piece of a label to mark the end with Pins 1&2.

Now the other ends of the wires can simply be pressed onto the pins on the board. Connect blue wire to A4, green to A5, and the mauve and black to the two GNDs (it doesn't matter which way round as they are connected internally on the Arduino Nano).

[[Image:IMG_20230828_180255_634.jpg|500px|thumb|center|Wires connected to Arduino board]]

=Uploading the Sketch file to the Arduino=

The Arduino project and its program are open-source, so is available free, but this does mean that there can be different builds. The sketch file you need to upload is in the RMIR folders when you download a new version and unzip it. The folder is JP1EEPROMSupport, subfolder JP1_Arduino, and the filename is JP1_Arduino.ino. The program, simply called "arduino", can be downloaded for Windows and Mac. For Linux users it may be in the repository of your distribution. On its menu bar, under Tools, you have to select the type of Arduino you are using. On one build I have, you have to select your board from a long list, the correct one being "Atmel atmega328p Xplained mini". On another build, there is a shorter list where you select "Arduino Nano", then separately select the processor "ATmega328P". There are two alternatives for this, but if you select the wrong one, the program just won't upload your sketch file and you can try the other one! Use the usual "File > Open" to open the sketch file, then the Right Arrow icon on the bar underneath the menus to upload your sketch. Your sketch will remain uploaded so this is a one-off.

I'm sure that by now you can't wait to get connected to your old JP1 remote so ... enjoy!

Building the Arduino Interface for older remotes

2023-08-28T22:16:50Z

Davecs: /* Background */

=Building the Arduino Interface for older remotes=

==Background==

When it was discovered that you could connect a computer to a UEI One For All remote that had 6 pins available inside the battery cover, it was possible to make a lead which connected via the printer port on your computer. As time went on, UEI changed the type of interface behind those six pins, which required a different interface. We called the original interface "JP1", because some of the remotes had that printed on the circuit board on which the 6 pins were mounted. The new interfaces were called JP1.1, JP1.2, and so on. We tend to call them JP1.x because although they are quite different from each other, they all work through the same USB interface. We've described that interface in this wiki. *[[JP1 Cables]]

As more and more printers used USB ports, computers came without the old printer port. This caused a problem for those of us trying to control the old JP1 interface. For a while, there was a dongle that sat between the FTDI cable and the old type JP1 remotes, but this is no longer available. The best way to connect your old JP1 remote to your computer is by making an interface based on the Arduino Nano. This method has been known for a long time, but I found the diagrams confusing and intimidating. Then someone posted a drawing on the forum which made it look much easier, so I had a go. And I was able to pull some very old remotes out of retirement!

==The drawing==

This is based on the drawing that was posted, with some alterations I made, in order to make it easier still!

[[Image:Arduino-wiring3.jpg]]

The Arduino Nano comes with a strip of pins matching the holes down each side, plus a 3x2 connector matching the 6 holes on the right-hand edge of the Nano as shown. They can be supplied soldered in or loose as part of the Nano. If they are soldered in, you have no soldering to do. If not, you can break off the pins you actually need. Break off two together, plus two singles. You can put a strip of pins through all the holes from D12 to TX1, and put the pair and one of the singles in A4, A5 and GND on the opposite side. This will enable the board to keep still while you put a small bit of solder on the pins to attach them. You can then connect the other pin to the GND on the other side in the same way.

The other thing you need is a pack of female-to-female Dupont-type jumper wires. They normally come in mixed colours in packs of 40. You may also be able to get hold of a 3x2 Dupont connector. They're cheap enough, but you often have to buy them in bulk. It's possible to superglue the single Dupont housings together to make a 3x2 connector. As my board came unsoldered, I used the 3x2 pin block to hold the single housings together while I glued them. You can do this if the pin block is soldered to the Arduino board, but be careful not to glue the connectors to the board!!

[[Image:IMG_20230826_155004_334_1.jpg|300px|thumb|left|Pins 2, 4 and 6]] [[Image:IMG_20230826_155015_490_1.jpg|400px|thumb|right|Pins 5, 3 and 1]]

You will need 5 wires from your pack of jumper wires. I used one each of White, Black, Blue, Green and Mauve. I put a tiny drop of superglue on the back of one end of the white wire, and stuck the back of the other end to it. Then carefully stuck the black and blue wires to that, finally sticking the mauve and green wires. The little exposed bits of metal on the sides are where you can clip and unclip the wires, so make sure they are on the outside. Alternately, if you have a 3x2 Dupont connector, you just unclip the wires from the single terminals and push them into the 3x2 connector. Whichever method you use, it should look like these pictures.

You can see where I have stuck a small piece of a label to mark the end with Pins 1&2.

Now the other ends of the wires can simply be pressed onto the pins on the board. Connect blue wire to A4, green to A5, and the mauve and black to the two GNDs (it doesn't matter which way round as they are connected internally on the Arduino Nano).

[[Image:IMG_20230828_180255_634.jpg|500px|thumb|center|Wires connected to Arduino board]]

=Uploading the Sketch file to the Arduino=

The Arduino project and its program are open-source, so is available free, but this does mean that there can be different builds. The sketch file you need to upload is in the RMIR folders when you download a new version and unzip it. The folder is JP1EEPROMSupport, subfolder JP1_Arduino, and the filename is JP1_Arduino.ino. The program, simply called "arduino", can be downloaded for Windows and Mac. For Linux users it may be in the repository of your distribution. On its menu bar, under Tools, you have to select the type of Arduino you are using. On one build I have, you have to select your board from a long list, the correct one being "Atmel atmega328p Xplained mini". On another build, there is a shorter list where you select "Arduino Nano", then separately select the processor "ATmega328P". There are two alternatives for this, but if you select the wrong one, the program just won't upload your sketch file and you can try the other one! Use the usual "File > Open" to open the sketch file, then the Right Arrow icon on the bar underneath the menus to upload your sketch. Your sketch will remain uploaded so this is a one-off.

I'm sure that by now you can't wait to get connected to your old JP1 remote so ... enjoy!

JP1 Cables

2023-08-28T22:14:02Z

Davecs: /* JP1 (EEPROM) Drivers */

'''JP1 Interfaces''' 

==Introduction==
In order to use the JP1 software to program your remote, you need an interface to connect the remote to your computer, for which several models now include a USB lead as original equipment. Otherwise you can build your own or purchase one from any one of several vendors. The first JP1 remotes had the same interface. But over the years, new types of JP1 remotes have been introduced which require different interfaces, the latest being USB. 

Lists of JP1 remotes and the type of interface each requires can be found at http://www.hifi-remote.com/wiki/index.php?title=RemoteChart 
- and the technical details with a brief history of JP1 interface designs at http://www.hifi-remote.com/forums/dload.php?action=download&file_id=5204

==Interface Types==
UEI is the maker of all JP1 remotes. They change the way they build remotes every so often such that they require a different type of interface. There are currently two basic types of JP1 interfaces: JP1 (Flash) and JP1 (EEPROM). Their older remotes had a separate MCU chip and an EEPROM chip, with all the JP1 activity occurring on the EEPROM chip, so it didn't matter what brand and model of MCU they used because the access to the EEPROM was the same. These remotes are called JP1 or "JP1 (EEPROM)"

Then they switched to using flash based MCU chips, which meant it was no longer necessary to have a separate EEPROM chip. The protocol needed to access the flash chip is completely different to that needed to access the old EEPROM chips. Furthermore, the access method sometimes changes when they switch from one brand of flash chip to another. All these flash based JP1 remotes are called "JP1 (Flash)" (also JP1.x, JP1.1, JP1.2, JP1.1/2, JP1.2/3 or JP1.3). Below are the different types of JP1 remotes, where the type is indicated on the circuit board beside the JP1 connector. However in some cases the connector may be mislabeled.

JP1 indicates a remote with an EEPROM chip. (random signatures) 
JP1.1 indicates a remote with an SST brand flash chip. (CS30xxxx alpha-numeric signatures, only used in 4 Comcast remotes) 
JP1.2 indicates a remote with a Motorola HCS08 flash chip. (1xxx1xxx numeric signatures) 
JP1.3 indicates a remote with a Samsung S3F8 flash chip. (3xxx3xxx numeric signatures) 
JP1.4 indicates a remote with a Samsung S3F8 flash chip.* (3xxxxx numeric signatures) 
JP2 indicates a remote with a Maxim MAXQ622 flash chip.* (2xxxxx numeric signatures) 
JP2 also indicates a remote with a Texas Instruments TI2541 flash chip.* (6xxxxx numeric signatures) 
Mini-USB or Micro-USB indicates a remote which is supplied with a USB cable. 

* JP1.4 and JP2 remotes use a "segment" memory structure, which is completely different that all previous remotes.

Some JP1 (Flash) cables will work with both JP1.1 and JP1.2, but NOT JP1.3, these are usually called JP1.1/2 (Flash) cables.

Some JP1 (Flash) cables will work with both JP1.2 and JP1.3, but NOT JP1.1, these are usually called JP1.2/3 (Flash) cables.

If you have a JP1 (Flash) cable, you can use a special [https://www.diygadget.com/remote-control-accessories/jp1-2-1-3-to-jp1-adapter "JP1 EEPROM Programming Adapter"] to program a JP1 (EEPROM) remote. There are many advantages to this approach since JP1 (Flash) interfaces are compatible with the latest operating systems and I/O ports, and the old style JP1 cables are no longer available.

Some remotes have additional constraints related to the JP1 pins that require special consideration. The Radio Shack 15-133, 134 and 135 models have a smaller opening that the standard plug will not fit. In this case, you can remove the outer clip from the connector and reinforce with super glue, or purchase a cable with a smaller connector or an an adapter with a smaller connector. Some models are JP1 compatible but not "JP1 Ready", having no pins, but pads where the pins should be. In this case an adapter with pogo pins (spring loaded pins for making good contact with the pads) can be used. The connector is held against the pins when communicating with the remote. Some models have no pads at all, so a connector must be soldered to various points on the circuit board, like on the Radio Shack 15-100. Some models, like the URC-6131, require both an EEPROM chip and a connector to be soldered in.

==FTDI and Prolific cables on eBay==
There are many cables on eBay which will function as JP1.x cables. In order for the cable to work, it must have 6 connectors, there are many cables out there with only 4 connectors, these won't work because the RTS line is not exposed. These cables either come with 6 individual connectors, or one flat 1*6 connector. In order to make these ideal JP1.x cables, the supplied connectors should be replaced with a 2*3 DuPont connector. However, the cables with 6 individual connectors will work, it's just a lot more fiddly to connect them to your remote.

Two types of cable that are known to work are the FTDI FT232RL and the Prolific PL2303HXD.

[[Image:FTDI cable.jpg]] [[Image:Prolific cable.jpg]] 

===Cable color codes===
The pin codes for these cable are (NOTE: colors can vary in different cables):

'''pin - color - type'''
:1 - (empty):VDD
:2 - RTS (usually Yellow)
:3 - GND (usually Black)
:4 - TXD (usually Green)
:5 - (empty)
:6 - RXD (usually White)
:''CTS (usually Blue, not connected)''
:''5V (usually Red, not connected)''

For remotes with a 5-hole connector (like the URC-2025): 
'''[NOTE: remove the batteries while using RMIR]'''
:1 - RTS (usually Yellow)
:2 - (empty)
:3 - GND (usually Black)
:4 - TXD (usually Green)
:5 - RXD (usually White)

If you need to make it work with older EEPROM based JP1 remotes, you'll need a DIY Gadget JP1 EEPROM programming adapter $10 (+ $4 shipping): 
https://www.diygadget.com/remote-control-accessories/jp1-2-1-3-to-jp1-adapter

These adapters usually do not have pin1 marked. To find pin1, feel the adapter over the heat shrink tubing and you'll notice that one side is flat whereas you can feel the components on the other side. Looking at the flat side, pin1 is marked with white dots in this photo:

[[Image:JP1 Adapter.jpg]] 

If you want a 6-pin DuPont plug for the end, click here (select 2x3P): 
* https://www.ebay.com/itm/263051820184 (qty=40)
* https://www.ebay.com/itm/263051796913 (variable qty, from 20 to 500)

To remove the existing DuPont connector, use a blade and pop up the plastic tab over each connector and then pull the wire out. With the new connector, just slide each wire into the appropriate slot, with the connector tab facing up so that it pops out of the little window.

The following pic shows how the pins are numbered for the 6-pin connector in the remote itself:

[[Image:JP1 pins.jpg]] [[Image:JP1 6pin.jpg]] 

This video shows you how to connect the cable: 
https://www.youtube.com/watch?v=cLYzsh-usTo

See this for other cheap cable sources: 
http://hifi-remote.com/forums/viewtopic.php?t=16200

==Interface Designs==
There are many different interface designs. JP1 (EEPROM) interfaces include the "Simple" design which connects to your PC's parallel printer port and a USB design. JP1 (Flash) interfaces include two serial designs (one with discrete transistors and another with an IC), as well as a USB design. The serial interfaces are compatible with serial ports and with USB to Serial adapters. The parallel interfaces are compatible with parallel ports and parallel PCI or PCMCIA adapters. They are not compatible with USB to parallel printer adapters. Below are several interface design and troubleshooting documents.

EEPROM Interfaces: http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=49 
Flash Interfaces: http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=121 

==Interface Vendors==
JP1 is a hacker project. Most JP1 interfaces are hand made. You won't find a JP1 interface at any retailer. However, there are now some generic USB-Serial interfaces available on ebay that will work for JP1.1 and above. Since the hand made interfaces aren't mass produced, there are no economies of scale. So the interface can more than the remote. But this is still a great value since a JP1 remote with its interface cable and software becomes as functional as remotes costing 10 times as much. Below is a list of JP1 interface vendors.

[http://www.hifi-remote.com/forums/viewtopic.php?t=9405 Tommy Tyler] 
[http://www.diygadget.com/jp1-1-1-1-2-1-3-cables.html DIY Gadget] 
[http://www.txsat.net/ TX SAT Electronics] 
[http://www.hifi-remote.com/forums/viewtopic.php?t=16360 Generic FTDI USB-Serial (cheapest option)] 

==Interface Drivers==
The drivers for JP1 (Flash) interfaces are built in to the latest Windows OSs. They use a chip from FTDI. Drivers for JP1 (EEPROM) USB interfaces are supplied by Delcom, the maker of the chip in these interfaces. The Delcom drivers can be problematic and do not work with the latest 64-bit Windows OSs. There are several versions available with which users have varying degrees of success. There is also a generic WinUSB driver for JP1 (EEPROM) USB interfaces which is compatible with modern OSs. JP1 (EEPROM) parallel interfaces do not require a driver.

===JP1 (EEPROM) Drivers===

*http://www.hifi-remote.com/wiki/index.php?title=Building_the_Arduino_Interface_for_older_remotes

*http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=81
*http://www.delcomproducts.com/productdetails.asp?PartNumber=890520

===JP1 (Flash) Drivers===
*http://www.ftdichip.com/Drivers/D2XX.htm 

===PDF Using Legacy Interfaces on Windows 10 ===
*http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25588

===Prolific Drivers on Windows 10 ===
JP1 (Flash) interface cables using a non-genuine Prolific chip will be automatically disabled by default in Windows 10. To work around this issue, install the alternate driver below which bypasses the genuine hardware check, and prevent the genuine driver from reinstalling by following the steps below:
:1. Download the alternate Prolific Windows 10 driver:
::*http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25608
:2. Download the "Show or Hide Updates" troubleshooter tool from Microsoft or mirror copy:
::*https://support.microsoft.com/en-us/topic/how-to-temporarily-prevent-a-driver-update-from-reinstalling-in-windows-10-17df0ef3-7480-36e9-0ed9-118351398897
::*http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26315
:3. Plug in interface cable.
:4. In device manager, locate non-genuine Prolific device under Ports, Right-click and uninstall current driver.
:5. Leave cable plugged in and run the PL2303_64bit_Installer downloaded in step 1.
:6. Click "Continue" when prompted.
:7. Reboot when prompted, leaving cable plugged in.
:8. Run the troubleshooter downloaded in step 2 (wushowhide tool).
:9. Click "Hide" and choose the genuine Prolific driver, then click next (Windows reports problem is "fixed" and hides the driver).

Building the Arduino Interface for older remotes

2023-08-28T22:11:22Z

Davecs: Created page with "=Building the Arduino Interface for older remotes= ==Background== When it was discovered that you could connect a computer to a UEI One For All remote that had 6 pins availa..."

=Building the Arduino Interface for older remotes=

==Background==

When it was discovered that you could connect a computer to a UEI One For All remote that had 6 pins available inside the battery cover, it was possible to make a lead which connected via the printer port on your computer. As time went on, UEI changed the type of interface behind those six pins, which required a different interface. We called the original interface "JP1", because some of the remotes had that printed on the circuit board on which the 6 pins were mounted. The new interfaces were called JP1.1, JP1.2, and so on. We tend to call them JP1.x because although they are quite different from each other, they all work through the same USB interface. We've described that interface in this wiki. [http://www.hifi-remote.com/wiki/index.php/JP1_Cables#FTDI_and_Prolific_cables_on_eBay]

As more and more printers used USB ports, computers came without the old printer port. This caused a problem for those of us trying to control the old JP1 interface. For a while, there was a dongle that sat between the FTDI cable and the old type JP1 remotes, but this is no longer available. The best way to connect your old JP1 remote to your computer is by making an interface based on the Arduino Nano. This method has been known for a long time, but I found the diagrams confusing and intimidating. Then someone posted a drawing on the forum which made it look much easier, so I had a go. And I was able to pull some very old remotes out of retirement!

==The drawing==

This is based on the drawing that was posted, with some alterations I made, in order to make it easier still!

[[Image:Arduino-wiring3.jpg]]

The Arduino Nano comes with a strip of pins matching the holes down each side, plus a 3x2 connector matching the 6 holes on the right-hand edge of the Nano as shown. They can be supplied soldered in or loose as part of the Nano. If they are soldered in, you have no soldering to do. If not, you can break off the pins you actually need. Break off two together, plus two singles. You can put a strip of pins through all the holes from D12 to TX1, and put the pair and one of the singles in A4, A5 and GND on the opposite side. This will enable the board to keep still while you put a small bit of solder on the pins to attach them. You can then connect the other pin to the GND on the other side in the same way.

The other thing you need is a pack of female-to-female Dupont-type jumper wires. They normally come in mixed colours in packs of 40. You may also be able to get hold of a 3x2 Dupont connector. They're cheap enough, but you often have to buy them in bulk. It's possible to superglue the single Dupont housings together to make a 3x2 connector. As my board came unsoldered, I used the 3x2 pin block to hold the single housings together while I glued them. You can do this if the pin block is soldered to the Arduino board, but be careful not to glue the connectors to the board!!

[[Image:IMG_20230826_155004_334_1.jpg|300px|thumb|left|Pins 2, 4 and 6]] [[Image:IMG_20230826_155015_490_1.jpg|400px|thumb|right|Pins 5, 3 and 1]]

You will need 5 wires from your pack of jumper wires. I used one each of White, Black, Blue, Green and Mauve. I put a tiny drop of superglue on the back of one end of the white wire, and stuck the back of the other end to it. Then carefully stuck the black and blue wires to that, finally sticking the mauve and green wires. The little exposed bits of metal on the sides are where you can clip and unclip the wires, so make sure they are on the outside. Alternately, if you have a 3x2 Dupont connector, you just unclip the wires from the single terminals and push them into the 3x2 connector. Whichever method you use, it should look like these pictures.

You can see where I have stuck a small piece of a label to mark the end with Pins 1&2.

Now the other ends of the wires can simply be pressed onto the pins on the board. Connect blue wire to A4, green to A5, and the mauve and black to the two GNDs (it doesn't matter which way round as they are connected internally on the Arduino Nano).

[[Image:IMG_20230828_180255_634.jpg|500px|thumb|center|Wires connected to Arduino board]]

=Uploading the Sketch file to the Arduino=

The Arduino project and its program are open-source, so is available free, but this does mean that there can be different builds. The sketch file you need to upload is in the RMIR folders when you download a new version and unzip it. The folder is JP1EEPROMSupport, subfolder JP1_Arduino, and the filename is JP1_Arduino.ino. The program, simply called "arduino", can be downloaded for Windows and Mac. For Linux users it may be in the repository of your distribution. On its menu bar, under Tools, you have to select the type of Arduino you are using. On one build I have, you have to select your board from a long list, the correct one being "Atmel atmega328p Xplained mini". On another build, there is a shorter list where you select "Arduino Nano", then separately select the processor "ATmega328P". There are two alternatives for this, but if you select the wrong one, the program just won't upload your sketch file and you can try the other one! Use the usual "File > Open" to open the sketch file, then the Right Arrow icon on the bar underneath the menus to upload your sketch. Your sketch will remain uploaded so this is a one-off.

I'm sure that by now you can't wait to get connected to your old JP1 remote so ... enjoy!

File:IMG 20230828 180255 634.jpg

2023-08-28T21:39:33Z

Davecs: Photo of Arduino Board with wires attached.

Photo of Arduino Board with wires attached.

File:IMG 20230826 155015 490 1.jpg

2023-08-28T21:25:58Z

Davecs: Dupont 3x2 connector from odd pin side

Dupont 3x2 connector from odd pin side

File:IMG 20230826 155004 334 1.jpg

2023-08-28T21:24:04Z

Davecs: 3x2 connector from Even Pin side.

3x2 connector from Even Pin side.

File:Arduino-wiring3.jpg

2023-08-28T20:44:49Z

Davecs: Diagram of connection layout for Arduino interface.

Diagram of connection layout for Arduino interface.

The 3660 family

2023-08-15T19:32:17Z

Davecs: /* Multi Macros ("Channel Shortcut Macros") */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' (USA), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart, USA) and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT8D21]''' (Best Buy, USA). There is also the Insignia NS-RMT5D21 which has only four device buttons but also limited access to an Audio device. The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8". In addition, the NS-RMT5D21's two further missing device buttons are labelled "AUDIO" and "Dev7". There is also a missing Activity button on this one, referred to as "button5". You can access the devices without a button by putting Dev4/Dev8 (or AUDIO/Dev7) in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 cable which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 cable.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

Another example is the Power key. You can use a short press to send the normal Power function to a device. A long press can be used to run a macro which will switch off the device and also other devices needed to use that device. For example, the BluRay player would have a macro on the long press to switch off the player, the TV and also the amplifier.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. With "AV Shift", pressing the AV/Input key brings up a TV menu to change the input, and for 10 seconds, the Arrow Keys and OK operate the TV. However, on some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the arrow keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s still possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. "Power Macro" sends the Power signal to every device involved in the current Activity, but using standard Power keys on the remote which will be toggles. Sometimes the toggles get out of sync, and it’s possible to write your own (device specific) macros for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. ''NOTE: This feature is available from version 3.0.0, released on 13 June 2023''. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Macros==

The manual doesn't even mention ordinary macros! With RMIR and your JP1 cable, you can put an ordinary macro on any button except the device buttons. It can be global or device specific. For example, the power button, under the BluRay device, can have a macro that switches off the BluRay player, the amplifier and the TV. Remember earlier that they were all switched on by pressing the "Watch Movie" button.

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

=User Manuals=
Here are the original user manuals for this family of remotes:
* [https://www.oneforall.com/sites/default/files/2022-09/713142_7T_1_3_URC3661_ESSENTIAL_6_Antimicrobial_RDN1291121-gec.pdf One For All URC-3661]
* [https://www.oneforall.com/sites/default/files/2021-11/712836_essential8_manual_urc3680_rdn1100920_incl._codelist.pdf One For All URC-3680]
* [https://www.datocms-assets.com/44652/1621517371-onn6engmanual-rdn1010321fczpfinal.pdf Onn URC-3660] ([https://manuals.plus/m/86233d842fdbaf1b3b3a2771419d82039f309911a91763ff5e43a566a7680ac1 setup codes])
* [https://files.bbystatic.com/Wwm5sSNR5p7n7UGIrSgg2g%3D%3D/User%2BGuide Insignia NS-RMT5D21] ([https://files.bbystatic.com/COLuTZC9IL3IWnzmkWzfgg%3D%3D/Codes%2BManual setup codes])

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-07T21:01:40Z

Davecs: /* systemd */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

===Mounting===

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

After a reboot, your remote will be mounted automatically whenever it is plugged in (but see next section re systemd). RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit one or two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf''' but don't do anything if it's not there.

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager (create folder REMOTE inside /mnt) or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-07T21:01:01Z

Davecs: /* systemd */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

===Mounting===

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

After a reboot, your remote will be mounted automatically whenever it is plugged in (but see next section re systemd). RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf''' but don't do anything if it's not there.

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager (create folder REMOTE inside /mnt) or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-07T20:59:54Z

Davecs: /* Mounting */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

===Mounting===

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

After a reboot, your remote will be mounted automatically whenever it is plugged in (but see next section re systemd). RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager (create folder REMOTE inside /mnt) or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-07T20:59:24Z

Davecs: /* Mounting */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

===Mounting===

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

After a reboot, your remote will be mounted automatically (but see next section re systemd). RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager (create folder REMOTE inside /mnt) or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-07T20:58:03Z

Davecs: /* Mounting */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

===Mounting===

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

After a reboot, RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager (create folder REMOTE inside /mnt) or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-06T12:59:34Z

Davecs: /* Manual Method */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

===Mounting===

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager (create folder REMOTE inside /mnt) or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-03T19:00:18Z

Davecs: /* Automatic Method */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

===Mounting===

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-03T15:43:46Z

Davecs: /* Automatic Method */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-03T15:26:11Z

Davecs: Major change, remote One User At a Time method, substitute Manual Method.

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=Manual Method=

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager or in a terminal:

sudo mkdir /mnt/REMOTE

su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports '''sudo''' or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-03T14:53:54Z

Davecs: /* systemd */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-03T14:52:56Z

Davecs: /* systemd */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) called '''systemd-udevd.service'''. As root, you need to copy it to the folder /etc/systemd/system and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-03T14:52:31Z

Davecs: /* systemd */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called /usr/lib/systemd/system/ (or /lib/systemd/system/ — due to symlinks, it's often the same folder) called '''systemd-udevd.service'''. As root, you need to copy it to the folder /etc/systemd/system and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-02T14:27:16Z

Davecs: /* Unmounting */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a file the folder /usr/lib/systemd/system/ (or /lib/systemd/system/ — due to symlinks, it's often the same folder) called '''systemd-udevd.service'''. As root, you need to copy it to the folder /etc/systemd/system and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-07-02T14:24:10Z

Davecs: /* Any User Method */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Automatic Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===systemd===

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a file the folder /usr/lib/systemd/system/ (or /lib/systemd/system/ — due to symlinks, it's often the same folder) called '''systemd-udevd.service'''. As root, you need to copy it to the folder /etc/systemd/system and then edit two lines in it as follows:

1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf'''

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-06-29T13:35:16Z

Davecs: /* Any User Method */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Any User Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-06-29T12:52:31Z

Davecs:

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Any User Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-06-28T14:45:02Z

Davecs: /* Any User Method */

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. This is because the file system on these two remotes does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Any User Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-06-28T14:44:06Z

Davecs:

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. This is because the file system on these two remotes does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.

=Any User Method=

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

===Unmounting===

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

=One User at a Time Method (Deprecated)=

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-06-28T12:30:14Z

Davecs: /* Any User Method */

When you connect a JP1.x type remote to a Linux computer, running RMIR, all should be well. If RMIR can't find your remote, it may well be a permissions problem. This is currently being investigated and any updates will be posted to this page. If all else fails, you might have to set up RMIR so that it runs as root.

However, when you connect a USB remote to your computer, it connects by creating a "device" that you can mount. In many cases it will mount automatically, and the RMIR program will find it automatically. There are special instructions with your RMIR download for dealing with XSight and Nevo remotes, and you should follow those. In other cases, it may not mount. This seems to be a problem with the OARUSB04G or URC-6440, when using recent releases of Linux. This is because the file system on these two remotes does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" shortcut that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That shortcut is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's not very short for a shortcut, but it will always be the same, so we can make use of it in the '''mount''' command.

==Any User Method==

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

==One User at a Time Method (Deprecated)==

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-06-27T19:24:22Z

Davecs: /* One User at a Time Method */

When you connect a JP1.x type remote to a Linux computer, running RMIR, all should be well. If RMIR can't find your remote, it may well be a permissions problem. This is currently being investigated and any updates will be posted to this page. If all else fails, you might have to set up RMIR so that it runs as root.

However, when you connect a USB remote to your computer, it connects by creating a "device" that you can mount. In many cases it will mount automatically, and the RMIR program will find it automatically. There are special instructions with your RMIR download for dealing with XSight and Nevo remotes, and you should follow those. In other cases, it may not mount. This seems to be a problem with the OARUSB04G or URC-6440, when using recent releases of Linux. This is because the file system on these two remotes does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" shortcut that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That shortcut is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's not very short for a shortcut, but it will always be the same, so we can make use of it in the '''mount''' command.

==Any User Method==

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

==One User at a Time Method (Deprecated)==

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-06-27T18:12:32Z

Davecs: /* Any User Method */

When you connect a JP1.x type remote to a Linux computer, running RMIR, all should be well. If RMIR can't find your remote, it may well be a permissions problem. This is currently being investigated and any updates will be posted to this page. If all else fails, you might have to set up RMIR so that it runs as root.

However, when you connect a USB remote to your computer, it connects by creating a "device" that you can mount. In many cases it will mount automatically, and the RMIR program will find it automatically. There are special instructions with your RMIR download for dealing with XSight and Nevo remotes, and you should follow those. In other cases, it may not mount. This seems to be a problem with the OARUSB04G or URC-6440, when using recent releases of Linux. This is because the file system on these two remotes does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" shortcut that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That shortcut is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's not very short for a shortcut, but it will always be the same, so we can make use of it in the '''mount''' command.

==Any User Method==

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

==One User at a Time Method==

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

Using URC6440 and OARUSB04G Remotes with Linux

2023-06-27T17:52:19Z

Davecs: Major update with "All user" method of mounting the remote.

When you connect a JP1.x type remote to a Linux computer, running RMIR, all should be well. If RMIR can't find your remote, it may well be a permissions problem. This is currently being investigated and any updates will be posted to this page. If all else fails, you might have to set up RMIR so that it runs as root.

However, when you connect a USB remote to your computer, it connects by creating a "device" that you can mount. In many cases it will mount automatically, and the RMIR program will find it automatically. There are special instructions with your RMIR download for dealing with XSight and Nevo remotes, and you should follow those. In other cases, it may not mount. This seems to be a problem with the OARUSB04G or URC-6440, when using recent releases of Linux. This is because the file system on these two remotes does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" shortcut that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That shortcut is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''

It's not very short for a shortcut, but it will always be the same, so we can make use of it in the '''mount''' command.

==Any User Method==

Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing that it was so simple to do once I got the information I needed.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!

==One User at a Time Method==

This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.

The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.

Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:

#!/bin/bash
/usr/local/bin/mount_ofa &

This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:

#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137

NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.

An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:

hisname=`who | awk '/tty[17]/ {print $1;}'`

For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.

Set up RemoteMasterIR to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin

Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.

The 3660 family

2023-06-14T19:22:01Z

Davecs: /* About this family of remotes */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' (USA), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart, USA) and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT8D21]''' (Best Buy, USA). There is also the Insignia NS-RMT5D21 which has only four device buttons but also limited access to an Audio device. The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8". In addition, the NS-RMT5D21's two further missing device buttons are labelled "AUDIO" and "Dev7". There is also a missing Activity button on this one, referred to as "button5". You can access the devices without a button by putting Dev4/Dev8 (or AUDIO/Dev7) in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 cable which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 cable.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. With "AV Shift", pressing the AV/Input key brings up a TV menu to change the input, and for 10 seconds, the Arrow Keys and OK operate the TV. However, on some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the arrow keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s still possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. "Power Macro" sends the Power signal to every device involved in the current Activity, but using standard Power keys on the remote which will be toggles. Sometimes the toggles get out of sync, and it’s possible to write your own (device specific) macros for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. ''NOTE: This feature is available from version 3.0.0, released on 13 June 2023''. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Macros==

The manual doesn't even mention ordinary macros! With RMIR and your JP1 cable, you can put an ordinary macro on any button except the device buttons. It can be global or device specific. For example, the power button, under the BluRay device, can have a macro that switches off the BluRay player, the amplifier and the TV. Remember earlier that they were all switched on by pressing the "Watch Movie" button.

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

=User Manuals=
Here are the original user manuals for this family of remotes:
* [https://www.oneforall.com/sites/default/files/2022-09/713142_7T_1_3_URC3661_ESSENTIAL_6_Antimicrobial_RDN1291121-gec.pdf One For All URC-3661]
* [https://www.oneforall.com/sites/default/files/2021-11/712836_essential8_manual_urc3680_rdn1100920_incl._codelist.pdf One For All URC-3680]
* [https://www.datocms-assets.com/44652/1621517371-onn6engmanual-rdn1010321fczpfinal.pdf Onn URC-3660] ([https://manuals.plus/m/86233d842fdbaf1b3b3a2771419d82039f309911a91763ff5e43a566a7680ac1 setup codes])
* [https://files.bbystatic.com/Wwm5sSNR5p7n7UGIrSgg2g%3D%3D/User%2BGuide Insignia NS-RMT5D21] ([https://files.bbystatic.com/COLuTZC9IL3IWnzmkWzfgg%3D%3D/Codes%2BManual setup codes])

The 3660 family

2023-06-13T15:43:53Z

Davecs: /* Activities */ — Notifying availability of RMIRv3 needed for repurposing the Activity buttons.

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' (USA), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart, USA) and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (Best Buy, USA). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 cable which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 cable.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. With "AV Shift", pressing the AV/Input key brings up a TV menu to change the input, and for 10 seconds, the Arrow Keys and OK operate the TV. However, on some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the arrow keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s still possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. "Power Macro" sends the Power signal to every device involved in the current Activity, but using standard Power keys on the remote which will be toggles. Sometimes the toggles get out of sync, and it’s possible to write your own (device specific) macros for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. ''NOTE: This feature is available from version 3.0.0, released on 13 June 2023''. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Macros==

The manual doesn't even mention ordinary macros! With RMIR and your JP1 cable, you can put an ordinary macro on any button except the device buttons. It can be global or device specific. For example, the power button, under the BluRay device, can have a macro that switches off the BluRay player, the amplifier and the TV. Remember earlier that they were all switched on by pressing the "Watch Movie" button.

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

=User Manuals=
Here are the original user manuals for this family of remotes:
* [https://www.oneforall.com/sites/default/files/2022-09/713142_7T_1_3_URC3661_ESSENTIAL_6_Antimicrobial_RDN1291121-gec.pdf One For All URC-3661]
* [https://www.oneforall.com/sites/default/files/2021-11/712836_essential8_manual_urc3680_rdn1100920_incl._codelist.pdf One For All URC-3680]
* [https://www.datocms-assets.com/44652/1621517371-onn6engmanual-rdn1010321fczpfinal.pdf Onn URC-3660] ([https://manuals.plus/m/86233d842fdbaf1b3b3a2771419d82039f309911a91763ff5e43a566a7680ac1 setup codes])
* [https://files.bbystatic.com/Wwm5sSNR5p7n7UGIrSgg2g%3D%3D/User%2BGuide Insignia NS-RMT5D21] ([https://files.bbystatic.com/COLuTZC9IL3IWnzmkWzfgg%3D%3D/Codes%2BManual setup codes])

The 3660 family

2023-06-13T12:50:03Z

Davecs: /* Activities */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' (USA), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart, USA) and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (Best Buy, USA). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 cable which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 cable.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. With "AV Shift", pressing the AV/Input key brings up a TV menu to change the input, and for 10 seconds, the Arrow Keys and OK operate the TV. However, on some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the arrow keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s still possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. "Power Macro" sends the Power signal to every device involved in the current Activity, but using standard Power keys on the remote which will be toggles. Sometimes the toggles get out of sync, and it’s possible to write your own (device specific) macros for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. ''NOTE: This feature was added in version 2.15.x which is still in development''. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Macros==

The manual doesn't even mention ordinary macros! With RMIR and your JP1 cable, you can put an ordinary macro on any button except the device buttons. It can be global or device specific. For example, the power button, under the BluRay device, can have a macro that switches off the BluRay player, the amplifier and the TV. Remember earlier that they were all switched on by pressing the "Watch Movie" button.

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

=User Manuals=
Here are the original user manuals for this family of remotes:
* [https://www.oneforall.com/sites/default/files/2022-09/713142_7T_1_3_URC3661_ESSENTIAL_6_Antimicrobial_RDN1291121-gec.pdf One For All URC-3661]
* [https://www.oneforall.com/sites/default/files/2021-11/712836_essential8_manual_urc3680_rdn1100920_incl._codelist.pdf One For All URC-3680]
* [https://www.datocms-assets.com/44652/1621517371-onn6engmanual-rdn1010321fczpfinal.pdf Onn URC-3660] ([https://manuals.plus/m/86233d842fdbaf1b3b3a2771419d82039f309911a91763ff5e43a566a7680ac1 setup codes])
* [https://files.bbystatic.com/Wwm5sSNR5p7n7UGIrSgg2g%3D%3D/User%2BGuide Insignia NS-RMT5D21] ([https://files.bbystatic.com/COLuTZC9IL3IWnzmkWzfgg%3D%3D/Codes%2BManual setup codes])

Using URC6440 and OARUSB04G Remotes with Linux

2023-05-30T18:04:26Z

Davecs: Some distros allocate desktops at tty8

The 3660 family

2023-05-14T20:13:54Z

Davecs: /* More Features */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' (USA), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart, USA) and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (Best Buy, USA). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. With "AV Shift", pressing the AV/Input key brings up a TV menu to change the input, and for 10 seconds, the Arrow Keys and OK operate the TV. However, on some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the arrow keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s still possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. "Power Macro" sends the Power signal to every device involved in the current Activity, but using standard Power keys on the remote which will be toggles. Sometimes the toggles get out of sync, and it’s possible to write your own (device specific) macros for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. ''NOTE: This feature was added in version 2.15.x''. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Macros==

The manual doesn't even mention ordinary macros! With RMIR and your JP1 lead, you can put an ordinary macro on any button except the device buttons. It can be global or device specific. For example, the power button, under the BluRay device, can have a macro that switches off the BluRay player, the amplifier and the TV. Remember earlier that they were all switched on by pressing the "Watch Movie" button.

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

=User Manuals=
Here are the original user manuals for this family of remotes:
* [https://www.oneforall.com/sites/default/files/2022-09/713142_7T_1_3_URC3661_ESSENTIAL_6_Antimicrobial_RDN1291121-gec.pdf One For All URC-3661]
* [https://www.oneforall.com/sites/default/files/2021-11/712836_essential8_manual_urc3680_rdn1100920_incl._codelist.pdf One For All URC-3680]
* [https://www.datocms-assets.com/44652/1621517371-onn6engmanual-rdn1010321fczpfinal.pdf Onn URC-3660] ([https://manuals.plus/m/86233d842fdbaf1b3b3a2771419d82039f309911a91763ff5e43a566a7680ac1 setup codes])
* [https://files.bbystatic.com/Wwm5sSNR5p7n7UGIrSgg2g%3D%3D/User%2BGuide Insignia NS-RMT5D21] ([https://files.bbystatic.com/COLuTZC9IL3IWnzmkWzfgg%3D%3D/Codes%2BManual setup codes])

The 3660 family

2023-05-14T16:47:29Z

Davecs: /* Activities */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' (USA), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart, USA) and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (Best Buy, USA). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. With "AV Shift", pressing the AV/Input key brings up a TV menu to change the input, and for 10 seconds, the Arrow Keys and OK operate the TV. However, on some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the arrow keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s still possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. "Power Macro" sends the Power signal to every device involved in the current Activity, but using standard Power keys on the remote which will be toggles. Sometimes the toggles get out of sync, and it’s possible to write your own (device specific) macros for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. ''NOTE: This feature was added in version 2.15.x''. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

=User Manuals=
Here are the original user manuals for this family of remotes:
* [https://www.oneforall.com/sites/default/files/2022-09/713142_7T_1_3_URC3661_ESSENTIAL_6_Antimicrobial_RDN1291121-gec.pdf One For All URC-3661]
* [https://www.oneforall.com/sites/default/files/2021-11/712836_essential8_manual_urc3680_rdn1100920_incl._codelist.pdf One For All URC-3680]
* [https://www.datocms-assets.com/44652/1621517371-onn6engmanual-rdn1010321fczpfinal.pdf Onn URC-3660] ([https://manuals.plus/m/86233d842fdbaf1b3b3a2771419d82039f309911a91763ff5e43a566a7680ac1 setup codes])
* [https://files.bbystatic.com/Wwm5sSNR5p7n7UGIrSgg2g%3D%3D/User%2BGuide Insignia NS-RMT5D21] ([https://files.bbystatic.com/COLuTZC9IL3IWnzmkWzfgg%3D%3D/Codes%2BManual setup codes])

The 3660 family

2023-05-08T23:20:18Z

Davecs: /* Activities */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (America). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. With "AV Shift", pressing the AV/Input key brings up a TV menu to change the input, and for 10 seconds, the Arrow Keys and OK operate the TV. However, on some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the arrow keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s still possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. "Power Macro" sends the Power signal to every device involved in the current Activity, but using standard Power keys on the remote which will be toggles. Sometimes the toggles get out of sync, and it’s possible to write your own (device specific) macros for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

The 3660 family

2023-05-08T23:11:40Z

Davecs: /* Multi Macros ("Channel Shortcut Macros") */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (America). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), the Rewind/FastFwd keys, nor the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. On some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the direction keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. Also for "Power Macro", the standard Power keys on the remote will be toggles, but it’s possible to write your own (device specific) macro for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

The 3660 family

2023-05-08T23:00:43Z

Davecs: /* About this family of remotes */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.walmart.com/ip/747238608 Onn URC-3660]'''(Walmart), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''' and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (America). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), or the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. On some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the direction keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. Also for "Power Macro", the standard Power keys on the remote will be toggles, but it’s possible to write your own (device specific) macro for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

The 3660 family

2023-05-08T21:08:35Z

Davecs: /* Fast Forward, Rewind and Skip */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''', '''[https://www.walmart.com/ip/747238608 Onn URC-3660]''', and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (America). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), or the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. On some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the direction keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. Also for "Power Macro", the standard Power keys on the remote will be toggles, but it’s possible to write your own (device specific) macro for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design your own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

The 3660 family

2023-05-08T20:56:22Z

Davecs: /* About this family of remotes */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''', '''[https://www.walmart.com/ip/747238608 Onn URC-3660]''', and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (America). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), or the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. On some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the direction keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. Also for "Power Macro", the standard Power keys on the remote will be toggles, but it’s possible to write your own (device specific) macro for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design you own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

The 3660 family

2023-05-08T20:54:41Z

Davecs: /* About this family of remotes */

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''[https://www.oneforall.com/universal-remotes/urc-3661-essential-6-antimicrobial-remote-control/ One For All URC-3661]''' (Europe), '''[https://www.oneforall.com/en-us/universal-remotes/urc-3680-essential-8-antimicrobial-remote-control One For All URC-3680]''', '''[https://www.oneforall.com/en-ca/universal-remotes/urc-3660-essential-6-remote-control One For All URC-3660]''', and '''[https://www.insigniaproducts.com/pdp/NS-RMT8D21/6495830 Insignia NS-RMT5D21]''' (America). The URC-3660 and URC-3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the URC-3660 and URC-3661, RMIR refers to the missing buttons as "Dev4" and "Dev8" and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to "learn" signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through ("Volume Lock")=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the "General" Tab of RMIR, you can assign "Volume Punch Through" individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros ("Channel Shortcut Macros")=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the "Setup" key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), or the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for "eject", then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros ("App Shortcut Keys")=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes "Activities" which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the URC-3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the "6 Device" remotes.

The Manual shows "AV Shift" and "Power Macro" as separate headings, but these are tied in with Activities. On some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the direction keys and "OK" to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. Also for "Power Macro", the standard Power keys on the remote will be toggles, but it’s possible to write your own (device specific) macro for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the "Watch Movie" button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as "Skip", forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design you own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

The 3660 family

2023-05-08T16:58:26Z

Davecs:

The sections of this page follow the order of the User Manual that comes with the remote, and seeks to compare what you can do with the Remote Master software and a JP1 cable, compared to the Remote on its own.

=About this family of remotes=

These remotes include the '''One-for-All 3661''' (Europe), '''One-for-All 3680''', '''Onn 3660''', and '''Insignia NS-RMT5D21''' (America). The 3660 and 3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the 3660 and 3661, RMIR refers to the missing buttons as “Dev4” and “Dev8” and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to “learn” signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through (“Volume Lock”)=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the “General” Tab of RMIR, you can assign “Volume Punch Through” individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros (“Channel Shortcut Macros”)=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the “Setup” key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), or the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for “eject”, then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros (“App Shortcut Keys”)=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes “Activities” which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the 3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the “6 Device” remotes.

The Manual shows “AV Shift” and “Power Macro” as separate headings, but these are tied in with Activities. On some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the direction keys and “OK” to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. Also for “Power Macro”, the standard Power keys on the remote will be toggles, but it’s possible to write your own (device specific) macro for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the “Watch Movie” button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as “Skip”, forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design you own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.

The 3660 family

2023-05-08T16:51:33Z

Davecs: /* Volume Punch Through (Volume Lock) */

=About this family of remotes=

These remotes include the '''One-for-All 3661''' (Europe), '''One-for-All 3680''', '''Onn 3660''', and '''Insignia NS-RMT5D21''' (America). The 3660 and 3661 have six device buttons, but are capable of controlling eight devices but only if used with RMIR. The other two have eight device buttons. In the 3660 and 3661, RMIR refers to the missing buttons as “Dev4” and “Dev8” and you can access them by putting Dev4/Dev8 in a macro. More about Macros later. There are powerful features on these remotes which are enabled with RMIR, in conjunction with a JP1 lead which connects to your computer.

=Setting Up Your Remote=

In the manual that comes with the remote, you are shown how to use built-in device codes to set up your devices. This may be adequate for your needs, but on occasions, not all buttons on the original remote will become available on your remote. In some cases, buttons may not be in the right place, or to your requirements. With RMIR there is another way.

Your remote is able to “learn” signals from your original remote, and RMIR is able to decode those signals, in such a way that you can build up your own device code. You can then use the accompanying RMDU program to create your own Device Upgrade. The disadvantage is that it takes time and patience. One advantage is that you can get every button exactly where you want it. Another is that you can often get information to add one or two extra controls that were not originally on your remote, for things such as Discrete On and Discrete Off, as opposed to a Power Toggle button. Such controls are very useful in macros to turn everything on or off, without things getting out of sync, and you can often find them out by asking on the JP1 forum.

You can find out how to add devices from other JP1 users, or to create your own from scratch, on [http://www.hifi-remote.com/wiki/index.php/JP1_-_Just_How_Easy_Is_It%3F this page]. You should read the entire page, and also [http://www.hifi-remote.com/wiki/index.php/JP1_Cables this one], which shows how to make a JP1 lead.

=Volume Punch Through (“Volume Lock”)=

The manual for your remote shows you how to lock your volume and mute buttons so that they always operate the same device. However, on the “General” Tab of RMIR, you can assign “Volume Punch Through” individually. So, for example, you can set volume controls on your BluRay device to operate the Volume on the TV, but the volume on a different device (say a CD player) to operate the volume on your amplifier. You only get this flexibility with RMIR.

=Multi Macros (“Channel Shortcut Macros”)=

This is where we get to the real power of this remote, in conjunction with RMIR.

RMIR, on most remotes, enables use of a short press of the “Setup” key, in order to add a Shifted state to each key (two short presses for number keys). But with this family of remotes, there is also the Multi-Macro.

In the Remote’s manual, you are shown how to put a sequence of numeric macros on the four colour keys, representing your favourite channels. Using the Red button as Sport, if, instead of briefly pressing the Red button, which sends the normal signal associated with that button, you press and hold it for a couple of seconds, you will get the channel you programmed in, and if you do another long press, it will go to the next one in the list. These macros can be global or device-specific.

However, if you use RMIR, the macros can include keys other than numeric keys, and each macro can be put on almost any key. Not the three App keys (between the colour keys and the numbers), or the device keys. And they will clash with the short-press function on a key where the short-press function involves a key move (including Volume Punch Through) or a macro. But on most keys they will work properly.

Of course, a Macro can have just one step, and there doesn't have to be more than one Multi-Macro on any given key. As an example, if on your BluRay device, you put a single Device Specific Multi Macro on the Stop key, with just one stage which sends the code for “eject”, then if you press the Stop key briefly, the BluRay will stop playing, but if you press and hold it, the disc will be ejected. If you do want to have more than one multi-macro on a key, they are executed in the same order as they appear on the Special Functions tab.

You have 10 phantom keys (i.e., keys that are not physically on the remote, but which you can allocate in RMDU and include in macros) and 10 shifted-phantom keys per device. This gives you plenty of options for Shifted keys and Multimacros.

=Real-Time Macros (“App Shortcut Keys”)=

The Manual describes three App Shortcut Keys which can learn a macro that you enter in real time, giving the opportunity to wait for certain functions to have taken place before you press the next key. Once learned, you can just press the key and the remote sends the signals, remembering the times for which keys are held down, and the delays between them.

With RMIR, you can place these macros on any key, global or device specific. You can actually write them from scratch, or edit the time for which each signal is sent, and the delay between signals.

=Activities=

The Manual describes “Activities” which allows you to have groups of keys from different devices working at the same time. There are more choices than given in the manual (for the 3660/1 at least) which involve Dev8 as the audio device. But you need RMIR to access Dev8 on the “6 Device” remotes.

The Manual shows “AV Shift” and “Power Macro” as separate headings, but these are tied in with Activities. On some TVs, pressing the Input (AV) button cycles through the possible inputs, so you don’t need it to temporarily allocate the direction keys and “OK” to the TV. Where it does, you may wish to use Activities, but RMIR provides an alternative. If not using activities, it’s possible to write Key Moves to the Input/AV button so that it always sends the signal to cycle through inputs to the TV. Also for “Power Macro”, the standard Power keys on the remote will be toggles, but it’s possible to write your own (device specific) macro for the Power key, to make use of Discrete Power Off signals where known.

If you don't want to use the inbuilt activity settings, but write your own macros instead, RMIR offers a function for this remote on the Advanced drop-down menu, to Disable activities. Once you have done this, you can allocate the Activity keys as normal keys, or write macros on them. Unless you do this, anything you put on those keys won’t work. So, as an example, you may allocate a macro to the “Watch Movie” button, which switches on your TV, BluRay player, Amplifier, selects appropriate inputs and leaves the remote buttons controlling the BluRay player, except for Volume Punch Through controlling the amplifier. Depending on your devices, this may or may not be a better plan than using the built-in Activity feature. But without RMIR, you don’t have the choice.

=More Features=

==Backlight==

The Remote has a backlight, which can be switched on and off by a button at the bottom of the keys. When on, and a key is pressed, the backlight lights up for 10 seconds. RMIR allows you to change the time it lights for, there’s an entry on the General tab for this purpose. RMIR also allows you to allocate a function to that key! This would mean that every time you operated this function, you’d also be switching backlighting on and off. If you don’t want backlighting, you can set the time on the General tab to zero. This won’t stop the backlighting altogether, but it will be very short, a fraction of a second.

In normal use, if backlighting is on, you have to press a key to light up the remote. If you want to operate it in a darkened room, the backlight button can be felt at the bottom of the remote. Press it once to turn backlighting off, press it again and the entire remote will light up.

==Fast Forward, Rewind and Skip==

There is a feature, undocumented in the official manual, where the signal sent by the Fast Forward and Rewind transport controls, depends on how long you hold the button down for. A short press sends a different signal to a long press. In the RMDU program, these alternatives are labelled Rewind, Rewind(Held), FastFwd and FastFwd(Held). Some people use the short press function as “Skip”, forwards or backwards as appropriate. Some people prefer to use the longer press for this purpose. As for the built-in devices, there isn’t a great deal of consistency between the two. If you design you own device, as per "Setting Up Your Remote" above, you can, of course, allocate these keys to your own preference.