feat(heishamon): report electrical power, and the outdoor temperature under its canonical name

[frahlg]

Based on #59 — merge that first. Answers the driver-visibility half of srcfl/ftw#520.

FTW's heating view discovers a heat pump by the hp_power_w metric (web/heating.js:172) and shows nothing at all without it: no chart, no reading, no entry. So a driver verified against real hardware in June has had no page in the product it was written for.

hp_power_w now comes from main/Heat_Power_Consumption, which the new power_topic config key overrides for a Heishamon build that names the topic differently. It is emitted only once that topic has arrived, so a wrong name costs the power reading and leaves every other metric alone.

hp_outside_temp_c becomes hp_outdoor_temp_c — the name nibe_local and myuplink report, and the one the view charts. Nothing read the old name. Existing history under it stays where it is and stops growing.

Also: the DRIVER version said 0.4.0 while the manifest said 0.5.0, and nothing outside make bump-driver compares them; both now say 0.6.0. The example config carried what reads like a real MQTT password, now a placeholder.

make check green. make test-driver ID=heishamon: 36 passed, 14 skipped.

Needs a check against hardware before merge. Heat_Power_Consumption is TOP21 on the Heishamon builds I could find named, but I have no pump to confirm it against. @Rolf — if your build names it differently, the driver takes power_topic and the default should change to whatever yours reports. The power_topic= value is logged at init.

This does not give the pump a node in Live Energy Balance, or a control in the UI. Both need FTW Core changes and stay in srcfl/ftw#520.

🤖 Generated with Claude Code

[frahlg]

Automated maintenance pass: not merging this one.

The driver-side work looks sound — power_topic is a config-overridable, file-local-concatenated topic (compliant with #59's rewritten test_subscription_topics_are_static), the metric only emits once the topic has actually arrived so a wrong name costs just that one reading, the version drift between DRIVER (0.4.0) and the manifest (0.5.0) is a legitimate catch, and hp_outside_temp_c → hp_outdoor_temp_c lines up with what nibe_local/myuplink already report. drivers/packages/public-boundary/history-secret-scan/dco checks are green; drivers was still in progress at review time.

Not merging because the PR body already says it itself: "Needs a check against hardware before merge", and tags @Rolf to confirm Heat_Power_Consumption is the right topic name on their build. That's exactly the kind of hardware-correctness question this pass is supposed to defer to a human on rather than resolve by assumption — seconding it here rather than merging past it.

Also blocked mechanically until then: this PR is based on #59's branch, not main, and #59 itself is approved but couldn't be merged via API (stacked-PR restriction — needs the web UI). Once a maintainer merges #59 and @Rolf confirms the topic name, this should be quick to land.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8c151414fd

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Track power-topic freshness separately

When Heat_Power_Consumption stops arriving while any temperature or offset topic continues, those unrelated messages keep refreshing the shared last_msg_ts, so power_w is never cleared and the driver emits the last power reading indefinitely. Give the power topic its own timestamp, or clear it unless that topic itself arrived within the freshness window.

AGENTS.md reference: AGENTS.md:L58-L60

Useful? React with 👍 / 👎.

[frahlg]

Automated maintenance pass: not merging this one.

The change itself looks correct — hp_power_w and the hp_outdoor_temp_c rename match FTW's heating-view discovery convention, the version drift between the Lua DRIVER block and the manifest (0.4.0 vs 0.5.0) is fixed by bumping both to 0.6.0 consistently, index.yaml/manifests/heishamon.yaml sha256 and size are in sync (make sync-manifests was run), CHANGELOG and SUPPORT_STATUS.md are updated, and all 5 CI checks are green.

But the author's own PR description says it plainly: "Needs a check against hardware before merge." Heat_Power_Consumption is a guess at the TOP21 topic name based on the Heishamon builds available for inspection, not confirmed against a running pump, and the PR explicitly asks @Rolf to confirm or supply the correct power_topic for their build. That's a real hardware-verification gap, not a formality — merging now risks shipping a power_topic default that silently reports nothing (the driver degrades gracefully, but a wrong default still means no hp_power_w and no heating-view entry, the exact problem this PR sets out to fix). Flagging for a maintainer to get that hardware confirmation (or to confirm it themselves) before merge.

Also note: this PR is stacked on #59 (also reviewed this pass, CI green, ready but blocked from auto-merge by GitHub's stacked-PR API restriction). #59 needs to land first; the GitHub API wouldn't even let me retarget this PR's base to main while the stack exists ("Cannot change the base branch because the pull request is part of a stack"), so both need a maintainer in the web UI.

---

Generated by Claude Code