While reverse-engineering a few more undocumented TPAP methods(for my TapoVac-ADV integration) against a real RV30, I ran several rounds of exploratory calls — deliberately malformed/unknown-method requests sent in quick bursts, to tell PARAMS_ERROR (method name valid, wrong arguments) apart from UNKNOWN_METHOD_ERROR (name doesn’t exist). This happened while Home Assistant’s own integration was also actively polling the same device, with its refresh interval set fairly aggressive.
Partway through, one request came back with an undocumented INTERNAL_UNKNOWN_ERROR(-100000). Shortly after: the vacuum’s saved maps, its full cleaning history, and its consumable-usage counters (brush/filter, reset to “100% remaining” — as if new) were all gone. The TP-Link cloud map backup was empty too.
Best guess, not confirmed by TP-Link, no public docs exist for this error code: the TPAP session protocol (SPAKE2+ handshake plus an incrementing sequence counter) isn’t designed for two independent authenticated sessions hitting the device at once. Home Assistant’s poll loop and my manual script were doing exactly that, concurrently, on top of a burst of malformed requests — plausibly enough to crash the firmware badly enough that it wiped its own local config as a protective measure.
No cloud backup was available to recover from. Lesson for anyone else probing this protocol: don’t run manual TPAP scripts against a device while an integration or app with its own active session is also polling it, and don’t send bursts of unknown/malformed requests back to back, space them out. If you hit -100000 or any code you don’t recognize, stop immediately rather than continuing to probe.