FHEM > English Corner

New module: DaikinAC

<< < (3/14) > >>

hugomckinley:
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:
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:
- 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: ---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
--- Ende Code ---

control_info:

--- Code: ---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
--- Ende Code ---

model_info:

--- Code: ---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
--- Ende Code ---

sensor_info:

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

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


--- Code: ---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)
--- Ende Code ---

btw: set works, but no polling any longer

roelb:
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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln