OpenDaikin Binding from MarketPlace Questions

kevin · November 1, 2018, 1:32am

I’m shortly having a new Daikin AC installed and want to use the OpenDaikin Binding from the marketplace to control it.
Previously I’ve used IR commands recorded using the original remote to control things, but this hopefully offers an easier way.

Can someone advise whether sending the same command to the binding would result in it retransmitting the command to the AC?

For example if the unit is already on “COLD” and a rule sends the “COLD” command again will the binding transmit this or just ignore it?

Obviously I could use something like

 if (DaikinMode !== "COLD") {DaikinMode.sendCommand("COLD")}

but that complicates the rule if its not needed

@caffineehacker can you help?

I’ve getting the US7 unit which has many features, is the binding likely to be expanded or is it going to remain a basic Mode / Fan Speed / Setpoint / Power / Airflow Direction control facility?

OMR · November 2, 2018, 9:59pm

You could skip the binding and go this route.
Assuming your unit has a similt Eth/WiFi adapter as the one I’m using.

kevin · November 3, 2018, 1:38am

Thanks for the pointer, hopefully @caffineehacker will be along too with how he sees the binding developing in future so I can make an informed choice.

caffineehacker · November 3, 2018, 5:50pm

I believe the controller should send a new update to the A/C unit even you resend cold. One thing to note about Daikin units which makes them very difficult to work with is that you always have to include all of the information when you want it to change (the IR remote works this way too). E.g. you send it what mode, what the fan speed should be, what the temperature setpoint is, etc… with every command. I try to simplify that a lot with the binding by reading the current state from the A/C unit and only updating the fields you’ve chosen to update.

What features does the US7 have that aren’t covered? I’d be happy to expand it but with only my own units to test with I would need someone willing to confirm the other features are working correctly.

kevin · November 4, 2018, 1:49am

Thanks, the install is on Wednesday so I’ll see what is missing. The US7 has additional modes such as Humid Heating, Fresh Air and Dry Cooling, as well as options to send the air to where it detects people or send it away from people. It also has a built in Mold guard where it sterilises the filter and fan after use with a combination of UV and a drying function. Some of these could be setable as defaults with the remote.
When I have it installed I’ll play with the API and see what information comes back from a query after setting different things with the IR remote.
I’ll update this thread with what I find sometime later in the week or on the weekend

kevin · November 5, 2018, 7:45am

Turns out the install is on Friday so it’ll likely be early next week before I get chance to play with it

kevin · November 9, 2018, 3:54am

Tim,
unit is installed and the adapter appears as a thing. Unfortunately the thing sits with
a status of “OFFLINE - COMMUNICATION ERROR” and this lot is dumped in the log every minute.
It works with the phone app so I’m assuming its working - any idea of what I missed?

at java.lang.Thread.run(Thread.java:748) [?:?]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

at org.openhab.binding.opendaikin.handler.OpenDaikinAcUnitHandler.poll(OpenDaikinAcUnitHandler.java:154) ~[?:?]

at org.openhab.binding.opendaikin.handler.OpenDaikinAcUnitHandler.pollStatus(OpenDaikinAcUnitHandler.java:174) ~[?:?]

java.lang.NullPointerException: null

2018-11-09 16:50:18.943 [WARN ] [ikin.handler.OpenDaikinAcUnitHandler] - Unexpected error connecting to Daikin controller

caffineehacker · November 9, 2018, 5:47am

It looks like the enum for fan speed is incomplete and failed due to that. I’ll make a quick change and publish a new jar that handles this case (so it doesn’t crash) and will show the number it received instead of the enum value. If you can then tell me what the new numbers mean I should be able to add them to the addon.

kevin · November 9, 2018, 5:51am

Thanks for the reply, will test it tomorrow. (we’re GMT + 13 currently) Answers to queries are as follows in case it helps
http://ipAddress/aircon/get_sensor_info?

ret=OK,htemp=22.5,hhum=-,otemp=-,err=0,cmpfreq=0

