The robot is a Cecotec Conga M50. The box doesn't promise Google Home. The forums are blunt: this model doesn't do voice assistants, live with the app. I didn't want to live with the app.

What follows is the whole path, dead ends and all — because the dead ends are the useful part. If you've got a "not compatible" Tuya-based gadget of any kind, the last third of this is a recipe you can run.

Short version: the vacuum is a Tuya device wearing a vendor costume, the official Google path is broken in a way you can't fix from the outside, and the fix is to stop asking the vendor and build your own Google integration against a cloud you fully control. It now answers "Ok Google, start cleaning."

the four dead ends

I'll be honest about the ones that didn't work, because each one taught the next step.

Native Google Home. The robot actually showed up in the Google Home app after linking through the vendor. Tapping it flashed "in use" for ten seconds, then reverted. Nothing moved. Voice returned "the Conga M50 doesn't support that command." The device was present and dead — the worst kind of integration, because it looks like it should work.

The existing reverse-engineered clients. There are lovely community projects (badconga, ha-cecotec-conga) that speak to Cecotec's old AWS Cognito + IoT backend. I wired one up, logged in, and got UserNotFoundException. The account simply wasn't in that user pool. This model is on a newer backend. Different cloud entirely.

So I captured the traffic. mitmproxy on a laptop, the phone's Wi-Fi proxied through it, the app's CA pinning politely absent. The moment the app talked, the mystery evaporated. It wasn't calling anything named Cecotec or AWS. It was calling a1.tuyaeu.com. The vendor app is a re-skinned Tuya app; the robot is a generic Tuya "sd" (robot vacuum) device.

mitmproxy — flows from the vacuum app POST https://a1.tuyaeu.com/api.json a: smartlife.m.device.status.get clientId: 57rdy3nkqj4e7kyhphxe bundleId: es.cecotec.forceclima → not AWS. not "Cecotec". it's Tuya. the "incompatible" vacuum is a generic Tuya robot.
The one screen that changed the plan: the vendor app talks straight to Tuya's EU cloud. Payloads are AES-encrypted and signed, so you can't just replay a captured packet — but you now know exactly which ecosystem you're in.

The obvious Tuya path — also a wall. Fine, it's Tuya. Spin up a Tuya IoT Cloud project, link the account, drive it with tinytuya. Except the vendor's OEM app account can't be linked: scanning the project's QR from the Cecotec app returns "code expired" every time. That QR is meant for the public Smart Life / Tuya Smart apps, not a white-label one. The robot was locked inside the vendor's app.

the move that unlocked everything

Here's the trick, and it's almost dumb: re-pair the robot into the plain Smart Life app.

Congas are usually assumed to be locked to the vendor app. This one wasn't — reset its Wi-Fi, add it in Smart Life in AP mode, and it paired. The instant it lived in a first-party Tuya app, the QR account-link worked, and the device showed up in a Tuya IoT Cloud project. From a plain Python script on a server, I could now read and command it.

The real command codes turned out to be simple once I could query the device. This is the reusable nugget — if you have a Tuya Conga (or a cousin), these are the DPs:

start cleaning : {"code": "pause",         "value": false}
                 then
                 {"code": "power_go",      "value": true}   # status → "smart"

return to base : {"code": "switch_charge", "value": true}   # status → "goto_charge"

pause          : {"code": "pause",         "value": true}

That pause=false before power_go=true matters. The device docks with pause stuck true, so "start" alone makes it twitch and pause — which, it turns out, is exactly why the native Google integration looked broken. Google was flipping one bit and never clearing the other.

why "just fix Google Home" doesn't work

Now the robot was in Smart Life, and Smart Life links to Google Home natively. So the tile should work, right?

No. Tapping it in Google Home still sent nothing the device understood — I watched the Tuya cloud state the whole time and it never changed. The mapping from Google's vacuum commands to this device's DPs is wrong, and it lives on Tuya's side of the fence. You cannot fix it from outside. That's the honest ceiling of the "official" route.

So I stopped trying to fix someone else's integration and wrote my own.

a Google Smart Home Action you actually control

Google lets anyone publish a cloud-to-cloud Smart Home Action: you host the "brain," Google calls it. When you say "Ok Google, start cleaning," Google hits your endpoint, and your endpoint does whatever it wants — in this case, fire the Tuya command that genuinely moves the robot.

It's three small pieces on a server you own, behind HTTPS:

  1. A tiny OAuth 2.0 endpoint for account linking (single user, so it's ~40 lines — issue a code, exchange it for a token).
  2. A fulfillment endpoint that answers Google's three intents: SYNC (here's a vacuum with StartStop + Dock), QUERY (its state, read live from Tuya), EXECUTE (run the DP commands above).
  3. The device registered in the Google Home Developer Console pointing at those URLs.

Because I define the SYNC device and the EXECUTE handler, the "twitch and pause" bug can't happen — my handler sends pause=false then power_go=true, the sequence that actually works. Google talks to my server; my server talks to Tuya's cloud; Tuya talks to the robot.

Nest speaker "Ok Google, start cleaning" Google Home cloud your server OAuth + /smarthome SYNC · QUERY · EXECUTE tinytuya → power_go Tuya Cloud a1.tuyaeu.com Conga M50 Google never touches the robot. Your server owns the mapping — so the command that works is the one that runs.
The final path. The vendor's broken Google mapping is out of the loop entirely; your fulfillment endpoint sends the DP sequence that actually moves the robot.

the recipe, if you want to reuse it

For a "Google-incompatible" Tuya device of almost any kind:

  1. Confirm it's Tuya. Proxy the vendor app through mitmproxy for a minute. If you see *.tuyaeu.com / *.tuyaus.com, you're in.
  2. Get it into Smart Life. Reset the device's Wi-Fi and add it in the plain Smart Life app (try AP mode if EZ fails). This is the step everyone assumes is impossible and often isn't.
  3. Link Smart Life to a Tuya IoT Cloud project (match the data center — EU accounts on "Central Europe"), then drive it with tinytuya. Query the device to learn its real DP codes.
  4. If the native Google/Alexa control is broken, build your own Action. A cloud-to-cloud Smart Home Action is a small OAuth stub plus a SYNC/QUERY/EXECUTE handler. You own the mapping, so you own the behavior.

Total moving parts on the server: a Python fulfillment behind nginx with a Let's Encrypt cert, kept alive by a one-line cron watchdog. No new hardware, no hub, nothing running in the house — the robot is reachable through Tuya's cloud from anywhere.

what I'd tell you before you start

The captured Tuya payloads are AES-encrypted and HMAC-signed with a timestamp, so replaying a sniffed request doesn't work — you drive the device through Tuya's own cloud API, not by forging its app traffic. The re-pair into Smart Life can drop the vendor app's saved maps, so weigh that if you love your no-go zones. And the OEM-app QR link genuinely can't be made to work; the Smart Life detour is the way around it, not a workaround you can skip.

None of the pieces here are new. mitmproxy, tinytuya, and Google's Smart Home Actions have all been around for years. What was missing was someone saying out loud that "not compatible" usually means "the vendor didn't bother," and that the parts to fix it yourself are sitting right there. The robot vacuums when I ask it to now. That's the whole point.