From a cold-room probe to a work order: how we built the Factora IoT reading pipeline

Most IoT demos end at a chart. On a factory floor, a chart is the least useful outcome. A cold room drifting above 4 °C at 1 a.m. matters only if a person on shift finds out, does something, and the batch that was in the room carries the record.

That's the design brief behind Factora IoT, the industrial IoT module of FactoraERP, which we build at Tamalaki Business Network in Nairobi. This post walks through the pipeline and the trade-offs we made for plants where fibre is unreliable and nobody wants to open the factory firewall.

The six layers

Every reading takes the same path, whatever the factory makes:

1. Sensors: temperature, humidity, vibration, current, energy, level, flow, weight, door contacts and machine state.
2. Industrial gateways: a certified serial gateway polls Modbus RTU / RS485 and publishes engineering units. A site router handles Ethernet PLCs and meters (Modbus TCP) and the uplink.
3. Connectivity: dual-SIM LTE where fibre is flaky, Ethernet where a plant LAN exists.
4. Platform: checks the sensor's token, stores the reading against that factory only, and shows it to people signed into that plant.
5. Analytics: alerts, OEE, energy per unit. Each is a number the next shift can act on.
6. ERP sync: downtime, counts, energy and quality are shaped into work orders, batch records and cost in FactoraERP. Batches, products, shifts and targets flow back the other way.

The rest of this post covers the decisions inside those boxes.

Decision 1: the factory never opens an inbound port

Factory firewalls are, rightly, the most conservative thing on site. So the gateway always calls out. Nothing on the internet connects into the plant network.

That rules out "we'll SSH into the gateway" style operations and pushes you towards a strict ingest model:

• HTTPS ingest with a per-sensor token. Each sensor has its own token, stored hashed on our side. A reading posted with sensor A's token can only ever be sensor A's reading. This is the path a pilot uses today.
• MQTT over TLS is roadmap, not shipped. It's the natural protocol for gateways that publish, but we haven't exposed a broker to factory networks. That waits until an authenticated TLS ingress with a per-gateway identity has been reviewed. Until then the broker isn't published. We'd rather say "not yet" than run an unauthenticated broker on the internet.

An illustrative reading, showing the shape only (not our API contract):

{
  "point": "cold-room-b/probe-1",
  "quantity": "temperature",
  "value": 5.4,
  "unit": "°C",
  "observed_at": "2026-10-24T01:12:00+03:00"
}

The useful property: the payload never says which factory it belongs to. The token decides that. A misconfigured gateway can't write into another tenant by putting the wrong ID in a JSON field.

Decision 2: speak the plant's protocols, not ours

Brownfield plants already have meters and PLCs. Asking them to rip those out to "IoT-enable" the floor is a non-starter. So the connectors meet the equipment where it is:

• Modbus RTU / RS485 on the serial gateway. 4–20 mA signals come in through a Modbus input module, because a gateway's onboard analog input isn't always a true current loop.
• Modbus TCP for Ethernet devices behind the site router.
• OPC-UA, mapped node by node. A node id looks like ns=2;s=Line1.Crusher.Temperature.
• PLC and gateway connectors, with one rule we hold ourselves to: we don't name a controller brand until we've actually read a unit of that brand. On a pilot we ask for a photo of the nameplate and the panel, not a brochure.

The gateway publishes engineering units (°C, kW, mm/s), not raw registers. So register maps and scaling get settled at the gateway during commissioning, and the platform receives readings already in the units the shift uses.

Decision 3: store-and-forward, honestly labelled

LTE drops. When the cloud link goes, the gateway keeps the readings and syncs them later. The operator sees a buffered count and can choose Sync now or Pause sync.

Two things we're deliberately careful about:

• The buffered count is visible on screen, so the shift knows data is waiting rather than missing.
• Store-and-forward covers a dropped link. It doesn't mean a battery rides through a power cut, and we don't claim it does.

Decision 4: an alert belongs to a person

This is where most monitoring tools stop and where we spent the most design time.

When a reading leaves its band:

1. An alert goes out on WhatsApp, SMS and email once the plant's messaging accounts are connected.
2. If nobody takes it, it escalates.
3. The person on shift taps the card to acknowledge it, and their name is stored on the alert, not a role code. They can resolve it from the same card.
4. In FactoraERP, the alarm is built to open a maintenance work order for the shift, so nobody retypes it. That exchange is configured during implementation.

The named acknowledgement sounds like a small detail, but it's what auditors and buyers ask for: "who saw the excursion, and when?" It's also why shared logins defeat the purpose. A shared login throws that information away.

An illustrative batch record (sample data, not a customer):

Because stage conditions stay with the batch that was in the room, the plant can produce a PDF of that record. Spoilage, energy and downtime are shaped to land on the lot's cost in finance.

Decision 5: tenancy and the boring security that matters

• Tenant isolation: someone signed into one factory can't read another factory's devices, readings or users.
• MFA: any user can enrol an authenticator, and a factory can require it for the whole team. Plant roles are admin, maintenance and operator.
• Append-only audit log for security-sensitive changes, exportable as CSV.
• Ops allow-list: in production the fleet console refuses remote access when the IP allow-list is empty. (And 0.0.0.0/0 isn't a restriction, so don't put it there.)
• Health check returns only a status. Component detail needs a separate token.
• A content security policy and the usual hardening headers, with the app and worker built to run as a non-root user.

We also publish what we don't claim: no certifications, no uptime percentage, and no hosting region until it's agreed per contract. Engineers reading a security page can tell when it's padded.

Decision 6: demo data stays labelled

There's a simulator so prospects can see the floor before a gateway is installed. Every simulated reading stays marked as demo data until a real gateway is commissioned. It's a small rule, but it means no screenshot of fake telemetry can be mistaken for a customer result.

Where the copilot fits

The plant app includes Ask, a copilot that answers questions about the plant's own data in plain language. On the ERP side, FactoraERP's AI Factory Copilot does the same across production, stock, procurement and finance, and customer data isn't used to train shared models.

To be clear about scope: alerts in Factora IoT fire on the plant's configured bands and escalate to people. The copilot is for asking questions about the data. We don't market it as something that predicts failures.

What's next

• Authenticated MQTT over TLS with per-gateway identity, once the ingress has been reviewed.
• More dashboards per industry. Tea, dairy and grain milling are written up first.

If you work on plant-floor data, I'd like to hear how you handle buffered readings and alert acknowledgement in your own systems. And if you run a plant and want to try this on one line, pilots are open at factoraiot.com.

Isaac Muthui, Founder & CEO, Tamalaki Business Network Ltd (FactoraERP · Factora IoT)