Connectors are the interfaces through which niotix connects to the outside world.

Incoming connectors attach external data sources and platforms. Typical examples are LoRaWAN network servers (e.g. Firefly, ChirpStack, Things Stack, Loriot), plus generic entry points such as MQTT (Incoming) and Webhook (Incoming); depending on the setup, further sources (e.g. LwM2M Server) may apply. They are the entry into niotix: they supply raw or process data and—where the connector supports it—keep device inventories aligned between niotix and external platforms so data ingestion and lifecycle can converge in one place.

Functional profiles differ by connector. Possibilities include:

• Device management — synchronising create, read, update, and delete with the external system
• Data source for Virtual Devices and/or Digital Twins
• Rules/commands (e.g. downlinks to end devices)
• Data ingestion only, without the profiles above

This makes it clear per interface whether niotix primarily receives data, mirrors devices, or combines both. For supported network servers and protocols, niotix unifies end-device lifecycle management: instead of maintaining devices and metadata in parallel UIs, niotix remains the leading place for create, import, update, and delete towards each target system—within the limits of each connector’s capabilities.

Outgoing connectors send data to downstream systems, including via Webhook (Outgoing), MQTT (Outgoing), Kafka (Outgoing), Websocket, or MQTT Broker—each with a short pointer in the overview for integration flows; detailed settings are in the linked sections under Outgoing connectors. Typical uses include alarms, state changes, aggregated metrics, or continuous data hand-off to business applications and integration landscapes (e.g. data lakes, OT systems, notification channels).

In integration flows, the steps usually form a chain: trigger (e.g. new measurement, alarm) → filters (only events relevant to the target) → transformations (structure and format) → outgoing connector to the target system. Filters and transformations reduce and structure the data volume before it is sent out.

XAPI and outgoing connectors complement each other: events and current states usually run through flows plus push or streaming channels; historical time series can be queried from the database via the XAPI when needed, without putting them on the same real-time path.

Cross-connector functions

The following functions are equally available for all connectors:

Adding a connector

To add a new connector, select the connector type in the create dialog. The arrow next to the connector name in the menu indicates whether it is an incoming connector (arrow down) for receiving data in niotix or an outgoing connector (arrow up) for sending data. After you choose a type, the required connector settings are shown.

For all connectors: in the create dialog the button is “Validate & Save”; in the connector detail view (after saving) it is “Save”—in both cases validation runs first and, if successful, settings are saved. To delete, use the trash icon in the connector list; deletion is confirmed in a dialog.

Connector Logs

After a connector has been created, open its details via the pencil icon in the list; settings can be edited there. On the Connector Logs tab, the last 100 data packets processed by the connector (incoming and outgoing) are shown with timestamp and payload; the list can be refreshed and searched. The search covers both payload and metadata; the search term is preserved in the URL, allowing filtered views to be shared as a link. That helps when data does not arrive as expected.

Status logs

On the Status Logs tab of the same detail view you see a connection log with the last 100 status messages (including successful and failed connection attempts), also with refresh and search. That supports troubleshooting for connectivity issues.

Overview of available connectors and functions

The tables are split into incoming and outgoing connectors—matching how they are classified in the UI (down arrow vs. up arrow in the menu).

Incoming connectors

Outgoing connectors

Description of the functions

• Device management: The connector offers device synchronisation in an external system (create, read, update, delete)
• Virtual Device data point: The connector can be used as a source for data points in the Virtual Device
• Data point Digital Twin: The connector can be used as a source for data points in the Digital Twin
• Rules: The connector can be used to send commands
• Data forwarding: The connector can be used to forward data points (integration flows)

Incoming connectors

Incoming connectors such as MQTT(Incoming) and Webhook (Incoming) have a Template field in the UI. This field contains the transformation of incoming data into the niotix internal standard data format. The expected input format is described in the section Data format for incoming data.

Pass-through: If the data already arrives in the niotix standard data format, the “Pass-through” template (or pass-through) can be used. The payload is then forwarded unchanged.

