Hi,
Perhaps the event log just shows state changes?
It is true that thing channels and item states are updated on every poll, even when the value is not changed. Is this not the case you want to have?
With the old binding, at least using openHAB1, this increased CPU usage quite a lot. For this purpose, a configuration parameter was introduced to disable state updates when the value is unchanged from previous poll (updateunchangeditems). See PRs #4291 and #4339 for the original discussion regarding this topic.
Unfortunately, the feature has its downsides, and the item state can get out of sync of the polled data, see this comment (especially this chain of events).
As far I understood from the “openHAB philosophy”, the binding should update the states, whenever new data is available. It is said that binding is “stateless” in this sense. However, the CPU usage was considered such a downside, that it was well founded to limit the updates (see the PRs for the discussions).
I am curious to know how the CPU usage is with openHAB2 (pinging high frequency modbus poller @mbs38) . With openHAB1, the CPU usage was due to the internal state update events inside openHAB itself, the actual polling does not require much CPU.
Note that one can always react on state changes only (instead of all updates). However, it looks like expire binding does not allow this, and makes no distinction between the updates. In fact, they even have disclaimer in the docs about this:
If another binding is repeatedly updating the state of the item to be the same state it already was, the expiration timer will continue to be reset into the future. Dedicating an item to the expiration function (so it doesn’t receive repeated updates from another binding) would avoid unwanted behavior, should it apply in your case.
I wonder if such improvements are possible in expire binding, or if it has been discussed here in community forums? At least there is some new version of expire binding in the works, see here.
The good side with the current behaviour is that you can detect if the data just stop updating, e.g. when the slave goes down. On the other hand, there are now dedicated diagnostics channels(“last error” and “last read”) for this purpose, and using expire binding is perhaps more complicated than necessary.
Best,
Sami