OEE - Central Dashboard

The cloud app from the FlowFuse OEE worked example — it subscribes to every line's state, computes OEE, shows it live, and writes each reading to history. It runs on one Hosted Instance. Unlike the Edge Aggregator, this one earns a design pattern and more than one data-handling method.

Definition

• The app — subscribes to every line's state, computes OEE, shows it live, and writes each reading to history.
• Design pattern — link out / link in: the OEE result leaves the calc through one link out; a link in on the dashboard tab and a separate link in on the history tab pick it up — a clean fan-out across tabs with no cross-tab wire.
• Data handling — classify (a live event stream, plus history) → the two link-ins separate the paths (live vs history) → batch the history writes.
• Runs on — one Hosted Instance.
• Why this shape — a user-facing app driven by live data, with history kept off the live path so the dashboard never waits on the database.

The flow

Why these choices

• Link out, two link ins on separate tabs — the OEE result leaves the calc once through a link out; the dashboard tab and the history tab each pick it up through their own link in. Nothing crosses tabs, so each path reads on its own and the split is named — not a wire snaking across the canvas. (For two consumers on the same tab a plain node with two outputs would do; the link out/in earns its keep because these live on separate tabs.)
• The link-ins are the path split — the live dashboard rides one, batched history the other; neither waits on the other.
• Batch the writes — the history link in feeds a join / batch node, so readings land in the time-series DB in batches, not one insert per reading — cutting per-write overhead.
• Decouple UI from logic — the compute path builds a display-ready view-model; the widgets render it and emit intent. That's good form, not a selection — it applies to every dashboard.