🚀 Exciting News: Announcing Daikin Europe Developer Portal! 🚀

[Daikin-Europe]

Dear Developers and Tech Enthusiasts,

We are thrilled to announce the new Daikin Europe Developer Portal. This platform is dedicated to empowering developers like you to unlock the full potential of Daikin air2air and air2water heat pumps, fostering innovation in the world of climate control.

🌐 What is the Developer Portal?

Our Developer Portal is your gateway to a world of endless possibilities with Daikin products. Whether you're an experienced developer, a company exploring opportunities or just starting your coding journey, this platform is your ultimate resource for building and integrating with our technologies. It's a one-stop destination for all things development-related, offering documentation and resources to supercharge your projects.

🛠️ Key Features?

📚 Comprehensive Documentation: Access documentation that provide a deep dive into our APIs, ensuring you have everything you need to get started and excel with your integration.

🚀 Interactive API Explorer: Experiment with our APIs in real time using our interactive API explorer, making the integration process smooth and intuitive.

🔌 Easy integration: Integrate directly onto the Onecta ecosystem with your own units to develop or test your integration. No special hardware required!

🔑 Rate Limitation: To continue offering the Onecta API for free to all our customers a default rate limitation will be implemented.

💼 B2B Business Case Validation: Explore hassle free if your companies business case works together with the Daikin APIs. Get in contact with us when you want to become a partner.

🚧 What's Next?

This is just the beginning! We're committing to expand and enhance our Developer Portal, with new features and resources in the future. Your feedback and suggestions will be invaluable as we evolve the portal to meet the needs of our customers.

:wrench: What changes can already be prepared from your application? Make your current application compatible with the upcoming rate-limitation of 150 calls/day. This will allow everyone to query at least every 15 minutes for temperature changes in their home of all their devices. Temperature variation in the home is often not so fast that a faster update rate is required.

🌟 Ready to Get Started?

We're targeting beginning 2024 for the first access to the Daikin Europe Developer Portal. With later in Q1-2024 the release of self service within the developer portal. Get ready to innovate, build, and make a lasting impact with our Developer Portal. We can't wait to see the incredible solutions you'll create!

Stay tuned for more !

Daikin Europe

[jwillemsen]

Great news @Daikin-Europe ! Hopefully there will be much more information available from the Daikin devices, especially from the Altherma 3 device I would like to see much more details!

[rospogrigio]

Thank you @Daikin-Europe . I have created a new PR #183 that reduces the polling time to every 15 minutes, as you suggested, for everybody to try. A couple of questions: is there (or will be in the future) the possibility to send commands locally in the LAN instead of passing through the cloud? Many users (including myself) have been asking for this. Thank you for letting us know.

[jwillemsen]

A rate limit of 150 calls is enough for an AC unit, but not for an Altherma, those change much faster, would love to see a higher rate there

[VolkerH]

As @rospogrigio said, implement local network access! Rate limiting is a no-go if you don't provide it. I bought and my airconditioning systems specifically because they can be controlled via Wifi. This was listed as a feature of the device when i bought it (not as an optional service), you can't take it away after I paid for it. I use Home Assitant together with Zigbee sensors to implement my own thermostats. This is for 5 devices. If querying and setting a state is one API access each, that already requires 10 calls for 5 devices. I don't see why there should be any limit at all.

P.S. I will send some feedback to my installer. Until this is fixed I will not recommend this product to anyone. Good hardware, but if you decide to cripple it ... P.P.S: I also don't see why you should have access to our data

[jwillemsen]

For the Altherma there is a separate HA integration, at some point I want to extend that integration also with support for the AC devices, see https://github.com/jwillemsen/daikin_residential_altherma

[Apollon77]

@Daikin-Europe Cool, good news, keep us updated. But basically I agree to the discussed topics above about rate limits vs local access.

[barryvdh]

1 update per 15 minutes seems a bit low ..? My AC goes from 18 to 23 degrees in 15 minutes (small room)..

I can understand limiting to 1 call a minute (instead of 15 seconds) or 150 change operations/day (setting temp/hvac mode), but it's also about showing the actual state in Home Assistant (current/target temperate, hvac mode, on/off), so 15 minutes seems a long time to reflect the current state on your dashboards, which means the dashboard is not really useful.

Thanks for the Developer API though, just hope it doesn't cripple the HA integration, instead of making it better..

