Support for Tado X

[Moritz-Schmidt]

Problem/Motivation

Currently, only pre line X devices are supported. Tado X has many API and functionality changes which are not compatible with V3, V2, etc.

Expected behaviour

Tado X being supported.

Proposed changes

Implementation of Tado X. I've already started working on it in a fork which I would like to merge later on. However there are some basic design choices which would have to be made. I'm opening this issue to discuss them:

1. Currently, the Tado class has methods which are the same for pre X and X but some are not. One way to approach this would be to implement Tado X in the same class with some new and some modified methods and to raise an exception on unsupported methods. Alternatively (which I think would be more elegant) there could be a common base class with everything that stayed the same over the generations and one class for pre line X and one for line X. Both inherit from the common base class but implement the features with API and functionality changes separately. The base class could be an abstract base class to keep typing mostly consistent. However, the detection if the system is line X or pre line X has to be done somewhere different than in the class itself.

2. there are some models which are mostly the same, but some properties have different names in the new API. For Example in the Device model the Device type isn't called deviceType anymore but just type. Mashumaro supports multiple aliases for this case but only with the Annotated notation. For the before mentioned device type this would be:

   device_type: Annotated[str, Alias("deviceType"), Alias("type")]

   I think it would be good to decide whether this notation should be used consistently with everything or if there should be separate models for X and pre X. Later would mean a lot of duplicated code but maybe better readability (personally I like the Annotatednotation more)

3. For some functions currently the argument type is str but I think an Enum would be more appropriate. For example for the Overlay termination type or the presence, this would ensure that the Input is always one of the supported options. Alternatively a Literal type with the options could be used, personally I like Enums more since there are suggestions in the IDE which options exist. (This has nothing to do with Tado X directly, but I would like to discuss it anyway.)

[erwindouna]

Thanks for sharing, @Moritz-Schmidt! I will use this in a later iteration once I have finished the overall library to be compatible with Home Assistent.
Your effort is greatly appreciated!

[Moritz-Schmidt]

Yes, I also think making the library home assistant compatible should have the highest priority. But I also think some decisions should be made better sooner than later since it would be more work to change it afterwards. Especially the question if everything should be in one class or if there should be different classes for Tado X Systems and pre Tado X systems.

What can I do to move forward with this?
Should I create a draft PR with all my suggested changes or would you like to discuss the fundamental choices which I wrote about earlier first?
Is there anything I could do help you with making the library compatible with home assistant?

[github-actions]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

[erwindouna]

Will be handled in PyTado.