Just to elaborate a bit on @hmerk 's response.
events.log shows the logger for openHAB’s Event Bus. The Event Bus is complety separate from all bindings. It logs all ItemStateChangedEvents regardless of where the event came from.
If you have too much in events.log you have lots of options:
-
Leave it. Who cares how much is in events.log. You can use seraches and other techniques to see or find what you need in Frontail and from the command line. See How to watch and look through logging for how to work with logs from the command line.
-
Turn off events.log entirely. I’m of the opinion that either events.log is useful or it’s not useful. If it’s useful, it’s important to see everything. If you are going to filter out some things but not others just because some bindings are “chatty” then I’d argue events.log probably just needs to be shut off in the first place. A partial picture of the events going around is worse than no picture.
-
Configure Frontail not to show events.log. Of course then one must ask what’t the point of having events.log at all.
-
Turn off logging for ItemStateChangeEvent by setting the logging level to ERROR. Of course this means you won’t see any ItemStateChangeEvents in events.log any more but you’ll still see commands, autoupdate predictions, and Thing status changes. Note that there are lots of other events that don’t get logged as well, see log4j2.xml for the list of all events. Those with a level of ERROR are not logged to events.log.
-
Filter out those ItemStateChangeEvents for Items you don’t care about using regex filter in the log4j2.xml config. Again, it’s probably better to just shut off the whole log or the ItemStateChangeEvent entirely.
-
Add profiles to the link between the Channel and these Items to reduce the number of changes that get reported. See Basic Profiles - Transformation Services | openHAB for some useful options for this. However, this will clear up the logs by making it so the Item actually doesn’t change as much.