We are using a TCP node and that is working well.
However , the TCP Host address will be changing based on user setup.
Looking for method to have user enter the Host IP address in Dash board and pass that into the TCP node as IP address. But not having much luck.
Any ideas?
Hi. The TCP Out node doesn't allow the host to be set dynamically. It has to be hardcoded in the node.
Hi Nick,
First of all , NODE RED is incredible tool!
-TCP IP address needs to be 'hardcoded' into the node- OK, I am sure there is some good reason for this.
But it sure would be nice, since we want to avoid 'end-users/ operators' from entering into the "FLOW" to enter/change the IP. Just in case they accidentally delete / alter the other parts of the flows.
Sorry, I missed a vital piece of information in my original reply... whilst the TCP In/Out nodes are for long-held connections, the tcp-request node does let you set host/port dynamically.
Hi Nick,
I am trying the TCP Request node.
Added an INJECT node (for testing) with the IP address that we want to set the TCP to. But still not connecting.
WHat is the proper way to 'inject' in the IP address as User Defined ( not hardcoded)
The sidebar help for that node tells you how to do it. Hint - you leave the necessary fields blank and set the appropriate message properties.
Thank you Nick! I found it.
For sake of others in the community.
Setting the IP address for a TCP node can be done 'dynamically' ( from user input field)
I am new to Node-Red please explain step 3.
This should help you get started working with messages. Also read throught the node red docs and the cookbook.
https://nodered.org/docs/user-guide/messages
The only way I could get this to work was to put a Change node after the Inject node. Set two new properties, msg.host and msg.port to the appropriate values. The TCP Request node would then connect to the TCP socket but it would constantly error out with "Missing host or port value" and be non-functional.
Perhaps this methodology only really works when you open / close the socket for work (sort of silly). In my case, with my hardware device, I open it and it stays open forever.
I have since learned how to set the message parameters more appropriately, but the same issues seem to remain. If you dynamically set host and port, the TCP request node refuses to stay open even though it is configured to never return. It closes immediately after opening.
The object seems to have an "out" parameter which is set to "sit" to keep it open, but that parameter doesn't seem to be exposed.
It is highly likely that I have overlooked some tidbit, but the fact that it works perfectly if address and port are configured in the node dialog leads me to believe otherwise...
What I am driving at is the ability to be able to "configure" the IP address and TCP port via global context items sourced from say, INI files in the instance. This allows USER control over the addressing which is important. If only the person(s) with Admin rights can change these things, it creates a support nightmare. Why shouldn't a "paying customer" be able to configure the flow externally, while NOT being able to see or mess with the actual programming of the nodes? Someone educate me please.
Another interesting, undocumented 'feature' I just ran across.
Scenario is like my above post where the IP address and TCP port would be dynamically set for a TCP Request which is "never - keep connection open". An initial connect request can open the socket fine and it stays open. In my case the port is fixed at 23 and I had to run the node as root (which is another issue). Then i noticed any messages sent to the TCP Request node were met with "Host and/or port not set". On a whim, I added msg.host and msg.port to a few of the other messages and it took them, even though the node was already connected.
So, even if you set the TCP Request node to "sit" ("never - keep connection open"), any input to that node REQUIRES msg.node= and msg.port= values in the message. While this is incredibly tedious, at least it seems to be functional this way.
I am not sure what happens if you change either the address or port, but I am sure I'll find out!! 
You can set properties of (most) nodes by using environment variables from outside of Node-RED - so you can expose them that way to be configured for free... https://nodered.org/docs/user-guide/environment-variables
yeah - it's not like you have a computer to help fill them in for you...
but we will happily consider a Pull Request that fixes it if you like.
It wasn't the HOW to do it that is annoying to me, it was that that this rather important detail is not documented. It's sort of an important point. A lot of folks have asked very similar questions on the forum, and not one answer contained this information. I will dig up the github and put in a suggestion for documenting it better now that I have it figured out.
When you have dozens of controls that all have to have another node added to set these two values, YES I consider that tedious. 
I am not working on a single function "sensor" type device.
On a more serious note, is there a rationale for doing the way it is now? Logically thinking in my mind, on the devices I work with, once I connect to them, I stay connected forever, thus, if I set the node to stay connected forever, I would expect that the connect request set that state into motion. Maybe I just don't understand the use case for doing it this way.
Lastly, I also have to get WireShark cranked up to make sure that it is not tearing down and rebuilding the socket for every request that is made using this methodology. I doubt it, but I want to be sure. The application in question is largely an unattended one, meaning that the device is not readily available for hands-on tweaking and such.
And in all my crankiness, I neglected to say a huge "THANK YOU!" to those who created the Dashboard nodes. Just terrific stuff that has opened new vistas for my dev work. I really appreciate it.
Well the info sidebar for the tcp request node does say " If you leave tcp host or port blank they must be set by using the msg.host and msg.port properties. "
Of course if you don't leave them blank (eg by using the environment variable approach) then you don't need to set them - and indeed if set this way then the connection should stay open.
A little extra verbiage would have helped me avoid two days of flailing and cursing.
" If you leave tcp host or port blank they must be set by using the msg.host and msg.port properties in every message sent to the node. "
Also wondering whether it might be possible to expose the "out" property as well. It would be quite valuable to be able to change the behavior of the TCP request node as well.
Apologies that I have not gotten far enough into the "system" to even know the node creation language(s). I am a C++ and Java guy, heavily OO naturally. Perhaps once I get a bit further downstream, I can pitch in. Right now, I am resurrecting my HTML/CSS/Javascript brain cells. It's been quite a while since I use that stuff, which was all Java Servlets on Tomcat at the time.
I think we can add those extra words
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
