You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FTW can now feed live solar surplus to a NIBE S-series heat pump's own Solar PV input (registers 2107/2109) over the pump's on-prem Local REST
API — the pump then soaks the surplus into heating and hot water using its
own owner-tuned logic. The mechanism is built, reviewed-ready and
hardware-validated as far as one site can take it. What we cannot produce
ourselves is a site that has both an S-series pump and PV — and that is the
half that matters most.
Looking for: one or more testers with an S-series pump (S735/S1155/S1255 or
similar, myUplink-era firmware with the Local REST API in installer menu 7.5)
AND real PV production on the same site.
What is already proven
On a real S735 (no PV on site), the full write chain has been run end-to-end
(findings on #537):
the pump accepts the write (modified), the value read back from register
2109 tracks exactly what FTW wrote, the driver's dead-man's switch clears a
stale feed on its own, and a hard crash mid-feed is cleaned up by the next
boot's orphan sweep. Every write is clamped to an operator-set max_w
ceiling, and the whole path is off by default behind three separate gates.
What only a PV site can answer
Does the pump do something sensible with a real, moving surplus? Our
test site had register 2107 (the owner's Solar PV master switch) off, so
the value was accepted but ignored. With 2107 on, the pump acts on it —
compressor scheduling, hot-water boosts, offsets — and nobody has watched
that happen under FTW yet.
The pump's own timeout for a silently stopped feed is undocumented; we
clear proactively, but knowing the pump-side behaviour would let the
driver state it instead of guessing.
Register 2108 (own consumption): gross vs net — whether "include own
consumption" changes what the pump expects 2109 to mean on a real site.
What testing involves
Enabling the Local REST API on the pump's own screen (installer menu 7.5 —
no myUplink account or app needed) and setting it to read/write
(7.5.15), plus turning on the Solar PV input (2107) when ready.
Running the write-capable build: driver from device-drivers#46, UI
switch from #769 — once merged,
it is one toggle in Settings → Devices plus a maximum-watts field.
Starting with a small max_w and watching: the feed value, the pump's
reaction, and the two telemetry series FTW records for exactly this
(hp_solar_pv_feed_w — what FTW wrote, and the register 2109 read-back).
A wrong value degrades to wasted comfort, never to unsafe operation — the
pump's own firmware stays in charge of everything that matters.
If you have the hardware and are willing, reply here or on #537. We can help with setup and
will take telemetry in whatever form is convenient.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
FTW can now feed live solar surplus to a NIBE S-series heat pump's own
Solar PV input (registers 2107/2109) over the pump's on-prem Local REST
API — the pump then soaks the surplus into heating and hot water using its
own owner-tuned logic. The mechanism is built, reviewed-ready and
hardware-validated as far as one site can take it. What we cannot produce
ourselves is a site that has both an S-series pump and PV — and that is the
half that matters most.
Looking for: one or more testers with an S-series pump (S735/S1155/S1255 or
similar, myUplink-era firmware with the Local REST API in installer menu 7.5)
AND real PV production on the same site.
What is already proven
On a real S735 (no PV on site), the full write chain has been run end-to-end
(findings on #537):
the pump accepts the write (
modified), the value read back from register2109 tracks exactly what FTW wrote, the driver's dead-man's switch clears a
stale feed on its own, and a hard crash mid-feed is cleaned up by the next
boot's orphan sweep. Every write is clamped to an operator-set
max_wceiling, and the whole path is off by default behind three separate gates.
What only a PV site can answer
test site had register 2107 (the owner's Solar PV master switch) off, so
the value was accepted but ignored. With 2107 on, the pump acts on it —
compressor scheduling, hot-water boosts, offsets — and nobody has watched
that happen under FTW yet.
clear proactively, but knowing the pump-side behaviour would let the
driver state it instead of guessing.
consumption" changes what the pump expects 2109 to mean on a real site.
What testing involves
no myUplink account or app needed) and setting it to read/write
(7.5.15), plus turning on the Solar PV input (2107) when ready.
device-drivers#46, UI
switch from #769 — once merged,
it is one toggle in Settings → Devices plus a maximum-watts field.
max_wand watching: the feed value, the pump'sreaction, and the two telemetry series FTW records for exactly this
(
hp_solar_pv_feed_w— what FTW wrote, and the register 2109 read-back).pump's own firmware stays in charge of everything that matters.
If you have the hardware and are willing, reply here or on
#537. We can help with setup and
will take telemetry in whatever form is convenient.
🤖 Generated with Claude Code
All reactions