[eloBLOCK] Research findings: PartloadHwcKW confirmed (A900), CurrentPower type investigation, D.152/D.153 discovery method, PowerValue decoding

[Gfermoto]

Summary

After extensive research across john30/ebusd-configuration issues, community gists, and testing on a live Vaillant eloBLOCK VE 14 (PROD=0010023658, SW=0109, HW=7503), I've gathered several findings that might help improve this project's configuration files.

---

1. PartloadHwcKW (D.77) — confirmed address A900 ✅ HIGH PRIORITY

Finding: Register address A900 for PartloadHwcKW (D.77, hot water partload / charging power) has been confirmed working on multiple eloBLOCK models by the community:

• 0010023657 (SW=0109, HW=7503) — confirmed by @AznKid45 and @stalniy (gist)
• 0010023684 (SW=0108, HW=7503) — confirmed by @Akeebaby
• 0010023691 — confirmed by @carhensi

Source: john30/ebusd-configuration issue #254 and PR #567 (submitted 2026-02-13, not yet merged).

What it enables: Control of storage charging power in 1–9 kW steps (for VE 9/14 models) or the equivalent range for VE 14/18. This is the most practical way to do software power limiting until D.152/D.153 register addresses are found (see §3 below).

Proposed line for bai.0010023658.inc:

r;wi,,PartloadHwcKW,d.77 hot water partload,,,,A900,,,UCH,,kW,Storage charging power limit

Note: The current bai.0010023658.inc has this line commented out:

#r;wi,,PartloadHwcKW,d.77 hot water partload,,,,0804,,,UCH,,,storage part load

