Hi! I'm running master on an ESP32-C6 attached to a Stiebel Eltron WPE-I 08
HK 230 Premium (brine/water, no integrated DHW), until now via wpl13.yaml.
I did a systematic audit of every entity against the pump's own WPM panel
(video walkthrough + CAN logs with raw values) and have working, panel-verified
fixes on a local branch. Before opening PRs I'd like your preference on
structure — and there are two findings that affect more than the WPE-I.
Verified identical to WPL13 on the WPE-I: all water-circuit temperatures,
HK1/HK2 setpoints and heat curves, heat-yield counters (16.829 MWh exact),
efficiency values, and VERDICHTER_STARTS (2209 exact).
Findings, each panel-verified:
-
EL_ENERGIEAUFNAHME_*_SUMME_KWH combines the two parts swapped
(affects every model, not just WPE-I): the kWh part gets scaled ×1000 and
the MWh part added raw. My pump returns 0x0920 = 623, 0x0921 = 2; the
entity showed 623,002 kWh while the panel shows 2.623 MWh
(cross-check: panel efficiency 6.34 = 16.829 / 2.623). One-line var swap in
wpl_base.yaml; WAERMEERTRAG_* and VERDICHTER_STARTS are correct.
-
Elster sentinels decode to garbage numbers: 0x8000 ("not available")
and 0x9000 ("AUS") pass through the int16 cast — e.g. MINTEMP raw
0x9000 renders -2867.2 while the panel shows AUS, and the (absent)
DHW counters render 32.768 MWh / 32,768,000 kWh. I return NAN for these
words in GetValueByType so HA shows the entity as unavailable.
-
PROGRAMMSCHALTER on the WPE-I is a low byte (raw 0x02 captured while
the panel showed Programmbetrieb), so the WPL_13-only value << 8
shift in type.cpp makes the lookup fail and the select stays at
"Unbekannt". My WPE_I build simply doesn't shift. Question: since
5c9a3f6 keys the map on low bytes for WPL13/17/23, can a WPL13 user confirm
their Programmschalter select still works? Reading the code I'd expect the
shift to break it there too — happy to include that fix if so.
-
The WPE-I has no DHW — the controller answers the WW energy properties
with 0x8000. I moved the four WW packages from wpl_base.yaml into
wpl13/17/23.yaml (no behavior change for those models) so a WW-less
variant can just not include them. OK for you?
-
On the WPE-I, 0x02e2 is WP_WASSERVOLUMENSTROM (as on your WPL17),
not the WPL13 WAERMEPUMPEN_STATUS word: it tracks the circulation
flow (raw 280/285 = 28.0/28.5 l/min alongside VOLUMENSTROM = 27.7)
and decoding it as status bits produced VERDICHTER/STOERUNG=true with
the compressor off and a clean panel. My variant exposes it as the flow
sensor and omits the nine status binaries until the WPE-I's real status
property is found.
Structure question: I currently have a thin yaml/wpe-i.yaml following
the wpl17/23 pattern (-DWPE_I build flag joining the existing property
groups, plus LAUFZEIT_VD_*/LAUFZEIT_NHZ* runtime counters). Would you
prefer that shape, or conditionals inside the WPL yamls? Happy to split the
PRs however works best for you — I'd propose: (1) sentinels, (2) energy-swap,
(3) WW move, (4) WPE-I variant.
Still investigating on the WPE-I (will file separately with evidence once
pinned down): the Prozessdaten refrigerant-circuit temperatures
(RUECKLAUFTEMP/VORLAUFTEMP/VERDAMPFERTEMP/VERDICHTER_EINTRITTSTEMP/
HEISSGAS_TEMP) read water-circuit sensors instead (panel 25–34 °C vs entities
18–21 °C); the Manager BETRIEBS_STATUS cooling bit (panel shows Kühlbetrieb
active, bit reads false — the pump broadcasts a different status word, raw 4,
to the room-unit address); the room-unit (FET2) values; and
LAUFZEIT_PASSIVKUEHLUNG (raw 1884 vs panel 116 h, no clean scale factor).
Thanks for the great project!
Hi! I'm running master on an ESP32-C6 attached to a Stiebel Eltron WPE-I 08
HK 230 Premium (brine/water, no integrated DHW), until now via
wpl13.yaml.I did a systematic audit of every entity against the pump's own WPM panel
(video walkthrough + CAN logs with raw values) and have working, panel-verified
fixes on a local branch. Before opening PRs I'd like your preference on
structure — and there are two findings that affect more than the WPE-I.
Verified identical to WPL13 on the WPE-I: all water-circuit temperatures,
HK1/HK2 setpoints and heat curves, heat-yield counters (16.829 MWh exact),
efficiency values, and
VERDICHTER_STARTS(2209 exact).Findings, each panel-verified:
EL_ENERGIEAUFNAHME_*_SUMME_KWHcombines the two parts swapped(affects every model, not just WPE-I): the kWh part gets scaled ×1000 and
the MWh part added raw. My pump returns
0x0920 = 623,0x0921 = 2; theentity showed 623,002 kWh while the panel shows 2.623 MWh
(cross-check: panel efficiency 6.34 = 16.829 / 2.623). One-line var swap in
wpl_base.yaml;WAERMEERTRAG_*andVERDICHTER_STARTSare correct.Elster sentinels decode to garbage numbers:
0x8000("not available")and
0x9000("AUS") pass through the int16 cast — e.g.MINTEMPraw0x9000renders -2867.2 while the panel shows AUS, and the (absent)DHW counters render 32.768 MWh / 32,768,000 kWh. I return
NANfor thesewords in
GetValueByTypeso HA shows the entity as unavailable.PROGRAMMSCHALTER on the WPE-I is a low byte (raw
0x02captured whilethe panel showed Programmbetrieb), so the
WPL_13-onlyvalue << 8shift in
type.cppmakes the lookup fail and the select stays at"Unbekannt". My WPE_I build simply doesn't shift. Question: since
5c9a3f6 keys the map on low bytes for WPL13/17/23, can a WPL13 user confirm
their Programmschalter select still works? Reading the code I'd expect the
shift to break it there too — happy to include that fix if so.
The WPE-I has no DHW — the controller answers the WW energy properties
with
0x8000. I moved the four WW packages fromwpl_base.yamlintowpl13/17/23.yaml(no behavior change for those models) so a WW-lessvariant can just not include them. OK for you?
On the WPE-I,
0x02e2isWP_WASSERVOLUMENSTROM(as on your WPL17),not the WPL13
WAERMEPUMPEN_STATUSword: it tracks the circulationflow (raw 280/285 = 28.0/28.5 l/min alongside
VOLUMENSTROM= 27.7)and decoding it as status bits produced VERDICHTER/STOERUNG=true with
the compressor off and a clean panel. My variant exposes it as the flow
sensor and omits the nine status binaries until the WPE-I's real status
property is found.
Structure question: I currently have a thin
yaml/wpe-i.yamlfollowingthe wpl17/23 pattern (
-DWPE_Ibuild flag joining the existing propertygroups, plus
LAUFZEIT_VD_*/LAUFZEIT_NHZ*runtime counters). Would youprefer that shape, or conditionals inside the WPL yamls? Happy to split the
PRs however works best for you — I'd propose: (1) sentinels, (2) energy-swap,
(3) WW move, (4) WPE-I variant.
Still investigating on the WPE-I (will file separately with evidence once
pinned down): the Prozessdaten refrigerant-circuit temperatures
(RUECKLAUFTEMP/VORLAUFTEMP/VERDAMPFERTEMP/VERDICHTER_EINTRITTSTEMP/
HEISSGAS_TEMP) read water-circuit sensors instead (panel 25–34 °C vs entities
18–21 °C); the Manager
BETRIEBS_STATUScooling bit (panel shows Kühlbetriebactive, bit reads false — the pump broadcasts a different status word, raw 4,
to the room-unit address); the room-unit (FET2) values; and
LAUFZEIT_PASSIVKUEHLUNG(raw 1884 vs panel 116 h, no clean scale factor).Thanks for the great project!