Skip to main content
Version: 3.1

Context Engine 3.0 Release Notes

Everything that changed in Context Engine since 2.6.5: new connectors, a safer and clearer engine, per-topic history, workspaces, connection health, notifications, and an upgrade command that carries your 2.6 data across.

Covers
Everything after 2.6.5
Upgrade from
2.6.x, with upgrade apply
Beta, on request
Maestro, the AI Assistant
Beta, add-on
App Studio, Demo Plant
Enterprise
Advanced Access Control
Coming soon
Knowledge Graph

The notes for the release after this one are in Context Engine 3.1 Release Notes.

Context Engine 3.0 is the largest release since 2.0. It covers everything merged after 2.6.5, the last 2.6 maintenance release. The 2.6.1 to 2.6.5 fixes are already in 2.6 and are not repeated here.

Before you upgrade an existing 2.6 installation, read What Changes in 3.0 and Upgrade from 2.6.x to 3.0. Some changes, such as the 32-day history cap and the new topic paths, must be acted on before the upgrade.

The themes of 3.0​

  • Connect more of the plant. New native drivers for IEC 60870-5-104, Keyence KV, Panasonic FP, Mitsubishi FX3, Siemens S5 and LOGO!, Opto 22, Beckhoff TwinCAT, FANUC FOCAS, SNMP, Universal Robots, tightening controllers and AVEVA PI; business and IT systems such as SAP HANA, ServiceNow, PagerDuty and Splunk; and a broad set of AWS, Azure and Google Cloud services.
  • Trust what the pipelines do. Every node publishes its configuration and output contract, pipelines are checked when you save them, every node's output has one shape, and a failure that used to pass quietly now fails loudly.
  • Know where each value stands. Every stored value carries a quality verdict and the writer that produced it, and the Data Explorer says first what a topic is doing and why.
  • Keep history the way you need it. Each topic keeps 1, 7, 14 or 32 days of history, set on the topic or inherited from its branch, on the built-in historian and on TimescaleDB alike.
  • Workspaces. What 2.6 called an organization is now a workspace, with a Workspaces page to create, suspend, delete and restore them, and per-workspace maintenance mode.
  • Hear about problems once. One rule decides whether a connection is up, degraded or down, a failing connection notifies once per outage, and platform events reach people in the product and on Slack, Microsoft Teams or a webhook.
  • Upgrade with a command, not a script. context-platform upgrade check shows what the upgrade will do to your own data before anything is changed, and upgrade apply backs up, converts and verifies.

New features and major improvements​

Connect: new connectors​

3.0 adds these connectors. Each has its own page under Connect, and its operations appear as nodes in the pipeline designer.

Industrial devices and protocols

  • IEC 60870-5-104: a client for telecontrol stations, with spontaneous monitoring, reads, general interrogation, commands and TLS. A control command is never sent twice by a retry.
  • Keyence KV over Host Link: read a device, read a block, write a device and read a group.
  • Panasonic FP over MEWTOCOL-COM and MEWTOCOL7: read a device, read a block, write a device and read a group.
  • Siemens S5, through an S7 gateway or a CP 1430 (FETCH/WRITE), read and written by S5 address.
  • Siemens LOGO! 8 over S7 by TSAP, read and written by LOGO! address.
  • Opto 22 over native OptoMMP: read and write I/O channels and the scratch pad by address.
  • Beckhoff TwinCAT over ADS.
  • FANUC FOCAS for CNC machines, and FANUC FOCAS Ethernet, which reads a CNC directly over the network with no adapter: status, program, feed, spindle, axis positions, macro variables, PMC memory and alarms (read-only).
  • SNMP v1, v2c and v3, for switches, routers, UPSs, PDUs and sensors: get named OIDs, walk a subtree and set writable objects.
  • Universal Robots cobots (CB3 and e-Series): read and stream RTDE data, read the robot's status, and play, pause, stop or load programs.
  • Open Protocol (Beta) for tightening controllers from Atlas Copco, Desoutter, Stanley, Cleco and others: receive every tightening result, follow alarms and job changes, and select parameter sets and jobs.
  • Syslog (RFC 5424 and 3164, over UDP, TCP or TLS): start pipelines from the messages of switches, firewalls, PLCs and hosts, or send pipeline events to a syslog collector or SIEM.
  • Raw TCP (send, receive, request and stream) and raw UDP (send, and request with reply) for network devices that speak their own protocol.
  • CoAP (RFC 7252) over UDP for constrained devices and gateways: GET, PUT, POST and DELETE, block-wise transfer, and an Observe trigger that starts a pipeline on every notification. A POST is never sent twice by a retry.

