The correct way is to create a filters attribute and then add new filters under that. The above sample will work, but it will generate an error in the console log file (systemctl status openhab2) that can be ignored
I just updated to OH 2.5.1 and have seen that I get this error in OH status
systemctrl status openhab2.service
Jan 28 21:48:34 openHABianPi karaf[4032]: org.ops4j.pax.logging.pax-logging-api [log4j2] ERROR : RegexFilter contains an invalid element or attribute "onMismatch" Ignored FQCN:
according to apache.org the last line of the filter should be
I now have multiple filters working in OH 2.5.1.2.
Per @petero’s last post, you have to define the filter attribute, and then add filters to it. I defined “Stuff” and then filled it with filter sets for general, astro, ups, wifi, and zwave.
Note that the onMismatch line in each filter set must be NEUTRAL. If it’s set to ACCEPT, the filters will stop evaluating at that point. This stackoverflow link explains it better than I can.
@Schrott.Micha I tried changing the last line to ACCEPT, and my filter immediately stopped working. Going back to NEUTRAL fixed it. I can live with the error in the console log file, which I think is a bug in the version of Log4j2 used in openHAB (see this link).
Honestly, there’s no real benefit to this unless your regex string is extremely long and hard to manage…but it’s satisfying if you like things to be grouped together.
I would love to have an option to turn on/off a filter for the log… As time goes, my tail log is so filled with stuff going on all the time. And sometimes I need to look for something special, it would be great to turn off (temporary) stuff I dont need to look at, (cause I know it´s working fine).
I wonder if this kind of filter would do, and then create a proxy switch to turn on/off several filters? I suspect it´ll have to be done using exec/scripts and commandline to Karaf consol?
This is a good point for using filter sets. If you want to see the log entries for something specific, it’s easier to find and comment out the filter specific to the device type than editing those entries out of a long regex list and adding them back later.
yea but i was hoping for a permanent solution… i tried pretty much all of the log4j2 settings but nada… there must be a way though since we can exclude specific bindings and levels…
I want to filter anything with amazonechocontrol:smartHomeDevice or other regex compatible lines from log:tail ( i have no issue with log files filtering but that is not what i specifically want )
Is it possible to check out events that have already been filtered? I had a Item filtered and I would like to check out when changed the status yesterday and I do not know if it is stored in another file into the system.
When you filter the logs like this, that log statement is lost. That’s why I’m very much against filtering logs like this except in extreme circumstances. The whole purpose of logs is to preserve information like this so you can go back and see information like this. It’s better to let the log statements be written and use tools available to you to filter the logs based on what’s important to you at that time. Everything continues to be written but you can narrow down what you are looking at to just those lines that are relevant to what you are working on. And then, when something happens and you have to go back and do a forensic analysis, all the logs are there.
You cannot know ahead of time what logs will be relevant so let everything log as normal and search/filter the logs as needed.
@rlkoshak just chucked a link to your thread into the main post. When i wrote this up the intent was to keep stuff I didn’t want ‘out’ of the log, but I can see some users won’t always know the difference between filtering something to prevent it being logged, and filtering a log view to only show what they want. Thx.
I originally implemented log filtering both to reduce what I see in my log (understanding fully what it was doing) and to reduce writes to my SD card. I recently enabled ZRAM, which takes care of the latter goal. That didn’t occur to me until reading this just now.
If of any help, this is how I implemented a filter on events per item “categories”. Purpose was to make it easier to track particular events while debugging my scripts. Of course, following rules should be disabled once debugging is over as the rule trigger on all monitored items which adds useless processing.
I created Group items for each category to monitor and attached the corresponding items to these groups. For example, to monitor items related to alarm system, I created a group named SEC_Alarm and assign to items in the definition in the .items file Group SEC_AlarmMode Number SEC_System_AlarmMode_G1 "Garage côté rue" <_garagerue> (SEC_AlarmMode) {autoupdate = "false" } Number SEC_System_AlarmMode_G2 "Garage de l'impasse" <_garageimpasse> (SEC_AlarmMode) {autoupdate = "false" } Number SEC_System_AlarmMode_Cave "Cave" <_cave> (SEC_AlarmMode) {autoupdate = "false" } Number SEC_System_AlarmMode_HomeAxs "Accès maison" <_access> (SEC_AlarmMode) {autoupdate = "false" } Number SEC_System_AlarmMode_HomeMvt "Mouvements maison" <_motion> (SEC_AlarmMode) {autoupdate = "false" }
I created a Number item that holds the expected level of monitoring: 0=no monitoring, 1=monitor changes, 2=monitor commands, 3 (1+2)=monitor both changes and commands Number SYS_LogGroup_SEC_AlarmMode "SEC_AlarmMode" (SYS_LogGroup)
This item is exposes in the sitemap and allows changing the log level from the UI
I wrote rules to monitor the expected event (indeed I have 2 rules : one monitors change events and the other monitors command events):
import java.util.HashMap val HashMap<String, String> itemChanges = newHashMap() var found = false
mute the “standard” event logging with : log:set ERROR smarthome.event.ItemStateChangedEvent
I am a bit ashamed to propose such an ugly workaround but at least it works. And I am afraid that the headless development of OH will let more of these awful tricks to develop as I have not seen one single improvement since OH 1.8 to improve script development despite the ever-changing XTend / JAVA / smarthome environment which forces us to review/readapt our code at every OH “upgrade” with no functional improvement for an end user like me.
OH is definitely a powerful modular tool but is not aimed at audience like me who would prefer concentrating on automation logic rather than Java and all that clumsy stuff.
