add detection of tado generation

[karlbeecken]

Proposed Changes

implements basic detection if the home is a V3 or X home, including tests and a new get_home function

Related Issues

part of #136

[karlbeecken]

My main question would be how we want to handle the slight differences between the V3 and X API going forward. Here I did something like this:

 async def get_home(self) -> Home:
        """Get the home."""
        response = await self._request(f"homes/{self._home_id}")
        obj = orjson.loads(response)

        # For Tado X, enrich the home payload from hops.tado.com.
        # The X payload provides roomCount, which maps to zonesCount in our model.
        if obj.get("generation") == TadoLine.LINE_X.value:
            try:
                x_response = await self._request(
                    f"homes/{self._home_id}",
                    endpoint=TADO_X_URL,
                )
                x_obj = orjson.loads(x_response)

                if "roomCount" in x_obj:
                    obj["zonesCount"] = x_obj["roomCount"]
                if "isHeatPumpInstalled" in x_obj:
                    obj["isHeatPumpInstalled"] = x_obj["isHeatPumpInstalled"]
                if "supportsFlowTemperatureOptimization" in x_obj:
                    obj["supportsFlowTemperatureOptimization"] = x_obj[
                        "supportsFlowTemperatureOptimization"
                    ]
            except TadoError as err:
                _LOGGER.debug(
                    "Failed to enrich Tado X home data from hops endpoint: %s",
                    err,
                )

        return Home.from_dict(obj)

But I am not sure if that is the optimal way, as I feel it could add a lot of boilerplate. Any thoughts on this?

[wmalgadey]

on one hand it will create a lot of extra code for every method and for every change in the api. I am naturally more a fan of abstraction here, but adding the complete overhead we added in PyTado seems also not the right way to solve it.

[wmalgadey]

What if we put this "enricher" code into its own class and then call only an "EnricherFactory" within it, which would then call the actual enricher class based on the "generation" and simply modify the current object?

Then the code is separated, we can call the enricher wherever we need it, and we don't clutter up our methods so much!

Could be a main enricher we create on first contact, because this "generation" won't change for the complete api of this home!

[wmalgadey]

@karlbeecken should we close this PR? in Favor of #151?

[karlbeecken]

@wmalgadey we could, although iirc #151 doesn't auto-detect what the tado line of the user is, so that would be needed again. I can add that to the other PR though, I guess that'll be cleaner than trying to use this PR for that

[wmalgadey]

@wmalgadey we could, although iirc #151 doesn't auto-detect what the tado line of the user is, so that would be needed again. I can add that to the other PR though, I guess that'll be cleaner than trying to use this PR for that

I totally agree. so we close this PR