rustuya-manager 0.1.0__tar.gz

rustuya_manager-0.1.0/PKG-INFO

@@ -0,0 +1,20 @@
+Metadata-Version: 2.4
+Name: rustuya-manager
+Version: 0.1.0
+Summary: Management tool for rustuya-bridge — keeps Tuya Cloud devices and the bridge in sync
+License: MIT
+Requires-Python: >=3.10
+Requires-Dist: aiomqtt>=2.0
+Requires-Dist: rich>=13.0
+Requires-Dist: fastapi>=0.115
+Requires-Dist: uvicorn[standard]>=0.30
+Requires-Dist: pyrustuyabridge<0.4,>=0.3.0
+Requires-Dist: tuyawizard>=0.1.9
+Requires-Dist: cryptography>=41
+Requires-Dist: packaging>=23
+Provides-Extra: dev
+Requires-Dist: pytest>=8; extra == "dev"
+Requires-Dist: pytest-asyncio>=0.23; extra == "dev"
+Requires-Dist: pytest-playwright>=0.5; extra == "dev"
+Requires-Dist: httpx>=0.27; extra == "dev"
+Requires-Dist: ruff>=0.6; extra == "dev"

rustuya_manager-0.1.0/README.md

@@ -0,0 +1,302 @@
+# Rustuya Manager
+
+A management tool for [rustuya-bridge](https://github.com/3735943886/rustuya-bridge) that diffs Tuya Cloud devices against the running bridge and syncs add / remove / update operations. Includes a web UI with built-in Tuya Cloud login.
+
+![rustuya-manager web UI](docs/screenshots/main-annotated.png)
+<sub>Desktop view — sync categories highlighted with their actions; the header's <b>☰ Menu</b> holds add device, cloud login, <b>📡 Scan</b>, theme, refresh, and <b>🔧 Reconfigure bridge</b>. Each row also carries a live-status dot and per-device ✎ edit / 🗑 remove / ↻ query-status icons.</sub>
+
+<img src="docs/screenshots/main-mobile.png" alt="Mobile layout" width="280">
+<br><sub>Mobile view — layout adapts to narrow viewports.</sub>
+
+<sub>Other views: [unannotated](docs/screenshots/main-light.png) · [dark](docs/screenshots/main-dark.png) · [bulk sync](docs/screenshots/sync-modal.png)</sub>
+
+## Key Features
+
+- **Status dashboard** — Missing / Orphaned / Mismatched / Synced categories by diffing the Tuya Cloud device list against the bridge's live state.
+- **Built-in Tuya Cloud login** — fetch the device list straight from the web UI; no external tooling needed. A `tuyadevices.json` upload / drop-zone is still available for offline workflows.
+- **No separate config** — picks up the bridge's topic and payload templates from its retained `bridge/config`.
+- **Live updates over MQTT** — DPS values stream into the UI in real time.
+- **Web UI** — single-page UI with search, sort, sub-device tree, per-device add / edit / remove and bulk-sync.
+
+## Usage
+
+Start with `--web` (the Docker image does this by default). The
+dashboard loads every device known to either side and categorizes
+it by how the bridge's view compares to the Tuya Cloud-of-record
+— uploaded as `tuyadevices.json` or pulled in-app via the header **☰ Menu → ☁ Fetch from cloud**:
+
+- 🟦 **Missing** — in cloud, not yet on the bridge. Click **Add** on
+  the card to publish it; the bridge picks it up and starts polling.
+- 🟥 **Orphan** — on the bridge, not in cloud (or dropped from cloud
+  since last sync). Click **🗑** to remove it from the bridge.
+- 🟨 **Mismatch** — in both, but a field drifted (IP / key / version
+  differ). Click **Update** to push the cloud values; expand the row
+  to see exactly which fields are out of sync.
+- 🟩 **Synced** — in both, fields match. No action needed.
+
+Every per-card action has a bulk path — the buttons above the list
+(**Add missing** / **Remove orphan** / **Update mismatch** / **Apply
+all**) open a modal showing the full plan, let individual rows be
+unchecked to skip, then run them sequentially with per-row status.
+
+Click any row to expand it: live DP values stream in via MQTT, plus
+the bridge's last error/status message and the resolved IP / key /
+version. The pencil ✎ opens an editor that re-publishes the device
+to the bridge with the modified fields (the cloud-of-record JSON is
+unchanged); the trash 🗑 removes the device from the bridge.
+
+### Refreshing from Tuya Cloud
+
+The header **☰ Menu → ☁ Fetch from cloud** opens the in-app login wizard. Sign in
+once via QR with the Smart Life or Tuya Smart app — credentials are
+cached in `tuyacreds.json`, so subsequent re-fetches skip the scan and
+go straight to the device list.
+
+<img src="docs/screenshots/wizard-modal.png" alt="Tuya Cloud login modal" width="420">
+
+**Scan device IPs after fetch** (off by default) decides what the
+manager writes into the bridge record:
+
+- **Off (default)** — devices ship to the bridge with no IP. The
+  bridge runs its own LAN scan at runtime and catches DHCP IP
+  changes automatically. Recommended unless every Tuya device on the
+  LAN has a pinned address.
+- **On** — best performance: the bridge **never scans the LAN** and
+  every reconnect goes straight to the recorded address. Only useful
+  when every device has a pinned IP (manual static or DHCP
+  reservation on the router). On DHCP networks where leases rotate
+  the bridge ends up retrying stale addresses; the header **☰ Menu →
+  📡 Scan LAN** (or a fresh cloud re-fetch) recovers visibility.
+
+The toggle state is persisted per browser.
+
+**📡 Scan LAN** (header **☰ Menu**) asks the bridge for a one-shot LAN
+scan. Any device registered with an explicit (non-auto) IP that has drifted
+surfaces as `ERR_STATE 906` in the MSG line, so the right device can
+be fixed at the router.
+
+## Quick Start
+
+Requires Python 3.10+ and a running [rustuya-bridge](https://github.com/3735943886/rustuya-bridge) reachable via MQTT.
+
+### Install
+
+**pipx (recommended)** — drops a `rustuya-manager` shim into `~/.local/bin/`, no activate step:
+```bash
+sudo apt install -y pipx                          # if not already
+pipx ensurepath
+pipx install rustuya-manager
+```
+
+**venv + pip** — alternative install without pipx:
+```bash
+python3 -m venv ~/.venvs/rustuya-manager
+~/.venvs/rustuya-manager/bin/pip install rustuya-manager
+~/.venvs/rustuya-manager/bin/rustuya-manager --help
+```
+Run it by full path, or activate the venv first (`source ~/.venvs/rustuya-manager/bin/activate`). The systemd unit in the next section assumes the pipx path — change `ExecStart` to `%h/.venvs/rustuya-manager/bin/rustuya-manager` for the venv install.
+
+### Run
+
+```bash
+rustuya-manager --broker mqtt://localhost:1883 --root rustuya \
+                --web --port 8373 --auth admin:CHANGE_ME
+```
+Then open the URL printed at startup. The default bind is `127.0.0.1` so the UI is reachable only from the same machine. To open it to the LAN add `--host 0.0.0.0` — pair with a real `--auth user:pass`.
+
+Common flags:
+- `--cloud PATH` (default `tuyadevices.json`) — Tuya devices JSON. If
+  missing, the web UI offers an in-app Tuya Cloud login or a JSON
+  drop-zone.
+- `--broker URL` (default `mqtt://localhost:1883`) — accepts
+  `mqtt://[user:pass@]host:port`.
+- `--root TOPIC` (default `rustuya`) — must match the bridge's
+  `--mqtt-root-topic`.
+- `--host`, `--port` (default `127.0.0.1:8373`) — web server bind.
+- `--auth USER:PASS` (default off) — HTTP Basic auth for the web UI.
+- `--embed-bridge` (default off) — run the bridge inside this process
+  via the `pyrustuyabridge` bindings (single-process deploy). Refused
+  at startup if another bridge already publishes on `--root`.
+- `--bridge-state PATH` (default: `rustuya.json` in the same
+  directory as `--cloud`, matching the standalone bridge's filename) —
+  embedded bridge's device state file. **Only meaningful with
+  `--embed-bridge`.**
+- `--bridge-config PATH` (default off) — JSON config for the embedded
+  bridge, same format as `rustuya-bridge --config` (read and merged;
+  auto-created if missing). Sets custom topics / MQTT auth / scanner
+  options without re-exposing every bridge flag here. **Only meaningful
+  with `--embed-bridge`.** For the three fields the manager and bridge
+  share (`mqtt_broker`, `mqtt_root_topic`, `state_file`) the manager
+  adopts the config's values as its own defaults; a CLI flag still wins.
+
+### Run as a service (systemd, user-level, no sudo)
+
+```bash
+mkdir -p ~/.config/systemd/user ~/.local/share/rustuya-manager
+cp examples/rustuya-manager.service ~/.config/systemd/user/
+# edit the file — change --auth, --broker, --root to match the local setup
+systemctl --user daemon-reload
+systemctl --user enable --now rustuya-manager
+journalctl --user -u rustuya-manager -f         # follow logs
+```
+
+To keep the service running after logout (one-time, the only sudo step):
+```bash
+sudo loginctl enable-linger $USER
+```
+
+### Update
+
+```bash
+pipx upgrade rustuya-manager                                   # pipx install
+# or, for the venv install:
+~/.venvs/rustuya-manager/bin/pip install -U rustuya-manager
+systemctl --user restart rustuya-manager
+```
+
+## Docker
+
+Single-container deploy with the bridge bundled in — aimed at HA OS,
+unraid, CasaOS and similar container-first setups (distinct from the
+pipx + systemd track above, which keeps `rustuya-bridge` as a separate
+service).
+
+```bash
+docker run -d \
+  --name rustuya-manager \
+  --network host \
+  --restart unless-stopped \
+  -e AUTH=admin:CHANGE_ME \
+  -v rustuya-manager-data:/data \
+  3735943886/rustuya-manager:latest
+```
+
+The image runs `rustuya-manager --web --embed-bridge`, so manager and
+bridge share one process and the only external dependency is an MQTT
+broker. Key points:
+
+- **`--network host` is required** — the embedded bridge discovers Tuya
+  devices with UDP broadcasts (ports 6666/6667), which Docker's default
+  bridge network drops, so devices are never seen.
+- **Broker** defaults to `mqtt://localhost:1883` (host-local mosquitto
+  under `--network host`). For a remote broker, set `mqtt_broker` in
+  `/data/config.json` — the embedded bridge auto-creates that file and
+  treats it as the single source of truth.
+- **Already running a separate bridge?** Pass `-e EMBED_BRIDGE=0` so the
+  container doesn't spawn a second one that double-publishes on the same
+  topics.
+- **`--restart unless-stopped`** lets Docker recover the manager — and
+  with it a fresh embedded bridge — after the in-process supervisor hits
+  its restart rate limit.
+
+Environment variables (defaults shown; all optional unless noted):
+
+| Variable | Default | Maps to |
+|---|---|---|
+| `HOST` | `0.0.0.0` | `--host` |
+| `PORT` | `8373` | `--port` |
+| `BROKER` | *(unset → bridge-config, then `mqtt://localhost:1883`)* | `--broker` |
+| `ROOT` | *(unset → bridge-config, then `rustuya`)* | `--root` |
+| `AUTH` | *(off)* | `--auth USER:PASS` |
+| `CLOUD` | `/data/tuyadevices.json` | `--cloud` |
+| `PLUGIN_DIR` | `/data/plugins` | `--plugin-dir` |
+| `BRIDGE_CONFIG` | `/data/config.json` | `--bridge-config` |
+| `BRIDGE_STATE` | *(unset → bridge-config `state_file`, then `/data/rustuya.json`)* | `--bridge-state` |
+| `PUID` | `1000` | UID the app runs as |
+| `PGID` | `1000` | GID the app runs as |
+| `EMBED_BRIDGE` | `1` | `--embed-bridge` (set `0` when an external bridge is already on the broker) |
+
+All persistent state lives under `/data` — cloud cache
+(`tuyadevices.json`), wizard credentials (`tuyacreds.json`), bridge
+config (`config.json`) and bridge state (`rustuya.json`) — so the volume
+is the only backup target. Pass an empty value to disable an optional
+flag (e.g. `-e BRIDGE_CONFIG=`).
+
+For **bind-mounted** host directories (`-v /host/path:/data`), pass
+`PUID`/`PGID` so the in-container user can write to them:
+
+```bash
+-e PUID=$(id -u) -e PGID=$(id -g)
+```
+
+The entrypoint renumbers its internal `manager` user to that UID/GID and
+`chown`s `/data` on startup. Named volumes need none of this — Docker
+handles ownership.
+
+### Plugins
+
+A plugin can add a UI tab, REST routes, an MQTT subscription, and its
+own slice of state. They arrive three ways:
+
+1. **From the in-UI catalog** (recommended) — the **Manage plugins** (🧩)
+   item in the ☰ menu lists a curated catalog you install from with one
+   click, no shell or `pip`.
+2. **As a pip-installed package** under the `rustuya_manager.plugins`
+   entry-point group.
+3. **Hand-dropped** into the plugin directory (handy for development or
+   Docker, where you'd otherwise rebuild the image).
+
+All three run **in-process with no sandbox**, so the trust anchor is the
+same in every case: only install plugins you trust. The catalog is
+curated for exactly this reason — there is no arbitrary-URL field.
+
+#### Installing from the catalog
+
+**Manage plugins** (☰ → 🧩) opens a modal listing each catalog plugin
+with its install state and actions:
+
+- **Install** downloads the plugin into the managed plugin directory,
+  verifies its checksum, and wires it up **live** — the new tab appears
+  with no restart.
+- **Update**, **Enable/Disable**, and **Uninstall** act on an installed
+  plugin. These need a manager restart to take effect (already-loaded
+  code can't be swapped or unloaded at runtime), so the modal offers a
+  **Restart now** button when an action requires it.
+
+Installs need a writable plugin directory (see below). Under Docker that
+means a mounted `PLUGIN_DIR`.
+
+#### The plugin directory
+
+The managed plugin directory is where the catalog installs plugins and
+where you can also hand-drop your own. It defaults to a `plugins/` folder
+next to the cloud file; override it with `--plugin-dir DIR` (env
+`RUSTUYA_MANAGER_PLUGIN_DIR`). Under Docker the image defaults
+`PLUGIN_DIR=/data/plugins` — mount a folder there so installs persist.
+
+To hand-drop a plugin, place a package (a directory with `__init__.py`
+exposing `register(ctx)`) or a single `*.py` file in that directory:
+
+```
+<plugin-dir>/
+  rustuya_hello/        # package plugin
+    __init__.py         #   defines register(ctx)
+    static/             #   its UI assets (served automatically)
+  quicktweak.py         # single-file plugin: just register(ctx)
+```
+
+One caveat for hand-dropped plugins: they **can't install their own
+dependencies** (they get the standard library plus what the manager
+already provides — for anything heavier, install it as an entry-point
+package or via the catalog instead). See
+[`examples/hello_plugin`](examples/hello_plugin) for a complete plugin.
+
+#### Loading a hand-dropped plugin
+
+Installing from the catalog ("Manage plugins" 🧩) loads the plugin live, no
+restart. If you instead copy a plugin package into the plugin dir by hand, pick
+it up with:
+
+- **Restart manager** (♻, ☰-menu) — restarts the manager process in place (same
+  PID, via re-exec). This is the full reload: it discovers hand-dropped plugins,
+  picks up edited plugin code, drops removed/disabled plugins, and respawns an
+  embedded bridge — lighter than a container restart and works outside Docker
+  too. The UI reconnects automatically; an embedded bridge briefly disconnects
+  its devices.
+
+(The add-only `POST /api/plugins/scan` endpoint still loads newly-dropped
+plugins without a restart, but it's no longer surfaced as a menu item — a
+restart is the simpler story for the rare hand-drop.)
+
+## License
+MIT

rustuya_manager-0.1.0/pyproject.toml

@@ -0,0 +1,76 @@
+[build-system]
+requires = ["setuptools>=68"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "rustuya-manager"
+# Single source of truth: src/rustuya_manager/__init__.py:__version__. Bump it
+# there only — this resolves it at build time, web.py reads it at runtime, and
+# check.sh reads it from the installed package. See [tool.setuptools.dynamic].
+dynamic = ["version"]
+description = "Management tool for rustuya-bridge — keeps Tuya Cloud devices and the bridge in sync"
+requires-python = ">=3.10"
+license = { text = "MIT" }
+dependencies = [
+    "aiomqtt>=2.0",
+    "rich>=13.0",
+    "fastapi>=0.115",
+    "uvicorn[standard]>=0.30",
+    "pyrustuyabridge>=0.3.0,<0.4",  # Floor is the 0.3.0 stable line: it supersedes the 0.3.0rc28 the manager was developed against (by PEP 440, a stable 0.3.0 already includes everything through rc28), and clears the last pre-release pin from the tree for the final manager release. The rc-by-rc history below is retained as the rationale for why the manager needs this line. 0.2.0rc11 added the `reconfigure` self-terminate that _EmbeddedBridgeSupervisor (cli.py) drives. rc12–rc16 are bridge-side correctness fixes the manager benefits from: rc12 retained cleanup covers the whole fleet, rc13 fixes a cleanup deadlock + coalesced-removes gap, rc15 counts PubAcks instead of buffered writes, rc16 adds a liveness-probe singleton check so post-power-loss startup can't deadlock. rc17 makes multi-target commands (remove cascade, clear) reply per-id so the manager can act on each ack individually instead of guessing which devices the bridge wiped. rc18 moves the cache-mode retained snapshot from `{type}=passive` to `{type}=state` (passive becomes a no-retain delta); the manager wildcards `{type}` so no code change, but pinning rc18 keeps a mixed deployment from leaving orphan `passive` retained snapshots that briefly seed `retained_only` before the bridge's scavenger clears them. rc19 exposes `parse_seed_dps` so `_extract_dps_from_event` reads multi-DP event payloads (no `{dp}` in topic, bare DPS object — e.g. a `get` reply on `event/passive/{id}`) byte-identically to the bridge instead of dropping them; the manager now calls it, so this is a hard pin. rc20 bumps the core rustuya crate (bridge-internal). rc21 lifts rumqttc's 10KiB client packet cap and paginates the `status` reply so large fleets aren't truncated mid-device-list, and caps connection-establishment concurrency so a big fleet's startup storm can't overwhelm the bridge. rc22 adds background-task panic logging (diagnostic). rc23 fixes a Python-binding shutdown-time process abort — a tokio worker forwarding a log record to Python during interpreter finalization could force-terminate the process at the `panic=abort` boundary; since the manager drives the embedded bridge's `stop()`/`close()` (_EmbeddedBridgeSupervisor), pinning rc23 keeps an embedded-bridge shutdown from aborting the manager process. rc23 also pulls rustuya rc7's replay-latched-status fix so a late-attaching listener still gets a large fleet's straggler device states. rc24 fixes fleet-scale fan-out under QoS1: a name-addressed `set`/`get` or gateway cascade emitting hundreds of deltas+responses at once stalled the MQTT event loop (PUBACK round-trips + the in-flight window) and reset ~60% of a 500-device fleet's connections, so most responses were lost (~99/500 delivered). Live messages now publish at QoS0 (retained state stays QoS1) and the publish loop uses non-blocking try_publish; fan-out also runs bounded-concurrent. A 500-device name fan-out now completes with 0 connection resets — the manager issues exactly these name/cascade commands, so this is the fix that makes whole-fleet ops reliable. rc25 stops publishing mqtt_user/mqtt_password into the retained {root}/bridge/config (skip_serializing) and injects the bridge `version` into that payload. The manager exposes the raw bridge config to third-party plugins via ctx.bridge_config(), and can run an embedded bridge through this binding — so pinning rc25 guarantees the embedded path never writes credentials to the broker in the first place (the manager also redacts defensively in plugins.py for external/older bridges). The `version` field is surfaced in the UI's bridge-diagnostics panel. The pin moved 0.2.x→0.3.x at the same rc25: the wheel was re-tagged 0.3.0rc25 to match the bridge crate version it ships (`CARGO_PKG_VERSION`, which the bridge publishes into {root}/bridge/config), so the pip label and the status-reported version finally agree — same code, aligned numbering. The Info panel's online version check (PyPI max, prereleases included) relies on this alignment. rc26 makes the retain scavenger sweep in repeated passes (re-subscribe → collect → clear, until a pass clears nothing) instead of a single replay window with no retry: a mass `clear`/`remove` on a large fleet, where the broker's one-shot retained replay is gappy or slow, previously stranded most retained device state ("scavenger left orphans"). The manager issues exactly these mass clear/remove commands, so pinning rc26 is what makes whole-fleet teardown reliably leave no orphan retained state. rc27 bumps the core rustuya crate rc7→rc9 (bridge-internal, transparent through the binding): device connect now accepts IPv6 literals, link-local zone ids, and NAT64-synthesized addresses (the connect path passes `(host, port)` as a tuple instead of a formatted `addr:port` string, which mangled bracketless IPv6), and the crypto stack moves to aes-gcm 0.11.0 final, clearing the last pre-release dependency from the tree. No manager-facing API change. rc28 adds a `set_config` MQTT command (alias `configure`) that patches the six topic/template/retain settings into the config file and optionally chains a `reconfigure`, and — BREAKING for the bridge's own CLI/env surface — makes those same six settings (mqtt_command_topic, mqtt_event_topic, mqtt_message_topic, mqtt_scanner_topic, mqtt_payload_template, mqtt_retain) config-file/set_config only, dropping their `--mqtt-*` flags and `MQTT_*` env vars so a runtime config write can't be silently overridden on the next restart. This doesn't affect the manager: `_spawn_embedded_bridge` (cli.py) only forwards mqtt_broker/mqtt_root_topic/state_file/log_level (+ optional config_path) and broker creds as kwargs — it never passed any of those six as flags or env, so the embedded path already complies with the config-file-only rule, and the manager reads templates from the retained {root}/bridge/config topic regardless. The new set_config command is available to surface in the UI later but is not yet used.
+    "tuyawizard>=0.1.9",  # 0.1.8 added close()/context manager to stop the per-call requests.Session leak (~750-950 KB/cycle); 0.1.9 then changed close()'s default so it no longer POSTs to `/v1.0/m/token/terminal/expire` — the previous default revoked the saved tokens server-side after every wizard run, forcing a fresh QR scan on the next call. Manager's wizard.close() is called with no args so it picks up the new revoke_terminal=False default automatically.
+    "cryptography>=41",   # missing dep of tuya-sharing-sdk
+    "packaging>=23",      # PEP440 parse/compare for the Info panel's PyPI update check (max-incl-prereleases vs installed); already present transitively, declared since versions.py imports it directly
+]
+
+[project.optional-dependencies]
+dev = [
+    "pytest>=8",
+    "pytest-asyncio>=0.23",
+    "pytest-playwright>=0.5",
+    "httpx>=0.27",
+    "ruff>=0.6",
+]
+
+[project.scripts]
+rustuya-manager = "rustuya_manager.cli:main"
+
+[tool.setuptools.dynamic]
+version = { attr = "rustuya_manager.__version__" }
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.setuptools.package-data]
+rustuya_manager = ["templates/*.html", "static/*.js", "static/*.css", "static/locales/*.json", "data/*.json"]
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]
+asyncio_mode = "auto"
+# e2e_ui boots uvicorn in a session-scoped daemon thread and drives the page
+# via Playwright's sync API (greenlet bridge). Both leak event-loop state into
+# the main thread, which then collides with pytest-asyncio's per-test Runner
+# when async unit tests run in the same session. Default to excluding e2e here
+# so a bare `pytest` is fast and conflict-free; CI runs `pytest -m e2e` in a
+# separate step.
+addopts = "-m 'not e2e'"
+markers = [
+    "e2e: browser-driven UI smoke tests (Playwright + uvicorn); run separately",
+]
+
+[tool.ruff]
+line-length = 100
+target-version = "py310"
+extend-exclude = ["build", "dist"]
+
+[tool.ruff.lint]
+select = ["E", "F", "I", "W", "B", "UP"]
+ignore = [
+    "E501",  # formatter handles line length
+    "B008",  # FastAPI Depends/Body in defaults
+]
+
+[tool.ruff.lint.isort]
+known-first-party = ["rustuya_manager"]
+
+[tool.ruff.format]
+quote-style = "double"

rustuya_manager-0.1.0/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+

rustuya_manager-0.1.0/src/rustuya_manager/__init__.py

@@ -0,0 +1,12 @@
+"""rustuya-manager — sync layer between Tuya Cloud and rustuya-bridge.
+
+The package exposes domain modules (models, diff, state, mqtt) plus a
+`cli` entry point that preserves the original interactive workflow.
+Topic and payload templating is delegated to `pyrustuyabridge` so the
+manager's interpretation is byte-identical to the bridge's behavior.
+"""
+
+# The one place the version is defined. pyproject.toml resolves it at build
+# time via [tool.setuptools.dynamic]; web.py uses it for the FastAPI title;
+# check.sh reads it from the installed package. Bump here and nowhere else.
+__version__ = "0.1.0"

rustuya_manager-0.1.0/src/rustuya_manager/__main__.py

@@ -0,0 +1,6 @@
+"""Allow `python -m rustuya_manager` invocation."""
+
+from .cli import main
+
+if __name__ == "__main__":
+    raise SystemExit(main())