Crestron Tesira Modules v3.0 - 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.
• The latched signal connecting 'Is_Communicating' feedback to 'Initialize' control input is required. Placing a '1' on the 'Initialize' signal as shown serves the same purpose.
  • 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.
• The latched signal connecting 'Is_Communicating' feedback to 'Initialize' control input is required. Placing a '1' on the 'Initialize' signal as shown serves the same purpose.
  • 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 communication.
  • 'Username' and 'Password' parameters are available for enabling system security.

Basic supervision

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

1. Firmware Watchdog
   • 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. Patrolling Watchdog
   • Every 30 seconds, the Command Processor will send a subscription request to a valid Function Module that supports subscriptions. Once a valid response is received, the Command Processor will chose another subscription capable Function Module and send it a subscription request. This process will continue covering all subscription capable Function Modules in the SIMPL file.
     • It is normal to see Tesira respond with "Error - already subscribed" as this confirms the subscription exists.
     • If the Tesira system 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

With the introduction of the 'patrolling watchdog' feature, the need for per-device or per-partition supervision is lower. However, some users may require more granular supervision. To accomplish this, designate a Command Processor for each Tesira device or partition. The Tesira module suite allows up to 32 Command Processors in a SIMPL file.

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 v3.x module suite to register and control of up to approximately 2,000 functions when properly deployed. 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.