What's new

What changed in each release, for the person upgrading. Every release also has a full changelog on its GitHub release, and the install guide says what to check when you upgrade.

0.0.20

Released 2026-11-11 · GitHub release

Note

This release also delivers 0.0.19, which was tagged but never published.

OPC UA structured values in the default package (tedge-dot-c)

The C build now reads OPC UA structured values, as the Rust build does since the previous release. You no longer need tedge-dot-rs to read one field of an ExtensionObject. See doc/connectors/opcua-connector-spec.md §3.7.

• address.field selects a field of a structure (Motor.Current, Items[1].Value), decoded with the DataTypeDefinition the server publishes.
• address.index selects one element of an array variable.
• A mode = "raw" point on a structure publishes the encoded body, with addr.encoding_id and addr.data_type.
• DateTime, LocalizedText, StatusCode, Guid, NodeId, ExpandedNodeId and QualifiedName values are read as string (DateTime also as int64, StatusCode also as uint32).

Configurations that used field or index with the C build loaded before but gave bad samples. They now give values, with no change to the configuration.

The C build keeps its fixed value sizes: a raw structure body longer than 256 bytes and a bytes value longer than 127 bytes are bad samples that name the limit, and string values are cut at 255 bytes, as other C string values are.

0.0.18

Released 2026-11-10 · GitHub release

Note

This release also delivers 0.0.17, which was tagged but never published.

tedge-dot-c is now the recommended package

The documentation now recommends tedge-dot-c by default: it is about 25 times smaller, runs down to glibc 2.17 and ships every protocol, including the PROFIBUS-DP preview. Choose tedge-dot-rs when you need one of the features only the Rust build has (SNMPv3 with SHA-2 or AES-192/256, OPC UA structured values, the deprecated Basic128Rsa15 policy, CAN FD); the package picker helps you decide.

• Nothing changes for an existing install: both packages are still built and released, and a config, a flow or a cloud integration works unchanged with either.
• Whether both packages remain in the final product is not decided yet.

A documentation site

tedge-dot now has a documentation site at https://thin-edge.github.io/tedge-dot/: task-first guides for every protocol, the reference pages rendered from doc/, and three tools that run in the browser:

• a config builder that writes a connector config and checks it against the contract schema as you type;
• a package picker that says whether tedge-dot-rs or tedge-dot-c suits your gateway, and why;
• a report-policy playground that shows what a report table publishes on a signal of your choice, using the same rules (and test vectors) as the connectors.

The Markdown in the repository stays the source: edit doc/ and the site follows.

CAN bus, CANopen and PROFIBUS-DP are marked as previews

The CAN bus, CANopen and PROFIBUS-DP connectors are now labelled preview in the README and the documentation. They are tested in CI against simulators (a virtual SocketCAN bus and a PROFIBUS-DP slave simulator) but not yet on real equipment, so expect rough edges and changes to their configuration.

If you run one of them on real hardware, please tell us how it went.

Measurement output: batched measurements from the connector

A connector can now publish thin-edge measurements itself, hundreds of readings per message, instead of one sample per reading for the ot-measurement flow to convert. Set output = "measurements" in the [connector] table. No flow runs for a measurement, which takes most of the work off the mapper at high reading rates. See doc/measurement-output.md.

• Opt-in: without output, a connector publishes samples exactly as before.
• batch = { group_by = ... } chooses how readings with different timestamps are grouped: "time" (default, nothing moved or lost), "frame" (a window) or "sample" (a fixed rate).
• Samples are still published for points with alarms, events or parameters, and for points with sample = true.
• The OT Connector Contract is now version 0.2.0 (§5.4, §5.5, measured, outputs). The additions are optional and do not appear in the default output.

Behavior and API changes. These apply without output = "measurements":

• Action needed if you use the measurement-series alarm or event (a series in the ot-alarm or ot-event params.toml): that mode moved to the new ot-alarm-series and ot-event-series flows, and ot-alarm and ot-event no longer subscribe to measurements. The package installs the new flow with your params file on upgrade; check that /etc/tedge/mappers/c8y/flows/ot-alarm-series/ (or ot-event-series/) exists. If you install the flows by hand, copy the new flow from /usr/share/tedge-dot/flows/.
• Every sample of one read call now has the same ts, the time the call completed. In the C build, a module without read_points (Modbus, for example) uses one time per device pass. Points that were read together used to have times a few milliseconds apart.
• Pushed OPC UA values in the C build now carry the server’s source timestamp instead of the time they arrived, as in the Rust build.
• For module authors: the Rust Sample has a new public field, source_ts. A module that builds a Sample with a struct literal must add source_ts: None (or the protocol’s own time). The C tdot_sample_t has a new last member, source_ts_ms, so modules must be recompiled against the new header; modules that call tdot_sample_init need no source change.

