Tuya eufy RoboVac Cleaning and Docking
Read and control a confirmed Tuya-based Wi-Fi eufy RoboVac through Muse Home Link using its model schema and existing local key. Excludes non-Wi-Fi and AIOT/X10 models.
eufy RoboVac — Compatible Tuya Models
Humans to Know Editorial Context
Use the pinned Muse Gadget SDK repository for runtime setup. Existing LAN-device clients run on its Linux Home Link through system.run; the Muse app, SDK token and VM connection remain required.
This is a community-sourced Muse device skill, adapted by Humans to Know; it is not an official integration. Before choosing the runtime, read repository context and task handoff. That supplement identifies the pinned SDK, Linux command boundary, setup dependencies and the evidence to retain for this device.
Use this skill when the exact Wi-Fi RoboVac model and firmware are confirmed to use the documented local Tuya interface.
Identify the Device
- Confirm the model code, local device ID, protocol and matching datapoint schema; do not use a broad generation table.
- This is not support for non-Wi-Fi models such as 11S or for X10/AIOT models.
Prerequisites
Read the Humans to Know repository context before network access. It is an editorial supplement for the upstream home_link.md reference, whose target is absent from this public snapshot.
- Existing local key, device ID and a model-appropriate command/datapoint map supplied securely.
- A compatible local eufy/TinyTuya client using HomeLink's TCP transport, as described in the Tuya skill.
- A ready robot and user permission for the intended cleaning or docking action.
Workflow
- Initialize the local client with the confirmed model/protocol, current endpoint and supplied credentials. Read state before sending commands.
- Decode cleaning mode, battery, error and docking state using the exact model's schema. Do not copy datapoint numbers from a different RoboVac.
- For the user's requested action, use the documented clean/start, pause/stop or return-to-dock operation supported by that model.
- Read new status and monitor the relevant mission transition. Keep unsupported map, room and station operations out of the command set.
Verify the Result
- Confirm a reported mission/state change; a TCP or encrypted-packet acknowledgment alone is insufficient.
- Distinguish a command to dock from successful docking, and report error/battery states without overriding them.
- Read state before retrying an uncertain movement command.
Limits
- No AIOT/X10 support, non-Wi-Fi model support, broad room/map/station promises or cloud key retrieval in the runtime path.
- No credential extraction through debugging, provisioning changes or re-pairing.
- The existing documented model match and credentials are mandatory; do not write guessed datapoints.
Sources
humanstoknow/skills · Apache-2.0 — upstream community recipe with Humans to Know editorial additions · Revision 79908eb1d698
Be the first to comment
Share what worked or leave a question for the creator.