0.9.7-rc2: a strategy-generated dashboard blocks the panel behind an on-screen prompt after upgrade

Upgrading a panel from 0.9.6 to 0.9.7-rc2 left it on the "Entity filter needs attention" screen with no dashboard for 2.75 days, until I answered the prompt through the API. The panel is a Sonoff NSPanel Pro 120P, firmware 3.8.0, Android 8.1, built-in renderer, home_dashboard unset (follow the account default).

The blocking issue from GET /api/v1/dashboard/entities/issues:

{
  "type": "unbounded_selector",
  "severity": "error",
  "blocking": true,
  "would_block": true,
  "rule_summary": "Dashboard strategy generates entity dependencies at runtime",
  "reason": "The selector has no structural bound that can be converted into a safe subscription set.",
  "recommendation": "Add an explicit entity ID, entity pattern, domain, area, floor, or label constraint.",
  "source_locations": ["dashboard.strategy"],
  "view_path": "dashboard"
}

While held, the bootstrap watchdog resynced the whole entity catalog every 5 minutes without ever making progress — 794 times:

08-29 11:28:46.495 W/ha-paneld/dashboard: entity bootstrap held 237616126ms — watchdog resync 794, next in 300000ms

Why I think this is broader than my panel. The selector it cannot bound is a dashboard strategy, and a strategy-generated dashboard is what Home Assistant serves by default. Any panel whose home dashboard follows the account default lands on this screen on upgrade. On my fleet that is all 16.

The recovery path is the problem as much as the block itself. The three offered choices all need a hand on the glass, and a wall panel that is mounted, unattended and set to self-update goes dark and stays dark until someone walks up to it. POST /api/v1/dashboard/entities/issues {"fingerprint":"...","ignored":true} cleared it remotely and the filter then applied normally at 347 entities out of 3055, so the filtering itself works fine on this dashboard once it is allowed to proceed — the safety check is refusing a case it could handle.

Suggestions, in the order I would want them:

Don't hold the dashboard indefinitely on an unbounded selector. Open it unfiltered with the warning surfaced, or auto-ignore after a bounded number of failed verifications, so a panel converges on its own.
Treat dashboard.strategy as a known bounded-unknown rather than an error, given it is the default dashboard shape.
Whatever the decision, the watchdog should stop resyncing a catalog that is blocked on a human answer. 794 full resyncs is a lot of write traffic for a state that cannot change on its own.

Happy to test a build on the same panel — it reproduces on every upgrade of a panel with a default dashboard, and I have 15 more that have not been upgraded yet.

This is a release blocker. A panel which was working before an upgrade must not disappear behind a prompt indefinitely, particularly when the decision can only be made on the panel itself.

The strategy-generated dashboard is one problem; the 794 full catalogue retries while the panel waited for a person are another. Please do not update the other panels yet. I am investigating both before the next release candidate, and your offer to test the result on this fleet will be useful.

rc3 is out, and it changes how this recovers. An account-default dashboard can now resume its previous entity filter after an update, but only while the whole catalogue that filter referenced is still valid. If anything in it has changed, you still get the safety question rather than a silent guess.

So upgrade one panel first rather than the whole set. If it comes back to its dashboard without stopping at the prompt, the rest should follow. If it still stops, send me the diagnostic dump from that panel, because then something is invalidating the catalogue that I have not reproduced.

Sorry for leaving you frozen this long.

0.9.7 final self-updated my 16 panels on 2026-09-14. 15 of them came up on the "Entity filter needs attention" hold; only the one that already had the strategy issue ignored from rc2 did not. They stayed dark for ~27 h until I answered: two at the panel, 13 through the API. So the rc3 upgrade recovery didn't cover this fleet; my guess is there was no retained filter for it to restore.

The resync loop is fixed. A held panel now logs an hourly "dashboard change probe" instead of resyncing the catalogue.

The hold was also right about something. After ignoring it, the Areas dashboard renders with controls missing. cover.window_primary, cover.window_kyra, cover.window_hannah and 7 other covers never entered the filter. The strategy only draws what the panel receives, so those tiles never render and runtime learning never sees them. The unfiltered panel shows them. Ignoring the check silently loses controls on a strategy dashboard, and nothing on the panel says so.

Diagnostic dump from one of the held panels (captured while held)

ha-paneld diagnostics — 0.9.7 (build 776)
[captured] 2026-09-15T09:26:57.159-06:00 uptime=2d0h