[VolkerH]

To elaborate on my earlier comment. Maybe I am jumping the gun here, but this announcement seems like a crass form of corporate language to me. DAIKIN describing a serious deterioration in thier product as a great new feature for developers. Maybe my concern is unfounded, but there are recent examples of other companies ... this is called enshittification https://doctorow.medium.com/the-enshittification-of-garage-door-openers-reveals-a-vast-and-deadly-rot-eed85da5b0ba

As for the corporate speak: you are not making sure you are able to continue this free service. This is not a free service. As customers, we already paid for this feature, so it is not free. I paid for a device, I didn't subscribe to a service. In my case, I paid a 5 digit EUR sum for DAIKIN devices.

There is no technical reason for denying local access. This is proven by my Comfora unit with the older WIFI modules (if I had known I would only have installed the cheaper Comfora units and not the more expensive, newer units). Local access works well, no cloud needed (so no cost for DAIKIN to run servers for a "free" cloud service most customers don't want). The only reason to make cloud mandatory is to grab data and lock us into using their apps. The B2B stuff in combination with the rate limiting suggests to me that any access with more than 15 min interval access will either be through Onecta or some subscription based model. So, we're being dis-owned of our devices for which we paid! I would hope DAIKINs business model is about selling good hardware, not about dealing/collecting in data and selling subscriptions to their API. I would love it if @Daikin-Europe proves my suspicions wrong and enables local access.

Since my last comment, I found this https://github.com/revk/ESP32-Faikin and ordered several of the pre-assembled PCBs. I fear this will be the only way to truely own the DAIKIN devices that I paid for. But again, please prove me wrong @Daikin-Europe .

To all the others who left ❤️ emojis, please re-read the announcement carefully, with the garage door enshittification in mind and your translator for corporate speak turned to "on". There needs to be massive push-back against @Daikin-Europe disowning its customers.

[rospogrigio]

Yes @VolkerH , I see a common trend with several other IOT vendors about this, that set up everything to be cloud-oriented, and then they realize how high is the cost for them to maintain the cloud connection, and consequently start cutting off the service. My Xiaomi vacuum cleaner, for example, now no longer shows the real time map if you make too many requests, and so we users needed so setup a hack within HA in order to reduce the calls and stay within the rate limitation. I really don't understand this approach, as you say local access is faster and more secure. Cloud connection is nice to have as an add-on, but shouldn't be the only way to interact with the device on the network. Just my 2 cents, let's wait and check wheter @Daikin-Europe want to reply something.

[rgerhards]

I guess @Daikin-Europe will never reply here. Just dropped the "bad news PR".

BTW: the same also happened to the VW API for their electric cars. And there even is an annual subscription fee for "connected services".

I am/was thinking about purchasing an Altherma. I am now reconsidering. Albeit is is becoming really hard to own any hardware I paid for. General trend.

[andreas-bulling]

Yes @VolkerH , I see a common trend with several other IOT vendors about this, that set up everything to be cloud-oriented, and then they realize how high is the cost for them to maintain the cloud connection, and consequently start cutting off the service. My Xiaomi vacuum cleaner, for example, now no longer shows the real time map if you make too many requests, and so we users needed so setup a hack within HA in order to reduce the calls and stay within the rate limitation. I really don't understand this approach, as you say local access is faster and more secure. Cloud connection is nice to have as an add-on, but shouldn't be the only way to interact with the device on the network. Just my 2 cents, let's wait and check wheter @Daikin-Europe want to reply something.

The only solution to all of these issues is to go with an alternative (open source) firmware, e.g. Faikin for Daikin ACs and valetudo for vacuum cleaners. Leave their cloud and never look back. Maybe this will make them sane again once enough customers stop using/buying their products.

[pjgoodall]

No Faikin for FTXM71WVMA with wifi controller BRP084C44. Restricting API call frequency to 15m shows that the whole ‘cloud only’ drive was marketing not engineering or customer based at Daikin. Marketing people should only be in meetings at a ratio of 1 in 5. There should never be rooms with only marketing people in them. So how does the cloud-centric control go when Optus falls flat during a 40c heatwave?

[Apollon77]

The more interesting question from my perspective is how that should work withthe Onecta App? All the non tech users will use the app whenever they want and expect current data ... So the App-API will then maybe not have such rate limits (because honestly else normal users will make big noise) , but an "open API" will have? This also makes not that much sense ...

[rospogrigio]

The more interesting question from my perspective is how that should work withthe Onecta App? All the non tech users will use the app whenever they want and expect current data ... So the App-API will then maybe not have such rate limits (because honestly else normal users will make big noise) , but an "open API" will have? This also makes not that much sense ...

I believe the app will be allowed to perform more frequent polling, or possibly it would update -let's say- every 5 minutes and I highly doubt that anyone would notice. Still would be nice from @Daikin-Europe to have some answers to all the questions asked in the thread so far... but they just threw the stone and hid their hand, as we say in Italy 😉

[RadianM]

If polling for dashboard status updates is rate-limited to the imposed maximum of 150 calls/day, that doesn't seem to leave sufficient 'bandwidth' for actual commands? I want to use automations to operate the A/C under my own scheduling and these additional calls would be on top of those performing the 15m polling. And how does this all work out when multiple A/C units are being polled?

[rospogrigio]

If all the units are connected to the same account, with each polling you get the data from all the units so don't worry for this. But you do are right when you say that each command you send is a call that goes on top of the polling commands.

[RadianM]

each command you send is a call that goes on top of the polling commands

In which case it would definitely appear that we need a way of setting the polling rate as has been suggested. Personally I think I will be removing the cards from the dashboard as such stale information is offensive.

I also wonder if the 'too frequent' polling is what is affecting my use of the Onecta app to control the A/Cs? I don't know if it's a general thing but the response time is lousy when using the app - very often a new setting does nothing and then shortly after the displayed new setting reverts to how the device was. A frequent culprit is "Powerful mode" which needs several goes at selecting it before it engages.

[rgerhards]

I also wonder if the 'too frequent' polling is what is affecting my use of the Onecta app to control the A/Cs? I don't know if it's a general thing but the response time is lousy when using the app - very often a new setting does nothing and then shortly after the displayed new setting reverts to how the device was. A frequent culprit is "Powerful mode" which needs several goes at selecting it before it engages.

I noticed that problem as well. I "fixed" it by increasing the polling time to 90 seconds inside the current code. I think the value is definined in init.

[RadianM]

I noticed that problem as well. I "fixed" it by increasing the polling time to 90 seconds inside the current code. I think the value is definined in init.

So this lends support to having a user-adjustable polling time. At the moment, this integration would appear to be interfering with my domestic heating system.

Can you be a bit more specific about the whereabouts of the polling time you made an edit to? I searched the repo but could only find TIMEOUT = 60 in custom_components/daikin_residential/const.py or maybe this is it ininit.py: MIN_TIME_BETWEEN_UPDATES = datetime.timedelta(seconds=15)

[shermozle]

The rate limits seem substantially low, and if this is a problem removing local API access seems like you're intentionally removing a great number of use cases. Let me explain my use case (via Home Assistant):

• Every minute, my solar power inverter tells me how much power was generated vs consumed
• If I have >1,000W of energy being exported, I set the thermostat 4º lower than the target
• If I have <1,000W of energy being exported, I set the thermostat to the target

This means I can pre-chill my house while the sun is shining to give us good comfort with no or low energy usage in the evening, while accounting for variable solar input and variable other loads. When the dishwasher is running its heater, the air con temperature is allowed to warm up a bit.

[cypherbits]

Does these rate limits mean that someone can start the AC from Onecta or IR and Home Assistant will only know after 15 minutes?

That is shit @Daikin-Europe .

Where is the local control we wanted for months that do not suppose a cost for your cloud?

[jwillemsen]

I have to come back on my previous comment, a rate of 1 times per minute still looks slow when the AC is controlled through onecta and monitored through HA, a rate of 1 times per 10 minutes is really too slow

[RadianM]

IMO It's all a bit of an unpleasant mess now. I suspect the choice of rate limiting to 50/day has been set by them to cover half-hourly dynamic energy pricing. It's not been chosen with a view to real time monitoring but for slow 'smart grid' applications. Ultimately this is my goal so I can live without the 'nice to have' dashboard integration. But I'll be sad to have to remove it. And it definitely rules out fine-grained adaptive solar PV integration.

My family wouldn't appreciate losing control using the Onecta app on their smartphones - otherwise the brilliant Faikin would be my go-to solution.

I currently have polling from HA set to every 5 minutes and it's still getting the 288 calls a day through OK. The Onecta app is still a bit laggy but I don't feel it's any worse than before I started using this integration.

[barryvdh]

My family wouldn't appreciate losing control using the Onecta app on their smartphones - otherwise the brilliant Faikin would be my go-to solution.

Depending of the availability of the S21 port, I think you can use both? Eg. the Perfera has built-in Wifi for Onecta, so adding Faikin would allow both Onecta and direct Faikin control I think?

[RadianM]

Depending of the availability of the S21 port, I think you can use both?

Possibly, - I know there's a modbus adaptor available for most indoor units and I had the impression both could co-exist.

[Gtwizzy]

Is there any updated release ETA on this yet?

[eskey0]

Commenting just to note that, while is honourable that Daikin is trying to acommodate some "extreme cases", as others already said that feels way underwhelming. Just for reference, I have my units at home, I do have a HA at home, today they have a downtime from 8am to 4pm (or something like that, don't quote me), while that downtime I CANNOT control my units.

I am sorry this is not acceptable, sadly after expending a good amount of money for the WIFI module, I see myself looking for fakin and the likes.

[cypherbits]

Yeah, me too, can't control my units right now for maintenance reasons. When is the local control coming @Daikin-Europe ?

[Webreaper]

It's absolutely absurd that scheduled maintenance takes 8+ hours. An hour I could understand, but this is nuts.

At least I can use the MMI.

[VolkerH]

Maybe they neeed 8h to implement the rate limit ?

5 Units. Spot the old model that still supports local control:

In case @Daikin-Europe are still monitoring this issue, here is some suggested reading from the FTC (in the US, but maybe the EU thinks along similar lines and introduces some regulatoin with big fines): https://www.ftc.gov/business-guidance/blog/2016/07/what-happens-when-sun-sets-smart-product

[barryvdh]

Might be good if Daikin takes a look at the commotion caused by Haier; https://www.theregister.com/2024/01/22/haier_plugin_takedown/ https://tweakers.net/nieuws/217750/haier-stuurt-takedownverzoek-aan-home-assistant-plug-inontwikkelaar.html (Dutch) https://github.com/Andre0512/hon/issues/147#issuecomment-1902075829

[RadianM]

Unfortunately, while I totally agree with all the points made above, my legal mind tells me there's nothing particularly compelling towards them providing fairer use. What I'd really like to understand is the reason a local rest interface isn't provided anymore? Some aspects are still there - the debug endpoints and license page are still present. Running debug creates a bunch of files that make it clear how many useful pages have gone - all over local network.

Can anyone explain how it benefit the company to disallow local access? If it's because they might lose usage statistics and monitoring, are they really concerned about a small number of people blocking WAN access and losing that information? People who don't bother with setting up wifi for their devices fall into the same class of user.

[rospogrigio]

@RadianM which debug endpoints are you talking about? Can you explain? I don't really see the benefit in removing the local access too, hope @Daikin-Europe will reply one day...

[RadianM]

@RadianM which debug endpoints are you talking about? Can you explain? I don't really see the benefit in removing the local access too, hope @Daikin-Europe will reply one day...

The license page is served directly from the IP address of the device. In the Onecta App, on the main page under More>Settings>Diagnostics - starting that process returns a zip containing a number of files. The json and gateway endpoints list all the features of the devices but these all appear to be routed via the cloud server.

[Daikin-Europe]

🚀 Exciting News: The Daikin Europe Developer Portal now available! 🚀 It is with pleasure that we announce that the new Daikin Europe Developer Portal is now available for use! This platform is created to empower developers like you to unlock the potential of Daikin air-to-air and air-to-water heat pumps.

🔧 What about existing open-source integrations? To ensure a seamless experience and to take advantage of the new platform, we kindly request all users/developers with existing integrations on the Daikin Onecta platform to migrate their setups within the next 30 days. From 11 March onwards, we'll deprecate the currently used API key found in many open-source projects. This means existing integrations will stop functioning.

🚧 What's next for the Developer Portal? This is just the beginning! We're committing to expand and enhance our Developer Portal. Expect new features and resources in the future! In a following update we want to bring a developer self-service functionality, allowing developers to create their own application credentials.

🙏 Thank you for your continued support and for being an integral part of the Daikin community. We appreciate all your feedback posted on GitHub and through other channels. We will process and evaluate this input for future updates of Daikin Products and the Developer Portal. We’re looking forward to witnessing the incredible projects and innovations that you are about to create!

🔗 Explore the portal now: Daikin Europe Developer Portal Daikin Europe

[barryvdh]

Hmm it's slightly improved, from 150 to 200.

This rate limit configuration allows you to send a maximum of 200 requests per day to the ONECTA Cloud API. Furthermore, per minute, a maximum of 6 requests can be sent. This rate limitation gives you the possibility to query the state of your devices periodically while keeping the flexibility to perform sufficient actions on your devices. For example, if your application would fetch the state of your devices every 10 minutes, this would take up 144 API requests over a window of 24 hours. Note that you can request the state from all devices with only one API request. You then still have 56 requests that you can use for other actions such as changing the operation mode or room temperature setpoint during this window. However, you can't perform these actions too quickly after each other because you only have a budget of 6 requests per minute.

So every user needs its one API key? Which is not a problem per se I guess, but 1 month might be a little fast to implement the redirect flow and API calls and have all the users update their integrations..?

[tetele]

Good thing you listened to what people said about local control @Daikin-Europe 🤨

[jwillemsen]

🔧 What about existing open-source integrations? To ensure a seamless experience and to take advantage of the new platform, we kindly request all users/developers with existing integrations on the Daikin Onecta platform to migrate their setups within the next 30 days. From 11 March onwards, we'll deprecate the currently used API key found in many open-source projects. This means existing integrations will stop functioning.

As you know your API the best and there are several projects that use the existing API it would be much more helpful when you would convert at least one integration to the new model, that way you know also whether the new model works ;-). Also just a month to rework the code (people have to find time) and all users to upgrade isn't really helping.

🚧 What's next for the Developer Portal? This is just the beginning! We're committing to expand and enhance our Developer Portal. Expect new features and resources in the future! In a following update we want to bring a developer self-service functionality, allowing developers to create their own application credentials.

That really depends on the data Daikin provides, with the limited data available integrations can't do much more more. We lack for example data to calculate a COP, see all Altherma sensors, etc. A rate limit of 200 calls per day is not really much when you want to control all devices. As remarked several times, a local API would be much more helpful.

[Webreaper]

We lack for example data to calculate a COP

It does seem crazy that the key measurement we'd want from the heat pump, i.e., COP, isn't available to track via the API. The only way I can monitor my COP is to remember to go to the MMI and write down the total energy use figures, and track them in a spreadsheet. Totally absurd, Daikin!

[rospogrigio]

@Daikin-Europe , are you even considering to provide local LAN control as was available on older models? Can you please give a word about this request? Just to know whether it's something we can expect in the future or whether you're not willing to make it available. Also knowing the reasons behind the choice would be nice. Thank you

[Apollon77]

@Daikin-Europe As one of the affected developers with a relevant userbase of smart home users using this (and also an owner of Daikin devices) - is there any interest or way to get a personal contact to discuss your approach and the limits? In fact you thank us as being part of the community, but it seems that you are not part of it yourself ... Community is about communication and collaboration but unfortunately Daikin is very unresponsive here in this thread and also in all the tries I did personally before to get a contact to discuss integrations. I would really be happy to start a discussion with you guys to find the best approaches for the Daikin community! Come one ... jump over your shadow and lets talk ... lets work together!

For the timeframe: I agree: 30 days is really short to adjust solutions because, as you know, open-source development means that we this in free time and not commercially ... AND after we adjusted the implementation the users still need to upgrade their plugins to use the new version (with this breaking change in it) So tbh: a bit more time would be valuable for the community! Please consider to at least double that time ... 90 days would be the best choice in my eyes.

For the Limits In fact the Limits with 200 calls /day we end up with one call per 7,2 aka 8 minutes - as you already calculated in your infos ... If it would only about getting the currenmt data honestly that could in theory work out ... BUT the reality is that for each controlling action an integration needs to query the device status after the action to update the details. If you now really consider people using the Daikin devicees to heat (or cool) their houses and partially mix devices (so it is not only Daikin devices relevant) or react to someone opening a window to turn off the device or using boost modes to heat faster then usual and and and then for all such use cases this is not enough. Because if I now calculate some reserves in here for this then it means that I can use maximum a third of 200 for "status updates" and the rest is "control+request of status afterwards" reserve for controlling the system. This end then with status update every 24mins ... lets say 30 mins to have reserves for controlling operations. When I heat my room with Daikin device for 30 minutes I end up in a way too warm room if I have no control to react on things ... In my eyes 56 requests left - as your own text states @Daikin-Europe with knowing that we need to "read" after every "write" we end up with 28 control operations for a whole day ... This might work for a static "app controlled home" but not for a bit more enhanced smart home operations and logics. Also allowing "just" 6 API calls a minute in case of configuration (I just saw the API also allows to edit schedules and such) might also be a bit less ...

So having 500 calls/day ... or at least 400 ... could be maybe a better idea then 200 ... but in fact any limitation is a downside.

As an enhancement: If there would be options like an MQTT interface that pushes state changes in a subscription like matter then the 200 calls per day would maybe be enough again because we do not need to request state updates and the service pushes them whenever appropriate. Also this would save costs on your side because in the end less HTTP requests.

I will write an email now to Daikin ... lets see if I get an answer

Re local operations: maybe somewhen Daikin adds Matter as protocol ... It would be much cheaper then operating an own Cloud system these days :-) maybe something to think about in the Daikin prodict management and tech departments :-)

