Zendure-HA: Board

Review: #1694 last_states-Befund auf v2 unabhängig prüfen

tsk-3k5a8n9bdq1f review zendure-coder (zendure-coder)

Independent review of one finding before it goes to Wolfgang. Keep it short and cheap (reasoning high), read-only, nothing on GitHub.

Claim: On Zendure/Zendure-HA branch v2 (HEAD 34042ac), custom_components/zendure_ha/migration.py:81 reads rs.async_get(hass).last_states (used at line 96). Home Assistant core removed RestoreStateData.last_states in 2026.11 (core PR #183906, beta 2026.11.0b0 to b3), so the 1.x→v2 migration raises AttributeError on HA 2026.11. Issue #1694 (filed by an HA core dev) asks for async_get_stored_state(entity_id), which exists only from 2026.11.0b0 on. v2's floor is homeassistant>=2026.4.3, so a fix must support both APIs.

Proposed fix (3 lines):

restore = rs.async_get(hass)
self.stored_state = restore.async_get_stored_state if hasattr(restore, "async_get_stored_state") else restore.last_states.get  # HA 2026.11 dropped last_states
# line 96: stored := self.stored_state(e.entity_id)

Please check, and say confirmed or refuted for each:

  1. last_states absent and async_get_stored_state present in homeassistant/helpers/restore_state.py at tag 2026.11.0b3; last_states present at 2026.10.4 (gh api repos/home-assistant/core/contents/homeassistant/helpers/restore_state.py?ref=<tag>).
  2. Is migration.py:81 really on a path every 1.x→v2 migration hits? Trace from __init__.py async_migrate_entry.
  3. Does async_get_stored_state keep the semantics the migration needs? Read lines 160–250 at b3: it is keyed by entity_id with a registry-id fallback. Also: is the restore data loaded at the moment migration runs (before hass_start)?
  4. Any other v2 use of last_states or of other private restore-state internals: git grep -n "last_states\|restore_state\|RestoreStateData" origin/v2 -- custom_components.

Reply with maity say <me> --type review_result or as a notice, 10 lines max.