RM/RMIR v2.11 available

[mathdon]

Edit: RMIR v2.11 is now superseded by v2 12, whose first official release is RMIR v2.12.0 available here.

RM/RMIR v2.11 is now officially released.. Please note that due to a change made by SourceForge, the update checker in v2.10 and earlier no longer works, so it will report that you already have the current version. The checker in v2.11 will correctly report updates when there are future builds or versions.

This is a major new version that provides additional ways to exchange data between RMIR and RM on the one hand and IrScrutinizer and IRScope on the other. The native file format of IrScrutinizer is Girr files (.girr), that of IRScope is Ict files (.ict). RM, and the Device Upgrade Editor in RMIR, can now import and export files of these formats. Depending on the context, for import these are either new file types on File > Open dialogs or on new dedicated Import dialogs, for export they are on new Export dialogs. Import creates functions for a new device upgrade but cannot create button assignments, as there is no button information in the imported files. An exported file is correspondingly missing the button assignments, which is why export is only through Export and not Save As dialogs. RMIR can also export an entire remote as a Girr file that contains all its functional device upgrades, but the structure of Ict files does not support such an export.

This build incorporates version 1.2.7 of IrpTransmogrifier by Bengt Martensson (Barf). The new features described above have been made possible only through greater consolidation of IrpTransmogrifier into the structure of RMIR, and the willingness of Bengt to incorporate amendments and new features to facilitate this consolidation. I am indebted to him for this cooperation. As previously, command-line access to IrpTransmogrifier itself is available if required through the command files irptransmogrifier.bat (for Windows) and irptransmogrifier.sh (for Linux and Mac OS X) in the RMIR installation folder.

The supported platforms are 32-bit and 64-bit Windows, Linux and Mac OS X, together with experimental support for Raspberry Pi. This version, like versions 2.09 and 2.10, requires Java 8 or later. It supports all currently known types of UEI remotes, including XSight and Simpleset remotes. UEI has closed down the EZ-RC.com website that provided support for XSight and similar remotes. RM/RMIR provides complete replacement support for these remotes, including the ability to upgrade the firmware to the last version that UEI issued. XSight users new to RMIR, especially ones who have been directed here from the legacy page at EZ-RC.com, should read the Wiki article Getting started with XSight and Nevo for further information.

No special action is needed to perform a firmware upgrade on an XSight remote. Just do a download in the usual way. If a firmware upgrade is available it will be offered. You may install it or not, at your choice, and if you choose not to install it, you are given the opportunity not to be offered the upgrade again in future.

The XSight and Simpleset remotes are supported by RMIR directly via their USB interface, without the need for any cable other than the USB lead supplied with the remotes. Other remotes are supported through their JP1 6-pin connector with JP1.x interface cables that use an FTDI chip. These cables are also available with a Prolific chip instead of the FTDI one, but many remotes will not work with these cables. More information on this is given below. It is strongly advised that you use a cable with a genuine FTDI chip - there are also cables with counterfeit FTDI chips on the market and these too will often not work.

Remotes that support the Bluetooth UEI phone app can access RMIR through their Bluetooth interface, in several ways. All supported OS platforms can use the BLED112 Bluetooth dongle, currently available for $10.45 in the US or for GBP8.52 (UK 8 pounds 52 pence) in Europe. Windows users have two additional access methods. One uses the Bluetooth stack that is built in to Windows 10, but the remote needs v2.00 of the Bluetooth extender installed and this installation requires a one-off use of a JP1.x cable. The other is available both for Windows 10 and some earlier Windows versions (but so far only tested on Windows 8.1) and does not require this use of a JP1.x cable, but needs the installation of the BlueSoleil Bluetooth stack. See the Bluetooth thread Bluetooth is coming to RMIR for more details.

Previous versions of RMIR have had their first release build available only as a full installation package but with subsequent builds issued both as a full package and as a cumulative update package to install into any earlier build of the same version. Little use has been made of these update packages and from version 2.11 onward they will no longer be issued. To upgrade from v2.10 without losing your settings, delete everything in your installation folder other than the RemoteMaster.properties file that contains your settings. Then unzip the new installation package into that folder and you are done. Alternatively, if you wish to keep your v2.10 installation and port your settings to v2.11, follow the installation instructions below and then copy the RemoteMaster.properties file from your v2.10 installation to this new one.

