Crestron Tesira Modules v2.x - deep dive

RS-232

Let's take a look at the RS-232 Command Processor as displayed in the Detail View of SIMPL Windows:

Important items to note:

• The RS-232 Command Processor supports over a thousand function modules
• Each RS-232 Command Processor pairs with a single COM port or two-way serial driver of a Crestron control processor.
  • Best results have been observed when COM 1 of the processor is utilized.
  • The 'To_Device' and 'From_Device' signals shown allow connection to and from the two-way serial driver.
• It is important that there is a signal connecting 'Is_Communicating' feedback to 'Initialize' control input. The alternative is to place a '1' on the 'Initialize' signal which will provide the same result.
  • This connection enables the auto-recovery mechanism.
  • If RS-232 communication is dropped or suspended for some reason, once that communication is restored, the Command Processor will re-initialize all connected function modules.
• It is good practice to add a signal name to the 'Is_Initialized' feedback.
  • This will provide visibility of the Command Processor being fully initialized.
  • If the Command Processor is fully initialized, that means that all attached function modules have been initialized.
  • The initialization of the function modules occurs in a non-linear fashion that appears to work up from the bottom of the Crestron program tree. 
    • If for some reason function module 3 of 62 does not initialize, that means that only function module 3 will not initialize. The Command Processor will not report as fully initialized until all of the function modules it manages are initialized.
    • The most common error preventing initialization is related to instance tag typos.
• It is recommended to place a '1' on the 'Debug' signal as this will print out debug information in SIMPL Debugger to allow further troubleshooting. Once troubleshooting is complete, the 'Debug' signal can be disabled if desired.
• Notice the 'Command_Processor_ID' parameter, this is a unique identifier ranging from 1 to 32 for each Command Processor in the Crestron file. The function modules will have a similar parameter option allowing them to point back to the specified Command Processor.
• 'Username' and 'Password' parameters are available for enabling system security.

IP

Let's take a look at the IP Command Processor as displayed in the Detail View of SIMPL Windows:

Important items to note:

• The IP Command Processor supports over a thousand function modules
• Each IP Command Processor manages TCP/IP communications within the SIMPL# code.
• It is important that there is a signal connecting 'Is_Communicating' feedback to 'Initialize' control input. The alternative is to place a '1' on the 'Initialize' signal which will provide the same result.
  • This connection enables the auto-recovery mechanism.
  • If IP communication is dropped or suspended for some reason, once that communication is restored, the Command Processor will re-initialize all connected function modules.
• It is good practice to add a signal name to the 'Is_Initialized' feedback.
  • This will provide visibility of the Command Processor being fully initialized.
  • If the Command Processor is fully initialized, that means that all attached function modules have been initialized.
  • • The initialization of the function modules occurs in a non-linear fashion that appears to work up from the bottom of the Crestron program tree. 
      • If for some reason function module 3 of 62 does not initialize, that means that only function module 3 will not initialize. The Command Processor will not report as fully initialized until all of the function modules it manages are initialized.
      • The most common error preventing initialization is related to instance tag typos.
  • It is recommended to place a '1' on the 'Debug' signal as this will print out debug information in SIMPL Debugger to allow further troubleshooting. Once troubleshooting is complete, the 'Debug' signal can be disabled if desired.
  • Notice the 'Command_Processor_ID' parameter, this is a unique identifier ranging from 1 to 32 for each Command Processor in the Crestron file. The function modules will have a similar parameter option allowing them to point back to the specified Command Processor.
  • The 'IP_Transport_Type' parameter allows selection of Telnet or SSH.
    • SSH is the recommended default as it is more secure and at times quicker than Telnet.
    • SSH or Telnet must be enabled on the Tesira system to allow communiation.
  • 'Username' and 'Password' parameters are available for enabling system security.

Basic supervision

Each Command Processor has two layers of 'watchdog' supervision built in.

1. Every 30 seconds, the Command Processor will poll the Tesira system for its current firmware version (DEVICE get Version).
   • If the Tesira device does not respond, the Command Processor will attempt to re-initialize.
2. Every 30 seconds, the Command Processor will send a subscription request to the first Function Module that supports subscriptions.
   • It is normal to see Tesira respond with "Error - already subscribed" as this confirms the subscription exists.
   • If the Tesira system does not respond, or responds with an '+OK', the Command Processor will attempt to re-initialize.

Once TTP commands are received by a Tesira system, they are passed to the appropriate Tesira device within that system via the Tesira Control Network. Tesira uses the instance tag to pass the TTP commands to the correct device.

Enhanced supervision

Though not always necessary, there are systems that require per device supervision.

Let's consider a small example system that includes a Tesira Server-IO in the IDF closet and a TesiraFORTE VI installed down the hall in the Conference Room. The TesiraFORTE VI provides VoIP functionality for the Conference Room. The third party Crestron control processor is also located in the IDF closet and is connected to the same control network as the Tesira system. Since we have two Server class Tesira devices, the Crestron code can include an IP Command Processor for each respective Tesira device. This will employ the 'watchdog' supervision detailed above on each respective Tesira device to our advantage. In the event of a power outage at the TesiraFORTE, the respective IP Command Processor will detect loss of communication and re-initialize once the device powers back up.

This same technique can be applied for per partition supervision. The assumption here is that the project has multiple partitions that may be updated throughout the commissioning period. As a partition or file is uploaded, existing subscriptions will be dropped. The per partition IP Command Processors would detect the lost subscription for the respective partition and re-initialize as needed.

Load balancing

When we consider larger system designs which require hundreds of control points, we will need to use multiple Command Processors to accommodate all of the Function Modules. An example system may include 32 touch panels, one or more Crestron control processor(s) and nine Tesira Server-IO. For this example, strategically balancing the room/device specific controls across nine Command Processors would strategically load balance communications as well as employ per device supervision.

Performance expectations

There are many variables for each deployed Crestron control system due to the different project needs and unique programming approaches. We expect the Crestron Tesira v2.x module suite to allow control of up to approximately 2,000 functions when properly deployed on a control processor. Performance will vary from one project to the next so keep an eye on the CPU usage of the Crestron processor as the program size grows.