The current TCP/IP communication with the low-level controller has several issues that I'd really like to see cleaned up, if you can find the time:

• It does not report whether a given command succeeds or fails. I suggest adding a command ID integer that the CSC specified (and increments for each command) and reporting that integer with a code that indicates success or failure in the status. This will only allow acknowledging one command at a time, and requires polling, but I think we may have to live with that. A much more robust solution would be an asynchronous message as each command is implemented or rejected. But the current interface has no provision for asynchronous communication.
• Communication is via two separate sockets, one which is only read, one which is only written. This is nuts because TCP/IP sockets are intrinsically bidirectional. Please combine them. This should be a simple change. It is well worth doing, in my opinion, because it reduces the failure modes. With a single socket we are either connected or not. With 2 sockets either or both can be disconnected.
• The server is in the CSC and the client is in the low-level controller. If possible, please turn this around. That would allow us to manage the CSCs with Kubernetes – a big win. It also puts the configuration in the logical place (the CSC).