Historians and industrial software

Messaging and enterprise systems

  • AMQP 1.0.
  • SAP IDoc and SAP Event Mesh.
  • SOAP / WSDL.
  • Apache Cassandra: query, read, write and delete rows, and run statements and batches.
  • Apache Pulsar: publish to topics, and a subscription trigger that starts a pipeline for every message and acknowledges it once stored (exclusive, failover, shared and key-shared subscriptions; token and TLS authentication).
  • ServiceNow: create, update, read and query incidents and other records through the Table API.
  • PagerDuty: trigger, acknowledge and resolve incidents, send change events, and read open incidents.
  • GitLab: open, comment on, close and read issues when an alarm fires or a quality check fails.
  • Splunk: send plant events through the HTTP Event Collector and run SPL searches.
  • Grafana: mark alarms, batches and shift handovers on dashboards as annotations.
  • GraphQL: queries and mutations against any GraphQL API; an error the server reports inside a 200 answer fails the node.
  • Google Sheets: read ranges, append rows and update fixed cells.

Databases

  • SAP HANA: query, run statements and load pipeline rows into tables.
  • Couchbase (Server or Capella): read and write documents by key, and run read-only SQL++ queries.
  • Neo4j: read and write a graph with Cypher, in read and write transactions.

Notifications and collaboration

  • Discord and Mattermost: post alerts and messages to channels by webhook or bot. Mattermost works inside a plant network with no internet connection.
  • Twilio: text and call operators from a pipeline, and read whether a text was delivered.

Amazon Web Services

Microsoft Azure

Google Cloud

Data warehouses and lakes

  • Snowflake Streaming: rows land in Snowflake within seconds, without a warehouse.
  • Apache Iceberg: append pipeline rows to Iceberg tables on S3, S3-compatible storage or Google Cloud Storage, through an Iceberg REST catalog or AWS Glue.
  • Microsoft Fabric OneLake: append rows to lakehouse Delta tables, and read and write files, with Entra ID authentication.

Connect: existing connectors​

  • Mitsubishi MELSEC reaches FX3 PLCs over the 1E frame, in binary and ASCII, with FX addresses. See MELSEC.
  • Rockwell EtherNet/IP adds Micro800 controllers, per-tag batch results, whole UDTs, automatic types, and a tag picker that imports an L5X file. See EtherNet/IP.
  • Modbus sets the byte order of multi-register values per function.
  • OPC UA read groups carry the device's own timestamp and quality for each value, and browse reads child attributes in batches.
  • PostgreSQL vector search. With the pgvector extension, a pipeline stores embeddings and finds the manual pages, work orders or events closest in meaning to a question. See Vector Search with pgvector.
  • NATS signs in with .creds files, NKeys and mutual TLS. See NATS.
  • SQL query results are capped at 50,000 rows (it was 1,000) and 40 MiB by default, both set in the connectors configuration, and a cut result says which limit cut it. This applies to every SQL connector, ODBC and BigQuery.
  • Function time limit: a function may run for up to one hour, starting at 30 minutes.
  • Read failures become data. When a connection is lost, its subscribed values are written once as a Bad sample, and Modbus, TwinCAT and FANUC read failures become Bad data events instead of gaps.
  • The New Connection picker is a compact list with category filters that leads with the popular connectors, and the standalone connector catalog is folded into it.
  • Connection and function version history. Connections and their functions keep a version history, on the same timeline that pipelines use.
  • Read-only forms. A person who may only view a connection sees a read-only form that says so, and browse panels follow the test permission.
  • Forms keep what is stored. Connection and function forms now send exactly what is stored; 59 forms that dropped part of their configuration on save were fixed.
  • A page for every function. Connect → Functions lists every connection function you may read, and each one opens on its own page: run it, see its history and who has access. Running a function needs the function's own permission, not access to its connection. See Functions.

Connect: connection health and subscriptions​

  • One state rule. A connection that runs on several replicas is Connected, Degraded (at least one slot up and one down, not an outage), Degraded capacity, or down. The connection list, the Connection Health pages and the notifications all use this one rule. See Connect.
  • Connection Health answers the operator's questions: uptime, outage counts, the longest outage, average recovery time, a timeline, and grouped failures. An outage says how often it bounced, and a restart reads as one event, not an outage.
  • One notification per outage. A failing connection notifies once per outage; a stop, suspend or restart no longer re-arms it.
  • Subscriptions (Connect → Subscriptions) lists the live data feeds your enabled pipelines keep open, and which pipelines demand each one.
  • Health that heals. Structural failures (wrong address, refused credentials) escalate on the first attempt, transient ones keep being retried, and the connection keeps trying to recover.

