Wizard/auto-config finds SE4 despite SE3 selected in official Nordpool integration

[johanzander]

This issue was supposed to be fixed here:
#85
but user reports it is still an issue.

See attached logs:

bess-debug-2026-05-04-111931.md

Version 8.4.2

[bess-manager-claude-bot]

The report suggests the wizard/auto-config is selecting the wrong Nordpool price region (SE4 instead of SE3) in version 8.4.2, despite a prior fix attempt in PR #85. Debug log received.

Reply @claude-bot analyze to start deep code-level analysis.

[johanzander]

@claude-bot analyze

[bess-manager-claude-bot]

Root cause

discover_ha_metadata successfully finds the nordpool config entry and extracts its entry_id, but fails to extract the price area. The function looks for the area under entry["options"]["area"] or entry["data"]["area"] (one key name each). However, the debug log proves the config_entry_id was correctly stored (health check shows 01KQ7GQNJG9XBDDBJYSH90JCDY) while the area stayed SE4. The only code path that stores config_entry_id is apply_discovered, which requires nordpool_config_entry_id to be non-null — so discovery succeeded in finding the entry, but raw_area was falsy, leaving nordpool_area = None. Because apply_discovered has a if nordpool_area: guard (line 149), the area is never written and the SE4 bootstrap default persists. The entity-based detection branch (for the HACS legacy integration) defensively tries four attribute keys — price_area, area, deliveryArea, delivery_area — but the config-entry branch added by PR #85 only checks one (area). If the official HA nordpool integration stores the area under a different key name, or if the WebSocket config_entries/get command omits the data field for security reasons, the area lookup returns None and the bug reproduces identically.

Evidence

• core/bess/ha_api_controller.py:1446–1451 — entry_id is extracted (confirming discovery succeeds), but area extraction only checks one key name:

nordpool_config_entry_id = entry["entry_id"]
raw_area = entry.get("options", {}).get("area") or entry.get(
    "data", {}
).get("area")
if raw_area:
    nordpool_area = str(raw_area).upper()

• core/bess/ha_api_controller.py:1573–1578 — the entity-based path (for HACS integration) correctly tries four attribute variants; the config-entry path is missing these alternatives:

area = (
    attrs.get("price_area")
    or attrs.get("area")
    or attrs.get("deliveryArea")
    or attrs.get("delivery_area")
)

• backend/settings_store.py:149 — area is silently skipped when nordpool_area is None:

if nordpool_area:
    ...
    if not price.get("area") or price.get("area") == DEFAULT_AREA:
        price["area"] = nordpool_area

• backend/settings_store.py:313 — bootstrap writes SE4 on first boot, never corrected if area detection yields None:

"area": DEFAULT_AREA,

• Debug log: Health check reports config_entry_id = 01KQ7GQNJG9XBDDBJYSH90JCDY (proving apply_discovered was called with a non-null config entry ID), while electricity_price.area = "SE4" (proving nordpool_area was None at that call).

Proposed fix

1. In discover_ha_metadata (line 1447): extend the area key lookup to mirror the entity-based detection, adding price_area and currency_to_show as fallbacks alongside the existing area key. This is a one-liner expansion of the or chain.
2. Add a debug log line immediately after extracting the config entry, logging entry.get("options", {}).keys() and entry.get("data", {}).keys() (not the values, which could be sensitive). This would have confirmed the bug immediately from the user's debug export.
3. In the wizard response from run_setup_discovery: if nordpool_config_entry_id is set but nordpool_area is still None, include an explicit "nordpoolAreaUndetected": true flag so the frontend can prompt the user to confirm the area manually rather than silently inheriting SE4.

Risks / open questions

• The exact key name used by the official HA nordpool integration in its config entry is unconfirmed without a live HA instance running the official (core) integration. It could be area, price_area, or something else introduced in a recent HA release. The unit tests added by PR Fix #78: nordpool_official area locked to SE4 bootstrap default #85 mock the WebSocket with {"options": {"area": "SE3"}} — they pass regardless of what the real HA integration actually sends, so they cannot catch this discrepancy.
• There is a secondary risk: if the HA config_entries/get WebSocket command omits the data dict for security (some HA versions do this), no key in data is reachable and the fix must rely on options alone.
• The apply_discovered guard at settings_store.py:155 (if not price.get("area") or price.get("area") == DEFAULT_AREA) correctly allows overwriting SE4 once a valid area is detected — this part of the PR Fix #78: nordpool_official area locked to SE4 bootstrap default #85 fix is sound and does not need to change.

---

Reply @claude-bot fix to implement and open a draft PR.