POINTTAPI: generic Bosch services are not compatible with POINTTAPI

[jfhautenauven]

Description

I'm currently using Bosch Home Assistant integration v1.5.0-beta.1 with a CT200 connected through POINTTAPI.

While testing the available Bosch services, I noticed that the generic services such as:

• bosch.send_custom_get
• bosch.send_custom_put_string
• bosch.send_custom_put_float
• bosch.update_thermostat
• bosch.debug_scan

appear to have been designed for the legacy XMPP/HTTP implementation and are not fully compatible with the new POINTTAPI implementation.

In particular, bosch.send_custom_get is exposed in Home Assistant, but calling it with a POINTTAPI device results in:

Failed to perform action bosch.send_custom_get. Unknown error

Technical details

In v1.5.0-beta.1, POINTTAPI uses the new PoinTTAPIClient, which exposes:

async def get(self, uri: str)
async def put(self, uri: str, value)
async def bulk(self, paths: list[str])

However, the generic services still call the legacy methods through BoschGatewayEntry:

async def custom_get(self, path):
    return await self.gateway.raw_query(path=path)

async def custom_put(self, path: str, value):
    await self.gateway.raw_put(path=path, value=value)

For a POINTTAPI device, self.gateway is a PoinTTAPIClient, which does not provide raw_query() or raw_put().

Therefore the current call chain is effectively:

bosch.send_custom_get
        ↓
custom_get()
        ↓
self.gateway.raw_query()
        ↓
PoinTTAPIClient
        ↓
Unknown error

The POINTTAPI client instead provides get() and put().

Suggested implementation

Could the generic services be adapted to support both protocols?

For example:

async def custom_get(self, path):
    async with self._update_lock:
        if self._protocol == POINTTAPI:
            return await self.gateway.get(path)
        return await self.gateway.raw_query(path=path)

And similarly for PUT:

async def custom_put(self, path, value):
    if self._protocol == POINTTAPI:
        return await self.gateway.put(path, value)
    return await self.gateway.raw_put(path=path, value=value)

This would allow the existing Home Assistant services to work transparently with both legacy Bosch protocols and POINTTAPI.

debug_scan

The same issue seems to apply to bosch.debug_scan.

Currently, debug_scan is not registered for POINTTAPI. The code deliberately registers the debug services only on the XMPP/HTTP path.

However, POINTTAPI already has a useful bulk() mechanism which can query multiple resources in a single request.

It would therefore be very useful if bosch.debug_scan could also support POINTTAPI, ideally using the existing PoinTTAPIClient.bulk() implementation.

This would make it possible to discover the resources exposed by a CT200 through POINTTAPI and would greatly simplify troubleshooting and development of additional entities.

Expected behaviour

For a POINTTAPI CT200, I would expect:

bosch.send_custom_get

to perform a GET against:

/gateways/<deviceId>/resource/<path>

using the existing POINTTAPI authentication/token mechanism.

Likewise:

bosch.send_custom_put_string
bosch.send_custom_put_float

should use the POINTTAPI PUT endpoint.

And ideally:

bosch.debug_scan

should be available for POINTTAPI devices as well.

Why this would be useful

Having the generic GET/PUT/debug services working with POINTTAPI would make the integration significantly easier to extend.

It would allow users and developers to test newly discovered Bosch resources directly from Home Assistant without having to modify the integration every time a new POINTTAPI resource is found.

This is particularly useful for the CT200 / EasyControl, where POINTTAPI exposes many resources that are not yet represented as Home Assistant entities.

Thanks for the work on the POINTTAPI implementation! This seems like a relatively small gap between the existing generic service layer and the new POINTTAPI client, and fixing it would make the integration much more powerful for POINTTAPI users.

[CaseyRo]

@jfhautenauven Confirmed — your diagnosis is exact, and thanks for tracing it down to the call chain rather than just reporting the "Unknown error". 🙏

BoschGatewayEntry.custom_get / custom_put in __init__.py call raw_query / raw_put unconditionally, async_register_services registers the generic services for every entry regardless of protocol, and PoinTTAPIClient only speaks get / put / bulk. So on a cloud entry the services are advertised and then blow up on an AttributeError. That's a bug, not a missing feature — the fix is the protocol branch you sketched, in those two methods, and nowhere else, since both services route through them.

On debug_scan I'd go a different way than porting the rawscan:

• The diagnostics download already dumps coordinator_data — every path the reference walk discovered, with the raw available / unitOfMeasure flags — which is what bosch_scan.json is for on the XMPP side.
• What diagnostics can't do is a live GET on a path the walk never reached. That is exactly send_custom_get, once it works. Between the two, the "discover resources on a CT200" use case is covered without a second scan implementation to maintain.

So: fix custom_get / custom_put for POINTTAPI (small, with a test each), leave debug_scan XMPP-only and document diagnostics + send_custom_get as the cloud equivalent. One thing I haven't checked yet is whether update_thermostat → thermostat_refresh() does anything sensible on a cloud entry; it probably wants to become a coordinator refresh. I'll look at that in the same pass.

Queued behind #23 for 1.5.0-beta.2. If you'd rather take it yourself, it's yours — you've already written half the diff in the issue. 🚀

[jfhautenauven]

@CaseyRo : TBH, i'll leave this one to you, I'm running out of time. For the rest of this month, I'll concentrate on fixing and stabilization of 1.5.0 beta.

Although, if this can wait a little, I could take it start of next month, somewhere / sometime around at least :)

[jfhautenauven]

@CaseyRo : pretty sure that the changes included in my PR are close to what you expected ... but yeah, same as always, I can only test when this goes to the next beta stage.