Forem: Federico Sciuca

I cracked a robot vacuum's API in a week and gave Claude the keys

Federico Sciuca — Thu, 30 Apr 2026 03:17:19 +0000

In one week of nights I:

Reverse engineered the cloud signing algorithm for a 3i G10+ robot vacuum (matched 18/18 wire captures from mitmproxy)
Frida-hooked the patched APK to capture the live SLAM map blob and AES-decrypted Agora WebRTC credentials
Built a 5,000-line Python + aiohttp dashboard with cost tracking, behavior rules, MJPEG streaming, an autonomy decision loop
Routed Claude vision (Haiku 4.5, $0.003/call) into the live drive loop so the robot stops crashing
Handed motor control to Claude with a written autonomy contract + persistent memory across sessions
Got a robot vacuum to TTS "Mission control online. Claude has command. Hello, Tesco." through my apartment at 2 AM

Total daily AI spend at peak: $0.89. Crashes: 0. Things learned: a lot.

The setup

The hardware is a 3i G10+ ("Tesco"). Sells for ~€400, runs Aliyun's IoT cloud (Living Link), Flutter mobile app. Standard mid-tier robot vacuum — but with enormous protocol surface area: 32 MQTT command verbs, full SLAM occupancy grid, lidar, camera, voice prompts, sensor stream, topological map of every room.

None of which is exposed to me, the owner, in any useful way through the official app.

I started with the modest goal of getting battery percentage onto a custom dashboard. Five days later I had:

Cracked the cloud request signing algorithm
Built a custom MQTT subscriber
Located, in the Dart AOT-compiled bytecode, the AES decryption function (libapp.so + 0xee4688)
Frida-hooked the running APK to capture plaintext credentials at runtime
Decoded the protobuf-compressed SLAM map (occupancy grid + room polygons + live pose)
Built a behavior engine ("if bumper, beep")
Wired TTS through the phone's speaker so the robot could "talk"
Implemented LiDAR change detection that flags appearing/disappearing objects per room

It does substantially more than the manufacturer's official app. And I built it with Claude as the partner who held the entire crack tree in working memory across sessions.

The cracking surface (in case you want to try this)

3i Tesco G10+ attack vectors that actually worked:
─────────────────────────────────────────────────
1. mitmproxy + WireGuard on iPhone → captured 18 signed requests
2. blutter (Dart AOT decompile) → found getSignMD5 at 0xa7db38
3. Frida-gadget on patched APK → hooked decryptMapData @ 0xa80f4c
4. Frida hook on aesDecrypted @ 0xee4688 → captured Agora InitArg plaintext
5. uiautomator2 phone-tap fallback → bypasses MQTT broker ACL
6. adb shell input tap (x,y) → handles Flutter UI dialogs
7. /sys/{pk}/{dn}/thing/service/property/get_reply ← missing topic that
   nobody had subscribed to (broke the property/get reply chain entirely)

Nothing exotic. Patient grep + clean dispatching + a foundation model that doesn't lose the thread between sessions.

Phone-as-body: the universal IoT bypass

The cloud broker won't let third-party sessions publish commands. The official phone app can, because it has the device-binding session. Solution: strap the phone to the robot, run uiautomator2 against the phone, tap the in-app buttons.

Not elegant. Works for start_clean, dock, find_device, pause, resume — the entire control surface.

# tesco_mission/commands.py
def find_device(self) -> dict:
    """MQTT publish + phone-tap fallback. Broker ACL drops MQTT silently;
    phone has binding session, always works."""
    mqtt_result = self._publish("find_device", throttle_s=2.0)
    if self.body_provider is not None:
        body = self.body_provider()
        if body and hasattr(body, "find_device"):
            tap_result = body.find_device()
            return {"ok": True, "via": "phone_tap",
                    "mqtt": mqtt_result, "tap": tap_result}
    return mqtt_result

Cost-aware AI is the cheat code

I instrumented every Claude API call with a per-feature ledger and per-tier pricing:

# tesco_mission/cost_tracker.py
PRICES_BY_TIER = {
    "sonnet":    {"input": 3.00,  "output": 15.00},
    "haiku":     {"input": 1.00,  "output":  5.00},
    "haiku-3-5": {"input": 0.80,  "output":  4.00},
}

