I already wondered why this was configurable, since you cant change the port on the daikin modules anyhow, but maybe it will be useful when you want these behind a loadbalancer and/or proxy, but most users won't have as many vlans/subnets as I do . Perhaps the devs can add a hint to the interface.

I'm trying to control my Daikin Airco with Domoticz.
However, when I try to set the temperature in the dashboard (see screenshot) the log displays:
2016-10-17 16:46:54.717 User: admin initiated a SetPoint command
But nothing changes on the Airco.
For the record, I'm using Domoticz on WIndows.
Can anyone explain this or help me?

Well I'm sorta missing the following options in the wiki script: (note that I did not spend much time trying to add these to the script since I expected native support to come soon, guess I was wrong on that one:) )

Manual Mode Control (domoticz now has a multi-mode control switch type device)
Humidity Control (Ururu Sarara models)
Ventilation/Fresh-air Control (Ururu Sarara models)
Air purification/Flash streamer control
Powerful Mode Control
Fan speed control incl. silent mode

I have silent mode in my own installation and humidity is trivial looking at:http://192.168.10.26/aircon/get_control_info
Supporting humidify/cool/heat using the selector should also be simple and is a good idea (like the one I used in https://www.domoticz.com/wiki/NAD7050 for my amplifier mode), I removed all the options in the past because my domoticz interface became too cluttered with buttons (like you also said viewtopic.php?t=7244). I would probably use a selector for the mode, a selector for the fan speed (including auto and silent), a setpoint for temperature and a setpoint for humidity (though I never use humidify). The other options you mention cannot be reached from the Wifi interface as far as I know.

I will probably rewrite the daikin script yet again to support more features, but I will first replace my KAKU blinds with ZWAVE, so it will probably not be very soon.

I would definitely appreciate your efforts on adding this to the script, take all the time you need. Exactly like you said, the selector switches would be ideal for fan speed and mode settings. I did some investigation into the other options, you are right in that they cannot be set from the app for FTXNxxN (Ururu Sarara) models, however these are present in the app for the FTXMxxM models and are controlled through the adv= parameter (which is also present on the US models, however not updated when setting these options through the remote).

I've found the following values for these settings on the FTXM:
Powerful Mode: adv=2
Econo Mode: adv=12
Flash Streamer enabled: adv=13.

You'd expect these to be added up to a decimal value when combined, however they are shown as e.g. "adv=2/13" or adv="12/13" when the first and last, resp. last 2 options are enabled together. The FTFZxxN/US also seems to respond to at least the powerful command when set through set_control_info, however I will need to confirm from home since it's hard to fully confirm remotely. As for the hum settings, I found the below values for each mode:
"Zwitsal mode": no API value found, will look further into this.
"Continous mode": shum=CONTINUE
High: shum=50
Med: shum=45
Low: shum=40

I think that the best option is: native integration, second best is the use of the new python framework to create new hardware...

But scripts are also a good option.
a mode selector, a working temperature setpoint and a fanspeed selector is all I want..
for those who want a webpage of some documentaion: https://github.com/ael-code/daikin-control

I will the the new changes later this week and will reply feedback thanks!

Fully agree, I did not know about the existence of the python framework. The reason I worked with LUA instead of Python was that I can use these scripts inside domoticz whereas I need to call external scripts to use python (native python seems to work if you build your own domoticz, but I don't). I use python on a daily basis, should not be too hard to make a Daikin plugin (and an NAD7050 for that matter)!

I looked a bit into the Python framework and for me it is still too much a work in progress, I will stick with the LUA implementation for a while.

From the documentation I deduce that the python framework will become the new native implementation. Good choice, much easier to implement support using python than using C-code (even makes me think why Domoticz is using C at all, would it not be much easier to develop everything in python?).

HI Rob, thanks so much for the updated script, quicker then I'd expected I'll do some testing over the weekend and give you some more feedback. As for your question: "However, I don't understand how I can create a humidity setpoint, anyone with ideas?"

Maybe you should implement this as a selector switch instead of a setpoint. With the display options LOW/MED/HIGH/CONT like on the US-remote, translating to the command values "40","45","50","CONTINUE". E.g. just like you did for the fan speed control.

I have amended the script into 2 new variants to provide the exact same level of control and more as the daikin app, specifically for the R32 ranges Ururu Sarara (FTXZxxN) and Daikin Comfort or Bluevolution (FTXMxxM) variants. Note that for all types of units, I have added flow direction control to the LUA.

We will start with the FTXM25M, which has additional control options for "advanced modes", being the Powerfull- and Econo mode as well as the flash streamer. Note they cannot be combined as discussed earlier (did not know how to do that in LUA, perhaps a real dev can help). For now I can live without the streamer when econo or powerfull is activated. I intend to automate the use of econo (when my car is charging at 11KW) and set powerfull when entering a room where climate was disabled before, e.g. after power off and dT is larger then say 3 degrees C).

First we add a selector switch type dummy device for flow direction control, name it "DaikinFdir" and set the levels als pictured below:

Next we add a selector switch type dummy device for advanced options control, name it "DaikinAdv" and set the appropriate levels:

Now we paste the below script into the event editor (note you need to set LUA script type to "device", or you'll get an eval error line in the log). If you have multiple units like myself, you can add a pretext to the device names, e.g. Office_DaikinMode, Living_DaikinMode etc. and repeat for other units. Use find/replace to amend the scripts accordingly.

And now we will do the same for the Ururu Sarara variants which do not support the advanced modes, but does support humidity control. Let's start again by creating again the selector switch for the airflow direction and call it "DaikinFdir":

And create another selector switch for the humidity modes called "DaikinHumid" (note "Zwitsal Mode" seems not to be supported through the wifi controller):

Now use the event editor to create another LUA script, set script type to device and paste the below code:

Philos31 wrote:Hello all, made a little change to the script so now you can use cooling too.
How it works: Just the same as the old script, but the script now checks: If room temp is lower then the programmed temperature then heat, if room temp is higher then programmed temperature then cool.

Will this work reliably? The typical fear with this implementation is that the unit will cycle between cooling and heating due to the big difference between measured and true temperature (because the sensor is inside the unit). What I think will happen is that the unit will switch from heating to cooling and very soon the sensor will say that it is pretty cold (because it is very close to the cold unit), so it will start heating again. If you use a separate temperature sensor in the room you will still face similar problems (it is hard to perform decent control with a large time delay). I had a similar feature in the past and the main reason I removed it was that I never heat and cool on the same day (for that matter, typically not even in the same month). Maybe the feature is handy for poorly isolated houses. Oh, by the way, why not just use the auto feature of the unit itself?

robhuls wrote:
Will this work reliably? The typical fear with this implementation is that the unit will cycle between cooling and heating due to the big difference between measured and true temperature (because the sensor is inside the unit). What I think will happen is that the unit will switch from heating to cooling and very soon the sensor will say that it is pretty cold (because it is very close to the cold unit), so it will start heating again. If you use a separate temperature sensor in the room you will still face similar problems (it is hard to perform decent control with a large time delay). I had a similar feature in the past and the main reason I removed it was that I never heat and cool on the same day (for that matter, typically not even in the same month). Maybe the feature is handy for poorly isolated houses. Oh, by the way, why not just use the auto feature of the unit itself?

It will set to heat or cool only when starting up the device. So it will not switch from heating to cooling when in operation.
So it looks at the room temperature and your set temp. If the set temp is higher then it will hesat, if the set temp is lower then room temperature it will cool.

But as I said, the bash script is a proof of concept, it is now old and there are better options in the wiki.
Half of Daikin support is even native in domoticz, so we might see a native Daikin support in the future.

RasPi2/KaKu/HUE/Xiaomi/Z-Wave/Nuki/Daikin 3,5kw Ururu Sarara/IR Heating Panels all working together with domoticz

I used your script and it works on DaikinMode when i switch on the selector (auto, cool, Heat) but when i try to switch off the daikin i have an error
"[string "commandArray = {}..."]:34: attempt to concatenate global 'mode' (a nil value)"