Telnet Actions in Core Studio are used to send Telnet and TCP data to a specific IP:port. Without a Telnet Event listening for data from that same IP:port, the Action will open the socket, send the command, then close the socket.
Telnet Events in Core Studio are used to listen for incoming data from a server or client. Events force the socket to remain open - in this case, the Telnet Actions using the same IP:port no longer need to open and close the socket, they simply use the existing open socket.
We often get asked, "does Core Studio TCP communications?". The answer is yes! Telnet Actions and Events that do not have the 'Use Telnet Encoding' box checked will default to raw TCP. Unfortunately, over the years, manufacturers in the AV industry used the term "Telnet" to refer to their control APIs, when is reality the vast majority of manufacturers are using TCP, so it becomes a point of confusion. Our suggestion - when controlling a device that uses "Telnet" control, try it first with the default setting of 'Use Telnet Encoding' unchecked. If that is not working, then try it enabled.
Below are some definitions of the different options for Telnet Events and Actions.
Telnet Event: Triggered when a matching string is received by the ReAX's telnet server or when a telnet server sends a matching string through an established telnet client connection.
NOTE: If using a Telnet Event, with Telnet encoding enabled, enabling Auto-buffer will cause undesired results.
Server Mode: When checked, ReAX will act as a server and wait for incoming connections from the specified origin host (no port needs to be defined, port 2323 is the listening port). In this case, the client would use port 2323. When unchecked, ReAX will connect to the specified origin (host:port) and wait for incoming data.
Note: certain RX controllers allow you to change the server port. On supported controllers, go to the web setup pages > Setup > Event Manager and set the Telnet Server Port.
Keep Connection Alive (deprecated): When checked, ReAX will attempt to keep the client connection alive by reconnecting to the origin (TCP server) every 60 seconds if the connection is not open. This does not impact server mode.
NOTE: in recent version of Core Studio, the 'keep connection alive' checkbox has been removed, and is always enabled for any Telnet Event).
Auto-buffer: By default, while an event is executing, all triggers are skipped. Let's say you have a variable action in your telnet event that increases variable varX with 5 seconds delay. When the telnet event triggers, the variable action is queued for execution in 5 seconds. Meanwhile if you get additional telnet triggers, those are discarded. So in the end you'll get varX increased once. If "auto buffer" is checked, those additional telnet triggers are buffered. This means that if you get 10 triggers within 5 seconds, then the varX will be increased 10 times, all triggers are executed.
Use Telnet Encoding: When checked, the client connection will be established using negotiation as specified by the Telnet protocol. When unchecked, it will not attempt to negotiate (raw TCP). Keep this box unchecked unless your device specifically requires true Telnet (Biamp devices require this checked). This does not apply to the server mode.
Receiving Feedback from Sent Commands: To receive feedback from a device that you will also be sending commands to, use a Telnet Event and specify the trigger value (Any, Value, or Expression). Also make sure "keep connection alive" is checked. The trigger data is represented by a reserved variable _g. For example, you could use _g as the value (with the expression box checked) in a variable action to dump the incoming Telnet/TCP data into a variable.
Additional Notes:
- If multiple Telnet events have the same origin field (for example 192.168.1.100:6000), they will share a single TCP socket.
- If a Telnet action has "Output to" field that matches the origin field of an existing Telnet event, then it will reuse the already created TCP socket. For example, a telnet action that outputs to 192.168.1.100:6000, will reuse the socket created for an event that has the same origin.
- If no socket exists to handle a Telnet action, then EM will create a new 'temporary' TCP socket, send the data, then close to socket.
Troubleshooting Tips:
If a device is not responding to control commands:
- Test commands with the Use Telnet Encoding option disabled, if not working, try with the option enabled (Biamp devices require Telnet Encoding enabled, most other devices require it disabled)
- Try creating a Telnet event with the Keep Connection Alive option checked, which will force the socket to stay open (Audac DSPs require this)
- With the Telnet event above, you can add a variable action to dump incoming data to a variable which can be displayed on your control GUI for debugging (incoming data is represented by the reserved variable _g).
- Send the commands to the device from a Telnet/TCP terminal (Putty, Hercules, etc.) to test that the commands are correct
- Point the destination IP of the Telnet/TCP action in Core Studio to the IP of your computer, and confirm that commands are being received using a TP server (Hercules, etc.)
- Review the ReAX device logs for any errors