v.1.12.0-beta2

Eufy Robovac MQTT — v1.12.0-beta2

The biggest release since the live map: Eufy's older, non-MQTT vacuums now work. This adds a full Tuya Cloud path for legacy/scalar robovacs that never spoke Eufy's MQTT protocol, an opt-in direct LAN ("local Tuya") transport that replaces 30-second cloud polling with near-instant push, unified "Eufy" app (v2) login for accounts migrated off the old Eufy Clean app, and first-class modelling for the RoboVac S1 / S1 Pro.

This beta builds on v1.12.0-beta1 with the fixes that beta surfaced: it makes migrated unified-app accounts that showed "No devices" discover their robots again (#121 / #124), routes the S1 Pro down the correct Tuya path (#131), and reworks the options screen into a clean menu that fixes the two rough edges from beta1.

It consolidates the community legacy/Tuya work tracked in #110 (Tuya Cloud), #111 (S1 Pro), #122 (unified-app login) and #126 (local Tuya) on top of main, and fixes #121 / #124, #131 and the stale-version display in #140.

⚠️ This is a beta (v1.12.0-beta2). The login-discovery (#121/#124) and S1 Pro routing (#131) fixes are covered by tests but still need confirmation from the reporters on real migrated accounts / a physical S1 Pro — please comment on those issues if you can.
New dependency: tinytuya>=1.18.0,<2.0.0, installed automatically by HACS/Home Assistant on upgrade.
The live map and live X/Y position are MQTT-only. Eufy delivers them over a separate encrypted P2P channel (eufy_mega) that hasn't been reverse-engineered, so they're unavailable on either Tuya transport. Everything else — start/stop/pause/return, fan speed, battery, errors, lifetime stats — works.

---

✨ Highlights

☁️ Tuya Cloud support for legacy (non-MQTT) vacuums

Older Eufy robovacs that talk to Tuya's cloud instead of Anker's MQTT broker are now discovered and controllable from Home Assistant — previously they simply never appeared. A new Tuya Cloud client logs in alongside the existing Eufy login, discovers any Tuya-backed vacuums on the account, and drives them over a plain-value DPS command/parse path (no protobuf).

• Transport is decided per device at runtime from the Eufy API's mqtt flag — not by model name. MQTT devices keep their full push experience; Tuya-only devices fall onto the cloud path.
• What works on the legacy path: start/auto clean, play/resume, pause, stop, return to base, find robot, fan speed, spot clean, room clean and edge clean — plus battery, error code + message, charging state, fan speed and work-mode reporting.
• 30-second polling with backoff. Cloud devices refresh every 30 s; on repeated failures the interval backs off exponentially (capped at 5 min) and the device is marked unavailable after 5 consecutive failures rather than hanging silently.
• Resilient login. EU-first / US-fallback regions, automatic re-login on session expiry (one retry per command), and a clear aggregate error in the log if every login endpoint fails.

Legacy devices get a deliberately reduced entity set — no dock/station controls, consumables, scenes, zone/area cleaning or numeric controls, because those commands have no legacy equivalent. They keep the vacuum entity, Suction Level, Find Robot and the universal sensors. See Upgrade notes.

⚡ Optional local (LAN) push transport — goodbye 30-second lag

For any Tuya-discovered vacuum, you can opt in to a direct LAN socket to the dock (Tuya local protocol, port 6668) instead of cloud polling:

• Near-instant updates — state changes push to HA within seconds, and the connection keeps working even while the Eufy/Tuya cloud is unreachable.
• No key wrangling. The 16-character local key is supplied automatically from your Tuya Cloud login — you never extract or paste it.
• Per-device, opt-in via Configure → enter the dock's LAN address and (if needed) pick the Tuya protocol version. Host/version fields only appear for devices that actually have a local key.
• Graceful fallback. If the socket can't open (wrong host, firewall, dock offline, IP changed), the coordinator silently drops back to 30-second cloud polling — the dashboard never goes unavailable just because the LAN address shifted.

🔒 Security model: the local transport is AES-encrypted with your device's local key — it is not TLS and performs no certificate validation, so it's intended for a trusted LAN only. The local key grants full local control of the dock; treat it as a secret and never paste integration debug logs (which can contain it) into public issues. tinytuya is deliberately kept out of the manifest loggers for exactly this reason.

🔑 Unified "Eufy" app (v2) login — now finds devices on migrated accounts

Accounts migrated to the new "Eufy" app could authenticate but came back with "No devices" (#121 / #124). The cause: AIOT device discovery needs a user_center token, but those accounts only get one from the v2 login — the v1 login authenticates yet returns no user_center, and the old logic stopped at the first token that merely worked.

• Login now tries each credential set (v2 first, then v1) and prefers one whose token actually yields a user_center, then fetches MQTT credentials from it.
• If none does, it keeps a working session as a fallback so the Tuya cloud/local path can still discover the robot via the Eufy user_id alone — instead of giving up with an empty list.
• A rejected get_user_info response no longer leaves stale state behind for later callers.

🤖 RoboVac S1 / S1 Pro (T2080 / T2080A) — routed correctly

The S1 Pro (T2080A) is now modelled ("Robovac S1 Pro") alongside the S1 (T2080), and model resolution no longer truncates codes (T2080A ↛ T2080). Beyond just keeping the device (#131), this beta makes sure it lands on the right transport:

• When the AIOT list is empty, the integration reconstructs a placeholder "MQTT" device — and the real Tuya device (carrying its local key) now supersedes that placeholder instead of being dropped as a duplicate. No more S1 Pro "stuck on the MQTT path it can't answer" (the 1 MQTT + 0 cloud symptom).
• A single robot reported under different Eufy/Tuya ids no longer shows up twice (dedupe + a single-robot safety net so two coordinators aren't created for one vacuum).
• Device classification now reads a Tuya status string ("Running", "Charging") as legacy, not scalar — so the S1 Pro uses the legacy parser/commands rather than the scalar (G50) path.

🏷️ Manual room-name overrides (Clean Room on Tuya transports)

The room list and the Clean Room select normally arrive over the same encrypted P2P channel as the map — so on Tuya transports the dropdown is empty. You can now supply your own mapping in Configure → Local-Tuya address & room names → pick the device → the Room names field, one id: name per line: