Question about Modbus TCP (telnet) multi-UnitId single connection support

[wsfyh666]

Hi everyone,

I would like to ask about the current status of Modbus TCP (telnet) multi-UnitId communication in FUXA, specifically regarding single-link (single socket) handling.

Background / Current Behavior

In my setup, I have multiple Modbus devices that share the same IP and PORT, but are distinguished by different Unit IDs.
my setup is Modbus TCP (Telnet)

Currently in FUXA:

• Each UnitId(SlaveId) must be configured as a separate “Connect Device”
• Each Connect Device establishes its own TCP connection
• As a result, multiple connections are opened simultaneously to the same IP:PORT
• This causes concurrent polling on the device side
• The Modbus device cannot handle these concurrent requests properly, leading to:
  • Request timeouts
  • Data not being collected reliably

Tried Solutions

• Tested different reuse option configurations
• The behavior did not match the expected goal of sharing a single TCP connection
• In addition, after enabling reuse:
  • A large number of devices experienced unexpected disconnections
  • Data polling frequently failed or became unstable
• This indicates that the concurrency issue still exists, and in some cases the situation became worse

I also noticed that most available documentation and examples focus on Modbus RTU behavior.
However, my setup is Modbus TCP (Telnet), and I could not find clear guidance specific to this scenario.

My Understanding / Questions

From my understanding of Modbus TCP behavior:

• Multiple Unit IDs should be able to share a single TCP connection
• Requests should be queued / serialized per connection, not per device
• This is especially important for gateways or devices that expose multiple Unit IDs on one IP/port

So my questions are:

1. Has FUXA already implemented support for multi-UnitId over a single TCP connection?
2. If yes:
   • How should it be configured correctly?
   • Is there an official recommended pattern?
3. If not:
   • Is this a known limitation?
   • Are there any planned improvements or recommended workarounds?

At the moment, I haven’t found an effective way to handle this scenario cleanly in FUXA, so any clarification would be greatly appreciated.

Thanks in advance.

[wsfyh666]

Temporary Workaround

At the moment, I haven’t found a native solution in FUXA for this scenario.

As a workaround, I introduced Node-RED into the architecture:

• Used node-red-contrib-modbus to handle Modbus TCP data collection
• Implemented proper request queuing to avoid concurrent access to the same IP:PORT
• Forwarded the collected data to FUXA via MQTT
• FUXA is currently used only for visualization and data consumption

This approach works reliably so far and avoids the multi-connection concurrency issue.

If anyone is interested, I can share the relevant Node-RED flow.json for reference.

[jingshui127]

https://mp.weixin.qq.com/s/JWZjV29GDDKhv9ORCKMpow
ModbusTCP转ModbusTCP小工具
.思路可以参考一下

[wsfyh666]

Yes, the overall idea is similar.
Currently, I’m using Node-RED as a data acquisition layer, where I implemented a single TCP connection with queues, which is working reasonably well for now.

From a SCADA perspective, supporting multiple Unit IDs over a single Modbus TCP socket should be a basic capability.
My expectation was that FUXA’s reuse option would enable this behavior.

That’s why I raised this question — to confirm whether:

• this use case is already supported but requires a specific configuration, or
• the current Modbus TCP implementation does not serialize requests per connection.

I mainly want to avoid misunderstanding the intended usage or missing an existing best practice.

[MatthewReed303]

@wsfyh666 this does not seem like a standard modbus TCP spec? TCP Network requires each device to have it's own IP and Port, how can you have multiple physical devices on a network sharing same IPs? This would cause IP conflict?

Anyway to simplify your node-red approach Fuxa does have node-red built in with it's own nodes so you can directly connect to Fuxa tags without using MQTT as a bridge

[jingshui127]

It is distinguished by the slave number. But FUXA indeed hasn’t implemented it well.