Przejdź do treści

Kiosk → SmartConf /v1 — locker open methods & sequences (etap-14)

The open method is identical in every kiosk flow; what differs is the orchestration per machine type. Knowing this tells you which step failed.

Method (everywhere)

  • Open cell N: SmartConfHardware.open(N) → POST /v1/doors/{N}/open, with the virtual cell number N. SmartConf maps N → (column, row) and rotates the drum.
  • Re-lock (DynaBox only): close(N) → POST /v1/doors/{N}/close.
  • State: GET /v1/status (cache) + GET /v1/events?after= (edges: Opened/Unlocked/Closed/FaultRaised). orderState=PROCESSING = drum turning.

DynaBox (single rotating drum, e.g. 28×13 = 364 virtual cells)

  • Open ONE cell at a time (_maxConcurrent = 1). Concurrent opens make the master refuse the extras (E16 / not-ready) and the session stalls — this was the bug fixed in etap-14 (replenish/inventory used max-3).
  • Don't fire the next open while orderState == 'PROCESSING' (drum settling).
  • A cell's physical hatch = its row = ((N-1) % doorsPerColumn) + 1.
  • Re-lock with close(N) after the operator closes the flap.

LockerBox (independent doors, 1 cell = 1 door)

  • Up to 3 opens in parallel (_maxConcurrent = 3). No drum, no PROCESSING gate, no close(N) re-lock. physicalDoorNumber == number.

Code

replenish_run_screen.dart, inventory_column_screen.dart (accordion: machine-type concurrency + PROCESSING gate + on-tile failure reason); locker_open_screen.dart (canonical single-cell open with DynaBox branches).

Diagnostics

Every /v1 call is logged and relayed to the panel (machine detail → Komunikacja z agentem · log API /v1, 7-day retention). During an operation the full request/response sequence is captured, so a failed open shows the agent's non-2xx body — telling E16 / not-ready / timeout apart. (MachineApiLog model, ingested on POST /machines/me/door-states as apiLog, pruned by a daily cron.)