DALI · API access
Cloud destinations
Send a station's data straight to your own service over HTTPS, Azure, AWS, MQTT, SFTP or TCP. What each type needs, the common settings, and how delivery works.
A destination is a place the station sends its data to by itself, on a schedule. You add destinations in the Destinations section of the Cloud upload tab on the Network page. Admins and Factory can add and change them. For the steps, see Send data to your cloud.
Firmware 4.1 and later
Destinations need firmware 4.1 or later. On firmware 4.0, the station can upload to Aeron Cloud (Live3), FTP and HTTP servers only.
A station can hold up to 16 destinations. Each one runs on its own: a slow or failing destination does not hold the others up.
Destination types
| Type | What it does | What you need |
|---|---|---|
| HTTPS webhook | Sends each batch to a URL you give, with POST or PUT | The URL. Optionally an Authorization header, a secret query string and other headers. |
| Azure IoT Hub | Device-to-cloud messages to an IoT Hub device | The hub host name (*.azure-devices.net) and the device primary key, or an X.509 device certificate when connecting with MQTT. The device ID defaults to the station's serial number. |
| Azure Event Hubs | Events to an event hub | The namespace host name (*.servicebus.windows.net), event hub name, shared access policy name and policy key |
| AWS IoT Core | Messages to an AWS IoT thing | The device data endpoint (*.amazonaws.com), a topic, and the thing's device certificate and private key. MQTT on port 8883 by default, or HTTPS on port 8443. |
| MQTT broker | Publishes each batch to a topic on your broker | Broker host and port (8883 by default), topic, and a username and password if the broker needs them |
| SFTP | Writes one file per batch into a folder on an SFTP server | Host, port (22 by default), username, a password or private key, the remote folder, and the server's host key fingerprint (SHA256:...) |
| TCP socket | Writes each batch to a TCP connection | Host and port. Choose how batches are separated: a 4-byte big-endian length prefix (default), a newline, or one connection per batch. Optionally the reply that means "delivered". |
Legacy FTP and HTTP uploads also appear in this list, marked Legacy.
Encryption
Every type uses TLS by default, and the station checks the server's certificate against built-in public roots (Let's Encrypt, DigiCert, Microsoft, Amazon). If your server uses a private or company certificate, upload its CA certificate under the advanced settings. You can also give the station a client certificate and key where the server asks for one.
MQTT and TCP can be sent without encryption, but only if you tick a box confirming the receiver is on a private network. Do not do this across the internet.
Placeholders
In a URL, topic, client ID or username you can write {{usn}} for the station's serial number and {{stream}} for the kind of data: interval for minute data and inst for 1-second data. The default topic is aeron/{{usn}}/{{stream}}.
Settings every destination has
| Setting | Values | What it does |
|---|---|---|
| Name | Up to 64 characters | Your own label, shown in the list |
| Minute data (logged readings) | On by default | Sends the logged records |
| 1-second data | Off by default | Sends raw readings every second. About 60 times more data; think twice on a cellular link. |
| Send every | 1 minute (default), 5 minutes, 15 minutes, 1 hour, 6 hours, 1 day | How often the station connects. Each send carries everything new since the last one. |
| Group readings into (advanced) | Whatever is new at each send, 1-minute blocks (default), 5, 15 or 60-minute blocks | How much time one message covers |
| Payload format (advanced) | See below | The shape of the data |
| Compress (gzip) (advanced) | Off by default | Much smaller uploads; your receiver must unzip them |
| Also send the parameter list (advanced) | On by default | Sends parameter names and units first, and again whenever they change |
| Start from (advanced, when adding) | Now (default), the oldest reading stored on the station, or a date and time in station time | Whether to send history already on the station |
Payload formats
| Format | Shape |
|---|---|
| JSON, one object per reading (default) | One JSON object per record |
| JSON with parameter names on every value | Larger, but each value is self-describing |
| JSON, compact columns | The smallest JSON form |
| Aeron Cloud JSON lines | The same newline-delimited JSON the Aeron Cloud uploader sends |
| CSV | The same columns as a download. See Data downloads. |
Values are rounded to each parameter's number of decimals. A value whose sensor has stopped answering is sent as NaN, unless you switch Stale Value Representation off on the Device page.
Passwords and keys
Passwords, keys and tokens are write-only. Once saved, the page shows only that one is set, never the value. Leave the field blank when editing to keep the stored one. If you change the server a secret belongs to (for example the host or username), you must enter the secret again, so a stored password is never sent to a new server.
Before a destination is saved, the station checks every field and then checks the finished configuration itself. A destination that would not run is not saved.
Testing
Click Test connection in the form, or Test on a saved row, to try the destination without waiting for the schedule. One test runs at a time per station.
The list shows each destination's Status, when it Last delivered, and how much is Waiting to send.
How delivery works
- Nothing is lost when the network drops. Each destination remembers the last record it delivered. When the connection comes back, it sends everything since then that is still stored on the station.
- Retries send the same bytes. A batch is saved on the station before the first attempt, so every retry is identical.
- A batch counts as delivered only when your receiver accepts it. Temporary failures are retried with increasing waits. A batch your receiver rejects outright is set aside so it does not block the ones after it.
- Expect the occasional duplicate. After an outage or restart, a batch may arrive twice. Every batch carries an ID (and the HTTPS webhook can send it as an
Idempotency-Keyheader), so your receiver can ignore repeats. - A receiver that keeps refusing is paused. After several rejections in a row the destination pauses and tries again later, so a broken receiver does not use up your data one batch at a time.