Connect - Universal Data Collection
Set up reusable connections to devices, brokers, databases and cloud services, watch their status and health, and test network reach.
- Functions
- Connect › Functions
- Live feeds
- Connect › Subscriptions
- Network test
- Needs connection:test
- Scaling
- Needs connection:update
Connect is your gateway to bringing data from any source into MaestroHub. Whether you're working with industrial PLCs, IoT sensors, enterprise databases, or cloud services, Connect provides pre-built connectors that eliminate the complexity of integration.
Why Connect?
Traditional industrial integrations require custom development, protocol expertise, and ongoing maintenance. Connect changes this by offering:
- No-code configuration: Set up connections through an intuitive interface without writing code
- Native protocol support: Built-in connectors for the most common industrial and enterprise systems
- Secure by default: TLS encryption, authentication, and credential management built-in
- Reusable configurations: Create connection profiles once, use them across multiple pipelines
- Built for operations: connectors with health checks, reconnects, and per-connection status
How Connect Works
Connect operates through three key concepts:
1. Connection Profiles
Define how to reach a system: broker URLs, database credentials, protocol settings. Create once, reuse everywhere.
2. Functions
Define what data to read or write: tag subscriptions, SQL queries, MQTT topics. These are reusable building blocks you configure per connection. Each one also has a page of its own, where you can run it without opening the connection: see Functions.
3. Pipeline Integration
Use your functions in Orchestrate pipelines to trigger data collection, transform results, and route data to its destination.
Creating a Connection
Connect → Connections → New Connection opens the connector picker. The left side picks what the list shows: All, one category (Industrial, Messaging, Databases and so on), or Used in this workspace, the connector types the workspace already has connections of, most used first. The search narrows every category at once, and each entry counts the connectors that match.
Click a connector to see it on the right before you commit to it:
| Part | Shows |
|---|---|
| Description | What the connector connects to and how |
| What it can do | Read, Subscribe (values arrive as they change), Write, Call (run a query, function or command), Browse (list tags, tables or topics) and Delete, as the connector's functions allow |
| You will need | What to have ready before you start: network access and its port, credentials, a setting on the device or service |
| Features | The connector's main capabilities |
| Setup guide | The connector's page in this documentation |
The Industrial category, with Siemens S7 selected and previewed on the right
Continue, a double-click or Enter opens the connector's form. From the search box, the arrow keys move through the list, so you can type, arrow down and press Enter without the mouse. Request a connector at the bottom asks for one that is missing.
The count of connections per type covers only the connections you can see, so it never reveals one shared with someone else.
Connection Statuses
Every connection profile has a runtime state that reflects its current condition. Understanding these statuses helps you monitor and troubleshoot your integrations.
| Status | Description |
|---|---|
| Idle | The connection is registered but not actively running. This is the initial state before a connection is started, or after it has been manually stopped. |
| Connecting | The connection is in the process of establishing communication with the target system. |
| Connected | The connection is active and healthy. Data collection and function execution are fully operational. |
| Disconnected | The connection has lost communication with the target system. MaestroHub will automatically attempt to reconnect. |
| Reconnecting | An automatic reconnection attempt is in progress after a disconnection. |
| Failed | Reconnection has kept failing: the circuit breaker has tripped three times in a row. MaestroHub keeps retrying, paced by the circuit breaker, and the first successful attempt returns the connection to Connected. Check that the target system is running and reachable; you do not need to restart the connection. |
| Suspended | The connection has been intentionally paused by an operator. No data collection or reconnection attempts occur while suspended. See Connection Suspension below. |
Connections that run on several replicas
A connection can run on several replicas at once, one slot each. Its status then follows one rule, the same rule the Connection Health pages and the connection notifications use:
| Status | When |
|---|---|
| Connected | Every slot is connected. |
| Degraded | At least one slot is connected and at least one is not (a failed slot included). The connection still serves, so this is not an outage: it does not count as downtime and sends no notification. The status says which slot is down and why. |
| Degraded capacity | At least one slot is connected, but fewer slots run than were requested (no replica to take a slot, or a replica was lost and another is taking over). |
| Failed, Disconnected, … | No slot is connected. This is an outage, and the status shows the worst slot's state. |
A connection on one replica has one slot, so its status is simply that slot's state.
What a Lost Connection Writes
When a connection leaves Connected for Disconnected, Reconnecting or Failed, every subscribed function it was delivering replays its last known value once as a sample marked quality bad with reason comm_error, the OPC convention: last value, Bad. The sample takes the same path a device reading takes, so a pipeline publishing from that trigger stores it as bad · comm_error at the moment the link dropped, charts show the outage where it happened, quality-based alerts fire, and an onChange trigger fires for it even though the value itself did not change (a change of verdict is a change). The receiver stamps the disconnect time; the device's own timestamps are not replayed. A function that never delivered a value has nothing to replay and stays silent. Suspending or stopping a connection is intentional and writes nothing.
Connection Suspension
Suspension allows operators to intentionally pause a connection without deleting or reconfiguring it. This is useful during planned maintenance windows, infrastructure changes, or when you need to temporarily stop data collection from a specific source.
When you suspend a connection:
- All active communication is gracefully stopped
- Automatic reconnection is disabled
- A suspension reason is recorded for audit purposes
- Functions targeting the suspended connection will not execute
To resume a suspended connection, use the Resume action. Resume resets the circuit breaker and reconnection backoff and starts the connection straight away. While the workspace is in maintenance mode, Resume is refused; the connections that maintenance suspended resume on their own when it ends.
Connection Health
MaestroHub records every state transition of each connection, and counts the work each connection completes and the operations that fail. The Connection Health page uses both to say whether each connection is working right now, not only whether it is connected:
- Needs attention: a card for every connection that is down, connected but idle, failing operations, flapping, degraded, suspended, or that failed earlier in the period, with one sentence saying what is wrong
- Activity: when the connection last completed an operation, how often it usually does, failing operations, response time, and a sparkline of operations per minute
- Uptime: uptime, outages, the longest outage and average recovery over the period you pick. An outage is time with no slot connected; see what counts as an outage
- Messages: errors grouped by message with how often each occurred, then the most recent state changes
A connection's Health tab shows the same card for that connection. See Connection Health for every number on it.
Scaling
Every connection form has a Scaling tab, available once the connection has been saved. It sets Desired replicas: how many MaestroHub replicas run this connection in parallel, each owning one slot and sharing the load. If the cluster has fewer live replicas than you ask for, the extra slots show as pending until more replicas join.
The value is read-only, and the tab shows the reason, in these cases:
- single-binary: Multi-replica scaling needs a microservices deployment. A single-binary deployment runs each connection on one instance.
- protocol-locked: The protocol always runs on a single replica (for example Siemens S7, OPC UA, Modbus and MQTT 3.1.1), or it uses a single slot, where every replica uses the connection on its own and a value above 1 has no effect (for example REST, SMTP and Azure Blob).
Changing the value requires the connection:update permission.
Scaling tab on a single-binary deployment: one replica, read-only, with the reason shown
Functions
Connect → Functions lists every connection function you may read, across all the workspace's connections. A function is an operation a connection performs: read a tag, publish a message, query a table, call an API. You don't need access to a connection to find or run its functions: the list and each function's page ask for the function's own permissions (function:read to see it, function:execute to run it) and show the connection by its name only.
| Column | Shows |
|---|---|
| Function | The function's name and description. |
| Runs on | The connection the function runs on. |
| Type | The function type, such as opcua.read or rest.get. |
| Labels | The function's labels. |
| Last Edited | Who last changed the function, and when. |
Search filters by function name. Select a row to open the function's page. The same page opens from Open function page in the row menu of a connection's Functions tab, and from Open function under a pipeline node's function picker.
Functions are created on a connection, in its Functions tab. The list doesn't create them.
Connect → Functions: the plant's functions, each with the connection it runs on
A function's page
The page shows the function's name and description, the connection it Runs on, its type and its labels, and these actions:
- Run: one input for each parameter the function takes: a switch for a boolean, a JSON box for an object or array, a text box for anything else. A required input is marked, and Run stays off until it is filled in. Run calls the function once, now, on its connection, and Result shows what came back, as JSON, a table or a single value. A run is real: a write function writes to the device. Running needs
function:execute. Without it, the inputs and Run are off and the page says why. Subscribe functions and event triggers (MQTT subscribe, CANopen PDO subscribe, Kinesis consume) run by themselves and can't be run by hand. The page says that too. - History: every saved version of the function, and what changed from the version before.
- Who has access: who can read, run, edit or delete the function, and why: the roles that grant each action, and any shares and deny rules on the function.
- Share: shown to people who may share the function. Adding a share needs Advanced Access Control. Without it, Share can only remove shares that already exist.
- Edit settings: opens the function in its connection's Functions tab. A function's settings belong to its connection, so editing, renaming or deleting a function needs access to the connection. If you can't open it, the button is off, and the page names the connection and tells you to ask someone who manages it.
A function's page after a run: its inputs, what it returned, and the connection it runs on
Sharing a single function is part of Advanced Access Control, an Enterprise feature. A function is shared for use: a share can let someone read and run it, never edit, delete or share it further. Those stay with the people who manage its connection.
Subscriptions
Connect → Subscriptions lists the live data feeds your pipelines keep open. A subscription exists while an enabled pipeline uses a subscribe function (MQTT, Sparkplug B, Redis and similar) as its trigger. Use it to find out why MaestroHub is subscribed to a device or broker.
| Column | Shows |
|---|---|
| Connection | The connection the feed runs on. |
| Function | The subscribe function and its type. If the function was deleted, the row says so: the pipeline asks for a feed that can never start until you change it. |
| Demanded by | The enabled pipelines that use this feed. Each one links to the Pipeline Designer. |
| State | The connection's current state, and the number of replicas running it when there is more than one. When the connection is up but this one feed was turned down, a second badge says subscription refused (the broker said no, or two functions on the connection ask for overlapping topics in different share groups) or subscribe failing (the attempt got no answer), with the reason. Both are retried every 30 seconds and clear by themselves once the cause is gone. |
There is no cancel button. MaestroHub keeps the subscriptions in line with your enabled pipelines, so a cancelled feed would come straight back. To stop a feed, disable the pipelines listed under Demanded by. Search filters by connection, function or pipeline name, and the list refreshes every 30 seconds.
Connect → Subscriptions with two MQTT feeds held open by enabled pipelines
Network Diagnostics
Network Diagnostics, on the Connections page, checks whether the MaestroHub server can reach a host and port. Use it to tell a network problem (firewall, routing, DNS, the device being down) from a connector that is misconfigured: if the test fails, fix the network first; if it succeeds but the connection does not, check the connection's settings and credentials.
- Single Test: Enter an IP Address or Hostname, a Port (default 80), a Protocol (TCP or UDP) and a Timeout (seconds) (default 5), then select Test Connection.
- Batch Test: Add several hosts, each with its own port, protocol and timeout, and select Test All Hosts. The hosts are tested in parallel, and a summary shows how many succeeded and failed.
Each result shows the host and port, the resolved IP address, a success or failure message, the protocol, the time of the test and, on success, the latency. For a hostname that cannot be resolved, the result says so. A UDP test sends nothing to the target, because UDP has no handshake: a success means the host name resolved, not that anything is listening on the port.
Single Test with a successful TCP result
Running a test requires the connection:test permission, and every test a person runs is recorded in the audit log.
Getting Started
Choose the connector that matches your data source:
- Browse the connector documentation to understand capabilities
- Create a connection profile with your system's credentials
- Define functions to specify what data to collect
- Build pipelines in Orchestrate to put your data to work
Each connector guide includes detailed configuration references, security best practices, and real-world examples to help you get up and running quickly.
Once you've connected your data sources, build your first data pipeline in Orchestrate, then give your UNS topics a meaning, with a unit, rules and alert limits, from Libraries.