[daikin] Delay in commands being enacted

glen_m · October 6, 2025, 6:46am

Issue Summary:

When issuing a command from OpenHAB (e.g. turn on/off power), it can take 5-9+ seconds for the Heatpump to enact the command (i.e. for the power led to come on), and it looks like even more for the switch state to be updated in OpenHAB. (Maybe even up to 15 seconds).

Initial investigation:

There may be 2 issues in play here (I will treat them separately for now, until proven otherwise):

It appears that it can take 5-9+ seconds just for OpenHAB to send the resulting HTTP/S request to the heatpump
After that, it may take another similar amount of time for the Switch state to update in OpenHAB. I though it was similar to [daikin] Update channels immediately after a successful API command by jimtng · Pull Request #17149 · openhab/openhab-addons · GitHub but that looks like it was resolved/merged in OH 4.3

This only occurs for the newer heatpump with the BRP072C42 WiFi adapter (HTTP/S), I have 3 other Daikin Heatpumps using the BRP072A42 WiFi adapters (HTTP) for which the binding seems to issue commands immediately, and the status update in OpenHAB is also immediate.

This delay issue occurs for any valid channel for this HeatPump (Power, Temp Set Point etc). I have tried updating the refresh interval (currently 5 sec, was 15), even as low as 1 sec, and there was no difference for the time to send the command to the unit, however perhaps the state update for the switch occurred within a few seconds of the unit actually powering on.

I will keep digging around, but wondering if anyone has some ideas (or a similar issue), before I log a github issue.

Environment
OpenHAB Version: 5.0.1 (Release Build)
Java Version: 21.0.8 (Azul Systems, Inc.) - Zulu21.44+17-CA
OS: Ubuntu Server 25.04
Daikin Binding: 5.0.1
WiFi Adapter Model: BRP072C42
WiFi Adapter Firmware Version: 1.16.0

Thing Config
Channels excluded for brevity

UID: daikin:ac_unit:DaikinAirconLiving
label: Living Heat Pump
thingTypeUID: daikin:ac_unit
configuration:
  host: 192.168.4.50
  refresh: 5
  secure: true
  uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  key: "xxxxxxxxxxxxx"

events.log

2025-10-06 18:06:13.408 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LivingHeatPump_Power' received command OFF
2025-10-06 18:06:25.000 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LivingHeatPump_Power' changed from ON to OFF

openhab.log (trace)

