For mode, you need rules to keep Alexa/Google in sync with power on/off and AC mode.
Hopefully tomorrow I’ll get time to write code for the binding to do this for us. I have code written that doesn’t quite work for Google -> Airbase but still need to write code for Airbase -> Google
@Paul_Smedley instead of implementing the google/alexa power modes in the binding, shouldn’t that just be an example rule in the documentation?
PS the binding doc needs some clarifications. At first when people copy pasted the example items definition, they’d assume the “fanspeed” and “setpoint” would work for airbase too. The example needs to be split up. One example for non airbase, another separate example for airbase. It would make it more “copy paste” friendly 
Alternatively if it’s possible, just use “fanspeed” instead of “airbasefanspeed”, and “setpoint” instead of “settemp” to make it uniform.
Hi @JimT,
This is possible… but I don’t like it… rules adds another layer of complexity, which is beyond many users. In particular, item names would need to be changed by the user to suit how they added the items.
Feel free to submit a PR for this 
docs ain’t my thing 
https://github.com/openhab/openhab2-addons/pull/6476
Sorry if this doesn’t conform to the contribution standards. It’s my very first PR on github.
I would prefer that the airbase version would just use the same channel name “setpoint” and “fanspeed”.
Hi Guys,
Updating Binding at http://smedley.id.au/tmp/org.openhab.binding.daikin-2.5.0-SNAPSHOT.jar
This adds a new channel for use with homekit/alexa/google home, CHANNEL_AC_HOMEKITMODE
Current supported values for this channel are off, on, heat & cool.
Currently only homekit -> daikin is supported. If I change mode via the Google Home app, the correct power/mode settings are applied via the airbase app.
I’ll try write the code to sync airbase -> homekit tomorrow. Most likely this will occur at a refresh event, so there may be a slight lag when changing via openhab back to homekit/alexa/google.
docs still to be updated.
Cheers,
Paul
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
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.