ClearOne StreamNet Integration - Manual (Page 9)

Chapter 2: Controlling A StreamNet System 3
Chapter 2: Controlling A StreamNet System
StreamNet is designed such that a very large number of networked devices behave as a single coordinated
system. The integrator does not need to know about the underlying network complexity; StreamNet completely
handles it all. With StreamNet you get all of the advantages of an IP based system without the complexity. The
third party control device only needs to know a single IP address and through this one address can control
an unlimited number of StreamNet devices. Instead of IP addresses (which may change) the controller can
address commands to friendly, human readable names such as “Bedroom TV” or “DVD Player”. Control
messages using these friendly names may be sent to any StreamNet device or broadcast to all of them;
StreamNet will make sure that the correct device(s) and only the correct device(s) receive the message.
NOTE f : This document will describe a large number of alternative ways to control a StreamNet
system. This is a testament to the incredible flexibility of StreamNet; but, it may give the
impression that controlling StreamNet is complex – nothing could be further from the truth.
The integrator does not need to use all of the methods, only the most convenient one(s).
A StreamNet system remains remarkably uncomplicated even when scaled to huge proportions. Network
technology makes this scalability possible and StreamNet makes it simple.
Touchpanel user interface devices are available for controlling StreamNet without requiring any central
controller; but, this by no means the only way a StreamNet system can be controlled. In fact, StreamNet was
explicitly designed to simplify control by third party control devices such as AMX or Crestron Controllers.
Advanced users may be interested in StreamNet’s Auto-Discovery or Time Sync mechanisms, but the integrator
may mostly ignore how StreamNet does what it does and just take advantage of the simplicity it offers.
StreamNet devices handle the routing of AV content from one location to another as well as all aspects of
controlling the source and display devices. Most devices can learn and reproduce IR codes for controlling
non-StreamNet devices such as TVs, DVD players, etc. Serial and IP control of non-StreamNet devices are
also supported. StreamNet can even route IR signals transparently across the network to be reproduced at
other locations to control remote devices.
CONNECTING TO THE STREAmNET SySTEm
Control messages may be sent to the StreamNet system in a variety of ways. Messages may be sent through
a TCP connection to a single device or through multiple TCP connections. Also, messages may be sent
using UDP, either unicast or multicast. It is even possible to send the commands using an IR or RS232 serial
interface. The integrator may choose the most convenient method or any combination of these methods.
StreamNet TCP Portal
The most common way for a controller to connect to the StreamNet system is through a single TCP connection
to one of the StreamNet devices. This single TCP connection can be made to any StreamNet device which
supports the “TCP Control Portal”. If lots of control message traffic is expected then it is recommended
that a ControLinX be dedicated to providing this TCP connection. The commands are sent and responses
and unsolicited status messages are conveyed over the TCP connection. The TCP connection should be
maintained continually if system status is desired. Typically, each StreamNet device supports a maximum of 4
TCP clients at a time.
Obviously to make the TCP connection the controller must know the IP address of the device to which it is
connecting. So at least one device in the StreamNet system must have a fixed IP address. This is another good
reason to dedicate a ControLinX device as the portal to the StreamNet system. The portal ControLinX can be
assigned a static IP address but all of the other StreamNet devices can be allowed to find their own address.
NOTE f : If there is no traffic on the TCP connection after 60 seconds it will be closed. To
keep the connection alive the client can send a dummy ASCII command every 30 seconds.
#HEARTBEAT is often used for this purpose. But if the client has registered for status the
#REGISTER commands will keep the connection alive.