docs(discovery): precise wording on the watchdog, the empty state, recovery

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.
This commit is contained in:
engineer committed 2026-10-12 08:23:29 +01:00
1 parent 1c414c2f70
commit afc3326fc3
2 files changed
+4 -3

No files matched your search

@@ -229,7 +229,7 @@ class ShieldConnectionManager:
# here (t62 F1): a failed or unavailable sweep records itself as UNKNOWN # here (t62 F1): a failed or unavailable sweep records itself as UNKNOWN
# instead, because stamping an empty answer would serve "0 apps" — and # instead, because stamping an empty answer would serve "0 apps" — and
# block every retry — for the whole APP_LIST_TTL. Refreshed on demand; # 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 self._installed_apps: tuple[list[dict], float] | None = None
# t62 F1: True when the last sweep could not deliver an answer (no # 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 # poller, ADB down, a shell that raised or answered nothing) — so an
+3 -2
View File
@@ -168,8 +168,9 @@ class NvidiaShieldAppsSensor(NvidiaShieldSensorBase):
runs once when the entity is added and then only when the table has gone 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 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 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 (t62 F1): it is recorded as ``unknown`` — or shown as ``not_connected``
instead of being frozen as a stamped-empty table for APP_LIST_TTL, while a 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 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 top of that the user can ask for a refresh with the standard
``homeassistant.update_entity`` action, and the Configure page runs the same ``homeassistant.update_entity`` action, and the Configure page runs the same