Book an Idako Demo

How to Implement a Unified Namespace: Plain MQTT or OPC UA

Aug 18, 2026 | Blog

This article was created with AI assistance.

A Unified Namespace is usually built on plain MQTT. It doesn't have to be — and the alternative fixes several problems MQTT-based UNS projects run into once they scale past the pilot.

1Introduction to UNS

A Unified Namespace (UNS) is a single, live, hierarchical source of truth for operational data across a plant or enterprise. Instead of wiring point-to-point integrations between every PLC, SCADA system, MES, and cloud application, every system publishes into — and subscribes from — one shared namespace. It has become a foundational pattern in Industry 4.0 and Digital Transformation initiatives because it decouples data producers from data consumers: adding a new consumer means subscribing to existing data, not building yet another custom interface to yet another data source.

The typical implementation: MQTT broker + ISA-95 topic hierarchy

The most common way to build a UNS today is around an MQTT broker as the central nervous system. Devices, PLCs, and applications publish and subscribe to topics, and the broker fans messages out to whoever is listening. The topic tree is usually organized to mirror the ISA-95 equipment hierarchy — enterprise, site, area, production line, and work cell/asset — so a topic name alone tells you where in the physical plant a value came from, for example enterprise/site/area/line/cell/tagName.

PLAIN MQTT UNS Publishers PLC / SCADA MES / gateways (custom payload & topic per source) MQTT Broker Topic tree (ISA-95 style) enterprise / site / area line / cell / tagName no browse API, no history, no request/reply Subscribers Dashboards Historian bolt-on Cloud / analytics Everything a new subscriber needs to know about the topic tree — names, structure, payload shape — has to be documented and shared out of band, because MQTT itself has no way to browse or describe what's published.

A typical MQTT-based UNS: publishers push to a broker organized as an ISA-95 topic tree; subscribers read what they need — but nothing about the tree is discoverable from the protocol itself.

Pros and cons of MQTT-based UNS

Pros

  • Lightweight, simple pub/sub model with a low barrier to entry
  • Decouples publishers from consumers — add a subscriber without touching the source
  • Huge ecosystem: open-source brokers (Mosquitto, EMQX, HiveMQ), client libraries in every language, native support in most cloud IoT platforms
  • Works well over constrained or unreliable networks
  • Easy first step — a pilot UNS can be running in days

Cons

  • Payload format is not standardized. MQTT only moves bytes; every team invents its own JSON schema (Sparkplug B helps but is adopted inconsistently and is its own layer to agree on and maintain)
  • No access to historical data. The broker only knows the latest retained value — a historian has to be bolted on separately, with its own query interface
  • No feature for synchronous requests, including transactional calls — pub/sub has no built-in request/response, so writing back to a device or invoking an action needs an entirely separate mechanism
  • No support to browse the topic structure. Topics aren't self-describing; a new client has to already know the tree from external documentation, since MQTT has no discovery or introspection API
The question this raises Is it possible to build a UNS on a protocol other than MQTT — one that doesn't have these gaps?

2An Alternative: OPC UA as the Core Protocol

OPC UA is an IEC 62541 standard maintained by the OPC Foundation, built specifically to solve the problems above. Relevant to a UNS, it provides:

  • A browseable, discoverable address space — the information model is a hierarchy of objects, variables, and methods that any client can walk and inspect at runtime, no external documentation required
  • A well-defined payload format for published data, carrying value, quality, and both server and source timestamps as standard parts of every reading — not an ad-hoc JSON shape each team has to agree on
  • True report-by-exception, with server-side monitored items supporting both absolute and percent-based deadbands, so only meaningful changes go over the wire
  • Native support for both real-time and historical data through the same address space and the same client APIs
  • Built-in support for alarms and events, not a separate system bolted on afterward
  • A lighter footprint on the wire than it gets credit for: despite MQTT's "lightweight" reputation, MQTT/JSON payloads commonly run three times or more the size of the equivalent OPC UA binary-encoded payload for the same data

OPC UA also supports a Publish-Subscribe transport mode of its own — including over MQTT — so choosing OPC UA as the core protocol doesn't mean giving up MQTT transport where it's useful; it means the payload, the address space, and the semantics riding on top of it are finally standardized.

Implementing UNS with oBox Suite

