Data Flow
:::info Quick Reference: Data Path Sensors/PLCs → MQTT/OPC-UA → Ingestion Workers → PostgreSQL/TimescaleDB → FastAPI → React UI
All data stays on-premises. No cloud dependency. No internet required. :::
OpSee connects the physical world (sensors, PLCs, IoT devices) to real-time dashboards and analytics. This page explains how data flows through the system, from the shop floor to your screen.
Why does this matter?
If you are new to manufacturing software, the data flow can seem complex. Here is a simple way to think about it:
Think of OpSee like a weather station. A weather station has sensors (thermometer, rain gauge, wind vane) that continuously measure conditions. Those measurements are collected, stored in a database, and displayed on a dashboard that shows you the current weather and historical trends.
OpSee works the same way, but for your factory:
- Sensors on machines measure temperature, speed, state (running/stopped), and counts
- Workers (software processes) collect and store those measurements
- Dashboards display real-time production metrics and historical analysis
The key difference is that OpSee also adds intelligence: it automatically calculates OEE, detects downtime events, lets operators classify the reasons for stops, and raises alarms when a tag value crosses its limits or stops arriving.
The big picture
Layer by layer
1. Shop floor (data sources)
| Source | Protocol | Description |
|---|---|---|
| PLCs / SCADA | MQTT, OPC-UA | Industrial controllers publish machine state, counters, and alarms |
| IoT Sensors | MQTT | Temperature, pressure, vibration sensors via IoT gateways |
| Node-RED | MQTT | Visual flow programming to transform, route, and enrich data before it reaches OpSee |
| Manual Input | HTTP (UI) | Operators log downtime reasons, quality defects, and production counts directly in OpSee |
2. Message broker (transport)
MQTT (Mosquitto) is the primary message transport. It uses a publish/subscribe model:
- Publishers: PLCs, sensors, and Node-RED flows publish data to MQTT topics
- Subscribers: OpSee's ingestion workers subscribe to relevant topics
- Topics follow a structured naming convention, e.g.,
plant/line1/machine3/state
OPC-UA is supported as an alternative for industrial environments that use it natively. OpSee's OPC-UA worker connects directly to OPC-UA servers.
3. Ingestion layer (processing)
Two parallel ingestion paths ensure data reaches the database:
| Worker | Role |
|---|---|
| MQTT Collector Worker | Subscribes to MQTT brokers, parses payloads, maps them to equipment and tags, writes to the database |
| OPC-UA Collector Worker | Subscribes to OPC-UA servers (data-change notifications), maps values to equipment and tags, writes to the database |
Workers are managed through the OpSee API. You can monitor their status, toggle debug mode, and adjust polling intervals from the admin panel.
:::info Discovery Mode The MQTT Discovery Worker automatically scans MQTT topics to find new data sources. This helps during initial setup when you're mapping sensors to equipment. :::
4. Storage (database)
PostgreSQL + TimescaleDB is the single source of truth:
- Master data (tables prefixed
m_): equipment, materials, personnel, recipes, OEE configuration - Actual data (tables prefixed
a_): production events, availability records, quality logs, audit trail - Time-series: TimescaleDB hypertables for high-frequency sensor data with automatic compression and retention
All data is stored locally. OpSee runs entirely on-premises with no cloud dependency.
5. Application layer (presentation)
| Component | Purpose |
|---|---|
| FastAPI Backend | REST API that queries the database, calculates OEE metrics, enforces access control, and serves data to clients |
| React Frontend | Single-page application with real-time dashboards, data grids, forms, and the Cockpit widget system |
| Grafana | Advanced time-series visualization and alerting for sensor data trends |
Data flow examples
Example 1: machine state change
Example 2: operator logs a downtime reason
Offline-first architecture
OpSee is designed for factory environments where internet connectivity is unreliable or nonexistent:
- All services run locally via Docker containers
- No external API calls or cloud dependencies
- Data stays on-premises
- The React frontend is fully bundled, with no CDN resources
- MQTT and OPC-UA work on the local network
This makes OpSee suitable for air-gapped environments, classified facilities, and remote manufacturing sites.
Next steps
- OEE Fundamentals: how OEE is calculated from the ingested data
- Equipment Model: how sensors and tags map to equipment
- Glossary: definitions for MQTT, OPC-UA, TimescaleDB, and other terms
Prerequisites
- Introduction: get the overall picture of OpSee
Related
- Administration → Data Tags: configure and manage sensor tags
- OEE Fundamentals: OEE is calculated from ingested availability data
- Cockpit: real-time dashboards powered by this data pipeline