# IoTClient for C# industrial PLC and Modbus access

> IoTClient is a .NET Standard 2.0 library for Modbus, BACnet, and named PLC communication clients. It fits C# applications that need direct device reads and writes, but its sparse setup guidance and old published release require careful evaluation before production adoption.

**zhaopeiym/IoTClient** — This is an IoT device communication protocol implementation client, which will include common industrial communication protocols such as mainstream PLC communication reading, ModBus protocol, and Bacnet protocol. This component is open source and free for life, using the most relaxed MIT open source agreement, you can modify and commercial use at will (commercial use please evaluate and test).   这是一个物联网设备通讯协议实现客户端，将会包括主流PLC通信读取、ModBus协议、Bacnet协议等常用工业通讯协议。本组件终身开源免费，采用最宽松的MIT开源协议，您可以随意修改和商业使用（商业使用请做好评估和测试）。

- Repository: https://github.com/zhaopeiym/IoTClient
- Stars: 1,690 · Forks: 488
- Language: C#
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/zhaopeiym-iotclient

## IoTClient's direct industrial communication scope

IoTClient targets applications that must exchange data with industrial controllers rather than consume data through a separate cloud service. The repository description names mainstream PLC communication, Modbus, and BACnet as its intended protocol coverage. Its README also provides named clients for Siemens, Mitsubishi, Omron, and AllenBradley equipment. This makes the library most relevant to C# developers building device-facing utilities, data collectors, control services, or equipment integrations where the application owns the connection and protocol details.

The project is not presented as a general IoT application framework. The documented usage centers on client construction, opening a connection, reading registers or values, and writing device data. That narrow scope can be useful when an application needs direct communication with a known PLC or Modbus server. It also means the caller must already understand the relevant industrial protocol. For example, Modbus operations require an address, station number, data type, and often a function code. The library does not abstract those vendor and device concepts into a universal device model.

IoTClient is based on .NET Standard 2.0, which the README says permits use across .NET applications on Windows and Linux, including Raspberry Pi. No platform-specific setup matrix is documented. The available examples and naming suggest a reusable managed library rather than a command-line program or a hosted service.

## How IoTClient moves reads and writes

The clearest documented data flow appears in the Modbus examples. A client is constructed with the target IP and port. Calls such as `Write` and `ReadInt16` receive the device address and protocol parameters, then return an operation result object. For a read, the result exposes `IsSucceed`, `Err`, `Requst`, `Response`, and `Value`. This design gives the caller both the decoded value and diagnostic details about the request and response.

Connection handling is explicit enough to affect application design. The README states that if a connection is not open, each read or write automatically opens and closes it. It warns that this reduces operation efficiency and recommends calling `Open` and closing the connection manually. Persistent connection handling therefore belongs in the calling application's lifecycle. The README does not document automatic reconnection after a broken socket or a retry policy.

Protocol operations are exposed through typed methods. The Modbus examples include signed and unsigned 16-bit, 32-bit, and 64-bit values, as well as `float`, `double`, coil, discrete input, and string access. `BatchRead` accepts a list of `ModBusInput` objects with an address, data type, function code, and station number. This provides batching at the request-description level, although the README does not specify transaction scheduling, partial-result behavior, or concurrency guarantees.

## NuGet installation and a first ModbusTcp read

The README directs users to the NuGet package and gives the following Package Manager command. The reader should see the `IoTClient` package added to the target .NET project through Visual Studio's NuGet interface.

```powershell
Install-Package IoTClient
```

A minimal documented flow writes a signed 16-bit value, opens the connection, and reads it. The addresses and station number in this example come directly from the README. It assumes a Modbus TCP service is reachable at `127.0.0.1` on port `502`.

```csharp
ModBusTcpClient client = new ModBusTcpClient("127.0.0.1", 502);
client.Write("4", (short)33, 2, 16);
client.Open();
var result = client.ReadInt16("4", 2, 3);
```

The writer should inspect `result.IsSucceed` and `result.Err` before using `result.Value`. `result.Requst` and `result.Response` are also available for diagnostics. The example does not show the namespace imports or a `Close` call, so the complete compilable context must be taken from the repository tests and current project files. The README links the Modbus TCP unit test as the fuller usage reference.

## ModbusTcp versus serial ModbusRtu deployment

IoTClient contains a real deployment choice within Modbus itself. The TCP example constructs `ModBusTcpClient` with an IP address and port, while the RTU example constructs `ModBusRtuClient` with a COM port, baud rate, data bits, stop bits, and parity. Modbus TCP carries framed Modbus messages over a network connection. The documented RTU client targets a serial interface and requires the physical communication settings to match the equipment.

