I was using epg-pers’s Tapo RV30 integration — solid, local-only, no cloud — but I wanted more than it had, so I forked it and (built with Claude Code) added:
Native room cleaning — Home Assistant 2026.3 added a “map vacuum segments to areas” dialog to the standard vacuum more-info card plus a vacuum.clean_area action. This fork implements that contract directly: map your rooms to HA areas right in the UI, then clean them with the normal action. No YAML, no custom service calls. (The original custom tapo_rv30.clean_rooms service is still there too, for automations.)
Mop pad attached binary sensor — useful for an automation that reminds you to wash the pad after a mop clean.
Fixed resume-after-pause — in the original, hitting resume after pausing silently did nothing (the device ignores a repeated start command while it’s already mid-clean). Now it actually resumes.
Clean progress as a proper % sensor, not just a vacuum attribute with no unit — drop it straight into a Tile card.
Diacritic-insensitive room/map name matching for the custom service, and the map image now refreshes every 60s while actively cleaning instead of only every 5 minutes.
Confirmed working on my RV30 Max.
Requires HA 2026.3+ — that’s what the native area-mapping feature needs, so the whole integration’s minimum version is bumped rather than trying to support older cores too. (That is why I don’t know if I should make a PR to origin)
All credit to epg-pers for reverse-engineering the TPAP/SPAKE2+ protocol and room-cleaning payload in the first place — this fork just builds on that. Feedback and issues welcome, especially from anyone on an RV20 or a different firmware.
Read-only Schedules sensor — see your saved schedules from the Tapo app (time, days, rooms, clean settings) right in HA as an attribute. Credit to peggleg/tapo-rv30 for discovering the get_schedule_rules call (in response to the same feature request on the epg-pers repo) — I just ported it over to the TPAP transport my fork uses. Read-only for now; no way to trigger a schedule on demand has turned up in either fork yet.
Fixed the -3002 error when starting a new clean while one’s already running, fixed resume-after-pause (used to silently do nothing), a proper integration icon, a real % sensor for clean progress instead of just an attribute, and an MIT license (the original didn’t have one either).
Another round of updates to the fork(all confirmed working):
tapo_rv30.run_schedule — actually launch a saved schedule on demand now, not just view it. There’s still no device call to trigger a schedule by ID directly, so this reads the schedule’s settings via get_schedule_rules and replays them through the same calls room cleaning uses.
Cleaning-preset schedules — turns out some schedules aren’t built from a plain room list but reference a saved “cleaning preset” in the Tapo app instead (clean_mode: 5 + custom_rule_id, confirmed against real device data). run_schedule now handles that case correctly instead of silently falling back to a whole-house clean.
Multi-floor native room cleaning — the “map vacuum segments to areas” dialog now covers every saved map, not just whichever one happens to be active, so multiple floors show up as separate groups when mapping rooms to HA areas. (If you already set up area mapping before this, you’ll need to redo it once — segment IDs changed format.)
Proper integration icon — HA 2026.3 lets custom integrations ship their own local brand icon instead of needing a PR to home-assistant/brands (which stopped accepting those for custom integrations anyway), so it now shows up properly on the Integrations page instead of a generic placeholder.
A small bugfix release, this one’s for anyone who hit a crash after the v1.9.0 multi-floor room cleaning change:
Native room cleaning (vacuum.clean_area) — fixed a crash for anyone who’d already set up Map vacuum segments to areas before v1.9.0. Those mappings stored bare room IDs, but v1.9.0 switched segment IDs to <map_id>:<room_id> so multiple floors could show up as separate groups. Cleaning an area mapped the old way blew up with ValueError: not enough values to unpack (expected 2, got 1) instead of actually cleaning. It now recognizes the old bare-ID format and sends it against whichever map the vacuum is currently on, so the old mapping keeps working — though it’s still worth redoing once in the mapping dialog when you get a chance, since a bare ID is ambiguous if you have more than one saved map.
Requires HA 2026.3+ — that’s what the native area-mapping feature needs, so the whole integration’s minimum version is bumped rather than trying to support older cores too. (That is why I don’t know if I should make a PR to origin)