Skip to Content
ConnectionsCloud Connections

Cloud Connections

Not all data lives inside the factory. Some data is already on the internet: a machine builder’s cloud, an external MQTT broker, a system that can send webhooks. For these sources you don’t need a Collector. A Cloud Connection runs in the UpBlue cloud and collects the data directly.

The rest works exactly the same as a local connection: rules pick the values, transformations clean them and everything is stored as tags.

There are three cloud connection types:

TypeHow data arrivesUse for
WebhookThe external system pushes data to a unique UpBlue URLSystems that can send HTTP messages
MQTTUpBlue subscribes to an MQTT broker on the internetExternal or hosted MQTT brokers
WebSocketUpBlue opens a streaming connection to an external serverAPIs that stream live values

Create a Cloud Connection

Name connection

A connection is created within an organisation. Go to the UpBlue Management Environment to open an organisation.  Go to the connection page to create a connection.

Click on:

Choose the Cloud source and select the connection type. Give the connection a name. This name is only for identification and can be changed later.

Click on:

Labels

Labels tell UpBlue where the data of this connection comes from. The Enterprise and Site labels are prefilled. Fill in the location as far as it makes sense. Labels are optional and can be overridden per rule. Read more about labels.

⚠️

Think carefully about the labels you choose! Changing them later will have effect on your dashboards! Read more about this here.

Create Connection

Click on: to create the connection. The connection will open.

Running a cloud connection

A cloud connection has no Collector. Instead:

Configure the fields and rules, then click: to run the connection in the UpBlue cloud.

The connection page shows the status, the last run and any errors. When a connection keeps failing, a warning with the last error is shown.

Log

Every cloud connection has a built-in log viewer. This is the first place to look when data is not coming in: you see exactly what the connection is doing and why a message was rejected. The log level can be set to Debug for more detail.

Webhook

A webhook is the simplest way for an external system to deliver data: it sends an HTTP message to a unique UpBlue URL. Many SaaS systems, IoT platforms and custom applications support webhooks out of the box.

Fields

Webhook URL

Created automatically. Copy this URL into the external system. All messages sent to it arrive at this connection.

Webhook token

A secret of at least 16 characters that the external system must send along, so only your system can deliver data. The token can be sent in three ways:

  • Header X-Webhook-Token: <token>
  • Header Authorization: Bearer <token>
  • URL parameter ?token=<token>
💡

The webhook accepts up to 10 messages per second. Sending faster is fine in short bursts, but sustained higher rates are rejected.

Rules

Webhook rules work like MQTT rules, without the topic: define the tag source (manual or extracted from the message body), the time source, and use the JSON to value and JSON filter transformations to pick values out of the message.

MQTT

The same protocol as the local MQTT connection, but for brokers on the internet: a hosted broker, or the broker of a machine builder. UpBlue connects as a client and subscribes to topics.

Fields

The fields are the same as the local MQTT connection: Protocol (TCP or Websocket), Address, Port, Username, Password and SSL. Since the broker is on the internet, SSL is normally on here.

The password is stored as a secret: after saving, it shows as “Set” and cannot be read back.

Rules

Exactly the same as local MQTT rules: topics with wildcards, tag from topic or body, time source and transformations.

WebSocket

For external systems that stream live values over a WebSocket API. UpBlue opens the connection and keeps listening.

Fields

Address

The address of the WebSocket server.

Authentication

How UpBlue authenticates to the server:

  • None
  • API key header — a header name and key, for example X-Api-Key
  • Basic — username and password
  • Bearer token

Keys, passwords and tokens are stored as secrets.

Subscribe message

Optional. Some APIs expect a first message that tells them what to send, for example {"subscribe": "measurements"}. This message is sent right after connecting.

Rules

WebSocket rules work like MQTT rules, without the topic: tag source, time source and the JSON transformations to pick values out of each message.

Last updated on