oBox Suite from One-Way Automation is a modular platform for building exactly this kind of OPC UA-centric UNS. Its three main modules are:

  • Protocol Converter — south-bound connectivity to virtually any industrial data source: PLCs, RTUs, SCADA and DCS systems, CNC machines, and robots from mainstream and legacy vendors alike
  • Model Designer / Data Harmonizer — a WYSIWYG, web-based editor for building a hierarchical, ISA-95-aligned address space, turning raw tags into meaningful objects (for example, a Pump with Temperature and Pressure attributes) instead of a flat list of points
  • Data Logger — stores and forwards data, both real-time and historical, to downstream databases and messaging systems

That combination gives a UNS built on oBox Suite a few concrete advantages over a bare MQTT broker:

  • Southbound connectivity to virtually any industrial data source through the Protocol Converter module
  • A WYSIWYG, browser-based editor for the address space, with a real hierarchical structure — not a topic-naming convention enforced by hand
  • Support for a layered deployment: local site-level edge instances that push harmonized data up to a centralized cloud instance
  • Multiple, standards-based interfaces for higher-level applications to consume the same data:
    • OPC UA — real-time data via standard OPC UA subscriptions and monitored items; Pub/Sub over MQTT or brokerless UDP; and historical data, both raw and processed
    • REST API for lightweight application integration
    • MCP for straightforward integration with AI-based solutions
    • A built-in MQTT broker, so applications that only know how to subscribe over MQTT are still fully supported
OPC UA + OBOX SUITE UNS Field devices PLC / DCS / SCADA CNC / robots oBox Suite (edge) Protocol Converter Model Designer (harmonized) Data Logger Interfaces OPC UA subscribe OPC UA Pub/Sub (MQTT/UDP) Historical (raw / processed) REST API MCP (AI integration) Built-in MQTT broker Applications MES / analytics AI agents / cloud oBox Suite (cloud) centralized instance, multiple sites merged Site-level edge instances harmonize local data and push it up to a centralized cloud instance — the same browseable, standardized address space at every layer.

UNS built with OPC UA and oBox Suite: harmonized address space at the edge, layered up to a centralized cloud instance, exposed through OPC UA, REST, MCP, and MQTT.

3MQTT-Only vs. OPC UA + oBox Suite

DimensionPlain MQTT UNSOPC UA + oBox Suite
Payload format Not standardized — every team defines its own JSON schema Standardized OPC UA data value: value, quality, server and source timestamps
Historical data Not available from the protocol — a separate historian must be bolted on Native raw and processed historical access via the Data Logger module
Synchronous / transactional calls Not supported — pub/sub only, no request/response Supported via OPC UA services and method calls
Browsing / discovery of structure Not supported — topic tree must be documented and shared out of band Address space is browseable and self-describing by design
Report by exception Depends entirely on how each publisher is coded Built-in, with absolute and percent-based deadbands on monitored items
Alarms & events No native model — typically a separate system Native OPC UA alarms & events
Bandwidth efficiency JSON over MQTT — commonly 3x+ the size of the OPC UA binary equivalent Compact OPC UA binary encoding
Southbound connectivity to legacy/industrial sources Left to whatever publishes into the broker — usually custom, per source Protocol Converter module covers PLCs, RTUs, SCADA/DCS, CNC, robots out of the box
Building the address space / hierarchy Enforced only by topic-naming convention and discipline WYSIWYG Model Designer / Data Harmonizer, ISA-95-aligned
Edge-to-cloud layering Possible via broker bridging, configured and maintained by hand Built-in layered edge → cloud instance support
Integration interfaces MQTT only OPC UA (subscriptions, Pub/Sub over MQTT or UDP), REST API, MCP, plus a built-in MQTT broker
AI integration Custom, built by hand against the topic schema Native MCP interface

4Wrapping Up

Plain MQTT is a perfectly reasonable way to get a UNS pilot running quickly, and its ecosystem is hard to beat for raw reach. But the gaps that show up once a UNS moves past a pilot — no standard payload, no history, no synchronous calls, no browsing — aren't quirks of a particular broker; they're gaps in MQTT itself. OPC UA closes all four by design, and a platform like oBox Suite turns that into a practical UNS implementation: south-bound connectivity to the plant floor, a real hierarchical address space you build visually instead of by naming convention, and northbound access over OPC UA, REST, MCP, or MQTT — so applications that only speak MQTT still aren't left out.

See a UNS built on OPC UA in action

oBox Suite combines protocol conversion, address-space modeling, and historical logging in one platform — with OPC UA, REST, MCP, and MQTT all available on the same harmonized data.

→ onewayautomation.com/obox-suite  |  → Talk to us

