Connect a device
RTU, TCP, TLS, endpoint discovery, retries, and lifecycle.
Connect a device
A connection profile answers where the device is and how bytes reach it. It does not start views or define decoding. Busloom keeps one active serialized connection so reads, writes, scans, automation, and diagnostics agree on the same transport history.
| Mode | Use it for | Parameters that must match | First failure to check |
|---|---|---|---|
| RTU | USB–RS485 / serial | Port, baud, parity, data bits, stop bits, Unit ID | Port ownership, wiring, termination, framing mismatch |
| TCP | Direct device or gateway | Host, port, Unit ID | Routing, firewall, gateway Unit ID |
| TLS | Encrypted Modbus/TCP | Host, port, Unit ID, CA/pin, optional client cert/key | Trust chain, hostname, certificate path, client identity |
RTU setup
Connect the adapter
Refresh/discover ports and identify the adapter by system path. Close any terminal or vendor tool that may own it.
Match serial framing
Copy baud, parity, data bits, and stop bits exactly. A wrong Unit ID can still produce silence, but wrong framing usually makes every Unit ID fail.
Find the Unit ID if unknown
Run Unit-ID discovery. It probes IDs 1–247 with one FC03 request at PDU 0 and accepts both data and valid exception responses as evidence of a device.
Connect, then inspect Health
A successful open only proves the OS port opened. Perform a read and verify a completed exchange in Raw Traffic.
TCP and TLS setup
For TCP, start with the documented host, port, and Unit ID. Port 502 is conventional, not mandatory. For TLS, prefer normal CA verification. A local certificate pin is machine-specific and is not written to the project. Skip verification and certificate paths belong to the selected project profile; use skip verification only for deliberate development setups.
Discover the route when the endpoint is unknown
| Discovery | Scope | Result | Important limit |
|---|---|---|---|
| Serial ports | Local workstation | Lists available system ports before a profile is configured | A visible port proves enumeration, not wiring or Modbus traffic |
| RTU Unit IDs | Selected port and framing | Probes a bounded Unit-ID range and accepts data or a valid Modbus exception as evidence | Standard RTU discovery uses responding addresses 1–247; Unit ID 0 is broadcast |
| TCP / TLS network | Selected interface and bounded IPv4 subnet | Finds active hosts, tests their TCP ports, and reports confirmed Modbus endpoints as IP:port | A large subnet or many active hosts can produce substantial traffic |
TLS discovery identifies a listening Modbus endpoint independently from the profile's final trust decision. An untrusted or mismatched certificate therefore remains visible; certificate verification is resolved when you apply the endpoint and connect with the intended profile.
Connection lifecycle
- Connected
- The transport is open. It does not imply any source view is running.
- Degraded / retrying
- A request failed and the configured retry/reconnect path is active.
- Disconnected
- The transport is closed or the retry policy was exhausted. The next operation may reopen it on demand.