FHEM Forum

FHEM => English Corner => Thema gestartet von: roelb am 26 März 2020, 19:16:24

Titel: New module: DaikinAC
Beitrag von: roelb am 26 März 2020, 19:16:24
Zitat
UPDATE: 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 (https://fhem.de/commandref.html#HVAC_DaikinAC)

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:

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

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

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


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.
Titel: Antw:New module: DaikinAC
Beitrag von: rudolfkoenig am 26 März 2020, 20:11:35
Zitat
So 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.
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 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.
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 27 März 2020, 14:39:05
Hi,
very nice! I will test it.
Give me e few days.

Hugo
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 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:

And my featurerequests: ;-)

Question: Should I translate the commandref entry to german?

Here are some log entries:


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
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 31 März 2020, 22:50:39
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]
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 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:
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

Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 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.
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 01 April 2020, 11:46:01
Looks good!

but the cmpfreq reading is still not available :-(

Tip for the docu -> a nice state visualisation:
attr <device> stateFormat 1:pow
<br>In: htemp °C <br>Out: otemp °C
attr <device> devStateIcon 1.0.*:frost@gray 1.1.*:frost@blueImportant: the new line after 1:pow

Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 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?
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 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
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 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.
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 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:
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:
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:
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:
ret=OK,htemp=25.0,hhum=-,otemp=11.0,err=0,cmpfreq=0
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 04 April 2020, 10:52:06
I defined the AC at about 19:40 and later this flooded may log:

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
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 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.
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 04 April 2020, 13:36:37
Thank you for the new version!

My solution would be the "normal" behavior of other FHEM modules. As I have seen they update the readings at the defined interval unless you specify the event-on-* attributes.
You can also force actual readings with event-min-interval.
If you want to know, if the readings are current, you could introduce a last-successful-poll reading (could also be enabled/disabled with an attribute) or use the timestamp of the readings. And as you have written, otemp should not be used for other things so it doesn't matter if it is not correct. I'm sure you have another thermosensor for the outdoor temperature to visualize ;-)
But I'm not a developer, so I think it would be good if a experienced FHEM developer would say a few words, what would be the usual method how to solve this tasks. I think it's not a question of right or wrong, but of what is usual.

I agree with you, that the usecases are very different, but I still think 10sec are not the usual case. If you keep the update strategy of only updateing if values are changed, it would not generate events in the log, but if not that would be too much entries in the filelog/dblog. But if it is documented users can decide their intervals correctly. I am a friend of slim databases and of not doing things that are not necessary ;-)
My usecase is: All indoor units are under full control of FHEM. Nobody touch any button. So 5 minutes are enough for me. I dont need to know everything I can ;-)
I would suggest to generate the attributes for the intervals when the device is defined, so the user can see the values imediately in the device.

Hugo
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 04 April 2020, 14:17:40
My solution would be the "normal" behavior of other FHEM modules.

It's up to the module to decide what to do and the API provides functionality to update either a single reading, or all. I would qualify updating readings with the same value each time over, where that has no sensible meaning, to be just bad programming. And that is true the other way around as well.

This module now provides these three readings both ways. Simply use what fits your use case. It's all documented. The "event-on-change" attribute is a workaround that, IMHO, should not be neccessary except for exceptional cases.

Zitat
If you want to know, if the readings are current, you could introduce a last-successful-poll reading

There is already an internal LASTUPDATE var exposed. And every reading has it's own timestamp which serves that purpose perfectly. those timestamps are there for a reason. The three readings that are updated on each poll, even if unchanged, represent spot measurements valid at a single point in time, but are independent from each other, so keeping a single "last updated" state for that would not make sense. For all other readings, updating them unchanged would not make sense either.

Zitat
I agree with you, that the usecases are very different, but I still think 10sec are not the usual case.

The internal timer in the Daikin units for the cmpfreq and mompow values seems to be 10 seconds, so 10 seconds makes perfect sense if you are graphing or displaying those interactively. If not, just increase the interval. I guess most FHEM users use some form of interactive visulization (Tablet UI for most), so a short feedback loop makes sense when the unit is running. The demo tablet-UI control features a scale that visualizes the current compressor frequency - see attachment.

But as mentioned above, if it does not make sense in your use case, just adjust the intervals, it's a simple parameter.

Zitat
it would not generate events in the log, but if not that would be too much entries in the filelog/dblog. But if it is documented users can decide their intervals correctly. I am a friend of slim databases and of not doing things that are not necessary ;-)

