Skip to content
tedge-dot
AI-driventedge-dot is developed largely by AI coding agents, and it is alpha software. Check what it does before you rely on it, and report what you find.

Overview

tedge-dot connects industrial (OT) equipment to thin-edge.io. One tedge-dot binary reads and writes Modbus, OPC UA and SNMP devices, plus CAN bus, CANopen, PROFIBUS-DP and AVEVA PI Web API in preview (tested against simulators, not yet on real equipment), and publishes what it reads to the thin-edge.io MQTT broker in one protocol-neutral format. From there, thin-edge.io flows turn it into measurements, child devices, alarms, events and device parameters in the cloud.

How it fits thin-edge.io

Section titled “How it fits thin-edge.io”
tedge-dot architectureOT devices (Modbus, OPC UA, SNMP, CAN bus, CANopen, PROFIBUS-DP, AVEVA PI) are read and written by tedge-dot, which publishes protocol-neutral sample, status and command envelopes to the thin-edge.io MQTT broker. thin-edge.io flows turn them into measurements, child devices, alarms, events and parameters, and the Cumulocity mapper sends them to the cloud. Writes and parameter edits travel back the same way as commands.OT devicesModbus TCP/RTUOPC UASNMPCAN / CANopenPROFIBUS-DPAVEVA PItedge-dotone binary, one contracttransportdecodetransform · mapreport by exceptionthin-edge.ioMQTT broker · te/device/…/ot/…sample · statuscmdflows (JavaScript)measurementregistrationalarm · eventparameter statecommand forwardcommand resultCumulocity mapperCumulocitydevices · dataparameterstedge-dot architectureOT devices are read and written by tedge-dot, which publishes protocol-neutral envelopes to the thin-edge.io broker; flows shape them for the cloud, and writes travel back as commands.OT devicesModbus · OPC UA · SNMP · CANCANopen · PROFIBUS-DP · AVEVA PItedge-dottransport · decodetransform · map · reportsample · statuscmdthin-edge.ioMQTT brokerflowsmeasurement · registration · alarm · eventparameter state · commandsCumulocity mapperCumulocitydevices · data · parameters
tedge-dot moves bytes; flows make meaning. Writes and parameter edits travel back as commands.

The connector is a dumb driver. It talks the protocol, decodes primitive values, and applies what each point declares about itself: scaling and unit (transform), a value map (map) and a reporting policy (report). It then publishes generic sample, status and cmd envelopes on te/device/<device>/ot/<protocol>/....

Everything else lives in flows: small JavaScript modules that run inside the thin-edge.io mapper and are hot-reloaded without a restart. The packaged flows register each OT device as a child device, turn samples into measurements, raise alarms and events declared on a point, keep device parameters in the digital twin, and carry writes from the cloud back to the connector. Because every connector speaks the same OT Connector Contract, the same flows work for every protocol.

For many points at a high rate, a connector can publish the measurements itself, hundreds of readings per message (output = "measurements"), and keep samples only for the points that a flow still reads. It reads its devices in parallel, within a per-endpoint budget of requests in flight. See measurement output and concurrent reads.

Writes never open a second protocol session. A write, or an edit in the Cumulocity Parameters tab, becomes a thin-edge.io command that the connector carries out and acknowledges.

What you configure

Section titled “What you configure”

A connector is one TOML file per protocol in /etc/tedge/plugins/ot/:

  • [connector]: the protocol, the poll interval and defaults such as a heartbeat;
  • one [[device]] per device, with its address;
  • the device’s points, either inline ([[device.point]]) or from a point library that the device references by name with points_from, so that a fleet of identical devices shares one point list.

The service applies a changed file within a few seconds, without a restart. Every key is listed in the configuration reference, and the config workbench writes a file for you.

Two packages, one contract

Section titled “Two packages, one contract”

tedge-dot is built twice, from two maintained implementations that run the same test suites. Both packages install the same /usr/bin/tedge-dot, the same systemd service and the same configuration layout, so a config or a flow works unchanged with either. A host runs one or the other.

tedge-dot-c

The default. The C build: about 25x smaller, a glibc 2.17 floor (Debian 8 / RHEL 7 era), amd64, arm64 and armhf packages, and every protocol, including the PROFIBUS-DP preview.

tedge-dot-rs

The Rust build, for the features only it has: SNMPv3 with SHA-2 or AES-192/256, the deprecated Basic128Rsa15 policy, CAN FD.

The package picker recommends one for your gateway, and the install guide lists the differences.

Next steps

Section titled “Next steps”
Your first device in 5 minutesRead a simulated Modbus PLC from your laptop, no broker or cloud needed.
InstallPick a package and install it on a gateway.
Modbus TCP PLC to CumulocityThe whole path, from a register to a measurement in the cloud.
The OT Connector ContractThe topics, envelopes and rules every connector follows.