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.
Another round of updates to the fork(all confirmed working):
What is new?
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.
- number.refresh_interval — status poll cadence, now adjustable at runtime instead of a fixed 30s
- switch.child_lock — read/write
- select.area_unit — m²/ft², read/write
- sensor.carpet_clean_preference — read-only for now (no confirmed full option set beyond “boost”)
- binary_sensor.do_not_disturb — with start/end time attributes
Also: getMapData’s furniture_list turned out to be readable locally after all (earlier docs said furniture was cloud-only) — the map camera entity now exposes it as room_geometry.furniture, in the same pixel space as room_geometry.rooms. The companion VacuumCard-ADV card’s editor can now click a detected outline to place a furniture item there instead of dragging it into position by hand.
Don’t know what happened, but today the official TP-Link integration discovered the RV30 Max, and it works (still no map or room cleaning there, though).
Strange things are now going on with Tapo and Home Assistant; something starts working, and other things stop…
EDIT: It was caused by my new custom integration changing the pyhton-kasa liblary to a fork that supports TPAP.
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)
!
, v2.1.0, v2.1.1, and v2.1.2 destroyed you all (not you, but the bugs)!