And that is exactly why, except for three documented spot vars, all others are only updated on change. The documentation provides a section on logging with a clear warning on blanket logging and includes an example FileLog configuration:

define <devicename>_LOG FileLog <filename> <devicename>:(pwr.*_last|pwr_year_cur|power|pow|cmpfreq|mompow|stemp|shum|mode|rate|swing|powerful|streamer|econo|.*_ifchanged:.*

Zitat
I would suggest to generate the attributes for the intervals when the device is defined, so the user can see the values imediately in the device.

Sure, that's not an issue. They are visible in the FHEM webinterface though as internals if not overridden by an attribute. But I'll generate those two attributes on default at define time in the next version.
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 04 April 2020, 14:35:44
So we can both agree, that every use case should be covered :-)

I continue testing ...

Hugo
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 04 April 2020, 17:16:17
Yep ;-). And thanks, if you see anything out of the ordinary, please let me know.
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 04 April 2020, 18:42:24
You should delete all old versions of the module in this thread and attach the latest version to the first post.
So there is no risk of downloading a old release even without reading all answers.

Is there somebody else who is testing this module?
Titel: Antw:New module: DaikinAC
Beitrag von: hugomckinley am 05 April 2020, 20:02:37
A minor bug is still there:

Sometimes I get timeouts even with a attr timeout=10
2020.04.05 18:18:22 2: AC_WZ_OG HVAC_DaikinAC_Poll(): failed (HVAC_DaikinAC_Poll) - Timeout while attempting to poll 192.168.64.5 (Timeout: process terminated)
I think the problem is not the value of the timeout, but the unit doesn't answer at all.

Is it possible to make a second try before logging this error?
Titel: Antw:New module: DaikinAC
Beitrag von: markusphi am 05 April 2020, 22:44:35
ich habe das Modul Heute getestet und es funktioniert sehr gut!
Danke!
Titel: Antw:New module: DaikinAC
Beitrag von: markusphi am 06 April 2020, 13:43:39
PERL WARNING: Argument "interval=180" isn't numeric in int at ./FHEM/58_HVAC_DaikinAC.pm line 110.
2020.04.05 22:39:40 3: AC_s_WZ: internal interval timer stopped

180 <> numeric?
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 06 April 2020, 17:16:33
PERL WARNING: Argument "interval=180" isn't numeric in int at ./FHEM/58_HVAC_DaikinAC.pm line 110.
2020.04.05 22:39:40 3: AC_s_WZ: internal interval timer stopped

180 <> numeric?

I think you are specifying the text "interval=180" instead of just 180. That might be a misunderstanding of the usage prompt that you're getting.

Syntax: define <name> HVAC_DaikinAC <hostname/ip> [interval=60] [interval_powered=10]

What is meant here is that you can specify two optional parameters, "interval" and "interval_powered", with default values 60 and 10. So if you want to use 300 for the interval when the unit is off, and 120 when the unit is on, you define the device using:

define MY_DEVICE_NAME HVAC_DaikinAC 1.2.3.4 300 120

I'll update the usage error and documentation with a couple of examples to clarify this.
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 06 April 2020, 17:21:15
I think the problem is not the value of the timeout, but the unit doesn't answer at all.

Is it possible to make a second try before logging this error?

Sure, I could add a "retries" parameter for this purpose, default value of 2. I haven't seen this on my units so far, they always respond as long as the network is up. Might be a wifi issue. Anyway, I'll add an automatic retry.
Titel: Antw:New module: DaikinAC
Beitrag von: markusphi am 06 April 2020, 17:22:10
I'll update the usage error and documentation with a couple of examples to clarify this.

ok, thank you! (sorry my english ist not so good)
Titel: Antw:New module: DaikinAC
Beitrag von: Slanesh am 10 April 2020, 00:39:19
Just installed the module and it worked in less than 2 minutes. Great job @roelb!
Titel: Antw:New module: DaikinAC
Beitrag von: gadget am 11 April 2020, 10:07:35
Just stumbled across this module. Got a Multisplit Daikin Stylish FTXA installed lately. Will try it and report back soon. Thanks for all your effort.

Edit: First quick test looks very promising.
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 11 April 2020, 20:37:23
Thanks guys. I'll start the work on getting this into the base FHEM distribution.

