[tado] Tado changes their OAuth2 flow from 'password' to 'device' per 15 March 2025

[kritsel]

I do not use openHAB myself, but I wanted to let you know that tado will be changing their OAuth2 flow per 15 March 2025, which will break any existing tado API integration.

More info: https://support.tado.com/en/articles/8565472-how-do-i-authenticate-to-access-the-rest-api

[andrewfg]

Thanks @kritsel

[andrewfg]

@Hilbrand I think there is now an OAuth component in OH core. So I wonder if you have any tips if that can be used for this case? And if so any other bindings that I can use as an example?

EDIT: the tado authentication uses Rfc-8628 oAuth 2.0 "Device Code Grant Flow" .. which it seems that the OH core oAuth service does not offer. Or??

[OlduwanSteve]

@andrewfg This fix is much appreciated and works well for one tado account, but I don't think I'm alone in having two accounts because of limitations in the tado ecosystem. It looks like some other OAuth client services use their 'thing id' or some other unique key to tie stored token to an instance rather than have one shared token.

[andrewfg]

some other OAuth client services use their 'thing id' or some other unique key to tie stored token to an instance

The OAuth unique service ID is currently the thing type uid. Indeed not the thing instance uid. I purposely had to do it that way since a) the thing instance uid may not be initialised when the handler is created, and b) there are some use cases where the user may have two things linked to the SAME account.

Can you explain to me your use case? Why do you have two accounts? Rather than one account with two homes in it? In order to address your use case, we may need to add a “hack” config parameter or something..

Edit: there will also be an issue with the http servlet on http://ip-address:8080/tado since it can’t know which account it is supposed to be validating until after you would have logged in with whichever account. I don’t have a clue how to resolve that.

Edit2: I think currently the binding only supports one home (the first one). It would be very easy to adapt the binding to support multiple homes within one account. So I wonder if your use case could be solved with multiple homes under one account rather than multiple accounts with one home. Please advise?

[OlduwanSteve]

All the information on the internet suggests, and my experience has been, that you can only have one home per tado account. If there's a workaround for that I'm very open to it as it would be a big win all around!

I have two bridges because of the layout of my house - not all thermostats could connect to one bridge. I therefore have an account per bridge.

In terms of a solution, it could be fairly niche config if there's not an obvious pattern to follow. E.g. the http servlet could accept an additional query parameter or sub-path with the thing instance id included, or just an arbitrary suffix value that could be included in the token store key, and then also included in the config for the bridge thing?

[andrewfg]

All the information on the internet suggests, and my experience has been, that you can only have one home per tado account.
If there's a workaround for that I'm very open to it as it would be a big win all around!

The Tado API GET user info contains a JSON element called homes which is an array type. So in theory (at least as far as the API is concerned there could be more than one entry in that array. Currently the OH Tado binding always uses the first entry in that array. But it would be trivial to use another entry. Indeed I already wrote the Java code for this. However I personally only have one Tado stick so I cannot test it in reality. But possibly Tado artificially restricts the number of homes in this array to one entry only??

[andrewfg]

the http servlet could accept an additional query parameter or sub-path with the thing instance id included, or just an arbitrary suffix value that could be included in the token store key, and then also included in the config for the bridge thing

Yeah. But I would use neither the thing instance uid, nor an arbitrary suffix (because they could change). Instead I would probably (re)use the already present 'userName' config param.

[andrewfg]

@OlduwanSteve I wrote some code for you. I hope you are able to test it for me on OH 5.0.x Snapshot?

See #18481