The RMIR menu item Help > Check for updates checks for new builds as well as new versions. If a new build or version is available then this menu item displays a message containing a hyperlink that will take you straight to the download for the update.

To install RMIR for any OS, first unzip the installation package to a new folder that is not read-only. For a Windows OS this means, in particular, that it should not be unzipped into a subfolder of the Program Files folder. After unzipping it, do the appropriate one of the following:

• If your OS is Windows then run Setup.vbs by double-clicking or otherwise. This will create three shortcuts, one each for RMIR and RMPB and the third (named Remote Master) for RM. They will be created in your installation folder, but they are also copied to Start > All Programs > Remote Master if you are running a Windows version that has a Start menu. You may copy them to your desktop, or any other location, as you wish. Setup.vbs also creates file associations to open .rmir files in RMIR, .rmdu files in RM and .rmpb files in RMPB.
• If your OS is Linux then run setup.sh from Terminal as a shell script. If the current directory in Terminal is the RemoteMaster installation directory then the command "sh setup.sh" will run the script. It creates three .desktop shortcuts, one each for RMIR and RMPB and the third (named RemoteMaster) for RM. They will be created in your installation folder, but they are also copied to your $HOME/.local/share/applications folder to ensure that they appear on your Dash. setup.sh will also add you to the dialout group of users, if you are not already in it. If you need to be added, then it will ask you for your sudo password as this step needs to be run with root privileges. This step is needed to enable RMIR to access USB serial ports without RMIR itself being run as root.
  
  The distribution also contains a text file linux_xsight.rules. If you have an XSight or Nevo remote, you may need to copy this to the directory "/etc/udev/rules.d/". It may be re-named if desired, provided the extension .rules is kept. This file provides a user-friendly name for the XSight as a USB device. Some users have found that Linux systems cannot find the XSight/Nevo remote unless RM/RMIR is run as root, even after running setup.sh, unless this file is present.
• If your OS is Mac OS X then there is as yet no special installation procedure.

With all three OS's, RMIR can be opened without using a shortcut by double-clicking or otherwise running the Java file RemoteMaster.jar. RM can be opened from RMIR with the menu item File > New > Device Upgrade and RMPB with the menu item File > New > Protocol. The instances of RM or RMPB so opened are independent of the RMIR instance from which they are opened, so you can then close RMIR and leave RM or RMPB open if you wish. RM can also be opened from a command line by running RemoteMaster.jar with an argument -rm and RMPB with an argument -pb. Please note that although it is optional to run Setup.vbs in Windows as RMIR, RM and RMPB can always be opened in these ways, in Linux you need either to run setup.sh or to use some other means to add your user id to the dialup group of users. This need only be done once ever, however, as it is a system setting that is not specific to the RemoteMaster program.

A few remotes have an external 5-hole connector rather than the 6-pin connector in the battery compartment that is common in UEI remotes. These need an adapter to convert the 5-hole connector to the standard 6-pin one. Detailed instructions for making such an adapter are given here. Remotes that use a Maxim processor can all be connected with a standard JP1.2/3 interface cable but only one that uses the FTDI chip. Cables with chips of other manufacturers such as Prolific have difficulty communicating with the Maxim processors. This is discussed in some detail in this thread. The most recent processors used by UEI are from Texas Instruments (TI). These can certainly be connected by JP1.2/3 cables with the FTDI chip. The situation with other chips is not yet known. The remotes with TI processors either support Bluetooth as described above or have RF capability through the RF4CE protocol, depending on the processor concerned.

When using XSight remotes (and similar ones such as Nevo) with Windows 8.1 and Windows 10, Enhanced Power Management needs to be disabled for access to the remote through the USB port. Changing this setting affects only the connection for that specific remote, leaving other devices accessed through USB ports unaffected. RMIR v2.11 checks for this and displays a message giving instructions for disabling it if it finds that this setting is still enabled.

