- Published on
Client-based diagnostics on Extron controllers (Part 3)
- Authors
- Name
- Ngoc Mai
- @ngockmai
Introduction
This is part 3 of 3 for diagnostics on Extron controllers.
As I mentioned in Part 2, there is only one client and hundreds of Extron controllers in my campus network.
I want: Extron controllers' job:
- Establishing and maintaining a reliable network connection to the client
- Receiving and responding to commands from the client
The EthernetClientInterface class in Extron Lib provides an interface to a client Ethernet socket. This class allows the controllers to send data over Ethernet port in a synchronous or asynchronous manner.
This class enables configuration of the server's hostname, port number, protocol, service port...
Blow is the diagram of a campus network with AV devices
Implementation
Design a touch panel layout
Note on the layout:
- The messaging button is used to enable/ disable the messaging function
- The volume slider is used to set the volume of the AV system
Hostname: The server's hostname or IP address
Port: The port to connect to (default is 8888)
ConTime: Retry interval in seconds for reconnection attempts (default is 5)
Instance Attributes:
Port: the port to connect to, default is 8888.
DataBuffer: a buffer for partial messages. Since network data can arrive in chunks, this buffer is used to store the partial message until they are complete.
ConnectionStatus: tracks connection state (initially 'Disconnected', and then can set to 'Connected').
MsgStatus: tracks whether messaging is enabled or disabled (initially 'Disabled' later can set to 'Enabled')
Contime: Retry interval in seconds for reconnection attempts (default is 5)
**ConnectionTimer: timer for reconnection attempts. It allows executing another function on a periodic time.
ConnectionTimer.Stop: stop the timer until the first connection attempts.
Bind event handlers
Connected: called when socket connection is established.
Disconnected: called when socket connection is closed.
ReceiveData: called when data is received. The callback takes two arguments: ClientObject instance triggering the event, and a bytes object.
Methods:
EnableMsg: set MsgStatus to 'Enabled' and then call StartConnection() to establish a connection.
DisableMsg: set MsgStatus to 'Disabled' and then call ConnectionTimer.Stop() to stop the timer, and call Disconnect() to close the connection.
StartConnection: establish a connection to a client with retry intervals. It takes two arguments: timer and count.
- timer: the timer object to execute the function on a periodic time.
- count: the number of times to retry.
If MsgStatus is 'Enabled', it will attempt to connect to the client. In case of the connection not successful:
- It will attempt to connect the client every 5 seconds in the first 2 hours.
- After that, the attempts slow down to every 1 minute for the next 1 hour.
- After that if the connection is not successful, it will stop te timer, set MsgStatus to 'Disabled', and call Disconnect() to close the connection.
Connected: handle successful connection event. when the event is fired, the function will stop the timer, set ConnectionStatus to 'Connected', and wait for 0.1 second (small delay to ensure connection stability), and then send a message to the client with a format: "Connected to Diagnostic Port at ...time..."
Disconnected: handle disconnection event. When the event is fired, the function will set ConnectionStatus to 'Disconnected' and then check if MsgStatus is 'Enabled'. If is enabled. It will call ConnectionTimer.Restart() to retry connection.
ReceiveData: handle received data, and process the data. When the event is fired, this function will decode data in bytes to UTF-8 and add the strings to dataBuffer attribute. The function also checks for complete messages.
Testing
Step 1: After the server started and running.
Status
The connectionStatus is 'Disconnected' and the MsgStatus is 'Disabled'. The server is not attempting to make a connection to the client.
Step 2: Messaging function is enabled.
From TCP server on my laptop, I can see Extron controller successfully connected and send the first message (messaging button was pressed). The reason the pressing button event was sent before the successful connection message is because there is Wait(0.1) second in the Connected() function.
Step 3: Test buttons and volume slider on touch panel.
Whenever I press test buttons and volume slider, the server send a message to all connected clients with a format: "time | message".
Step 4: Test ReceiveData function
The ReceiveData event is fired when data is received. In the screenshot below is 'end' command that I sent from TCP server on my laptop. Unlike server-based diagnostics Part 2, the server (Extron controller) made attempts automatically to reconnect to my laptop.
Note on the screenshot above
- I sent 'end' command to Extron controller. Extron responded to a message: "11:31:11 | Connection will be termintated."
- Four seconds later, I received a message from Extron controller: "11:31:16 | Connected to Diagnostic Port at 11:31:16 - 03/28/25".
- On client status: I also see the time when a client connected to TCP server on my laptop.
Conclusion
With this approach, there are also pros and cons to consider.
Pros:
- Extron controllers only send data to the IP addrss of client (Linux server) on a defined port, so it prevents unauthorized access to the controllers.
- Same as solution in Part 2, (server-based diagnostics), data can be stored in a database for later analysis.
- Client can send requests such as device status, volume, projector status, etc. and get data from all Extron controllers.
- Extron controllers maintain a reliable network connection to the client, and are responsible to reattempt to connect to the client if the connection is lost.
Cons:
- Because shifting connection maintenance to the servers, so it may create more workload on Extron, which has limited resources (CPU, memory).
Demo
Coming soon ...