Slow response from accessory results in failed scene

[michaelflux]

When using the BRP072C42 adapter inside of CTKS25TVMG units, it takes 6-10 seconds for the unit to respond to HomeKit.

As HomeKit expects a much faster response time from the accessories, the result is as follows;

• AC accessory is part of a scene (e.g. turn off living room AC when Goodnight scene is triggered)
• User triggers the scene, all other accessories work as expected.
• Since the AC accessory takes longer to respond than what HomeKit is expecting, the scene is marked as 'Failed' since the AC accessory did not respond in time.

The unit still turns on/off as expected, just not fast enough for HomeKit. Since we can't do anything about the hardware/firmware of these adapters to speed them up (using Daikin's own apps it's even slower), perhaps a solution would be for the plugin to instantly respond to HomeKit with a dummy 'success' status which would satisfy HomeKit's response time expectations, but then check/update the actual status when it becomes available 6-10 seconds later? Maybe not by default, but have a toggle for such dummy statuses in the config?

[11/21/2021, 11:17:19 AM] [Dining Room AC] setTargetHeaterCoolerState: received new state 2
[11/21/2021, 11:17:20 AM] [Dining Room AC] HomeKit requested the AC to operate in COOL mode.
[11/21/2021, 11:17:20 AM] [Dining Room AC] setTargetHeaterCoolerState: query: ret=OK&pow=0&mode=3&adv=&stemp=23.0&shum=0&dt1=24.0&dt2=M&dt3=23.0&dt4=25.0&dt5=25.0&dt7=24.0&dh1=0&dh2=50&dh3=0&dh4=0&dh5=0&dh7=0&dhh=50&b_mode=3&b_stemp=23.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=3&b_f_dir=3&dfd1=2&dfd2=0&dfd3=3&dfd4=0&dfd5=0&dfd6=0&dfd7=2&dfdh=0
[11/21/2021, 11:17:24 AM] [Dining Room AC] setActive: Power is 0, Mode is 3. Going to change power to 1.

RPReplay_Final1637464660.mov

[cbrandlehner]

What hardware are you running on? Any chance to try this plugin on a different platform?

I am running Homebridge on a Synology NAS with a Intel Atom processor and it performs OK.

[gid204]

I second this 'issue'. In the Homebridge-WOL plugin there is a similar issue raised: AlexGustafsson/homebridge-wol#85

A solution was implemented in the plugin to return an early success (as eluded to by OP). Is this something that could be implemented?

My performance seems to be mixed, the AC will ALWAYS turn on, but the scene/Siri will occasionally say it failed/took to long to respond, which gets annoying.

[cbrandlehner]

This plugin already uses early response.
I am not saying the code is perfect but one needs to understand what the exact problem is before changing anything.

[dchevell]

Same here - I've never had this fail to set the aircon state, but often see weird issues around response time. e.g. using the Shortcuts app, triggering an aircon setting will almost always result in "operation timed out". Using a siri command will work sometimes, and sometimes will come back with "accessory took too long to respond". I'm not sure how to provide more information, if I trigger an instance of this would there be logs that you could use?

btw, great work on this plugin!

[michaelflux]

@cbrandlehner Sorry for the delay in response - notifications from this repo enter up getting lost.

Homebridge 1.4.0 with homebridge-daikin-local v2022.3.1 running in Docker on a Synology DS1821+ (AMD cpu) - Daikin units connected through a Unifi setup. So no slowdowns anywhere on the hardware side (other than the BRP072C42 being slow).

When you say it performs ok, are you saying that when the AC is part a HomeKit scene you don't encounter timeouts such as what I had demonstrated in the initial comment?

But yes aside from the timeout issue, everything else has been solid.

[Shep084]

Did we find a solution to this issue? i'm having the exact same issue.
Running Hoobs box with all the latest firmware and plugins.

I had a look in the log and i am getting the below errors

08/05/2022, 1:18:04 pmDaikin Local BridgeERROR[Daikin Local Bridge 59EC@Target Heater-Cooler State] The write handler for the characteristic 'Target Heater-Cooler State' on the accessory 'Office Air Conditioning' was slow to respond!
08/05/2022, 1:18:04 pmDaikin Local BridgeERROR[Daikin Local Bridge 59EC@Cooling Threshold Temperature] The write handler for the characteristic 'Cooling Threshold Temperature' on the accessory 'Office Air Conditioning' was slow to respond!
08/05/2022, 1:18:04 pmDaikin Local BridgeERROR[Daikin Local Bridge 59EC@Active] The write handler for the characteristic 'Active' on the accessory 'Office Air Conditioning' was slow to respond!
08/05/2022, 1:18:04 pmDaikin Local BridgeERROR[Daikin Local Bridge 59EC@Rotation Speed] The write handler for the characteristic 'Rotation Speed' on the accessory 'Office Air Conditioning' was slow to respond!

[cbrandlehner]

@Shep084 Currently there are no known issues with the code of this plugin.

The advise is to use
a) child bridges
https://github.com/homebridge/homebridge/wiki/Child-Bridges
b) upgrade hardware if a) does not help
for more speed.

[michaelflux]

@cbrandlehner Trying your suggestion with child bridges - while it doesn't solve the issue of scenes having a 'Failed' status, it does make the AC units far more responsive, both when it comes to sending commands to them, and receiving the current status.

When using child bridges, as soon as I open the Home app, the AC status is instantly available, vs previously when I had to wait for 3-5 seconds while it was 'Updating'

[dchevell]

@cbrandlehner feels like we're not aligned on the problem here.

The problem, as I understand it: Some daikin modules/systems are very slow to respond, and can take up to 2-3 seconds to respond to a single HTTP request, which adds up when multiple requests (get info, set info) are required in order to have an effective interaction.

This is not a fault of this plugin, but viewing it that way is missing the point. This is an issue that can be resolved in this plugin, and it's unrealistic to suggest that the solution is to replace one's entire air conditioning system when we could solve it "for free" in software.

I've resolved this issue for myself by inserting an overcomplicated handwritten proxy service that does the following:

• Receives requests directly from this plugin via homebridge
• for requests to /aircon/set_control_info, converts the requested state into a compatible get_control_info value and caches it, sends the original request to the daikin wifi module in a background thread, and returns success immediately. Writes to the cache include a timestamp check to prevent/reduce race conditions
• for requests to /aircon/get_control_info, return the cached value if one exists; otherwise, wait for the raw upstream response.

This fairly short bit of caching/background threading magic is the only way to give homekit the fast responses it needs to provide a responsive UI. There's no way around this: some daikin modules are slow to respond to raw requests, and the only options available are to abstract it away from the user at a higher software layer (this plugin, homebridge, homekit) or to change one's air conditioning.

If desired I can put my little flask-based proxy service up somewhere; I think it would be a worthy addition to this plugin and make more sense to live here. It could be an opt-in configuration, "Return optimistic responses" or something similar.

I don't think it's on you to implement this, someone better than me could help turn this into a PR - but let's at least make sure we all agree on what needs to be solved.

[cbrandlehner]

The current release of this plugin does have a caching mechanism to reduce the number of API calls to the local device to a minimum.
In addition, the plugin will try to cope with slow devices by allowing the user to configure individual timeouts and allowed retries.
So in total, a lot of effort was invested to improve connectivity.

I assume the reported problem should be fixed in the meanwhile so I am closing this report.