JavaScript transformation: If the incoming format does not match the niotix standard data format, a custom JavaScript function can be stored. Clicking the pencil button opens the editor to enter and test the transformation. The function is entered as the body; the wrapper is fixed: module.exports = (packet) => { ... }. The argument packet corresponds to the input format of the connector.

Example — incoming packet from an external source:

{
  "deviceId": "sensor-42",
  "timestamp": "2025-03-21T09:26:04Z",
  "payload": {
    "temperature": 21.5,
    "humidity": 58
  }
}

Matching transformation that converts this into the niotix standard format:

module.exports = (packet) => {
  return {
    identifier: packet.deviceId,
    variable: "temperature",
    data: {
      value: packet.payload.temperature,
      time: packet.timestamp     // optional; if omitted, system time is used
    }
  };
};

The fields identifier, variable, and data correspond to the niotix standard format for Virtual Devices; alternatively, routing can be used to address Digital Twins via reference-ID keys — details in the section Addressing data point updates via data routing.

Connector “Chirpstack”

The connector connects to the Chirpstack instance: uplinks are received via webhook (HTTP POST); device management and downlinks are handled through the Chirpstack REST API. A connector is always scoped to one “Application” in Chirpstack. The connector supports Chirpstack versions 3 and 4.

Function details:

• Authentication: API key (Bearer token)
• Inbound data path: Webhook-based — Chirpstack pushes uplinks via HTTP POST to niotix
• Chirpstack version: v3 or v4 (default: v4); v4 additionally requires a Tenant ID
• API timeout: 2,000 ms
• Downlink parameters (configurable in the Virtual Device or a rule):
  • EUI — target device EUI as hex string (16 chars, required)
  • data — downlink payload as hex string (required)
  • port — LoRaWAN FPort, default: 0
  • confirmed — confirmed downlink, default: false
  • pending — mark as pending, default: false

Supported remote actions:

• Create device: Supported. Devices which are created in niotix will automatically be created in the application the connector is pointing to.
• Import device: Supported. Devices which already exist in Chirpstack can be imported by their EUI.
• Update device: Supported. Connector-specific properties that are changed in the Virtual Device, such as region or title, are also changed in Chirpstack.
• Delete device: Supported. Devices which are deleted in niotix will be automatically deleted from Chirpstack application (if option “Delete device in remote external service” is activated during deletion)
• Send downlink: Supported. Downlinks can be sent from the Virtual Device or a rule in the Digital Twin.

Connector Firefly

The Firefly connector establishes a bidirectional connection to DIGIMONDO’s Firefly LoRaWAN network server: uplink data is received via an MQTT subscription; downlinks and device management are handled via the Firefly REST API.

Function details:

• Authentication: API key (for REST API and MQTT)
• Protocol: REST API (device management, downlinks) + MQTT (data reception via RabbitMQ subscription)
• API timeout: 2,000 ms; MQTT timeout: 2,000 ms
• Downlink parameters (configurable in the Virtual Device or a rule):
  • eui — EUI of the target device (required)
  • payload — downlink payload (required)
  • encoding — encoding: utf8 (default), base16, base64
  • port — LoRaWAN FPort, default: 0
  • confirmed — confirmed downlink, default: false
• Multicast downlink: Supported (via multicast ID mcid)
• Device defaults: Activation mode OTAA; region EU868; RX2 data rate 0 (SF 12 / BW 125 kHz)

Supported remote actions:

• Create device: Supported. Virtual devices created in niotix are automatically created in the organisation the connector points to.
• Import device: Supported. Virtual devices that already exist in Firefly can be imported by their EUI.
• Update device: Supported. Connector-specific properties changed in the Virtual Device, such as region or title, are also changed in Firefly.
• Delete device: Supported. Virtual devices deleted in niotix are automatically removed from the Firefly organisation (if the option “Delete device in remote external service” is enabled).
• Send downlink: Supported. Downlinks can be sent from the Virtual Device or a rule in the Digital Twin.

Connector “Loriot”

The connector connects to the Loriot instance: uplink data is received via WebSocket; downlinks and device management are handled via the Loriot REST API. A connector is always scoped to one “Application” in Loriot.

