Provision of a new API for daikin cloud Onecta

[ThibautTrarbach]

Hello,

Just to inform you that Daikin has finally released its API for Onecta. I just had access to their developer panel

See attached documentation : https://developer.cloud.daikineurope.com/spec/b0dffcaa-7b51-428a-bdff-a7c8a64195c0/70b10aca-1b4c-470b-907d-56879784ea9c

Sincerely Thibaut

[JeroenVdb]

@Apollon77 do you have the intention to update this library to be able to use the new API? Or would this be deprecated?

[Apollon77]

Yes, seems I need to update, so need to find time next weeks or such :-) You could also try to do it and provide a PR

[JeroenVdb]

@Apollon77 I was already looking into a lightweight version based on what you have here. I was in doubt about the PR because I don't know how you looked at the following:

• I would remove the proxy because I don't think it can be used anymore. To retrieve the authentication token you can't use a localhost url for the redirect so I think (no expert in this) it can't be MITM'ed.
• I would ask the users for an access/refresh token to start with, so they will need to create an App (client id/secret) and retrieve the tokens themselves. The library can then use the refresh token to keep getting new tokens.
• Deprecate Node 16 and bellow
• As far as I can see the API is kept the same so all set and get data related stuff can be kept the same

[Apollon77]

Hi,

• yes the proxy is most likely "dead", same for the "scripted http auto login flow". so all this should be removed
• Then we need a way to authenticate "one time" and return the tokens. Here in fact the complexity comes in. We need to start a local webserver for this process because we need a target for the "OAuth end redirect or users need to copy stuff from URLs or network tabs around which is semi good. This all could also be triggered again with executing a script which outputs the details like in the beginning times. And yes each user creates his own Client-ID and secret for that. I think it is all relatively straight forward and parts of the proxy code (that basically do the same) can be reused for start and end.
• Rest should work - as you said - as before. I just heared that some data might be no longer included, but did not validated so far.
• AND a big difference is that there are rate limits now ... so you only have a limited number of calls per day, so it might be thought here and maybe about reducing updates in night hours or such.

[JeroenVdb]

Then we need a way to authenticate "one time" and return the tokens. Here in fact the complexity comes in. We need to start a local webserver for this process because we need a target for the "OAuth end redirect

Here the problem is, I think, that the redirect url to start the OIDC flow can not be a localhost url. So starting a webserver wouldn't be enough. Or am I missing something?

I guess if we tell to first edit /etc/hosts as well and let them direct a specific domain to the local webserver it could maybe work.

[JeroenVdb]

@Apollon77 this is the "main" change I had in mind: https://github.com/Apollon77/daikin-controller-cloud/pull/138

[Apollon77]

Localhost should work because in fact it is your browser that does the redirect. So ideally it is a local IP or local hostname rather then "localhost/127.0.0.1" but in theory also 127.0.0.1 would work if it is the same machine where the browser runs on. Will look into.

Re your PR: I would keep the Openid logic like https://github.com/Apollon77/daikin-controller-cloud/pull/138/files#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346L55-L76 for a new onetime-auth-script... in fact you just use the users clientid/secret and urls from them

[JeroenVdb]

Localhost should work because in fact it is your browser that does the redirect. So ideally it is a local IP or local hostname rather then "localhost/127.0.0.1" but in theory also 127.0.0.1 would work if it is the same machine where the browser runs on. Will look into.

I might be misinterpreting the way you see it but even if the browser makes the redirect, the authorisation flow will fail because the redirect_uri must be whitelisted via the ONECTA Api platform. And it does not except localhost values.

[JeroenVdb]

Never mind, had another look at the proxy and I see you also intercept the daikinunified:// uri there, so I guess it's possible to intercept any domain.

[fichtenmoped82]

Good Evening,

@Apollon77 : Any idea, how the new rate limit will affect existing scripts?

What exactly are the script operations that count to that new 200 requests/day limit? Is a call of setState regarding a datapoint of a Daikin Cloud instance already "consuming" one request for example?

Regards & Thanks!

[Apollon77]

@JeroenVdb ohj they really try to validate the domainname you enter? What about an ip?

[Apollon77]

@fichtenmoped82 reading in any way. But in general should be all actions too. And the rest is hard to answer without knowing the current scripts but in fact to have a bit reserve.

In fact 24h/200 is one action every 7.2min. So with some Actions reserves one read every 15 mins should allow that. If you define a night timeframe where you read less often you can optimize other timeframes.

[JeroenVdb]

@JeroenVdb ohj they really try to validate the domainname you enter? What about an ip?

Tried both ip and localhost variants. All are blocked. They also explicitly mention in the docs that they block it.

I think it’s possible via a small web server + change the hosts file on your computer. But then again it’s probably easier (or both hard) to ask the users to navigate to the authorization page and do some curl commands.

[nightsha-de]

Tried both ip and localhost variants. All are blocked. They also explicitly mention in the docs that they block it.

Did you just try 127.0.0.1 or also the local network IP of your machine?

[Apollon77]

The other alternative I thought about is to add a special webservice hoested e.g. by me which is publicly available and allows to fix these local issues ... i need to check

[Apollon77]

Ok, I tested:

• needs to be https ... but in fact we could use a self generated and tell users to ignore browser warnings because of that
• local ips do work, except 127.0.0.1 but in fact each local host also has another ip :-)
• local hostnames also work except localhost so should work

[DrHauss]

There is a working way for Home Assistant with a custom integration which uses the new API

https://github.com/jwillemsen/daikin_onecta

Maybe this is helpful to check how they implemented also the OAUTH redirect.

[Apollon77]

Thx, thats known, in fact it is just "time" and not the "how" :-)