hello @marcus-j-davies
Thanks for your response. A few things changed since i posted. I learnt that the API is custom, then my work was delayed for personal reasons, so the boss went back to a previous plan. Oh well.
Just for completeness, here is the basics from a chat-GPT attempt at making it work direct from Node-RED:
TL:DR, It is a custom API so can't do it.
1. Extracted info from RemoteAPITestClient.exe.config
From the config you pasted:
1.1 WCF bindings
Two custom bindings are defined:
<bindings>
<customBinding>
<binding name="longSendNamedPipeBinding" ...>
<binaryMessageEncoding ... />
<namedPipeTransport ... />
</binding>
<binding name="longSendTcpBinding" ...>
<binaryMessageEncoding ... />
<tcpTransport ... portSharingEnabled="true" />
</binding>
</customBinding>
</bindings>
So:
- longSendNamedPipeBinding
- Protocol: net.pipe (Named Pipes, local-only)
- Encoding: binaryMessageEncoding (WCF-specific binary)
- Timeouts: long send/receive, huge message sizes
- longSendTcpBinding
- Protocol: net.tcp (TCP, not HTTP)
- Encoding: binaryMessageEncoding (WCF-specific binary)
- Port sharing enabled
- Again, this is WCF’s own binary framing, not raw JSON/XML.
1.2 The actual Nova Remote API endpoints 
This is the gold:
<client>
<!-- Endpoints for Nova remote API. -->
<endpoint
name="LocalNovaConnection"
address="net.pipe://localhost/Infratec/remoteAPI"
binding="customBinding"
bindingConfiguration="longSendNamedPipeBinding"
contract="FOSS.Nova.CoreServer.RemoteAPI.Client.Contract.INovaRemoteAPI"/>
<endpoint
name="RemoteNovaConnection"
address="net.tcp://localhost:8899/Nova/remoteAPI"
binding="customBinding"
bindingConfiguration="longSendTcpBinding"
contract="FOSS.Nova.CoreServer.RemoteAPI.Client.Contract.INovaRemoteAPI"/>
</client>
So we now know:
- Service contract:
FOSS.Nova.CoreServer.RemoteAPI.Client.Contract.INovaRemoteAPI
(this is the WCF interface your .NET proxy uses)
- Local endpoint (on same PC only):
LocalNovaConnection →
net.pipe://localhost/Infratec/remoteAPI
Binding: customBinding/longSendNamedPipeBinding
- Remote endpoint (TCP, potentially from another machine):
RemoteNovaConnection →
net.tcp://localhost:8899/Nova/remoteAPI
Binding: customBinding/longSendTcpBinding
If another PC connects over the LAN, its address would look like:
net.tcp://<NovaPCNameOrIP>:8899/Nova/remoteAPI
1.3 No HTTP / SOAP endpoint
Important: there is no basicHttpBinding, wsHttpBinding, .svc URL, or http://... endpoint defined here.
Everything is:
net.pipe://... (Named Pipes, local only)
net.tcp://... with WCF customBinding (binary)
That matches the Remote API manual: they expect clients to use their .NET proxy and WCF, not generic HTTP/SOAP.
2. What this means for Node-RED (hard truth + good workaround)
You originally asked for:
“code that i can use in Node-RED using either HTTP, Websocket, TCP, or UDP, to connect to WCF”.
Given what we now know:
- The Nova Remote API uses net.tcp + customBinding + binaryMessageEncoding.
- Node-RED’s
tcp node can only send/receive raw bytes; it does not understand WCF’s binary framing, channel handshakes, message headers, duplex callbacks, etc.
- There is no HTTP/SOAP endpoint we can just point a SOAP node at.
- WebSocket and UDP are not used for the actual Remote API calls (UDP is only used for discovery in the .NET library).
So:
Direct Node-RED → Nova Remote API is not feasible
You cannot realistically point Node-RED straight at:
net.tcp://localhost:8899/Nova/remoteAPI
and expect it to work. You’d have to re-implement the WCF protocol in JavaScript, including duplex callbacks, addressing headers, etc. That’s insane-level work and very brittle.