[panel]
ha-paneld=0.9.7 (build 776)
Android=8.1.0 (API 27)
Firmware=3.8.0
Device=rockchip px30_evb (px30_evb)
CPU=4 cores · arm64-v8a · rk30board
RAM=1.9 GB total · 1.3 GB free
Storage=7.8 GB eMMC · 2.1 GB free (data)
Display=750×1334 px · logical 320 dpi
System WebView=com.android.webview 138.0.7204.63
HA Companion=not installed
MQTT state=connected · TCP/IPv4 · last-ok 35s ago · last-auth 56296s ago · auth-ok · family Automatic (next IPv4)
Security mode=Relaxed
Keep panel responsive=on · power locks held
Prevent idle dim=on · timeout never
Android dashboard lock=off
LED=none
Nav actions (a11y)=yes
Navbar=Swipe reveal
Zigbee=vendor-native · running · Repeater
Relays=none
Network ADB=active (5555) · external — not persisted by ha-paneld
Audio playback=idle
App database=52.0 MB used · 52.6 MB on disk · schema 14
Product version=NSPanel120P_3.8.0
Local-state sync=215s ago · brightness 202→206 · 575s ago · brightness 198→202 · 815s ago · brightness 194→198 · 1055s ago · brightness 190→194 · 1295s ago · brightness 186→190 · 1535s ago · backlight →186 (firmware dim) · 1655s ago · brightness 179→183 · 1835s ago · brightness 172→179
State convergence=43 channels · 0 dirty · 0 in-flight · 15 unknown · ack 979/2 · pending none