http://ipAddress/aircon/get_control_info?

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

App currently shows 19 Degrees setPoint, Cooling, 22 Degrees Internal Temp, 20 Degrees Outside Temp

caffineehacker · November 9, 2018, 6:05am

That looks like exactly what I’d expect from the code. f_rate isn’t there which the code expected to see. I just pushed the new code to GitHub so it should be live by the time you get up. I probably won’t be able to dig in further this weekend, but if you want to try using the more advanced features and capturing a couple of the responses from get_control_info that should give me enough to figure out what I need to add to support them.

kevin · November 10, 2018, 10:06pm

Is there a place I can get the updated Jar from? Looking at GITHUB, which I don’t really inderstand, it seems I have to compile it first and I don’t currently have a development environment. Deleting and reinstalling from the MarketPlace just gives me the same binding with the same fault.
I just tried to create a development environment but as expected the instructions didn’t work and Maven spits a bunch of meaningless errors.

kevin · November 10, 2018, 10:39pm

Whilst I’m waiting for the binding I’ve been experimenting, it seems it’s controllable from Firefox with strings such as

http://ipAddress/aircon/set_control_info?pow=0&mode=1&stemp=21.5&shum=0

Using “sendHttpGetRequest” has allowed me to create a temporary workaround until I can get my hands on a JAR to test the binding.

here’s a few get_control_info strings from the extra, non app controlled modes:

19 Degrees Auto

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

19 Degrees Cooling

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

19 Degrees Heating

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

19 Degrees Fan (temp not selectable in this mode)

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

19 Degrees Dehumidify (temp not selectable in this mode)

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

That’s all that can be selected from the IOS app, rest are selected from the IR Remote and then queried in a browser

Humidify Low:

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

Humidify Std:

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

Humidify Hi:

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

Humidify Cont:

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

Fan Only with Fresh Air and Air Cleaner:

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

I suspect a lot of these new modes may be IR Remote only, but if we can work out the format of the command string it expects I can send commands to the unit and see what comes back. The Fresh Air one is a good start as I can hear the Fresh Air Fan running. Ultimately I suspect I’ll have to start recording IR Command Strings, but it makes sense to find out what can be achieved with WiFi first

Riccardo_Ottolina · November 12, 2018, 9:48pm

Hi All, I think I had a similiar problem!
with OpenDaikin 2.3 all works fine in one direction Daiikin ==> OH2. If I use the AC with the App or the cabled display, OH2 updates the values accordling… but when I try, for example, to turn it on:

2018-11-12 22:46:04.306 [vent.ItemStateChangedEvent] - opendaikin_ac_unit_192_168_88_52_power changed from OFF to ON

==> /var/log/openhab2/openhab.log <==
2018-11-12 22:46:04.440 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.opendaikin.handler.OpenDaikinAcUnitHandler@b73b58’: null
java.lang.NullPointerException: null
at org.openhab.binding.opendaikin.internal.api.ControlInfo.getParamString(ControlInfo.java:161) [245:org.openhab.binding.opendaikin:2.3.0.201803241901]
at org.openhab.binding.opendaikin.internal.OpenDaikinWebTargets.setControlInfo(OpenDaikinWebTargets.java:48) [245:org.openhab.binding.opendaikin:2.3.0.201803241901]
at org.openhab.binding.opendaikin.handler.OpenDaikinAcUnitHandler.changePower(OpenDaikinAcUnitHandler.java:214) [245:org.openhab.binding.opendaikin:2.3.0.201803241901]
at org.openhab.binding.opendaikin.handler.OpenDaikinAcUnitHandler.handleCommand(OpenDaikinAcUnitHandler.java:64) [245:org.openhab.binding.opendaikin:2.3.0.201803241901]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [101:org.eclipse.smarthome.core:0.10.0.oh230]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [101:org.eclipse.smarthome.core:0.10.0.oh230]
at com.sun.proxy.$Proxy143.handleCommand(Unknown Source) [245:org.openhab.binding.opendaikin:2.3.0.201803241901]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [108:org.eclipse.smarthome.core.thing:0.10.0.oh230]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [108:org.eclipse.smarthome.core.thing:0.10.0.oh230]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [101:org.eclipse.smarthome.core:0.10.0.oh230]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [101:org.eclipse.smarthome.core:0.10.0.oh230]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]