References

  1. [1] OPC Foundation — OPC UA overview, address space, PubSub, and historical access: opcfoundation.org/about/opc-technologies/opc-ua/
  2. [2] One-Way Automation — oBox Suite: onewayautomation.com/obox-suite/

Idako vs. Telegraf: Two Ways to Log OPC UA Data to InfluxDB

Aug 18, 2026 | Blog

This article was created with AI assistance.

Both can move process data from an OPC UA server into InfluxDB. They're built on very different assumptions about what else your pipeline needs to do — here's how to pick.

Telegraf is InfluxData's open-source metrics collection agent — a single Go binary with 300+ plugins covering everything from system metrics to databases, cloud APIs, message queues, and (via community-maintained plugins) OPC UA. Idako is a purpose-built OPC UA-to-database bridge: a much narrower tool that does one job — reading from OPC UA servers and getting that data into InfluxDB, SQL databases, or messaging platforms without losing samples along the way.

Neither is "better" in the abstract. Which one fits depends on what else is in your stack, who configures it, and how much you need OPC UA specifically — as opposed to metrics collection in general — to just work.

1The Short Version

Choose Idako if…

  • OPC UA is your primary or only data source
  • You want a GUI, not TOML files, for OT technicians to maintain — or SQL/REST access for automation
  • You need guaranteed store-and-forward buffering by default
  • Your servers expose complex/structured (ExtensionObject) data types
  • You want tags selected by scripted (Python) rules and mapped by template, not listed by hand one at a time
  • You need two-node HA for zero-downtime maintenance
  • You want a single vendor to call when something breaks

Choose Telegraf if…

  • You already run Telegraf for other metrics (hosts, containers, APIs)
  • You need one agent to also collect from dozens of non-OPC UA sources
  • Your team is comfortable in Go-ecosystem tooling and config-as-code
  • Budget requires a fully open-source, license-free tool at any scale
  • Your OPC UA tags are simple scalar types (no ExtensionObjects)

2What Each Tool Actually Is

Telegraf

Telegraf is part of InfluxData's TICK stack — the same company that makes InfluxDB. It's a general-purpose, plugin-based collection agent configured with TOML files. For OPC UA specifically, it ships two separate input plugins: opcua, which polls a configured list of nodes on a fixed interval, and opcua_listener, which opens a true OPC UA subscription and streams changes as the server reports them [1]. Output goes through the influxdb_v2 (or influxdb for 1.x) plugin, one of roughly 100 supported outputs.

Idako

Idako (formerly ogamma Visual Logger for OPC) is built around a single job: bridge OPC UA servers to storage and messaging targets — InfluxDB, TimescaleDB, MS SQL/MySQL/PostgreSQL, Kafka/Confluent/Redpanda, MQTT, Snowflake — with native OPC UA subscriptions, millisecond (microsecond with InfluxDB) timestamp resolution, and Store & Forward buffering as a first-class, on-by-default feature rather than an add-on. Its own configuration lives in a SQL database (SQLite for single-node installs, PostgreSQL for larger or clustered deployments) rather than a flat file — so you can change it from the GUI, by editing the database directly, or programmatically through a REST API, whichever fits your ops workflow.

3Architecture, Side by Side

IDAKO PATH OPC UA PLC / DCS / SCADA Idako Native subscribe + buffer Forward (Store & Forward on) InfluxDB TELEGRAF PATH OPC UA PLC / DCS / SCADA Telegraf opcua / opcua_listener input influxdb_v2 output (+ 99 others) InfluxDB Buffering on by default, disk-backed In-memory by default; disk mode is opt-in

Both draw the same box diagram at a glance. The difference is in the boxes: Idako's collector and forwarder are one purpose-built component; Telegraf assembles the same pipeline out of two independently-maintained, general-purpose plugins that happen to be able to talk to each other.

4Head-to-Head

