Daikin wi-fi adapter BRP072C42 not visible or configurable in OH

Hi there,

I’ve recently had wi-fi adapters installed into my Daikin AC units but I can’t seem to find bindings which work with the wi-fi adapters with a Daikin part number BRP072C42.

The adapters work fine with the Daikin app “Daikin Mobile Controller” but I’d like to be able to control them with OpenHAB. One of the AC units uses the wi-fi adapter type BRP072A42 and this works with the bindings from Paul Smedley (Daikin Airbase Binding)

I am new to OpenHAB so my lack of knowledge could be playing the largest part of the problem!

Any help you’re able to offer would be greatly received!

Cheers, Roy.

Hi Roy,

It’s possible that Daikin have changed the API (language the controller uses) with the BRP072C42. They did this with the Airbase module that’s used in Australia.

What kind of phone do you use? If it’s Android, you could install an app like tPacketCapture and capture some logs when using the BRP072C42 (cycling through the various commands) and send them to me. I might be able to see what’s different and modify the code to work with your adapter.

Edit: https://community.home-assistant.io/t/daikin-brp072c42-wifi-custom-component/126981 has some background. They’ve switched to using https and a token for authentication…

Cheers,

Paul.

Hi Paul,

I have an iPhone7 - which probably doesn’t help much.

I found this thread in a search which describes a similar problem in Home Automation https://community.home-assistant.io/t/daikin-brp072c42-wifi-custom-component/126981

I don’t know how relevant that is to OpenHAB but if I run the following from a browser (http) against the AC unit which is visible (with adapter BRP072A42), it returns info:

IPADDR/aircon/get_control_info
ret=OK,pow=1,mode=3,adv=,stemp=26.0,shum=0,dt1=25.0,dt2=M,dt3=26.0,dt4=21.0,dt5=21.0,dt7=25.0,dh1=AUTO,dh2=50,dh3=0,dh4=0,dh5=0,dh7=AUTO,dhh=50,b_mode=3,b_stemp=26.0,b_shum=0,alert=255

However, if I run the same thing against the AC unit which has the adapter BRP072C42, it returns an error:

IPADDR/aircon/get_control_info
Unable to connect

Thanks, Roy.

Hi @RoyOven let me have a think on how this could be supported, those Home Assistant instructions aren’t quite making sense to me right now…

Hi, I also have a C42 wifi module in my new Alira. It works fine with the Mobile Control app and listens on https instead of http.

Would love to have a go at testing any changes that could be made to support this newer module - from a read through that Home Assistant link I’m guessing they are on the right track. TIA for anyone able to work on this!

Hi, I also have a BRP072C42 (actually three of them) in my new Daikin aircon units.
I am ready to make tests, unfortunately I don’t have any Android phone. Thanks in advance for anyone able to work on this!

Is there any solution yet to support BRP072C42 controller? From what I see, the difference is that it moved to “HTTPS” as well as token authentication/authorisation. :frowning:

From: https://community.home-assistant.io/t/daikin-brp072c42-wifi-custom-component/126981 but with a little change:

Can someone try this on their BRP072C42 controller?

  1. Generate a UUID4 (https://www.uuidgenerator.net/ is one way to do it). eg. 7b9c9a47-c9c6-4ee1-9063-848e67cc7edd

  2. Strip the hyphens from the UUID. eg. 7b9c9a47c9c64ee19063848e67cc7edd

  3. Grab the 13-digit key from the sticker on the back of the controller. eg. 0123456789012

  4. post the output of the following command - do NOT register the UUID at this point. I’d like to see the error message

curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd" -v "https://<controller-ip>/common/basic_info"
  1. Register your UUID as a valid token:

curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd" "https://<controller-ip>/common/register_terminal?key=0123456789012"

Please post the output

  1. Use the UUID to call the usual API endpoints:

curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd" "https://<controller-ip>/common/basic_info"

Please post the output

Hi Jim,

Output of "Register UUID as a valid token:

curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd" -v "https://10.100.100.97/common/register_terminal?key=0307222342343"
  • Trying 10.100.100.97…
  • Connected to 10.100.100.97 (10.100.100.97) port 443 (#0)
  • found 148 certificates in /etc/ssl/certs/ca-certificates.crt
  • found 592 certificates in /etc/ssl/certs
  • ALPN, offering http/1.1
  • SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
  • server certificate verification SKIPPED
  • server certificate status verification SKIPPED
  • common name: 015F4441494B494E000000430020A0DD.svr (does not match ‘10.100.100.97’)
  • server certificate expiration date OK
  • server certificate activation date OK
  • certificate public key: RSA
  • certificate version: #3
  • subject: C=JP,ST=Osaka,O=DAIKIN INDUSTRIES, LTD,CN=015F4441494B494E000000430020A0DD.svr
  • start date: Sat, 06 Apr 2019 01:56:10 GMT
  • expire date: Mon, 13 Mar 2119 01:56:10 GMT
  • issuer: C=JP,ST=Osaka,O=DAIKIN INDUSTRIES, LTD,CN=CA.daikindev.com
  • compression: NULL
  • ALPN, server did not agree to a protocol

GET /common/register_terminal?key=0307222342343 HTTP/1.1
Host: 10.100.100.97
User-Agent: curl/7.47.0
Accept: /
X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd

  • HTTP 1.0, assume close after body
    < HTTP/1.0 200 OK
    < Content-Length: 6
    < Content-Type: text/plain
    <
  • Closing connection 0
    ret=OK

Output of "Use the UUID to call the usual API endpoints"

$ curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd" -v "https://10.100.100.97/common/basic_info"

ret=OK,type=aircon,reg=th,dst=1,ver=1_13_7,rev=4335040,pow=1,err=0,location=0,name=%44%61%69%6b%69%6e%41%50%31%35%33%37%35,icon=0,method=home only,lpw_flag=0,adp_kind=3,pv=2,cpv=2,cpv_minor=00,led=1,en_setzone=1,mac=C0E434B74C85,ssid=DaikinAP15375,adp_mode=ap_run,en_hol=0,enlver=1.00,grp_name=,en_grp=0,en_secure=1,port=30050,id=,pw=

curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd" -v "https://10.100.100.97/aircon/get_control_info"

ret=OK,pow=1,mode=0,adv=,stemp=23.0,shum=0,dt1=23.0,dt2=M,dt3=23.0,dt4=25.0,dt5=25.0,dt7=23.0,dh1=0,dh2=50,dh3=0,dh4=0,dh5=0,dh7=0,dhh=50,b_mode=0,b_stemp=23.0,b_shum=0,alert=255

curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd" -v "https://10.100.100.97/aircon/get_model_info"

ret=OK,model=0C93,type=N,pv=2,cpv=2,cpv_minor=00,mid=NA,humd=0,s_humd=0,acled=0,land=0,elec=0,temp=1,temp_rng=0,m_dtct=1,ac_dst=–,disp_dry=0,dmnd=0,en_scdltmr=1,en_frate=0,en_fdir=0,s_fdir=0,en_rtemp_a=0,en_spmode=0,en_ipw_sep=0,en_mompow=0,en_patrol=0,en_fdir2=0,en_filter_sign=0

Can you call get_model_info using an invalid uuid?

curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc23edd" -v "https://10.100.100.97/aircon/get_model_info"
  • Trying 10.100.100.97…
  • Connected to 10.100.100.97 (10.100.100.97) port 443 (#0)
  • found 148 certificates in /etc/ssl/certs/ca-certificates.crt
  • found 592 certificates in /etc/ssl/certs
  • ALPN, offering http/1.1
  • SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
  • server certificate verification SKIPPED
  • server certificate status verification SKIPPED
  • common name: 015F4441494B494E000000430020A0DD.svr (does not match ‘10.100.100.97’)
  • server certificate expiration date OK
  • server certificate activation date OK
  • certificate public key: RSA
  • certificate version: #3
  • subject: C=JP,ST=Osaka,O=DAIKIN INDUSTRIES, LTD,CN=015F4441494B494E000000430020A0DD.svr
  • start date: Sat, 06 Apr 2019 01:56:10 GMT
  • expire date: Mon, 13 Mar 2119 01:56:10 GMT
  • issuer: C=JP,ST=Osaka,O=DAIKIN INDUSTRIES, LTD,CN=CA.daikindev.com
  • compression: NULL
  • ALPN, server did not agree to a protocol

GET /aircon/get_model_info HTTP/1.1
Host: 10.100.100.97
User-Agent: curl/7.47.0
Accept: /
X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc23edd

  • HTTP 1.0, assume close after body
    < HTTP/1.0 403 HTTP_FORBIDDEN
    < Content-Length: 0
    < Content-Type: text/plain
    <
  • Closing connection 0

Thanks! This will take me a while because I need to refactor the existing code, something that I’ve been wanting to do for a while and now there’s a good reason to do so. Once it has been refactored, adding this controller should be easier.

1 Like

Thank You! :smiley:

Hello testers @alexander_romanov_pv, @madsing, @alison, @RoyOven, etc.

Please download and try this jar:
https://github.com/jimtng/openhab-addons/blob/binaries/org.openhab.binding.daikin-2.5.4-SNAPSHOT.jar?raw=true

Steps:

  • Uninstall your built in daikin binding
  • Place the above jar into your addons folder
  • Make sure you have a UUID that has been registered against your adapter. If you haven’t got one:
    – generate a UUID4 from https://www.uuidgenerator.net/ and remove the dashes.
    – Obtain the 13-digit key from the sticker on the back of the controller. eg. 0123456789012
    – Then register your UUID:
curl --insecure -H "X-Daikin-uuid: uuidwithnodashes" "https://<controller-ip>/common/register_terminal?key=0123456789012"
  • In your things file, use this syntax:
Thing daikin:ac_unit:pickwhatevername [ host="x.x.x.x", secure=true, uuid="YOURUUID", refresh="15" ]
  • Setup your items file etc.

As far as I know, an openhab restart is not necessary.

Please report the result. I don’t have this adapter myself so I can’t do any testing on it.

2 Likes

Hi Jim, I did a quick test just now and it looks VERY promising. Connection with adaptor is established (Thing is ONLINE). Switch item for power added and it WORKS!

I’ll set other items later in a day and let you know the results. Thanks for you work! :slight_smile:

UPDATE:
All is working like a charm! :slight_smile:

1 Like

@alexander_romanov_pv thanks for testing.

One thing I haven’t implemented is the autodiscovery for this adapter. I’m not sure how to do it, since the registration requires a valid key and everything else requires a registered uuid. Any ideas? Could you perhaps do some sniffing/wiretapping on the android app to see how it does it beyond the UDP discovery, prior to the key being entered?

I am on iOS… sorry

Amazing work thanks @JimT - working well for me too.

Any glitches I’m seeing I believe are more likely due to my local config than any issues with your updated binding. Basically it seems to overwrite the updated binding with the 2.5.3 version on some restart events, but I have running well now.

Appreciate your effort!

I can help - have PMed you

I am wondering what to do during the discovery process because at that time, the thing hasn’t been created, so there’s no “uuid” to speak of. In such case, I could perhaps just declare it discovered despite receiving a 403 error?