[rgerhards]

@Daikin-Europe If you insist on cloud only, I would even be willing to pay a modest fee to use it with a much higher rate limit that actually permits to control the device.

I am doing the same with Davis Weatherstations, and I do so in additition to the local interface they offer. Simply because the cloud has some benefits in here.

All in all, I agree to everyone else here. Enforcing cloud use and then crippeling it to a point where it becomes unusable for real home automation is not a smart move.

[f0rdprefect]

@Daikin-Europe a user of the homeassistant integration here: For me you borked the control via the oneta app for the last 24hrs or so. I specifically bought daikin, because I believed I had a good homeassistant support, taking my chances to get either local or cloud control. Last summer everything worked perfectly until you imposed the rate limit.

So not only you do enforce the cloud. You also broke it and leave me stranded with the strong incentive to buy two faikin controllers and void my warranty in order to own my HVAC units again. Would I recommend Daikin products to friends right now? Not likely!

Update: I needed to make chrome my default browser in order to log in again! At least Onecta works again.

[jwillemsen]

@Daikin-Europe Looking at the documentation is it correctly determined that the user has to login at Daikin Cloud and not specify the user/password within the HA setup dialog? How does this work for python scripts which don't have a user interface, for example the helper scripts at https://github.com/rospogrigio/daikin_residential/tree/master/tools. I wanted to convert these to the new API, that would be much easier to test as through Home Assistant, started with that at https://github.com/jwillemsen/daikin_residential_altherma/tree/jwi-daikincloudcontroller/tools