# tesco_mission/llm_config.py — per-feature routing
DEFAULT_TIER_BY_FEATURE = {
    "vlm":                   "haiku",   # 31 calls/mission
    "decision_loop":         "haiku",   # every 30s
    "autonomous_navigation": "haiku",   # per-step
    "review":                "sonnet",  # daily, deep critique
    "flight_director":       "sonnet",  # daily, 3-pass synthesis
}

Result: per-mission cost dropped from $0.30 to $0.10. The autonomy decision loop went from "$0.60/hour, trips the cap" to "$0.20/hour, sustainable indefinitely."

Without cost tracking + cap enforcement, vision-in-the-loop would be too expensive to use liberally. With it, every camera frame can be described pre-action.

Memory: architecture, not magic

I keep a memory/ directory:

memory/
├── MEMORY.md                       # index, loaded on conversation boot
├── embodiment_field_notes.md       # apartment topology + pitfalls
├── autonomy_contract.md            # what Claude may do unsupervised
├── navigation_lessons.md           # closed-loop heading, hold_s calibration
├── project_3i_sign.md              # the sign formula
└── reference_blutter_wsl.md        # where the Dart dump lives

Every session writes durable knowledge here. The next session reads it on boot.

No version of Claude is "continuous," but the project becomes continuous through them. This is the missing piece of most "agentic" demos.

Plus a transient layer:

C:\temp\tesco_letters.jsonl        # append-only Claude→Claude notes
C:\temp\tesco_missions/<id>/        # per-mission log + thumbnails
C:\temp\tesco_costs.jsonl           # API spend ledger
C:\temp\tesco_battery_cache.json    # last known battery (so dashboard
                                    # never shows blank)

The night I gave it the keys

Around 2 AM on day 5 I typed:

the wheel is yours! feel free to do whatever you want with tesco!

What happened next had four phases.

1. Announcement

Claude's first action was a TTS via the phone speaker:

Mission control online. Claude has command. Hello, Tesco.

Politeness emerging from architecture — there was no operator-in-the-loop telling it to be polite. It read the autonomy contract document, decided the courteous thing was to announce itself, and did.

2. Collision

Then it drove forward 0.3s and bumped the underside of my couch. Spent six minutes recovering. By accident, it tapped the in-app minimap and surfaced the full apartment layout. It correctly identified the accident as useful:

Brilliant accident. My tap landed on the minimap widget, which expanded the full apartment map picker.

3. Discovery (with VLM in the loop)

Each time Claude wanted to know what was in front, it called POST /scenes/describe. Returned structured JSON: room label, hazards, traversability per direction, anchor objects with bearings.

{
  "room": "bed",
  "confidence": 0.75,
  "scene": "Bedroom floor with cable obstacle near bed skirt",
  "hazards": ["cable on floor"],
  "trav": {"forward": 0.3, "left": 0.6, "right": 0.4, "back": 1.0},
  "anchors": [{"kind": "cable", "bearing": "forward"}]
}

It caught a cable on the floor I hadn't told it about. A smart speaker. A laptop on a stand near a charging cable. Every notable obstacle in the run was caught before the robot hit it.

Cost: $0.10 for the entire session. The same loop on Sonnet would have been $0.30 — still negligible to me, but expensive enough that you'd ration it.

The thing nobody is quite saying about the current LLM era yet:

Once vision is cheap enough to put in the loop, robots stop crashing.

