From 14c168c25e6f103e482a7fe8cf38024cf20267e9 Mon Sep 17 00:00:00 2001 From: James Mackay Date: Mon, 12 Oct 2026 12:15:58 +0100 Subject: [PATCH] feat(remote): the app/activity picker, and a protocol transport that really connects (t15) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The user's remote displayed but offered no app picker, and the protocol transport was never actually switched on. Both halves are fixed here. REMOTE PARITY. The entity declares RemoteEntityFeature.ACTIVITY — exactly what core's androidtv_remote declares — and publishes activity_list, which is what makes the frontend render an activity picker at all. The list is the app directory (the user's apps map, else the curated table as a floor) in map order, then the apps ADB discovery found and something can name, in the one name chain (user map > device label > curated > package id). Nothing nameless is listed as a bare package id, and current_activity is None until something is known: no activity is invented. remote.turn_on honours activity= by waking the device when it reports itself off and then launching through the existing launch path; a listed name resolves case-insensitively, a package id or a detail link passes through, and anything else raises unknown_activity naming the value instead of silently doing nothing. An empty/absent activity keeps the previous behaviour exactly, async_turn_off is untouched, and a configured command script still owns the sequence. WHY THE TRANSPORT WAS DEAD, MEASURED. androidtvremote2's keep_reconnecting only starts _async_reconnect, whose whole body is `while self._remote_message_protocol:` — false on the first check with nothing connected, so the task returned immediately: no connect attempt, no retry, and the auth callback was never reachable. HA core connects FIRST and only then keeps it alive. Our _start_protocol called keep_reconnecting after generating a certificate and never called async_connect anywhere, so every send_key_command/send_launch_app_command raised ConnectionClosed internally, the helpers swallowed it into `return False` plus a debug line, and no push (is_available/is_on/current_app/volume_info) ever arrived. The fix is a background connect loop: async_connect under a bounded timeout, network failures retried with the ADB watchdog's jitter and backoff, InvalidAuth routed into the EXISTING reauth callback (entry.async_start_reauth), and keep_reconnecting only after a session is up. Setup never blocks on a transport. A send that cannot run is no longer silent: it is counted, its error recorded verbatim, and logged at WARNING with the transport state, and the remote publishes protocol_state / protocol_connected / protocol_ever_authenticated / protocol_last_error / protocol_failures / protocol_certificate plus sticky per-push *_seen flags — so "sent" and "never switched on" can never look alike again. CASE (b) IS FIXED, NOT DOCUMENTED: switching the transport on in the options flow for an entry that never paired now routes into the real async_step_protocol_pair, and "continue without pairing" persists the transport OFF. One marker carries the pairing (CONF_PROTOCOL_PAIRED), written by the setup pairing step, the reauth finisher and the reconfigure finisher, so no entry can sit enabled-but-unpaired. The certificate from the first pairing is reused by design, so a paired entry is asked for no new PIN — which is also why the marker, not certificate material, is the source of truth. ADB STAYS THE PRIMARY STATE SOURCE. Arming the protocol introduces pushes that were never live before, so the reading now names its tier: manager.foreground_source drives the media player's app_source and the remote's activity_source, and the new tests prove a full protocol push set leaves the media state, the now-playing reading and every ADB store field untouched, while an ADB-only entry still serves media player, sensors, apps, scripts and receiver with only the protocol surface degraded. Copy: unknown_activity, activity_launch_failed and protocol_unavailable in BOTH strings.json and translations/en.json, pinned by a test; the README documents the picker, activity resolution, how to read the transport-state attributes, the script bypass (a script-routed press is never evidence of pairing), the connect-then-keep-alive lifecycle and cert reuse versus the other integration's own pairing. Evidence: 6 new real-HA FlowManager tests in tests/test_config_flow_real_ha.py (unpaired -> pairs, PIN -> marker, skip -> off, paired -> not asked again, and the setup flow's marker on success and on skip), a real-HA entity contract test in tests/test_ha_api_drift.py (exact supported_features equality with core, activity_list/current_activity reaching the state machine, live _attr_ updates) and new suites in tests/test_protocol_transport.py (connect-first, keep_reconnecting alone is a no-op, retry, auth rejection, honest send failures, ADB-primary precedence) and tests/test_command_routing.py (the activity contract, turn_on(activity=), script ownership, the transport attribute states). No device and no browser exist here: device behaviour is inferred from the library and core source, and every UI-facing claim is proven at the entity/registry/metadata level under real Home Assistant. Verify: suites 719/4 and 720/3; real-HA glob (tests/test_adb_command_real_ha.py + tests/test_config_flow_real_ha.py) 56 passed, 0 skipped; ruff clean; drift exit 0 (25 modules, 76 imports, 206 relative imports, 1322 statement blocks, 57 call arguments) with the floors raised 40->70, 100->195, 500->1300 and 52->55. --- README.md | 91 ++++ .../nvidia_shield/config_flow.py | 247 +++++++++-- custom_components/nvidia_shield/connection.py | 249 ++++++++++- custom_components/nvidia_shield/const.py | 25 ++ .../nvidia_shield/media_player.py | 144 +++++-- custom_components/nvidia_shield/remote.py | 331 ++++++++++++++- custom_components/nvidia_shield/strings.json | 12 + .../nvidia_shield/translations/en.json | 12 + tests/entity_stublib.py | 41 ++ tests/ha_api_drift.py | 24 +- tests/test_command_routing.py | 382 ++++++++++++++++- tests/test_config_flow_real_ha.py | 223 ++++++++++ tests/test_ha_api_drift.py | 62 ++- tests/test_protocol_transport.py | 394 +++++++++++++++++- 14 files changed, 2101 insertions(+), 136 deletions(-) diff --git a/README.md b/README.md index 4cb6e55..27fa24c 100644 --- a/README.md +++ b/README.md @@ -419,6 +419,14 @@ already submitted. The two pairing rows appear only while that transport still n pairing (a skip leaves its row there to retry; a successful pairing removes it), and the menu's description names what is still to pair. +Turning **Add the Nvidia Remote Protocol** on in the **Main setup** row of the +*options* page does not silently enable a client that cannot connect: an entry that has +never completed a pairing is taken to the same **Pair the remote protocol** step, and +its **Continue without pairing** escape turns the option back off. Pairing is remembered +per entry, so switching the transport off and on again on a paired entry asks for no new +PIN (the certificate from the first pairing is reused — see +[is my transport paired?](#is-my-protocol-transport-paired-connected-or-not-running-at-all)). + ### The Apps table The **Apps** row opens a small editor rather than one long form. Home Assistant has no @@ -767,6 +775,88 @@ All four variables are always present, including their defaults, so a script can on the shape. Unset — the default — nothing changes: keys go out over the protocol exactly as before. +### The remote entity: the app / activity picker + +The `remote` entity speaks Home Assistant's own remote contract, matching the +`androidtv_remote` entity it replaces — so a replaced setup keeps its automations +**and** gets the app picker the frontend only renders for a remote that declares it: + +| Piece | Value | +| --- | --- | +| `supported_features` | includes `RemoteEntityFeature.ACTIVITY` — without that flag Home Assistant offers **no activity picker at all**, which is why the remote card can look empty | +| `activity_list` | the friendly app names, in your order: your **Apps table** (or the built-in table when you have none), plus the apps **ADB discovery** actually found on the device | +| `current_activity` | the app on screen as a friendly name: the protocol's current-app push when it arrives, the ADB foreground reading otherwise. `None` while nothing is known — no activity is ever invented | +| `turn_on` with `activity:` | wakes the Shield when it reports itself off, then launches that app over the protocol | + +```yaml +# launch Netflix by the name from the activity list / Apps table +action: remote.turn_on +target: + entity_id: remote.living_room +data: + activity: Netflix +``` + +An `activity` resolves in this order: a **name** from the activity list +(case-insensitive), then a **package id** or a **detail link** (`https://…`, +`market://…`) passed through unchanged — that is how an app your table does not carry +is still launchable, and what the other integration does with a name it does not know. +Anything else raises a clear error naming the value instead of silently doing nothing. +Leaving `activity` out (or empty) keeps the old behaviour exactly: wake through the +configured script, else `POWER` when the device reports it is off. + +**Where the list comes from, and why.** `androidtvremote2` exposes **no app-list API +at all** (measured against the installed library) — which is exactly why +`androidtv_remote` keeps a user-maintained app map. This integration has the same kind +of source *plus* something the other one lacks: ADB discovery, so the picker can offer +what is actually installed and name it through the one chain (your Apps table → the +device's own label → the built-in table → the package id). Apps nothing can name are +not listed as bare package ids; pass their id to `activity` if you need them. + +#### Is my protocol transport paired, connected, or not running at all? + +The library offers no `is_paired` / `is_connected`, so the remote entity publishes what +can be **proven** (Developer Tools > States, or +`state_attr('remote.living_room', 'protocol_state')`): + +| Attribute | Meaning | +| --- | --- | +| `protocol_state` | `off` (no transport configured), `never_connected`, `connected`, `disconnected`, or `auth_rejected` | +| `protocol_connected` | `true` only while the device reports the protocol session up | +| `protocol_ever_authenticated` | `true` once a session connected **or any push arrived** — the only proof of a paired client the library gives | +| `protocol_current_app_seen` / `protocol_is_on_seen` / `protocol_volume_seen` | whether each device push has **ever** arrived (sticky: the state cache expires, these do not) | +| `protocol_last_error` / `protocol_failures` | the last protocol connect/send failure verbatim, and how many sends could **not** run | +| `protocol_certificate` | `present` / `missing` — the certificate from your setup pairing, which is why enabling the transport on a paired entry asks for **no new PIN** | +| `power_on_route` / `power_off_route` | `protocol`, or `script: