smart-line

Context and purpose

smart-line is an IIoT prototype for bringing manual product sorting and production-line monitoring into one operator surface. Its goal is not merely to display sensor values: product flow, environmental conditions, fire events, and conveyor commands are all treated as explicit system responsibilities.

The project establishes clear boundaries between firmware, vision-based data collection, messaging infrastructure, the application API, and the dashboard. That makes it possible to develop and test the web interface, physical devices, and safety behaviour independently.

How it works

ESP32 firmware produces environmental and fire data. A separate Python vision service prepares barcode and QR results, while an ESP32-CAM provides the video stream. Device and vision messages reach the API through a TLS-protected MQTT broker.

API background services process those messages, persist records in PostgreSQL, and publish live updates to the dashboard through SignalR. Operators can observe current measurements, alerts, production activity, and conveyor state in one interface. Commands never travel directly from the browser to a device; they pass through API authorisation and safety rules first.

System design

The system has six focused parts:

• SmartLine.Firmware reads ESP32 sensors, maintains the MQTT connection, and owns local emergency-latch behaviour.
• SmartLine.Cam exposes an ESP32-CAM MJPEG stream.
• SmartLine.Vision uses OpenCV and code readers to turn physical product information into MQTT messages.
• SmartLine.API contains the Minimal API, EF Core, PostgreSQL access, MQTT consumers, and SignalR hub.
• SmartLine.Dashboard provides role-based operation, live data, and alert interaction through React.
• Infrastructure keeps service boundaries explicit through Mosquitto, certificates, Caddy, and Compose configuration.

Human identity and device identity are separate. Human users have Viewer, Operator, or Admin roles, while devices use a dedicated Device identity model for messaging.

Key technical decisions

The MQTT layer uses mutual TLS, credentials, and principal-based ACL rules instead of anonymous or plaintext connections. Being able to connect to the broker therefore does not automatically grant permission to act on every topic.

Normal stop, emergency stop, and administrator reset are distinct conveyor transitions. Firmware persists a device epoch, fire generation, and reset generation in NVS. A device with missing or corrupt state remains on the safe side, and an administrator reset does not automatically start the conveyor.

The API uses a feature-oriented Minimal API approach rather than a heavy abstraction stack. MQTT command transitions are serialised through a gate under the assumption of one active API instance, keeping safety rules out of scattered endpoint code.

Validation and limits

The API includes integration tests using real PostgreSQL Testcontainers, while the dashboard has lint and build checks, firmware has PlatformIO builds, and Vision has Python validation. Separating these layers helps catch changes to communication contracts earlier.

This is not a certified safety-critical hardware system. A servo position considered safe does not physically remove motor power; a real production line requires a hardwired emergency-stop circuit and safety relay. Command coordination also assumes one API instance, so horizontal scaling would require a distributed safety model.