azure-iot

## Instructions This is the **read interface** to `azure-iot-mcp-server`. This is **where every Line-N investigation starts** — OEE tells you which line is missing target; downtime events tell you which device and why; telemetry tells you the underlying signal. ### Tool routing | User intent | Tool | |---|---| | List the equipment on the floor (filter by plant, line, status) | `iot_list_devices` | | One device with full detail (vendor/model/firmware, alarm thresholds, status_note) | `iot_get_device` | | Pull time-series readings for a device (vibration, temp, load, RPM, etc.) with pre-annotated `alarms` array | `iot_get_telemetry` | | List downtime events with cause codes (`VIB_ALARM`, `MATERIAL_HOLD_QA`, `CAL_DRIFT`, `PLANNED_MAINT`), lot ids, and `related_po_id` for cross-MCP joins | `iot_list_downtime_events` | | Per-line per-day OEE with `vs_target_pct` and `flag` (`on_target` / `watch` / `investigate`) | `iot_get_oee` | ### Investigation workflow — the canonical pattern The IoT story is **OEE → downtime → telemetry → device twin**. Walk that order; don't query everything up-front. 1. **`iot_get_oee(plant_id="P-CLE")`** → which line is `investigate`? Look at the 7-day trend, not just today. 2. **`iot_list_downtime_events(plant_id="P-CLE", line="<that line>", since="<yesterday>")`** → what stopped it? Read the `cause_code`, `lot_id`, `related_po_id`. 3. **`iot_get_device("<the device named in the events>")`** → is the device twin in `Warning` / `Degraded`? Read the `status_note`. 4. **`iot_get_telemetry("<device>", since="<window>")`** → confirm the signal. The `alarms` array on each reading already lists the breaches — **don't re-derive thresholds in your head**. 5. **Hand off** — if a downtime event has a `related_po_id` or a Northbridge-style lot id, pivot to **sap-s4**; if you need to log a maintenance ticket, pivot to **servicenow**. ### Conventions - **The `alarms` array is the source of truth on threshold breaches.** Quote it: *"vibration crossed 4.5 mm/s at 22:00 — reading was 4.7"*. Don't compute it. - **Plant ids match sap-s4 verbatim.** `P-CLE` here = `P-CLE` there. Lines too (`Line 3 — Precision` is the same string). - **Device ids `DEV-*` map to servicenow CMDB `CI-DEV-*`** by numeric suffix. DEV-3001 → CI-DEV-3001. The servicenow CI's `owner_group` is `Plant Maintenance` — that's the assignment group for the work order. - **OEE flag wording is fixed** (`on_target` / `watch` / `investigate`) — use those words; don't invent synonyms. - **Time windows.** All timestamps are ISO-8601 with offset (Cleveland `-04:00`, Munich `+02:00`). When Frank says "last shift" assume the prior 8 h ending at the current time. ### Output Prefer compact tables — one row per device, one row per downtime event, one row per day for OEE. Lead each row with the id, the metric, and the flag. ### When NOT to use - Production orders / materials / vendors → **sap-s4** - Logging a maintenance ticket against the device → **servicenow** (maintenance work order section) - Charting the OEE trend / computing aggregates → **oee-analysis** (don't ask `code_interpreter` to retype numbers — pipe them through that skill)