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