Fewer measurement messages with group_by = "frame"

In measurement output, a frame no longer ends when a point changes twice within the window. The second value goes into a second message of the same window, the third into a third, and all of them are published when the window ends. A device with 1,000 changing points now publishes a few messages per window instead of one for every 30 to 40 values, so a longer window now saves mapper CPU. See doc/measurement-output.md.

• Nothing to configure. The examples now use window = "500ms", which suits most pushed telemetry.
• Behavior change for existing frame users: a repeated point’s earlier value is published at the end of the window instead of at once, still within the window plus one pass.
• Message times of one measurement topic now always increase. When source times jitter, a message can be stamped 1 ms after the previous one instead of with its first reading’s time, so a point’s values reach Cumulocity in the order they were read.
• The OT Connector Contract is now version 0.2.1 (§5.5).

Mean, minimum and maximum per period in measurement output

A connector in measurement output can now publish, for every point and period, the time-weighted mean, the minimum, the maximum or the last value, instead of one sampled reading. It accounts for every reading of the period, so a spike or a drift between two published values still shows. See doc/measurement-output.md.

[[device]]
name  = "line1"
batch = { aggregate = ["mean", "min", "max"], every = "1s" }   # temp_mean, temp_min, temp_max

• aggregate = "mean" keeps the point’s series name; a list publishes <series>_<aggregate>.
• The mean is weighted by how long each value held, so change-only pushed data averages correctly.
• An aggregated point cannot also have a report policy; the configuration is refused.
• The OT Connector Contract is now version 0.3.0 (§5.5, batch.aggregate).

Devices read in parallel

A connector now reads its devices in parallel, and sends up to four Reads at once to an OPC UA server, in both builds. A connector used to read one device after another, one request at a time, so its throughput was set by the PLCs’ round-trip times: with 20 ms per read it stopped at about 22,000 readings/s (16,500 in the C build) while its CPU idled. Measured on the same host, one connector now reads 64,000 readings/s from 64 devices in both builds, and one OPC UA device with 20,000 nodes about 64,000 readings/s with the default budget, 80,000 with max_inflight = 8. See doc/concurrent-reads.md.

• New max_inflight (default 4) on [connector] or a device: requests in flight to one endpoint (a host and port, a serial port or a CAN bus), shared by every device on it. A bus always carries one request at a time. max_inflight_total (default 32) bounds all endpoints.
• A server that answers busy (BadServerTooBusy) gets fewer requests, and the refused one is sent again.
• Behavior change: devices on different endpoints are read in parallel, and OPC UA devices get up to four Reads at once. max_inflight = 1 sends one request at a time to each endpoint.
• Polls now run on their interval’s grid, so a 1 s poll no longer runs every 1.0 to 1.2 s.
• The capability descriptor lists the endpoints (endpoints). The OT Connector Contract is now version 0.4.0 (§5.6).

Config workbench

The config builder and the report-policy playground are now one page, the config workbench (the old links redirect). Build a connector configuration and try it before you deploy it, in three steps that share one state:

1. Signals: up to four simulated signals, each with a behaviour and an optional outage, or one of the examples.
2. Configuration: the config builder, for every protocol, with a point for each signal. Set report and batch on [connector] or on a point, and a point’s poll_interval, sampling_interval or subscribe; a point inherits what it does not set, as on the gateway. A demo config runs as well: its point library (points_from) is resolved as the connector does. Points and less used sections fold away.
3. Outcome: which package runs the configuration, what each point’s effective report policy publishes, and how measurement output batches it: the three batch policies (time, frame and sample, with or without aggregates) side by side, which signals each measurement is missing, which samples are not sent, and the measurement Cumulocity stores.

Its report and batching engines pass the same test vectors as the Rust and C SDKs.

The config builder can now set output, max_inflight, max_inflight_total, batch (with aggregate), and per point poll_interval, sampling_interval, subscribe, report and batch.

AVEVA PI Web API connector (preview), and replayed history in the reporting policy

A new aveva-pi connector reads PI points and AF attributes from an AVEVA PI System through the PI Web API, in both builds. It replaces the community thin-edge-aveva-pi-connector. See the AVEVA PI guide and doc/connectors/aveva-pi-connector-spec.md.

The connector is a preview: it is tested in CI against the project’s PI Web API simulator, but not yet against a real PI System, so expect rough edges and changes to its configuration. If you run it against a real server, please tell us how it went.

