Reference · for Engineers, Administrators
Outbound target types
Every kind of outbound target, the parameters each one reads, how values are sent, and what Check and Test Connection prove.
An outbound target sends a device's values to a system outside Proxus. This page lists every target type, the parameters each type reads and how the gateway sends to it. To create one, see Outbound targets.
Fields of every target
| Field | Meaning |
|---|---|
| Profile Name | A unique name. |
| Type | The kind of target, from the tables below. Cannot be changed on SYSTEM INTERNAL DB. |
| Transport Strategy | Pass Through: every reading with all its values. On Change: only the values that changed; a reading with no change sends nothing. Pipelines Only: nothing from normal device delivery; only pipelines that name this target send to it. |
| Parameters | Key and value rows. The keys each type reads are listed below. Values of keys such as Password, Token or Secret are masked. |
| Status | Ready, Running, Degraded, Error or Stopped as reported by the gateways, Unused when no device uses the target, Unknown when nothing has been reported yet. With Last Success, Last Failure and Last Error. |
| Devices Used | How many devices send to this target. |
The gateway that reads a device also sends its values to the device's targets, so the target must be reachable from that gateway's network.
Check and Test Connection
Check on a saved target opens a check of its parameters and shows the health reported by the gateways.
- The parameter check lists Errors (the target cannot work, for example a required key is missing), Warnings and Notes (a key the type does not read, with a suggestion when it looks like a typo, or a key left empty that falls back to a placeholder value).
- Test Connection then connects to the target from the hub or from a gateway you choose and reports one of:
Connected(the target accepted the credentials),Reachable(something answers at the address, credentials not verified),Failedwith the reason, or no probe available for the type. No data is written by the test.
The Probe column below says what the test proves for each type.
Message brokers and streaming
| Type | Parameters (required in bold) | Probe |
|---|---|---|
| MQTT | BrokerHost, BrokerPort (1883), Username, Password, UseTls (false), TlsVersion (Tls12), CertificateThumbprint, ServerCertificateThumbprint, Topic (falls back to proxus_device_data), QualityOfServiceLevel (1), MaxBatchSize (50), MessageBatchTimeoutMs (500), ConnectionTimeoutSec (5), MaxReconnectAttempts (10), InitialReconnectDelayMs (1000), MaxReconnectDelayMs (30000), HealthCheckIntervalSec (10) | Connects and checks the broker's answer. |
| SparkplugB | BrokerHost (falls back to localhost), BrokerPort (1883), Username, Password, GroupId (ProxusGroup), EdgeNodeId, ScadaHostIdentifier (scada1), UseTls (false), UseWebSocket (false), TlsVersion, CertificateThumbprint, ServerCertificateThumbprint, ReconnectInterval (5 s) | Connects and checks the broker's answer. |
| Kafka Messaging System | BootstrapServers (falls back to localhost:9092), Topic (falls back to proxus_device_data), ClientId, SecurityProtocol, SaslMechanism, SaslUsername, SaslPassword | Asks the cluster for its brokers and whether the topic exists. |
| RabbitMQ Messaging System | HostName, UserName, Password (fall back to localhost, guest, guest), Port (5672), VirtualHost (/), Exchange, RoutingKey | Signs in to the virtual host and checks the exchange. |
| Redis Database | Host (falls back to localhost), Port (6379), Password, Database (0), DataType (hash) | Signs in and sends PING. |
Username and Password on MQTT are used only when both are set.
Cloud services
| Type | Parameters (required in bold) | Probe |
|---|---|---|
| AWS IoT Core | EndPoint, CertificateThumbprint (the thing's device certificate in the Certificate Store, chosen as Client Certificate), ClientId, Port (8883), UseTls (true), ServerCertificateThumbprint (Amazon Root CA 1), Topic (falls back to proxus_device_data), and the batch and reconnect keys of MQTT | Connects with the certificate. |
| Azure IoT | HostName (for example my-hub.azure-devices.net), DeviceId, SharedAccessKey, OperationTimeoutMs (30000), RetryMaxAttempts (5), RetryMinBackoffMs (200), RetryMaxBackoffMs (5000), RetryDeltaBackoffMs (200) | Opens the device connection. |
| Azure Data Lake Gen2 | AccountName, FileSystem, TenantId, ClientId, ClientSecret, Directory, PathPattern, Format (parquet, json or csv), CsvDelimiter, CreateIfNotExists, DefaultRegion, DefaultSubject, FlushIntervalSeconds (30), MinBatchCount (5000), MinBatchBytes (16 MiB), MaxBatchCount (100000), MaxBatchBytes (64 MiB), MaxWaitSeconds (300) | Signs in and checks that the file system exists. |
Time-series and analytics databases
| Type | Parameters (required in bold) | Probe |
|---|---|---|
| ClickHouse | Host (falls back to localhost), Port (8123, HTTP), Database, Table, Username, Password, TTLExpression, LogTTLExpression, WriteIntervalSeconds (1) | Runs SELECT 1. |
| InfluxDB | Url (falls back to http://localhost:8086), Token, Organization (proxus), Bucket (proxus), Measurement (proxusdevicedata) | Checks the token and that the bucket exists. Each value is written as one point at the time it was read, tagged deviceName and deviceId; numbers and booleans keep their type. |
| TDengine | Host (falls back to localhost), Port (6041), Username (root), Password (taosdata), Database, StableName, Keep (365), Duration (10), Buffer (256) | Signs in. |
| Splunk | Url (the HTTP Event Collector), Token, UseAcknowledgment (false). HTTPS follows the Url (https://); the older UseSSL has no effect. Each event carries the time its value was read, so values sent after an outage are indexed at the right time | Checks the collector's health and the token. |
REST API
| Type | Parameters (required in bold) | Probe |
|---|---|---|
| REST API | Uri (absolute http or https address), AuthenticationType, Username, Password, Token, APIKey | Sends a HEAD request. |
Each reading is sent as a JSON POST to Uri. AuthenticationType decides the credentials: Basic (with Username and Password), Token (sent as Authorization: Bearer <Token>) or APIKey (sent as the header X-Api-Key). Any other value, including Bearer and OAuth, sends no credentials. A REST API target can also be called from a pipeline's Call Api node; set its strategy to Pipelines Only for that use.
Relational databases
The gateway creates the table it needs on first write.
| Type | Parameters (all required) | Probe |
|---|---|---|
| Microsoft SQL Server | Server, User, Password, Database; optional TrustServerCertificate, Encrypt | Opens a connection. |
| PostgreSQL Database | Server, User, Password, Database; optional Port | Opens a connection. |
| MySQL Database | Server, User, Password, Database; optional Port | Opens a connection. |
| Oracle Database | Server (data source or TNS name), User, Password | Opens a connection. |
| Firebird Database | Server, User, Password, Database | Opens a connection. |
| System Database | none | none. This is the Proxus historian itself (SYSTEM INTERNAL DB). |
Types that cannot be used in this version
The type list also contains these, but they do not work in this release:
| Type | Why |
|---|---|
| IBM DB2, SAP HANA, SQLite Database, VistaDB, Advantage Database, Adaptive Server Enterprise, SQL Anywhere, Pervasive Database | The gateway does not include a database driver for them, so writing fails. |
| Microsoft Access | Needs a Windows-only driver that the gateway does not have. |
| XML File | The file is opened read-only, so nothing can be written. |
To write to one of these databases, send the values to a supported target or a function that writes them.
TLS parameters
Every TLS connection verifies the server: its certificate must match the address and chain to a trusted root, which is the target's trusted server certificate from the Certificate Store or the operating system's roots. No target accepts an unknown certificate, and Test Connection verifies the same way. Thumbprints are copied from the Certificate Store. The gateway reads the certificates from the store at every send, so a renewed or replaced certificate is used without changing the target.
| Type | TLS settings |
|---|---|
| MQTT, AWS IoT Core, SparkplugB | Trusted Server Certificate field in the parameter form: any CA or server certificate in the store, the Proxus Platform CA included. The client certificate is uploaded with Certificates. |
| Kafka Messaging System | With SecurityProtocol Ssl or SaslSsl: CertificateThumbprint (client certificate), ServerCertificateThumbprint (trusted CA). The broker's host name is verified. |
| RabbitMQ Messaging System | UseTls, CertificateThumbprint, ServerCertificateThumbprint. The default TLS port is 5671. |
| Redis Database | UseTls, CertificateThumbprint, ServerCertificateThumbprint. |
| ClickHouse | UseTls, CertificateThumbprint, ServerCertificateThumbprint. The default TLS port is 8443. |
| REST API, InfluxDB, Splunk | An https address is verified. CertificateThumbprint and ServerCertificateThumbprint are optional. |
| TDengine | UseTls (verified against the operating system's roots). |
| PostgreSQL Database | SslMode: Disable, Allow, Prefer, Require, VerifyCA or VerifyFull, and ServerCertificateThumbprint for the verifying modes. |
| MySQL Database | SslMode: None, Preferred, Required, VerifyCA or VerifyFull, and ServerCertificateThumbprint for the verifying modes. |
When SslMode is not set, the database's own default applies.
Uploading a certificate with Certificates (PEM certificate and key, optional CA file) adds the CA to the store and sets it as the target's trusted server certificate. For AWS IoT Core that is Amazon Root CA 1, downloaded by Proxus; without internet access the operating system's roots are used.
Step-by-step setup for each type, AWS IoT Core included, is in Secure connections to targets.
Buffering
Every working target type keeps data in a durable queue on the gateway. Data enters the queue first and leaves it only after the target took it, so values read while the target is down, restarting or unreachable (also when the gateway starts) are written in order when it is back.
- Data waits for the gateway's Buffer Retention (hours): default 48 hours, up to 30 days.
- While the target is unreachable, its status error says how many queued messages are waiting at the gateway.
- A record the target answers but never accepts (for example a value too long for the column) is skipped after a few attempts and named in the status. The data behind it does not wait.
- Delivery is at least once: rarely, a record that was written but whose confirmation was lost is written twice.
Related
- Outbound targets: create a target and attach it to devices.
- Troubleshoot data: values missing in a target.
Was this page helpful?
Evaluating Proxus? See it on your own machines in a 30-minute technical session.