New module: DaikinAC

roelb · 26 März 2020, 19:16:24

ZitatUPDATE 2023/2024: This module will not work with the latest generation of Daikin built-in Wifi modules, revision C or later. Those modules will only support cloud-based control as Daikin has removed the local API altogether. There is a solution though. If you have an indoor unit with this latest version of the Wifi module, you can get a compatible Daikin A or B revision wifi adapter and connect this to the S21 or X50 connector on the PCB of your indoor unit. Another option is to get the third-party "Faikin" module (sold om Amazon UK for GBP30) that also connects to this same connector. Either option will give you back the local API.

ZitatUPDATE: As of 21 april 2020, this module is part of the base FHEM distribution and documented in the command reference.

I've written a new module to control Daikin airconditioning units. The HTTPMOD based solution that has been going around on the forum for a few years now was only partially working and it's impossible to get it right using HTTPMOD.

The module I've written is fully functional on all units I've tested it on and allows to set all settings that can be set remotely, including power, operation mode (auto/cool/heat/dehumidify/vent), fan speed, airflow direction (none/vertical/horizontal/3D), as well as setpoint temperature, humidify, special modes such as powerful and streamer mode.

I've also made a Tablet UI template to control the units and a few extra SVG icons.

While I am working on getting this into the base FHEM distribution, you can find the current version attached to this post, as well as a tablet UI template and a couple of icons used in that template (which you'll need to put into your own custom font).

The documentation for the module is included in the .pm file and is part of the command reference

TabletUI

You can use the template that is attached to this post, as follows:

- Copy template_DaikinAC.html into your fhem/www/tablet folder
- Copy daikinac.css and daikinac.woff into your fhem/www/tablet/fonts folder
- Copy widget_scale.js into your fhem/www/tablet/js folder
- Add the following code into the <head> section of your own HTML file:

[tt] <link rel="stylesheet" href="fonts/daikinac.css" />[/tt]

- Add the following code into your HTML file whereever you want to place your control:

[tt]<div data-template="template_DaikinAC.html" data-parameter = '{ "p01": "your_device_name_here" }'></div>
[/tt]

You'll need about 350x160 pixels for this control, so scale the <li> in which you place it accordingly. The updated widget_scale.js is required as I've added a couple of extra parameters to it.

rudolfkoenig · 26 März 2020, 20:11:35

ZitatSo how do I proceed to get this into the base FHEM distribution?

#1. publish your code in the Forum => Done
#2. wait for at least two FHEM-Users for positive feedback
#3. somebody with longer FHEM module-writing experience must take a look at your code. I can take over this part if nobody else is volunteering, and #2 is done.
#4. if #1,#2 and #3 ist done, get an SVN write access, and check in your code. See http://svn.fhem.de for details. The .svg files should be submitted to the icon Maintainer.

roelb · 26 März 2020, 22:55:33

Oke. So I'll suggest the module (and this topic) to the folks that have been active in the other Daikin topics and wait for their feedback. I've renamed it to 58_HVAC_DaikinAC and it is attached to this post.

hugomckinley · 27 März 2020, 14:39:05

Hi,
very nice! I will test it.
Give me e few days.

Hugo

hugomckinley · 31 März 2020, 20:06:47

Hi roelb,
tested it some days with my ACs.
Works well. (I tried all functions excepting streamer and set hum, I don't own an Ururu, I've got an Emura)

Here is my feedback:

slider for values (like interval) -> should be a textfield
powerfull on works, powerfull off doesn't work
state is "Timeout: process terminated" at 4 of 4 ACs after 48 hours (set works, but state doesn't change even; no polling any longer), Daikin App works too
after changing some things (stateFormat and devStateIcon) state changed back to initialized

And my featurerequests:

reading compfreq (polled from get_sensor_info)
reading name (url encoded, as I remember) (at creation, or with update, like the other "static" values, polled from /common/basic_info)
get update button below the set list
readings for the used energy (hour/day/week/year), don't remember what is logged in the indoor units
"set reboot" to reboot the WiFi Adapter, has never been used, but who knows

Question: Should I translate the commandref entry to german?

Here are some log entries:

Code Auswählen

2020.03.28 19:28:55 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 19:29:02 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.

2020.03.28 20:46:12 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 64298) line 1.

2020.03.28 21:05:13 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:05:54 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:06:13 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:06:45 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:07:12 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:07:30 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:07:38 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:08:15 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:08:40 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:09:21 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:09:43 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:10:18 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:10:29 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:10:47 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:11:29 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:12:00 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:12:15 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:12:28 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:12:40 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:12:52 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:13:00 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:13:31 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:13:40 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:13:54 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.
2020.03.28 21:14:18 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:15:20 1: PERL WARNING: Use of uninitialized value $adv in split at ./FHEM/58_HVAC_DaikinAC.pm line 209.
2020.03.28 21:15:37 1: PERL WARNING: Use of uninitialized value $adv in sprintf at ./FHEM/58_HVAC_DaikinAC.pm line 220.

- next day:(no interaction)

2020.03.29 09:40:54 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/58_HVAC_DaikinAC.pm line 659.
2020.03.29 09:40:54 2: AC_SZ_DG HVAC_DaikinAC_Poll(): failed () - Timeout: process terminated
2020.03.29 09:43:32 2: AC_KZ_OG HVAC_DaikinAC_Poll(): failed () - Timeout: process terminated
2020.03.29 09:45:49 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/58_HVAC_DaikinAC.pm line 478.
2020.03.29 21:53:59 2: AC_KZ_DG HVAC_DaikinAC_Poll(): failed () - Timeout: process terminated

The next week(s) I will rework my script to use your module control my ACs automatically, before the summer arrives in Austria.

Good work!

Hugo

roelb · 31 März 2020, 22:50:39

Zitat von: hugomckinley am 31 März 2020, 20:06:47
Works well. (I tried all functions excepting streamer and set hum, I don't own an Ururu, I've got an Emura)

I've got one unit that has the streamer function and that works. Haven't got an Urura either, so the humidity functionality is completely untested.

Zitat
slider for values (like interval) -> should be a textfield
powerfull on works, powerfull off doesn't work
state is "Timeout: process terminated" at 4 of 4 ACs after 48 hours (set works, but state doesn't change even; no polling any longer), Daikin App works too

Done and fixed. I've done some sniffing on traffic from the Daikin app to my units here and got powerful mode to work as it should. I've noticed the timeout issue. It seems that my choice of rescheduling the call to my poll() function (using the blocking.pm lib) immediately after the SetBlocking() call is incorrect and can cause a race condition. I've moved the reschedule over to both finish/abort functions and can't get it to fail anymore.

Zitat
And my featurerequests:

reading compfreq (polled from get_sensor_info)
reading name (url encoded, as I remember) (at creation, or with update, like the other "static" values, polled from /common/basic_info)
get update button below the set list
readings for the used energy (hour/day/week/year), don't remember what is logged in the indoor units
"set reboot" to reboot the WiFi Adapter, has never been used, but who knows

"compfreq" is added. Useful indeed, but I didn't know what it represented until I just googled it and found it to be the current compressor frequency. Both "name" and the usage statistics are added as well. The same is true for the reboot option.

As for the "get update" button, I've been looking at how to do that, but unfortunately the documentation on module development is quite lacking on that front

. So any suggestion on how to accomplish that are welcome.

I'm currently looking at parsing the usage statistics into useful readings. I'm not entirely sure (yet) what the ordering in the weekly usage statistics is, as the get_week_power_ex and get_week_power output doesn't match up. So I've gathered todays output and will do that again tomorrow.

For now, an updated version is attached.[/list]

hugomckinley · 01 April 2020, 01:09:51

I can't set anything any longer (power, mode, rate, ...)
Only the readings hhum, htemp and otemp are updated if I set something, but nothing else happens.
I just copied the modul, set the correct rights an restarted fhem.

This is in the log, when I restart FHEM:

Code Auswählen

2020.04.01 00:51:23 1: PERL WARNING: "my" variable $s masks earlier declaration in same scope at ./FHEM/58_HVAC_DaikinAC.pm line 178, <$fh> line 3741.

get update generates an empty popup window with an O.K. button

There is no compfreq reading, but in the polled rawdata there is compfreq

roelb · 01 April 2020, 10:34:24

Sorry.. Late night changes

. I noticed that today. Fixed and attached file has been updated in my previous post.

hugomckinley · 01 April 2020, 11:46:01

Looks good!

but the cmpfreq reading is still not available

Tip for the docu -> a nice state visualisation:

Code Auswählen

attr <device> stateFormat 1:pow
<br>In: htemp °C <br>Out: otemp °C

Code Auswählen

attr <device> devStateIcon 1.0.*:frost@gray 1.1.*:frost@blue
Important: the new line after 1:pow

roelb · 01 April 2020, 11:49:45

- we were typing at the same time, see below -

As for compressor frequency, I just used "compfreq" as stated in your post, but did not check whether that worked. It turns out the actual parameter name is "cmpfreq", without the o. That has now been changed as well.

The "get update" should probably be "set update", as nothing is returned perse, but it does trigger an action. So I've changed that as well.

v1.0.4 is attached with these two changes. I'll have a look at the usage/wattage statistics later today. Any preference on how these should be exposed / parsed into readings?

hugomckinley · 01 April 2020, 13:18:20

Oups, sorry for the typo!

Looks good. Now I recode my controllscript for my ACs to use your module.

Suggestion for the powerconsumption readings:
* 0:00 - 24:00 of the last day and current day
* mo - sun last week and current week
* january - december last year and current year

so we could see the actual (and running/incomplete) values in relation to the last period of the same time range

roelb · 03 April 2020, 17:23:40

I've added the power usage statistics and cleaned up a few other things.

Changelog:

- stateFormat is now automatically generated upon creation, a bit more extensive than your example (different icons for different modes).
- two distinct poll intervals, one when the unit is powered off, another for when the unit is powered on. First interval defaults to 60 seconds, second interval to 10 seconds.
- Added the option to set shum with an offset, just as stemp
- shum must now be a multiple of 5 (the unit won't accept another value, at least not the ones that I've tested it on)
- Bugfix that caused polling to stop if the unit could not be reached or returned invalid values
- Renamed "set update" to "set refresh". "set update" still works though but is no longer documented
- added attribute "pwrconsumption" (0 or 1). If 1, power consumption data is gathered and returned in several new readings, in kWh.
- fixed mompow to be always 0 when the unit is powered off, and divided by 10 to represent kW when turned on
- added cmpfreq_max and mompow_max readings that keep track of maximum value seen for those. Can be used to display a dial or vu-meter representing relative power/frequency.
- added htemp_ifchanged, hhum_ifchanged and otemp_ifchanged readings. Copy of htemp,hhum and otemp, but only updated on change so that they can be used for logging purposes.
- documentation update to reflect above changes.

Please have a look at it and let me know if you notice any issues or see any errors in the log.

hugomckinley · 03 April 2020, 20:23:59

- In my opinion the intervals are much too short (why should I know the values every 10 seconds? Temperature is very sluggish.) I will use 300 sec when on and 600 seconds when off. But I think one interval would be enough.

- I don't understand the _ifchanged readings. Isn't it the same as the event-on-change-reading attribute?

- Note: With my Emura, the htemp reading always seems to be correct.

- No errors in the log entries.

-I don't have the reading mompow. (doesn't matter if the unit is on or off)
I think the reason is, that the model_info says: en_mompow=0 and I think this is enable_mompow, so my unit isn't able to send this value

Here are my raw Values:

basic_info:

Code Auswählen

ret=OK,type=aircon,reg=eu,dst=1,ver=1_2_51,rev=D3A0C9F,pow=0,err=0,location=0,name=%57%6f%68%6e%7a%69%6d%6d%65%72,icon=1,method=home only,port=30050,id=,pw=,lpw_flag=0,adp_kind=3,pv=3.20,cpv=3,cpv_minor=20,led=0,en_setzone=1,mac=DCF5054E1675,adp_mode=run,en_hol=0,grp_name=%4f%47,en_grp=1

control_info:

Code Auswählen

ret=OK,pow=0,mode=3,adv=,stemp=23.0,shum=0,dt1=25.0,dt2=M,dt3=23.0,dt4=25.0,dt5=25.0,dt7=25.0,dh1=AUTO,dh2=50,dh3=0,dh4=0,dh5=0,dh7=AUTO,dhh=50,b_mode=3,b_stemp=23.0,b_shum=0,alert=255,f_rate=A,f_dir=0,b_f_rate=A,b_f_dir=0,dfr1=5,dfr2=5,dfr3=A,dfr4=A,dfr5=A,dfr6=A,dfr7=5,dfrh=5,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0,dmnd_run=0,en_demand=0

model_info:

Code Auswählen

ret=OK,model=0D75,type=N,pv=3.20,cpv=3,cpv_minor=20,mid=NA,humd=0,s_humd=0,acled=0,land=0,elec=1,temp=1,temp_rng=0,m_dtct=1,ac_dst=--,disp_dry=0,dmnd=1,en_scdltmr=1,en_frate=1,en_fdir=1,s_fdir=3,en_rtemp_a=0,en_spmode=3,en_ipw_sep=1,en_mompow=0,hmlmt_l=10.0

sensor_info:

Code Auswählen

ret=OK,htemp=25.0,hhum=-,otemp=11.0,err=0,cmpfreq=0

hugomckinley · 04 April 2020, 10:52:06

I defined the AC at about 19:40 and later this flooded may log:

Code Auswählen

2020.04.04 02:00:11 1: PERL WARNING: Exiting subroutine via last at ./FHEM/58_HVAC_DaikinAC.pm line 824.
Label not found for "last PWR" at ./FHEM/58_HVAC_DaikinAC.pm line 824.
2020.04.04 02:00:11 2: AC_WZ_OG HVAC_DaikinAC_Poll(): failed (HVAC_DaikinAC_Poll) - Timeout while attempting to poll 192.168.64.5 (Process died prematurely)
2020.04.04 02:01:14 1: PERL WARNING: Exiting subroutine via last at ./FHEM/58_HVAC_DaikinAC.pm line 824.
Label not found for "last PWR" at ./FHEM/58_HVAC_DaikinAC.pm line 824.
2020.04.04 02:01:15 2: AC_WZ_OG HVAC_DaikinAC_Poll(): failed (HVAC_DaikinAC_Poll) - Timeout while attempting to poll 192.168.64.5 (Process died prematurely)
2020.04.04 02:02:18 1: PERL WARNING: Exiting subroutine via last at ./FHEM/58_HVAC_DaikinAC.pm line 824.
Label not found for "last PWR" at ./FHEM/58_HVAC_DaikinAC.pm line 824.
2020.04.04 02:02:22 2: AC_WZ_OG HVAC_DaikinAC_Poll(): failed (HVAC_DaikinAC_Poll) - Timeout while attempting to poll 192.168.64.5 (Process died prematurely)
2020.04.04 02:03:23 1: PERL WARNING: Exiting subroutine via last at ./FHEM/58_HVAC_DaikinAC.pm line 824.
Label not found for "last PWR" at ./FHEM/58_HVAC_DaikinAC.pm line 824.
2020.04.04 02:03:27 2: AC_WZ_OG HVAC_DaikinAC_Poll(): failed (HVAC_DaikinAC_Poll) - Timeout while attempting to poll 192.168.64.5 (Process died prematurely)
2020.04.04 02:04:28 1: PERL WARNING: Exiting subroutine via last at ./FHEM/58_HVAC_DaikinAC.pm line 824.
Label not found for "last PWR" at ./FHEM/58_HVAC_DaikinAC.pm line 824.
2020.04.04 02:04:32 2: AC_WZ_OG HVAC_DaikinAC_Poll(): failed (HVAC_DaikinAC_Poll) - Timeout while attempting to poll 192.168.64.5 (Process died prematurely)

btw: set works, but no polling any longer

roelb · 04 April 2020, 11:13:28

Got it, had the same issue this morning. I initially created the power reading in a perl block, but split that into a function. I changed all the "last" statements into returns, but seem to have forgotten one.

Fixed version is attached. Just reload in place and everything should continue.

As for your remarks:

- seperate htemp and htemp_ifchanged:

There is a use case for both. For logging purposes, you only need changed values. However, if the temperature is to be displayed on an interactive controller / thermostat, you need to know whether the value that you display is current. The module will only update all other readings only if they have changed, so there is no need to force all readings to event-on-change. That way, a front-end can check whether the current temperature is current. If not, it can be grayed out, for example if the unit is offline and can not be polled or if it does no longer return a temperature (my older multisplit only returns otemp if it's turned on for example).

- I'll update the documentation with your findings for the Emura and my findings for the different units I've got here (5 different indoor units in two systems, one multisplit and one singlesplit).

- As for the interval, it all depends on your use case. I'm controlling these units on multiple TabletUI driven wall mounted tablets. But they can also be controlled through their infrared remotes and/or switched on or off with their internal timers. So I need their status to be correctly reflected within an acceptable timeframe, so that the status in FHEM corresponds to what the unit is actually doing. A minute is a reasonable interval whenever FHEM thinks the unit is off. That means that I'll still have pretty accurate temperature readings, and FHEM will know if a unit has been turned through timer or remote within a minute of that actually happening. That is acceptable from a user interface perspective. The load on FHEM with a 1-minute interval is very low, the 2 or 3 (with power monitoring) HTTP requests are short and generate very little data.

If the unit is turned on, there are readings that can change often, other than the temperature readings. The cmpfreq and mompow readings reflect the current compressor frequency and power usage. I've been observing those on my units, and they seem to change at most once per 10 seconds, so 10 seconds seems to be the goldylocks timeframe to poll them. And if you are displaying these values on a controller display, you need up-to-date readings, so that the displayed value actually makes sense. 10 seconds is an interval that gives people reasonably intuitive feedback as well, but still does not cause much load. For example, I've integrated a level meter in my TabletUI control that displays the current compressor frequency. But there is no issue in changing these into a larger value if you're use case is different.

Roel.