Guidewheel data model & endpoint map
Where the data comes from
Guidewheel's core sensor is a non-invasive clip-on current transducer (CT clamp) around a machine's power line — no PLC integration, no network port on the machine. From that single current signal the platform derives:
- Load states — online (running), idle, offline (down), planned downtime, nodata
- Cycles and cycle time
- Energy — per-second active power; other metrics per-minute
On top of the sensed signal sit operator- and platform-generated records: downtime issues with tagged reasons, production entries, scrap events, shifts, and tags (standardized reason codes). A secondary photo-eye sensor covers throughput counting where the current signal can't infer it.
Knowing this genealogy matters when interpreting the data: everything state-like is inferred from power draw (robust, but blind to machine internals like alarm codes or process parameters), while issues/production/scrap are human- or rule-entered records with the usual bookkeeping caveats.
Entities
| Entity | What it is |
|---|---|
| Device | A sensored machine, line, or cell |
| Device list | Curated machine group for role-based visibility (e.g. one plant's machines) |
| Issue | An alerting event — usually a downtime event or anomaly; carries comments and tags |
| Production entry | A production run with start/end and produced quantities |
| SKU | A product, typically synced from an ERP (ERP as source of truth) |
| Tag | Standardized categorization — most often a downtime reason code |
| Shift | Shift with start/end, status, duration |
| Scrap | A recorded scrap event |
| Plant | A site; exposes its current shift |
Endpoints and verbs (/api/v1)
| Path | GET | POST | PATCH/PUT | DELETE |
|---|---|---|---|---|
/devices (list, specs) | ✓ | ✓ | – | – |
/devices minute telemetry | ✓ | – | – | – |
/devices uptime (group_by=day) | ✓ | – | – | – |
/devices state | ✓ | – | – | – |
/devices energy (group_by=day) | ✓ | – | – | – |
/devices threshold changes | ✓ | – | – | – |
/issues | ✓ | ✓ | ✓ | ✓ |
/production-entries (+ bulk CSV) | ✓ | ✓ | ✓ (PUT) | – |
/skus | ✓ | ✓ | – | – |
/tags | ✓ | ✓ | – | – |
/device-lists | ✓ | – | – | – |
/plants (current shift) | ✓ | – | – | – |
/shifts | ✓ | – | – | – |
/scraps | ✓ | ✓ | – | – |
Issues are the only fully read-write entity — deliberately, since they're the synchronization point with external maintenance systems.
Gaps to plan around
- No webhooks or streaming. Everything is polled. Agent flows that react to downtime need a polling loop (mind the 1000 calls/day budget) or an external trigger.
- No computed-OEE endpoint. Compute OEE yourself from uptime + production entries + scrap.
- No alert-rule or anomaly-output API. Guidewheel's alert configuration and AI anomaly detection are platform-UI features; their outputs surface only as issues.
- Schemas are tenant-flavored. The response field names can vary with tenant configuration, and the field-level API guide is distributed by Guidewheel on request. Daslab's tools accept passthrough
query/fieldsobjects, andguidewheel_api_getlets an agent probe any path and learn the live schema empirically.