Decode Elster sentinel values as unavailable instead of garbage numbers

[adrai]

Related: #363 (finding 2)

Symptom: scaled numeric properties render impossible values when the
controller has no data:

• MINTEMP (HK2) showed -2867.2 °C while the panel shows AUS
  (raw 0x9000 through the int16 cast)
• on a pump without DHW, WAERMEERTRAG_WW_SUMME_MWH showed 32.768 MWh
  and EL_ENERGIEAUFNAHME_WW_SUMME_KWH 32,768,000 kWh (raw 0x8000)

Fix: in GetValueByType, return NAN for 0x8000 ("not available") on
et_dec_val/et_cent_val/et_mil_val/et_double_val/et_triple_val, and for
0x9000 ("AUS") on et_dec_val. ESPHome then reports the entity as
unavailable in HA instead of publishing garbage.

Deliberately not touched: et_default/bitfield types (0x8000 could be a
legitimate raw word there) and the write path (GetRawByType).

Tested on: WPE-I 08 HK 230 Premium via ESP32-C6, ESPHome 2026.6.5 —
MINTEMP now unavailable, matching the panel's AUS.

[Copilot]

Pull request overview

Updates Elster value decoding so known sentinel raw words are mapped to NAN for specific scaled numeric types, allowing ESPHome/Home Assistant to treat those entities as unavailable rather than publishing impossible numeric values.

Changes:

• Return NAN for 0x8000 (“not available”) across et_dec_val, et_cent_val, et_mil_val, et_double_val, and et_triple_val.
• Return NAN for 0x9000 (“AUS”) specifically for et_dec_val.
• Add <cmath> include to support NaN usage.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Hello! This is an automated message regarding your pull request. We've noticed that this PR has been inactive for a while, with no updates or activity in the last 30 days. If no further updates or responses are provided within the next 7 days, this pull request will be closed as stale. If you're still actively working on this PR, please leave a comment to let us know. We're happy to keep it open and review your changes. Otherwise, feel free to reopen the PR if you have more work to contribute in the future. Thank you for your understanding and contributions!

[adrai]

not stale

[github-actions]

Hello! This is an automated message regarding your pull request. We've noticed that this PR has been inactive for a while, with no updates or activity in the last 30 days. If no further updates or responses are provided within the next 7 days, this pull request will be closed as stale. If you're still actively working on this PR, please leave a comment to let us know. We're happy to keep it open and review your changes. Otherwise, feel free to reopen the PR if you have more work to contribute in the future. Thank you for your understanding and contributions!

[adrai]

no, please don't close this....

[kr0ner]

@adrai since this change is touching common code, I don't want to merge this. I have no clue what implications this will bring for other variants. IMHO the correct way, at least for the sensors that show value 2^15 (32768), would be to remove them for you config. For the HK2 I'd propose you add min/max values to the temperatures and set them to the valid range instead.

[adrai]

Thanks for taking the time, and no worries about the delay at all.

That makes sense, I've taken the config level route. For the 32768 sensors you are right that they simply should not exist on my machine: the WPE-I has no DHW, so those four WW counters are meaningless here, and the variant no longer includes them.

For HK2 your min/max idea works nicely: a clamp filter with ignore_out_of_range drops the reading instead of publishing it, so the entity stays unavailable, which is what the panel shows (AUS). That is now in the WPE-I variant in #367, and I dropped this commit from it, so no common code is touched anymore.

I'll leave this PR open in case you ever want to revisit the decoding side, but feel free to close it. Just for the record and not asking for any change: 0x8000 is the standard Elster marker for "value not available" and 0x9000 is what the WPM sends for "AUS".