Refactoring Zone classes and ideas for functionality

[Moritz-Schmidt]

Currently, the TadoXZone Class inherits from the TadoZone Class which gives the TadoXZone class a lot of attributes which are not used by Tado X. Also the from_data function is quite complex with the kwargs dict which also doesn't ensure typing.

I want to propose creating an abstract base class which contains all the common attributes and having the TadoZone and the TadoXZone both inherit from the common abstract base class. To simplify the from_data method I'd suggest omitting it and doing the logic in the __init__ function. This can be done backwards-compatible by initializing the Class from the from_data function with directly passing the data object to the __init__ function.
That way default values can be set in the attribute definitions of the class. I think this would reduce the overall lines of code and increase readability. It would also make it possible to correctly type it.

I've also had the Idea to use the Zone classes not only as a data structure but also for all the zone-related functionality. This however means that the zone class would need to have access to the Http instance. This Idea is also a bit contradictory to the Idea above since the __init__ function would need to have another functionality.

A example what the later Idea would look like:

zone = Zone(http=http, zone_id=1)  # either fetch the zone state in the init function or lazy load when accessed
print(zone.current_temp)
zone.set_overlay(overlay_mode="MANUAL", set_temp=20)
zone.update_data()

This approach could be backward-compatible; for instance, Tado.set_overlay might internally use the zone class:

def set_zone_overlay(
        self, zone, overlay_mode, set_temp=None, ...
    ):
    return Zone(http=http, zone_id=zone).set_overlay(overlay_mode...)

I look forward to feedback on both the abstract base class proposal and the potential expansion of zone class functionality.

[wmalgadey]

I sure like the idea of an abstract base class, it is the proper way to extend the functionality. I personally wasn't aware, that abstraction can be achieved with python 😀.

But I do not like adding the http as a dependency to the zone class on the other hand. The current decoupled implementation has a good separation of concerns.

Moving the initialization to the init method would make sense IMO, because I do not really like the kwargs feature too. It is again a lack of my python knowledge, whereas I thought this would be the python way to do initialization 😄

[Moritz-Schmidt]

Thanks for your reply! I'll go ahead and implement it without moving the zone functionality to the zone class.

[wmalgadey]

I just did investigate a bit into the API itself by doing some test to #118. There is a valid point in separating some functionality:

• Some endpoints are universal between Tado and Tado X... All endpoints without a zone or device!
• The endpoints with zone_id parameter, will change with Tado X in corresponding rooms*-calls!

I don't know, what to do with this information yet 😁, but I think we should somehow differentiate between those changes in TadoX and Tado implementation.

[Moritz-Schmidt]

While starting work on this I realized that it'd be better to do typing / different data structures first and this later. We'll have some time to think about what to do with that information and how to change those classes.
Separating the universal endpoints from those that differ was exactly the idea I had with #128 too.

Basically I think we have three different "types" of endpoints:

• Home-related: Information about the Home, presence stuff, eiq. Those are afaik mostly universal between Tado v3/v2/... and Tado X
• Zone/Room-related: everything that takes a zone_id like setting the overlay or getting climate info. Those differ between v3/v2/... and X
• Device-related: everything that takes a device_id like setting the temperature offset. Those differ between v3/v2/... and X too

Essentially this could be handled in two Ways:

1. one class for each version which does everything with the universal functions in an abstract base class (like it's done now and in Refactoring the Tado Classes. #128).
2. one class for the Home (universal for X and pre X), one for the Zones (v3/v2/...) and one for Rooms (X) with universal functionality in an abstract base class if there is any and one for pre-X devices and one for X devices, again if needed with universal functionality in an abstract base class.

Let me know if you want an example what 2. could look like, I don't know if my description is really clear.

I don't really know which way would be better, I'd slightly prefer 2. however both have pros and cons. But this is what this discussion is for :)

[wmalgadey]

I like the idea, and do understand the intent 👍