I did fix one minor issue, which causes the monthly and daily power usage statistics to not be updated in time. They are now updated once every hour (if changed), so that the readings always reflect the most up-to-date power usage statistics.

This version (1.0.7) is attached to this post. I have also attached this version to the opening post, as well as the tablet UI template and a copy of the documentation.
Titel: Antw:New module: DaikinAC
Beitrag von: hubiuwe am 18 April 2020, 20:31:38
Hallo roleb!
I tested the module with two FTXP20M on multi split.  ;D
It work's good for me!
(Stream and shum is not supported)

Gruß Uwe
Titel: Antw:New module: DaikinAC
Beitrag von: Kasi13 am 26 April 2020, 09:04:22
Works perfectly with my FTXA, great addition to FHEM, Thank you roelb for your work!
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 27 April 2020, 11:50:18
You're welcome. Module is now part of the base FHEM distribution. Thank you all for testing!
Titel: Antw:New module: DaikinAC
Beitrag von: steffen83 am 18 Mai 2020, 08:35:47
Hello, I was a quiet reader, because my Daikin system was still in the ordering and assembly process. I have now installed the module and could not find any errors yet.
I think it's really great how it works. I'm still working on FTUI myself, so the question is whether someone already has a similar overview and control over reading groups etc.?
And is there a way to control the Daikin over my amazon alexa?
BR
Steffen
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 18 Mai 2020, 10:29:10
Thanks for the feedback!

As for TabletUI, I have already created a full template, which has always been included in the opening post to this thread. So no need to figure that our yourself..

I have now updated the original post to include a full manual on how to integrate that control template into your own FTUI design. I've also added a custom icon font for the four SVG's so you do not have to generate that yourself. The HTML template has been modified to use these new icon names, so please download that again if you've already done so in the past.
Titel: Antw:New module: DaikinAC
Beitrag von: fhemming am 26 Mai 2020, 12:44:56
Great module, works perfectly with Split FVXM35FV1B (BRP069B41). Big thanks! :)

Any chance to set up the device to interact with Alexa? I have the Alexa module successfully installed and can control other devices easily just by adding the alexaName attribute. This is not working for for the Daikin AC. I added the alexaName attribute and restarted the alexa module, but the device is not being listed when running:
list alexaName=..*
Following the troubleshooting wiki for the Alexa module https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa) it's not clear to me what's exactly missing or needs to be adjusted. Has anyone implemented it and has some guidance to share?

Thanks a ton!
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 26 Mai 2020, 16:19:06
I don't have an Alexa and can not easily test this. A quick scan of the Alexa modules wiki page though seems to indicate that the Alexa module expects a device to have a "set on" and "set off" command. The Daikin module currently has no such commands, you will need to specify the full "set power on" and "set power off" commands to turn it on and off.

You might get away with a simple EventMap to fix this:

attr <your daikin device> eventMap { usr=>{ 'on'=>'power on', 'off'=>'power off'}}

If not, try the patch that I've attached to add these commands to the module. If that works, please let me know and I'll commit those into the main branch.

The wiki page seems to be a work in progress, as there is no information on what the module expects a thermostat or other HVAC type-device to expose in terms of readings and commands to control the setpoint.

The author of the Alexa module might be in a better position to help on that and give pointers as to what must be done to make this fully compatible. I'd be more than happy to add something to make it work out of the box, but I would appreciate some pointers on what we need to make this compatible.
Titel: Antw:New module: DaikinAC
Beitrag von: steffen83 am 27 Mai 2020, 11:39:45
Hello roelb,

can you send the complete "58_HVAC_DaikinAC.pm" files?
Then i can replace and test it.

BR
Steffen
Titel: Antw:New module: DaikinAC
Beitrag von: fhemming am 28 Mai 2020, 20:02:34
Thanks, roelb!
Adding an EventMap worked perfectly, powering on and off the device with Alexa is now possible :)
I never tried out the patch you attached, but if you add support to the module I'd be happy to do some testing.
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 28 Mai 2020, 21:45:54
I've just committed version 1.0.9 which contains a shortcut on and off command into the main repository. So if you update FHEM you should have the new version, no more need for an Eventmap
Titel: Antw:New module: DaikinAC
Beitrag von: fhemming am 29 Mai 2020, 10:50:28
Confirming that it's working now without an EventMap :)
Thank you once again for your efforts here, roelb!
Titel: Antw:New module: DaikinAC
Beitrag von: steffen83 am 29 Mai 2020, 10:54:31
Hello fhemming,