DimensionIdakoTelegraf
OPC UA subscriptions Native from the start — event-driven with per-tag deadbanding Supported via opcua_listener (added in Telegraf v1.25) [1], separate from the older polling-only opcua plugin
Complex / structured data types Full support for vendor-specific structured types (custom binary decoding) Reading OPC UA ExtensionObjects is a known open limitation — errors out on many structured-type nodes [2]
Store & Forward buffering On by default, disk-backed, sized for your outage window out of the box In-memory buffer by default (metric_buffer_limit); a disk-backed WAL buffer exists but is still flagged experimental, with manual disk-space management and reported edge-case bugs [3]
Configuration storage & access Held in a SQL database (SQLite or PostgreSQL) — edit via GUI, direct SQL, or REST API Flat TOML config file, hand-edited or templated by external config management
Variable selection Manual pick in the GUI, or Python-scripted selection rules (e.g. "log everything under this folder matching X") run from the GUI on demand Listed explicitly, node by node, in the TOML config file
Measurement / tag mapping Set per variable individually, or generated automatically from templates so hundreds of similar tags map consistently without per-tag editing Set per node block in TOML; no built-in templating engine — bulk/consistent mapping across many tags is typically scripted outside Telegraf
High availability Native 2-node HA cluster — automatic failover and maintenance (e.g. upgrades) without a collection gap No built-in HA; redundancy means running independent agents and deduplicating downstream, or leaning on external orchestration (systemd/Kubernetes restarts)
Output destinations Curated set: InfluxDB, TimescaleDB, SQL databases, Kafka/Confluent/Redpanda, MQTT, Snowflake ~100 output plugins — InfluxDB is one of many, alongside Prometheus, Kafka, cloud monitoring services, and more
Non-OPC UA data sources Out of scope by design 200+ input plugins for hosts, containers, databases, cloud APIs, and other industrial protocols
Licensing / cost Community Edition free forever (≤64 tags); paid Standard Edition beyond that Fully open source (MIT), free at any scale
Support model Vendor support from One-Way Automation Community forums / GitHub issues, or a paid InfluxData support contract
Deployment Windows, Linux, Raspberry Pi, Docker; optional 2-node HA cluster Windows, Linux, macOS, Raspberry Pi, Docker — very portable single binary

5Where Telegraf Genuinely Wins

If OPC UA is just one of several things you're collecting — say, host metrics from your edge servers, container stats, and API health checks alongside process data — running one Telegraf agent for all of it is simpler than running Idako plus a separate metrics agent. Telegraf's plugin ecosystem is enormous, it's free without a tag-count ceiling, and if your OPC UA tags are all simple scalar types, both its polling and subscription-based inputs work well. It's also the natural choice if your team already standardizes on InfluxData tooling (Telegraf, InfluxDB, Chronograf/Grafana) and is comfortable maintaining TOML configs as code.

6Where Idako Genuinely Wins

When OPC UA reliability is the project — not a side input among many — the gaps close in Idako's favor. Store & Forward isn't something you have to opt into and tune around known bugs; it's the default behavior. Structured/ExtensionObject tags, common on DCS systems and vendor-specific PLC blocks, are handled natively instead of erroring out. And a GUI-driven config means the OT technician who owns the PLC, not necessarily the person who knows TOML syntax, can maintain the tag list. For a plant where OPC UA-to-historian is the whole job, that focus tends to matter more than plugin count.

A few differences matter specifically once you're managing more than a handful of tags:

  • Config lives in a real database, not a text file. Idako's own configuration is stored in SQLite or PostgreSQL rather than a flat TOML file, so a change can come from the GUI, a direct SQL statement, or a REST API call — useful if you want another system (a provisioning tool, an MES) to manage tags programmatically instead of hand-editing config.
  • Selection logic, not a hand-built list. Instead of listing every node by hand, Idako lets you define selection rules in Python — e.g. "log every variable under this folder whose name matches this pattern" — and run that selection from the GUI to (re)populate the tag list in one step, instead of adding nodes one at a time.
  • Mapping scales with templates. You can map OPC UA attributes to InfluxDB measurements and tags one variable at a time, or define a template once and apply it across hundreds of structurally similar tags — consistent naming without hand-editing each one.
  • Built-in 2-node HA. Idako supports deployment as a high-availability cluster across two nodes, so a node failure or a planned upgrade doesn't create a collection gap — maintenance becomes a non-event instead of a scheduled outage window.
Not mutually exclusive These tools coexist well. A common pattern: use Idako to pull OPC UA data reliably — especially anything with structured types or strict no-data-loss requirements — into InfluxDB or Kafka, and run Telegraf alongside it to collect infrastructure and application metrics from the same edge gateway into the same InfluxDB instance. You get purpose-built OPC UA handling without giving up Telegraf's broader collection footprint.

7Wrapping Up

Telegraf is the right tool when OPC UA is one data source among many and you want one open-source agent to rule them all. Idako is the right tool when OPC UA is the core of the job and you can't afford the pipeline to quietly drop a structured tag or lose an hour of data during a network blip. Most plants end up choosing based on which failure mode they're more worried about: missing a plugin, or missing data.