Function details:

• Authentication: API key
• Protocol: WebSocket (data reception) + REST API (device management, downlinks)
• WebSocket heartbeat: 10 seconds; connection timeout: 30 seconds without an incoming message
• Rate limiting: Disabled by default; can be enabled (default when active: 6 messages / 2 seconds, configurable)
• Downlink parameters (configurable in the Virtual Device or a rule):
  • EUI — EUI of the target device (required)
  • data — downlink payload (required)
  • encoding — encoding: utf8 (default), base16, base64
  • port — LoRaWAN FPort, default: 0
  • confirmed — confirmed downlink, default: false
• Activation modes: OTAA (default) and ABP are supported

Supported remote actions:

• Create device: Supported. Devices which are created in niotix will automatically be created in the application the connector is pointing to.
• Import device: Supported. Devices which already exist in Loriot can be imported by their EUI.
• Update device: Supported. Connector-specific properties that are changed in the Virtual Device, such as region or title, are also changed in Loriot.
• Delete device: Supported. Devices which are deleted in niotix will be automatically deleted from Loriot application (if option “Delete device in remote external service” is activated during deletion)
• Send downlink: Supported. Downlinks can be sent from the Virtual Device or a rule in the Digital Twin.

Connector “LwM2M Server”

The “LwM2M Server” connector is part of the “LwM2M Server” module and allows LwM2M devices to be integrated into niotix.

Function details:

• Authentication: OAuth2 (username/password against the LwM2M server); access token is generated automatically on validation and is read-only
• API timeout: 2,000 ms
• Data path (inbound): Webhook-based — LwM2M devices send uplinks via HTTP POST to niotix; the counterpart is the LwM2M server
• Security modes: PSK (PreShared Key, key as hex string) or NoSec (unencrypted, development only)
• Server types: Management Server or Bootstrap Server — configured per device
• Rate limiting: 1,000 messages / 5 seconds
• Downlinks: Not supported

Connector “MQTT(Incoming)”

The “MQTT(Incoming)” connector acts as an MQTT client and connects to an MQTT broker (e.g. a GWA system) to process measurement data in niotix.

Function details:

• Authentication: Either Basic Auth or mutual TLS (mTLS). Basic Auth requires username and password. mTLS requires a client certificate and client key; optionally, a CA certificate can also be provided for server verification
• MQTT version: 3.1.1
• TLS/WebSocket: Encryption via mqtts:// in the URL field; WebSocket connections via ws:// or wss:// also supported
• QoS (subscribe): Default 1 (configurable)
• Clean session: Default Yes
• Keepalive interval: 60 seconds (MQTT.js default)
• Connection timeout: 2,000 ms; automatic reconnect after 5,000 ms — the topic subscription is renewed automatically
• Message format: JSON is parsed; arrays are processed element by element (max. 50 objects per message, configurable); on parse failure the value is forwarded as a raw string

Connector “niota”

The “niota” connector sets up a connection to an existing instance of niota 1.0 / IoT Data Hub to receive device data from a selected account.

Connector “openweathermap.org”

The “openweathermap.org” connector retrieves weather data from the openweathermap.org platform and provides it as data points in the Digital Twin. Available data includes current measurements and a forecast for up to 7 days (daily rain forecast for the current day).

Setting up the connector requires a registration at openweathermap.org and the creation of an API key there.

Function details:

• Authentication: API key
• API: openweathermap.org One Call API v3
• Data points (selection): Current values (cur_temperature, cur_humidity, cur_pressure, cur_wind_speed, cur_wind_direction, cur_uv_index, cur_clouds_pct); daily forecast for today and up to 6 following days (today_temp_day/night/min/max, today_wind_speed, today_rain_mm, today_uv_index etc.)
• Update interval: Selectable: 1 min, 10 min, 30 min, 1 h, 6 h, 12 h, 1 d; internal default: 60 minutes
• Units: metric or imperial
• Downlinks / device management: Not supported

