One gRPC API for
every industrial protocol.

The problem

Stop writing a different client for every PLC.

Every industrial protocol has its own wire format, addressing scheme, and quirks. The gateway absorbs all of that: your application talks one gRPC API and the gateway drives the device.

The same protocol logic gets re-implemented in every SCADA, HMI, and edge collector. Voltrus Gateway uses the mt-* crates, the protocol engines that also power the MacTools apps, as the single implementation. SCADA shrinks to SCADA concerns; protocol bugs get fixed once.

How it works

One client. Any device. Any protocol.

Point the gateway at a device and talk to it over gRPC. Connect, read or write typed tag values, then subscribe for live updates. The same three calls regardless of protocol.

Features

A single binary that replaces a stack of clients.

One canonical, cross-platform implementation of every protocol your plant uses, self-hosted, type-preserving, with native streaming subscriptions.

Supported protocols

Read, write, and subscribe on every protocol below.

Full read, write, and subscribe on seven industrial protocols, all over the same gRPC surface.

# one client, any device: the full gRPC surface
rpc OpenSession(ConnectRequest)     -> ConnectResponse
rpc ReadTags(ReadTagsRequest)       -> ReadTagsResponse
rpc WriteTag(WriteTagRequest)       -> WriteResult
rpc SubscribeTags(SubscribeRequest) -> stream TagUpdateBatch
rpc Discover(DiscoverRequest)       -> DiscoverResponse

SDKs

Talk to the gateway from your own code.

Official Python and TypeScript gRPC clients ship to licensed customers on request from [email protected]; they are not on PyPI or npm yet. They wrap the typed API the gateway exposes: server-side sessions, reads and writes of type-preserving tag values, tag browsing, and streaming subscriptions. Where the SCADA SDKs speak REST to the SCADA server, these speak gRPC to the lightweight 24/7 protocol layer.

Subscribe once and the gateway pushes an initial batch, then sends a new one only when a value or its quality changes. Polls that fail while a device is down arrive as per-tag errors and quality stamps instead of killing the stream, and values return when the device recovers. Both SDKs ship a subscribe_24x7 example with reconnect and backoff for unattended use.

from voltrus_gateway import VoltrusGateway

with VoltrusGateway("http://127.0.0.1:50061") as gw:
    session = gw.connect("modbus", ip="192.168.1.10", unit_id=1, endianness="big")

    tags = [{"name": "temperature", "address": 0, "reg_type": "float32",
             "register_area": "holding"}]
    for tv in gw.read_tags(session, tags):
        print(tv.tag.modbus.name, tv.value.double_val, tv.quality)

    gw.write_tag(session, tags[0], 72.5)   # -> WriteResult(success, error, latency_ms)
    gw.disconnect(session)

import { VoltrusGateway, valueOf } from "voltrus-gateway";

const gw = new VoltrusGateway("http://127.0.0.1:50061");
const session = await gw.connect("modbus", { ip: "192.168.1.10", unitId: 1, endianness: "big" });

const tags = [{ name: "temperature", address: 0, regType: "float32", registerArea: "holding" }];
for (const tv of await gw.readTags(session, tags)) {
  console.log(tv.tag.modbus?.name, valueOf(tv.value), tv.quality);
}

await gw.writeTag(session, tags[0], 72.5);   // -> WriteResult { success, error, latencyMs }
await gw.disconnect(session);
gw.close();

Driving the SCADA server instead? See its SDKs.

FAQ

Questions engineers ask.

Also from Voltrus

More from the Voltrus platform