Problems like this can be very difficult to diagnose when you are on your machine, using your set up, and have access to local tools. To do this remotely makes it much harder still, and the real difficulty is that I don’t have an Audac device, so it is just not possible to debug the communication part of the issue.
The Node-RED and the TCP node part I can look at, since I use both and successfully.
I use the TCP request node, and this really is very simple to set up.
The problems are that these nodes are really working with buffers, and not strings. A buffer and a string may look the same, but a buffer is an array of values in the range 0x00 to 0xFF, whereas a string is a array of characters. Humans understand strings, computers understand buffers, and converting between the two is a major source of problems in comms such as here.
In my case, I am feeding commands to a battery console comms port, as if I was typing in the command, so I am sending in a string. I am expecting a response, as I would see on a console, so I am asking for a string back. The complex bit is adding in the necessary ‘new-line’ characters to make it work.
For me, as I am using Linux, the newline is represented by \n, and I need two of them. One terminates the command, the other gets consumed somewhere, either the TCP node or my console port, so I have added an extra one just to make it work.
Taking the time and trouble to read the manual you link to, I note
Command overview
Startsymbol|destination|source|command|argument’s|checksum|stopsymbol
Example: Set volume zone 1 to -30dB ASCII #|X001|web|SV1|30|U|return
Important:- The address of the MTX is fixed at X001.- The checksum is CRC-16 excluding the ‘#’. You can replace the checksum with ‘U’, this is always accepted as checksum.- return = 0x0d 0x0a- source address has a maximum length of 4 characters and cannot contain “|” or “#”
This clearly states that the command end terminator is ‘return’ which is 0x0d 0x0a
I note that you are sending r\n in your packet sender, which is showing in the Hex as 72 0a, so this is not correct. I have no idea why it is working, but it probably should be \r\n. Some software (particularly on PCs) takes \n to be a CR LF which is both 0d and 0a, so I am assuming that your packet sender is fudging it to work, whereas on a Linux machine it will not.
You don’t show your node settings (which make it impossible to debug these for you). If you want to keep the connection open (which I do as I am sending commands every 30 seconds or so) and if you are sending in a string and not a buffer (which I am) and if you want to get a string response back, you may need to play with the delimiter option. Sometimes you just have to fiddle with the settings until it all suddenly springs into life.
A great way to test all of this is to use a command that will always generate a known response (‘hello world’). You have the 'Get Firmware Version or GSV. This should return a string
Get the firmware version
Example Command #|X001|web|GSV|0|U|return
Answer #|web|X001|SV|V1.1|U|return
Since this is not dependent on having a valid instruction, it would test the send-response to at least know you have the correct command sequence and terminators, and your TCP node is working.
In the end, debugging TCP comms comes down to using the packet sender you have, and also using the TCP node and checking the input and output as a buffer, and checking each hex value to see exactly what is going on. Tedious, but sometimes necessary.
because otherwise, it would not create the correct buffer. With this modification, which I honestly understood little about, it works.