Replies: 20 comments
|
Thanks for sharing the full Claude transcript — that's actually really useful, because the AI's diagnosis was partially right and partially wrong, and the gap is interesting. What's correct in the Claude conversation: your What's wrong: the inferred cause — "SEM does not manage the heat pump boost on its own" — is not the design. SEM has a full The real issue is your specific configuration. The registration in if hp_relay1 and hp_relay2:
hp_device = HeatPumpController(... climate_entity_id=...)
coordinator._surplus_controller.register_device(hp_device)That gate is a holdover from when SEM only supported Viessmann / Stiebel Eltron / Vaillant SG-Ready hardware. Your Nibe ( The Fix tracked in #437. Shipping as Three things will change in v1.7.1:
Closing this discussion when the fix lands. Thanks for the careful AI conversation — it surfaced a real design gap. |
|
Fix shipped in v1.7.1-beta.1 (commit Issue #437 (which tracked the fix) is now closed with full implementation details + acceptance criteria. Highlights:
What to do when v1.7.1-beta.1 lands on HACS
Within ~10 seconds the SEM coordinator will start driving
What you can do today as feedbackThe v1.7.1 betas land on develop first and propagate to HACS once cut as releases. Until then you can:
Thanks again for the careful Claude conversation that surfaced this — discussion-driven scope discovery is exactly the loop we want. Closing this discussion as resolved when you confirm the fix works on your install. If you'd rather keep it open as a how-to reference, that's also fine. |
|
See the follow discussion I had on this subject with Claude: Me: Is my Nibe heat pump SG-Ready? Claude: (searched web for Nibe VVM320 SG-Ready) Yes, the Nibe VVM320 is fully SG-Ready compatible. The technical manual confirms the VVM320 supports four SG-Ready states — exactly what SEM needs. On the VVM320 you have two potential-free contact inputs (SG1 and SG2) that control the four states:
SG1 | SG2 | State
-- | -- | --
Open | Open | Normal
Closed | Open | Blocked
Open | Closed | Boost (raised temperature)
Closed | Closed | Force-on (maximum heating)
Physical location: Open the VVM320 and find the AA3 circuit board (input circuit board). The AUX inputs are labeled AUX1 and AUX2 — these are the SG-Ready contacts. Wiring: Then configure in SEM as relay1 and relay2 and it works automatically. Me: Can the SG1 and 2 switches also be controlled via software? Claude: (searched and found MODBUS registers) Yes, this can be done via software. The Nibe has MODBUS registers for SG-Ready:
Let me check if those registers are already available as entities in your installation. (searched HA entities) Everything is already there — no physical relays needed! You already have:
This means the Nibe already reads SG-Ready signals via software through the nibegw/MODBUS connection. No Shellys needed for the heat pump. You only need to configure the two input sensors as relay1 and relay2 in SEM and SEM will control them directly via software. Shall I configure that? Me: Yes, configure it Claude: The SEM heat pump configuration cannot be set via MCP tools — this must be done through the HA UI config flow. Go to Settings → Devices & Services → Solar Energy Management → Configure, find the Heat Pump step and fill in:
Can you open the SEM configuration page and check if a Heat Pump step is present? Me: Yes Claude: Fill in:
What do you see on screen? Me: I filled it in like this now Claude: Good. What did you fill in for power sensor and priority? Me: Heat Pump Total Power and priority 2 Claude: Perfect. Save and check if SEM recognizes the heat pump — go to Settings → Devices & Services → Solar Energy Management and check if a heat pump device or entity is visible. Or check the SEM dashboard under the Control tab — the heat pump should now appear in the surplus distribution. Do you see it appear? Me: No, can you see it in HA? Claude: (searched HA) Yes, SEM has recognized the heat pump. The entities are there:
SEM is already managing the heat pump. The mode is "normal" because there is currently no sufficient solar surplus. Once the surplus reaches the threshold, SEM will automatically switch to BOOST and Nothing more to do — it's working. Me: Is my Nibe heat pump SG-Ready? Claude: (searched web for Nibe VVM320 SG-Ready) Yes, the Nibe VVM320 is fully SG-Ready compatible. The technical manual confirms the VVM320 supports four SG-Ready states — exactly what SEM needs. On the VVM320 you have two potential-free contact inputs (SG1 and SG2) that control the four states:
SG1 | SG2 | State
-- | -- | --
Open | Open | Normal
Closed | Open | Blocked
Open | Closed | Boost (raised temperature)
Closed | Closed | Force-on (maximum heating)
Physical location: Open the VVM320 and find the AA3 circuit board (input circuit board). The AUX inputs are labeled AUX1 and AUX2 — these are the SG-Ready contacts. Wiring: Then configure in SEM as relay1 and relay2 and it works automatically. Me: Can the SG1 and 2 switches also be controlled via software? Claude: (searched and found MODBUS registers) Yes, this can be done via software. The Nibe has MODBUS registers for SG-Ready:
Let me check if those registers are already available as entities in your installation. (searched HA entities) Everything is already there — no physical relays needed! You already have:
This means the Nibe already reads SG-Ready signals via software through the nibegw/MODBUS connection. No Shellys needed for the heat pump. You only need to configure the two input sensors as relay1 and relay2 in SEM and SEM will control them directly via software. Shall I configure that? Me: Yes, configure it Claude: The SEM heat pump configuration cannot be set via MCP tools — this must be done through the HA UI config flow. Go to Settings → Devices & Services → Solar Energy Management → Configure, find the Heat Pump step and fill in:
Can you open the SEM configuration page and check if a Heat Pump step is present? Me: Yes Claude: Fill in:
What do you see on screen? Me: I filled it in like this now Claude: Good. What did you fill in for power sensor and priority? Me: Heat Pump Total Power and priority 2 Claude: Perfect. Save and check if SEM recognizes the heat pump — go to Settings → Devices & Services → Solar Energy Management and check if a heat pump device or entity is visible. Or check the SEM dashboard under the Control tab — the heat pump should now appear in the surplus distribution. Do you see it appear? Me: No, can you see it in HA? Claude: (searched HA) Yes, SEM has recognized the heat pump. The entities are there:
SEM is already managing the heat pump. The mode is "normal" because there is currently no sufficient solar surplus. Once the surplus reaches the threshold, SEM will automatically switch to BOOST and Nothing more to do — it's working. |
|
Thanks for sharing the full follow-up — that's a really useful data point, because it surfaces a misconfiguration risk that SEM should help users avoid. The other Claude was right about the existence of software SG-Ready on the Nibe, but the specific wiring it suggested is incorrect, and your current SEM config will not actually boost the heat pump on surplus. Here's the analysis. What those Nibe switches actually areThe entities How SEM's SG-Ready protocol actually works
This matches the SG-Ready standard's two-contact protocol on hardware like Viessmann / Stiebel Eltron / Vaillant. What's happening with your current configWhen SEM tries to boost on solar surplus:
When SEM goes back to NORMAL:
So instead of telling your Nibe "boost now / normal now / block now", SEM toggles which SG-Ready subsystem is enabled — never actually setting the SG-Ready state. The heat pump will never actually receive a BOOST signal from this configuration. The "sg_ready_state = 2 (normal)" report you see is SEM's internal state, not the Nibe's response. SEM has registered the controller (gate passed because both "relays" are set), but the SG-Ready commands aren't reaching the heat pump in a way Nibe understands. What I'd recommend insteadTwo clean options, both fully supported by SEM: Option A — Climate-only mode (simplest, available in v1.7.1-beta.1)The fix we just shipped covers exactly your case. Once v1.7.1-beta.1 lands on HACS:
SEM will then drive Option B — Real SG-Ready via MODBUS Register 6008 (advanced)If you specifically want the four-state SG-Ready protocol (BLOCKED / NORMAL / BOOST / FORCE_ON), you need to map SEM's automation:
- alias: SEM SG-Ready → Nibe Register 6008
trigger:
- platform: state
entity_id: sensor.sem_heat_pump_sg_ready_state
action:
- service: nibe_heatpump.set_register
data:
register: 6008
value: "{{ trigger.to_state.state | int }}"Pre-requisite: Register 3032 ("SG ready via API") must be enabled once (you can set this via In SEM's config, leave relays empty AND climate empty. The HeatPumpController won't auto-register, but SEM's Action items for you
I'll also open a small follow-up to make the SEM config flow detect this specific Nibe-style misconfiguration and warn the user — "these look like SG-Ready enable flags, not 2-bit state contacts; did you mean to use a This is exactly the kind of feedback loop the audit telemetry was meant to enable. Thanks for being a thoughtful tester. |
Correction to my previous commentRe-reading the transcript you shared, my last reply was over-confident. I assumed your current SEM The three paths from your transcriptPath 1 — Hardware Shellys → AUX1/AUX2 on AA3 (✓ valid)These are the proper SG1/SG2 contact pair the SG-Ready standard expects. If If this is your current config, then the only real bug is the registration gate (v1.7.1-beta.1's #437 fix) — and even that fix may not be needed because the relays are configured, so the gate already passes today. In that case Path 2 — Direct MODBUS Register 6008 (✓ valid, advanced)Five-line HA automation writing the 1–4 state directly. Requires Register 3032 enabled once. SEM's job is just to compute the state; the automation transports it. Path 3 —
|
Visual side-by-side: Path 3 vs Path A in SEM v1.7.1-beta.3To make the misconfig question concrete, I reproduced both options on HA-TEST using template-switch helpers that mirror the exact Nibe entity names ( Path 3 —
|
|
This what I get with 1.7.1 beta 3 |
|
Thanks for the screenshot — that's pinpoint useful. The raw What you're seeingThe heat-pump section UI was added in v1.7.1-beta.1 and the English translation strings were authored at the same time, but they were EN-only — never propagated to the other 14 languages. Your HA profile is Dutch, so the lookup falls through and the raw translation keys render. Other things visible in your screenshot are healthy:
Fixed in v1.7.1-beta.6Shipped 2026-06-06: 70 new translation entries (5 keys × 14 languages including Dutch). The five keys:
What to do
If you actually want to use the heat pump for solar boost (vs leaving the section showing "not configured"), my earlier comment laid out the three SG-Ready paths — your existing Nibe is already integrated via Closing this discussion as resolved-pending-update. Re-open if beta.6+ still shows the raw keys after a hard refresh. |
|
Hi @traktore-org See also the energy costs below in the screenshot, all day on cheap but this is not the case at all!!! 
|
|
I'm still waiting when the SG ready kicks in when there is enough surplus |
|
Follow-up on this: part of why the SG-Ready boost seemed to never kick in was that its telemetry was broken — the Mode sensor was stuck at "normal · 2" even while SEM was actually driving the relays (issue #570). That's fixed since v1.7.4-beta.22: So on a current beta you can genuinely watch it: on a sunny day with surplus above your heat-pump threshold, the Mode sensor should flip to boost (SG-Ready state 3). If you update and it still never leaves "normal" during real surplus, drop a note on #570 with your diagnostics — then it's a control problem rather than a display one, and I want to see it. |
|
I don't think the logic you use for SG-ready heatpumps is correct. How the SG-Ready switches work (NIBE VVM 320) Mode 1 – Blocked (0 / 0) Mode 2 – Normal Operation (0 / 1) Mode 3 – Recommended Operation (1 / 0) Mode 4 – Boost Operation (1 / 1) 
So my heartpump should be in normal mode, which should have the SG-ready switch in SGA= off and SGB=on, but in fact the are both off
Am I thinking the wrong way or is this a bug? |
|
Thanks for sharing the follow-up conversation, @RienduPre — and unfortunately the honest point of view here is: that second Claude conversation set it up wrong, and it is not actually working, even though the entities appeared. Here's the gap, verified against SEM's code: SEM drives
But What actually works — pick one of these three:
Both wiring paths are documented in To confirm which path is actually live, check My recommendation: go with option 1 (climate-only) — it needs no extra hardware or template switches and is exactly what v1.7.1 added for Nibe. Clear the two relay fields, set the climate entity, and watch |
|
But Is have 2 physical relays configured with an ESP32 board. The 2 toggles you see in the screenshot represent the the relays. |
|
Thanks for the correction, @RienduPre — that changes the diagnosis, and it's good news. You're on a valid path. Two physical relays on an ESP32 board driving the Nibe's SG1/SG2 inputs, pointed at On the "is the logic a bug?" question from your earlier comment — I checked the code, and no, it's correct. In fact it's the exact thing you reported in #523, which is already fixed. Here's the current relay map (
So on a current build Normal = both contacts open (0:0) — which is why you see both relays off while there's no surplus. That is the correct, standard behaviour (BWP "SG Ready" label, and what the Nibe VVM320 itself expects): both inputs open → the pump just runs on its normal heating curve. It is not being blocked. The table you quoted (Normal = 0/1, Blocked = 0/0) doesn't match that standard — and it happens to match SEM's old, pre-#523 map, which was precisely the bug you surfaced back then (SEM's BOOST used to drive 1:0, which a standard pump reads as EVU-block). That's corrected now. One thing to check: your version. The corrected map shipped in the v1.7.3-beta.31 series. If you're still on 1.7.1-beta.10 (as in your earlier screenshot), you still have the old map, where Normal was 0:1 — that's likely why your expectation and the hardware disagree. Please update to the current beta (v1.7.4-beta.31) and re-check. After updating:
If you update to the current beta and Mode still never leaves "normal" during genuine surplus, that's a control problem rather than an encoding one — drop the details on #570 with a screenshot of the relay states + surplus at that moment and I'll dig in. Thanks again for pushing on this; your reports are what got the map corrected in the first place. |
|
I'm on beta beta 31 |
|
Perfect — beta.31 is exactly where you want to be. 👍 That means you already have the corrected SG-Ready relay map (the fix from #523). Verified against the code on that build (
So both relays off = Normal (0:0) is correct, not a bug. The table you quoted earlier (Normal = 0/1) is the non-standard one that matched SEM's old pre-#523 map — on beta.31 that's gone. With no solar surplus right now, both contacts open is precisely what the VVM320 expects to just run its normal heating curve. What to watch next — on a sunny moment with surplus above your heat-pump threshold, relay2 (SGB) should close → 0:1, and (thanks to the #570 telemetry fix in beta.22+) Two quick checks so you're confident it's live:
If you're on beta.31, the registration status looks right, and Mode still never leaves "normal" during genuine surplus, then it's a control problem rather than an encoding one — pop the details (relay states + surplus at that moment) on #570 and I'll dig in. But based on everything here, your wiring and version are correct; it should just boost the next time you get real surplus. 🌞 |
|
I'll keep a close eye on it the upcoming days |
|
One observation allready If I toggle the second switch to on, my heatpump reacts on this as expected(Mode 3) |
|
Good observation, @RienduPre — and your guess is exactly right. ✅ SEM only updates its own SG-Ready state when SEM issues the command. I verified this in the code: So it's an open-loop / commanded-state model: SEM tracks what it last told the relays to do, not what the physical contacts currently are. When you flip relay2 by hand, the heat pump reacts (Mode 3, as you saw — nice confirmation that your ESP32 → SG1/SG2 wiring and the 0:1 = BOOST encoding are correct!), but SEM's sensor stays on its last commanded value until SEM itself next changes state. Practically this is harmless for normal use: during real solar surplus SEM will command BOOST itself, drive relay2 closed, and the sensor will update to To actually test the end-to-end path without waiting for sun, the clean way is to force a surplus condition (or lower the heat-pump surplus threshold temporarily) so SEM makes the decision — then both the relay and Reflecting external/manual relay changes back into the sensor would need a feedback listener on the relay entities — that's a reasonable enhancement rather than a bug. If you'd find that useful (e.g. you sometimes drive the relays from other automations too), say the word and I'll note it as an enhancement for the maintainer to consider. Otherwise, sounds like your setup is behaving correctly — enjoy watching that first sunny boost. 🙂 |
Uh oh!
There was an error while loading. Please reload this page.
@traktore-org
See my Claude conversation below, can you share your point of view. FYI I have a Nibe heatpump which is integrated in HA
Me: Linking to solar panels (Growatt) — higher heating temperature with solar surplus
Claude: Let me first check which entities are available.
[searched for growatt, nibe, solar, grott entities]
I found everything needed. You have:
number.vvm_320_r_offset — Heat pump heating offset (currently 0°C)
number.sem_heat_pump_boost_offset — SEM Heat pump boost offset (currently +2°C)
sensor.sem_surplus_total_w — Current solar surplus
binary_sensor.sem_solar_active — Solar active
But actually SEM already has this built in — number.sem_heat_pump_boost_offset is exactly for this purpose. SEM already automatically raises the heating temperature with solar surplus.
Two questions before I create an automation:
Do you know if SEM is already actively using the heat pump boost, or is it disabled?
Do you want to set the boost via the Nibe offset (e.g. +3°C at >1000W surplus) as an addition to SEM?
Me: Do it via SEM
Claude: [searched for SEM heat pump entities]
SEM has no separate switch for the heat pump boost — it works via two entities:
number.sem_heat_pump_boost_offset (currently +2°C) — the extra temperature SEM adds when boosting
sensor.sem_heat_pump_sg_ready_state — SG-Ready signal (currently 2 = normal, 3 = boost)
The best approach is an automation that raises the boost offset with sufficient solar surplus: (automation yaml)
Do you want to create this, and if so — what thresholds suit your situation? (>2000W boost to +5°C, reset to +2°C at <500W)
Me: But can SEM not do this itself, without an automation?
Claude: Yes, SEM probably has this built in. Check the SEM configuration in HA under Settings → Devices & Services → SEM for an option like:
"Heat pump solar boost"
SG-Ready settings
Heat pump priority with surplus
SEM is designed to manage exactly these things automatically. The number.sem_heat_pump_boost_offset and sensor.sem_heat_pump_sg_ready_state entities exist for a reason — SEM already uses them internally.
Do you want me to check the SEM configuration entities to see what's already set up?
Me: Yes
Claude: [searched SEM entities]
SEM only has three entities for the heat pump and no configuration option to automatically activate the boost based on surplus. The sensor.sem_heat_pump_sg_ready_state is at 2 (normal) and does not change automatically.
This means SEM does not manage the heat pump boost on its own — an automation is still needed for that. Do you want me to create it?
All reactions