rustuya-local 0.1.0.dev4__tar.gz → 0.1.0.dev6__tar.gz

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/.github/workflows/_test.yml

@@ -38,14 +38,14 @@ jobs:
           repository: 3735943886/ildevice-homeassistant
           path: ildevice-homeassistant
 
-      # tuya2ildevice is on PyPI (installed below via uv), so this isn't for dependency
+      # tuya-interpreter is on PyPI (installed below via uv), so this isn't for dependency
       # resolution -- it's so tests/e2e/test_full_stack_devices.py can reach its sibling
       # checkout's tests/golden fixture data, which isn't shipped in the published package.
-      - name: Check out tuya2ildevice
+      - name: Check out tuya-interpreter
         uses: actions/checkout@v7
         with:
-          repository: 3735943886/tuya2ildevice
-          path: tuya2ildevice
+          repository: 3735943886/tuya-interpreter
+          path: tuya-interpreter
 
       - name: Set up Python ${{ matrix.python-version }}
         uses: actions/setup-python@v7
@@ -114,7 +114,7 @@ jobs:
           "$RUNNER_TEMP/smoke/bin/python" -c "
           import rustuya_local.cli, rustuya_local.manager_plugin, rustuya_local.service
           from rustuya_local import register
-          import tuya2ildevice
-          tuya2ildevice.preload()
+          import tuya_interpreter
+          tuya_interpreter.preload()
           print('ok')"
           "$RUNNER_TEMP/smoke/bin/rustuya-local" --help

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/.github/workflows/release.yml