==> /var/log/openhab2/events.log <==
2018-11-12 22:46:40.822 [vent.ItemStateChangedEvent] - opendaikin_ac_unit_192_168_88_52_power changed from ON to OFF

in my opinion I have some parameter at NULL that breaks the function…

thank you in advance for the support!

kevin · November 12, 2018, 10:46pm

Try typing into a web browser http://ipAddress/aircon/get_control_info?
and post what you get back (if you put this in the middle of 3 lines with 5 spaces before it on your post it will go into the easier to read code format)
That should let @caffineehacker know whether your aircon is returning the fan information - mine doesn’t but I think most do

Riccardo_Ottolina · November 12, 2018, 11:37pm

 ret=OK,pow=0,mode=3,stemp=25.0,shum=--,dt1=25.0,dt2=--,dt3=25.0,dt4=25.0,alert=0,adv=,f_rate=3,dfr1=3,dfr2=-,dfr3=3,dfr4=3,dfr6=3

and
get_sensor_info?

 ret=OK,htemp=24,otemp=-,hhum=-,err=0

thank you!

kevin · November 12, 2018, 11:49pm

No fan information in there - sounds like we have the exact same problem. I’m currently using mine with a simple work around using the http binding in case you just want ON and OFF control. You can use something in a rule like

acHost = http://yourACipAddress:80/
var acCommandString = ""

rule "Turn AC ON"
when Item AC changed then
if (AC.state == ON){
    acCommandString = "aircon/set_control_info?pow=1&mode=0&stemp=18&shum=0"
    logInfo("DaikinPower", "acCommandString=" + acCommandString)
    logInfo("DaikinPower", "sendHttpGetRequest() returns: " + sendHttpGetRequest(acHost + acCommandString, 5000)) 
    }
if (AC.state == OFF){
    var acCommandString = "aircon/set_control_info?pow=0&mode=0&stemp=18&shum=0"
    logInfo("DaikinPower", "acCommandString=" + acCommandString)
    logInfo("DaikinPower", "sendHttpGetRequest() returns: " + sendHttpGetRequest(acHost + acCommandString, 5000)) 
    }
end

Hopefully the fixed binding will appear soon

caffineehacker · November 30, 2018, 4:06am

Interesting, it should be up on the Marketplace with the null pointer fix, but I admit I have no idea how OpenHab updates addons from the Marketplace so it might not be pulling the latest if you’ve installed it previously.

Edit: Looks like when the version bumped from 2.3 to 2.4 I needed to update where the jar was picked up from in the marketplace. I made the update so it should now be pointing to the most recent jar.

kevin · November 30, 2018, 7:13am

I’ve worked a solution out using the HTTP binding which is working well, although I’ll give your binding a test when I get chance. Is there any way to add extra receiving items to it such as compressor frequency which I’ve just added to my setup so I can work out the best way to get maximum cooling

Riccardo_Ottolina · December 1, 2018, 10:58am

Thank you!
I put the jar from https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.opendaikin/2.4.0-SNAPSHOT/ in the addons folder and it works ow!

thank you so much, I will test it further in next days!

Paul_Smedley · December 1, 2018, 8:44pm

This looks interesting. I just installed a Daikin BRP15B61 Wifi adapter for a Daikin ducted AC system.

The API looks similar but also a little different Using Wireshark I’ve discovered API per my post at https://forums.whirlpool.net.au/forum-replies.cfm?t=2768285

eg http://ipAddress/aircon/get_sensor_info? is http://ipAddress/skyfi/aircon/get_sensor_info? on the BRP15B61

Wondering if the opendaikin plugin could easily be modified to support multiple Daikin adapters?

Thanks!

Cheers,

Paul