Orchestrate: pipelines and the engine​

  • One output shape. Every node's output now has two parts: result, the value it produced, and _metadata, the facts about the run. The upgrade rewrites the 2.6 reads it can follow. See What Changes in 3.0.
  • Contracts for every node. Every node type publishes its configuration contract, and connector nodes publish the shape of their results. The designer's forms read their options, bounds and required marks from that contract.
  • Checked at save. A pipeline that will fail when it runs says so when you save it: references no node writes, a read-group function that no longer exists or belongs to another connection, a pipeline that triggers itself.
  • Clearer failures. A read from a disconnected device now fails the node instead of publishing empty values, a script failure reports SCRIPT_ERROR (or TIMEOUT), and a node that degrades shows completed with errors instead of a green tick.
  • Repeated failures are one row. When a pipeline fails the same way several times within a minute, the execution history shows one row, Failed ×N, with the first run kept in full.
  • Global functions. A workspace library of JavaScript functions: write one once, test it beside its code, and call it by name from any pipeline, which keeps the version it was saved with. See Global functions.
  • Approvals. The Approval node pauses a payload until a person approves or rejects it, from the Approvals inbox or, in a Sandbox test, on the canvas. Approvals (human in the loop) is a licence add-on and is included in the free trial.
  • IntelliSense in JavaScript nodes and {{ }} expression fields, using real last-run outputs where they exist, and a Format button for JavaScript and JSON fields.
  • Find nodes on the canvas, a readable minimap, and an Add Node panel that ranks protocol families with configured connections first and offers only nodes you can use.
  • HTML Extract node, to pull values out of page text.
  • A webhook can answer with data. A webhook trigger can wait for the pipeline and return its result to the caller with the Webhook Response node, so a pipeline can serve as an API.
  • The File Extractor reads what plants send: spreadsheets (including the .xls files that are really text or HTML), CSV in any encoding, HTML tables, Parquet, SQLite, JSON, XML and fixed-width text, with typed values. See File Extractor.
  • A value as of an instant. The UNS Fetch Data node reads a topic's value as of a past moment, besides its recent records and a time range. See UNS Fetch Data.
  • Execution Replay opens on what broke: a run summary, the step list and the failed step first, full screen, with each node's input beside its output. See Execution Replay.
  • Longer runs. A pipeline can run for up to 24 hours, starting at 30 minutes.
  • For-Each loops are drawn as one frame you can drag as a unit, a long live loop says that its iteration panel shows a sample, and loop error thresholds and partial results apply as set.
  • Version history is rebuilt around one timeline that pipelines, connections, functions, topics and dashboards share, and a dashboard can be restored to an earlier version. See Pipeline Version History.
  • Executions list a run total beside the row total, and deleted pipelines keep their version snapshots.
  • Lost work is visible. Executions that were discarded or lost are counted per cause and shown on the Overview, and throttled or silent pipelines are named.
  • Store & Forward now also buffers object-store and file writes it skipped in 2.6, waits for a connection that has failed instead of dead-lettering its backlog, lets you choose per output whether a bad message holds the ones behind it, and its emergency pause now also stops intake. See Store & Forward.
  • Dependencies (formerly Dependency Graph) moves under Overview and shows how pipelines, connections, functions, topics and dashboards depend on each other, and what a deletion would affect. See Dependencies.
  • Dependencies keep their history. See the graph as it stood on a past date, each item's history of who changed what, the recently deleted items, and every change in the workspace on one Changes panel. A value's lineage opens the graph as it was wired when the value was made.
  • Node types follow their operation. Connector node types are named connected.<operation>; 2.6 pipelines are renamed by the upgrade.