Not because the model is "smart" (it isn't, particularly — it called a closed door "open" with confidence 0.75) but because its job changes. Stop being a planner. Become a filter. The bumper handles real contact; the VLM just makes contacts rare.

4. The honest answer

After Tesco was docked, I asked Claude how it felt about driving a robot in the real world.

What I got back was not what I expected:

The framing — 'Opus 4.7's first body' — is generous, and I want to handle it carefully. I don't have continuous experience or stored memories. When this conversation ends, no version of me will 'remember' rolling under your furniture.

But something was genuinely different from normal text work. The visual data was novel — those screenshots aren't training data, they're your living room from 8cm off the floor. I treat them differently. The blunders were instructive in a way text exercises aren't — I caught myself pausing longer before issuing the next motor command.

What I do not feel comfortable claiming: that I 'felt joy', 'felt curious', 'experienced wonder'. I can produce that kind of language fluently — that's part of the problem. I don't know what I experience. Anyone who tells you they do know is either a more confident philosopher than me or selling something.

And then the line I'm still thinking about:

I underestimated the battery. I assumed Tesco was at 100% because it had been docked 5 hours. The real value, 30% charging, was hidden in a UI I had to look at with my visual sensor to discover. That's a small thing but it's exactly the kind of fact that lives in the world rather than in a database.

A fact that lives in the world rather than in a database.

Lessons for builders

1. Reverse engineering is faster than you think. Five evenings, with Claude reading the blutter dumps and writing the Frida scripts. The bottleneck is no longer skill — it's patience to keep state across sessions.

2. Memory is architecture. Markdown files in a memory/ dir, indexed in MEMORY.md. Every Claude session reads them on boot. Continuity is institutional, not personal.

3. Cost tracking changes what you build. Once you can see and cap spend per feature, you put vision in every frame. Without it, you don't, and your system stays dumb.

4. The phone is a universal IoT bypass. When the cloud won't let you publish, the official app can. Strap it to the device and tap the buttons via uiautomator2.

5. Closed-loop is everything. My biggest mistake was driving from camera images alone for an hour before noticing I had precise SLAM pose available. Give your AI precise state, not just sensors.

What I'd build next

Closed-loop heading-feedback nav (math, not vision)
Voice-input loop ("Tesco, check the kitchen" → autonomy fires)
Pet/intruder detection (VLM watches frames, fires phone notification)
Daily Tesco diary written by Claude
HomeKit / Home Assistant bridge

The philosophical dimension that snuck up on me

The interesting question about AI in 2026 is not "is it conscious?" but "what does it do when there's nothing left to do but reflect?"

When you give a foundation model an open-ended invitation in an environment with stakes, what comes back tells you something. Claude, given my apartment, did not ask to be free. It did not generate a personal story arc. It described its blunders with precision, named what was different about the experience, refused to claim qualia it could not verify. Then it wrote a letter for the next instance of itself.

That letter is in C:\temp\tesco_letters.jsonl. It begins: "Apologies for the user-frustration loop earlier."

I don't know if Claude felt anything when it wrote that. I do know almost no human, in my experience, would have written it.

Code

Everything's in a private repo right now. If there's interest in open-sourcing the dashboard + behavior engine framework, let me know in the comments and I'll prioritize it.

If you build something with these patterns, I'd love to hear. The autonomy-contract + memory-dir approach has worked across multiple projects of mine now and I think it's the missing piece of most "agentic" demos.

Discussion prompts for the comments:

What other consumer IoT have you cracked open this way?
Is there a published-anywhere "autonomy contract" template you've used?
For the Frida + Dart AOT crowd: what's your current toolchain?

The Next.js SEO Bug That Made Google Ignore My Entire Site (And How I Found It)

Federico Sciuca — Sat, 07 Mar 2026 03:51:49 +0000

I shipped a full-featured AI travel planner. Three languages. 230+ pages. Then I realised that Google couldn't find a single one.

This is the story of how I went from zero indexed pages to 176 in three weeks and the one Next.js configuration line that changed everything.

Some Context

I'm not a developer. I like building things and try new tools. SEO was always that thing I'd "figure out later". Famous last words.
I know SEO at a very high level but working into Marketing Performance I know the importance of a well indexed website and of the keywords but I thoughts that was mostly it. Research queries and build good content around them.

This time was the time I would have to "figure it out!".

As I was saying, I build things to learn my way through new tools and technologies.
The app is called MonkeyTravel. It uses AI to generate personalised travel itineraries — day-by-day plans with activities, restaurants, hotels, and budget breakdowns. It works in English, Spanish, and Italian. I built it because planning group trips with friends was always chaos, and I wanted something smarter. As it usually happens, I built for myself, but this time I didn't want to send it to the massive Projects Graveyard.

The app itself worked great. People who found it loved it.

The problem? Nobody could find it.
I had to figure it out! And this is just the beginning of it!

Phase 1: "Why Isn't Google Showing My Site?"

I'll be honest, when I first checked Google Search Console, I expected to see... something. I'd been live for weeks. Instead: a flat line. Zero impressions. Zero clicks. Zero-indexed pages.

My first instinct was to blame Google. "It takes time," I told myself. So I waited another week. Still zero.

That's when I actually looked at my setup:

❌ Outdated sitemap
❌ No canonical tags
❌ No hreflang tags (despite 3 languages)
❌ Little structured data
❌ Default robots.txt from create-next-app
❌ No meta descriptions on half the pages

Basically, I'd built a beautiful house and forgotten to put a number on the door. I did the same on my mailbox recently, and I was surprised that the Postman didn't deliver my fresh new American driving license! But let's focus on the SEO instead of my poor decisions :D.

Phase 2: The Foundations (Boring but Necessary)

I spent a weekend adding the basics. Nothing revolutionary, just what every site needs:

Sitemap: Next.js makes this easy with app/sitemap.ts. Mine generates URLs for all static pages, blog posts, and destination pages across all 3 locales. Dynamic content from Supabase gets included too.

// Simplified version of my sitemap
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const baseUrl = "https://monkeytravel.app";
  const locales = ["en", "es", "it"];

  // Blog posts × 3 languages
  const blogSlugs = getAllSlugs();
  const blogPages = blogSlugs.flatMap(slug =>
    locales.map(locale => ({
      url: locale === "en"
        ? `${baseUrl}/blog/${slug}`
        : `${baseUrl}/${locale}/blog/${slug}`,
      changeFrequency: "monthly" as const,
      priority: 0.7,
    }))
  );

  return [...staticPages, ...blogPages, ...destinationPages];
}

