---
title: "Combining IoT and camera analytics: MQTT and an event-driven architecture"
author: "Abdulaziz Akyol"
author_url: https://www.abdulazizakyol.com/en/about/
url: https://www.abdulazizakyol.com/en/blog/combining-iot-and-camera-analytics-mqtt-event-driven-architecture/
language: en
published: 2026-04-22
categories: ["IoT", "Artificial intelligence"]
tags: ["MQTT", "webhook", "event schema", "PLC", "MES", "sensor", "integration"]
translation: https://www.abdulazizakyol.com/blog/iot-ve-kamera-analitigini-birlestirmek-mqtt-olay-tabanli-mimari/
description: "A camera is the richest sensor. On one event bus with PLC signals, door contacts and temperature it yields new data: event schema, MQTT topics, lessons."
---

# Combining IoT and camera analytics: MQTT and an event-driven architecture

By [Abdulaziz Akyol](https://www.abdulazizakyol.com/en/about/) · 2026-04-22

## Key takeaways

- Combining IoT and camera analytics starts with turning every signal, whether from a camera, a PLC, a door contact or a temperature sensor, into one event schema and treating the camera as one of the sources.
- The event schema carries source, type, UTC timestamp, site, zone, confidence, rule identifier and payload; confidence exists so that a camera event is not weighed the same as a sensor event.
- MQTT is used inside the site because it is lightweight, gives sub-10-millisecond latency on the local network and, being publish–subscribe, lets new consumers be added without changing producers; ERP and MES systems are reached through webhooks and REST.
- The real value is in combined events: a PLC line-stop signal plus a camera seeing nobody in the operator area for 3 minutes becomes an unattended-stop event.
- The most frequent fault in this architecture is timestamp mismatch; every source must sync to NTP, every event must be stamped in UTC, and local time should appear only in display.

For a long time we built camera analytics as a separate system: its own server, its own panel, its own alert. Once we started working with manufacturing customers the separation stopped making sense. The PLC already knows the machine stopped, the camera knows whether the operator is there; without the two joining, the information "machine stopped, operator absent, 4 minutes gone" never appears. Since then we treat the camera as a sensor. The richest sensor, but a sensor.

## The common language: the event

Whatever comes from any source is turned into an event. From the camera "zone intrusion", from the door contact "door opened", from the PLC "line stopped", from the temperature sensor "threshold exceeded". One event schema:

```
{
  "source": "cam-07",            // source identifier
  "type": "zone.intrusion",      // event type, dotted hierarchy
  "ts": "2026-04-21T09:14:03Z",  // UTC timestamp
  "site": "gebze-01",
  "zone": "press-line-2",
  "confidence": 0.93,            // 1.0 for sensors
  "rule": "r-118",
  "payload": { "duration_s": 12, "object": "person" }
}
```

Every field in the schema has a reason. Without `site` and `zone` there is no filtering for a multi-site customer. `confidence` exists so that an event from a camera is not weighed the same as one from a sensor. The `rule` field shows which rule produced the event; when the rule changes, the interpretation of old events changes too, and you need to know that retrospectively.

## Transport: MQTT

Inside the site we use MQTT. Reasons: lightweight, sub-10-millisecond latency on the local network, the publish–subscribe model means adding a new consumer does not change the producer, and most industrial devices already speak it. Topic structure:

```
cx/{site}/{source}/{type}
cx/gebze-01/cam-07/zone.intrusion
cx/gebze-01/plc-line2/machine.stop
cx/gebze-01/env-03/temp.high
```

Consumers subscribe with wildcards: the shift supervisor's panel listens to `cx/gebze-01/+/zone.intrusion`, the maintenance team to `cx/gebze-01/plc-line2/#`. In MQTT, `+` stands for one whole topic level and `#` for all remaining levels at the end; there is no partial matching such as `zone.*` or `plc-+`. Keeping the full event type in a single level keeps subscriptions simple. The broker is on site, on the same machine as the server or on a separate small box. What goes to the cloud is a set of selected topics bridged from the broker; [the video still does not go](https://www.abdulazizakyol.com/en/blog/edge-or-cloud-where-to-process-video-analytics/).

The road outward, to the customer's own systems, is webhooks and REST. ERP and MES teams do not know MQTT, they know HTTP POST. The same event schema goes as JSON; for the BI team that wants CSV an hourly file is dropped as well.

## Combination rules

The real value is in events combining. A few real examples:

- **Machine stopped + operator absent.** The PLC says "line stopped", the camera sees nobody in the operator area for 3 minutes. Result: unattended-stop event, notification to maintenance and shift supervisor. With the PLC alone the reason for the stop is unknown; with the camera alone it is unknown that the machine stopped.
- **Door opened + zone intrusion.** The electrical-room door contact opened, no authorised vest seen in the zone within 30 seconds. Result: unauthorised access. The contact alone would alarm on every opening; the camera alone would not know the door opened.
- **Temperature rose + smoke.** Sensor threshold exceeded, camera sees a smoke-like pattern in the same zone. Each alone can produce a false alarm; together they are a pre-fire event.
- **[Forklift proximity](https://www.abdulazizakyol.com/en/blog/forklift-pedestrian-proximity-detection-measurable-warehouse-safety-rules/) + beacon relay.** The camera produces the event, a zone controller pulls the relay over MQTT, light and sound. The reverse direction: camera triggers, IoT acts.

Combination rules live in the rule engine with a time window: "if event B arrives within N seconds after event A, produce C". Window and sources are defined from the interface.

## Clocks

The most frequent fault we meet in this architecture is timestamp mismatch. The PLC clock 40 seconds ahead, the camera on local time, the server on UTC. The rule "B within 30 seconds after A" never fires. The rule: every source syncs to NTP, every event is stamped in UTC, conversion to local time happens only in display. We made this the first item on the commissioning checklist.

## Querying back in time

Events are stored in a time-series database. "Last month, on line 2, in the first hour after shift change, how many unattended stops" is a single query. The OEE calculation comes from the same data; I will cover that in [a separate article](https://www.abdulazizakyol.com/en/blog/measuring-oee-on-the-production-line-with-cameras/). Because no video is stored, this database stays small: a few hundred MB a day for a 60-camera plant.

## The lesson

Sold on its own, camera analytics remains "a nice panel". Connected to the same event bus as PLC, door contacts, temperature and POS, it becomes part of operations. The difference is not technical but architectural: fixing the event schema on day one, and designing the camera as one of the sources, not an exception.

## Frequently asked questions

### What is MQTT and why is it used for video analytics?

MQTT is a lightweight publish–subscribe messaging protocol. Inside a site it gives sub-10-millisecond latency on the local network, adding a new consumer does not change the producer, and most industrial devices already speak it.

### How should MQTT topics be structured for IoT events?

We use a hierarchy of the form cx/{site}/{source}/{type}, for example cx/gebze-01/cam-07/zone.intrusion or cx/gebze-01/plc-line2/machine.stop. Consumers subscribe to the topics they need with wildcards; the broker stays on site and only selected topics are bridged to the cloud.

### How are camera and sensor events combined?

Combination rules live in the rule engine with a time window: if event B arrives within N seconds after event A, produce C. For example, if the electrical-room door opens and no authorised vest is seen in the zone within 30 seconds, an unauthorised-access event is raised.

### Why does clock synchronisation matter in an event-driven architecture?

With the PLC clock 40 seconds ahead, the camera on local time and the server on UTC, a rule such as B within 30 seconds after A never fires. Every source should sync to NTP, every event should be stamped in UTC, and conversion to local time should happen only in display.

## Sources

1. [MQTT Specification (mqtt.org)](https://mqtt.org/mqtt-specification/)
2. [MQTT Version 5.0, OASIS Standard](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)
3. [RFC 5905: Network Time Protocol Version 4](https://www.rfc-editor.org/rfc/rfc5905)

---

Abdulaziz Akyol is the founder of CX Teknoloji (AI, computer vision and IoT). Canonical version: https://www.abdulazizakyol.com/en/blog/combining-iot-and-camera-analytics-mqtt-event-driven-architecture/