# Control vacuums and cleaning rooms

Find the robot endpoint and inspect its robotic-vacuum-cleaner and related capability declarations in [the directory](/docs/for-ai/capability-interfaces.md). Supported operations vary by provider; do not infer room cleaning, scheduling or modes from a device name.

Use supported start/stop/mode schemas and full IDs. Spatial cleaning targets the robot endpoint with its supported room/zone payload; an endpoint group is not automatically a robot room. Check constraints and [dispatch semantics](/docs/for-ai/guides/using-the-api.md). Query fresh status afterward, then call `endpoint_show` on the robot so the customer sees it; accepted work is not completed cleaning. Put every requested room in one clean-room request, in cleaning order. Robot status does not list target rooms, so name the rooms you sent rather than reading them back. Ask for clarification when room mappings are ambiguous.

## Show the map or pick rooms

- [ ] To show the map or let the customer pick rooms, call `endpoint_show` on the robot with `primary: house-map`. That card has room picking. Never draw your own map or floor plan from group spatial geometry, and do not read groups one by one to build one.

## Select rooms on the website

- [ ] Select a room on the robot's map to highlight it. Select it again to deselect it, or use Clear to remove all selections. Selecting a room does not send a command.
- [ ] Select several rooms only when the robotic-vacuum-cleaner configuration advertises `supportsMultiRoomCleaning: true`; otherwise selection is limited to one room. Only groups the robot can clean are selectable.
- [ ] Use Clean selected to send one `clean-room` command to the robot with the `groupIds` of the selected rooms. Check fresh state afterward; request acceptance does not establish completed cleaning.

## Start and end remote movement

- [ ] Prefer `unary-move` for a bounded movement with working live camera feedback. Roborock owns start, native readiness, five-second startup settling, fresh readiness revalidation, ordered moves and session end.
- [ ] Keep movement duration in milliseconds and preserve its requested bound. Startup settling adds time before motion, not extra motion.
- [ ] Explicit `start-session` acknowledgement does not establish readiness. Advanced callers must verify healthy native manual mode, settle for five seconds and recheck before a `move`; a generic RUNNING state alone is insufficient. Use `unary-move` when those native checks are unavailable.
- [ ] Explicit `move` uses increasing `seqNum` values, beginning at 1 for a new session. `stop-session` stops movement; `end-session` exits manual mode. End an explicitly started session after success or failure, including cancellation, and before requesting docking.
- [ ] Send one-way remote controls with dispatch-acceptance intent (`FIRE_FORGET` in REST; omit MCP `waitForResult`). This still reports dispatch errors. Do not wait for a nonexistent reply or automatically retry an uncertain physical move.