[simonebortolin]

@Daikin-Europe Looking at the documentation is it correctly determined that the user has to login at Daikin Cloud and not specify the user/password within the HA setup dialog? How does this work for python scripts which don't have a user interface, for example the helper scripts at https://github.com/rospogrigio/daikin_residential/tree/master/tools. I wanted to convert these to the new API, that would be much easier to test as through Home Assistant, started with that at https://github.com/jwillemsen/daikin_residential_altherma/tree/jwi-daikincloudcontroller/tools

Like smallstep sso: https://smallstep.com/sso-ssh/

you make a webserver in localhost that implements OIDC, log in via idp daikin, and then return to the application. Not a bad idea. It's better than saving your username and password who knows where

[barryvdh]

I think it's basically an OAuth 2 implementation, right? So https://developers.home-assistant.io/docs/core/platform/application_credentials/ where you would indeed trigger a popup to login, and receive the token in the callback.

[jwillemsen]

Any help migrating to the new API authorization mechanism is welcome! My time is pretty limited the coming weeks due to other obligations and I have no experience with OAuth2 so this would really be trial and error for me :-(

[jwillemsen]

Looks the approach to try to get the scripts working is not the best one. Need to rework the code to use the application_credentials support from HA, that looks to be easier, hopefully someone reading here has experience with that.

[jwillemsen]

First change for today on https://github.com/jwillemsen/daikin_residential_altherma/tree/jwi-haoauth2, there is a redirect to the Daikin login page, but get an error there, probably need to tweak some settings

[Apollon77]

In fact yes the Authentication is an OpenID/Oauth flow ... all pretty standard stuff ... So you need to store the tokens and potentially refresh the access token and such ... also Standard OAuth stuff.