Wrong MODEL_ID source: PRODUCT_CODE from /debug/config/info ≠ key prefix in /DWI/getInstantValues (mapping exists but is never matched)

[ryja81]

Summary

On a Vágner Pool KIT VA DOS BASIC Chlor — pH + ORP (Pt) (Czech rebrand of SEKO PoolDose / Kommander Spot),
python-pooldose==0.7.0 (shipped with Home Assistant Core 2025.11.3 as the pooldose integration) cannot decode any values
from the device, even though a matching mapping file is already present in the package.

Root cause is a two-step naming mismatch inside the device API itself, which the library doesn't compensate for:

• GET /api/v1/debug/config/info returns DEVICES[0].PRODUCT_CODE = PDHC1H1HAR1V0
• POST /api/v1/DWI/getInstantValues returns telemetry keys prefixed with PDPR1H1HAR1V0_FW539224_… (PDPR, not PDHC)

pooldose/client.py uses PRODUCT_CODE as MODEL_ID for both mapping-file lookup and the runtime prefix used to read
instant values, so neither step ever matches reality on this device.

Interestingly, the package already ships mappings/model_PDPR1H1HAR1V0_FW539224.json (22 entries), with conversion strings
hardcoded to |PDPR1H1HAR1V0_FW539224_LABEL_…|. The mapping was clearly authored with PDPR in mind — but client.py never picks
it up because it's keyed off PRODUCT_CODE.

Where in the code

Two related lines in client.py (v0.7.0):

# client.py: ~L161  (inside _load_device_info)
self.device_info["MODEL_ID"] = device.get("PRODUCT_CODE")   # → "PDHC1H1HAR1V0"

# client.py: ~L170
model_id = self.device_info.get("MODEL_ID")
fw_code  = self.device_info.get("FW_CODE")
self._mapping_info = await MappingInfo.load(str(model_id), str(fw_code))
# → tries to load model_PDHC1H1HAR1V0_FW539224.json — does not exist

# client.py: ~L259-262  (inside instant_values)
model_id = str(self.device_info.get("MODEL_ID", ""))   # → "PDHC1H1HAR1V0"
fw_code  = str(self.device_info.get("FW_CODE", ""))
prefix   = f"{model_id}_FW{fw_code}_"                  # → "PDHC1H1HAR1V0_FW539224_"
return ..., InstantValues(device_raw_data, mapping, prefix, ...)

InstantValues then does full_device_key = f"{self._prefix}{device_key}" (instant_values.py:159) → looks for keys like
PDHC1H1HAR1V0_FW539224_w_1f0io7hq6 in device_raw_data, but the box only ever sends PDPR1H1HAR1V0_FW539224_w_1f0io7hq6.

So even if the mapping file is renamed to model_PDHC1H1HAR1V0_FW539224.json, the prefix computed at runtime is still PDHC…,
and every device_raw_data.get(...) returns None.

Real diagnostic data from the device (LAN)

GET /api/v1/debug/config/info — DEVICE block (relevant fields):

DID:           012400003954_DEVICE
name:          VA DOS CONTROL
PRODUCT_CODE:  PDHC1H1HAR1V0      ← used as MODEL_ID by the lib
FW_CODE:       539224
release:       2.11
build:         1

POST /api/v1/DWI/getInstantValues — every key in devicedata.012400003954_DEVICE is prefixed PDPR1H1HAR1V0_FW539224_…, e.g.:

PDPR1H1HAR1V0_FW539224_w_1f0inr5mg     (current pH:    6.8)
PDPR1H1HAR1V0_FW539224_w_1f0invtg9     (current ORP:   755 mV)
PDPR1H1HAR1V0_FW539224_w_1f0io42cq     (current Cl:    0.2)
PDPR1H1HAR1V0_FW539224_w_1f0io7hq6     (water temp:    18.5 °C)
PDPR1H1HAR1V0_FW539224_w_1f0irf02j     (pH setpoint:   7.2)
PDPR1H1HAR1V0_FW539224_w_1f0ishl5i     (ORP setpoint:  700 mV)
…

Happy to paste the full payloads of both endpoints if it helps.

Error from HA log (debug enabled)

WARNING (MainThread) [pooldose.mappings.mapping_info] Error loading model mapping:
[Errno 2] No such file or directory:
'/usr/local/lib/python3.13/site-packages/pooldose/mappings/model_PDHC1H1HAR1V0_FW539224.json'

DEBUG  (MainThread) [homeassistant.components.pooldose.coordinator]
Finished fetching Pooldose data in 0.6 seconds (success: False)

