OK, Updated again… should sync power/mode to the appropriate homekit thermostat state. Same link as previous post.
Hi Paul
Im confused what this channel actually does? Right now I have no ability to use heat/cool but it works fine for off/on and the zones work also along with setpoint. Cheers
@dastrix80 the intent is to make it easier to use with Google Assistant…
Google assistant expects a mode command that supports on, off, heat & cool. Tag this new command/channel as the mode…
Ah. I use Alexa. I’ve not worked out how to change the mode using Alexa
I would assume this is wrong
String DaikinACUnit_Mode "Air Mode" (Group_HabPanel_Dashboard) { channel="daikin:airbase_ac_unit:ducted_ac:mode", alexa="PowerController.powerState" }
Alexa can use homekit tags…
I have:
DaikinBindingAirbaseACUnit1921681150_Power tagged as [Switchable] (allows turn on/off type commands)
DaikinBindingAirbaseACUnit1921681150_SetPoint tagged as [TargetTemperature]
DaikinBindingAirbaseACUnit1921681150_IndoorTemperature tagged as [CurrentTemperature]
DaikinAirbaseACUnit_HomekitMode tagged as [homekit:HeatingCoolingMode]
Ah!
PS: Not sure if the binding honours refresh? using the setpoint with a slider
The logs show this, anyone else get this? When i do the command a second time (im using Habpanel to change the temp via slider) it works.
DaikinACUnit_SetPoint predicted to become 24
DaikinACUnit_SetPoint changed from 31.0 °C to 24.0 °C
DaikinACUnit_SetPoint changed from 24.0 °C to 31.0 °C
Hi Paul, can it so that you dont need to adjust the temp twice for it to work?
Anything is possible, I just need to work out how best to implement this. Unlikely to happen before Christmas, unless someone else contributes code.
Thats OK Paul, i know you’re busy and appreciate you developing this - happy to wait mate! 
Cheers
EDIT: even just sending HEAT to the mode channel, it appears to do it as well, changes then changes back
12:48:18.664 [INFO ] [arthome.event.ItemStatePredictedEvent] - DaikinACUnit_Mode predicted to become HEAT
12:48:18.665 [INFO ] [smarthome.event.ItemStateChangedEvent] - DaikinACUnit_Mode changed from FAN to HEAT
12:48:19.051 [INFO ] [smarthome.event.ItemStateChangedEvent] - DaikinACUnit_Mode changed from HEAT to FAN
The challenge here is that a single http command returns updated values for several channels (power, fan speed, mode, etc). REFRESH itself is easy, but at startup, each channel is issued with REFRESH, so the way the code is currently designed, we’d call the http commands for sensor, status or zone as many times as there are channels.
The solution to this is to cache the values returned by httpd, but this code confuses the heck out of me (I consider myself a hacker not a programmer :P). Once cacheing is implemented, if the http is called again before the cache expires, the code would just return the cached value.
The positive side is that once I work this out, I can apply the same logic to my opengarage binding, and the tesla powerwall one that I have in work
1 Like
Ah, understood why this occurs then. Geeh, if you’re a hacker making a binding I dunno what that makes me 
@Paul_Smedley, would you mind if I take a crack at the airbasefanspeed? I’d like to make it have 7 states like I described above.
Don’t forget, someone else created the binding for european adapters, I just modified it to work with the Airbase and added zoning support
Go for it… this will be a bit of work, as it means when you change a fan setting, you’re going to need to set f_airside, f_rate, and f_auto - the current code only handles f_rate
Also not sure how you detect if Airside is supported - my system doesn’t seem to support it. We need to ensure that nothing breaks if this is set on a system that doesn’t support it. It would be nice if we could query model info and dynamically set the supported fan modes based on this, but I’m not sure Openhab is that smart.
My output: ret=OK,pow=0,mode=1,stemp=23,dt1=23,dt2=23,dt3=23,f_rate=3,dfr0=1,dfr1=3,dfr2=1,dfr3=1,f_airside=0,airside0=0,airside1=0,airside2=0,airside3=0,f_auto=0,auto0=0,auto1=0,auto2=0,auto3=0,f_dir=0,dfd0=0,dfd1=0,dfd2=0,dfd3=0,dfd7=0,filter_sign_info=0,cent=0,en_cent=0,remo=2
I do wonder what would happen if I send the f_airside=1 command - I assume I’d get a NOK response code…
From http://192.168.1.xx/skyfi/aircon/get_model_info:
....,en_airside=1,....
I presume this means “enable airside” ? What does yours say?
Mine says …,en_airside=0,…
So we should be able to parse the get_model_info string to know if this is supported or not. If not supported, if the Airside mode is selected, the code should not get run, so the fan speed won’t change.
Hi @Paul_Smedley,
I’ve managed to get my development environment set up on my laptop, and was able to build the daikin binding. I’ll work on the airbasefanspeed but I might rehash some of the info classes a bit first. I wish I could just work off your PR since I noticed you’ve had some work on Refresh as well as that homekitmode.
While looking through the binding’s code, I noticed that there’s no channel name called “setpoint” as mentioned in the doc’s example. Both airbase and non airbase use “settemp”. Upon closer inspection, the documentation also stated that “settemp” is the channel name for both non airbase and airbase. So the Doc’s example is wrong about the non airbase being “setpoint”. I’ll submit another PR for the doc.