2025-10-06 18:06:01.266 [TRACE] [n.internal.handler.DaikinBaseHandler] - Polling for state
2025-10-06 18:06:01.267 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:01.267 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_control_info
2025-10-06 18:06:03.185 [TRACE] [ding.daikin.internal.api.ControlInfo] - Parsing string: "ret=OK,pow=1,mode=4,adv=,stemp=19.0,shum=0,dt1=25.0,dt2=M,dt3=25.0,dt4=19.0,dt5=19.0,dt7=25.0,dh1=AUTO,dh2=50,dh3=0,dh4=0,dh5=0,dh7=AUTO,dhh=50,b_mode=4,b_stemp=19.0,b_shum=0,alert=255,f_rate=A,b_f_rate=A,dfr1=A,dfr2=A,dfr3=A,dfr4=A,dfr5=A,dfr6=A,dfr7=A,dfrh=A,f_dir=0,b_f_dir=0,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0"
2025-10-06 18:06:03.186 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:03.186 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_sensor_info
2025-10-06 18:06:03.861 [TRACE] [scovery.DaikinACUnitDiscoveryService] - Starting broadcast for /172.17.255.255
2025-10-06 18:06:04.863 [TRACE] [scovery.DaikinACUnitDiscoveryService] - Starting broadcast for /192.168.91.255
2025-10-06 18:06:05.088 [TRACE] [nding.daikin.internal.api.SensorInfo] - Parsing string: "ret=OK,htemp=23.0,hhum=-,otemp=15.0,err=0,cmpfreq=0"
2025-10-06 18:06:05.089 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:05.089 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_year_power_ex
2025-10-06 18:06:05.866 [TRACE] [scovery.DaikinACUnitDiscoveryService] - Starting broadcast for /192.168.10.255
2025-10-06 18:06:06.975 [TRACE] [g.daikin.internal.api.EnergyInfoYear] - Parsing string: "ret=NG (time is not sync)"
2025-10-06 18:06:06.976 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:06.976 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_week_power_ex
2025-10-06 18:06:08.818 [TRACE] [in.internal.api.EnergyInfoDayAndWeek] - Parsing string: "ret=NG (time is not sync)"
2025-10-06 18:06:08.818 [DEBUG] [in.internal.api.EnergyInfoDayAndWeek] - EnergyInfoDayAndWeek::parse() did not receive 'ret=OK' from adapter
2025-10-06 18:06:13.410 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:13.410 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_control_info
2025-10-06 18:06:13.818 [TRACE] [n.internal.handler.DaikinBaseHandler] - Polling for state
2025-10-06 18:06:15.372 [TRACE] [ding.daikin.internal.api.ControlInfo] - Parsing string: "ret=OK,pow=1,mode=4,adv=,stemp=19.0,shum=0,dt1=25.0,dt2=M,dt3=25.0,dt4=19.0,dt5=19.0,dt7=25.0,dh1=AUTO,dh2=50,dh3=0,dh4=0,dh5=0,dh7=AUTO,dhh=50,b_mode=4,b_stemp=19.0,b_shum=0,alert=255,f_rate=A,b_f_rate=A,dfr1=A,dfr2=A,dfr3=A,dfr4=A,dfr5=A,dfr6=A,dfr7=A,dfrh=A,f_dir=0,b_f_dir=0,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0"
2025-10-06 18:06:15.372 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:15.373 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_control_info
2025-10-06 18:06:17.269 [TRACE] [ding.daikin.internal.api.ControlInfo] - Parsing string: "ret=OK,pow=1,mode=4,adv=,stemp=19.0,shum=0,dt1=25.0,dt2=M,dt3=25.0,dt4=19.0,dt5=19.0,dt7=25.0,dh1=AUTO,dh2=50,dh3=0,dh4=0,dh5=0,dh7=AUTO,dhh=50,b_mode=4,b_stemp=19.0,b_shum=0,alert=255,f_rate=A,b_f_rate=A,dfr1=A,dfr2=A,dfr3=A,dfr4=A,dfr5=A,dfr6=A,dfr7=A,dfrh=A,f_dir=0,b_f_dir=0,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0"
2025-10-06 18:06:17.269 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:17.269 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/set_control_info?mode=4&f_rate=A&shum=0&pow=0&stemp=19.0&f_dir=0
2025-10-06 18:06:19.161 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:19.161 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_sensor_info
2025-10-06 18:06:21.106 [TRACE] [nding.daikin.internal.api.SensorInfo] - Parsing string: "ret=OK,htemp=23.0,hhum=-,otemp=15.0,err=0,cmpfreq=0"
2025-10-06 18:06:21.107 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:21.107 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_year_power_ex
2025-10-06 18:06:23.061 [TRACE] [g.daikin.internal.api.EnergyInfoYear] - Parsing string: "ret=NG (time is not sync)"
2025-10-06 18:06:23.062 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:23.070 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_week_power_ex
2025-10-06 18:06:24.998 [TRACE] [in.internal.api.EnergyInfoDayAndWeek] - Parsing string: "ret=NG (time is not sync)"
2025-10-06 18:06:24.999 [DEBUG] [in.internal.api.EnergyInfoDayAndWeek] - EnergyInfoDayAndWeek::parse() did not receive 'ret=OK' from adapter
2025-10-06 18:06:30.000 [TRACE] [n.internal.handler.DaikinBaseHandler] - Polling for state
2025-10-06 18:06:30.000 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:30.000 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_control_info
2025-10-06 18:06:31.912 [TRACE] [ding.daikin.internal.api.ControlInfo] - Parsing string: "ret=OK,pow=0,mode=4,adv=,stemp=19.0,shum=0,dt1=25.0,dt2=M,dt3=25.0,dt4=19.0,dt5=19.0,dt7=25.0,dh1=AUTO,dh2=50,dh3=0,dh4=0,dh5=0,dh7=AUTO,dhh=50,b_mode=4,b_stemp=19.0,b_shum=0,alert=255,f_rate=A,b_f_rate=A,dfr1=A,dfr2=A,dfr3=A,dfr4=A,dfr5=A,dfr6=A,dfr7=A,dfrh=A,f_dir=0,b_f_dir=0,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0"
2025-10-06 18:06:31.913 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Header: X-Daikin-uuid: xxxx
2025-10-06 18:06:31.913 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_sensor_info
^C2025-10-06 18:06:33.804 [TRACE] [nding.daikin.internal.api.SensorInfo] - Parsing string: "ret=OK,htemp=23.0,hhum=-,otemp=15.0,err=0,cmpfreq=0"

