Not really a protocol choice, a wiring choice. Same data model, same registers, entirely different operational life.
| Modbus RTU | Modbus TCP | |
|---|---|---|
| Specification | Modicon Modbus, serial framing with CRC | Modicon Modbus, TCP encapsulation (Modbus-TCP) |
| First published | 1979 | 1979 (serial), 1999 (TCP) |
| Transport | RS-485 / RS-232 multidrop, typically 9600-115200 baud | TCP, port 502 |
| Data model | Identical to Modbus TCP, the same registers and coils, different framing. | Flat 16-bit registers and single-bit coils. No types, no names, no metadata: a register is a number at an address. |
| Discovery | None, plus you also need the bus address, baud rate, parity and stop bits. | None. You need the vendor's register map, usually a PDF. |
| Security | None. Physical access to the bus is full access. | None in the base specification. Whatever the network gives you. |
| Polling or subscription | Polling, strictly one master per bus, request/response with turnaround delays. | Polling only. The client asks; the device answers. |
| Implementation complexity | Low protocol complexity, real physical-layer complexity: termination, biasing, cable length, ground loops. | Lowest of any protocol here. A working client is ~200 lines. |
| Typical industries | Retrofit and brownfield. Meters, VFDs, older instrumentation. | Everything. Drives, meters, inverters, sensors, PLCs, BESS. |
| Forge support | Adapter shipped (same adapter as Modbus TCP). | Adapter shipped. 19 verticals mapped. |
Strength. Runs over two wires for a kilometre. No switch, no IP stack.
What it costs you. Bus-limited throughput. One slow device delays every other device on the loop.
Modbus TCP adapter →Strength. Universal, trivial to implement, works on hardware from 1985.
What it costs you. Carries no semantics whatsoever. Scaling, byte order and register meaning all live outside the protocol.
Modbus TCP adapter →The register map is identical, so anything that reads one reads the other after a framing change. What differs is everything around it: bus arbitration, cable runs, and the fact that one slow RTU device delays every other device on the loop while a slow TCP device delays only itself.
Forge is not an argument for a protocol. It is the layer that makes the choice stop mattering downstream: 2,086 curated mappings across 13 protocol adapters, resolving to 985 canonical fields defined with enforced units and physics bounds.
Two devices, two protocols, two vendors, two entirely different tag names, and one canonical field out. Both of these are real mappings from the corpus, not illustrations.
Same field: active_power_kw. Same unit contract, same physics
bounds, same shape. Your query does not need to know which protocol the reading
arrived on.