I don’t think it’s likely to change, but there’s a small risk.
I have done that as well, but we have radiators on our upper floor that are quicker to adjust. Even in winter the heatpump can allow the compressor to turn off completely for long periods on a sunny day, or run at a low frequency, and the electric addon (which are the biggest source of power consumption) don’t have to run as much. Money-wise it doesn’t add up to much, but it’s satisfying to see .
There’s different types of OAuth authentication. A simpler one, where the user logs in, and then the application (often browser-based) can get access to the data. This is called “implicit grant”. But if it’s meant for server-server communication the “authorization grant flow” is used, where the user authenticates, giving OH in this instance an authorization code. OH can then trade this for an access-token that can be used when querying the API. The token is only valid for a short time (30 minutes), but with it also comes a “refresh token” that can be user to obtain a new token when it has expired. This makes it able to continue without user interaction indefinitely, even if OH would be offline for several hours, the refresh token it has saved can be used to get a new access token. The token renewal is handled automatically by the framework. And since it’s a well defined standard, it works the same for many different services. The spotify binding uses it as well. I have had my own implementation running for over a year without having to do any re-authentication, even though both my server and Nibe’s have been offline from time to time.
It would be my preference as well to have as much as possible in common. I have made my binding the way I felt was easiest, just to get it working and to learn all the ins and outs of OH, but I can certainly try to adapt it more to your modelling. Do you know if it’s possible to have the same Thing working both with and without a bridge?