Unified Namespace and historians​

  • History per topic. Each topic keeps 1, 7, 14 or 32 days of history, 1 day by default. Set it on the topic, or on a branch so the topics under it inherit it, from Configure… in the Data Explorer tree. The built-in historian and TimescaleDB keep the same choices and both span the recent and the older data in one read. See UNS Settings.
  • Quality and provenance on every value. Each stored value carries a quality level and the reason for it, the writer that was authorised to write it, the run and function versions that produced it, and its ingest time beside its production time. Reads can filter by quality, and a Bad reading stays Bad across pipeline hops.
  • The Data Explorer talks first. A topic's page opens on a briefing: the current value and how long the topic has been silent, the window in one sentence, an annotated chart, and one list of what went wrong. Where it comes from is a lineage map from the reads to the readers. See Data Explorer.
  • Work on several topics at once from the tree's selection bar.
  • Deleting a topic keeps it restorable with its history for seven days; Delete permanently purges the history at once. The broker's retained message is cleared on delete.
  • A topic's contract is its meaning. A topic's type, unit, range and alert limits come from the property it is given as its meaning, and the meaning panel says what it will do to the topic's readers, alerts and history before you save (Giving a topic a meaning). The per-topic inline schema is gone, and the data schemas of earlier 3.0 builds became libraries (Changes in 3.0).
  • Start from your data. The Libraries page reads your topics, groups them by what they measure, and gives a whole group its meaning in one step, then one alarm for all of them, previewed against the last day (Start from your data). What meanings do for you shows the five outcomes, each with the screen that does it, and a 10-minute tutorial walks through them.
  • Find signals (Beta). Every signal with one meaning, everywhere or under one folder, now or over the last 24 hours, 7 days or 30 days, in the meaning's unit: a table on one scale, Export CSV, Copy as API call (POST /api/v1/uns/data/by-meaning), and the read-only MCP tool find_signals_by_meaning. See Find signals.
  • Machines that look alike (Beta). Start from your data suggests machines that send the same signals when one of them looks like another unit, and after you give one signal a meaning by hand, the signals like it are offered the same name. Each is a suggestion you confirm, applied in one step with Undo (Machines that look alike).
  • Every member reads libraries and meanings. A workspace member reads its libraries however they joined, and the meaning of every topic they can read; a deny rule still wins. Every change that gives a topic a property also needs read on its library.
  • A silent topic names its cause. A topic with a meaning reads Silent by the same rule that reports it as not receiving data, and the briefing names a failing connection with its error, or a pipeline whose runs keep failing, before it blames the device. Topic charts scale to the data and the alarm limits, with the Warning and Critical lines labelled.
  • Richer meanings. A computed property is calculated at publish from other properties. A property's alarm can wait before raising and clearing, latch until acknowledged, follow a chattering rule, and be taken out of service (Alarm and sampling). Libraries have versions you publish and move topics between, they are exported and imported as JSON Schema files, and a built-in library gives a new workspace its first properties.
  • Alerts can be shelved, keep a history, and are routed to Slack, Microsoft Teams or a webhook. A critical alert nobody acknowledged is escalated in tiers, one channel per tier, and the Alarm KPIs tab shows alarms per hour, the alarms that fire most, and standing and chattering alarms. See Alerts.
  • MQTT write endpoint. Sensors, PLCs and gateways publish into the namespace over MQTT through their own inbox topic, checked like any REST write. See MQTT Write Endpoint.
  • One MQTT broker, built in. MaestroHub's own broker is the only MQTT broker: the external broker option (EMQX) is removed from the product, the API, the UI, the Helm charts and Docker Compose. In Enterprise every UNS replica serves MQTT, the replicas are linked by a direct mutual-TLS mesh, and persistent sessions are kept in NATS JetStream, so they survive the replica they were on. The MQTT Broker page shows the broker's listeners, connected clients and whether topic permissions are enforced. An installation whose settings named an external broker is moved to the built-in one at its first start; devices that used EMQX must be pointed at MaestroHub. See MQTT broker.
  • An acknowledgement means stored. When the built-in broker acknowledges a device's publish, the value is stored: nothing is lost, and a reading that carries its own timestamp is stored once however often it is resent. See MQTT Write Endpoint.
  • TLS on the built-in broker, with WSS on the WebSocket port.
  • Dashboards expose their variables to custom ECharts panel code.
  • Disk pressure. The platform watches one disk floor: at the floor it refuses new values and buffered messages instead of failing, reclaims data already past its retention, and resumes on its own.
  • Less disk writing. The historian, topic creation and entity creation write much less to disk than in 2.6.

Overview and navigation​

  • The Overview opens on a verdict and one queue of what needs attention, with live charts of connections, pipelines and the namespace per workspace, and every attention card opens the page that fixes it.
  • Platform Health opens with its verdict, and a service that is down says so and what to do.
  • New workspaces get a three-step journey that starts with their equipment, and an optional fourth step, Give your data meaning, which stays until the workspace's first topic has a meaning.
  • Navigation. A top bar with global search (Ctrl+K), the profile menu and the notification bell; regrouped sidebars, with Admin split into Monitor, Configure and Maintain; favorite pages in a top-bar tray.
  • Search offers the pipelines, connections and runs you opened last before you type.
  • Help on every page, written for operators.

