Fix POINTTAPI child lock switch resolution and thermostat path handling

[jfhautenauven]

Summary

This PR fixes multiple POINTTAPI thermostat-valve issues found during live testing and dump validation.

What is fixed

• Fixes child-lock switch device attachment:
  • dynamic thermostat-valve child-lock switches now attach to the dedicated thermostat-valve device, not the gateway fallback.
• Adds support for thermostat-style device paths:
  • handles /devices/deviceN/thermostat/* alongside existing etrv paths for valve-related entities.
• Makes child-lock switch discovery strict and consistent:
  • a switch is created only when a concrete .../childLock/enabled leaf is available in coordinator data.
  • no parent .../childLock fallback switch is exposed.
• Strengthens discovery behavior for mixed layouts:
  • supports both direct device-tree paths and reference-following to enabled leaf nodes.

Why this is needed

• Real-world dumps show different path layouts by device type:
  • device1 can expose thermostat paths (/thermostat/...),
  • other valves can expose etrv paths.
• Child-lock state/write semantics should mirror existing enabled-leaf switches (like /gateway/notificationLight/enabled) to avoid ambiguous parent-node behavior.
• Without these fixes, users can see wrong device grouping in HA and/or missing or incorrect child-lock switches.

Validation

• Updated and added unit tests for:
  • enabled-leaf child-lock discovery,
  • thermostat-path variants,
  • strict no-switch behavior when no concrete enabled path is available.
• Test results:
  • unittests/test_pointtapi_new_entities.py: passing
  • unittests/test_pointtapi_entity_coverage.py: passing

[jfhautenauven]

@CaseyRo : all my changes work in 1.5.0 beta 1 except this HUUUGE mistake I made on the child lock stuff.

Two mistakes : the way the switch is linked to what device ... makes something absolutely incoherent under the gateway device. See picture here :

Second error : I assumed by reading the dumps I got that the childlock information was directly exposed on leaf /ertv/childlock or /thermostat/childlock ... and that proved incorrect ... those nodes are the reference list of the childlock related stuff.
The references list /ertv/childLock/enabled and thats the correct, writable node there. Same way the notification light for the gateway works in fact ... I overlooked that.

This PR should hopefully fix it, and a good reason to tag as 1.5.0 beta 2 so that I can test it further :)

Enjoy :)

[jfhautenauven]

Took care of

"Leftover from #20 cache removal (63b80d9): unittests/test_pointtapi_setup.py:62 and :95 still define async_load_persistent_cache on the fake coordinators — the real method is gone, so the stubs are dead. Delete both when next in that file."

that you mentionned on issue #19

[CaseyRo]

Verified on my side: branch is on current master, ruff clean, 539 green locally. Approving. ✅

The actual fix is the switch constructor finally honouring description.device_info_fn — the child-lock descriptions were already carrying the valve device, the entity just never asked. Same shape as the sensors, so that's the right place. Going strict on the .../childLock/enabled leaf and dropping the nested-row fallback is fine by me too: that fallback was #20's own from a week ago, so nobody else's hardware has ever leaned on it.

Two questions, neither blocking:

1. Did you toggle child lock live? The PR says "found during live testing", so I assume the PUT on the .../enabled leaf was accepted by the gateway and the next refresh reflected it — worth one line of confirmation since it's the first write we do under /devices.
2. _thermostat_valve_device_path_from_data now cross-products the normalised suffixes with the four layouts, so it also probes paths like /devices/device1/etrv/etrv/temperatureActual. Harmless (dict lookup, never present), just more candidates than the two layouts need. Trim if you're in there anyway; ignore otherwise.

Side note: GitHub never fired the pull_request CI run for this PR — zero check-runs on 01a0ed7 while the workflow trigger is unchanged. I've closed/reopened to nudge it. Local numbers above stand regardless.

Queued for 1.5.0-beta.2. #19 closes with this — items 1–4 already landed in #20, the stubs were the last of it. 🙏

[jfhautenauven]

@CaseyRo :

🔍 To answer

Did you toggle the child lock live?

The PR says it was “found during live testing”, so I assume that the PUT on the .../enabled leaf was successfully accepted by the gateway, and that the following refresh reflected the change.

👉 It would be worth adding a one-line confirmation of this, since this is the first write operation we're doing under /devices.

🧪 What I actually tested

I initially tested it directly from Home Assistant by clicking the child-lock control.

➡️ This resulted in a 403 error.

That is what I would expect from a PUT being sent to an endpoint that doesn't actually exist in the Bosch API.

I then tested it on another setup/codebase, using the XMPP paths I used back when I was developing my Jeedom plugin.

It's admittedly a rather ghetto way of manually sending paths 😅 — but it seems to work.
Until we tackle the issue #24 , it's my only resort ... but as I told you, this could be fixed in a short while, as described in the issue.

🤔 The missing part

The real question is:

Did I verify that everything is correctly wired end-to-end in the Home Assistant integration?

The honest answer is: no. 😅

My current workflow is basically:

🔧 Change the code
⏳ Wait for the next beta tag/release
🧪 Test it again
🔁 Repeat

So while I have confirmed that the underlying API path works, I haven't yet properly validated the complete flow through the Home Assistant integration itself.

Definitely not the most professional testing workflow, I reckon. 😄

[jfhautenauven]

@CaseyRo : just checked

"_thermostat_valve_device_path_from_data now cross-products the normalised suffixes with the four layouts, so it also probes paths like /devices/device1/etrv/etrv/temperatureActual. Harmless (dict lookup, never present), just more candidates than the two layouts need. Trim if you're in there anyway; ignore otherwise."

I'll fix it now :) you are right ... cartesian product made some absurd paths ... can be fixed ... hold my beer

[jfhautenauven]

@CaseyRo : aaaaand, it's fixed :)

[CaseyRo]

Merged and out as v1.5.0-beta.2. 548 green on master after the squash. Thanks for turning this around the same day, @jfhautenauven 🔒🚀

[jfhautenauven]

@CaseyRo : you'll enjoy the next PR too :D I lied, i couldn't resist to attack bug #24 :D