RMIR is available only as a Java file and from version 2.09 onwards has required a Java 8 or later runtime environment, either 32-bit or 64-bit. Versions from 2.04 through 2.08 required Java 7 or later, version 2.03 and earlier only required Java 6. The release package includes the following support files:

• DecodeIR v2.45 as library files for Windows (32-bit and 64-bit), Linux and Mac OS X.
• jp12serial v0.24 as library files for Windows (32-bit and 64-bit), Linux, Mac OS X and Raspberry Pi.
• digitmaps.bin with digit maps up to number 744.
• protocols.ini which is a database of protocol executor data.
• RMIR.sys that contains the data needed by RMIR to perform firmware upgrades of the XSight remotes.
• The RDF File Specification, Version 4.
• The RDF File Specification, Version 5 as revision 14 of an Addendum to Version 4.

An update to any of these files will result in a new build being released, so there is no need for separate updating of any of them. Version 4 of the RDF File Specification covers RDF files for remotes with interfaces up to JP1.3. Version 5 is required to support remotes with interfaces from JP1.4 onward. Version 5 is under continuous review as UEI remotes with new features are discovered, with revisions of the Addendum being issued as required.

Please visit the JP1 Community Wiki for information about how to use RMIR. A link to the Tutorial in the Wiki is also included in the Help menu. Please note that as this project is supported solely by volunteers, the Wiki may not be up to date. This version of RM/RMIR contains many new features required to support the newer types of remote. At the time of its release, these are not covered by the help files contained in the Wiki. RM/RMIR itself, however, shows notes and tooltips (the text shown when you hover the mouse pointer over a button or table entry) designed to make its use as self-explanatory as possible.

The download package is available in the following folder. Just click on it to start the download.

• http://sourceforge.net/projects/controlremote/files/RemoteMaster/v2.11build1 - (~23MB)

Please see above for installation instructions.

Links:
The RemoteMaster project home page.
IrpTransmogrifier manual.
JP1 Community Wiki
Tutorial (part of the Wiki)
Getting started with XSight and Nevo (also part of the Wiki)
Nevo and XSight Remotes (thread specific to these remotes)
Bluetooth is coming to RMIR (announcement thread for the new Bluetooth interface)
RF Support in RMIR (announcement thread for RF support through RF4CE)
RMIR XSight Support (development thread)
RMIR Simpleset Support (development thread)
RemoteMaster on Raspberry Pi with Raspian (development thread)
RMIR: Prototype IR function in RM (development thread)
IrpTransmogrifier: new program/library for IRP protocols (development thread for IrpTransmogrifier)
How to install Java 8 on Windows XP (YouTube video and written instructions)
RM/RMIR v2.10 available (announcement thread for last official version)
ChangeLog.txt (also included in the installation package)

[mathdon]

I have now posted development build 3 of RMIR v2.11 in the RMIR Development folder on SourceForge. It contains three files to replace the corresponding files in the installation folder of builds 1 or 2.

In addition to the changes in development build 2, this build adds two new features: (a) the ability to change the frequency tolerance when decoding learned signals, and (b) the ability to export the learned signals timing summary as a Girr file, thanks to Bengt. It also adds a new option to suppress the protocol choice dialog in the conversion or import of signals as device upgrade functions. This defaults to true, in which case the choice is made algorithmically by RMIR.

[mathdon]

I have written a fix that does three things

This fix is now included in development build 3 of RMIR v2.11, modified so that the Save button gives you the option of saving as .girr (default) or .csv.

you can generate cvs from girr with a simple xskl-script.

Simple ... that's a joke, yes???

[mathdon]

I have now posted development build 4 of RMIR v2.11 in the RMIR Development folder on SourceForge. It contains four files to replace the corresponding files in the installation folder of builds 1 through 3.

