Skip to content

How to control vacuums and cleaning rooms

View as Markdown

Find the robot endpoint and inspect its robotic-vacuum-cleaner and related capability declarations in the directory. 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. 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.