Brand:

• AMX

Models:

• RMS Enterprise

Confirm the following first:

• The Duet module is in the online tree and assigned to a virtual number between 41000 and 41999.
• The port status of the virtual should show feedback on channels 251 and 252.
      ​​​- A device will not register until these are true.
• The code contains an RMS SDK Duet monitor connected to the device's Duet module.
      - Duet devices do not auto register without a monitor.

If the above list checks off, there is a lesser-known issue to explore.

​The model list sent to RMS during registration must be no more than 50-characters. This list of models comes from the TKO file within the JAR and is used by RMS to create the device (asset) default name.  Sometimes the model list contains several models, exceeding the 50-character limit. This article covers diagnosing the problem and how to modify the JAR to shorten the model list

Diagnosis

Details of the asset registration can be seen in diagnostics with LOG.LEVEL-DEBUG. Inside “sending asset [<asset info>]" will be model list (“name="). If this list is more than 50 characters, there will be an “EXCEPTION-Request to RMS Server failed."  At the same time, the RMS server log reports “…data would be truncated." Together these provide concrete evidence as to why the device does not register. The MANIFEST.MF found in the JAR contains a Device-Model list. If the model list in the manifest is over 50 characters, then likely the TKO would have the same list length but not always.

There is a similar issue with passing the firmware data from the Duet device. This limitation is 30 characters. So far this has only been an issue with certain Vaddio cameras. For example, a camera reported, “SYSTEM VERSION ROBOSHOT HDBT 3.5.0". A workaround has not been sought out for this.

Here is an example of diagnostic messages and the RMS log.

Viewing The Manifest File

Open the JAR file as a zip file, either in a program such as 7-zip or temporarily change the extension from “.jar" to “.zip." Inside will be a folder called META-INF.  Open this folder and open the file MANIFEST.MF in notepad.

This is an extreme (but real) example of a Device-Model list.  This entire list may not be in the TKO but it was confirmed there are more than 50 characters.

How to Modify the Duet JAR​

Since the source of the TKO file is not readily available, the TKO cannot be modified. The objective changes to replacing the TKO. There is a AXS template to create a new TKO available to down​​load.

1. Download the AXS template file, “Manu_Model_Comm_dr1_0_0.axs"
2. Open the JAR file to be modified as a zip file, either in a program such as 7-zip or temporarily change the extension from “.jar" to “.zip." 
3. Rename the downloaded template file exactly as the “.tko" found in the JAR but keep the “.axs" extension.
   For example: Manu_Model_Comm_dr1_0_0.axs  → LG_WebOS_IP_Comm_dr1_0_0.axs
   Download Example AXS
4. Open the AXS file in NetLinx Studio
5. Step through the comments adding the required information to the marked areas as shown below:
   
   
   To locate the Bundle-Version, refer to the MANIFEST.MF.  Alternatively, the version is part of the package filename downloaded from the developer site.  (i.e. Sony_VPL_ Comm_dr1_0_4.zip would be 1.0.4).
   
   The most common asset types are listed in the comments. If the device module does not relate to any of the listed assets refer to the MANIFEST.MF and locate “Device_SDKClass"  If not found, open an RMS web GUI and navigate to Configuration/Asset Types. Look for the closest asset type and use the associated Key.
6. After filling in all the module information, proceed with compiling the code.  
7. ​Locate the newly created TKO file and copy it into the JAR file, replacing the original.
   

​If there is existing Netlinx code, the code must be re-compiled with the new modified JAR. 
Re-upload ​​​the code and new modified JAR to the controller.