Set log level of binding has no effect

Hi!

I use Shelly devices over MQTT with JSON path transformation. Based on the fact, that the Shelly devices publishes many informations under the same topic I have a lot of topic content where I don’t defined a transformation. Now I got a lot log entries like this:

2022-11-21 17:11:59.962 [WARN ] [t.generic.ChannelStateTransformation] - Executing the JSONPATH-transformation failed: Invalid path ‘$.params.switch:0.output’ in ‘{“src”:“shellypro4pm-083af27b540c”,“dst”:“shellypro4pm-083af27b540c/events”,“method”:“NotifyStatus”,“params”:{“ts”:1669047120.59,“switch:3”:{“id”:3,“aenergy”:{“by_minute”:[0.000,0.000,0.000],“minute_ts”:1669047119,“total”:0.000}}}}’

Possible solutions:

  • Avoid the not interesting topic updated: not possible, controlled by the Shelly device
  • Define a dummy transformation
  • Set log level to ERROR and avoid the logging of the WARNINGS

I decided to change the log level - without success. Could anybody tell me, what’s the correct logger which I have to adjust? I tried

  • tt.generic.ChannelStateTransformation
  • org.openhab.binding.JSonPath
    Both without any effect in the log file… Here’s the output of log:list in the openhab console:
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.InboxUpdatedEvent                    │ ERROR
openhab.event.ItemAddedEvent                       │ ERROR
openhab.event.ItemChannelLinkAddedEvent            │ ERROR
openhab.event.ItemChannelLinkRemovedEvent          │ ERROR
openhab.event.ItemRemovedEvent                     │ ERROR
openhab.event.ItemStateEvent                       │ 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                                    │ WARN
org.eclipse.lsp4j                                  │ OFF
org.jupnp                                          │ ERROR
org.openhab                                        │ INFO
org.openhab.binding.JSonPath                       │ OFF
org.ops4j.pax.url.mvn.internal.AetherBasedResolver │ ERROR
org.ops4j.pax.web.pax-web-runtime                  │ OFF
su.litvak.chromecast.api.v2.Channel                │ ERROR
tt.generic.ChannelStateTransformation              │ ERROR

Thanks for our support!

See MQTT 2.5 M1+ How to implement the equivalent to MQTT1 REGEX filters. Set REGEX expression to look for something that identifies that the message contains the JSONPATH value. Only if the expression matches will the message be passed to the JSONPATH, eliminating the errors.

Another option is to use the Shelly binding. It’s still local control but handles all this stuff for you.

You can change the log level of the whole binding using org.openhab.binding.mqtt

But the expected way to handle this is through that REGEX filter.

First, I would like to thanks you for the really great support and the quick reply!

I forgot to mention, that the Shelly device provides in the MQTT topic a JSON formated string like this

{“src”:“shellypro3-ec626089c618”,“dst”:“shellypro3-ec626089c618/events”,“method”:“NotifyStatus”,“params”:{“ts”:1669064396.18,“switch:0”:{“id”:0,“output”:false,“source”:“WS_in”}}}

I need to react on the “switch:0” and “output:false”. I configured the MQTT channel like following:

  • id: Channel1
    channelTypeUID: mqtt:switch
    label: Channel 1
    description: “”
    configuration:
    commandTopic: shellypro3-ec626089c618/rpc
    formatBeforePublish: ‘{“id”: 1,“src”:“openhab”,“method”: “Switch.Set”,“params”:
    {“id”: 0,“on”:%s} }’
    stateTopic: shellypro3-ec626089c618/events/rpc
    transformationPattern: JSONPATH:$.params.switch:0.output
    off: “false”
    on: “true”

The problem no is, that the device provides cyclic updates with different content on the same MQTT topic, for example:

{“src”:“shellypro3-ec626089c618”,“dst”:“shellypro3-ec626089c618/events”,“method”:“NotifyStatus”,“params”:{“ts”:1669064451.04,“switch:2”:{“id”:2,“temperature”:{“tC”:33.75,“tF”:92.75}}}}

I need to filter these updates out, but I have no idea how a REGEX could help here…

That’s why I posted a link to that tutorial above. It tells you exactly how REGEX helps here.

As discussed in that topic I linked to, create a REGEX that matches only those messages you care about for that channel and chain that to the JSONPATH. So to only match on switch 0 and extract the output

REGEX:(.*switch:0.*)∩ JSONPATH:$.params.switch:0.output

Only messages that contain “switch:0” will be processed and all other messages will be ignored.

Hi!

Sorry, but I didn’t understand how to combine both filters. But now it works perfectly… I will create a short topic for the inclusion of Shelly devices (not supported by the official binding) via MQTT.

Thanks again!

I’m not sure where the confusion is. You put the REGEX config, ∩ , and then the JSONPATH. That’s it. That’s all there is to it. What ever the first expression matches will be passed to the second one (and so on down the chain should you need more than two.

So make the REGEX only match and return those messages you want to process.