Why I think PDHC vs PDPR is a SEKO firmware quirk, not a per-device misconfiguration

• The shipped model_PDPR1H1HAR1V0_FW539224.json already hardcodes |PDPR1H1HAR1V0_FW539224_LABEL_…| strings inside its
  conversion maps. So the mapping author already had PDPR… payloads in front of them when writing the file.
• Issue model_PDHC1H1HAR1V1_FW539224.json #13 describes a related mismatch (V1 in identification, V0 in values) on what looks like the same generation of hardware.
• Two separate fields (the PRODUCT_CODE shown to the user/web UI vs. the per-key namespace inside getInstantValues) come out
  of two unrelated parts of the SEKO firmware. They were apparently never meant to agree.

Suggested fix (one of these, in increasing order of robustness)

1. Derive the prefix from the actual telemetry payload, not from MODEL_ID. When fetching instant values, scan
   devicedata[device_id] for the longest common prefix that ends in _FW{fw_code}_, and use that for both the file lookup and the
   key prefix. This makes the lib resilient to any future SEKO renaming.

2. Alias PDHC1H1HAR1V0 → PDPR1H1HAR1V0 for both file lookup and prefix. Cheap, fixes my device today; less robust if SEKO
   introduces yet another family code.

3. Ship a PDHC1H1HAR1V0_FW539224.json whose internal conversion strings reference PDHC… AND change client.py to also
   rewrite the prefix → essentially a duplicated alias, more maintenance.

I'd suggest 1 (or 1 + 2 as belt and suspenders). Happy to send a PR if you'd prefer.

Workaround applied locally (verified)

Until upstream fix lands, monkey-patching _load_device_info in client.py:

# right after: self.device_info["MODEL_ID"] = device.get("PRODUCT_CODE")
if self.device_info["MODEL_ID"] == "PDHC1H1HAR1V0":
    self.device_info["MODEL_ID"] = "PDPR1H1HAR1V0"

