📣 v1.0.0 feedback thread — does it work on your setup?

[CaseyRo]

v1.0.0 overhauls the cloud (POINTTAPI) path: bulk polling, gateway auto-discovery, native boost (real device boost — the manual-mode workaround is now only a fallback), plus away mode, extra hot water, and thermal-disinfect controls.

It's verified against one live CT200 — mine. Your firmware, zone count, solar setup, or hot-water type may exercise paths mine can't. That's where you come in. 🙏

✅ If it works

Reply here with:

• Device + firmware (firmware is a sensor on the Gateway device)
• System layout: zones, solar yes/no, instant vs tank hot water
• Which features you tried (boost! away mode! extra hot water!)
• For boost: which route the probe picked — find boost_probe_result in the diagnostics download (Settings → Devices & Services → Bosch → ⋮ → Download diagnostics)

🐛 If something broke

Don't reply here — open a bug report instead. The form walks you through the diagnostics file and debug log capture. Full instructions: Testing & reporting in the README.

⚠️ One rule

Never paste your access token, refresh token, or OAuth callback URL. The diagnostics download redacts credentials automatically — use it instead of hand-copying data.

[jonlove234]

I got it working but had to use the script (with some tweaks) to get the correct code:

#!/bin/bash
# Capture the OAuth callback URL for pasting into Home Assistant.
# Does NOT consume the code — safe to paste into HA afterwards.
set -e
cd "$(dirname "$0")"
op run --env-file=.env -- uv run --python 3.11 --with playwright --with playwright-stealth --with setuptools --with aiohttp python test_pointtapi_playwright.py --ha

[CaseyRo]

Thanks so much for testing and reporting back — really glad it's working on your setup, and this is exactly the feedback that makes the next release better. 🙏

A few things I'd love to pin down so I can fix the documented flow for the next person:

1. What were the tweaks? If you can paste your version of the script (or a diff against the repo's test_pointtapi_playwright.py --ha flow), I'll fold the working bits back in so nobody has to hand-patch it.

2. The dependencies. Your run pulls in playwright, playwright-stealth, setuptools, and aiohttp via uv run and pins Python 3.11. Did the documented command fail to resolve those, or was pinning 3.11 the key fix? I want the documented setup to work without the extra --with flags.

3. "Does NOT consume the code." Your note that it's safe to paste into HA afterwards suggests the current flow does consume the OAuth code — which would break the paste-into-HA step. If that matches what you saw, it's a real bug and I'll make the capture non-consuming by default. Confirming this is the single most useful thing.

One safety note: never paste the callback URL, access token, or refresh token into a public issue — the integration's Diagnostics download redacts those automatically, so use that if you need to share anything.

Thanks again! If you're up for it, drop your device model + firmware here too, so I know which EasyControl variant this path is confirmed on.

[jonlove234]

1. just the last line of the script
2. the documented command didn't resolve those for me (and i also needed the 1password package). i'd also say that the .env needing to have the ID added wasn't clear but i got it in the end 😅
3. i think that line is in the current version? i didn't add it iirc

and model is bosch easycontrol ct200, firmware 5.04.00

[jfhautenauven]

Feedback after testing

Hello! 👋

I’ve tested the new integration and wanted to share some feedback.

🛠️ Installation / migration

Installation via HACS was easy and it correctly replaced the old integration from Pszafer.

However, even though my existing entities were migrated and still visible in Home Assistant, the integration itself could not initialize and reported an issue with my login/password.

I had to completely remove my existing CT200 configuration, which was previously connected via XMPP, and then go through the login procedure again using POINTTAPI.

So unfortunately, XMPP → POINTTAPI is not really an in-place upgrade.

🔐 POINTTAPI login

The login procedure was the most confusing part for me.

It wasn't immediately clear what was expected regarding the login URL or how exactly it needed to be transformed.

I eventually used the Firefox extension to obtain the required URL, but I think the process could still be quite difficult for a newcomer.

💡 Suggestion: improve the documentation with a step-by-step explanation showing:

where to get the login URL
how to transform it
what needs to be copied/pasted into Home Assistant
ideally, an example of the expected result

That would make the setup much easier for new users.

🌡️ ETRVs / per-room control

Once the login was successful and the integration was properly configured, everything seemed to work — except that my ETRVs are no longer detected.

This means I lost the per-room temperature control, which is a pretty important feature for my setup.

Since I also had to completely remove the original CT200 configuration, I effectively lost functionality compared to the previous integration.

I have 12 ETRVs, so once ETRV support is restored, I will most likely have to reconfigure the whole setup again.

For now, this was enough for me to stop testing:

ETRVs not supported → rollback 😅

🧪 Happy to help with testing

Despite this, I'm very happy to see this integration being worked on and I'm more than willing to help with testing/debugging.

I can provide logs, diagnostics, test results, or test specific functionality on a real CT200 setup if that helps.

⚙️ Setup
CT200 firmware: 5.04.00
Zones: 12
Solar: No
Hot water tank: Yes
ETRVs: 12

I didn't get to test the new features yet, as I stopped once I discovered that ETRVs were not supported and rolled back. 😉

Thanks for the work on this! 🙏

[jfhautenauven]

@CaseyRo : mmmh, I see regression on beta 5, the names of the zones are gone again, except zn1

[CaseyRo]

@jfhautenauven good catch, and fixed — v1.2.0-beta.6: https://github.com/CaseyRo/ha_bosch/releases/tag/v1.2.0-beta.6

Root cause, since you'll appreciate it: your open-window switch and window sensor from #14 were the first switch/binary-sensor entities to ever attach to zone devices — and those two constructors still registered the device without the room name (the fallback "Heating Zone znX"). Whichever entity registered last won the device name, so the rooms flip-flopped away. Not your bug — mine: I hardened exactly this in beta.4 but only for the entity classes that had zone paths at the time. Now every constructor resolves the name identically, and a regression test builds one entity of every zone-attachable class and asserts they all agree — so this can't sneak back with your next batch of entities. 😄

Update + reload once and your rooms should reappear.