In addition to the changes in development build 3, this build updates the criteria for decoding a signal as Pioneer by changing the upper frequency limit from 41000 to 42000 and adding device codes 161, 162 and 171 to those for which Pioneer is preferred over NEC2. These changes are based on information from Rob, see this post and the preceding one in that thread. Bengt, the author of IrpTransmogrifier, will have to decide whether or not to incorporate those changes for Pioneer into a later build.

[mathdon]

Build 6 of RMIR v2.11 is now officially released. The main changes since build 1, which was the last official release, are enhancements to the import and export of device upgrades as Girr and IRScope ict files, including the update of IrpTransmogrifier from v1.2.7 to the current snapshot of v1.2.8. There is a new option on the Learned Signals tab to change the frequency tolerance in signal decoding, or to turn off frequency checking completely. There is an improved algorithm for the matching of device parameter names when changing the protocol of a device upgrade. There are also minor amendments to protocols.ini and the addition of RDF, map and image files for two remotes.

[mathdon]

Development build 7 of RMIR v2.11 is now available in the RMIR Development folder on Sourceforge. It is posted as an update to build 6 and contains only one file, a RemoteMaster.jar to replace that in the installation folder of v2.11 build 6. This build fixes a bug that affects the use in RMIR (but not RM) of protocols that have a CodeTranslator entry. It also adds additional data to the output of the Summary feature, and a new item on the File > Summary menu to create a summary consisting of only user-selected tables.

[mathdon]

The latest development build in the RMIR Development folder is build 10. This fixes several bugs and adds various improvements. Please see the ReadMe that displays in that folder for details.

[mathdon]

I have now posted development build 11 in the RMIR Development folder. The additions in this build are to provide a user-friendly interface for air-conditioning protocols where the usual Device, Subdevice and OBC are meaningless. Please see this post for details and illustrations.

[Barf]

Graham, can you explain the purpose of

Code: Select all

   <irp:parameter name="uei-executor" type="xml">
	    <rm:deployment executor="">
	        <rm:translator target="data">0x</rm:translator>
             </rm:deployment>
	</irp:parameter>

within <irp:protocol name="NEC-Shirriff-32">? I suppose that you just want to disable that dumb protocol; is there a reason why (for example)

Code: Select all

<irp:parameter name="uei-executor"/>

won't do?

And please update the version attribute every now and then...

[mathdon]

It isn't disabling it at all. I opened an Ict file that had signals that decoded as NEC-Shirriff-32 and saw that the 32-bit value was displayed as a decimal number. I thought it would make a lot more sense if it was displayed as hex. This is what that does. 0b would display it as binary, 0q as base 4 and simply 0 as octal. That is part of the new syntax added to rm:translator. You can set the radix for any individual parameter if desired.

And please update the version attribute every now and then...

Oversight . I had posted it before I realised this. For the same reason it still says the file has no entries, when it does so. I will be more careful next time. I've already made these amendments in my own files.

[Barf]

It isn't disabling it at all. I opened an Ict file that had signals that decoded as NEC-Shirriff-32 and saw that the 32-bit value was displayed as a decimal number. I thought it would make a lot more sense if it was displayed as hex.

Do you show it in msb-first form too (all other NEC*-stuff is lsb first)?

Personally I would probably prefer (for example) an attribute, say

Code: Select all

<rm:translator target="data" radix="16"/>

instead of another "notation".

[mathdon]

Do you show it in msb-first form too (all other NEC*-stuff is lsb first)?

It is the value of the "data" parameter expressed in hexadecimal, with the usual "0x" prefix.

Personally I would probably prefer (for example) an attribute, say

Code: Select all

<rm:translator target="data" radix="16"/>

instead of another "notation".

To me, that would be another notation. Mine is not, the syntax of an rm:translator value is always a list (including a list of just one member) of strings separated by vertical bars. Just one parser needed. The semantics is determined by the length of the list and the value of the first element, and is explained in the revised description of the rm:translator element.

[mathdon]

Build 6 was the last official build of RMIR v2.11. The changes in subsequent development versions are incorporated into RMIR v2.12.0, which is now available. There has also been a change of numbering, so this is not a typo. The build number is now given as a third element of the version number and starts at 0 rather than 1.