@@ -96,7 +96,7 @@ jobs:
         run: twine check --strict dist/*      # --strict: a missing README (long description) fails the release
 
       - name: Build the rustuya-manager drop-in zip
-        # The manager's plugin catalog installs this asset (it cannot pip-install): rustuya_local with the tuya2ildevice
+        # The manager's plugin catalog installs this asset (it cannot pip-install): rustuya_local with the tuya-interpreter
         # the wheel resolves to vendored inside. Kept out of dist/ so it is not uploaded to PyPI.
         run: |
           python -m pip install dist/*.whl

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/CHANGELOG.md

@@ -8,6 +8,23 @@ stable release.
 
 ## [Unreleased]
 
+## [0.1.0.dev6] — 2026-10-12
+
+### Changed
+- Require tuya-interpreter 0.1.0a1 (tuya2ildevice renamed) in place of tuya2ildevice, in the package, the Home Assistant integration and the manager drop-in archive.
+- Fetch builtin rule updates from tuya-interpreter's `master` branch.
+
+## [0.1.0.dev5] — 2026-10-11
+
+### Fixed
+- Share the running service's complete bridge registry and MQTT command connection with the panel, so panel listing and edits do not open a second registry requester. Require complete contiguous registry pages for standalone setup sessions.
+- Keep explicit offline connection errors from being overwritten by replayed device state snapshots in the panel.
+
+### Changed
+- Split the HA panel synced filter into online and offline, with live sub-device/gateway state and migration of saved filters.
+- Check builtin rules when opening the HA panel; automatically install available updates when enabled, or enable the manual update button with a yellow dot when automatic updates are off.
+- Allow manual builtin rule updates while automatic updates are disabled.
+
 ## [0.1.0.dev4] — 2026-10-11
 
 ### Fixed

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/PKG-INFO

@@ -1,7 +1,7 @@
 Metadata-Version: 2.5
 Name: rustuya-local
-Version: 0.1.0.dev4
-Summary: Local Tuya control: rustuya-bridge -> tuya2ildevice -> IL (ildevice). HA-independent core.
+Version: 0.1.0.dev6
+Summary: Local Tuya control: rustuya-bridge -> tuya-interpreter -> IL (ildevice). HA-independent core.
 Project-URL: Homepage, https://github.com/3735943886/rustuya-local
 Project-URL: Repository, https://github.com/3735943886/rustuya-local
 Project-URL: Issues, https://github.com/3735943886/rustuya-local/issues
@@ -10,7 +10,7 @@ License-File: LICENSE
 Requires-Python: >=3.13
 Requires-Dist: paho-mqtt>=2.0
 Requires-Dist: pyrustuyabridge>=0.4
-Requires-Dist: tuya2ildevice>=0.4.0.dev4
+Requires-Dist: tuya-interpreter>=0.1.0a1
 Provides-Extra: fullstack
 Requires-Dist: tuyamock; extra == 'fullstack'
 Provides-Extra: manager
@@ -37,7 +37,7 @@ rustuya-bridge ──MQTT──► rustuya-local ──MQTT (il/…)──► il
                          BridgeClient + rustuya_local.host.Hub
 ```
 
-- **[tuya2ildevice](https://github.com/3735943886/tuya2ildevice)** is the only place that interprets Tuya: Home Assistant core's `tuya` behaviour and
+- **[tuya-interpreter](https://github.com/3735943886/tuya-interpreter)** is the only place that interprets Tuya: Home Assistant core's `tuya` behaviour and
   user overrides for non-standard devices, through its Sans-I/O Rust engine and Python wrapper.
 - **rustuya-local** is one `Service` (`src/rustuya_local/service.py`) and three thin shells that run it:
   the `rustuya-local run` daemon, the `custom_components/rustuya` Home Assistant integration, and a rustuya-manager
@@ -62,7 +62,7 @@ Stopping the daemon only marks it `offline`; its devices stay in IL (retained) f
 and run `rustuya-local purge --config config.json`: the retained descriptors, values and presence of its IL prefix and
 source are cleared (other sources on the prefix are left alone), so IL consumers drop the devices.
 
-## tuya2ildevice 0.4 host boundary
+## tuya-interpreter host boundary
 
 The shared Rust core interprets one device and has no MQTT or rule-file loading API.
 `rustuya_local.host.Hub` owns the device registry and maps `TuyaDriver` outputs to IL MQTT wire data;
@@ -96,20 +96,24 @@ everything on an external bridge, are left as they are.
 Tuya's cloud schemas are fragmented; fixes go in a `custom_converters/` directory (daemon: `custom_converters` in the
 config; integration: `<config>/rustuya_converters`; manager plugin: its data dir), followed live:
 
-- `*.json`: tuya2ildevice override blocks by product or device id: rename a dp, define one the schema lacks, map the
+- `*.json`: tuya-interpreter override blocks by product or device id: rename a dp, define one the schema lacks, map the
   device's words to the standard ones (`remap.alias`), fix labels and classes, define a declarative converter. A cover's
   direction is not set here but with its settings (below). Each file is a rule object with fixes under `overrides`, for example
   `{"overrides": {"product_id": {"cover": {"invert_position": true}}}}`.
 - Converters are JSON programs under `converters.declarative`; Python code plugins are not loaded.
 
-See tuya2ildevice's README ("User overrides") for the format. Official builtin rules, including `00-default.json`,
-ship with tuya2ildevice and update when that package is upgraded. They are applied before your own rule files.
+See tuya-interpreter's [device customization guide](https://github.com/3735943886/tuya-interpreter/blob/master/docs/device-customization.md#user-overrides) for the format. Official builtin rules, including `00-default.json`,
+ship with tuya-interpreter and update when that package is upgraded. They are applied before your own rule files.
 
-Online updates fetch the latest [builtin rules](https://github.com/3735943886/tuya2ildevice/tree/feat/rust-rule-engine/rules/builtin)
+Online updates fetch the latest [builtin rules](https://github.com/3735943886/tuya-interpreter/tree/master/rules/builtin)
 into `rules/builtin/` inside the overrides directory at start and daily. In the Rustuya panel, use *Update builtin rules*
-to fetch them now or *Automatically update builtin rules* to control automatic updates. The daemon uses `"pack": false`
-to disable online updates; the manager plugin has the same option in its settings. Installed builtin rules remain
-available when online updates are off. Updates only replace or remove files they downloaded, preserving user edits.
+to fetch them now or *Automatically update builtin rules* to control automatic updates. Opening the panel checks for
+updates: with automatic updates on, available changes are installed immediately without a yellow dot. With automatic
+updates off, available changes enable the manual update button with a yellow dot. The button is disabled while checking
+or when the installed rules are current. The daemon uses `"pack": false`
+to disable automatic updates; the manager plugin has the same option in its settings. Installed builtin rules remain
+available when automatic updates are off, and the panel still allows manual updates. Updates only replace or remove
+files they downloaded, preserving user edits.
 
 ### Cover settings
 
@@ -136,9 +140,12 @@ Older `cover.infer_motion` and `converters.cover_motion` blocks are upgraded on
 
 In Home Assistant the files can be edited from a sidebar panel: the integration's *Configure* → *Add the Rustuya
 panel to the sidebar* adds it and links to it. The panel is for administrators. It fetches the device list from Tuya Cloud, shows the
-bridge's devices against the cloud list as rustuya-manager does (missing, bridge only, mismatch, synced, each a filter you can
+bridge's devices using the running service's complete registry and MQTT connection against the cloud list (missing, bridge only, mismatch, online and offline, each a filter you can
 turn off; sub-devices under their gateway; each device's bridge connection, live while the panel is open) with add /
-update / remove. *Register manually* adds Wi-Fi devices or sub-devices without a cloud login, using the same
+update / remove. Online and offline split devices whose cloud and bridge records match; selecting both shows the
+previous synced view. Sub-devices use their own link state, falling back to their gateway when unavailable; an offline
+gateway makes its sub-devices offline. Unknown state is grouped under offline. A gateway stays visible for context
+when one of its children matches the filters. *Register manually* adds Wi-Fi devices or sub-devices without a cloud login, using the same
 fields as rustuya-manager. Devices absent from the cloud list appear under *Bridge only*; their removal is not
 preselected in bulk sync. The panel lists, edits and deletes user converter files (drop JSON rule files on it to copy them in),
 updates builtin rules on demand, and has the
@@ -151,7 +158,7 @@ language: Korean, or English.
 ## rustuya-manager plugin
 
 Installed next to rustuya-manager, as a pip package (`pip install rustuya-local` in the manager's environment) or as
-the drop-in zip each release carries (`rustuya_local-<version>-dropin.zip`, tuya2ildevice binding, native library and builtin rules vendored inside, built by
+the drop-in zip each release carries (`rustuya_local-<version>-dropin.zip`, tuya-interpreter binding, native library and builtin rules vendored inside, built by
 `scripts/build_dropin.py`; unpack it into the manager's plugin directory, or install it from the manager's plugin
 catalog once listed there), it appears as a **Tuya (IL)** tab and runs the service under the manager: the manager's broker and bridge root, the manager's device
 list (followed). Its data dir (`rustuya-local/` next to the manager's plugins) holds `settings.json` (`il`,
@@ -159,7 +166,7 @@ list (followed). Its data dir (`rustuya-local/` next to the manager's plugins) h
 converter files are picked up while it runs. A settings file it cannot use is shown on the tab until it is fixed.
 
 The drop-in zip includes native code for the platform on which it was built; use a matching OS and architecture,
-or install with pip to select the appropriate wheel. It freezes the tuya2ildevice it was built with: a tuya2ildevice fix reaches manager users with the next
+or install with pip to select the appropriate wheel. It freezes the tuya-interpreter it was built with: a tuya-interpreter fix reaches manager users with the next
 rustuya-local release (bump the patch version and tag; the manager's catalog follows the release). Installed both ways
 (pip and the plugin directory), the plugin runs once.
 
@@ -171,7 +178,7 @@ rustuya-local release (bump the patch version and tag; the manager's catalog fol
 
 Everything here needs the sibling repos and, for the last two groups, `mosquitto`, `pyrustuya-bridge` and `tuyamock`
 (`pip install -e ".[test,fullstack]"`); those are skipped when missing. Parity with Home Assistant core's fixtures lives in
-`tuya2ildevice/tests/chain`, the wire and topic vectors in `ildevice/vectors`.
+`tuya-interpreter/tests/chain`, the wire and topic vectors in `ildevice/vectors`.
 
 - `tests/unit/`: the configuration.
 - `tests/e2e/test_service.py`: the service on in-memory brokers (overrides directory, a failed start).
@@ -181,7 +188,7 @@ Everything here needs the sibling repos and, for the last two groups, `mosquitto
 - `tests/ha/`: the integration (config flow, setup).
 - `tests/e2e/test_full_stack*.py`: the real rustuya-bridge (`pyrustuyabridge`, in process) and Tuya device emulators
   (`tuyamock`) around the daemon: state, commands, rejections, a device dropping off and returning, a daemon restart, and a
-  differential check that 38 real device shapes come out of the whole chain exactly as `tuya2ildevice` computes them.
+  differential check that 38 real device shapes come out of the whole chain exactly as `tuya-interpreter` computes them.
 
 ## Status
 

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/README.md

@@ -11,7 +11,7 @@ rustuya-bridge ──MQTT──► rustuya-local ──MQTT (il/…)──► il
                          BridgeClient + rustuya_local.host.Hub
 ```
 
-- **[tuya2ildevice](https://github.com/3735943886/tuya2ildevice)** is the only place that interprets Tuya: Home Assistant core's `tuya` behaviour and
+- **[tuya-interpreter](https://github.com/3735943886/tuya-interpreter)** is the only place that interprets Tuya: Home Assistant core's `tuya` behaviour and
   user overrides for non-standard devices, through its Sans-I/O Rust engine and Python wrapper.
 - **rustuya-local** is one `Service` (`src/rustuya_local/service.py`) and three thin shells that run it:
   the `rustuya-local run` daemon, the `custom_components/rustuya` Home Assistant integration, and a rustuya-manager
@@ -36,7 +36,7 @@ Stopping the daemon only marks it `offline`; its devices stay in IL (retained) f
 and run `rustuya-local purge --config config.json`: the retained descriptors, values and presence of its IL prefix and
 source are cleared (other sources on the prefix are left alone), so IL consumers drop the devices.
 
-## tuya2ildevice 0.4 host boundary
+## tuya-interpreter host boundary
 
 The shared Rust core interprets one device and has no MQTT or rule-file loading API.
 `rustuya_local.host.Hub` owns the device registry and maps `TuyaDriver` outputs to IL MQTT wire data;
@@ -70,20 +70,24 @@ everything on an external bridge, are left as they are.
 Tuya's cloud schemas are fragmented; fixes go in a `custom_converters/` directory (daemon: `custom_converters` in the
 config; integration: `<config>/rustuya_converters`; manager plugin: its data dir), followed live:
 
-- `*.json`: tuya2ildevice override blocks by product or device id: rename a dp, define one the schema lacks, map the
+- `*.json`: tuya-interpreter override blocks by product or device id: rename a dp, define one the schema lacks, map the
   device's words to the standard ones (`remap.alias`), fix labels and classes, define a declarative converter. A cover's
   direction is not set here but with its settings (below). Each file is a rule object with fixes under `overrides`, for example
   `{"overrides": {"product_id": {"cover": {"invert_position": true}}}}`.
 - Converters are JSON programs under `converters.declarative`; Python code plugins are not loaded.
 
-See tuya2ildevice's README ("User overrides") for the format. Official builtin rules, including `00-default.json`,
-ship with tuya2ildevice and update when that package is upgraded. They are applied before your own rule files.
+See tuya-interpreter's [device customization guide](https://github.com/3735943886/tuya-interpreter/blob/master/docs/device-customization.md#user-overrides) for the format. Official builtin rules, including `00-default.json`,
+ship with tuya-interpreter and update when that package is upgraded. They are applied before your own rule files.
 
-Online updates fetch the latest [builtin rules](https://github.com/3735943886/tuya2ildevice/tree/feat/rust-rule-engine/rules/builtin)
+Online updates fetch the latest [builtin rules](https://github.com/3735943886/tuya-interpreter/tree/master/rules/builtin)
 into `rules/builtin/` inside the overrides directory at start and daily. In the Rustuya panel, use *Update builtin rules*
-to fetch them now or *Automatically update builtin rules* to control automatic updates. The daemon uses `"pack": false`
-to disable online updates; the manager plugin has the same option in its settings. Installed builtin rules remain
-available when online updates are off. Updates only replace or remove files they downloaded, preserving user edits.
+to fetch them now or *Automatically update builtin rules* to control automatic updates. Opening the panel checks for
+updates: with automatic updates on, available changes are installed immediately without a yellow dot. With automatic
+updates off, available changes enable the manual update button with a yellow dot. The button is disabled while checking
+or when the installed rules are current. The daemon uses `"pack": false`
+to disable automatic updates; the manager plugin has the same option in its settings. Installed builtin rules remain
+available when automatic updates are off, and the panel still allows manual updates. Updates only replace or remove
+files they downloaded, preserving user edits.
 
 ### Cover settings
 
@@ -110,9 +114,12 @@ Older `cover.infer_motion` and `converters.cover_motion` blocks are upgraded on
 
 In Home Assistant the files can be edited from a sidebar panel: the integration's *Configure* → *Add the Rustuya
 panel to the sidebar* adds it and links to it. The panel is for administrators. It fetches the device list from Tuya Cloud, shows the
-bridge's devices against the cloud list as rustuya-manager does (missing, bridge only, mismatch, synced, each a filter you can
+bridge's devices using the running service's complete registry and MQTT connection against the cloud list (missing, bridge only, mismatch, online and offline, each a filter you can
 turn off; sub-devices under their gateway; each device's bridge connection, live while the panel is open) with add /
-update / remove. *Register manually* adds Wi-Fi devices or sub-devices without a cloud login, using the same
+update / remove. Online and offline split devices whose cloud and bridge records match; selecting both shows the
+previous synced view. Sub-devices use their own link state, falling back to their gateway when unavailable; an offline
+gateway makes its sub-devices offline. Unknown state is grouped under offline. A gateway stays visible for context
+when one of its children matches the filters. *Register manually* adds Wi-Fi devices or sub-devices without a cloud login, using the same
 fields as rustuya-manager. Devices absent from the cloud list appear under *Bridge only*; their removal is not
 preselected in bulk sync. The panel lists, edits and deletes user converter files (drop JSON rule files on it to copy them in),
 updates builtin rules on demand, and has the
@@ -125,7 +132,7 @@ language: Korean, or English.
 ## rustuya-manager plugin
 
 Installed next to rustuya-manager, as a pip package (`pip install rustuya-local` in the manager's environment) or as
-the drop-in zip each release carries (`rustuya_local-<version>-dropin.zip`, tuya2ildevice binding, native library and builtin rules vendored inside, built by
+the drop-in zip each release carries (`rustuya_local-<version>-dropin.zip`, tuya-interpreter binding, native library and builtin rules vendored inside, built by
 `scripts/build_dropin.py`; unpack it into the manager's plugin directory, or install it from the manager's plugin
 catalog once listed there), it appears as a **Tuya (IL)** tab and runs the service under the manager: the manager's broker and bridge root, the manager's device
 list (followed). Its data dir (`rustuya-local/` next to the manager's plugins) holds `settings.json` (`il`,
@@ -133,7 +140,7 @@ list (followed). Its data dir (`rustuya-local/` next to the manager's plugins) h
 converter files are picked up while it runs. A settings file it cannot use is shown on the tab until it is fixed.
 
 The drop-in zip includes native code for the platform on which it was built; use a matching OS and architecture,
-or install with pip to select the appropriate wheel. It freezes the tuya2ildevice it was built with: a tuya2ildevice fix reaches manager users with the next
+or install with pip to select the appropriate wheel. It freezes the tuya-interpreter it was built with: a tuya-interpreter fix reaches manager users with the next
 rustuya-local release (bump the patch version and tag; the manager's catalog follows the release). Installed both ways
 (pip and the plugin directory), the plugin runs once.
 
@@ -145,7 +152,7 @@ rustuya-local release (bump the patch version and tag; the manager's catalog fol
 
 Everything here needs the sibling repos and, for the last two groups, `mosquitto`, `pyrustuya-bridge` and `tuyamock`
 (`pip install -e ".[test,fullstack]"`); those are skipped when missing. Parity with Home Assistant core's fixtures lives in
-`tuya2ildevice/tests/chain`, the wire and topic vectors in `ildevice/vectors`.
+`tuya-interpreter/tests/chain`, the wire and topic vectors in `ildevice/vectors`.
 
 - `tests/unit/`: the configuration.
 - `tests/e2e/test_service.py`: the service on in-memory brokers (overrides directory, a failed start).
@@ -155,7 +162,7 @@ Everything here needs the sibling repos and, for the last two groups, `mosquitto
 - `tests/ha/`: the integration (config flow, setup).
 - `tests/e2e/test_full_stack*.py`: the real rustuya-bridge (`pyrustuyabridge`, in process) and Tuya device emulators
   (`tuyamock`) around the daemon: state, commands, rejections, a device dropping off and returning, a daemon restart, and a
-  differential check that 38 real device shapes come out of the whole chain exactly as `tuya2ildevice` computes them.
+  differential check that 38 real device shapes come out of the whole chain exactly as `tuya-interpreter` computes them.
 
 ## Status
 

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/custom_components/rustuya/bridge_supervisor.py

@@ -1,6 +1,6 @@
 """An embedded rustuya-bridge: `pyrustuyabridge.PyBridgeServer` run in a background thread, tied to this config
 entry's lifecycle instead of a separate rustuya-bridge process. Same class our own end-to-end tests drive
-(tuya2ildevice/rustuya-local tests/e2e/test_full_stack.py) — proven against a real broker and real Tuya-protocol
+(tuya-interpreter/rustuya-local tests/e2e/test_full_stack.py) — proven against a real broker and real Tuya-protocol
 devices, just supervised here instead of by a test fixture.
 
 The embedded bridge still needs a real MQTT broker to talk through (it manages its own native MQTT client); it does

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/custom_components/rustuya/const.py

@@ -28,7 +28,7 @@ CONF_DEVICES_PATH = "devices_path"              # tuyadevices.json; the cloud wi
 # --- entry options (changed any time through the options flow) -------------------------
 CONF_ALLOW_HAZARDOUS = "allow_hazardous"
 CONF_EXPOSE_UNUSED = "expose_unused"
-CONF_PACK = "pack"                          # sync tuya2ildevice's override pack into CONVERTERS_DIR
+CONF_PACK = "pack"                          # sync tuya-interpreter's override pack into CONVERTERS_DIR
 CONF_PANEL = "panel"                        # the sidebar page (panel.py); Configure adds / removes it
 
 DEFAULT_OPTIONS = {CONF_ALLOW_HAZARDOUS: False, CONF_EXPOSE_UNUSED: False, CONF_PACK: True}

rustuya_local-0.1.0.dev6/custom_components/rustuya/manager_registry.py

@@ -0,0 +1,71 @@
+"""Per-session compatibility guard for manager versions accepting incomplete status pages.
+
+The response topic is broadcast: the service and a short-lived Manager can receive each other's
+pages. Only a contiguous snapshot starting at zero may become the panel/config flow's registry.
+"""
+from __future__ import annotations
+
+import asyncio
+import time
+from typing import Any
+
+
+async def ready_registry(manager: Any, timeout: float) -> None:
+    client = getattr(manager, "client", None)
+    if client is None or not hasattr(client, "_handle_status_page"):
+        await manager.wait_ready()
+        return
+
+    request = client._request_status
+    handle = client._handle_status_page
+    offset = 0
+    total = None
+    ids: set[str] = set()
+    complete = False
+
+    async def request_status() -> None:
+        nonlocal offset, total, complete
+        if (not client._status_active or client._status_started is None
+                or time.monotonic() - client._status_started >= client._STATUS_CYCLE_TIMEOUT):
+            offset, total, complete = 0, None, False
+            ids.clear()
+            client._status_accum = None
+        await request()
+
+    async def handle_page(parsed: dict[str, Any]) -> None:
+        nonlocal offset, total, complete
+        if not client._status_active:
+            return
+        devices = parsed.get("devices")
+        start = parsed.get("offset", 0)
+        returned = parsed.get("returned", len(devices) if isinstance(devices, dict) else 0)
+        count = parsed.get("device_count")
+        more = parsed.get("has_more", False)
+        if (not isinstance(devices, dict) or type(start) is not int or start != offset
+                or type(returned) is not int or returned != len(devices)
+                or type(more) is not bool or (more and not returned)
+                or ids.intersection(devices)):
+            return
+        if count is not None and (type(count) is not int or count < start + returned
+                                  or more != (start + returned < count)):
+            return
+        if offset and count != total:
+            return
+        total = count
+        offset += returned
+        ids.update(devices)
+        complete = not more
+        await handle(parsed)
+
+    client._request_status = request_status
+    client._handle_status_page = handle_page
+    await client.wait_bootstrap(timeout=timeout)
+    if not client._bootstrap_done.is_set():
+        raise TimeoutError("bridge subscriptions are not ready")
+    # Bootstrap may have received pages before the guard was installed. Start a fresh
+    # offset-zero cycle after subscription readiness instead of trusting that snapshot.
+    client._status_started = None
+    await client._request_status()
+    await asyncio.wait_for(client._status_idle.wait(), timeout)
+    if not complete:
+        raise TimeoutError("incomplete bridge registry")

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/custom_components/rustuya/manager_session.py

@@ -68,7 +68,9 @@ async def open_manager(*, broker: str, root: str, devices_path: str, username: s
         # `sync()`'s diff is only meaningful once the bridge's device list has arrived; without this every cloud
         # device looks "missing" (an empty bridge side), which is how a whole device list ended up offered for
         # registration.
-        await manager.wait_ready()
+        from .manager_registry import ready_registry
+
+        await ready_registry(manager, WAIT)
     except BaseException:
         await close_manager(manager)
         raise
@@ -107,6 +109,26 @@ async def open_for_entry(hass: Any, data: dict[str, Any], *, run_bridge: bool =
                               devices_path=data[CONF_DEVICES_PATH], username=username, password=password, **bridge)
 
 
+async def open_panel_for_entry(hass: Any, data: dict[str, Any], service: Any):
+    """Share the loaded service's registry and command transport; no Manager MQTT connection."""
+    from .const import CONF_DEVICES_PATH
+    from .panel_bridge import PanelBridge
+
+    lock = _lock()
+    try:
+        await asyncio.wait_for(lock.acquire(), WAIT)
+    except TimeoutError as e:
+        raise Busy from e
+    session = PanelBridge(hass, service, data[CONF_DEVICES_PATH])
+    _HOLDERS[session] = lock
+    try:
+        await session.ready()
+    except BaseException:
+        await close_manager(session)
+        raise
+    return session
+
+
 async def saved_user_code(hass: Any, data: dict[str, Any]) -> str | None:
     """The user code of the saved Tuya login (`tuyacreds.json` beside the device file, where a session's wizard keeps
     it), read without a session: no broker connection and no lock, so the panel can fill it in before a fetch starts."""

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/custom_components/rustuya/manifest.json

@@ -9,12 +9,12 @@
   "iot_class": "local_push",
   "issue_tracker": "https://github.com/3735943886/rustuya-local/issues",
   "requirements": [
-    "tuya2ildevice>=0.4.0.dev4",
+    "tuya-interpreter>=0.1.0a1",
     "paho-mqtt>=2.0",
     "rustuya-manager>=0.2.2",
     "pyrustuyabridge>=0.4",
-    "rustuya-local>=0.1.0.dev4"
+    "rustuya-local>=0.1.0.dev6"
   ],
   "single_config_entry": true,
-  "version": "0.1.0.dev4"
+  "version": "0.1.0.dev6"
 }

{rustuya_local-0.1.0.dev4 → rustuya_local-0.1.0.dev6}/custom_components/rustuya/panel.py

@@ -349,11 +349,15 @@ async def _restart(hass: HomeAssistant, entry: Any, *, data: dict[str, Any] | No
 
 
 class PackView(_View):
-    """POST: sync the override pack now rather than at the end of its day; `pack` in the list shows the result."""
+    """GET checks for updates without writes; POST requests a sync."""
 
     url = "/api/rustuya/pack"
     name = "api:rustuya:pack"
 
+    @_entry_view
+    async def get(self, request: web.Request, entry: Any, runtime: Any) -> web.Response:
+        return self.json(await runtime.service.check_pack())
+
     @_entry_view
     async def post(self, request: web.Request, entry: Any, runtime: Any) -> web.Response:
         return self.json({"started": runtime.service.sync_pack_now()})
@@ -536,8 +540,8 @@ def _manual_device(body: Any) -> dict[str, str]:
 
 
 class BridgeView(_View):
-    """The cloud list against what the bridge holds, through a rustuya-manager session like the options flow's
-    `bridge_sync` step (and sharing its lock: one session at a time). GET: every device with its category. POST
+    """The cloud list against the running service's complete bridge registry, sharing the management session lock.
+    GET: every device with its category. POST
     `{"add": [...], "update": [...], "remove": [...]}`: those commands (only for ids the diff has in that category),
     then the list again. PATCH edits an existing device; PUT registers a manual device (id/name, WiFi key/ip/version or SubDevice cid/parent_id).
     `online` is the running service's link state by id."""
@@ -592,7 +596,7 @@ class BridgeView(_View):
         if not manager_session.available():
             return self.json_message("rustuya-manager is not installed", HTTPStatus.NOT_IMPLEMENTED)
         try:
-            manager = await manager_session.open_for_entry(request.app["hass"], entry.data)
+            manager = await manager_session.open_panel_for_entry(request.app["hass"], entry.data, runtime.service)
         except manager_session.Busy:
             return self.json_message("a Tuya login or device sync window is open; close it and try again",
                                      HTTPStatus.CONFLICT)

rustuya_local-0.1.0.dev6/custom_components/rustuya/panel_bridge.py

@@ -0,0 +1,48 @@
+"""Panel device management through the running service, without another MQTT registry requester."""
+from __future__ import annotations
+
+import json
+from pathlib import Path
+from types import SimpleNamespace
+from typing import Any
+
+
+class PanelBridge:
+    def __init__(self, hass: Any, service: Any, devices_path: str) -> None:
+        self.hass = hass
+        self.client = getattr(service, "bridge_client", None)
+        self.path = Path(devices_path)
+        self.state = SimpleNamespace(cloud={}, bridge={})
+
+    async def ready(self) -> None:
+        if self.client is None:
+            raise RuntimeError("Rustuya service is not ready")
+        await self.sync()
+
+    async def sync(self):
+        from rustuya_manager.diff import diff
+        from rustuya_manager.models import Device
+
+        def cloud():
+            if not self.path.exists():
+                return {}
+            data = json.loads(self.path.read_text("utf-8"))
+            records = data if isinstance(data, list) else data.values()
+            return {d["id"]: Device.from_dict(d) for d in records if "id" in d}
+
+        self.state.cloud = await self.hass.async_add_executor_job(cloud)
+        records = await self.client.registry()
+        self.state.bridge = {id: Device.from_dict({**record, "id": id}) for id, record in records.items()}
+        return diff(self.state.cloud, self.state.bridge)
+
+    async def publish_command(self, action: str, **kw) -> None:
+        await self.client.publish_command(action, **kw)
+
+    async def remove_device(self, target_id: str) -> None:
+        await self.publish_command("remove", target_id=target_id)
+
+    async def wait_registry_refresh(self) -> None:
+        await self.client.registry(refresh=True)
+
+    async def __aexit__(self, *exc) -> None:
+        pass