ACS Sample: Efficient TCP & Telnet in Core Studio

TCP and Telnet are one of the most common methods for controlling equipment in the pro AV industry.  This article covers some best practice concepts for controlling these devices in ReAX Core Studio.

Before you begin: read up on the terminology and settings used in Telnet events and actions in ReAX Core Studio here

First, it is important to understand how the TCP and Telnet work in our system.  Of course, in general, ‘events’ are triggers and ‘actions’ are for executing something.  In the scope of Telnet, an event is used to receive incoming TCP/Telnet data, and an action is used to send TCP/Telnet data.

When you create a Telnet action, it will send a message to the device you are talking to.  But if you only have an action without a Telnet event, it will by default open the connection, send the message, then close the connection.  In some cases and for some devices, this may be preferred.  If you have a DSP that is handling 10 classrooms, and all the classrooms have a touch panel, perhaps that matrix might not be able to handle 10 simultaneous connections, so this open > send > close method is necessary.

In order to listen for a response, you add the event.  As soon as you add the event, it will automatically keep that connection open in perpetuity.  If there is a disconnect, it will automatically attempt to reconnect.

You can add as many events and actions for the same IP and port as you want – the system is intelligent so that it will only open one socket to an IP:port, not multiple.

With that said, from a coding efficiency perspective, a good practice is to set up a single Telnet event that listens to data from a device and keeps the connection open.  If I am parsing the incoming data, I will use a JS action or variable actions to filter and parse and save the pertinent info.  Also, I add a single variable action that watches a variable to change, as soon as it does, it sends that value via a Telnet action.  To send any command, all you do is populate that variable with the command.  Using this technique, I have 2 variables, and 2 events that serve as a single conduit for all incoming and outgoing data.  This makes things simpler, more efficient, and better for debugging.

Another best practice is to store your TCP/Telnet IP (and port, if it might change) in a variable.  Even using this efficient technique above, you will need to define the IP and port twice - once in the event and once in the action.  If you hard code it into those blocks, you will likely need to change them once commissioning the client system.  If you get in the habit of saving values like this as variable values, you will only have to change them once.