Logging, chance to differences item value and state

  • Platform information:
    • Hardware: Intel
    • OS: Ubuntu Server 22.04 LTS
    • Java Runtime Environment: Zulu 8
    • openHAB version: 3.4.4

I hunt actually a bug or misconfiguration in my network, which results that average once a day my AVM FRITZ!Box can’t connected. It always takes only a few seconds, then the box is accessible again.

My problem is, to find the time, when this happens, faster. Logging in my installation is setup with default values, so item changes are logged with “Info”-Level. This has also been bugging me all along, as every voltage change is recorded by the DECT 200.

Example:

2023-07-22 08:29:23.926 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'eg_wohnzimmer_dect200_messwert_spannung' changed from 234.856 V to 234.886 V

This generates a lot of useless SPAM. The problem is, that the state OFFLINE or ONLINE also belongs to the “Info”-Level:

2023-07-22 08:45:53.227 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_3_2' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): FRITZ!Box does not respond with SID.
2023-07-22 08:46:10.547 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_3_2' changed from OFFLINE (COMMUNICATION_ERROR): Request is invalid to ONLINE

I mean, to lost the connection to my devices is worth a “Warn”-Level. So it would be easier to protect the SSD of the system and found the relevant problems in the system.

Is there any chance to get this work or must this be a main change inside openHAB?

You can update your logging configuration, that certain updates do not spam your log file or even write specific log messages into a dedicated file.

There are several other threads about logging with example configuration in the forum or Google e.g. for log4j regex filter and have a look into the docu

Is this a typo? If not, you are using the wrong Java version.
openHAB 3 requires Java 11.

Yes, I was thinking about another software that still requires Java 8.

Matthias, the setting options for logging in openHAB are known to me, including the associated article. This is not the problem. If I change the entire logging level from “Info” to “Warn”, I also lose the information about the online or offline status. It doesn’t matter if I do this on binding level or for the whole openHAB installation. This is what I wanted to clarify with my examples.

I am bothered by the classification that Online or Offline are classified as Information and not as Warning. I would consider warning to make more sense, since an item or thing can’t be addressed by anything in offline mode. Feel free to correct me, but I haven’t found a setting option for this case anywhere. I’m happy to do without the voltage changes, but not the online or offline status.

events.log is the logger for the openHAB Event Bus. As far as it’s concerned, any change to any Item is an INFO level event. The Event Bus doesn’t know and cannot know that a certain Item or Thing changing state is something you really care about. The Fritzbox Thing going OFFLINE isn’t something that impacts the Event Bus. It’s not a warning related to the operation of the Event Bus.

You cannot change the logging level of each event and this is the logger for the Event Bus nor via an individual binding.

It’s not even something you can change inside the Even Bus unless you put some specific code in:

if(event.thingUID == 'avmfritz:fritzbox:192_168_3_2') logWARN(...
else logInfo(...

I bet in openhab.log you’re already seeing a bunch of WARN and ERROR level logs associated with this Thing going OFFLINE. That’s where openhab core, bindings, and rules log to. And losing communication is a warning or error for the add-on. It’s not for the event bus.

And to debug this problem, you need to put the add-on into debug level and look at openhab.log for your information. That entry in events.log is pretty much only useful to tell you when to look in openhab.log for more information.

You can set up log4j2.xml log filters to suppress entries in events.log that match a regular expression and of course command line tools like grep are useful to filter stuff into and out of events.log. But ultimately it’s not going to help you solve this problem.