Skip to content

Refresh the plugin catalogs on demand with the stored cloud login - #253

Draft
virtitnerd wants to merge 4 commits into
Python-roborock:mainfrom
virtitnerd:pr/plugin-catalog-refresh
Draft

virtitnerd wants to merge 4 commits into
Python-roborock:mainfrom
virtitnerd:pr/plugin-catalog-refresh

Conversation

@virtitnerd

Copy link
Copy Markdown
Contributor

Depends on #224. This branch is built on #224's head, so until that merges the diff also shows its one commit
(fix(plugin): resolve string product ids and serve the iOS app plugin). Only the top three commits are new here.

Why

The plugin catalog is read once, during the cloud import, so it goes stale. In my setup the stock Android app (talking
to the real cloud) ran plugin 7006 for a Qrevo Curv 2 Flow while the iOS app, pointed at the local server, was served
5736. Re-running the whole import to refresh one list is heavy, and it needs a fresh email code.

What

  • POST /admin/api/cloud/refresh-plugins re-reads the plugin catalogs with the login the server stored at sign-in.
  • GET /admin/api/cloud/plugins shows what is stored without a cloud request, with each plugin's version, API level
    and download URL.
  • The import's own plugin fetch (from fix(plugin): resolve string product ids and serve the iOS app plugin #224) decides which platforms to fetch, so the refresh does not take a platform.

Testing

Tests for the refresh with a fake cloud, for the stored catalog and for the two endpoints, including that both need
the admin login. Full suite: 465 passed.

Related

#224 (the same stale-catalog problem for the iOS app).

AlexanderBabel and others added 4 commits October 30, 2026 21:17
The cloud lists newer models (e.g. roborock.vacuum.a226) under a string
product id, so the import never fetched their app plugin and /api/v5/product
answered with a hashed id that matches no plugin. The app then fails with
"device initialization failed".

The import now fetches the cloud's /api/v5/product to map models to their
numeric id, and fetches /api/v1/appplugin for both type 2 (Android) and
type 1 (iOS), which get different zips. The appplugin route answers iOS
requests from the iOS catalog, falling back to the existing one.

Fixes Python-roborock#221
The snapshot keeps the cloud login and the plugin catalogs fetched at sign-in, and the
plugin routes serve those. Newer robots can need newer plugins than the snapshot holds, so
CloudImportManager.refresh_plugin_catalogs asks the cloud again with the stored login and
replaces only the catalogs. The sign-in now also stores the device identifier the cloud
ties the login to. A rejected login or an empty answer leaves the snapshot as it was.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
POST /admin/api/cloud/refresh-plugins re-reads them with the stored login, taking an
optional platform type. GET /admin/api/cloud/plugins shows what is stored without a cloud
request. Both return each plugin's version, API level and download URL.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The refresh calls the same _fetch_plugin_catalogs as the sign-in import, so it gets
whatever that fetches, instead of carrying its own platform type.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants