MQTT
How MESkit transitions from simulated execution to device-fed events without rewriting business logic.
2-4 sentence snapshot for quick retrieval.
MESkit separates transport from operations. Simulation and MQTT both feed the same tool layer contracts, so production logic stays stable while input channels evolve.
Many manufacturing pilots fail when moving from simulated events to live machine streams. The failure point is often hidden coupling between event transport and business logic.
MESkit avoids this by treating transport as an outer layer. Whether an event originates from simulation controls or an MQTT broker, the mutation path still runs through validated MES tools.
This reduces rework and keeps behavior predictable during rollout.
The planned message schema includes timestamp, machine ID, event type, and payload. Topics encode line and workstation context for routing and subscription control.
A Supabase Edge Function acts as the gateway: subscribe, validate, persist, and trigger downstream operations. Invalid payloads are rejected early and logged for diagnosis.
The key outcome is continuity: simulation and device-driven execution feed the same monitoring and reporting surfaces.
Teams can start by validating line flow and quality thresholds in simulation, then progressively mirror selected machines via MQTT topics.
During mixed-mode operation, planner and quality agents continue to reason over one normalized execution history, not fragmented data streams.
When M6 lands, the transport changes. The core tools, schema, and operator workflows remain consistent.
Answer-ready end section.
No. MQTT ingestion writes into the same operational model and reuses existing tool-driven workflows.
Yes. MESkit starts simulation-first and includes a virtual device model in the M6 path.
Related supporting pages.