TCP-out seems to work only in random cases

I have been working with the TCP-out node for a couple weeks and I am observing a strange behavior on all my servers.
When I use a TCP-out node in order to send a message to an external server it works only erratically. This means sometime the message reaches the external server sometimes not. Sometimes it works after moving the node and (full) redeploy, sometimes not. This behavior is identical when connecting to different external servers as well as when using different node-red servers trying to connect to external servers.
With external servers I mean mostly other servers within the same local network.

I also looked into the TCP-request node as it might be better suited to what I am trying to do. Which is: send data to a TCP port and close the connection. If the external server sends a reply, fine, if not, also fine. The TCP-request node seems to give me the reply as well. I tried using it, but havent got it to work at all yet.

What I tried:

  • moving the TCP-out node and redeploy => works sometimes
  • restart node-red => no difference
  • just try another day (while server was running normally) => works sometimes

Is there something I am missing?
Maybe some permission on linux basis for the node-red user, like the dialout permission to use the serial port? tcp-port is always above 1024, so no root permission needed?

Thanks for any pointers!

Edit: I have in another flow the same TCP-out node, same configuration (literally copied) and it works every single time. Could it be that I cannot have multiple TCP-out nodes with the same host and port?

my flow:

[ { "id": "2a8456b600162ad0", "type": "tab", "label": "Flow 4", "disabled": false, "info": "", "env": [] }, { "id": "383b1e6bb59890e9", "type": "tcp out", "z": "2a8456b600162ad0", "name": "", "host": "", "port": "9100", "beserver": "client", "base64": false, "end": true, "tls": "", "x": 720, "y": 240, "wires": [] }, { "id": "9d73fd90bb2fea5b", "type": "inject", "z": "2a8456b600162ad0", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 260, "y": 240, "wires": [ [ "19ed156a81c4b731" ] ] }, { "id": "19ed156a81c4b731", "type": "function", "z": "2a8456b600162ad0", "name": "create label", "func": "// message to label printer\nmsg.payload = \"^XA~TA020^CI28^LH0,0^CF0,40,32\"\n +\"^FX(std text)^FS\"\n +\"^FO30,80^FDbla bla^FS\"\n +\"^FX(device name, space for word wrap over 3 lines)^FS\"\n +\"^FO30,130^FB580,3^FDtext text text text text text ^FS\"\n +\"^FX(___ID)^FS\"\n +\"^A0N,24,20 ^FO30,350^FDID^FS\"\n +\"^FX(optional: _____ID)^FS\"\n +\"^A0N,24,20 ^FO90,350^FD ^FS\"\n +\"^MMC^XZ\"\n\nreturn msg;\n", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 450, "y": 240, "wires": [ [ "76bc83896705a9a7", "383b1e6bb59890e9" ] ] }, { "id": "76bc83896705a9a7", "type": "debug", "z": "2a8456b600162ad0", "name": "debug 273", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 690, "y": 300, "wires": [] }, { "id": "3c94e577453e1fa8", "type": "tcp request", "z": "2a8456b600162ad0", "name": "", "server": "", "port": "9100", "out": "time", "ret": "string", "splitc": "10000", "newline": "", "trim": false, "tls": "", "x": 720, "y": 380, "wires": [ [ "74a708488d56c31f" ] ] }, { "id": "74a708488d56c31f", "type": "debug", "z": "2a8456b600162ad0", "name": "debug 274", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 930, "y": 380, "wires": [] }]

Some research shows that the TCP-out node does not close the TCP socket after sending the message.
To my understanding this is contrary to the description of selected option, which says "close connection after each message".
Is there any workaround for this? Or is it a bug in the TCP-out node?
Thanks for any pointers!

I don't believe you should be using the tcp-out node.

Provides a choice of TCP outputs. Can either connect to a remote TCP port, accept incoming connections, or reply to messages received from a TCP In node.

Neither of which is what you are trying to do I don't think?

As you mention, you should be using the tcp-request node.

A simple TCP request node - sends the msg.payload to a server tcp port and expects a response.

Noting though that it expects a response from the other end so if you still have issues when using tcp-request, you might need to do a network trace to make sure that the other server is sending a response in a reasonable timeframe.

1 Like

The way the node works is that if that option is selected - then it does close the connection (which some devices need) then immediately re-establishes ready to send the next packet.

If you add a status node set to watch the status of the TCP out node you should see it disconnect and reconnect.

But yes - as @TotallyInformation says - if you are expecting a response to a query then the TCP request node is a much better fit.

1 Like

Thanks for the input!
I tried the TCP-request and got the flow working just fine. It helped to delete all other TCP-out nodes and restart node-red, as the device that I am talking to seems to not support many open connections.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.