OH4 Blockly Debug logging - define the subpackage for ease of turning on/off logging

I have been using Rules DSL up until now, and had my logging configured as per the following example:

logDebug("shelly_uni", "UPS Batt Voltage Was: " + upsBattVoltagePrevious.toString())
logDebug("shelly_uni", "UPS Batt Voltage Now: " + upsBattVoltageNew.toString())

This will not show any logging until the following command is issued:

log:set DEBUG org.openhab.core.model.script.shelly_uni

Is there any way to achieve a similar result using Blockly? It appears that all blockly logs are issued under the package org.openhab..automation.script.ui with a subpackage of the rule name.

10:29:20.670 [ERROR] [nhab.automation.script.ui.Watts_to_VA] - Raw Value of ShellyEM_UPS_Watt: 404.36 W
10:29:20.670 [ERROR] [nhab.automation.script.ui.Watts_to_VA] - Raw Value of ShellyEM_UPS_PowerFactor: -0.86
10:29:20.671 [ERROR] [nhab.automation.script.ui.Watts_to_VA] - Updated Value of ShellyEM_UPS_PowerFactor: -0.86
10:29:20.671 [ERROR] [nhab.automation.script.ui.Watts_to_VA] - Calculated VA with UoM value is: -470.18604651162790697674418604651145864 VA

I tried setting:

log:set INFO org.openhab.automation.script.ui

however the logs still display in the logs

openhab> log:list
Logger                                                  │ Level
ROOT                                                    │ WARN
javax.jmdns                                             │ ERROR
javax.mail                                              │ ERROR
openhab.event                                           │ INFO
openhab.event.AddonEvent                                │ ERROR
openhab.event.ChannelDescriptionChangedEvent            │ ERROR
openhab.event.GroupStateUpdatedEvent                    │ ERROR
openhab.event.InboxUpdatedEvent                         │ ERROR
openhab.event.ItemAddedEvent                            │ ERROR
openhab.event.ItemChannelLinkAddedEvent                 │ ERROR
openhab.event.ItemChannelLinkRemovedEvent               │ ERROR
openhab.event.ItemRemovedEvent                          │ ERROR
openhab.event.ItemStateEvent                            │ ERROR
openhab.event.ItemStateUpdatedEvent                     │ ERROR
openhab.event.RuleAddedEvent                            │ ERROR
openhab.event.RuleRemovedEvent                          │ ERROR
openhab.event.RuleStatusInfoEvent                       │ ERROR
openhab.event.StartlevelEvent                           │ ERROR
openhab.event.ThingAddedEvent                           │ ERROR
openhab.event.ThingRemovedEvent                         │ ERROR
openhab.event.ThingStatusInfoEvent                      │ ERROR
openhab.event.ThingUpdatedEvent                         │ ERROR
org.apache.cxf.jaxrs.sse.SseEventSinkImpl               │ ERROR
org.apache.cxf.phase.PhaseInterceptorChain              │ ERROR
org.apache.karaf.jaas.modules.audit                     │ INFO
org.apache.karaf.kar.internal.KarServiceImpl            │ ERROR
org.apache.karaf.shell.ssh.SshUtils                     │ ERROR
org.apache.karaf.shell.support                          │ OFF
org.apache.sshd                                         │ ERROR
org.eclipse.lsp4j                                       │ OFF
org.jupnp                                               │ ERROR
org.openhab                                             │ INFO
org.openhab.automation.script.ui                       │ INFO
org.openhab.binding.hue.internal.connection.Clip2Bridge │ TRACE
org.openhab.binding.paradoxalarm                        │ INFO
org.ops4j.pax.url.mvn.internal.AetherBasedResolver      │ ERROR
org.ops4j.pax.web.pax-web-runtime                       │ OFF
su.litvak.chromecast.api.v2.Channel                     │ ERROR

There is no entry for org.openhab.automation.script.ui until I issue the log:set command, so it appears that is defined differently maybe?

Any suggestions and advise appreciated.

Well, yes they would. Logging levels are “this and above”. Setting the logging level to INFO means INFO and above with WARN and ERROR being above INFO. All those logging statements you show above are at the ERROR level so of course setting the level to INFO won’t suppress those. But is should suppress anything at the DEBUG or TRACE level.

No, it just inherits from the loggers above it before you issued that command which is the org.openhab logger, which too was set to INFO.

You appear to be doing everything right and just perhaps don’t understand how logging levels work. You need to use the levels in your rules. Stuff that means the rule failed for some reason should be logged as ERROR (rare). Stuff that means something may have gone wrong or is a little off should be logged as WARN. Stuff that you want to see every time the rule runs typically should be logged at INFO. Stuff that provides additional information useful to solving problems in the rule should be logged at DEBUG or TRACE (note in some cases TRACE is special and each log statement will also print a stack trace).

Leave the logger at the INFO level and set the log statements you don’t want to see all the time to DEBUG. Then if a rule is failing, you can set just that one rule to DEBUG level and see more info to help solve the problem, then turn those statements back off by setting it back to INFO, WARN, or even ERROR.

Thanks Rich. I got myself confused in trying to work out why it was not working as I expected. But I have been using WARN and ERROR, which by your explanation would be included in INFO.

I will chnage the rule sto use DEBUG instead and then I guess my expectation of setting

og:set INFO org.openhab.automation.script.ui.<RuleName>

will work.

Thanks for the course correction and explanation.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.