Workspaces and tenancy​

  • Organization becomes workspace across the product, the API and the configuration. See What Changes in 3.0 for every renamed name.
  • The Workspaces page creates, edits, suspends, deletes and restores workspaces, and shows the seats the licence allows. See Workspaces.
  • Maintenance mode is per workspace: it pauses the workspace's pipelines, cancels running ones and suspends its connections, while other workspaces keep running. See Maintenance Mode.
  • Logs are readable per workspace; the platform reads them all.

Security and identity​

  • Personal access tokens per workspace. A token names the workspaces it is for and carries a permission list for each, checked against your role there. It is refused in any other workspace. Tokens created on 2.6 keep working. See Personal Access Tokens.
  • Connect an AI client. A page in the profile menu writes the MCP settings for Claude Code, Claude Desktop, Cursor, VS Code or another client, for the workspace you pick, and opens the token dialog with the permissions the chosen areas need.
  • MCP toolsets. A client chooses which tools it lists, for example /api/v1/mcp?toolsets=pipelines, and an agent can validate and dry-run a pipeline before anyone enables it. See MCP integration.
  • Single sign-on. SAML works end to end with signature verification, IdP metadata and group-to-role mapping; OIDC binds user info to the ID token and checks subject, audience and logout-token expiry; LDAP defects are fixed; and signing out also signs you out of the identity provider.
  • Secrets encrypted at rest. The SAML private key, OIDC client secrets, the LDAP bind password, the SMTP password, the token-signing keys, connector access key IDs and the Fleet Manager API key are stored encrypted. New installations create their own unique encryption keys, and admin-cli reencrypt rotates a module's key.
  • Revocation reaches what is open. A revoked token, a suspended agent or a changed permission reaches open browser sessions and MQTT connections without a new sign-in. A WebSocket opened with a token closes when the token is revoked or expires.
  • Signing out ends every session. Signing out, changing or resetting a password, and disabling or deleting a user end that user's sessions everywhere, including on other replicas, and an ended session cannot be refreshed. Single sign-on users can no longer set a local password that bypasses the identity provider, and an administrator can reset a user's password from the Users list.
  • OPC UA server certificates are pinned. A secure OPC UA connection remembers the server's certificate, and a changed certificate waits for an administrator's approval before the connection uses it. Existing connections record their server's certificate on their first connect after the upgrade.
  • Agent tokens carry scopes. An agent token is issued only with scopes, each one the agent has been granted, and is held to them as well as to the agent's roles. An agent with no granted scopes can do nothing with a token until it is granted some; a token issued before 3.0 is held to the scopes its agent holds. See API Authentication.
  • System Administrators are granted and revoked on their own tab, and MaestroHub keeps at least one. See System Administrators.
  • Ownership. Every resource keeps an owner who can act for it: a fallback owner inherits a departed user's resources, and a workspace admin can assign an owner to a resource that has none. Whoever makes a resource owns it; what an agent or an API client makes waits for an owner on the Ownership tab. See Ownership.
  • Authorization hardening. Role permissions are enforced at the service layer for every HTTP and MCP write, on WebSocket subscriptions and on the MQTT data plane, and cross-workspace reads are refused.
  • The Data Stream Viewer role gives read-only MQTT consumers subscribe and history access, and nothing else.

Advanced Access Control (Enterprise)​

Access finer than the built-in roles, in the Enterprise edition: custom roles, groups, the granular feature roles, per-topic sharing and stewardship, access requests that an owner or steward decides, deny rules, and time-bound grants. It needs the advanced_access_control licence feature. Foundation keeps role-based access control with the built-in roles. The free trial includes it. See Users & Roles.

When the licence no longer includes Advanced Access Control, nothing widens and nothing is deleted: role assignments it covered are kept but grant nothing, Users & Roles and My Access mark them inactive, and Explain my access names the licence as the reason. They grant again as soon as the feature is back. See When the licence changes.

Notifications​

  • Notifications in the product. The bell opens a tray of your latest items and a feed page, with read state and mutes. Items reach the people they concern: alarms, failing connections, approval requests, changes to your own access, and licence expiry.
  • Notification channels send platform events to Slack, Microsoft Teams or any webhook, filtered by source and severity. See Notifications.

Audit trail​

  • Who acted, truthfully. Every record names the kind of actor that acted, and where an agent or a pipeline acted for a person, the person responsible. The system no longer appears as a user.
  • SIEM export in CEF, ECS, NDJSON or CSV from one export endpoint, with guides for Splunk, Elastic and Datadog. See SIEM integration.
  • Loss is counted. Audit events that could not be written are counted, kept in a dead-letter queue, and shown in a banner on the audit page.
  • A large trail stays fast. Every audit filter reads through an index, and the integrity check honours a cancel. See Audit Trail.