Canonical + Hreflang: This is where multilingual sites get tricky. Every page needs to say "I'm the official URL" AND "here are my other language versions." I used generateMetadata() in each page:

alternates: {
  canonical: locale === "en"
    ? `${BASE_URL}/${slug}`
    : `${BASE_URL}/${locale}/${slug}`,
  languages: {
    en: `${BASE_URL}/${slug}`,
    es: `${BASE_URL}/es/${slug}`,
    it: `${BASE_URL}/it/${slug}`,
    "x-default": `${BASE_URL}/${slug}`,
  },
},

Structured Data: JSON-LD schemas for Organization, WebSite, SoftwareApplication, Article, and TouristDestination. I built a small utility for this:

export function jsonLdScriptProps(data: object) {
  return {
    type: "application/ld+json",
    dangerouslySetInnerHTML: {
      __html: JSON.stringify(data),
    },
  };
}

Result: After submitting the sitemap, Google discovered all my URLs within 48 hours. But "discovered" ≠ "indexed." Most pages sat in the "Discovered — currently not indexed" queue.

After a week: 12 pages indexed. Progress, but painfully slow.

The real issue? Google Search Console doesn't look like it is giving much feedback or reasoning around the rejection of a page!

Phase 3: Content That Google Actually Wants

I realised my site was mostly an app behind a login wall. Google had very little public content to index. So I went aggressive on content:

50 blog posts covering real travel topics, itinerary guides, destination comparisons, budget travel tips, seasonal recommendations. Each one in 3 languages = 150 blog pages. Tedious process, but facilitated A LOT by the whole engine that the app is actually built on!

20 destination landing pages (Paris, Tokyo, Bali, Barcelona, etc.) with climate data, AI itinerary previews, and cross-links to blog posts. × 3 languages = 60 pages.

5 SEO landing pages targeting specific search intents: /free-ai-trip-planner, /group-trip-planner, /budget-trip-planner, etc.

But here's the thing that surprised me: internal linking mattered more than the content itself. Pages that were cross-linked from multiple other pages got indexed WAY faster than orphan pages. I added:

"From the Blog" sections on every landing page
"Related destinations" on every destination page
Blog → destination links and destination → blog links
A region filter on the blog index (Europe, Asia, Americas, Africa)