That difference is more than a constructor detail. A TCP deployment depends on a reachable address and port, while the RTU example depends on correct serial parameters such as `COM3`, `9600`, `8`, `StopBits.One`, and `Parity.None`. The README also lists Modbus ASCII and Modbus RTU over TCP in its document index, but the visible examples detail RTU and TCP operations directly. It would be unsafe to assume that every listed variant has identical connection management or identical coverage.

For readers choosing a protocol path, the deciding evidence should be the equipment documentation and the relevant repository test. The README does not provide a compatibility matrix that maps each PLC model, firmware, operating system, and transport combination to a supported status.

## PLC-specific address and model constraints

The repository separates several PLC families into named clients, including `SiemensClient`, `MitsubishiClient`, `OmronFinsClient`, and `AllenBradleyClient`. This is a useful distinction because PLC address spaces and communication procedures are not interchangeable merely because they all use registers. The README's table of contents includes a specific warning about Siemens PLC addresses and a section describing Siemens client practices.

However, the visible README ends before those Siemens examples. It therefore does not confirm the exact address syntax, supported memory areas, connection modes, or vendor-specific limits. This is a material limitation for anyone selecting the library. A typed API can still send an invalid address if the application passes the wrong vendor convention.

BACnet is named in both the repository description and README, but the README section visible here contains no BACnet installation or code example. The repository topics also mention sockets and TCP, yet the documentation does not provide a general network architecture diagram. Protocol support should therefore be verified at the class and test level before it is treated as confirmed production coverage.

## Failure handling and deployment boundaries

The most concrete failure-handling information in the README is attached to the returned operation result. Callers can distinguish success with `IsSucceed`, retrieve an error message through `Err`, and inspect the request and response fields. This supports logging and basic diagnostics without inventing a separate exception model that the documentation does not describe.

The automatic open-and-close behavior is another operational concern. The README explicitly says that repeated connection setup lowers efficiency and recommends manual lifecycle management. It does not document connection pooling, heartbeat behavior, cancellation, retry counts, backoff, or recovery after partial reads. Applications that must tolerate unstable links will need to establish those policies around the documented client calls rather than assume they are built in.

The examples also omit broader industrial safeguards. There is no documented audit format, role model, device simulation, rollback procedure, or safety-rated control claim. IoTClient should not be read as proof of deterministic timing or suitability for safety-critical control. The README's commercial-use notice asks users to evaluate and test the component, which is especially relevant when protocol behavior affects operational equipment.

## Maintenance, releases, and MIT licensing

The repository is not archived. Its last push was on 2026-05-12, while the latest listed IoTClient release is version 0.4.0 from 2020-09-11. That gap is important because the repository may have received code changes without a corresponding package release. Consumers should not infer that the current `master` branch and the NuGet package expose identical APIs.

The repository includes `IoTClient.Tests/`, an extension adapter project with tests, `IoTClient/`, `IoTServer/`, and a Visual Studio solution. The Modbus TCP documentation points readers to a unit test file for additional usage. Those repository elements indicate where protocol behavior can be inspected, but the README does not report test execution results, supported runtime matrix, compatibility policy, or release automation.

IoTClient uses the MIT License. The repository description says it can be modified and commercially used, while also asking commercial users to evaluate and test it. The MIT identifier and repository notice describe the stated licensing basis; they do not replace an organization's review of dependencies, device protocols, warranties, or deployment obligations.

## Conclusion

IoTClient is suitable for a C# team that already knows the device protocol, register model, and connection lifecycle, especially when the application needs the documented Modbus or PLC-specific clients directly. It is a poor choice for a team that expects a complete industrial connectivity platform, a documented commissioning workflow, or evidence of current package releases. Before adoption, verify NuGet compatibility with the intended runtime, compile the relevant client against the target PLC, and confirm how timeouts, reconnections, and unsupported device variants affect the deployment.

## FAQ

### Which development platforms does IoTClient support?

IoTClient targets .NET Standard 2.0. The README says it can support .NET development on Windows and Linux, including deployment on Raspberry Pi.

### How do I install IoTClient in a C# project?

The README links to the IoTClient NuGet package and documents `Install-Package IoTClient`. It also shows NuGet installation through the graphical interface in Visual Studio.

### How should a connection be managed for frequent IoTClient operations?

The README recommends calling `Open` and closing manually. Without an active connection, each read or write opens and closes the connection automatically, which the documentation says greatly reduces efficiency.

## Sources

- [Issues](https://github.com/zhaopeiym/IoTClient/issues)
- [License: MIT](https://github.com/zhaopeiym/IoTClient/blob/master/LICENSE)
- [README](https://github.com/zhaopeiym/IoTClient/blob/master/README.md)
- [Releases](https://github.com/zhaopeiym/IoTClient/releases)
- [zhaopeiym/IoTClient on GitHub](https://github.com/zhaopeiym/IoTClient)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zhaopeiym-iotclient