Kiosk readiness & safety testing

Synthetic inputs only. These controls test workflows; they do not establish food condition or change a physical kiosk. Automatic sample feeds run every 10 simulated seconds. Safety holds affect the whole simulated kiosk.

Try warm cabinet → advance 30s for a warning → another 30s for stop-sale → acknowledge an alarm → restore normal feeds → advance 30s → release with a review reason. Acknowledgment, normal readings, robot reset and PLC reset do not release a latched stop-sale. Restart also requires continuity review. Individual maintenance positioning and an already staged recovery remain separate from starting a new pick.

Stop-sale review

Release requires fresh required sensors, temperatures at/below the test maximum, closed doors, no robot fault, no recovery maintenance or staged payload, and the configured stability period. Release is a simulator exercise, not permission to sell recovered food. Policy edits never clear an existing hold.

Alarm tracking

An alarm condition clearing is distinct from a person acknowledging it. Escalation to critical requires a fresh acknowledgment. Enter a review reason above to acknowledge an alarm.

Product scanning test panel

Compare fixed waits with callback-driven scanning using the same synthetic barcode scenarios. Runs use virtual time and finish immediately. Results are not scanner benchmarks or predicted kiosk speed.

Stocking/loading: an operator presents each product. No robot motion or inventory assignment is modeled. The supplier waits are inventory-code reference timings; use of that path by the actual loading app is unverified.

Fixed-wait model: 500 ms scan window plus configured dwell. Callback model: finish on the first valid result or timeout, with no extra dwell. Both retry failed locations after the first pass and reject inactive attempt IDs. Movement/settling time is an explicit assumption, not a motor-speed setting.

Choose a scenario and run a comparison.

No results yet.

The last 20 reports persist in the simulator database. Resetting the robot does not clear reports. Synthetic attempt IDs demonstrate correct association; the real Zebra callback does not supply an attempt ID, so a live adapter still needs serialized triggering and verified event boundaries. This panel never moves the robot or reads a real scanner.

Individual robot stages

Try Position at slot → Pick to heating platform → Transfer platform to pickup → Open pickup door → Simulate item collected → Close pickup door. Movement requires closed freezer and pickup doors and no injected fault. These are model rules, not verified PLC interlocks. Position values are row/column indices, not millimetres.

Ready for a simulated command.

Freezer door monitor

Sound is off. Enable a browser tone preview to test reminders and repeated alarms. This does not test Android speakers.

Alarm settings

The timer runs on the server even with this page closed. Sound plays only while this page is open and preview is enabled.

Door opening history

History survives restarts. Interrupted events show the last observed duration as a lower bound, with no invented closing time. Advancing test time also advances synthetic UTC timestamps.

Interrupted cook recovery exercise

Load a synthetic meal left in the oven after a disconnect. Maintenance mode blocks normal robot requests. Supply simulated TurboChef statuses, door clearance and presence evidence, then test extraction to the customer chute. Zhilai provides robot/transfer control; TurboChef owns cooking and its automatic bay doors. No oven is connected. Recovered food remains for operator review, not automatic customer delivery.

After extraction, send TurboChef cook.ack. Never acknowledge before removal: it may close the bay door. Canceled/interrupted cooks remain blocked for engineering review. Open the pickup door using robot controls before operator collection. Maintenance remains active after extraction/collection. Reset recovery exercise explicitly discards the fixture. Evidence expires after 30 real seconds and is invalidated on restart; freezer time advancement does not refresh it.

No recovery exercise loaded.

API explorer

Oven control uses TurboChef JSON-RPC over TCP 8484 in production. This console has a local HTTP fixture for appliance.info, appliance.status, cook.status, cook.cancel and cook.ack only. Load a recovery scenario and supply fresh evidence first. There is no TCP oven connection. Zhilai oven commands are inventory-only and disabled.

TurboChef v1.0 method inventory: power.on · power.off · standby.wake · group.select · cook.start · cook.cancel · cook.ack · cook.status · appliance.status · appliance.info. Power, group, wake and start methods are not modeled yet.

Loading catalog…

Manufacturer get-prefixed commands use POST JSON. The GET endpoints are sandbox additions. Catalog presence does not prove installed-kiosk support. Unimplemented routes are browse-only.

Responses will appear here.