Overview
The Iotistica Agent is a lightweight runtime that runs directly on your edge hardware — industrial PCs, gateways, Raspberry Pis, or any Linux device. It connects to your industrial equipment, collects data, and routes it to wherever you need it: a local MQTT broker, InfluxDB, Azure, AWS, or GCP.
The agent is designed to work offline first. If the network goes down, data keeps accumulating locally in SQLite and flushes automatically when connectivity is restored. You don't need to babysit it.
What the Agent Does
Collects data from industrial devices. The agent speaks Modbus TCP/RTU, OPC-UA, BACnet, MQTT, SNMP, and CAN bus. You add an endpoint for each device, configure the connection and poll interval, and the agent handles the rest.
Routes data to destinations. Once data is coming in, you create subscriptions that send it to one or more destinations — a local MQTT broker, an InfluxDB instance, or a cloud IoT service. You can send the same data to multiple places simultaneously.
Discovers devices automatically. The discovery engine scans your network for compatible devices and presents them for review. You can set up recurring discovery rules so new devices are found as they appear.
Detects anomalies at the edge. The anomaly detection engine learns what "normal" looks like for each metric and raises alerts when readings drift outside the expected range. Alerts are evaluated locally — no cloud round-trip needed.
Monitors its own health. The dashboard shows CPU, memory, storage, and network bandwidth in real time. The agent also monitors schema changes in the data it receives and warns you if a device starts sending unexpected field names or types.
How It Works
Data flows left to right through four stages.
Endpoints: Data In
Each endpoint is a connection to a single industrial device. The agent runs a dedicated protocol adapter per endpoint — Modbus, OPC-UA, BACnet, MQTT, and so on — that polls the device at the configured interval and emits a stream of readings. Each reading has a metric name, a value, and a timestamp.
Multiple endpoints can use the same protocol independently. Ten Modbus devices run as ten separate adapters; a problem with one does not affect the others.
The Publish Pipeline
The pipeline sits between endpoints and destinations. It is where readings are batched, anomaly detection runs, and schema drift is monitored. When a batch is ready it is forwarded to every destination that matches the subscription rules.
Offline buffering: if a destination is unreachable, the batch is written to a SQLite queue and retried automatically when connectivity returns. No data is lost during outages.
Subscriptions: The Routing Rules
A subscription connects a source protocol to a destination and defines:
- Which payload format to use (raw JSON, field-name/value pairs for InfluxDB, or ECP for Sparkplug tooling)
- Which MQTT topic or InfluxDB measurement to write to
- Optional device or metric filters to include or exclude specific data
You can have multiple subscriptions from the same source to different destinations, and multiple sources feeding the same destination simultaneously.
Destinations: Data Out
A destination is a named, persistent connection to a service — an MQTT broker, InfluxDB, or a cloud IoT platform. The pipeline maintains one connection per destination and routes batches to it based on your subscriptions.
Anomaly Detection
The anomaly detection engine runs inside the pipeline. As readings flow through, it updates per-metric statistical models (EWMA, z-score, rate-of-change, and others) and raises an alert when a reading falls outside the expected range. Everything is evaluated locally — no cloud round-trip.
Schema Drift Monitoring
The pipeline learns what fields a device normally produces during a warmup period. After warmup it watches for:
- Missing fields — a reading that used to appear has stopped showing up
- New fields — the device is sending something it never sent before
- Type changes — a field that was a number is now a string
Sensitivity is tunable per protocol in Settings → Schema Drift Detection.
SQLite: The Local Store
Everything persists in a single SQLite file on disk. This includes endpoint and destination config, subscription rules, discovery history, anomaly baselines, schema drift baselines, the offline message buffer, and admin sessions. No external database is required.
Standalone Mode
Standalone mode means the agent runs independently — no cloud account required. You manage it entirely through a local web UI accessible on the device at port 48481. Everything lives on the device: configuration, historical data, anomaly models, and schema baselines.
This is the recommended starting point. You can always add cloud sync later without changing anything on the device.
The Admin UI
The web interface runs at http://[device-ip]:48481/admin/. It requires a username and password — the default is admin / admin, which you should change on first login.
| Section | What it's for |
|---|---|
| Dashboard | System health at a glance |
| Endpoints | The industrial devices you're collecting data from |
| Destinations | Where data gets sent (MQTT, InfluxDB, cloud) |
| Subscriptions | Rules that connect endpoints to destinations |
| Discovery | Auto-scan your network for new devices |
| Alerts | Anomaly alerts and detection rules |
| Settings | Agent configuration |
| Administration | User accounts |