From afc3326fc3fe5975c3b255f82b5da1f060a920dd Mon Sep 17 00:00:00 2001 From: engineer Date: Mon, 12 Oct 2026 08:23:29 +0100 Subject: [PATCH] docs(discovery): precise wording on the watchdog, the empty state, recovery MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three comments this repair touches were still loose: "never rebuilt on a state poll" (the discovery table, not the watchdog — the sensor's own poll does refresh it when it has no fresh answer), and the class docstring's "recorded as unknown" now says where a reader actually sees it, since the sensor reports not_connected while the transport is down and unknown once it is up but the sweep delivered nothing. --- custom_components/nvidia_shield/connection.py | 2 +- custom_components/nvidia_shield/sensor.py | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/custom_components/nvidia_shield/connection.py b/custom_components/nvidia_shield/connection.py index 5c46702..266cea0 100644 --- a/custom_components/nvidia_shield/connection.py +++ b/custom_components/nvidia_shield/connection.py @@ -229,7 +229,7 @@ class ShieldConnectionManager: # here (t62 F1): a failed or unavailable sweep records itself as UNKNOWN # instead, because stamping an empty answer would serve "0 apps" — and # block every retry — for the whole APP_LIST_TTL. Refreshed on demand; - # never rebuilt on a state poll. + # the watchdog cycle never rebuilds it. self._installed_apps: tuple[list[dict], float] | None = None # t62 F1: True when the last sweep could not deliver an answer (no # poller, ADB down, a shell that raised or answered nothing) — so an diff --git a/custom_components/nvidia_shield/sensor.py b/custom_components/nvidia_shield/sensor.py index 9c046da..f69ce70 100644 --- a/custom_components/nvidia_shield/sensor.py +++ b/custom_components/nvidia_shield/sensor.py @@ -168,8 +168,9 @@ class NvidiaShieldAppsSensor(NvidiaShieldSensorBase): runs once when the entity is added and then only when the table has gone stale: ``async_update`` goes through the manager's TTL cache, so a poll on a fresh table issues NO shell. A sweep that could not run is NOT an answer - (t62 F1): it is recorded as ``unknown`` and retried on the next update - instead of being frozen as a stamped-empty table for APP_LIST_TTL, while a + (t62 F1): it is recorded as ``unknown`` — or shown as ``not_connected`` + while the transport itself is down — and retried on the next update instead + of being frozen as a stamped-empty table for APP_LIST_TTL, while a sweep that ran and found nothing IS the answer ``ok`` with a count of 0. On top of that the user can ask for a refresh with the standard ``homeassistant.update_entity`` action, and the Configure page runs the same