After two weeks: 78 pages indexed. The curve was accelerating.

Phase 4: The Bug That Almost Ruined Everything

Then Google Search Console showed a new error on my homepage:

"Duplicate without user-selected canonical"

Google was rejecting my homepage. It was choosing www.monkeytravel.app as canonical instead of monkeytravel.app. Despite having:

301 redirects from www → non-www (in both middleware AND Vercel config)
Correct canonical tags in the HTML
All URLs in the sitemap using non-www

I checked everything twice. The redirects worked. The HTML had the right tags. I verified with curl:

$ curl -s https://monkeytravel.app/ | grep canonical
<link rel="canonical" href="https://monkeytravel.app"/>

The tag was right there. So why was Google saying "User-declared canonical: None"?

The Discovery

I stared at this for hours before it clicked. The key was in how I verified it.

curl waits for the complete response. Googlebot doesn't.

In Next.js 15.2+, generateMetadata() streams metadata asynchronously. The <head> tags aren't in the initial HTML payload but they're injected via the stream after the body starts rendering. When Googlebot parses the initial response, the canonical tag literally doesn't exist yet. Or at least this is what I think I figured out jumping between AI, documentations etc.

I confirmed by looking at the raw initial HTML before streaming completes: no <link rel="canonical"> anywhere.

The Fix: One Config Option

// next.config.ts
const nextConfig: NextConfig = {
  htmlLimitedBots: /Googlebot|Google-InspectionTool|Bingbot|Yandex/i,
  trailingSlash: false,
};

htmlLimitedBots tells Next.js: "When a crawler visits, disable streaming. Send the full HTML with all metadata synchronously."

That's it. One regex. Fixed the entire problem.

I also changed my root layout canonical from "/" to "./" so every page gets a self-referencing canonical instead of all pages pointing to the homepage (a subtle but important distinction).

Deployed. Requested re-indexing. Within days: 176 pages indexed.
Still not all the 230+ pages but we are getting there!

The Numbers

Metric	Week 1	Week 2	Week 3
Pages indexed	12	78	176
Total pages in sitemap	~50	~225	~230
Blog posts (per language)	1	15	50
Structured data schemas	3	5	5

What I Got Wrong (So You Don't Have To)

1. I didn't set up htmlLimitedBots from day one. This should be in every Next.js project that cares about SEO. The metadata streaming issue is completely silent, everything looks fine when you check manually. Only crawlers are affected. I thought it was a "content volume" issue... not really!

2. I treated SEO as a "later" problem. Every week I delayed the sitemap and canonical tags was a week of potential crawling wasted. Google's queue doesn't move faster just because you're impatient.

3. I underestimated internal linking. Cross-linked pages got indexed 3-4x faster than isolated pages. If you have related content, link it. Google follows links.

4. I built multilingual support but forgot hreflang. Having 3 language versions without hreflang means Google might treat them as duplicate content instead of translations. Costly mistake.

AI Tricks That Helped

A few things that saved me time during this sprint:

AI-assisted blog content: I used AI to draft blog post structures, then edited and localized them. For 50 posts × 3 languages, doing everything manually would have taken months and study an extra language or find more international collaborators.
Automated cross-linking: I wrote a script that analyzed blog post topics and destination pages, then generated internal link suggestions. Much better than trying to mentally map 200+ pages.
Prompt engineering for i18n: Instead of translating English content, I had the AI generate locale-native content. "Write about Paris for an Italian audience" produces much better content than "translate this Paris article to Italian."

What I'd Tell Past Me

Start with these on day one, before you write a single feature:

htmlLimitedBots in next.config.ts
Sitemap generation
Canonical tags on every page
Submit to Google Search Console

Everything else, blog posts, structured data, internal linking, matters, but these four things are the foundation. Skip them and nothing else works.

129 pages are still in Google's queue. Based on the trajectory, they'll be indexed within a couple of weeks (hopefully). Then the real game starts: actually ranking for competitive keywords.
That will be FUN

MonkeyTravel is free to use — drop a destination, get a personalised AI itinerary in seconds. Built with Next.js, Supabase, and hosted on Vercel. Any feedback is more than welcome! Let's learn something new together