Tado outdated form of communication

Hi,

Today I received an E-mail from Tado that the way HA is communicating with their Cloud is outdated and that they will close this kind of communication on February 12.
After Feb. 12 they will only support Oauth2 communication.
In the documentation found on the HA integration page ( Tado - Home Assistant (home-assistant.io) I can’t find anything how to use Oauth2 for connecting.
Probably for using Oauth I need a Oauth Client ID and a Oauth Secret ID the only thing is they don’t mention anything about this on their website.

Maybe someone already figured this out. :slight_smile:
If that’s the case I love to hear it.

Thanks in advance.

1 Like

I received exactly the same communication from Tado a few minutes ago.

P.

I have the same email today. Looks like the intergration was changed to use oath in 2024.1 (Switch tado device tracker to OAuth · Issue #102402 · home-assistant/core · GitHub), and I am running the most recent version, so not sure whether they are just seeing historical requests or whether I need to change something in my configuration?

Same problem here, see Tado will stop working without oauth2

Perhaps an issue in core stating this problem would be much more effective. Then the dev can look at it and do some fixin.
My guess is the code has to be changed to make that work if it doesn’t tell you how in the docs.

The Tado thermostats are internet connected thermostats. There exists an unofficial API at [my.tado.com](https://my.tado.com/), which is used by their website and now by this component.

1 Like

I am back after more than a year away because of this notification.
I have been stuck on a year old HA because my installation has a no longer supported Python.
So I could readily accept that I am using authentication that is going to be removed.

I used this as the reason to make a big jump to HA 2024-01 as a fresh installation.
However, on configuration the Tado integration it did not feel like OAuth to me - I would have expected some sort of prompt from Tado during the account verification phase.

Can someone - perhaps @martinhjelmare confirm that the new flow is really as simple as typing in id/password into HA and that there is no direct visible interaction with Tado expected?

The 2024.1 version that fixes it has a repair notice to remove old Tado GPS configuration from yaml. It could very well be that this part is what still triggers the message, as that was the part that needed fixing. I have not (yet?) received the message, and I did remove the old yaml config. I now use the device trackers provided by the gui based config.

Mine was a completely fresh install of HAOS on a new system and without migration from my old system.

I have had the same email.

The lines in my configuration.yaml for configuring the Tado integration are hashed out. (I cannot remember when I did this.)

I have also checked that the correct details are in core.config_entries as mentioned here: Tado stopped working after upgrade. “Failed to login to tado” - access_token.

I was on HA version 2024.1.2 but have upgraded to 2024.1.5 today.

Can anyone think of anything else to do?

On this page How do I update my REST API authentication method to OAuth 2? | Help Center it is explained how to create the new AccessToken for the API.

But my knowlage in REST API is so limited that I was not able to retreve my Token.

Thanks for that link to the Tado page.
I think I understand what is going on … the client id and secret are very public … which is not what I would have expected … but that is how Tado appears to be doing it.
Those credentials are hard-coded in the Python module that HA is using.

So - HA just needs to ask for the username and password of the user and the rest works in the background.
Looks like HA was already using this is some prior version - but not for everything.
The recent change in 2024-01 completes things so that all Tado access goes through the same route.
So all should be good.

OMG, This is exactly as (un)safe as the username/password they are now abandoning as too insecure. I doubt this is meant to be used this way in normal circumstances.