The above spans one minute pre/post the Command being issued, but probably the following line is key:

2025-10-06 18:06:17.269 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/set_control_info?mode=4&f_rate=A&shum=0&pow=0&stemp=19.0&f_dir=0

Which seems to actually send the command 4 seconds after the Command was registered by OpenHAB.

glen_m · October 8, 2025, 1:18am

Just adding a bit of further diagnostic/faultfinding information here, of additional steps tried:

Firewall Change (Heatpump to internet)

Have opened up my firewall to allow connections from the heatpump out to the internet. Part of the reason I opened the firewall, is to see if any updates are applied to the BRP WiFi adapter. Looks like the adapter was attempting to connect daily (early hours of the morning) - Maybe that’s a timesync, maybe a firmware check?? Might have a better idea tomorrow.

However this step has cleaned up the following in the Debug Log:

2025-10-06 18:06:21.107 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_year_power_ex
2025-10-06 18:06:23.061 [TRACE] [g.daikin.internal.api.EnergyInfoYear] - Parsing string: "ret=NG (time is not sync)"

And now getting, what I presume to be a expected return:

025-10-08 13:35:56.821 [TRACE] [ing.daikin.internal.DaikinWebTargets] - Calling url: https://192.168.4.50/aircon/get_year_power_ex
2025-10-08 13:35:58.687 [TRACE] [g.daikin.internal.api.EnergyInfoYear] - Parsing string: "ret=OK,curr_year_heat=0/0/0/0/0/0/0/0/0/0/0/0,prev_year_heat=0/0/0/0/0/0/0/0/0/0/0/0,curr_year_cool=0/0/0/0/0/0/0/0/0/0/0/0,prev_year_cool=0/0/0/0/0/0/0/0/0/0/0/0"

I know its not related, but may as well clean-up the log while going though this. (Looks like it somehow uses HTTP for timesync, as I have not seen any NTP requests blocked by the firewall).

2) Added Daikin Heatpump Cert to System Certificate Store

Exported Daikin cert by browsing to heatpump
`sudo cp daikin.pem /usr/local/share/ca-certificates/daikin.crt`
`sudo update-ca-certificates`
Restart OpenHAB

No change to behaviour

3) Change CRL behaviour

Added following to `/etc/defaults/openhab` :

`EXTRA_JAVA_OPTS=“-Dcom.sun.net.ssl.checkRevocation=false -Dcom.sun.security.enableCRLDP=false”`

No change in behaviour, and I hadn’t seen any attempts to contact a CRL in the packet capture pre/post this change (not that this is listed in the cert either)… But thought its worth a try anyway.

4) Perform network packet capture

I have also been performing packet captures whilst sending commands to heatpump. Only thing I am seeing, is that it appears that every call to the Heatpump involves a new connection (key exchange, handshake etc). Could this possibly be a contributing factor (at least to issue 1 listed in Original Post).

5) Misc

Have noticed that the background discovery is kicking off reasonably frequently (every 2 minutes). I have no idea how long this takes to complete, or if it could affect other functions of the binding while running:

2025-10-08 13:36:16.891 [TRACE] [scovery.DaikinACUnitDiscoveryService] - Starting broadcast for /172.17.255.255
2025-10-08 13:36:17.893 [TRACE] [scovery.DaikinACUnitDiscoveryService] - Starting broadcast for /192.168.91.255
2025-10-08 13:36:18.895 [TRACE] [scovery.DaikinACUnitDiscoveryService] - Starting broadcast for /192.168.10.255

