UNS OpenHubIntegrations

Integrations

From operational intent
to a working integration.

Publish and consume data with the open SDKs and Node-RED nodes. In the private Runtime preview, configure Triggers and Captures or prepare a custom service with the in-app Agent. Start with the demo to see a complete data flow.

Choose an integration pathWatch the demo setup

Two authoring paths

Configure the common case.
Prepare the custom one.

Both paths start from governed UNS context. Choose visual rules when the behavior is already understood, or generate an explicit project brief when custom code is the better fit.

Private Runtime previewVisual authoring

Configure an Automation

Create and manage focused data behavior directly in the application, without turning the Runtime into a general-purpose no-code environment. OpenHub owns authoring and status; UNS API Global executes the rules.

  • TriggersReact to UNS values and publish an output when a rule fires.
  • CapturesLog selected values during a stateful window, at intervals, on change, as a summary, or as a single shot.
Private Runtime previewAgent-assisted

Prepare a custom service

Describe the outcome, choose TypeScript or Python, and confirm the input and output paths. The in-app Agent resolves source shapes and creates a validated, reviewable contract.

service.bundle.jsonUNS paths · data shapes · goals · guardrails · acceptance
  1. 01ConfirmUse real UNS paths and source shapes, not guessed topics.
  2. 02GenerateReview the validated service bundle before code is created.
  3. 03ScaffoldUse uns-kit or uns-kit-py to create the TypeScript or Python project.
  4. 04BuildHand the project brief and guardrails to Codex, Claude, or another coding agent.

The scaffold keeps service.bundle.json as its source of truth and adds SERVICE_SPEC.md, AGENTS.md, and starter code. This bounded authoring flow is part of the private Runtime preview; broader Assistant capabilities remain a later phase.

Clear responsibilities

Integrate without
duplicating every tool.

Whatever authoring path you choose, protocol handling, semantic mapping, and governed context remain separate responsibilities.

01 · Source and edge

Operate close to the equipment

Devices, PLCs, databases, brokers, Ignition, and Node-RED own native protocols, local buffering, and edge operations.

02 · Provider

Map into a canonical contract

Browse or receive source data, validate it, map identity and semantics, and publish a consistent OpenHub representation.

03 · OpenHub Core

Govern the shared context

Keep stable identity, Schema, relationships, policy, history, and service lifecycle consistent across sources.

Available now

Public building blocks.

These repositories are public and usable today. Start from a generated bundle or create a project directly, then add storage, APIs, or visual flows as the data path grows.

AvailableToolkit

uns-kit

TypeScript and Python SDKs plus bundle-aware project scaffolding for publishing and consuming structured UNS data.

Open repository ↗
AvailableStorage

UNS Archiver

Archive scalar and table packets from MQTT in QuestDB with buffering, stable mappings, and recovery.

Open repository ↗
AvailableAccess

UNS API Global

Query current and archived UNS data with authentication, summaries, and bucketed time series.

Open repository ↗
AvailableVisual flows

Node-RED nodes

Subscribe to and publish structured UNS data from familiar visual flows.

Open repository ↗
AvailableReference app

Hot rolling mill simulator

See material flow, telemetry, storage, and APIs working together in one fictional end-to-end example.

Open repository ↗

Connectivity direction

Know what is ready.

Every integration is labelled by its current delivery stage, from publicly available components to private development and pilot preparation.

Private developmentMQTT

MQTT mapping provider

Browse external MQTT sources and map topics and payloads into governed OpenHub identity and Schema.

Private developmentOPC UA

OPC UA mapping provider

Browse OPC UA nodes and map selected values into the same canonical context.

Pilot preparationIgnition Edge

Ignition Edge integration

Start with a read-oriented pilot. Ignition keeps device drivers, tags, local buffering, and operator-facing edge behavior; OpenHub adds canonical identity, Schema, governance, and provider lifecycle.

What we do not duplicate

Leave specialist work
to specialist systems.

OpenHub focuses on the shared contract and operational governance around it, not on rebuilding the entire industrial or enterprise software stack.

Keep outside the core

Native operational tooling

  • PLC and device protocol drivers
  • SCADA, HMI, and local control behavior
  • Arbitrary no-code transformation environments
Connect through providers

Canonical context

  • Identity and semantic mapping
  • Validation against Schema and policy
  • Provider configuration, health, and lifecycle

Build the connection

Keep the edge focused.
Share the meaning.

Start with the SDKs ↗Understand add-on discovery