In essence, you already have manual configuration...
So if you set an env var for the port number then you can pick that up in the flows as well as for launching node-red on that port.
Is that not possible/suitable?
I can equally well put the port value into the configuration of the node as putting it into an ENV.
I woul like to avoid having to explicitly enter it at all. There is a significant difference in having to manually enter configuration compared for a system to be self configured.
I am not interested in various ways to manually configure the value of the endpoint, I already knew that (see initial post). I am interested to find out it is possible to find out the endpoint without ANY manual configuration.
I know now, that node-red code has no insight about its port number and could not provide it.
Ok, let me approach this from a different angle.
How do you currently set the port number that node-red starts on?
That is of no interest for me, since I want to be able to deploy the components into any node-red instance.
Yes and if you don't change the port number it will be 1880 and you will know it.
Fwiw and for anyone else following along, the point I was trying to get to is: if you go to the effort or setting a non std port number, do it in a way that can also be read inside Node-RED.
As you are not interested in that as being a viable solution and that to me, you are coming across as a bit rude when I am trying to help you (in my free time) I think I'll bow out here.
Good luck
That will not work in case you run several node-red systems on the same host.
Sorry, if I come across as rude, I only want to fulfill the requirements I am facing.
Thank you very much for your time and efforts.
Are you wanting to this on systems that you have control over, or do you want to install flows/nodes on other systems?
The latter.
OK, I am out of ideas then.
Ok, thanks.
The important thing for me is to discover any solutions that may exist. Before my initial post I tried to find some solution and when not found I created the post, to either find a solution or get confirmation that no solution exists.
Until anyone shows differently I accept that the problem could not be solved and I will have to deal with that, in some way. This is life 
Thanks
This will need some tweaking to make robust.
but here is 1 solution (if I understand this discussion)
i.e use netstat to find out what port Node RED is using, and use that to form the URL
[{"id":"9d0e2e7ea51dfa85","type":"exec","z":"2d7bf6e3.84c97a","command":"netstat -nlp|grep node-red","addpay":"","append":"","useSpawn":"false","timer":"","winHide":false,"oldrc":false,"name":"","x":430,"y":760,"wires":[["fbf516c0f717b215"],[],[]]},{"id":"11ddd3e12cd90511","type":"inject","z":"2d7bf6e3.84c97a","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":130,"y":750,"wires":[["9d0e2e7ea51dfa85"]]},{"id":"d788701921c9de17","type":"debug","z":"2d7bf6e3.84c97a","name":"debug 10","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":875,"y":745,"wires":[]},{"id":"fbf516c0f717b215","type":"change","z":"2d7bf6e3.84c97a","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"$split( $split(payload, ' ', 30)[15],':') [1]\t","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":675,"y":745,"wires":[["d788701921c9de17"]]}]
EDIT
For more than 1 instance on the same machine - might not be great, but its all I have.
Thanks, but as you point out it does not solve the case of multiple instances on the same host.
@helander Is this still a requirement?
@Steve-Mcl,
A Node developed to work with the Admin API within the flow is something I have put the easy-bake oven to pre-heat on for.
This should be a none-invasive creation, what is the thought of the community here?
I have some preliminary work done - but want to gauge the interest before I continue.
in essence.
- Asks for the endpoint/Method ->
POST:/flows - Creds
- Body (where applicable)
The output will be a passthrough of the response, and the Node status will, again, be a passthrough of the HTTP Response header (status code for example).
this will use the got library
Of-course this is just a contributed Node, but still, want to gain interest.
I have seen a few discussions involving Admin API within the flow - hence my attempt to fill this "hole"
Could you just use the HTTP Request Node? Absolutely - but having a Node to provide the ability without much set up (i.e requesting auth, using the correct port, uri etc etc) seems a niche area to fill?
Yes, this is still a requirement.
I think the devil is in the details here -- is this 'node' running in the same server downstream of the http-in node used to serve the admin client flow you created? If so, then you will have all the information you need inside the msg.req object.
But if this api calling node is part of some other unrelated flow within the same node-red server, then I think your only hope is to interrogate the settings.js properties.
The settings.js file in the node-red home directory is simply a javascript module file that is require()'d when node-red is started. It's exported property values are exposed to function and custom nodes under the object property name RED.settings. So yes, it will always be available -- although it's content has changed over the years.
I think the reason why the javascript inside a node cannot know what url(host:port/path) was used to access it, is because it's running behind an express server which uses the settings to create the http listeners and routes. I know that the ui_builder nodes have access to the express routes, because they manipulate them based on how the nodes are defined.
In fact, I would suggest using ui_builder to "host" your admin application, and to encapsulate your admin api flows. Essentially, you would replace your admin http-in endpoint with a ui_builder node using the same path name.
Thanks for the input.
First, there is no http-in node in my solution.
I need to look into the ui-builder too see if that could be my way forward. Thanks for the hint.
Since I have very little knowledge about the node-red internals, please understand that I fully understand if my following view points are ’unrealistic’.
In case a node would be provided with an interface that basically exposes the functionality of the HTTP admin interface, my primary take on this would be a native Javascript interface, i.e. with no network protocols involved. I guess that the underlying Javascript functions called by the HTTP admin interface implementation, would also be possible to call from the node itself (possibly via some helper interface layer). But as I said, I have not really any clue if that kind of solution is realustic.
I case anyone knows how such an interface could be implemented, any hints on how to do it woul be of interest - I am in that case willing to do some experimenting.
I think we are missing some details here... how can you use a node-red flow to serve your admin client pages without using the http-in node to serve those pages? Your small admin client IS invoked via an http/s url in the browser, right???
The ’small admin client’ gets it input events from Inject nodes. By clicking the ’button’ on a specific Inject node, a specific admin task is triggered.
So there are no http input nodes involved.
Ok, then that makes sense, thanks for the clarification. Sounds like you are trying to use the editor as a control "dashboard" ;*) which is an anti-pattern. The more "node-red" way of working is to trigger the flows from a browser page sending an HTTP GET or POST request to your admin client...
If you replace your inject nodes with http-in nodes, you can trigger the same admin events that way -- with the added benefit of having the incoming msg.req object with all the information about the host:port/path that was used to trigger it. You would use this "action" url instead of the "editor" url to trigger the flow.
At the end of each flow you would return the results of the admin action using an http-out node. If the flow succeeds, then return a statusCode 200 in the msg.headers array -- otherwise, return a different statusCode value (e.g. 500 for server error, 400 for bad request, or even 403 unauthorized).