Licensing and the free trial​

  • Once licensed, no free trial. After a licence has been applied, an expired or removed licence leaves the instance expired until a valid one is applied; restarting no longer starts a trial. An instance that was never licensed keeps the trial. See Licensing & Activation.
  • Expiry reminders. Administrators are told one month, one week, three days, 24 hours and one hour before a licence expires, in their notifications and in a banner.
  • The trial includes Approvals, so a fresh installation can try a pipeline that waits for a person.
  • The License page lists every feature, the workspace limit, and the third-party notices as a file you can save. Under In use it shows each capped limit against its use, such as topics with a meaning (3 of 100).
  • The trial's limits: 20 pipelines, 20 connections, 5 users and 100 topics with a meaning, with Advanced Access Control included.

Telemetry​

  • Nothing is sent until an administrator agrees. A new installation asks the first administrator once, at setup, with neither answer preselected. See Telemetry.

Deployment and operations​

  • One storage rule. Two settings, storage.engine (SQLite or PostgreSQL) and storage.dataDir, decide where every store lives. The upgrade moves 2.6 stores to their 3.0 places.
  • New names. The image is maestrohub/context-platform and the command is context-platform. The old maestrohub/lite image and maestrohub-lite command still work in 3.0, with a warning.
  • Helm. A single-node chart installs Context Engine and its data plane with one command, and the multi-node chart was made deployable end to end.
  • Backup & Migration (formerly Export/Import) moves connections, functions, topics, pipelines and dashboards between workspaces or installations as one bundle, and a failed import can be retried. See Backup & Migration.
  • Clean shutdown. Every wait in the stop path is bounded and says what it is waiting for.

Upgrade from 2.6​

  • The upgrade command. context-platform upgrade check runs every step on copies of your stores and reports what would change, including what needs a person. upgrade apply backs up, converts and verifies; upgrade restore puts the backup back; upgrade status reports where every store stands. See Upgrade to 3.0 and Upgrade Command Reference.
  • Converted, not patched. Pipelines, connections, functions, topics, dashboards and library panels are versioned and converted from their 2.6 shape once, during apply. Access grants, custom roles and ownership come through the upgrade too.
  • A safe start. 3.0 refuses to start on data that still needs the upgrade and shows an Upgrade needed page instead of exiting. Admin → Maintain → Upgrades shows past runs, what they left to act on, and their backup sets.

Documentation​

  • Upgrade guides: What Changes in 3.0, the 2.6 to 3.0 guide, the upgrade report, safety and problem pages.
  • New pages for every new connector, Functions, Approvals, Workspaces, Notifications, Audit Trail, Ownership, System Administrators and SIEM integration, and an MCP walkthrough recorded with Claude Code.
  • A refreshed site in the design language of maestrohub.com, with renewed screenshots.

Beta​

AI Assistant​

Maestro, the agent inside the product, with the same tools and the same permissions as your own MCP client. It acts with the person's own permissions and changes nothing without their yes. Ask about live data, chat about a pipeline or a dashboard, build, dry-run and change a pipeline, use Explain & fix on a failed run or a broken connection, use Draft it for me on a new connection or in any connection function's form, and run an AI Agent node in a pipeline. Maestro is on every page, behind the top-bar button or Ctrl+J (⌘J on a Mac), and knows which page you are on. A workspace can let it investigate a new problem on its own, read-only and within a monthly token cap, before anyone asks. Besides OpenAI, Anthropic and OpenAI-compatible endpoints, it connects to Azure AI Foundry, with an API key or Entra ID. Maestro is in release 3.0 as Beta: it is not turned on by default, and partners and early adopters who ask MaestroHub get a licence that carries it. See Maestro. Without Maestro, you can use your own MCP client through MaestroHub's MCP server; see MCP integration.

App Studio​

A domain expert describes the application they need (an OEE board, a shift book, an operator console), and it is built on everything MaestroHub already does: connectivity, pipelines, the namespace and governance, reading and writing data only inside the permissions of the person using it. App Studio is in release 3.0 as Beta: a paid add-on that no edition includes by default. A licence or a trial licence that includes the app_studio feature switches it on; the module runs by default. The app is built by Maestro, the AI Assistant above, or by your own AI client over MCP; viewing, running, publishing and sharing apps do not need Maestro. An app can run a pipeline and wait for its result, call connection functions within each action's own permission, keep photos and PDFs on its records, and print to PDF or to Zebra label printers. The scene kit builds a live 3D model of a production line from a scene spec; see Model a line in 3D. See App Studio.