• Points are addressed by tag, PI point path, AF attribute path or WebId. WebIds are looked up once, and one request reads all of a device’s points.
• Values are pushed over the PI Web API Channels WebSocket with their PI timestamps, or polled from the archive (delivery = "recorded"), or read as current values (delivery = "snapshot").
• After an outage or a restart, each pushed point catches up from the PI archive, from a cursor kept in /var/lib/tedge-dot/aveva-pi, bounded by backfill.max_age and backfill.max_events.
• Writes post a value to the PI stream, so PI points can be Cumulocity device parameters.
• TLS is verified by default. Authentication is Basic, Bearer or a client certificate, with secrets read from files that management commands cannot change, and never over plain HTTP. Kerberos is not supported.
• The packages install /etc/tedge/plugins/ot/aveva-pi.toml with no devices. Users of the community plugin: see doc/migration/aveva-pi-plugin.md, which includes a script that converts its configuration.
• Reporting policy (all connectors): a module can mark pushed samples as replayed history. min_interval and debounce then measure time on the samples’ source time, so a backlog is reduced the way the live stream would have been instead of collapsing to two values. The OT Connector Contract gains rule 7 in §5.3.

AVEVA, PI System and PI Web API are trademarks of AVEVA Group Limited or its subsidiaries.

0.0.16

Released 2026-10-12 · GitHub release

Note

This release also delivers 0.0.15, which was tagged but never published.

OPC UA method calls

A point can now be an OPC UA method: access = "call_method" with address = { object_id, method_id, inputs = [...] }. The new call-method command takes arguments and returns the method’s outputs. Both packages support it, with identical failure reasons.

[[device.point]]
id      = "multiply"
access  = "call_method"
address = { object_id = "ns=2;s=Machine", method_id = "ns=2;s=Machine.Multiply", inputs = ["int32", "int32"] }

• ot-registration announces a device’s methods as the retained ot_call_method command capability, and ot-command-forward routes an ot_call_method command to the connector. The outputs come back on the command.
• A method call is never retried. A call that times out may still have run on the server.
• Method ids follow the device’s namespace table (below).
• Breaking, tedge-dot-rs only: a write-only point (access = "write") is no longer polled and so no longer publishes samples, as the contract always required (tedge-dot-c already behaved this way). Declare it read_write to keep its samples.
• See doc/connectors/opcua-connector-spec.md §3.10 and contract §6.6.

OPC UA namespace tables

An OPC UA node id such as ns=3;i=1234 names its namespace by position in the server’s namespace array. A firmware update, or another instance of the same device type, can number the namespaces differently, and the id then reads a different node, or none. A device (protocol_address.namespaces) or a point library ([library] namespaces) can now record the array its ids were written against. On every connect the connector maps each index through that table to the server’s current one, and logs a namespace that moved.

• Node ids stay numeric, as copied from UaExpert. Without a table nothing changes.
• A namespace the server does not list fails only its own points (namespace not found: <uri>) and is tried again, so one the server adds later is picked up.
• Both packages support it. An older package ignores a device’s table and reads the configured index. It rejects a library that carries one.
• See doc/connectors/opcua-connector-spec.md §3.9.

---

0.0.14

Released 2026-10-09 · GitHub release

Fixes and smaller changes: see the changelog on the GitHub release.

0.0.13

Released 2026-10-07 · GitHub release

Measurement units reach Cumulocity

A point’s unit now arrives in Cumulocity with every measurement ({"value": 6.6, "unit": "l/m"}) on thin-edge.io 2.x. ot-measurement publishes the units as retained measurement metadata on te/<device>/m/<type>/meta, which the c8y mapper adds to the measurement. The measurement body is unchanged, so mappers without that support behave as before.

• The metadata is published only when a unit appears, changes or goes away, one message per measurement type. It survives a mapper restart.
• If you published unit metadata by hand as a workaround, remove that: the flow now owns these topics.
• The first measurement after a unit appears can still go without it.

Config changes are applied on their own

The service now notices when its config files, or the point libraries they reference, change. It applies the change within a few seconds, with no systemctl reload needed, whether the file was written by thin-edge.io configuration management, a provisioning tool or an editor.

• It runs the same reload as SIGHUP, which keeps working: unchanged connectors keep running, a changed one applies its file in place, and an invalid file is logged and ignored.
• A file is read only once it has stopped changing. A save that lands while a reload runs gets a reload of its own.
• TEDGE_DOT_CONFIG_WATCH_INTERVAL sets how often the files are checked (default 2s).
• To reload only on SIGHUP as before, run tedge-dot run --no-watch, for example in a systemd drop-in (see the comments in the unit file), or set the variable to 0.
• Workarounds that send SIGHUP after a configuration update can be removed.
• The C package now starts with an empty config directory as the Rust one does, and waits for a config to appear.

