SmartMeter Binding flooding stdout log (Docker Installation)

Platform information:

  • Hardware: Synology Diskstation
  • openHAB version: 3.4.5 running from official Docker image
  • serial port for SmartMeter binding connected via RFC2217 to a Moxa NPort with a RS232 optical interface (Mode C)


I’m using the SmartMeter binding to read my energy meter. The binding works fine and reliably, the only issue is, that it is flooding the Docker stdout log with debug information every time it reads the energy meter (interval is set to 60s):

I have set the logging level of the smartmeter binding to ERROR and even OFF by adding the line

<Logger level="OFF" name="org.openhab.binding.smartmeter"/>

to log4j2.xml, and also tried the command

log:set ERROR org.openhab.binding.smartmeter

on the Karaf console (which should have the same effect),
but this changed nothing, it is still logging every read cycle to stdout.

How can I turn off logging of SmartMeter binding?

Is this really caused by the smartmeter binding resp. openhab ?
The only relations to stdout that I found are:

                <!-- Console appender not used by default (see Root logger AppenderRefs) -->
                <Console name="STDOUT">
                        <PatternLayout pattern="%d{HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n"/>


                <!-- Karaf Shell logger -->
                <Logger level="OFF" name="">
                        <AppenderRef ref="STDOUT"/>

which means it should be turned off ( per default ).

Searching for “Changing baud rate from” this cannot be found in any binding nor in the openhab-core which would explain why you cannot turn it off.

Is this really caused by the smartmeter binding resp. openhab ?

That is a good question. I’d say yes, because:

If I disable the SmartMeter binding, the log entries immediately stop.
As the log entries clearly show information of processing steps of the IEC62056-21 protocol, they cannot emanate from lower protocol layers, like RFC2217, which is used to transfer serial data over network in my case.
So it is my deduction that is has to be caused by the SmartMeter binding or its underlying libraries, maybe the OpenMUC framework.