--- title: "Prepare your machines to connect to Tulip" slug: "prepare-your-machines-to-connect-to-tulip" status: "update" updated: 2026-05-29T20:43:07Z published: 2026-05-29T20:43:07Z --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Prepare your machines to connect to Tulip *Here are the questions you need to ask if you are interested in using machine monitoring with Tulip.* If you want to build a frontline operations app that uses data from both humans and machines, Tulip could be a great fit for your production floor. For example, if you want your operator's app to use dynamic logic based on whether a machine is running or not, Tulip can help. Or, if you just want to collect machine data alongside human data for later analysis, Tulip can also help. To determine which machine data can be integrated into Tulip, you will need to know the following information: 1. **What protocol does the device use to share data?** Common examples include OPC UA, MQTT, MTConnect and Modbus. 2. **What does your current data infrastructure look like?** For example, do you have a SCADA system, historian, or Kepware server that already aggregates machine data? Many scalable integrations connect Tulip to that layer rather than directly to each machine. 3. **If you are currently capturing data from the machine, where is it located?** And what is the format? Tulip uses [Connectors](/r230/docs/connectors) to work with external software and hardware. In addition to the standard HTTP and SQL Connectors, Tulip's Machine Monitoring module adds the capability to [connect to machine protocols through the OPC UA Connector](https://support.tulip.co/docs/how-to-build-your-first-opc-ua-connector) and the [MQTT Connector](/r230/docs/mqtt-connectors). Once you integrate your machine data into Tulip, you can combine it with human input in Tulip's App Editor. ## Tulip system connections See the [Tulip platform components and network diagram](/r230/docs/tulip-platform-components-amp-network-diagram) to understand how the Tulip system works. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/How%20To%20Prepare%20Your%20Machines%20to%20Connect%20to%20Tulip_88526530.png) ### Common connection scenarios If you want to connect Tulip to a device on the Shop Floor, you first need to consider how you will connect the device to your company’s data infrastructure, either on-premises or in the cloud. The most scalable architectures connect Tulip to an existing data aggregation layer rather than directly to individual machines. The most common scenarios are: 1. **A machine connected via a SCADA system, historian, or Kepware server**: If your facility uses a SCADA system or an OPC aggregation platform like Kepware, Tulip can connect to that layer via OPC UA or HTTP. This approach scales well across large machine estates without requiring per-machine configuration. 2. **A machine with a native API**: Many modern machines expose HTTP or MQTT interfaces directly. Tulip can connect to these via the HTTP Connector or MQTT Connector for a direct, lightweight integration. 3. **A machine that publishes to an MQTT broker**: If your facility uses an MQTT broker (including cloud brokers such as AWS IoT Core), Tulip's MQTT Connector can subscribe to topics from that broker and route data into your apps and machine monitoring dashboards. This is a common pattern in facilities using a Unified Namespace (UNS) architecture. 4. **An older machine connected to a Tulip Edge Device**: For legacy equipment without network connectivity, a Tulip Edge Device can bridge the gap via serial port, USB, or GPIO. This is a valid approach for isolated or legacy machines, but is not preferable for larger-scale deployments. The types of data that can be accessed in Tulip depend on the machine's method for sharing data. Tulip can capture simple facts like whether the machine is on or off, or more advanced metrics like spindle speed or operation pressure. ## Connect via MQTT MQTT is a lightweight, publish/subscribe protocol widely used in industrial IoT environments. If your machines or SCADA layer publish data to an MQTT broker, you can connect Tulip to that broker using the MQTT Connector. Here are the important things to note about MQTT Connectors: - Tulip supports both **MQTT** (username/password authentication) and **MQTTs** (MQTT over TLS/SSL, with support for private keys, certificates, and trusted CA tokens). - The connector runs on a **Connector Host**. If your MQTT broker is not accessible from the public internet, you need an **On-Premise Connector Host (OPCH)** (version 261 / LTS11 or higher). - Tulip supports **publishing data back to your MQTT broker from within apps**, making it possible to trigger downstream systems or update a Unified Namespace. This requires an On-Premise Connector Host (OPCH) running LTS13 or higher. - **Quality of Service (QoS) is configurable** at the connector level: QoS 0 (at most once), QoS 1 (at least once), or QoS 2 (exactly once). For setup instructions, see [Build your first MQTT connector](/r230/docs/how-to-build-your-first-mqtt-connector) and [Configure an MQTT connector functions](/r230/docs/configure-an-mqtt-connector-function). ## Data flow overview There are three major steps in the data flow from machine to Tulip’s apps. 1. The machine shares data via a protocol. 2. Your data infrastructure (SCADA system, historian, MQTT broker, or machine API) stores or routes the data. 3. The Tulip Connector Host receives the data and shares it with the rest of the Tulip platform. The machines usually **push** data into your company’s servers. And then your company’s servers **push** data into Tulip’s Connector Host when certain events occur. Here’s a diagram of that flow. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/How%20To%20Prepare%20Your%20Machines%20to%20Connect%20to%20Tulip_88526531.png) Once the data has reached Tulip, you can use Connectors to pass it into apps, machines, widgets, and live charts via the [Analytics Editor](/r230/docs/analytics-editor), then share those views with your team using [dashboards](/r230/docs/dashboards). ## Further reading - [Intro to Machine Monitoring in Tulip](https://support.tulip.co/docs/intro-to-machine-monitoring) - [Build your first MQTT connector](/r230/docs/how-to-build-your-first-mqtt-connector) - [Build your first OPC UA data source](/r230/docs/build-your-first-opc-ua-data-source) - [Overview of Tulip Connector Hosts](/r230/docs/connector-hosts) --- Did you find what you were looking for? You can also head to [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) to post your question or see if others have solved a similar topic! **OPC-UA** **OPC Unified Architecture** is a cross-platform, open-source, IEC62541 standard for data exchange from sensors to cloud applications developed by the OPC Foundation. **Connectors** **Connectors** enable real-time connectivity between your Tulip solution and a transactional system (e.g. an ERP). The output of a Connector Function can be used in Tulip Apps, Automations, and Functions. - **HTTP Connectors** utilize HTTP API endpoints. - **SQL Connectors** can enable connectivity with certain SQL databases. - **MQTT Connectors** can connect to MQTT brokers for machine monitoring. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/connector.gif) **App Editor** The web interface used for building applications. Where you design a user interface, add logic, and connect your applications to **Tables**. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Screen%20Shot%202022-09-13%20at%207.50.23%20AM.png) **Shop Floor** The area of the platform responsible for moving applications into production. Under the shop floor, you can manage **Stations**, **Edge Devices,**and the app publication details such as which **Version** is accessible to users, which **Devices**are connected to the app, and which **Interface (display device)******the app is run on. **Connector Host** Tulip **Connector Hosts**are designed to allow your Tulip Apps to interface with external systems such as databases, APIs, and machines. **On-Prem Connector Hosts**sit within your network and allow Tulip to interface with SQL databases and APIs that aren't accessible to the cloud. **On-Premise Connector Host (OPCH)** Tulip **Connector Hosts**are designed to allow your Tulip Apps to interface with external systems such as databases, APIs, and machines. **On-Premise Connector Hosts (OPCH)**sit within your network and allow Tulip to interface with SQL databases and APIs that aren't accessible to the cloud.