Evaluate Idako on your own OPC UA server

The Community Edition is free forever for up to 64 variables — enough to compare it directly against your current Telegraf setup on real tags, including any structured/ExtensionObject types Telegraf can't yet read.

→ onewayautomation.com/idako  |  → Free tools & Community Edition  |  → Talk to us

References

  1. [1] InfluxData, "Yes, You Subscribed Correctly. The OPC UA Client Listener Plugin Has Been Released!" — influxdata.com/blog/opc-ua-client-listener-plugin/; Telegraf opcua_listener and opcua input plugin docs — docs.influxdata.com/telegraf/v1/input-plugins/
  2. [2] Telegraf GitHub issue #9911, "OPC-UA Client: Support for ExtensionObjects" — github.com/influxdata/telegraf/issues/9911
  3. [3] Telegraf output buffer strategy spec (tsd-005) and related disk-buffer issues (#15876, #15868, #16500, #16670, #18085) — github.com/influxdata/telegraf

MQTT vs OPC UA myths and delusions

Jul 1, 2026 | Blog

You can see a repetition of the same myths and delusions that have been circulating on the internet for quite a while now. Here are some of them:

1. "When you use OPC UA, it is always point-to-point connections."

In fact, very often you will see OPC UA clients connecting to a gateway or aggregator like Kepware KEPServerEX or Prosys OPC Forge. Even in the "Decoupled Architecture" diagram presented by Kudzai, you can see an aggregator—Node-RED—being used.

2. "OPC UA is request-response based and synchronous, while MQTT is publish-subscribe and event-driven/asynchronous."

In fact, OPC UA clients very rarely use the Read service call to get real-time data. Instead, they use the Subscriptions and Monitored Items mechanism, which in many cases delivers data once it changes—and often within a much shorter time than MQTT brokers would. Note that this is a separate mechanism from OPC UA Pub/Sub (e.g., over MQTT/UDP), which can be considered equivalent to standard MQTT.

3. "When you use MQTT as a transport, data is published only when it changes (Report by Exception / RbE)."

In fact, MQTT itself has nothing to do with RbE; it does nothing to prevent publishers from repeatedly sending identical messages. In contrast, RbE is a core, built-in requirement for OPC UA. Furthermore, OPC UA allows you to explicitly define what a "value change" means using the deadbands feature. In other words, you can configure the server to trigger a change event only when the value fluctuates beyond a specific absolute value or percentage.

4. "MQTT overhead is minimal, while the OPC UA binary protocol is heavier."

In fact, the opposite is true. The OPC UA binary protocol is roughly three times lighter on the wire than vanilla MQTT.

5. "OPC UA might be good to use at the OT level, but when you move data to the cloud, MQTT is the only suitable option because OPC UA requires opening incoming ports into the OT network."

In fact, OPC UA features a "reverse connection" capability. This allows clients located in the cloud to access data from OPC UA servers located inside the OT network using only outgoing connections from the OT network—exactly how it is done with MQTT. If your specific OPC UA server or client doesn't natively support this feature, you can easily implement it using aggregating proxies like Prosys OPC Forge.

About OPC UA timestamps

Feb 22, 2026 | Blog

As software engineers and manufacturing industry professionals, it is important to understand the use of timestamps. This article explains the basics of what timestamps are, the features it boasts, and a possible solution to any associated headaches.

What is a Timestamp?

A timestamp is a way of recording the date and time of each data point or event in a data acquisition system. Having correct timestamps in process control data acquisition is essential for ensuring the validity, reliability, and usability of the data. It also helps to enable effective process monitoring, control, and optimization.

Precise timestamps ensure accurate analysis and interpretation of the data. This is especially crucial because it aids in the identification of trends, patterns, anomalies, and correlations. Timestamps also facilitate synchronization and integration of data from multiple sources. This includes different sensors, instruments, devices, or systems.

Types of Timestamps:

According to the OPC UA Standard, each value of an OPC UA variable is associated with 2 timestamps: Source and Server timestamps.

  • The Source Timestamp is used to reflect the timestamp that was applied to a variable value by the data source. This indicates the time at which data values were measured at the lowest-level data source. It’s important to consider that this data source can be located in the same machine that runs the OPC UA Server, or it can be in a different device with its own system clock.
  • The Server Timestamp is used to reflect the time that the Server received a variable value or deemed it as accurate.

If the server reads data values itself, then the source and server timestamps will usually be the same. If an OPC UA Server gets data from another device that supports timestamps, then the source timestamp can be significantly different than the server timestamp.

Time Zones: A Mystery

No matter the situation, system clocks in devices that are a part of the data acquisition path should be in sync. Ideally, system clocks should be synchronized with time servers, such as an NTP protocol.

To avoid confusion and errors during conversions, all timestamps in OPC UA are UTC timestamps. Interestingly, this means that there are no time zones or daylight savings. To offset this, timestamp values are usually converted to the user's local time by the application displaying them.

When an OPC UA client creates a subscription with monitored items, the device can define which timestamps it needs to receive. This can be a source or server timestamp, and sometimes even both.

The Solution:

Our bestselling product Idako: Industrial Data Collector, creates subscriptions and monitored items that request both timestamps. This allows you to have the choice of freedom between different timestamp formats. In addition, Idako is scalable, energy efficient, and robust when handling an unlimited number of tags.  When data values are forwarded to the destination time-series database or MQTT broker, the format of timestamps depends on the destination database type.

Different Scenarios, Depending on the Destination Database:

  • When the destination is an SQL database or Snowflake, the source timestamp is written in a "time" column of the values table. If the source timestamp is not defined, then a server timestamp is used. It is also possible to write a client timestamp in the column "client_time". The “client_time” is the time when data values were received by the Idako from the OPC UA Server. This timestamp is especially useful when the server or source timestamps are unreliable and not accurate enough.
  • When the destination is InfluxDB, Confluent, or Apache Kafka, then the source timestamp is used as a record timestamp. If the payload is composed using a template, then all three timestamps can be included in the payload using placeholders like "[SourceTimestamp]", "[ServerTimestamp]", and/ or "[ClientTimestamp]".
  • When the destination is an MQTT broker, timestamps cannot be a part of the published messages. This is because the MQTT protocol does not exactly specify how timestamps should be transported from the publisher to the broker. So, they can be only included in the payload. In this case, the payload should be defined using a template, with placeholders for timestamps like: "[SourceTimestamp]", "[ServerTimestamp]", and/ or "[ClientTimestamp]".

Duplicate Records and High-Resolution:

In some cases, duplicate records (with the same value and timestamp for the same variable) can be written on the database. This can occur when Idako disconnects from the server and reconnects, or when it restarts. In these cases, a variable data value can be the same, and the source timestamp can also be the same as before it was reconnected. This might cause duplicate record errors in SQL databases if the values table is configured to have a unique index by “source_id” and time column values. To resolve this issue, our product Idako has configuration settings that allow duplicate records (refer to our User Manual for details).

Furthermore, OPC UA allows the definition of timestamps with high resolution: down to a 10 picosecond precision. Other target databases usually do not support such high resolutions, so this is a very impressive feature. The Idako configures the precision with which timestamps are written. This can be seconds, milliseconds, or microseconds. Different storage destinations have different ways to represent timestamps.

Our product Idako is a master in fine-tuning the timestamp format. This can occur in the following ways:

  • An integer number representing a Unix epoch time (depending on the number of seconds, milliseconds, or microseconds precision since Jan. 1st, 1970).
  • A string value formatted with the ISO-8601 standard
  • An OPC UA DateTime value (which is an integer number of 100 nanosecond intervals passed since Jan. 1st, 1601).

If you enjoyed learning more about timestamps and its uses, feel free to comment and ask questions. If you’re interested in finding out more about the Idako, email us at sales@onewayautomation.com to begin the purchase process.

Idako version 4.3.0 has been released

Feb 12, 2026 | News

Idako: Industrial Data Collector – Version 4.3.0 Now Available!

We are excited to announce the release of version 4.3.0 of Idako: Industrial Data Collector. This milestone marks the first official release following the rebranding of the software formerly known as ogamma Visual Logger for OPC.

In addition to the new identity, this version introduces significant enhancements to integration and usability:

Key Highlights of version 4.3.0
  • Snowflake Integration: You can now log industrial data directly to the Snowflake platform. Beyond high-performance real-time data storage, Idako automatically generates tables for context metadata, ensuring your variables are fully defined and searchable within your data warehouse.
  • Refined Configuration GUI: We have updated the CSS styles of the configuration interface, providing a more modern, streamlined, and intuitive user experience.
  • Comprehensive Documentation Update: The User Manual has been fully revised. It now features updated text and new screenshots reflecting the latest UI changes to help you get the most out of the platform.

Ready to Upgrade?
Experience the new Idako today. Visit the product home page to download the latest version or view the full documentation.