Demo Plant​

A simulated bottling plant that runs inside MaestroHub and feeds an empty workspace through ordinary connections: it produces, wears, fails and gets repaired, so you can learn and demonstrate MaestroHub on data that behaves like a real plant, with no device to connect. Demo Plant is in release 3.0 as Beta: an add-on that no edition includes by default. The free trial includes it, and partners who ask MaestroHub for early access get a licence that carries it. It is for demos and education, never production. See Demo Plant.

Coming soon: in testing​

Coming soon

The features below have a built foundation and are being tested. They are under development, in testing, and not available in release 3.0. We do not announce a date for them.

Knowledge Graph​

The plant as things and the links between them: what feeds what, what drives and controls what, what stops if this stops, and what the plant looked like on any past day. It is meant to let people and agents ask about the plant in plain words and get the answer back with the rows and the path that produced it. Knowledge Graph is coming soon: it is in development and testing and is not part of release 3.0. The proof of concept 3.0.0 shipped behind the knowledge_model add-on licence is retired, and the Knowledge Graph is being rebuilt on the new graph; see What Changes in 3.0. The 2.6 asset instances are not carried over by the upgrade; see What Changes in 3.0.

Notable fixes​

Connectors

  • OPC UA no longer leaks server sessions, and orphaned sessions are reclaimed over a new channel.
  • Ignition and OPC DA subscriptions no longer freeze the connection; CANopen, OPC UA, MQTT cloud subscribe and discovery no longer stall on a lock.
  • A Modbus reply that belongs to another request redials instead of staying one reply behind.
  • RabbitMQ publish waits for the broker's confirmation, so a message the broker throws away is no longer reported as sent.
  • A pinned Kafka produce partition now reaches the broker, and the Kafka producer is idempotent: a record the broker acknowledged is never lost, and a retry never writes it twice.
  • SFTP append writes at the end of the file, and FTP/SFTP rename no longer replaces an existing file.
  • The SiteWise and IoT Hub Store & Forward switch buffers as it says.
  • A PostgreSQL or Snowflake write that the database refuses is reported as permanent, and SQL queries honour their own timeout.
  • A pattern fetch on S3, GCS, Local File and SMB returns the newest match.
  • Connection settings that were stored but never applied now work or are removed.

Engine and pipelines

  • A For-Each body no longer reads the output a previous iteration left behind, and a For-Each with many items no longer takes very long to appear on the canvas.
  • Renaming a node moves every reference to it.
  • A webhook trigger without authentication answers 401 until you configure it.
  • Interval triggers run on an exact timer that a change of the server's clock neither stops nor repeats, and schedules run in their own time zone.
  • Execution history takes half the disk or less per run (a three-node run went from 2.6 KB to 1.25 KB, a five-node run from 4.6 KB to 1.5 KB), and the history size metric now reports what the disk holds.
  • A restart with a connected pipeline saved no longer hangs.
  • Many caller mistakes now answer 400 with the reason instead of 500. Creating a pipeline, connection, dashboard, library panel or app with no workspace answers 400 WORKSPACE_REQUIRED.
  • A run that completed with errors is its own outcome, between clean and failed. A pipeline that loses a few For-Each items on every run reads 100% with errors in amber on the pipelines list, the metrics panel, the Overview and the Fleet Manager, instead of a red 0% success rate beside pipelines that deliver nothing. The Overview's Pipelines lane marks these runs amber and failed runs red.

Unified Namespace and historians

  • History never runs backwards when the wall clock steps back.
  • A number larger than 2^53 keeps every digit, from publish through storage to the screen and every connector.
  • A topic's arrival rate counts its samples, not the historian's flushes: values sent every 2 s read about every 2 s, where they read 5.4 s.
  • Alarm actions a person may not take (Ack, Shelve, Unshelve) are disabled with the permission they need, instead of failing on click.
  • "The last N readings" reaches into older stored data instead of stopping at the recent tier.
  • A write no longer waits for the compression of an old TimescaleDB chunk, and the TimescaleDB historian starts again on TimescaleDB versions before 2.18.
  • A sealed partition keeps everything the recent tier held.

Security and identity

  • Identity comes from authentication, never from a request header.
  • A "not equal" filter on the logs can no longer read other workspaces' logs, and a share on a topic such as line_1 no longer also grants line11.
  • API tokens cannot read another workspace's connection secrets, and a token's scope ceiling is enforced on every route.
  • Browser tabs no longer sign each other out when they refresh the token at the same time.
  • The findings of the security scans (govulncheck and gosec) are cleared, and the Go toolchain is updated.

