Hi all,
Just got my Daikin Perferra FTXM35R installed yesterday.
I can connect the binding/thing and it says connected (if I enter the FQDN or enable HTTPS it says offline or conn-error).
But it says at power that it is off, while it is on. Temp and humid is undeff.
Is the net BRP069C4x wifi supported?
If not, how can I add support or when will support be added?
Hi, I have the same issue. My other AC, a Daikin Stylish with a BRP069B4x is working and discovered fine.
If any testing or network sniffing is required, Iām happy to help.
Did some further investigation, it appears the C4x wifi unit is cloud only, so it doesnāt have a local API. Even though it has a webserver. If found some topics about it:
- Daikin AC Integration BRP069C4x - Third party integrations - Home Assistant Community
- CTXM15R5V1B and FTXM20R5V1B : New API? Ā· Issue #123 Ā· cbrandlehner/homebridge-daikin-local Ā· GitHub
And somebody already wrote some proxy for it:
1 Like
I created a github issue about this: [daikin] Support Daikin BRP069C4x (cloud only) wifi modules Ā· Issue #11032 Ā· openhab/openhab-addons (github.com)
Great.
in the mean time I will upgrade my openhab to version 3 
It is still 2.5.6, and probably the issue will not be solved on this version.
Ok, i am NOT a programmerā¦or lets say I am somewhere on kindergarden level of programming and therefore feel a bit ashamed to share codeā¦
However: Based on Apollo77 daikin controller cloud - mentioned above i was able to extend his example file with some mqtt and wrote a small daikincloud2mqtt.js
Even I hope it does the trick for me (i recently installed 2 of the units) until we have a binding I would more consider it a draft and I dont think I have the skills to make it āproperlyā.
If you want to try:
It depends on node.js and you will have to install Apollo77 daikin cloud controler (see his instructions) and get the tokeset.json in the same directory where the script is and you need to install mqtt.js
How it works:
It basically takes the whole JSON replied from DaikinCloud and writes it to an MQTT server (see head of the script and modify to your needs).
It will also subscribe to the topics marked in the JSON as āsettableā with the topic ā/setā and then send this data to DaikinCloud
example:
If the Data from DaikinCloud is published under:
/mqtt_baseTopic/deviceID/climateControl/temperatureControl//operationModes/auto/setpoints/roomTemperature/value
You can publish to:
/mqtt_baseTopic/deviceID/climateControl/temperatureControl//operationModes/auto/setpoints/roomTemperature/set
and the script will send it to DaikinCloud
It runs in an endless loop and will query DaikinCloud regularly (you can set the intervall at the bottom of the script) and for my purpose I start it through systemd.
Hi Specialist,
Iām joining haesslo as āNON programmerā OpenHab user. I recently extended my Daikin install base with FTXM20R and FTXM35R models, and I can confirm the problem statement.
The new models are making use of cloud API and the Daikin Residential Controller app.
On the positive note, both old and new models are supported in the Daikin App and Google Home is working (incl Google Assistant voice).
But indeed Daikin binding is not recognizing the new units. Are their any plans to update this Daikin binding in the ānearā future with above solution? (in that case I will just wait patiently 
) as ācontrolā features are survivable with above apps.
My targeted use case is more āaction triggerā based on āstatusā . Fi, turn off the central heating when airco is powered on. Open a blind when turning on airco. Change fan/temperature if room temperature is too high, turn off airco when window is open ā¦ the real ādomoticaā type of integrations between different end devices.
I was looking into alternatives like IFTTT, but they have the same challenge (new model not working)
and actions on google home are not possible? Anyone experience with Alexa actions?
(I noticed, openhab can push commands to alexa echo, and maybe with this 3 step workaround, we can control the aircoā¦ super inefficient)
@haesslo where you able to get the mqtt solution working as āstableā solution, would it cover above mentioned use case? (a bit unclear for me what the end result is)
if yes, can you guide me through the steps/advised reading as no experience yet with mqtt nor proxy setups ;-). Iām afraid current entry level is quite high for basic users, but worth a try.
Hi Midwave
Yes, it is basically working for me, meaning i am using it in my home. I manually refresh the token every month by calling one line of script.
The end result is that you can read/write any Daikin setting (write only if settable) via Openhab.
Not sure about the steps i can explain.
You will need an MQTT broker and Openhab MQTT plugin - there are a lot of explenations out there on that better than i could explain - but i want to recommend MQTT explorer for monitoring/understanding what is happening.
After that you basically only need the small setup:
- node.js (very often included on all linux)
- Download the script from Apollo - you can call it with user/pass and it will basically create the toke-file needed for authentification.
- install mqtt.js
- Modify my script to your needs (MQTT broker mainly).
- Run my script in a loop
Feel free to contact me if you get stuck on the road, and i will see to help (better then creating a full documentation )
I have done some work on the Daikin binding in the past because I have an older controller that still accepts local control for Daikin Airbase (ducted system). Here are my past PRs related to the Daikin binding that got merged: Pull requests Ā· openhab/openhab-addons Ā· GitHub
No promises, but I could have a go at implementing this for the binding. However, because I donāt have this adapter, testing would be quite difficult for me. Iāve had a look at the API document. At the very least I would need a valid login / password a daikin cloud account, and a device to test. Would someone be willing to volunteer their access code that is linked to a device? If so please send me a private message with your details. Iāll also need you to do the testing for me.
This is the API document that Iāve read: https://backend.daikincomfort.com/docs/default-source/product-documents/residential/manuals/othermanual/im-dknapi.pdf
If you know of other resources other than the ones posted here or on github please share.
Please use this to keep track of the status: [daikin] Support Daikin BRP069C4x (cloud only) wifi modules Ā· Issue #11032 Ā· openhab/openhab-addons Ā· GitHub
Lastly, if someone else who has this adapter want to implement it on the binding, donāt hesitate to take over this task. It would be far easier to do so with the adapter to test.
1 Like
Hi Jim,
I also have found this documentation, but how do you get to a client id and secret?
KR
Jan
@Earbender Iām not sure until Iāve tried, it but it seems that:
- Obtain ātokenā (access token?) using
2.3.2 Programmatic Interface
2.3.2 Programmatic Interface
This interface basically performs the actions described above (Login and Authorize), but without the
need of a browser; only through HTTPS requests. This method is suited for the integration in home
automated systems/BMS. We will describe the structure and format of each of the requests.
Step 1 and 2. Login:
- REQUEST:
- POST https://www.dkncloudna.com/api/v1/auth/login/dknUsa
- HEADERS:
o Accept: application/json
o Content-Type: application/json
- BODY: JSON body parameters:
o email: (String) user email
o password: (String) user password
- EXAMPLE:
curl --location --request POST "https://www.dkncloudna.com/api/v1/auth/login/dknUsa" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data "{\"email\": \"user@email.com\", \"password\": \"examplePassword\"}"
- RESPONSE: This returns a JSON object, where we only are interested in only one of its properties:
token.
Example response:
{
ā¦
"token": "R7k6xX3HsHH1LIPYrCV5SbtYNH7rzFlbā¦",
ā¦
}
The value of this field is needed for the next request. It acts as an authentication token for the DKN
Cloud NA environment, identifying the request in behalf of the user.
- Use that token in API request headers:
3 API
For every API request, the following headers are required:
- Accept: application/json
- Authorization: Bearer {{ACCESS_TOKEN}}
Where the value of ACCESS_TOKEN must correspond to a valid access_token for a specific user.
As for PUT requests, the following header is also required:
- Content-Type: application/json
The headers will be omitted in the following descriptions.
All responses are in JSON format.
HI JimT,
yes, that is the oauth2 protocol. but to acquire the access_token, you need a clientId and secret. And in the documentation youāve mentioned, Iāve seen that you can only manually asks this at the people of Daikin.
I will keep you informed.
KR
Jan
I must have misunderstood. So the ātokenā retrieved in 2.3.2 is only for Step 3, and itās not the actual access_token for the API?
Correct, I implemented this first part as a proof of concept based on the nodejs proxy from apollo, but in C#:
SierraNL/SierraNL.DaikinCloudLogin (github.com)
I tried picking up this ticket, but my lack of knowledge of Java libraries made it hard to get anywhere.
Since this code is basically reverse engineered from what the browser does, it is quite prone to breaking.
If you have something Iāll be willing to test it.
How did you get the clientid and secret?
I got them from the nodejs proxy implementation from Apollon77 (GitHub - Apollon77/daikin-controller-cloud: Connect and Control Daikin Cloud devices), but I think it is visible if you sniff network traffic of the login process triggered in the browser, triggered by the app.
Is this hard coded somewhere? I donāt have the daikin controller so I canāt do any sniffing and I havenāt tried the app. Not sure I could use the app without having the controller.
I think itās hardcoded in the app (ONECTA on the App Store (apple.com)) because that triggers the browser asks you to login on id.daikin.eu.
I think you could use the app and create an account without having a device.
1 Like
Is your system connected to Daikin EU? If it can only connect to Daikin EU, weād need to make this configurable in the binding, so people can choose, e.g. EU, US, etc.
Yes, from the look of it the URLās are region specific, the API documentation talks about NA (as in North America) all the URLās in my case point to the EU tld, or a European AWS region. Hope itās just the URLs and nothing more.
Can you use your EU account to login to the NA server?