This makes the lib (a) load the existing model_PDPR1H1HAR1V0_FW539224.json and (b) build a prefix that matches the real
getInstantValues keys. (Will report back once I've applied + restarted HA.)

Thanks for the great work on this integration!

[ryja81]

I applied locally — verified working

Monkey-patched _load_device_info in client.py:

# right after: self.device_info["MODEL_ID"] = device.get("PRODUCT_CODE")
if self.device_info["MODEL_ID"] == "PDHC1H1HAR1V0":
    self.device_info["MODEL_ID"] = "PDPR1H1HAR1V0"

After clearing __pycache__/client.cpython-313.pyc and restarting HA Core, coordinator now reports success: True and
entities populate from real telemetry, e.g.:

sensor.bazen_teplota   = 18 °C
sensor.bazen_ph        = 6.8
sensor.bazen_orp       = 758 mV
sensor.bazen_typ_davkovani_ph = acid
…

So both steps the patch fixes (file lookup → model_PDPR1H1HAR1V0_FW539224.json, runtime prefix → PDPR1H1HAR1V0_FW539224_) are
confirmed necessary; renaming the mapping file alone wouldn't have been enough.

[ryja81]

Quick follow-up after reading docs/device-support.md and the v0.9.0 source:

1. The device is explicitly listed as supported. device-support.md includes:

5. VÁGNER POOL VA DOS BASIC (PDHC1H1HAR1V0, FW 539224)

— exactly my hardware.

2. v0.9.0 already has the right mechanism but the wrong table. src/pooldose/constants.py defines:

MODEL_ALIASES: dict[str, str] = {
    "PDHC1H1HAR1V1": "PDPR1H1HAR1V0",   # VA DOS EXACT
    "PDPR1H1HAW102": "PDPR1H1HAW100",
}

client.py (v0.9.0) applies this dict before both MappingInfo.load(...) and prefix construction (lines ~103-108 and ~142-146) — exactly the fix this issue suggested. 🎉

The only thing missing is PDHC1H1HAR1V0 (= VA DOS BASIC) as a key. With it added, the existing model_PDPR1H1HAR1V0_FW539224.json mapping covers my device with no further changes.

3. Suggested one-line fix (in src/pooldose/constants.py):

 MODEL_ALIASES: dict[str, str] = {
+    "PDHC1H1HAR1V0": "PDPR1H1HAR1V0",   # VÁGNER POOL VA DOS BASIC (V0 hw, listed in device-support.md)
     "PDHC1H1HAR1V1": "PDPR1H1HAR1V0",   # VA DOS EXACT
     "PDPR1H1HAW102": "PDPR1H1HAW100",
 }

I'm happy to send a PR with that single-line addition + a small entry in the doc if helpful — let me know.

4. Diagnostic data per device-support.md workflow. Attaching all three required files (sensitive WiFi/AP data already removed):

• debuginfo.json (1.5 kB, GET /api/v1/debug/config/info)
  debuginfo.json
• instantvalues.json (15 kB, POST /api/v1/DWI/getInstantValues)
  instantvalues.json
• strings.json (33 kB, POST /api/v1/DWI/getDeviceLanguage with LANG=en)
  strings.json

For what it's worth, all three confirm the same picture: debuginfo.json reports PRODUCT_CODE: PDHC1H1HAR1V0, while every key in instantvalues.json and strings.json is prefixed PDPR1H1HAR1V0_FW539224_…. This is the same PDHC ↔ PDPR divergence the existing PDHC1H1HAR1V1 alias covers — it just needs the V0 entry too.

5. Local workaround in v0.7.0 (the version shipped with HA Core 2025.11.3) verified working by patching _load_device_info to translate PDHC1H1HAR1V0 → PDPR1H1HAR1V0 before mapping load. After patch, all 9 sensors populate (pH 6.8, ORP 758 mV, T 18.5 °C, …). On HA Core ≥ the version that ships python-pooldose>=0.9.0 + your accepted alias addition, the patch can be removed.

[lmaertin]

Hi @ryja81

thanks for your detailed analysis. I like the one-liner. Please provide this as PR if possible, so we have a clean history from issue to code.

[lmaertin]

@ronaldvdmeer since you improved the code with such device mappings, do you see any side effects here?

[ronaldvdmeer]

Hi @lmaertin,

I had a look at this, and my assessment is that this should be a safe change.

The important part is that the underlying logic was already generalized in the earlier alias work: MODEL_ALIASES is now the central place that resolves a reported PRODUCT_CODE to the model ID actually used for mapping lookup and runtime prefixes. Because of that, this issue looks like a missing alias entry, not a new behavioral change.

From the data in this issue, PDHC1H1HAR1V0 -> PDPR1H1HAR1V0 looks consistent with the earlier V1 -> V0 mismatch we already had:

• the device identifies itself as PDHC1H1HAR1V0
• the actual telemetry keys use PDPR1H1HAR1V0_FW539224_...
• the existing mapping file is already based on the PDPR... prefix

So I do not see meaningful side effects in the real client from adding this alias. It is the same class of firmware inconsistency that was already handled before.

The only thing I would keep in mind is consistency:

• add a small targeted test for mapping load and prefix resolution
• optionally align the mock_client as well, since it still seems to contain an older hardcoded special case for only the V1 variant

I would not switch to a more dynamic “detect prefix from payload” approach here. That is theoretically more robust, but also more invasive. For this codebase, extending the alias table is the simpler and more appropriate fix.

So in short: I think this is a good change and low risk.

[lmaertin]

Thanks for you detailed analysis @ronaldvdmeer

I fully support to keep the change as less immersive as possible as pool season starts and the number of users of the lib grows.

@ryja81 good for you?

I will not have capa to care about this change soon as I'm working on two other projects right now.

Looking forward to a PR raised from you, so I only need to care about the review and an api bump PR in HA core.

[ryja81]

Thanks both — and to keep momentum: PR is already up 👉 #43 (#43), single-line MODEL_ALIASES entry as discussed, body says Fixes #41 so the issue will auto-close on merge. Kept it intentionally minimal per the "less immersive" direction.

Happy to follow up with the two things @ronaldvdmeer mentioned if you'd like them in this PR (or as a small
follow-up):

• targeted test for MODEL_ALIASES resolution + mapping load,
• aligning mock_client with the V0 BASIC alias (currently only V1 EXACT is hardcoded there).

Side note from my side: I've meanwhile upgraded my HA Core to 2026.5.0 (fresh install on a new SSD setup) and re-verified — same root cause is still present on the python-pooldose shipped with that release, monkey-patch keeps it working, all sensor.bazen_* entities populate cleanly (pH 6.8, ORP 758 mV, T 18.5 °C, dosing types, …). Once #43 lands and the HA core bumps python-pooldose, the patch can be retired. Attaching a screenshot of the working entities for reference.

[lmaertin]

PR for Core Integration merged into HA dev branch, update will be Part of HA 2026.6