can you show me via "list" your clima-device with the amazon alexa configuration?

i have the same problem. But i can use it only as an thermostat.

BR
Steffen
Titel: Antw:New module: DaikinAC
Beitrag von: fhemming am 29 Mai 2020, 11:16:10
Sure, as everything is default, I guess you're interested in the Attributes section.
I just added the required attribute "alexaName" (no more EventMap) and restarted the alexa module (and if required re-run device discovery within Alexa):

Attributes:
   alexaName  Klima
   devStateIcon off.*:control_standby@gray on.*cool:frost@blue on.*heat:sani_heating@red on.*dehumidify:humidity@blue on.*vent:vent_ventilation@green on.*auto:temp_temperature@red
   icon       weather_frost
   interval   60
   interval_powered 10
   stateFormat power/mode
<br>In: htemp &degC <br>Out: otemp &degC

I'm just using Alexa for turning the device on and off. Not sure if any other command is possible yet, I haven't tried.

Is your problem that you cannot even switch the device on/off?
Titel: Antw:New module: DaikinAC
Beitrag von: raimundl am 29 Mai 2020, 20:37:32
Thanks for the great module.
Worked immediately and concern.
The AC can be switched on/off via Alexa.

Thank you and best regards

Raimundl
Titel: Antw:New module: DaikinAC
Beitrag von: realkev am 30 Mai 2020, 08:54:28
Good morning,

I am using this module with an FTXC-B35 and it works quite good. I seems that cmpfreq cmpfreq_max aren't supported as they are both showing the value 999.
What I noticed is the following log entry:

Klima_Schlafzimmer HVAC_DaikinAC_PollDone(): Invalid response on get_control_info: Server closed connection without sending any data back at /usr/share/perl5/Net/HTTP/Methods.pm line 391.
It occurs every 30 minutes during operation.

Poll intervals are

interval 180
interval_powered 10

Anyone other getting this entry?

Best regards,
Kev
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 30 Mai 2020, 10:36:49
The error message that you are getting seems clear: the airco unit closes the HTTP connection but did not sent any data. So the module got an empty response where it was expecting status data. That is not a big issue, if a failure happens on a poll you'll just miss one interval. For a set, the set will fail and you'll need to retry.

What you're seeing is definitely an issue in the Daikin wifi control unit. I haven't seen that issue.  You might try doing a couple of manual requests to the control interface and see if you can replicate that.

I've been thinking about implementing an automatic immediate retry whenever the request to the unit fails. However, that is a bit more complex than it seems due the asynchronous nature of the requests to the unit, using nonblocking IO. So an automatic retry will require some architectural changes in the module. It's on the todo list, so whenever I can find the time to rework this into the module, I will.
Titel: Antw:New module: DaikinAC
Beitrag von: wulfmain am 11 Juni 2020, 23:54:57
Works perfect. Thank you so much! I really appreciate your Great work!
Titel: Antw:New module: DaikinAC
Beitrag von: realkev am 14 Juni 2020, 11:22:12
The error message that you are getting seems clear: the airco unit closes the HTTP connection but did not sent any data. So the module got an empty response where it was expecting status data. That is not a big issue, if a failure happens on a poll you'll just miss one interval. For a set, the set will fail and you'll need to retry.

What you're seeing is definitely an issue in the Daikin wifi control unit. I haven't seen that issue.  You might try doing a couple of manual requests to the control interface and see if you can replicate that.

I've been thinking about implementing an automatic immediate retry whenever the request to the unit fails. However, that is a bit more complex than it seems due the asynchronous nature of the requests to the unit, using nonblocking IO. So an automatic retry will require some architectural changes in the module. It's on the todo list, so whenever I can find the time to rework this into the module, I will.

Hi Roelb,

thanks for your feedback, the empty responses weren't causing a significant issue within my system, nevertheless I am facing some other problems with the module at the moment:

2020.06.14 05:48:47 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 8504
2020.06.14 05:48:47 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 8503
2020.06.14 05:48:47 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 8502
2020.06.14 05:25:52 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 7597
2020.06.14 05:25:52 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 7596
2020.06.14 05:25:52 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 7595
2020.06.14 05:02:51 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 6685
2020.06.14 05:02:51 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 6684
2020.06.14 05:02:51 1: Timeout for HVAC_DaikinAC_Write reached, terminated process 6683

Is there any maximum of commands being defined in certain period of time?
I am using a DOIF to regulate the temperature in a room by controlling the AC...