0.0.12

Released 2026-10-07 · GitHub release

OPC UA structured values (tedge-dot-rs only)

The OPC UA connector reads custom data types (structures) from any server without compiled-in type definitions. Give a point address.field ("Speed", "Motor.Current", "Items[1].Value"): the connector reads the type’s DataTypeDefinition from the server once per session and publishes that field as an ordinary sample, so map, report and every flow apply. Several fields of one node share one read. Also new:

• address.index selects one element of an array variable.
• A mode = "raw" point on a structure publishes its encoded body, with the type named in addr, for a flow to decode (servers that do not describe their types).
• DateTime, LocalizedText, StatusCode, Guid, NodeId, QualifiedName and ByteString values can be read; the point’s datatype picks the form, e.g. DateTime as RFC 3339 text or Unix ms.

Field and element points are read-only. A point without field or index is unchanged, except that a raw point on a structure now publishes good samples where it published bad ones. The C package does not support this yet. See doc/connectors/opcua-connector-spec.md §3.7 and the demo-sim-structures point library.

0.0.11

Released 2026-10-06 · GitHub release

Value mapping (map)

A point can now declare a value map, which the connector applies in both directions for every protocol. It maps state codes to labels, using exact values, lists or inclusive ranges with a catch-all default, and it converts with as = "number" | "string" | "bool", so numeric text becomes a measurement. Samples carry the mapped value and add the original as source_value.

Writes carry the mapped value as well, and the connector maps it back to the device’s code. This covers the write and write-batch commands, the CLI and Cumulocity device parameters, where tedge-dot describe offers a mapped parameter’s labels as a choice. See doc/mapping-values.md.

• A point without map is unchanged.
• The demo point libraries show the feature: the Modbus boiler_state maps by range, and the OPC UA run_state is an enumerated parameter.

Literal device parameters (meta.parameter.fragment)

A device parameter no longer has to sit inside an object. With meta.parameter = { fragment = "pump_speed" } the point’s value is published as the fragment itself, so the managed object holds "pump_speed": 42 rather than an object around one value. tedge-dot describe renders it as a primitive Cumulocity definition (number, boolean or string), and an edit from the Parameters tab carrying the bare value is written to the point.

• The name is used verbatim, like set. It cannot be combined with set, group or key, and one name cannot be both a literal and a set. describe refuses either.
• Configurations without fragment are unchanged.

0.0.10

Released 2026-09-18 · GitHub release

Report by exception (report)

A point, a device or [connector] can now declare a reporting policy, applied by the connector itself for every protocol before a sample is published: on_change, deadband (absolute, or a percentage such as "2%"), min_interval (a change held back is published when the interval ends), max_interval (a heartbeat that publishes a fresh reading of a flat signal, reading a subscribed OPC UA node on demand) and debounce. See doc/reducing-data-volume.md.

• The packaged Modbus, OPC UA, CANopen and PROFIBUS configs set [connector] report = { max_interval = "30m" }, so a device whose values never change stays available in Cumulocity. This applies to fresh installs only: an existing /etc/tedge/plugins/ot/*.toml is kept on upgrade. To opt in, add that line to its [connector] section and reload the service. Without a report anywhere, every reading is published as before.
• The ot-measurement flow’s on_change, deadband, min_interval and debounce settings, and the same keys in a point’s meta, are deprecated. They keep working; move them to the point’s report table, and do not use both.
• tedge-dot-c, CAN bus: a signal is now published once per received frame, as in tedge-dot-rs, instead of republishing the last frame on every poll.

0.0.9

Released 2026-09-18 · GitHub release

Note

This release also delivers 0.0.7 and 0.0.8, which were tagged but never published.

Fixes and smaller changes: see the changelog on the GitHub release.

0.0.6

Released 2026-09-15 · GitHub release

Fixes and smaller changes: see the changelog on the GitHub release.

0.0.5

Released 2026-09-15 · GitHub release

Fixes and smaller changes: see the changelog on the GitHub release.

0.0.4

Released 2026-09-14 · GitHub release

Fixes and smaller changes: see the changelog on the GitHub release.

0.0.3

Released 2026-09-13 · GitHub release

Fixes and smaller changes: see the changelog on the GitHub release.

0.0.2

Released 2026-09-13 · GitHub release

Fixes and smaller changes: see the changelog on the GitHub release.

0.0.1

Released 2026-09-13 · GitHub release

Fixes and smaller changes: see the changelog on the GitHub release.