Address 0804 is likely wrong for this model (it's from the gas boiler generic fallback). The confirmed address is A900, same as models 0010023657 / 0010023684 / 0010023691.

Action requested: Uncomment/add PartloadHwcKW with address A900 for model 0010023658.

---

2. CurrentPower (D.108, E601) — data type investigation needed 🔍

Current state in config:

r,,CurrentPower,d.108 Power now,,,,E601,,,HEX:2,,kW,Current real-time power output

Finding: @Akeebaby (0010023684, SW=0108, HW=7503) had this line commented out with the comment "Additional electric parameters is total error" — see issue #254 comment (Nov 27, 2025).

Our live test result on 0010023658 SW=0109:

• CurrentPower shows unavailable after enabling in config and restarting ebusd
• Could be: wrong data type, wrong address variant for SW=0109, or the register only responds during active heating

Debug command to determine correct data type:

ebusctl hex b509 0d E601

• 1-byte response → try UCH (unsigned char, 0–255 kW)
• 2-byte response → try UIN (unsigned int, LE) or SIN
• ERR: invalid position → either wrong register or requires multi-field decode
• No response / timeout → register may not be accessible on SW=0109

From official manual 0020265768_01: D.108 type is listed as UIN (not UCH or HEX:2). This conflicts with @Akeebaby's HEX:2 choice — worth testing both on an active boiler.

Note on D.155 vs D.108: The manual also mentions D.155 as "current output (continuously updated)". These might be the same eBUS register or two different ones. If D.108 (E601) fails, searching for D.155 via grab scan might reveal an alternative address.

Action requested: If anyone with an active eloBLOCK can run ebusctl hex b509 0d E601 during heating and share the raw response bytes, that would resolve the data type question.

---

3. D.152/D.153 (PowerLimiterPhase / PowerLimiterValue) — eBUS addresses unknown 🔍 HIGH VALUE

Context: According to the official Vaillant manual (0020265768_01), parameters D.152 and D.153 allow software power limiting without any dry-contact hardware:

Code	Description	Values
D.152	Output limiter — phase selection	0=no limit, 1=phase1, 2=phase2, 3=phase3, 4=all phases
D.153	Output limiter — power reduction value (kW)	subtracted from max configured power

Example: MaxPower=14kW, D.152=4 (all phases), D.153=6kW → actual output = 8kW

Current status: eBUS register addresses for D.152/D.153 are not found in any public source (GitHub issues, HA Community, OpenEnergyMonitor, ioBroker, Reddit, ManualsLib, 4PDA, ab-log.ru).

Recommended method to find them (from @stalniy's gist and @john30's guidance in issue #36):

# Step 1: Enable hex access in ebusd (EBUSD_ENABLEHEX=1 in environment)

# Step 2: Dump all registers BEFORE changing D.152/D.153 on boiler display
# Script: https://github.com/stalniy/ebusd/blob/feat/retry_for_read_all/contrib/scripts/readallvaillantregisters.sh
./readallvaillantregisters.sh > registers_before.txt

# Step 3: Go to boiler display, change D.152 from 0 to 4 (all phases)
#         OR change D.153 from 0 to 6 (kW)

# Step 4: Dump registers again immediately
./readallvaillantregisters.sh > registers_after.txt

# Step 5: Compare — the changed register(s) = D.152/D.153 eBUS address
diff registers_before.txt registers_after.txt

Why this matters: This is the key to enabling Home Assistant energy management automation — e.g., automatically reducing boiler power when washing machine/oven is running, without installing a physical relay. The vaillant_power.yaml automation currently requires an ESPHome relay. D.152/D.153 via eBUS would eliminate the need for additional hardware entirely.

Action requested: Anyone willing to perform the grab diff scan please share results here!

---

4. PowerValue (AA00) — proposed byte layout decoding 💡

Current definition:

r,,PowerValue,PowerValue,,,,AA00,,,HEX:6,,,"Power Values of the Boiler (min Power, max Power)"

Observed value on eloBLOCK VE 14 (0010023657, HW=7503, from issue #254):
bai PowerValue = 11 02 64 0e 64 0e

Hypothesis for byte layout (VE 14 = 14 kW max):

Byte	Hex	Dec	Interpretation
[0]	0x11	17	Unknown header / coding resistor variant
[1]	0x02	2	Min power = 2 kW
[2]	0x64	100	Unknown (scale factor / 100%?)
[3]	0x0E	14	Max power = 14 kW ✅
[4]	0x64	100	Unknown
[5]	0x0E	14	Max power repeated?

For a VE 14 boiler: min=2 kW, max=14 kW perfectly matches specification.

Action requested: If anyone with a different power rating (VE 9 or VE 18) could share their PowerValue hex output, that would confirm the decoding. Commands:

ebusctl read PowerValue
# or
ebusctl hex b509 0d AA00

---

5. SetModeOverride — thermostat emulation (not in current config)

Finding from @stalniy (confirmed on 0010023657, SW=0109, HW=7503): The SetModeOverride command enables full thermostat emulation over eBUS — no external thermostat hardware needed.

Recommended line to add to bai.0010023658.inc:

wi,bai,SetModeOverride,Operation Mode,,08,"B510","00",hcmode,,UCH,,,,flowtempdesired,,D1C,,,,hwctempdesired,,D1C,,,,hwcflowtempdesired,,UCH,,,,setmode1,,UCH,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,setmode2,,UCH,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2

Usage:

# Set flow temperature to 55°C, heating on, DHW on
ebusctl w -c bai SetModeOverride "0;55;45;-;-;0;0;0;-;0;0;0"

Important: This command must be resent every ~60 seconds — otherwise the boiler reverts to its own display settings. Official VRC thermostats send it every few seconds.

---

6. HeatingStage1/2/3 and ActiveStages — verification status

Current config has these active for 0010023658:

r;wi,,HeatingStage1,d.100 Stage1 enable,,,,ED01,,,onoff,...
r;wi,,HeatingStage2,d.101 Stage2 enable,,,,EE01,,,onoff,...
r;wi,,HeatingStage3,d.102 Stage3 enable,,,,EF01,,,onoff,...
r,,ActiveStages,d.103 Stages active,,,,F001,,,UCH,...

Observed on 0010023658 SW=0109: All four show unavailable after ebusd restart, even when boiler is connected and signal is acquired.

@Akeebaby (0010023684, SW=0108) has all these commented out with "total error" in their config.

Possible causes:

• Registers only respond during active heating cycle
• Address correct but data type wrong (try UCH with 0=off;1=on instead of onoff)
• Address only valid for certain SW versions

Debug command: ebusctl hex b509 0d ED01 (run during active heating)

---

7. ElementHours data type (C401) — unverified

Current config:

r,,ElementHours,d.106 Elements runtime,,,,C401,,,hoursum2,...

hoursum2 is the type used for gas boiler HcHours. For an electric boiler, consider also testing UIN (unsigned int):

r,,ElementHours,d.106 Elements runtime,,,,C401,,,UIN,,h,Heating elements total operating hours

---

8. atmoTEC (0010015251) — SW-version guards for CO sensor parameters

The current bai.0010015251.inc includes e.04–e.19 CO sensor parameters. Per the README, most return errors on SW=0407.

Suggestion: Add [SW>=xxx] version guards (similar to the existing [SW>=413] guard for APCLegioProtection) to reduce error noise in ebusd logs for unsupported SW versions.

---

Test Environment

Parameter	Value
Model	Vaillant eloBLOCK VE 14
PROD	0010023658
SW	0109
HW	7503
ebusd instance 1	HA addon (LukasGrebe/ha-addons)
ebusd instance 2	Docker container (separate server)
HA	Home Assistant OS (current)

---

Priority Summary

#	Finding	Priority	Effort to fix
1	Add PartloadHwcKW at A900	🔴 High	1 line
3	Find D.152/D.153 addresses	🔴 High	Grab scan needed
2	Fix CurrentPower E601 type	🟡 Medium	1 debug command
4	Document PowerValue decoding	🟡 Medium	Comment addition
5	Add SetModeOverride	🟡 Medium	1 line
6	Verify HeatingStage registers	🟢 Low	Test needed
7	Fix ElementHours type	🟢 Low	1 line
8	atmoTEC SW version guards	🟢 Low	Minor

Thank you for this project — it's the best existing resource for Vaillant eloBLOCK eBUS integration!

[Gfermoto]

Live test results (0010023658 SW=0109, HW=7503) — 2026-03-02

Tested all electrical registers during active heating (Statenumber=4, FlowTemp rising 23°C→32°C over 5 minutes).

Results after adding r1/r2 explicit polling

Register	Address	Type	Result	Notes
HeatingStage1	ED01	onoff	✅ off	Readable! But off during heating — may be "enable/disable" not "currently active"
HeatingStage2	EE01	onoff	❌ unknown	ebusd polls but no value published — register may not exist on this unit
HeatingStage3	EF01	onoff	✅ off	Readable! Same as Stage1
ActiveStages	F001	UCH	✅ 192 (0xC0)	Bitmask interpretation is WRONG — bits 6+7 set, not bits 0-2. Actual meaning TBD
MaxPower	A201	UCH	❌ unknown	Polled with r1 for 4+ minutes, never published — register likely inaccessible on SW=0109
TotalEnergy	B301	ULG	❌ unknown	Same — polled, never published
ElementHours	C401	UIN	❓ entity never created	ebusd never got any valid response
OverTempStatus	D501	temp	❓ entity never created	ebusd never got any valid response
CurrentPower	E601	UIN	❌ unknown	Same as MaxPower — polled with r2, never published during active heating
PartloadHwcKW	A900	UCH	❌ unavailable	Register doesn't respond on this unit (no DHW storage connected?)

Key conclusions

1. ActiveStages bitmask is different than documented

Observed value during heating: 192 = 0xC0 = 1100_0000b

• Documented: bit0=stage1, bit1=stage2, bit2=stage3 → would give values 1, 2, 4, or combinations
• Actual: bits 6 and 7 are set, lower bits are 0
• Hypothesis: bit6=pump something, bit7=heating active? Or the whole field has different semantics on eloBLOCK

2. Electric power registers (A201, B301, C401, D501, E601) — all inaccessible on SW=0109

All registers in the XX01 range (A2-E6) appear to return errors when polled. The registers that DO work (ED01, EE01, EF01, F001) are in the same page but at higher addresses. No obvious pattern.

Possible explanations:

• These registers are only accessible via service/installer eBUS access level (not the standard r access we're using)
• SW=0109 firmware version doesn't implement these registers
• Address pattern assumption (step +0x11) from the manual may be incorrect for some registers

3. PartloadHwcKW (A900) — unavailable

This unit has no DHW storage tank connected, so the hot-water-related registers likely don't respond. This is expected behavior, not a config bug.

4. HeatingStage1/3 readable but off during heating

FlowTemp IS rising (23→32°C) and Statenumber=4, but HeatingStage1 and Stage3 both show off. This could mean:

• The Stage registers (ED01/EF01) are "enable/disable" flags (0=enabled, 1=disabled)? Counterintuitive naming.
• OR the actual active stages signal is elsewhere and ED01/EF01 serve a different purpose

---

Revised register status summary

✅ Confirmed working: ED01, EF01, F001 (semantics need clarification)
❌ Inaccessible on 0010023658 SW=0109: A201, B301, C401, D501, E601
❓ Unknown: EE01 (Stage2 — may not exist on this specific unit)
❌ Expected unavailable: A900 (no DHW storage connected)

---

If anyone with a different SW version or model can test the A201-E601 range, it would help narrow down whether this is a firmware version issue or a model-specific limitation.