Note: This connector uses the one-call API (https://openweathermap.org/api/one-call-3). The update interval may be limited by the openweathermap.org account plan. When the same API key is used for multiple connectors, the number of API calls is aggregated; exceeding the limit may incur charges.

Connector “smartservice”

The “smartservice” connector established a connection to the solutions of Thüga SmartService.

Connector “Things Stack”

This connector connects to a LoRaWAN network server of type The Things Network or The Things Industries: uplinks are received via MQTT; device management and downlinks are handled through the TTS REST API.

Function details:

• Authentication: API key (Bearer token)
• Protocol: MQTT (data ingestion, TLS-encrypted) + REST API (device management, downlinks)
• MQTT timeout: 2,000 ms
• Activation modes: OTAA (default) and ABP are supported
• LoRaWAN classes: A (default), B (Beaconing), C (Continuous), B+C
• Update device: Not supported — changes to connector-specific device fields are not written back to TTS
• Downlink parameters (configurable in the Virtual Device or a rule):
  • deviceId — End Device ID of the target device (required)
  • frm_payload — downlink payload (required)
  • encoding — encoding: hex (default), base64
  • f_port — LoRaWAN FPort, default: 1
  • confirmed — confirmed downlink, default: false

Supported remote actions:

• Create device: Supported. Virtual devices which are created in niotix will automatically be created in the Things Network/Industries instance the connector is pointing to.
• Import device: Supported. Virtual devices which already exist in The Things Network/Industries instance can be imported by their End Device ID.
• Update device: Updating the device in the remote system is not supported yet.
• Delete device: Supported. Virtual devices which are deleted in niotix will be automatically deleted from The Things Network/Industries instance.
• Send downlink: Supported. Sending a downlink from niotix to the sensor remotely via the connected The Things Network/Industries instance.

Connector “Webhook (Incoming)”

The “Webhook (Incoming)” connector provides an HTTP endpoint through which external systems can send data to niotix via HTTP POST. The endpoint URL is generated automatically and can be copied from the read-only “API endpoint” field.

Function details:

• Authentication: Token-based — the token is generated automatically and included in the “API endpoint” field as ?token=<token>. Alternatively, the token can be passed directly (without a Bearer prefix) in the Authorization header: Authorization: <token>.
• HTTP method: POST; OPTIONS is supported for CORS preflight (response: 204).
• Message format: The body must be valid JSON. The Content-Type header is not enforced server-side; application/json is recommended.
• Batch processing: A single JSON object or an array of objects. The maximum array size is 50 entries by default and is configurable via environment variable (INCOMING_WEBHOOK_MAX_BATCH_SIZE).
• Error responses: 400 for invalid JSON or exceeded array limit; 401 if no token is provided; 403 for an unknown token or a disabled connector.
• Rate limiting: Internally limited to 1,000 requests per 5 seconds (configurable via environment variable).

The incoming data format is converted to the niotix standard format via the Template — see section Incoming connectors. If the source data already matches the niotix format, “Pass-through” is sufficient. For other formats, a JavaScript transformation can be stored.

Connector “Wireless M-Bus Decoder”

The Wireless M-Bus Decoder connector is part of the “Wireless M-Bus Decoder” module and enables simple decoding and decryption of Wireless M-Bus messages (wM-Bus), which are sent from a wM-Bus concentrator to niotix via a connector.

Outgoing connectors

Outgoing connectors send data from niotix to external systems — typically triggered by an integration flow. The data format received by an outgoing connector corresponds to the niotix-internal output object of the integration flow (e.g. the “After state handling” object with meta and value fields).

If the format needs to be adapted to the requirements of the target system, a transformation can be added in the integration flow before the outgoing connector. Transformations can be written in JavaScript or JSONata and tested directly in the UI.

Connector “actility”

The “actility” connector enables the sending of LoRaWAN downlinks to Actility devices via the ThingPark API. It is used exclusively as an action in a rule in the Digital Twin.

Function details:

• Authentication: OAuth2 Client Credentials — client_id = <CustomTargetProfile>/<Login>, client_secret = password; the token is renewed automatically before each request (no manual token management required)
• Default baseURL: https://dx-api.thingpark.com (used when the field is left empty)
• API timeout: 2,000 ms
• Downlink parameters (configurable in the rule in the Digital Twin):
  • eui — EUI of the target device (required)
  • payloadHex — downlink payload as hex string (required)
  • port — LoRaWAN port (FPort), default: 0
  • confirmed — confirmed downlink, default: false
  • flushQueue — flush existing downlink queue, default: false
• Success check: The Actility API must respond with status: "QUEUED" — otherwise the error is written to the connector log

Connector “IEC-60870-5-104 Push”

The IEC-60870-5-104 push connector is an outgoing connector in niotix that sends data to the niotix IEC-104 server using an integration flow. In addition to the standard metadata, the outbound packets also contain the outbound_values object, which contains the IEC-104 addresses.

Connector “kafka”

The “kafka” connector forwards data points to an Apache Kafka cluster. It is used as a connector step in an integration flow and can send state changes of a Digital Twin to the cluster for further processing or storage.

Function details:

• Authentication: Optional — SASL PLAIN (username/password); optional TLS/SSL (boolean)
• Message format: Each message contains a randomly generated UUID key, the payload as a string value, and the fixed header origin: niotix
• Acknowledgement mode (acks): Default -1 (all in-sync replicas must confirm)
• Publish timeout: Default 30,000 ms
• Connection timeout: 500 ms; 2 retries on failure (initial retry time: 100 ms)
• Topic: Defined per message in the integration flow — topics must be pre-created on the Kafka cluster

Connector “mail”

The “mail” connector handles email sending from niotix and is used in two scenarios:

• Rule editor in the Digital Twin: Rules can be created in the rule editor that send emails when certain value conditions are met.
• System emails: The connector can be configured at account level as an SMTP relay for niotix system emails (e.g. password reset, welcome email, notifications). The assignment is made in Account management under Email settings → Use mail connector.

Function details:

• Protocol: SMTP via Nodemailer; supported fields per message: from, to, cc, bcc, subject, text, html, attachments
• Authentication: Username/password or OAuth2 — automatic token renewal implemented only for Outlook365(OAuth2.0) (incl. one retry on authentication error 535); all other services use Nodemailer standard auth
• TLS: Secure → implicit TLS from connection start (typically port 465); Unsecure → connection starts unencrypted, STARTTLS may be offered by the server; IgnoreTLS → STARTTLS negotiation is disabled (plain unencrypted transmission)
• Connection timeout: 2,000 ms (TCP connection to the SMTP server); overall send timeout: 15 seconds
• Retry: No automatic retry (except Outlook 365 OAuth2: one retry after token renewal on error 535)
• Rate limiting: Optionally configurable per hour; no limit if not set

Connector “MQTT (Outgoing)”

The “MQTT(Outgoing)” connector connects to external MQTT brokers and can be used as a connector step in integrationflows. Topic and quality of service are defined in the integrationflow settings.

Function details:

• Authentication: Either Basic Auth or mutual TLS (mTLS). Basic Auth requires username and password. mTLS requires a client certificate and client key; optionally, a CA certificate can also be provided for server verification
• MQTT version: 3.1.1
• TLS/WebSocket: Encryption via mqtts:// in the URL field; WebSocket connections via ws:// or wss:// also supported
• QoS (publish): Default 0; configurable in the integration flow (0 / 1 / 2)
• Clean session: Default Yes
• Keepalive interval: 60 seconds (MQTT.js default)
• Connection timeout: 2,000 ms; automatic reconnect after 5,000 ms on connection loss
• Message format: Payload is transmitted as a string unchanged (typically JSON from the integration flow)

Connector “mqttbroker”

The “mqttbroker” connector uses a RabbitMQ instance (with MQTT plugin) in the niotix service network as the MQTT broker. When validation is run, a topic and login data (user and password) are created automatically and the user is provisioned in RabbitMQ. The connector publishes data to this topic; external MQTT clients can receive the data by subscribing. This connector is suitable when the data-receiving remote station uses an MQTT client.

Function details:

• SaaS (niotix.io): Only MQTTS (MQTT over TLS) is supported — use the broker endpoint shown after validation (mqtts://… including port). Unencrypted mqtt:// is not available. TLS server certificates for SaaS are issued via Let’s Encrypt; broker identity is verified against the same public trust chain as HTTPS access to niotix.io.
• Certificates on the MQTT client: No client certificate or client private key is required; broker authentication uses only the automatically generated username and password. Server TLS verification normally uses the default certificate store of the operating system or runtime (public certification authority) — additional certificate files usually do not need to be imported. Only if the broker uses a self-signed certificate or a private corporate CA (often in OnPremise deployments) must the appropriate CA or server certificate be configured as trusted in the MQTT client, or the library’s certificate verification adjusted accordingly.
• Devices without a full standard certificate store (e.g. embedded systems, older firmware): If no current public CA trust store is available, it cannot by itself verify the broker certificate. Then the firmware or MQTT library typically needs at least the issuing CA of the broker certificate (or the chain to a trusted root) configured as a fixed trust anchor — obtained from the certificate presented by the broker or from the operator’s documentation. For niotix.io (SaaS), that chain is Let’s Encrypt / ISRG; current root and intermediate certificates are documented at Let’s Encrypt — Certificates. Alternatively, certificate pinning to the server certificate (or public key) can be used; if the broker certificate is rotated, the device configuration must be updated. Disabling TLS certificate verification is only acceptable in isolated test environments, not as a permanent production approach.
• Authentication: Username and password are generated automatically on first validation and are read-only — no manual input required
• MQTT version: 3.1.1
• Topic: Generated automatically (format: <vhost>/<uuid>/#); external clients subscribe to this topic, niotix publishes to <vhost>/<uuid>
• QoS (publish): Fixed at 0 — the subscribing client can use different QoS levels (see note below)
• Clean session: Default true
• Keepalive interval: 60 seconds (MQTT.js default)
• Connection timeout: 2,000 ms; automatic reconnect after 5,000 ms on connection loss
• Message format: Payload is transmitted as a string unchanged (typically JSON from the integration flow)

Connector “Webhook (Outgoing)”

The “Webhook (Outgoing)” connector sends data from niotix via HTTP to external systems. It is used as a connector step in an integration flow. To test the connection, open and free platforms such as webhook.site can be used if no own solution is available.

Function details:

• HTTP methods: POST (default), PUT, GET, PATCH
• Authentication: None (default), Basic Auth, Bearer Token, X-API-Key, API-Key — configured via Header Auth Type and Header Auth Value
• Custom headers: Additional HTTP headers configurable as a JSON object (e.g. {"X-Custom-Header": "value"})
• Message format: Default application/json; alternatively application/x-www-form-urlencoded; the payload is passed as a JSON string and parsed before sending
• Always-sent headers: User-Agent: webhook connector, Content-Type according to encoding setting
• Timeout: Default 2,000 ms (selectable: 1,000 / 2,000 / 3,000 / 5,000 / 10,000 ms); applies to the entire request (no separate connect/read timeout)
• Retry: No automatic retry on HTTP errors — one attempt per message
• Error handling: Non-2xx responses and response bodies containing an error field are treated as errors and written to the connector log
• TLS: Default rejectUnauthorized: true — self-signed certificates are rejected (can be disabled)

Connector “Websocket”

The “Websocket” connector establishes an outgoing WebSocket connection to an external server and transmits data points as a real-time data stream. It is used as a connector step in an integration flow. To test the connection, open and free services such as Pie Socket or Socketbay can be used if no own solution is available.

Function details:

• Protocol: RFC 6455 WebSocket (library: ws v7); encryption via wss:// in the URL field
• Authentication: No built-in authentication — credentials can be passed as query parameters in the URL if required (e.g. wss://server.example.com/data?token=<token>)
• Message format: Payload is transmitted as a UTF-8 text frame string; no additional envelope from niotix
• Connection timeout: Default 10,000 ms (configurable in the settings field)
• Reconnect: No automatic reconnect after connection loss
• Keep-alive / Ping-Pong: Not configured