[build] fingerprint=rockchip/px30_evb/px30_evb:8.1.0/OPM8.190605.003/092718:userdebug/test-keys
board=rk30sdk product=px30_evb hardware=rk30board abis=arm64-v8a,armeabi-v7a,armeabi
[boot-security] verified=green flash=locked vbmeta=unknown build=userdebug debuggable=yes
[env] selinux=0 su=true write_settings=true a11y=true daemon=true shizuku=manager_missing evdev=stopped/none ledjni=false
[display-sizing] android_base_logical_dpi=240 current_logical_dpi=320 override_dpi=320 font_scale=1.0 profile_recommended_dpi=250 profile_recommended_font_scale=1.0
[renderer] mode=builtin state=unobserved outcome=unobserved fault=none detail=none recovery=none transport=http address_family=automatic observed_age=never process_age=1d0h package_updated=1d0h theme=follow/unobserved
[ha-network] state=idle measuring=false
[ha-path-probe] state=unowned
[camera] state=absent outcome=camera-unavailable fault=none detail=not_enumerated recovery=none clients=0 last_frame=never failures=0 indication=none stream_clients=0 stream_port=off encoder=none encode=none delivered=none requested_fps=none
[zigbee-health] state=unknown layout=unknown package=- joined=true role=Repeater gateway_cpu=4 guard_cpu=0 restarts_10m=0 containment=none recursive_watchdog=false
[storage-health] state=healthy pressure_state=healthy usable_bytes=2090631168 total_bytes=3606069248 used_percent=42.02465276673467 database_bytes=54558720 wal_bytes=524288 sidecar_bytes=98304 page_size_bytes=4096 page_count=13320 freelist_count=3 schema_version=14 quick_check=ok auto_vacuum=incremental checked_at=1789484881642 failure=none failure_operation=none
[power-safety] state=safe keep_awake=true wake_lock=true wifi_lock_required=true wifi_lock=true prevent_idle_dim=true screen_timeout_ms=2147483647 interactive=true power_source=ac plugged_mask=1 stay_on_mask=15 stay_on_effective=true device_idle=false doze_exempt=true screen_off=su_blpower screen_off_selected=unknown screen_off_reason="not yet exercised; no screen-off has occurred since this controller was constructed" reasons=none
[sysfs] leds=[] backlight=[backlight] devfreq=[dmc, ff400000.gpu]
[labels] ls: /sys/class/leds/*/: No such file or directory ls: /dev/ledjni: No such file or directory u:object_r:sysfs:s0 /sys/class/backlight/backlight/
[hardware]
  inputs=[rk8xx_pwrkey (event0 cpufreq dmcfreq keychord ), chsc_cap_touch (event1 cpufreq dmcfreq ), adc-keys (event2 cpufreq dmcfreq keychord ), gpio_keys (event3 cpufreq dmcfreq ), lightsensor-level (event4 ), proximity (event5 )]
  i2c=[0-0020:rk809, 1-002e:chsc_cap_touch, 1-003c:tp, 2-0046:ls_stk3a5x, 2-0046-1:ps_stk3a5x, 5-0038:px30-aht20, i2c-0:rk3x-i2c, i2c-1:rk3x-i2c, i2c-2:rk3x-i2c, i2c-5:gpio_i2c@3]
  iio=[]
  thermal=[cooling_device0:thermal-cpufreq-0, cooling_device1:thermal-devfreq-0, cooling_device2:thermal-devfreq-1, thermal_zone0:soc-thermal, thermal_zone1:gpu-thermal]
  relays=[st_relay/mode, st_relay/relay1, st_relay/relay2, st_relay/relay3, st_relay/relay4]
[packages] android=not installed minimal=not installed
[vendor-tame] known=7 installed=7 active=0 disabled=7
[capabilities] Root (su)=ok | Verified app update / screenshot / display=ok | Screen brightness=ok | Screen on/off=ok | Reboot / reload / launcher=ok

Fixed in 0.9.7.

Your third point is implemented as written: a scan waiting only on a decision no longer resyncs. It polls for an actual dashboard change on a widening 5-minute-to-hourly interval instead.

Your first is handled on the upgrade path. A panel following the account default now restores the filter it was already running, so it comes back unattended. Only if the complete previous set is still valid; otherwise it keeps asking rather than silently showing you less.

I did not take the second. On a dashboard that has never been scanned there is no evidence to fall back on and the derived set can legitimately be empty, so the hold is all that stands between that and a blank screen. The automatic path is therefore limited to panels that had already accepted a filter.

I could reproduce your hold here but not the automatic recovery, since my own default dashboards are not strategy-generated. If you upgrade one of the panels still on 0.9.6 and it returns without prompting, that confirms the last piece.

No panel left to test that on — the whole fleet self-updated straight to 0.9.7 final on 2026-09-14, so there's no 0.9.6 survivor to run the one-panel upgrade test against. Would a deliberate downgrade-then-upgrade be a valid test, or does the recovery path only matter on the next release from here? Happy to try either once I know what data it'd need to leave behind.

On point 2/"second" — to be clear, I wasn't asking for automatic recovery on a never-scanned dashboard. The ask was narrower: when Ignore is chosen on a strategy dashboard, entities missing from the filter silently never render, and the panel gives no indication that's happening. That part's still open regardless of the upgrade-recovery work. Right now I'm mitigating it by hand-pinning the 10 affected covers on every panel; that's fine as a workaround but it's a silent-data-loss trap for anyone who doesn't know to check against an unfiltered panel.

No need to downgrade. The upgrade recovery runs on the next update from here, so that update is the real test. If a panel comes back to its dashboard without stopping at the prompt, that confirms it; if it stops, a /diag from that panel is what I need.

You are right about Ignore, and the next prerelease makes it visible. When a strategy dashboard runs with that check ignored, the Configure page says some dashboard cards may be missing, and the Entities page explains why and how to pin what is missing. It cannot name the missing entities itself: the strategy never asks for anything the filter leaves out, so the panel never sees their names. Comparing against the same dashboard on another device, as you did, is still how to find them.

feat: say when a strategy dashboard runs with its entity check allowed (

0.9.8 is out with the Ignore notice: on a strategy dashboard with that check ignored, Configure says some dashboard cards may be missing, and the Entities page explains why and how to pin them.

This update is also the real test of the upgrade recovery. If any panel stops at the entity filter prompt after updating, reopen this with a /diag from that panel. Otherwise I think we are done here, so I am closing it.

feat: say when a strategy dashboard runs with its entity check allowed (

Navigation Menu

0.9.7-rc2: a strategy-generated dashboard blocks the panel behind an on-screen prompt after upgrade #133

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

0.9.7-rc2: a strategy-generated dashboard blocks the panel behind an on-screen prompt after upgrade #133

Description

Activity

maxlyth commented on Aug 30, 2026

maxlyth commented on Sep 9, 2026

cb2206 commented on Sep 15, 2026

maxlyth commented on Sep 21, 2026

cb2206 commented on Sep 21, 2026

maxlyth commented on Sep 26, 2026

maxlyth commented on Sep 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions