Guys,
Is there any way to supress log entries for a specific binding via a rule?
I have a cron which disables my z-wave controller for 5 seconds and then re-enables it (I’ve been having issues where the controller or some of it’s items go ‘offline’ over time, this workaround solves the problem).
Problem is, I get loads of entries in the console log and I’d like to disable logging for the binding during this reset routine.
Seems you can change log levels using the REST API logging, looks promising, however where would I find the loggerName?
I am assuming I would change the level to NONE and then back to INFO after I am done?
Also, does the loggerName go in both the post data and the URL? The docs seem to suggest it does.
See Logging | openHAB :
The what is defined by
package.subpackageand is in most cases a binding (likeorg.openhab.binding.zwave).
It is OFF instead of NONE
According to the API Explorer that should be the case. Just try it.
using jruby:
OpenHAB::Log.logger("org.openhab.binding.zwave").level = :off
after(5.seconds) do
OpenHAB::Log.logger("org.openhab.binding.zwave").level = :default
end
Thanks for the reply,
I am able to execute the rule without errors, and it also executes in the API viewer with a status code of 200, however I am still getting INFO log entries when the zstick resets.
One of the messages I have included:
13:20:53.867 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:device:cf6d12cc56:node8' changed from ONLINE: Node initialising: REQUEST_NIF to ONLINE
It’s confusing, according to the docs I should be able to filter by binding.
I have also tried with:
{
"loggerName": "org.openhab.event.ThingStatusInfoChangedEvent",
"level": "OFF"
}
Status code 200, still get the logs.
Looking into the output of log:list in the karaf console I see
openhab.event.ThingStatusInfoEvent
no leeding org.
Awesome, works like a charm.
Well spotted!
15:10:17.819 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'z-reset.rules'
15:10:43.219 [INFO ] [org.openhab.core.model.script.Z-Reset] - Resetting... Disable event logs...
15:10:45.754 [INFO ] [org.openhab.core.model.script.Z-Reset] - Enable
15:11:15.947 [INFO ] [org.openhab.core.model.script.Z-Reset] - Enable event logs...
15:11:16.023 [INFO ] [org.openhab.core.model.script.Z-Reset] - Do Temps
15:11:16.035 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Stat_Target' received command 17 °C
15:11:16.037 [INFO ] [org.openhab.core.model.script.boiler ] - triggered by: Stat_Target
15:11:16.047 [INFO ] [org.openhab.core.model.script.boiler ] - Setting 17.0 Actual 20.2 State OFF
15:11:16.057 [INFO ] [org.openhab.core.model.script.boiler ] - Heating OFF, do nothing.
Exactly what I wanted, no more clutter.
1 Like
This illustrates the danger of working around a problem instead of solving the root cause. Regardless, I just wanted to make something clear which wasn’t explicitly stated.
All the openhab.event loggers are a part of the Event Bus, not the bindings. So by turning off openhab.event.ThingStatusInfoEvent you are turning off the logging events for all your Things, not just the zwave Things. And you can’t filter those logs by binding because they don’t come from the binding.
For completeness, here is how you would do it in a JS Scripting rule:
Edit: Corrected the code (see below)
osgi.getService('org.apache.karaf.log.core.LogService').setLevel('openhab.event.ThingStatusInfoChangedEvent', 'OFF');
setTimeout(() => osgi.getService('openhab.event.ThingStatusInfoChangedEvent').setLevel(console.loggerName, 'WARN'), 5000);
For completeness, I am pretty sure that’s exactly what I did.
if (ZTimer !== null) return;
logInfo("Z-Reset", "Resetting... Disable event logs...");
sendHttpPutRequest(eurl,"application/json",json,headers,1000);
sendHttpPutRequest(url, "text/plain", "false", headers, 1000);
var String loggerName = "openhab.event.ThingStatusInfoChangedEvent"
var String level = "OFF"
var String json = '{"loggerName":"'+loggerName+'", "level":"'+level+'"}'
var String eurl = "http://oh:8080/rest/logging/" + loggerName
var String url = "http://oh:8080/rest/things/zwave:serial_zstick:cf6d12cc56/enable"
ZTimer = createTimer(now.plusSeconds(2), [ |
logInfo("Z-Reset", "Enable");
sendHttpPutRequest(url, "text/plain", "true", headers, 1000);
ZTimer = createTimer(now.plusSeconds(30), [ |
logInfo("Z-Reset","Enable event logs...")
level = "DEFAULT"
json = '{"loggerName":"'+loggerName+'", "level":"'+level+'"}';
sendHttpPutRequest(eurl,"application/json",json,headers,1000);
logInfo("Z-Reset", "Do Temps");
Stat_Target.sendCommand(Stat_Target.state as Number);
ZTimer = null;
]);
]);
I’ve tried using this ogsi class / object, it’s been suggested before, however it isn’t recognised by my setup, despite my best efforts to get this working and asking for help getting this working, and although your code is shorter and more elegant we all have to get by with what we can use.
This is working now, in the immediate present that is all I can hope for.
I’m not entirely sure what you mean by “not recognized” but as I hope was clear in @JimT and my posts, our code is JS Scripting and jRuby respectively. They are not compatible with Rules DSL. I’m not certain access to pull OSGI services is available in Rules DSL.
In comparison to most of the other rules languages, including Blockly, Rules DSL is fairly limited, lacking support for even basic programming language features and failure to provide a significantly simpler programming environment. There isn’t much that is completely impossible from Rules DSL but anything outside of the simple and basic is going to take a lot more code and potentially be brittle.
I mean that I get an error saying just that, like it’s not supported in Rules DSL and impossible to import. Meaning people using those rules (as is suggested) cannot use these classes.
Agreed, maybe there could be some effort to change that, at the very least make the more helpful and common classes more available within the Rules DSL environment.
I guess what I am saying is that solutions which are unavailable to the most basic user are not helpful, however well intentioned.
Rules DSL really isn’t suggested to be used anymore, particularly for new development. It hasn’t been the recommended default since OH 3.0. The Getting Started Tutorial doesn’t even reference Rules DSL except in passing.
A month or so ago a PR was added to expose the ColorUtils in Rules DSL. It took hours and hours of effort and weeks to get it working right. Rules DSL is simply too hard to work with on both ends: for the developers and for the end users. That’s why all the other languages including Blockly have far exceeded Rules DSL in simplicity of use and capability and it’s why Rules DSL is mostly kept around for legacy support.
The most basic user is going to be using Blockly, not Rules DSL. That is the recommendation since OH 3.0. For Blockly users, there are either Block Libraries to expose these sorts of things or, in a pinch, the “inline script” block can be used to insert raw JS Scripting code into a Blockly Script. JS Scripting and jRuby have access to OH core APIs in their respective libraries. Groovy and Java Rule have raw access to the Java OH APIs. It’s only Rules DSL that is neutered and it’s why Rules DSL is no longer and has not been recommended for new development for a few years now.
Interesting, I had no idea Rules DSL had been abandoned. As far as I was aware the docs were still promoting this rule, when, then, end paradigm.
I have just looked at the ECMAScript examples and I still have no idea how to use this system. Do we create and write all our code in the UI now?
I liked the old system because I could simply save all my rules files if I ever needed to backup and restore my system.
Maybe I need to have a proper play with this new system before making any changes.
Not abandoned, just too hard to make changes to so a lot of new stuff never gets added to it.
That is indeed the syntax for Rules DSL in files and the docs do need some updates (some in progress, others need volunteers). But Getting Started doesn’t cover Rules DSL and makes it clear that the reference for the syntax is going to be in the add-on’s docs. The new Rules section under Concepts makes that clear also.
You can if you want to. If not, this section of the docs explains everything about how to write rules in text files for JS Scripting. In short:
- install the add-on
- files go under
$OH_CONF/automation/js - file extension is
.js - there are two ways to create rules in these .js files, using
JSRuleand the rule builder. There are several examples showing both - overall syntax is pretty thoroughly covered on that page or by following links on that page.
You can do the same with UI rules, they are just in a different file and folder: $OH_USERDATA/jsondb/automation_rules.json. The backup scripts that come with OH also save everything from both conf and userdata.
I’ve been migrating my rules to js and this doesn’t work for me.
My error is huge, but the crux of it is this:
18:26:12.172 [ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID '1918a768d0' failed: org.graalvm.polyglot.PolyglotException: Error: Failed to get any services of type(s): openhab.event.ThingStatusInfoChangedEvent
That was a pretty big typo on my part. I replaced the wrong part of the line with the logger name.
osgi.getService('org.apache.karaf.log.core.LogService').setLevel('openhab.event.ThingStatusInfoChangedEvent', 'DEBUG');
1 Like