Update registers based on cross-check with installer page

[johncuthbertuk]

Updated registers for discharge gas temp, fan suction and suction based on cross-check with installer page

[stuartj1-1981]

Thanks John — and thanks especially for the installer page cross-check. An independent naming source
is genuinely valuable, we've had very little of it, and you've found a real inconsistency in reg 45
that I'd missed. More on that below.

I want to split this one though. Reg 52 I'd like to take now. Regs 45 and 50 I don't think we can
land yet, and I'll try to explain why in a way that's useful rather than just "no".

The general point

identified.md sets the bar for the confidence column:

CONFIRMED: Cross-validated against an independent sensor or physical calculation (correlation
coefficient and sample size stated)

An installer-page label is an independent naming source, not an independent measurement. Under
our own taxonomy that lands as NAMED — the same classification reg 47 (Flow Rate) carries for
exactly this kind of evidence. It's not pedantry: that column is the thing that stops a
well-evidenced register getting overturned on thin grounds later, so it only works if we hold the
line on it consistently.

Regs 45 and 50 are both currently CONFIRMED against physics, so to overturn them we need evidence at
that level. Below is what I think would do it — and in both cases I think the data already exists.

Reg 45 — you've found a real problem, but I think the fix is the other way round

First, the mechanical issue: the two lines below your edit are context, so they survive the merge and
the block ends up self-contradicting —

# CONFIRMED: Compressor discharge gas temp. Matches HP installer page.
# Previously misnamed "DHW Cylinder Temp" - not available via Modbus
# Previously misnamed "Compressor Shell Temp" — reg 56 is the actual
# discharge temp (40.8°C), confirming this is NOT a compressor sensor.

And reg 56's own comment, further down and also untouched, argues directly against the change:

This SUPPORTS my reg 45 = DHW cylinder interpretation — if reg 56 is the actual discharge
temp, then reg 45 at 54.4°C cannot also be discharge.

So we'd ship two discharge temperatures. Regs 45 and 56 have to move together or not at all.

Now the substance — and you're right that something is wrong here, because identified.md has said
"Discharge Gas Temp" for reg 45 all along while the decoder said "DHW Cylinder Temp". Those have
disagreed for months and nobody caught it. Good spot.

My reading is that the decoder is the correct one. During the DHW cycle on 2026-02-18 (06:30–08:21)
reg 45 goes 52.4 → 54.4°C, creeping toward the 55°C setpoint over about two hours. That's
cylinder-probe behaviour — slow, monotonic, asymptotic. Discharge gas temperature swings within
seconds and tracks compressor frequency.

The test: plot reg 45, reg 56 and reg 19 (Compressor Frequency) across that window.

• reg 45 smooth while reg 56 follows reg 19 → it's the cylinder, and identified.md needs correcting
  instead.
• reg 45 follows reg 19 → you're right, and we rename reg 56 in the same PR.

I'm happy to be wrong on this. But whichever way it goes, we should fix both registers and the doc in
one commit so they can't drift apart again.

Reg 50 — plausible, but it collides with reg 24

Reg 24 is already Suction Pressure, CONFIRMED by R290 P–T physics:

Steady 608 kPa (×0.1), drops to 480 kPa at defrost. R290 sat at 480 kPa = 0°C matches R55.

That's 6.08 bar steady. Reg 50's mode means are idle 5.29, heating 3.56, DHW 3.20. If reg 50 is
suction in bar, the two disagree by about 2.5 bar during heating — they can't both be it.

To be clear, your reading is physically coherent. Idle 5.29 bar equalised, dropping to 3.56 in
heating and 3.20 in DHW as lift increases, is textbook suction behaviour, and it explains the
"inversely correlated with power" observation just as well as COP does. That's the problem: the same
numbers fit both stories, which is exactly the case where a label can't decide it.

Three tests, all on data we already have. Any one would settle it:

1. Direct. If reg 50 is suction pressure, reg_50 × 100 (kPa) must track reg_24 × 10 (kPa)
   sample-for-sample in the CSV logs. If they don't, one is misidentified.
2. R290 saturation. Same method that confirmed regs 24 and 48 — convert reg 50 to R290 saturation
   temperature and compare against reg 55 (Evaporator Temp).
3. Defrost. During reverse-cycle defrost reg 64 goes negative. A COP goes negative or undefined;
   a suction pressure just rises. We have the 2026-04-11 and AdamLC 13-Apr defrost datasets in the
   repo.

Test 3 is probably an afternoon's work and would be conclusive. If it comes out your way I'll merge
it happily — and reg 24 then needs a hard look, because its own comment has a scale muddle in it
("6080 kPa ≈ 60.8 bar. Plausible for R32") that nobody has unpicked.

Reg 52 — happy to take this now

This one's a clear win: reg 52 is currently unmapped and shows up as "Modbus Reg 52", so naming it
costs nothing and helps everyone. Two small things:

• Could you add the observed range? The identified.md cell is —, and ×1 in Pa is an assumption —
  if the raw values sit in 0–100 it's more likely a percentage. A monobloc with an axial fan normally
  sees ~0 Pa external static, so I'd like to see real numbers before we commit to the unit.
• Mark it NAMED rather than CONFIRMED until that range is in.

Then it can go in on its own and you'll have something merged while we work the other two.

Breaking change

Reg 50 moves from unitless/no-device-class to bar/pressure. The unique_id doesn't change, so
the entity survives and anyone with a COP dashboard or template sensor on
sensor.cosy_reported_cop silently starts reading a pressure. If we do land it, it needs a
### Breaking section like 4.9.0 had, telling people what to check.

Nits

Trailing whitespace on the blank line after the reg 52 entry:

And the typo:

    # CONFIRMED: Cross-validated with HP installer page during DHW cycle.

Also — if regs 50 and 52 do land, they should use the precision feature from your last PR: reg 50 at
scale 0.01 wants "display_precision": 2, and reg 52 at scale 1 wants "display_precision": 0,
which works now precisely because of your is not None fix. Nice when that comes round.

---

Sorry to push back on two of three — the installer page really is a useful source and I'd like more
of it. It just can't outrank a register confirmed by refrigerant physics on its own. Run any one of
those defrost/P–T checks and I'll take the lot.