Best regards,
Kevin
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 14 Juni 2020, 11:35:33
This might be a concurrency issue. As my module uses the FHEM nonblocking features for all requests, firing multiple requests at the same time (through some form of automation) will fork any number of processes that in turn perform the actual request to the aircon unit.

Daikin uses a AzureWave AW-CU300 integrated module for their Wifi controllers. This contains a Marvell 88MW300 microprocessor. I don't know what they have implemented in terms of handling concurrent requests. However, I can't get any of their units to fail in my own installation, whatever number of requests I fire at them.

Try adding 100ms of sleep in between your automated requests. If you have multiple Doif's that trigger on the same event, try adding different short delays to each of them so that they don't fire at /exactly/ the same time.
Titel: Antw:New module: DaikinAC
Beitrag von: Hippo am 11 Juli 2020, 12:38:23
Hi roelb,

Great work! Thank you very much. It works perfect.
I am using a DOIF to change stemp, mode... I have to set the wait Timer to 1 Second, then it works well with my Daikin Stylish.

The Daikin Stylish have 2 more Options:
The "Intelligent Eye" and "Comfort Airflow"

Are there any readings/settings?

Best regards, Hippo
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 11 Juli 2020, 14:21:31
As far as I know, these can not be set through the Wifi API. Just to make sure: are those functions available in the official Daikin controller app?
Titel: Antw:New module: DaikinAC
Beitrag von: Hippo am 11 Juli 2020, 15:02:53
No, only with the IR Remote. :-\
Titel: Antw:New module: DaikinAC
Beitrag von: shamal2008 am 23 Juli 2020, 17:29:22
Hi,

I just got my Daikin Stylish and tried to implement the Splits - what should I say - it works from the first moment. Now let's make the deep dive!

Thank you for this real great module - I'm happy and glad and can now try out some doif's and so on.

Thanks again,
Thomas from Vienna;

PS: my daikin just upgraded the firmware to 1.2.51 from 1.2.48 - works also!
Titel: Antw:New module: DaikinAC
Beitrag von: shamal2008 am 29 September 2020, 21:58:37
Hi Roelb,

do you have any idea how I can integrate the Daikin in gassistant (google-home) ? - It shows in the google-home app, but i can only turn it on or off.

For more details:
https://forum.fhem.de/index.php/topic,114428.0.html

PS: I got email from Daikin, the Daikin Residential App ("the new one") will support the Daikin Stylish in the new version, which should be released this year.

greetings,
Shamal2008
Titel: Antw:New module: DaikinAC
Beitrag von: m2th3o am 18 November 2020, 17:56:44
Great Module!!

Since I wanted to have it working with Alexa and there was already some discussion about it I would like to share my solution:

1. step: dummy with very limited attributes

Internals:
   CFGFN     
   FUUID      XXX
   NAME       WG_Heizung
   NR         9139
   STATE      off
   TYPE       dummy
   READINGS:
     2020-11-18 17:50:20   pct             24
     2020-11-18 17:51:24   state           off
Attributes:
   alexaName  Heizung
   genericDeviceType light
   readingList pct
   room       Wintergarten
   setList    pct:on,off

2. step: notify which fwds some commands when the dummy changes

WG_Heizung {my $Solltemperatur = ReadingsVal("WG_Heizung","pct","--");
if (Value("WG_Heizung") eq "on") {fhem("set WG_Klimaanlage stemp " .$Solltemperatur);}
if ((Value("WG_Heizung") eq "on") && (ReadingsVal("WG_Klimaanlage","state","--") eq "off")) {fhem("set WG_Klimaanlage on");}
else {if (Value("WG_Heizung") eq "off") {fhem("set WG_Klimaanlage off");}}}

For Alexa it behaves like a light with pct. But you can even say "Put Heizung on 24 degree".

Best regards
Markus
Titel: Antw:New module: DaikinAC
Beitrag von: erwin am 13 Dezember 2020, 19:52:46
Great Module!

very good job done!!!
one tiny thing is on my whishlist:
from time to time the AC's loose there WLAN conn. for 5 to 30 Mins, but somehow recover ......
During that time, the log shows a number of error entries from LWP/Protocol/... and other modules.

Proposed idea: do a ping on enter of the blocking routine, if that fails, it makes no sense to continue....
Invalid response for /common/get_datetime: Can't connect to 192.168.10.14:80

