Smartmeter Binding throws "unable to open port" after a while

Actually I have two brand new USB cable around here for quite a while. Since its not easy to exchange the old ones, I didn’t do it yet.
For the time being I have built a workaround script that just restarts my OH (or even the raspi itself) if there are some errors :-):


# ANY_OFFLINE calculation:
# 1. We check every openhab thing
# curl http://localhost:8080/rest/things
# 2. Pipe it to jq
# jq
# 3. Build an Array of OFFLINE things
# 3.1. Array
# [...]
# 3.2. Check every element of thing array array to be OFFLINE
# .[] | select(.statusInfo.status=="OFFLINE")
# 3.3. Extract the UID
# | .UID
# 3.4. Filter only smartmeter things
# | startswith("smartmeter") | select(. == true)
# 4. From the resulting array of booleans check of any is true (means there exists an OFFLINE element from smartmeter)
# [...] | any
# Result is true / false
echo "Running check for offline things..."

ANY_OFFLINE=$(/usr/bin/curl --silent http://localhost:8080/rest/things | /usr/bin/jq --raw-output '[.[] | select(.statusInfo.status=="OFFLINE") | .UID | startswith("smartmeter") | select(. == true)] | any')

if [ "$ANY_OFFLINE" == "false" ]; then
  echo "$(date): Online" >> /tmp/offline_log.txt
  rm -f /tmp/smartmeter_offline
  exit 0

if [ -f /tmp/smartmeter_offline ]; then
  rm -f /tmp/smartmeter_offline
  echo "$(date): Offline" >> /tmp/offline_log.txt
  FAILED_MODEM_LINES=$(cat /var/log/syslog | grep "failed to get modem status" | wc -l)
  INPUT_OVERRUN_LINES=$(cat /var/log/syslog | grep ttyUSB | grep "input overrun" | wc -l)
  if (($FAILED_MODEM_LINES > 10)) || (($INPUT_OVERRUN_LINES > 10)); then 
      echo "Rebooting now!" >> /tmp/offline_log.txt
      /sbin/reboot --reboot 
      echo "Restarting OH now!" >> /tmp/offline_log.txt
    systemctl restart openhab2.service
  echo "$(date): Offline" >> /tmp/offline_log.txt
  touch /tmp/smartmeter_offline

Since this OH instance is only for my smart meters and other less important sensors, I can live with some restarts once a while.
My plan is to re-do most of this and exchange the cables once I switch to OH3 and then a Raspi4 with a docker based installation.


Thank you. That is quite a hard workaround, but at the moment I don´t see any alternative… :frowning:
Are you using OH2?

As seen in other bindings, there does appear to be some problem in the common underlying serial library, which appears to manifest as serial port locking out during what should be a “routine” error recovery sequence.
Tagging the github issue as this may be what you are seeing too,

Any news on that topic?

I think there is a success in implementing a workaround on the modbus binding which avoids the lock of the serial port. See here:

I don’t know if the same workaround is working with the smart meter binding and if it will be implemented.
But I am also very interested in a solution here.

I still have the same problem here.
Running OH3.1.0 M5 now.
I am not sure when the fix in the nrjavaserial serial libary will be ready…?
What I am wondering: I am also runnging the ComfoAir Binding. The communication to the ventilation-system is also done over a serial connection. This connection is running absolutly stable and reliable since months. I am not a programmer, but I think the “buggy” serial libary is not used here.

@boehan Sorry for pointing you directly. Maybe you can tell how the serial connection is done with the ComfoAir binding? Is there a way to use the same way to communicate with the Smartmeter binding?

@Tuny my knowledge about serial communication is rather limited thus I have not much to add here. Having a quick look at the code of the smartmeter binding it just uses the available core libraries for the serial connector, just as the comfoair binding does.
From a rough read over this thread I’d assume that your connection to the smartmeter is just more unstable than that to the comfoair, e.g. due to interference, bad/longer cable, etc., which then causes the connection to get blocked.
However, I just saw, that the related bug in the error handling of nrjavaserial is fixed upstream and should find its way in OH soon (see Serial ports getting blocked after some re-connecting · Issue #1842 · openhab/openhab-core · GitHub)


OK, that makes sense. The connection to the smart meter is done over an optical probe. So there might be more reading errors and delays.
Thank you very much for your investigation.

Hi there!
I just stumbled into the same error; First I was very positively surprised how easy it was to get the optocoupler delivering useful values from my feed-in-counter.
But the next morning the state was the one discussed above. Rarely I do get that thing " go green" - no matter what I try. And now I stumbled into this thread…
The only useful I can tribute here is that in my case it doesn’t seem to be connected to the same issue disturbing Modbus-communication. My openhab system communicates with 3 different solar and battery inverters without any problems at all since a long time…
Did anybody get further in this case?
Best regards,

There is a soution which helped me. See here:

@Tuny Thanks a lot! I sniffed hope and direktly started the job, but faced two problems:

  • trying to log in at the openhab console none of my known passwords seem to fit. Neither the standardpasswort habopen doesn’t work. Nevertheless, I understood this step is only to “Check if the PureJavaComm provicer is active”
    So I rebooted without this check hoping things were all right, but after changing the Serial port of the Smart Meter Optokoppler Thing from dev/ttyUSB0 to ttyUSB0 the connection remained offline saying "No provider for port ttyUSB0 found "
    After switching back to /dev/ttyUSB0 message “wrong crc” and "Termination sequence is wrong " change to each other…
    Any additional idea???


Can you check what is listed in your dev folder?

cd /dev



What is the result? Did you check the log of your openHAB installation?
When you go in the Serial Port configration of your “smart meter thing”. Are there avilable ports shown (drop-down-menue)?

At the end did you try disable and eneble your smart meter thing?

dear Tuny,
the smartmeter optocoupler is listed as ttyUSB0 in /dev.

I tried to disable and enable the thing but without success.

sometimes after fresh plugin the thing goes online for a few seconds but then turns into offline

after disable and enable the thing says first:

Waiting for messages from device


wrong crc 

but doesn’t go green again…

Rossko’s post above is the issue here. The library used to provide serial in OH currently is nrjavaserial. Here is post from another thread with links to github issue by contributer of nrjavaserial library explain issue (which is an unresolved bug)

nrjavaserial has a file leak and creates lock files which on restarts of OH can leave serial port locked

I don’t think it is a problem of the provider. It is more a problem of the physical connection.
Please check all the cables. Also look that the optocoupler fits properly in the mounting fixture of the smart meter. Maybe you need to clean the front a little. Also check if the optocoupler is in the right rotation (there are sender and receiver IR-Lights inside and should fit together).

Maybe you can check if the it works with a windows openHAB installation? Does it work then?

There is an alternative which works pretty well. See my post above.

Dear Sebastian, dear Andrew,
thanks a lot to cope for my case.

  • I tried to follow the workaround from Rossko but must admit I got stuck at the place where I wanted to enter the console: it asked me for a password and none of the ones I know worked.
  • I don’t have an openhab-windows-system available but tried with a simple terminal program: At least the the sending diode pulsed when I’ve send some message to be sent
  • as written already, sometimes the system works. this is only after fresh reconnecting but not always. Sometimes even after reboot and reconnection the thing doesn’t turn green.
  • if it turns green, I can see all Obis-registers to be alive and mirroring the same values I can read from the LCD-display of my smartmeter
  • unfortunately, theses occurances are very short.

conclusion: I feel rossko’s approach would helb but need to find out why I don’t succeed at the console.

Best regards,


take a look here:

The username & password is there, right at the end of the “Accessing the console”.


Hi there,
thanks again!
I tried the default password, being on the machine (raspberry Pi) via teamviewer. It seems this password is not accepted. I don’t remember to have it changed on purpos, n’either work all the different passwords I’ve ever set (I tried all possibel)

Is there any way to reset the password of the console??

That sounds adventurous. There is no way to connect directly via ssh?
It could be a “poblem” with the keyboard layout. Also you need to be sure that every key you press is sent to the console… so don’t be to fast. Did you try copy & paste?

Dear all friendly helpers,
sorry for answering late; other things requested to shift priorities…
@ Tuny:
I read the console doesn’t allow connection within a ssh connection if this connection was made from a foreign machine.
I consider a Teamviewer connection is the same as you would be directly connected at the machine via keypoard and monitor (similar to VNC).
I understood the console connection is only necessary to check if the measure helped to change from nrjavaserial to the other serial library.
And - funny enough - it seem to have worked! The Thing stays green! I added a second sensor and this one stays green as well.
So thank you all again - One of all the tips I got seem to have helped!