Switch to ONECTA Cloud api

[JeroenVdb]

First step:

• removed proxy (might re-add later but want to focus in the core functionality)
• talk to official ONECTA Cloud API

Todo:

• Add debug logging
• Add debug logging about the ratelimit

[Apollon77]

I hope I find time sunday to look into the topic, had some other prio stuff to finish first ...

[jacoscaz]

Hi @Apollon77 and @JeroenVdb ! I'm working on a Onecta-to-MQTT adapter (something like zigbee2mqtt for the Onecta API) and literally just got a proof-of-concept working with a local HTTPS server used to capture the authorization code. It's not public, yet, but if all goes well I should be able to release an alpha within the next few weeks. I wasn't aware of this project when I started but I'd be happy to trade notes or work together if our goals align.

[JeroenVdb]

With these last changes I got something working for my plugin (https://github.com/JeroenVdb/homebridge-daikin-cloud/tree/support-new-api).

I ask for the authentication (which the user should get for themselves) and get going from there.

With the work of @Apollon77 and @jacoscaz it hopefully can be simplified but I'm thinking of already releasing this as a beta for the users to try out already.

[Apollon77]

@jacoscaz That sounds interesting and I would be happy when we can work together because then the core parts are just need to be implemented and maintained once. In fact I plan to do the same. Open a temp https server, tell the user what he needs to configure in the daikin portal and then use this once to initialize and after that refresh tokens should be sufficient. So if you would share your code maybe I can integrate here and you could also use this lib in the background? Or you do a PR? WDYT? I know it's late so I planned to work on that the next days (ok we only have 3 left basically if the Daikin date stays, maybe some more).

[jacoscaz]

@Apollon77 I've just invited you to my private repo. The Onecta client is self-contained in the src/onecta folder and should be easily portable to any other project, depending only on openid-client. It uses the authorization_request event to let consumers know that the user must open the URL passed as the first param to the event in a browser.

Let me know if you'd like to jump on a call or something like that. I'd be happy to contribute!

[Apollon77]

Thank you! I weill have a look after breakfast. The great thing is that my lib also bases on openod client and tokenset so this shoul dbe easiely reusable. If you like have a look at the API from my project, maybe it could be an idea to just move that client to my API (and yes, upgrade to TS is also cool) ... I think the methods are slightly different, but also not too much

WDYT?

I would later try to do that basically by maintaining the current basic API here. Thank you! That gives me a big boost :-)

I currently work on @project-chip/matter.js mainly, so time is very rare :-)

[Apollon77]

Ps: if you like we can also share maintainership of such a new client. So we could have reviews (if we want) ;-)

[jacoscaz]

@Apollon77 speaking purely from a technical standpoint rather than an organizational / maintainership standpoint, I suspect it would be easier to rebuild the device API of your client onto my client rather than vice-versa.

I don't care about where that happens, whether in this repo or mine; actually, it would probably be better to do everything in this repository given that it's been around for a while and is already in use by projects such as @JeroenVdb's.

I'll have a go at this at some point in the day and report back here or open a draft PR to have something practical to look at together.

[Apollon77]

I will need also some hours to really start. Have some family topics first ;-)

[Apollon77]

API wide in fact also that could work. My api tries to do some parting magic on the structures for developer convenience. But also because of the fact that it only works on the jsons we easiely could expose two apis for the beginning to give devs time to migrate. So we could have the client expose your and a derived "LegacyClient" just adds the old api id method names overlap or just have both styles.

So yes several options.

My lib is used by some node-red, the mentioned homebridge plugin and also ioBroker. So yes would be cool to have something basically compatible.

[JeroenVdb]

Might be opinionated but I think the first focus should be the authentication and authorization flow working with the “old” methods.

I agree it would be great if @jacoscaz project would also use this package to not spread to a multitude of implementations.

It would be handy, because we have the documentation now in the API docs, that we retrieve specific objects (boiler, airco, etc…). But again that should be second focus I think.

[Apollon77]

@jacoscaz @JeroenVdb If you like ... I'm also Apollon77 in Discord ... just contact me there and we can open a chat together there, might be better then via GitHub :-)

[jacoscaz]

@Apollon77 @JeroenVdb I've made some nice progress in the onecta-api branch of my fork. As per the above, I managed to keep the device API as-is while refactoring the DaikinCloudController and DaikinCloudDevice classes to use my own OIDC client.

Everything appears to be working correctly; you can clone my fork and then test as follows:

git clone git@github.com:jacoscaz/daikin-controller-cloud.git
cd daikin-controller-cloud
git checkout onecta-api
npm install
npx tsc
export oidc_client_id="" # your client id
export oidc_client_secret="" # your client secret
node dist/example.js

For it to work you need to map the daikin.local domain to 127.0.0.1 in your hostfile and set https://daikin.local:8765 as the application's OIDC callback URL in Daikin's developer console.

If this looks good to you I can work on cleaning it up and creating a PR.

[Apollon77]

@jacoscaz Awesome and yes that's a great start. I think that makes sense. types can be optimized later so all good for now.

In a second step I would propose node-forge or comparable to dynamically create and cache the certs. then the domainname for the server for the callback can be more dynamic

So if you would provide your changes as PR I would be very happy :-)

[Apollon77]

@JeroenVdb I would close here in favor of #139 :-)

I will merge and adjust tomorrow then I push a alpjha to npm and you can check what you need to do to update the homebridge plugin, ok?