No route to host at /usr/share/perl5/LWP/Protocol/http.pm line 49.

2020.12.03 23:47:10.427 2: AC_Schlafzimmer HVAC_DaikinAC_Poll(): failed (HVAC_DaikinAC_Poll) - Timeout while attempting to poll 192.168.10.14 (Timeout: pro

Thanks erwin   
Titel: Antw:New module: DaikinAC
Beitrag von: pdp1173 am 28 Dezember 2020, 12:17:10
....
2. step: notify which fwds some commands when the dummy changes

WG_Heizung {my $Solltemperatur = ReadingsVal("WG_Heizung","pct","--");
if (Value("WG_Heizung") eq "on") {fhem("set WG_Klimaanlage stemp " .$Solltemperatur);}
if ((Value("WG_Heizung") eq "on") && (ReadingsVal("WG_Klimaanlage","state","--") eq "off")) {fhem("set WG_Klimaanlage on");}
else {if (Value("WG_Heizung") eq "off") {fhem("set WG_Klimaanlage off");}}}


Hi Markus,

sorry , my first post here.
Can you please give a newcomer a hint, how and where step 2 is to be implemented.
I have defined a device "DaikinStube" with characteristics from step 1. It works!
But my

define DaikinStube notify { <data from Step 2>  } 

does not work. There is very little examples around how to use Perl Coding
inside a notify statement.

Thank you for your help.
Gino
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 11 Januar 2021, 22:35:11
Hi Roelb,

do you have any idea how I can integrate the Daikin in gassistant (google-home) ? - It shows in the google-home app, but i can only turn it on or off.

Sorry for the late response. Must have missed the notification, and have been very busy on other work for the last months.

As for your question: no, I have not looked at Google Assistent integration in depth. I do use the current module myself to turn the aircons on and off, but no more. The Google Assistent module documentation unfortunately is almost nonexistant and it's code, both FHEM module and corresponding daemon, is completely undocumented as well. I did have had a peek in there for other integrations about a year ago, but quickly abandonded that due the the lack of documentation and messy code.

If you did manage to get it to work, please share! And if you require any changes in the Daikin module to get the integration to work, just ask.. I'm more than happy to extend the Daikin module with some extra commands or readings if that is neccessary.
Titel: Antw:New module: DaikinAC
Beitrag von: MikeR am 18 Mai 2021, 22:13:09
Hello,

a few days ago i got my new Daikin Multisplit System installed. Today i tried this model for fhem and it works like a charm. Perfect.
Congratulations, superb job.

One thing: the two readings "mompow" and "mompow_max" didn't appear in my module. I have the indoor unit Stylish (aka: FTXA) with build in wifi adapter. I have activated the "pwrconsumption" attribute.

Any idea?

Greetings from Germany
Mike
Titel: Antw:New module: DaikinAC
Beitrag von: roelb am 18 Mai 2021, 23:10:59
Your unit probably does not provide the data.

You could try a manual request to http://<airco ip>/aircon/get_sensor_info while it's running.

That should return something like  "ret=OK,htemp=22.0,hhum=45,otemp=14.0,err=0,cmpfreq=0,mompow=1"

My guess is that for your unit, you won't see the "mompow" attribute. It's probably dependent on the outdoor unit providing the power usage information, but as long as Daikin does not publish anything about their API, we'll never know for sure.
Titel: Antw:New module: DaikinAC
Beitrag von: MikeR am 19 Mai 2021, 11:10:50
Ok  my result page looks like that:

ret=OK,htemp=24.0,hhum=40,otemp=26.0,err=0,cmpfreq=0
as i understand this means "No mompow" available.  :'(

Is it right that this url results are general values and the "mompow" is one of them if available?
I ask because such things like the state of the streamer are available in the fhem module. I think these are requested by an other url, right?

I guess readings for actual power are nice to monitor general power situations, but on the other hand no ones live depends on.  ;)

I thank you for your fast answer and wish you a nice day
Mike
Titel: Antw:New module: DaikinAC
Beitrag von: shamal2008 am 20 Juli 2021, 20:14:25
Hallo zusammen,

musste meine Daikin Stylish Geräte für die Verwendung der "neuen" Daikin Residential Controller App (aus dem Playstore) firmwaremäßig updaten.

Kann berichten, dass das Modul mit Firmware-Version 1_4_28 immer noch perfekt funktioniert!

Danke nochmal für das Modul!

lg Shamal