And unfortunately it includes a large Class B address space for Docker. I see this can be disabled via the runtime file, but is there an option to configure this via the UI?:

discovery.daikin:background=false

as all my other config is done via the UI now (everything in `/etc/openhab/services/runtime.cfg` is now commented out)

jimtng · October 8, 2025, 5:59am

How’s the cpu utilisation?

Can you check using this command Openhab 5.0.1 on docker java-21 high cpu and ram usage - #3 by rlkoshak

In a normal scenario, the request to daikin should be sent out immediately as soon as you send a command to the item. If there’s a delay, it would be caused by cpu or queue starvation.

Have you tried observing how much delay occured after a fresh openhab restart?

jimtng · October 8, 2025, 6:24am

I tried this on my instance and can confirm an immediate call to daikin:

16:23:03.578 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Aircon_SetPoint' received command 23 °C
16:23:03.583 [TRACE] [ding.daikin.internal.DaikinWebTargets] - Calling url: http://192.168.1.30/skyfi/aircon/get_control_info
16:23:03.713 [TRACE] [ternal.api.airbase.AirbaseControlInfo] - Parsing string: "ret=OK,pow=1,mode=2,operate=2,bk_auto=2,stemp=23,dt1=23,dt2=23,f_rate=3,dfr1=3,dfr2=3,f_airside=0,airside1=0,airside2=0,f_auto=0,auto1=0,auto2=0,f_dir=0,dfd1=0,dfd2=0,filter_sign_info=0,cent=0,en_cent=0,remo=2"
16:23:03.714 [TRACE] [ding.daikin.internal.DaikinWebTargets] - Calling url: http://192.168.1.30/skyfi/aircon/set_control_info?mode=2&f_airside=0&f_rate=3&shum=&pow=1&stemp=23.0&f_auto=0&f_dir=0

glen_m · October 8, 2025, 8:09am

Hi @jimtng - Cheers for having a look. When I was doing the subsequent fault-finding, each change I made to the Java Opts required a restart of Openhab. There was no perceivable difference in the timing after a fresh Openhab restart.

CPU should not be an issue - I was monitoring it with ‘top’ while performing the actions previously, and generally was sitting at <1% used (0.5-0.8%). I run a few other things on this system, but it is a Ryzen 7 5800 with 32GB Ram, so mostly is idle.

I did try the ttop command (although TBH, not super sure about how to interpret the output), but didn’t see anything changing significantly (I assume I would see something in the T-Blocked column if it was thread jammed?).

I also have the same result as you on my other Heatpumps, using HTTP (these have the BRP072A42 controller) - They respond immediately to all interactions in OpenHAB

Its only my newer heatpump with the BRP072C42 which requires HTTP/S which is the issue. At least it does work, and its just a case of being patient and waiting for the Button to change colour 10-15s later after you power it on (With the heatpump turning on about half-way during that time)

Its probably the temperature setpoint which is the most annoying (a dial) - turns into a game of whack-a-mole, where the dial moves to where you set it, back to the original temp again, and then back to what you intended to set it to about 10-15 sec later!!

Cheers - Glen

jimtng · October 8, 2025, 2:20pm

I’ve set up a https → http reverse proxy for my daikin controller, so that openhab would connect to it using secure option. Here’s my daikin.things file:

daikin:airbase_ac_unit:DaikinAP68583 [ host="daikin.local", secure=true ]

And here are my logs:

