Tcp out is eating some of my messages

General
1

Hi

I probably facing something really simple but I just can't get a grip on it.

Let me first explain what is working:
I can use 'Injection' to send a string of 17 Ascii characters to a 'TCP out' node. They arrive "on the other end" as expected. This string is a simple start command of an equipment. Click on the injection node and the machine starts.

I have a barcode scanner on a TCP in node that receive a barcode. The idea is if the barcode is correct the machine should be started. This part works great too. but.....

What is not working:
When I want to automate this by using a 'Change' node to replace the msg.payload of the message received from the 'TCP in' node (barcode) with the exact same string as the working example (17 char start command). When this string is sent to the same 'TCP out' node as above it does not show up anywhere. No errors, no nothing. I have used a sniffer to make sure the string does not get sent out. Scan barcode, machine does not start or even get any data at all.

When I use debug to see the string they appear identical and with 17 chars each. I have tried to use 'Template', 'Function' and 'Change' and they all produce a string to the 'TCP out' node but that's as far as they get.

Any brilliant tricks or tips to stop my TCP out node from eating my data?

Node Red 0.19.4
Node js 8.11.1
on a Raspi 3B os Linux 4.14.79 v7+ arm LE

2

what happens if you add a tcp-in node and configure both the in and out nodes to use a port on the pi? What do you see then?

3

If, after you get to the point when it should have sent the second command, you click the inject again does it get sent?

4

also:

  1. what are your settings for the tcp-out node
  2. how do you know They arrive "on the other end"
5

Let me simplify a little just to explain things easier. The "machine" is a lamp controlled by an embedded MCU via a transfer layer consisting of a ESP8266. The start command will turn on the machine. The Stop command obviously turns off the light. Today this can be done with 100% reliability via 2 Inject nodes. It is confirmed both by the light following the command states and by me using a serial logger on the ESP tx output pin watching the data to the MCU.

The ESP has an internal TCP server and I use TCP IN node "name=f2 connect to IP,port" this server. (verified working by both displaying connected and actual machine on/off)

Injection of commands is done by Injection node "a-z A,1,B,2" ----> TCP OUT node "Reply to TCP name f2" ( same name as the server connection)

This part works great!

The barcode reader is on a TCP IN listen to port and I can see the barcode data arriving too.

I just do a simple Change on the message and send it to the same TCP Out as used by the Injection, here is where things stop to work.

But probably there is something basic I am missing.

Try to load this flow just for testing, it does not really show the problem that I have but I feel it may be related probably because I am not getting this:

[{"id":"dd89fd24.9eb4","type":"tcp out","z":"9b347dac.64153","host":"localhost","port":"7000","beserver":"server","base64":false,"end":false,"name":"server","x":830,"y":540,"wires":[]},{"id":"fb629f19.088f","type":"tcp in","z":"9b347dac.64153","name":"1","server":"client","host":"localhost","port":"7000","datamode":"stream","datatype":"buffer","newline":"","topic":"","base64":false,"x":630,"y":660,"wires":[["f32de17.376cb2"]]},{"id":"dc1924fa.c2f7f8","type":"inject","z":"9b347dac.64153","name":"MSG1","topic":"","payload":"This is message 1","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":650,"y":540,"wires":[["dd89fd24.9eb4"]]},{"id":"f32de17.376cb2","type":"debug","z":"9b347dac.64153","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":850,"y":660,"wires":[]},{"id":"b8599052.34d2f","type":"tcp out","z":"9b347dac.64153","host":"localhost","port":"7000","beserver":"client","base64":false,"end":false,"name":"2","x":830,"y":600,"wires":[]},{"id":"b18227d1.341bc8","type":"inject","z":"9b347dac.64153","name":"MSG2","topic":"","payload":"This is message 2","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":650,"y":600,"wires":[["b8599052.34d2f"]]},{"id":"9d448680.b73438","type":"tcp in","z":"9b347dac.64153","name":"3","server":"client","host":"localhost","port":"7000","datamode":"stream","datatype":"utf8","newline":"","topic":"","base64":false,"x":630,"y":720,"wires":[["3609bc3b.0ff724"]]},{"id":"3609bc3b.0ff724","type":"debug","z":"9b347dac.64153","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":850,"y":720,"wires":[]}]

Injection MSG1 to "server"---> Debug windows belonging to TCP IN (1) and TCP IN(3) will display correct string. One as string and one as bytes formats. EXPECTED RESULT

Injection MSG2 to TCP OUT(2) should in my opinion also show up in the debug windows belonging to each TCP IN. But for some reason this does not happen.

I feel like I really do not understand even the basics of TCP here.

So thank you for any ideas and even bigger thank you for your patience.

6

I notice that the tcp-out node 'server' uses the type 'Listen on' while tcp-out node '2' uses the type 'Connect to' - Why is that?

Also since the "machine" contains an ESP8266 are you programming it and have you thought about using MQTT instead of TCP?

7

Hi,

Sorry for not being more clear. The flow above is not the one I originally had problems with. The example flow is a very simple example trying to send messages around with TCP internally in my Raspi to avoid any outside strange influences.

When I run the example flow I never get MSG2 delivered to any of the TCP In nodes. Can someone please try on their system and see if BOTH Msg1 and Msg2 show up at the debug.

I am trying to link to an existing hardware, the ESP module in that hardware is today using AT+ commands and does only support TCP and UDP. For sure the next upgraded hardware will have a MQTT enabled module but I still need to be able to support legacy mode with TCP.

If I have to pick who is to blame here I would put my money on Node is working as it should and I am not currently Node compatible

8

Oh I can confirm that, but you have two different connetion types using the same port. I'm not a tcp expert, but I think the issue is that you are trying to use the same port with both connect and listen for the output. I think in a tcp-out node, if you select listen on the tcp-in node you need connect and vice versa or
tcp-out(connect ===> tcp-in(listen)
tcp-out(listen ===> tcp-in(connect)
but not
tcp-out(connect ==(fails)=> tcp-in(connect)
tcp-out(listen ==(fails)=> tcp-in(listen)

9

Hi again,
After lots of testing I have come to an end. I still can't make it work but I do think it has to do with something internal in Node regarding how connections are handled. I can't spend more time on this for the moment so I have gone for a different solution.

I wrote a middleman handler in Python (TCP<==>MQTT) and deployed it as a service on my Pi. So now my equipment will connect to this service using TCP and I just forward all messages to MQTT and back. And of course MQTT really works with Node so problem solved :slight_smile:

Thanks for all input, maybe I will revisit this problem later when having more time.