Good way to handle and combine many msg from a tcp server

General
1

Hi there.

I have a flow in which I send many requests to a TCP server, and gets many different messages back from the server, all set properly with a specific msg.topic so I can filter them correctly when they arrive.

Some of the requests come from Dashboard actions, some from inject set with interval, some from different function nodes...

I need to send to other devices, some messages which make use of several content from the above. My first idea was to create some flow/global variables, which would include an array of many objects set from the above messages from tcp server... I'm there yet, but on my way.

Now, I think I'm confused about the "msg triggering" concept of node red compared to regular programming languages.
Example : I set a message do a bunch of DashBoard nodes, some of these nodes receiving an updated content, but some other nodes receiving the same content as their previous value. In that case, all these DB nodes are being updated, which makes the DB nodes with unchanged content "blink".....

Unitl now, my preferred way f using NR is to do a lot in the function nodes and make them build and send complex messages, if possible built to be received by many different nodes to keep the flow logical and "simple". But I start asking myself if that is the right way to go with NR, and if splitting flows to target specific nodes would be the solution.

What do you think ?

Thanks,

Jerome

2

Possibly the JOIN node.

Depending if there is/are always the same number of replies to your request.

3

As you have set topics for the responses from the tcp request you could use a filter node. You can set it to only allow changes to the required property (i presume payload) to pass, and set for each message topic. That way only topics with changed payloads would be passed on.

4

Yeap thanks that could be an idea.

I was also thinking about a switch node, but that brings me another question . If I still need some msg with different topics to be directed to a single output, is there any syntax I can use in a switch node rule which includes several conditions to go to the same output ?

Anyway, both ways don't match my idea of "one node do it all" , but It seems I have to think differently with NR :smiley:

Thanks for your help.

5

For now I would use as many nodes as needed to get the job done.

Then once that mish mash of nodes works, you can study their workings.

Then make your custom node.

Though for now I would suggest doing it the longer way.

If it helps, use link nodes and put this whole thing on it's own tab.

That may help you while dragging the nodes around making/getting it to work.

6

Send them to separate outputs then just join those outputs together.

1 Like
7

My approach here would be to publish them all directly to a local MQTT broker. Then I would use MQTT In nodes with appropriate topics configured to use the values wherever necessary. So for example if I have a dashboard node which is supposed to display the value for a particular topic then I would just need an MQTT In node feeding directly into the dashboard node. This approach might dramatically simplify your flows.

What dashboard node type are you seeing a flicker when you send the same value again? I have never noticed that.

8

Of course it would be much easier, if you have control of the TCP server, if it could publish direct to MQTT, either a broker on the server or on the node red machine or elsewhere on the network. Then you would not need to mess about with TCP.

9

Hi, thanks you all for taking time to answer.

Concerning the TCP server, I dont have any kind of control on it, so I just have to deal with what is being received from that guy, with the help of its API documentation.

Having that discussion with you guys made me think differently about what I do, and now I'm using a bit of filter/switch nodes, but actually, while they help a little bit, they don't provide a big change.
I now have a better understanding of the NR concept, and tweaked my function nodes somehow to manage different msg correctly :

Based on msg.topic received, sometimes part of the code only parses and stores flow/global variable, but nothing else (return null;)
When a different kind of msg.topic is received, then I make use of the received payload and maybe some other msg properties, and also attach some stuff from the flow/global variable previously stored.
It seems to me I'm on the right way, and close to achieve what I want to do.

My future work would be to reduce the number of flow/context variables, to avoid using a variable for each string content, but instead have a variable with an array containing all relevant information for a specific purpose.
Not that hard to do, but I have to clean the way the flow array would be partially updated when receiving a specific msg, based on the topic, without conflicting with the previously stored properties of that variable ( but I suspect I only have to improve a little bit my JS knowledge)

Cheers,

Jerome

1 Like
10

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