00:16:14.460 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Aircon_SetPoint' received command 23 °C
00:16:14.462 [TRACE] [ding.daikin.internal.DaikinWebTargets] - Calling url: https://daikin.local/skyfi/aircon/get_control_info
00:16:14.589 [TRACE] [ternal.api.airbase.AirbaseControlInfo] - Parsing string: "ret=OK,pow=0,mode=2,operate=2,bk_auto=2,stemp=23,dt1=23,dt2=23,f_rate=3,dfr1=3,dfr2=3,f_airside=0,airside1=0,airside2=0,f_auto=0,auto1=0,auto2=0,f_dir=0,dfd1=0,dfd2=0,filter_sign_info=0,cent=0,en_cent=0,remo=2"
00:16:14.590 [TRACE] [ding.daikin.internal.DaikinWebTargets] - Calling url: https://daikin.local/skyfi/aircon/set_control_info?mode=2&f_airside=0&f_rate=3&shum=&pow=0&stemp=23.0&f_auto=0&f_dir=0

So we can rule out https vs http here.

jimtng · October 8, 2025, 2:30pm

I’m curious, what’s the definition of item LivingHeatPump_Power ? Is it directly linked to daikin’s power channel or does it go through some rule?

glen_m · October 9, 2025, 8:26am

HI @jimtng - Cheers for those ideas & trying that - It certainly shows that the HTTP/S protocol itself doesn’t slow things down from an OpenHAB perspective, but given you are talking to NGINX (or something similar), I’m not sure it entirely rules it out?

The TLS negotiation with the reverse proxy will likely be different (and arguably probably better) to that of the Daikin WiFi adapter, the self signed certs presented by Daikin may have some anomalies which result in CRL/OCSP issues slowing things down in the negotiation (albeit I haven’t actually captured any attempts to reach out to an external service for this).

So it could be limitation(s) of the Daikin controller, and Openhab bindings handling of these factors contibuting to the issue?

Unfortunately, as I have been using PFSENSE for the packet capture (easiest place for me to do this), it only seems to support relative time, not absolute time, which is a bit of a nightmare for marrying it up to the Openhab logs timing. What this means, is its difficult to tell what, if any, related packets are sent to the Heatpump between when event log reports the item being turned on, and then the OH trace log reports actually sending the command. I may need to rethink how/where I capture this.

I would be keen to know if anyone out there with the same Daikin adapter, is seeing similar issues, or managed to get it working ok. That may quickly rule in/out a bunch of things

I might (when I get some time) go back to basics. Use something like CURL or Postman for faultfinding to directly issue commands to the Heatpump, and manipulate the TLS negotiation etc, look at the cert handling etc. If I can’t get it to perform a timely activation via one of those methods, then there is no hope for Openhab to do so - Means its just the Daikin adapter.

But if they do work OK, you have given me an idea however… I’ll probably try setup NGINX as a reverse proxy with HTTPS connection to the Heatpump (thereby having NGINX handle the connection/negotiation with the Heatpump, and Openhab only needs to negotiate TLS with NGINX)…

Not sure how feasible that it, and may take me a bit to think about it!

Just a direct link, no rules between the items and the channels….

Cheers - Glen

jimtng · October 9, 2025, 12:16pm

Take a look at the source code for the binding, perhaps you can trace things more easily.

jimtng · October 9, 2025, 3:41pm

Have you tried restarting the daikin controller itself?

glen_m · October 12, 2025, 8:31am

HI @jimtng - Thanks for the further response

Many times, no perceivable difference (My power lines company even managed to do this again for is on Friday, with a local outage!!)

I have looked at the source code, and struggled a bit as its not really my background - I am from IT infrastructure background, not so much dev, hence why a lot of my faultfinding is looking ‘outside in’ (network captures, logs etc).

But from my basic understanding, this uses Java’s HttpsURLConnection?

That all aside, I probably have made an incorrect assumption about the binding taking 4 or so seconds to actually send the command (The time difference between the item going on from the events file, and the command being sent to the heatpump (from the TRACE logging).

Perhaps the underlying library is trying to negotiate a TLS connection during those 4 seconds (rather than being when the connection is first attempted after 4 seconds).

I gave postman a whirl, and it complains SSL Error: Unable to verify the first certificate and after disabling SSL Verification, is seems to consistently take around 1800ms for https://192.168.4.50/common/basic_info to complete

Next step will be for me to try find some additional info using curl, but need to address the fact it looks like the Daikin adapter and OpenSSL 3.0 don’t see eye to eye on the negotiation. I will try figure that out later this week.

Cheers