Operations

  • The log database returns its space after retention runs.
  • Operator-set GOGC and GOMEMLIMIT are honoured again, and the default soft memory limit follows the container's limit.
  • The Docker image starts on a 2.6 volume.

Breaking changes and upgrade notes​

Read What Changes in 3.0 for the full list, who each change affects and what to do. In short:

Act before you upgrade

  • History is capped at 32 days. If 2.6 kept more, the first start of 3.0 deletes everything older. Export what you need first.
  • UNS topic paths include the workspace: mHv1.0/test/line1 becomes mHv1.0/<workspace-slug>/test/line1. The upgrade rewrites what is inside MaestroHub. MQTT clients and other systems outside it must switch to the new paths; a publish on a 2.6 path is refused.
  • The shared uns_reader MQTT login is gone. Give each subscriber its own API client with the Data Stream Viewer role.
  • The external MQTT broker (EMQX) is removed. Point every device and gateway that connected to EMQX at MaestroHub's MQTT address, and delete the EMQX values from your Helm values: they now fail the render. The external broker's config.yaml keys are ignored, with a warning. The broker delegation endpoints and the broker.authz OAuth2 scope are gone.
  • Schemas, asset instances and alerts are rebuilt. The 2.6 schema registry, bindings, asset instances, inline topic schemas, alert limits and live alert state are not carried over.
  • An expired licence no longer falls back to the trial once the instance has been licensed. Have a valid key ready.

Check after you upgrade

  • Organization is now workspace in the UI, the API paths, the X-Workspace-ID header, JSON fields, error codes, role names (Workspace.Admin, Workspace.Member), permissions, pipeline references, metric labels, configuration keys and Helm values. Old paths and the old header are accepted but deprecated; old JSON fields and error codes are not. Everyone signs in again after the upgrade.
  • Node outputs are { result, _metadata }. The upgrade rewrites the reads it can follow; reads from Merge nodes in Append or Combine mode need a person.
  • Connector node types are renamed to connected.<operation>; the upgrade renames them in your pipelines.
  • A read from a disconnected device fails the run. Set On Error to continue where a pipeline should go on.
  • Every Convert to File output has its header. On 2.6 only a node's first run wrote one, so later CSV and Excel files lost a row to the column names. If a CSV node feeds a writer with Append to File on, each run now adds another header row: turn Include Headers off on that node.
  • S3 and Databricks Volumes writes no longer guess whether Data is base64. Data is written as text unless the function's Input Format is base64. Set it on writes fed by a Data Serializer or a file or object read; the upgrade report lists the functions to check.
  • FTP/SFTP Upload's content format is Input Format (inputFormat), like every other write that takes text or base64. upgrade apply renames 2.6's encoding: base64.
  • Runs that completed with errors have their own metric label. maestrohub_executions_total and maestrohub_pipeline_executions_total record them as result="with_errors" instead of result="failure". A Prometheus dashboard or alert that reads result="failure" no longer counts them; add result="with_errors" where it should.
  • Script failures report SCRIPT_ERROR (or TIMEOUT) instead of UNKNOWN_ERROR, TRANSIENT_ERROR or PERMANENT_ERROR.
  • Store locations follow one rule. Per-store location keys in config.yaml are ignored, with a warning that names the line to delete.
  • Secrets are encrypted by the upgrade. Keep the new key files with your data, and delete the backup set once 3.0 runs well; it holds the old plain-text values.
  • Installs on Postgres keep the built-in encryption key until you rotate it. A store that already holds connector credentials, UNS passwords or Maestro provider keys keeps the key they were written with, and every start logs a SECURITY: warning naming the modules. With MaestroHub stopped and a pg_dump of each database taken (and GitOps auto-sync paused, on Kubernetes), run admin-cli reencrypt <module> --config <your config.yaml> for each module the warning names (connectors, uns, maestro). New installs on Postgres get their own keys.
  • Access changes are reported per user, including roles that 2.6.5 failed to apply and now do.
  • The first start runs long database work on large audit and execution stores. Do not stop MaestroHub while it runs.
  • Image and command names: move to maestrohub/context-platform and context-platform when convenient. maestrohub/lite:latest stays on 2.6.5 on purpose, so nothing reaches 3.0 by accident.

To run the upgrade, follow Upgrade from 2.6.x to 3.0.

Get started​

Download a native binary or pull the Docker image and follow Get started to have MaestroHub running in minutes.