Why I'm Touching Industrial IoT in 2022

TL;DR — Industrial IoT (IIoT) = factory floor sensors → cloud via MQTT brokers and time-series DBs. Different from web backends in three ways: unreliable connectivity, real-time alerting matters, legacy protocols (OPC UA, Modbus). The patterns translate to event-driven systems on the back end.

After seven months on web-backend topics, August pivots hard: industrial IoT. The trigger: we’re advising on a factory monitoring project that needs MQTT brokers, sensor ingestion, and real-time dashboards. I’m relearning patterns I last touched five years ago. This month documents what I’ve found.

If you’re a web-backend developer who’s never touched IIoT, this is intended to make the domain navigable. Same vocabulary will keep showing up; same architectural patterns repeat.

What IIoT actually is

Industrial Internet of Things. Two flavors:

Field / edge: sensors on machines (vibration, temperature, pressure, voltage), edge gateways, local control. Latency-sensitive. Often runs over private networks.

Cloud / platform: ingestion endpoint (MQTT broker), time-series database, analytics, dashboards, alerting. Looks like a web backend, with different constraints.

The link between them: an MQTT broker receiving sensor data, application code consuming and processing.

In 2022 the standard stack is:

• Edge: device or gateway publishing to MQTT (Mosquitto, EMQX) or directly to platform
• Protocol bridge: OPC UA (factory PLCs) → MQTT, or vendor-specific
• Time-series DB: TimescaleDB, InfluxDB, ClickHouse
• Dashboard: Grafana
• Alerting: Alertmanager, custom rules engine

This stack is what August covers.

How it differs from web backends

Three real differences from the web-backend mental model:

1. Connectivity isn’t reliable. Edge devices come and go (factory shift changes, network outages, devices powered off). Your ingestion code can’t assume “the device will send the message; if not, log an error and move on.” Missing messages might be normal.

2. Time-series is the dominant data shape. Everything is a value with a timestamp. Querying is “show me the temperature of machine 17 in the last 4 hours.” Different DB choices, different query patterns than CRUD-style.

3. Real-time alerting is load-bearing. A pressure spike on a press has to alert within seconds. The whole architecture is biased toward latency, not throughput.

4. Legacy protocols matter. OPC UA (industrial standard), Modbus (older), HART, Profibus, EtherCAT — these are the protocols PLCs and motor controllers actually speak. You bridge to MQTT; you don’t replace them.

What August covers

Twelve more posts:

• Aug 3: MQTT 101 — the protocol itself
• Aug 5: MQTT broker comparison — Mosquitto vs EMQX vs HiveMQ
• Aug 8: Self-hosting Mosquitto — TLS, ACL, real setup
• Aug 10: Sensor data schemas — JSON, Protobuf, CBOR
• Aug 12: Reading sensors with Go — edge code
• Aug 15: MQTT to TimescaleDB ingest — the cloud side
• Aug 17: Sparkplug B for industrial OT — MQTT for factories
• Aug 19: OPC UA to MQTT bridge — talking to PLCs
• Aug 22: Real-time Grafana dashboards
• Aug 24: Alerting on sensor anomalies
• Aug 26: Securing MQTT
• Aug 29: Month retro

What I’m NOT covering

• Specific PLC programming (ladder logic, structured text)
• Hardware design / driver writing
• AWS IoT Core / Azure IoT Hub / GCP IoT Core specifically (the patterns translate; vendor-specific details are out of scope)
• Field-bus protocols beyond OPC UA / Modbus
• Specific cellular / LoRaWAN / NB-IoT — different domain (consumer IoT > IIoT)

The honest framing

I’m not an OT engineer. I’m a web-backend developer adjacent to one IIoT project. This month is “what a competent web developer needs to know to be useful in IIoT,” not “the comprehensive OT manual.” If you’re a controls engineer, most of August will be remedial.

The patterns translate to back-end event-driven systems too. MQTT looks a lot like Kafka with different trade-offs. Time-series ingest at scale resembles tracing pipelines. There’s value here even if you never touch a factory.

What’s at stake

The factory project we’re consulting on has ~120 sensors on ~30 machines. Daily volume: ~2M messages, ~30 GB time-series data. Critical path: pressure / temperature alerts within 5 seconds of breaching threshold.

That’s a small IIoT deployment. A car factory has 100K+ sensors. An oil refinery has hundreds of thousands. The patterns scale up; the principles stay the same.

Common Pitfalls (preview of the month)

• Treating IIoT like web traffic. Different SLAs, different reliability profile, different protocols.
• Skipping the broker authentication setup. “It’s internal” → factory network has more devices than you think.
• Using REST instead of MQTT for edge. Heavier, no pub-sub semantics, connection overhead.
• Time-series in a relational DB without proper extensions. Postgres with TimescaleDB works; vanilla Postgres struggles past 100M rows.

Wrapping Up

IIoT is a domain pivot. The patterns are 80% similar to web backends, 20% genuinely different. August walks the differences. Wednesday: MQTT 101 — the protocol everything else builds on.