Skip to main content

One Agent, Every Protocol, One Data Stream

· 4 min read
Iotistica Team
Iotistica Team
Iotistica

Most plant floors don't run on one protocol — they run on all of them. A Modbus energy meter here, an OPC UA PLC there, a BACnet chiller down the hall, maybe an MQTT-speaking sensor someone bolted on last year. Every one of them "just needs a driver," and six months later you've got a pile of point-to-point integrations that only one person on the team fully understands.

The Iotistica Agent exists to collapse that mess into a single, consistent data stream — one thing to install, one place to look, one format flowing out.

What it actually does​

The agent runs directly on a Linux gateway — a Raspberry Pi, an industrial PC, whatever you've already got on-site. It speaks the industrial protocols natively (Modbus TCP/RTU, OPC UA, BACnet, MQTT), polls your devices, and republishes every reading in one normalized format to the MQTT broker or data platform of your choice. No cloud account required to get started, and it keeps working — buffering to local storage — even when the network doesn't.

Getting it running​

Three steps, no config files to hand-edit:

  1. Install it. One line on any Linux box with systemd: 
    curl -sfL https://get.iotistica.com/agent | sudo sh
  2. Point it at a device. Open the local admin UI (http://<device-ip>:48481/admin/), add a source with an IP/address and protocol, and the agent starts polling immediately.
  3. Watch the data land. Every reading shows up in the admin UI in real time, and publishes out over MQTT in a consistent Tag/Value or ECP format — ready for whatever's listening on the other end.

That's the whole loop. No custom polling scripts, no protocol-specific client libraries to babysit, no separate normalization step before your database or dashboard can make sense of the data.

Why consolidation is the actual win​

The protocol support is table stakes — the real value is what it does to your data before it leaves the building:

  • One schema out, regardless of what's plugged in. A Modbus register and an OPC UA node end up looking identical on the wire. Downstream consumers stop caring what protocol produced a reading.
  • Bad data doesn't get silently passed along. Failed reads carry an explicit quality code instead of a null pretending to be a zero.
  • It keeps running when the network doesn't. Readings buffer locally and flush automatically on reconnect — a Wi-Fi hiccup doesn't mean a hole in your historian.
  • Less to maintain, not more. Add a device, not a subsystem. The agent's already running; a new source is a form in the admin UI, not a new integration project.

If you're currently paying an integrator every time a new device type shows up, this is the part that actually saves money.

When you outgrow one device​

Everything above works for a single gateway, no account, no strings attached — that's the Community Edition, and it's genuinely free. But data consolidation on one device is only half the problem once you've got ten sites instead of one.

That's what Agent Pro is for: fleet-wide provisioning and configuration, remote shell access without opening a single port, on-device anomaly detection so you find out about a failing sensor before it wrecks a report, and direct publishing to InfluxDB, Azure IoT Hub, AWS IoT Core, or Google Cloud instead of just a generic MQTT broker. Same agent, same install, just switched on for the whole fleet instead of one box.

See the full comparison → or try it live — a private agent instance, ready in about a minute, no signup commitment required.