New module: DaikinAC

Begonnen von roelb, 26 März 2020, 19:16:24

Vorheriges Thema - Nächstes Thema

hugomckinley

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
----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

roelb

Zitat von: hugomckinley am 04 April 2020, 13:36:37
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.

ZitatIf 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.

hugomckinley

So we can both agree, that every use case should be covered :-)

I continue testing ...

Hugo
----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

roelb

Yep ;-). And thanks, if you see anything out of the ordinary, please let me know.

hugomckinley

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?
----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

hugomckinley

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?
----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

markusphi

ich habe das Modul Heute getestet und es funktioniert sehr gut!
Danke!

markusphi

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?

roelb

Zitat 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?

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.

roelb

Zitat von: hugomckinley am 05 April 2020, 20:02:37
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.

markusphi

Zitat von: roelb am 06 April 2020, 17:16:33
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)

Slanesh

Just installed the module and it worked in less than 2 minutes. Great job @roelb!
Intel NUC, 2x HM-LAN, 1x CUL-USB, 2x CCU2, 1x Harmony-Hub, 20x HM-LC-Sw1PBU-FM, 5x HM-LC-SW1-PL2, JeeLink mit 15x TX-29-DTH, 7x HM-SEC-SC-2, 3x HM-LC-SW1-BA-PCB, 8x HM-SEC-SD, 3x HM-SEC-MDIR-2, 2x HM-ES-PMSw1-Pl, 8x HmIP-BWTH, 3xHM-CC-RT-DN, 16xHM-LC-Bl1PBU-FM, 8x HM-SEC-SCo, 1xHM-ES-PMSw1-SM

gadget

#27
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.

roelb

#28
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.

hubiuwe

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
Die beste Automatik ist die, die man abschalten kann!