Troubleshooting | Crestron Q-SYS Module Feedback Issues
Gain insight into resolving Q-SYS module feedback issues within a Crestron system.
If you are not finding the results you need and still have questions, submit a request using the form below and our Tech Docs team will get right on it. Our goal is to provide the content you need!
Your engagement helps us create the content you need. Click here to review this article.
Table of Contents
|Software||Creston v4.2.1 Module Set|
During integration of Crestron Q-SYS Module Set, you may experience feedback issue coming from Q-SYS, or certain modules work while others do not.
Many problems in achieving proper Crestron control of Q-SYS can be resolved by following some fundamental best practices and understanding some basic background of the reasons for them:
Solution | Workaround
The next item to look for are certain tell-tale signs in the Crestron Debugger information. These will show up when either the Crestron program restarts (processor reboot or program restart), or the Q-SYS design is restarted (core reboot, or design push). Some common messages:
Null Reference Exception Error
This error may sometimes appear on its own due to other issues in the Q-SYS module set. It also may show up in other modules not related to Q-SYS at all.
- Unterminated string. Expected delimiter…
- Unexpected character encountered while parsing value…
- Unexpected end of content while loading JObject.
- Error reading JObject from JsonReader…
If those messages occur, it is time to find out why, and then take steps to mitigate them. The feedback issues that result in these messages are a result of the Crestron module choking on the sometimes large JSON-RPC responses from Q-SYS. To be clear, this is a Crestron issue, and not a Q-SYS issue. Technically it is up to either the Crestron programmer or Crestron themselves to resolve this. However there are ways to mitigate and even prevent the issue from occurring.
The best method to troubleshoot Crestron to Q-SYS communication issues is to grab a Wireshark PCAP capture. A capture of TCP/IP traffic from the core to the Crestron processor, on Port 1710, is required. From that capture it is possible to identify the location in JSON-RPC responses where the Crestron module fails.
The V4.2.1 module set will not accept anything over one TCP packet. JSON-RPC responses can technically span multiple TCP packets. Therein lies the issue, and also the path to mitigating the issue:
- Keep names of Named Controls as small as practical. The default names of Named Controls can sometimes be long. There is no need to keep those default names. Sometimes this step is all that is required.
- Only add polling to the Modules (controls) you really need. This will minimize the size of the initial JSON-RPC response from Q-SYS.
- If polling on a sizable number of Modules (controls) is still needed, then space out the rate at which polling gets enabled. Adding several groups of Modules (controls) over the period of 5, 10, 20 seconds or more will do much to minimize what would have been a large JSON-RPC response coming back. Implementing this may at times take some trial-and-error to ensure that the issues have been resolved consistently.