OH3: SmartMeter Binding looses connection after a while: No provider for port /dev/ttyUSB.COM found

Setup, Configuration and Use Migration
1

Hello community,

I am still in the process of migrating to OH3. For this purpose, I use two identical RPI4, one runs OH 2.5 (production) and the other one OH3. The OH3 RPI is a cloned version of the production system which I upgraded using openhabian. I got the OH3 RPI running so far, and yesterday I swapped SD-cards to test OH3 with all hardware connected.

Doing this, I encountered a problem with the smartmeter binding. I use two Serial-USB adapters to read counters for heating power and regular power. To avoid confusion with USB-Ports, I created a udev-rule which creates symlinks based on the serial numbers of the USB-adapters. This setup is identical in the OH3 RPI.

After I swapped SD-cards to the production RPI yesterday evening, smartmeters first were working fine and got updated. I usually have some log entries in openhab.log regarding CRC-errors, but this also occurs on the 2.5 system and after some retries values are always populated nicely.

But in OH3, after about 15 minutes, the following happend:

2020-12-30 22:06:24.921 [WARN ] [ding.smartmeter.internal.MeterDevice] - Failed to read: No provider for port /dev/ttyUSB.COM found. Closing connection and trying again in 2 seconds...; smartmeter:meter:5476e3cb
java.lang.IllegalStateException: No provider for port /dev/ttyUSB.COM found
	at org.openhab.binding.smartmeter.internal.sml.SmlSerialConnector.openConnection(SmlSerialConnector.java:137) ~[bundleFile:?]
	at org.openhab.binding.smartmeter.internal.MeterDevice.lambda$1(MeterDevice.java:168) ~[bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableDoOnLifecycle$SubscriptionLambdaSubscriber.onSubscribe(FlowableDoOnLifecycle.java:63) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableTimeoutTimed.subscribeActual(FlowableTimeoutTimed.java:47) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14479) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableDoOnLifecycle.subscribeActual(FlowableDoOnLifecycle.java:38) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14479) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableDoOnEach.subscribeActual(FlowableDoOnEach.java:50) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14479) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableDoOnLifecycle.subscribeActual(FlowableDoOnLifecycle.java:38) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14479) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableDoOnEach.subscribeActual(FlowableDoOnEach.java:50) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14479) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowablePublish.connect(FlowablePublish.java:130) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableRefCount.subscribeActual(FlowableRefCount.java:91) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14479) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14426) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableRepeatWhen$WhenReceiver.onNext(FlowableRepeatWhen.java:100) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableRetryWhen.subscribeActual(FlowableRetryWhen.java:62) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14479) [bundleFile:?]
	at io.reactivex.Flowable.subscribe(Flowable.java:14426) [bundleFile:?]
	at io.reactivex.internal.operators.flowable.FlowableSubscribeOn$SubscribeOnSubscriber.run(FlowableSubscribeOn.java:82) [bundleFile:?]
	at io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker$BooleanRunnable.run(ExecutorScheduler.java:260) [bundleFile:?]
	at io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.run(ExecutorScheduler.java:225) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]

The same happend to the second smartmeter connected. Worth to mention, the hardware is the same as with OH 2.5 I just swapped the SD-cards.

After a reboot, things work normal again for a couple of minutes, then the problem occurs again.

Switching the Thing to the “real” USB port instead of the symling (e.g. /dev/ttyUSB0) also does not bring the Thing back to life, only a reboot helps.

I checked /var/log/syslog and /var/log/messages for any entries regarding tty-devices at the same time, but no entries found.

Any ideas what could be wrong?

2

Addition to the above, I checked on my OH2.5 system and found this entry in /etc/default/openhab2

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB.COM:/dev/ttyUSB.HEA:/dev/ttyACM0.ZWA"

I added this one to /etc/default/openhab on the OH3 machine, but the error still occurs. It takes around 15 minutes to occur.

3

As I found no solution for the above mentioned problem, I ended up with a workaround.

I used the VZLogger-Daemon from VolkszÀhler-Project:

The Logger includes a HTTP-Server which offers the latest readings in JSON-Format, so I use a OH3 URL-Object, read the JSON-response from VZLogger and transform to the needed values using JSONPATH. VZLogger can also write to InfluxDB directly if necessary.

4

The very same effect happens to me, also with 2 readers installed. Whatever was working well in OH2.x, stops responding after a while in OH3. Multiple times per day. I tried fiddling around with MODE parameter of symlinks, but without success. System is openhabian 1.6.2b.

5

I discovered the same issue on RPI4 with openhabian 1.6.2b with 3 readers (volkszÀhler). After a reboot it works for a while, then the issue is back


6

Changed to openhabian 1.6.3, same issue. When using feature:install openhab-core-io-transport-serial-javacomm in console, it recovers (for a while?), but that doesn’t survive a reboot.

7

Do you use the Smartmeter-Binding or Volkszaehler to read the values? I noticed that VZLogger also is not very stable, so I use a cron to restart it every 30 minutes. At least this gives me continuous values.

8

I use smartmeter binding, which worked flawless up until 2.4, then started to become a little picky (“wrong crc” every ~2-3 readíngs) but continued working. Now, in OH3@openhabian1.6.3, it stops finding the ports - both the dev/ttyUSBx and a link (“No provider for port /dev/ttyUSB0 found”). After reboot, binding accesses native ports nicely again - for some hours.

1 Like
9

Check this thread: Apparently the Zwave binding blocks the / dev / ttyUSB0 port in Combination with a CC2652RB Zigbee2mqtt Dongle - #29 by yab

It is about Zigbee, but it could potentially be the same reason: Z-Wave Binding conflicts with /dev/ttyUSB* Ports. Start reading at post #29

10

Thank you for the crosslink, checked the thread. Although interesting, doesn’t apply to my issue, as there is no such (or similar) binding installed to query a physically connected device. Apparently I continued testing. Reducing the update interval to default (20s) helped a lot. While playing around I found out that the device read buffer might be the problem’s source. So reading it more frequently helps keeping the filling status within limits. Although I didn’t intend to read these data that often, it seems more stable. While with 30 or 60s both smartmeter readers became unavailable practically at the same time after some few hours, I now saw unavailability of a single reader after 2 days. So I might test even lower update period, 15s or so.

11

I’m using OH3 and also have that problem and found out that when activating the smartmeter “Thing” the output of the “dmesg” command gets flooded by input overruns like the following :

[151762.159243] ttyUSB0: 2 input overrun(s)

on the USB-port used by the smartmeter binding.
After a few hours OH3 becomes unstable and must be restarted or my Raspberry PI must be completly rebooted.
When deactivating the smartmeter “Thing” in the OH3 GUI these messages completly disappear and
OH3 runs fine without the need of any reboot or restart.

I hope anyone can find a way to fix this. For now I will leave the smartmeter “Thing” disabled.

12

Same issue here. Really frustrating

13

Hi,

I keep running into the same problem: OH 3.2.0 Release Build running on a Raspbbery 3B+. The smartmeter works well for a couple of hours but then I receive the same value all the time and get the comm error “No provider for port /dev/ttyUSB found”.

Has anyone found a solution or fix for this problem?
Best, Max

14

Try this:

15

Do you still have this issue or is it solved in Openhab4?

16

Still that same problem even with 4.04. Has anyone found a solution? I am running OH4 via docker desktop on a NUC and am frustrated of all that instability. Thinking to change systems

17

I began looking at possible causation of the overruns and it seems to be an speed issue: https://www.linuxquestions.org/questions/linux-software-2/ttys0-1-input-overrun-s-4175419550/#post4742210
Data arrives faster than it is being consumed. Now - in terms of improvements, it could be that serial port listener in openHAB side is not reading all data or reading it too slow.
I don’t know this binding at all, but of all of you have similar symptoms on various hardware it suggests that listener code or protocol implementation should be improved.

18

What would be possible workarounds to get it stable?

I only know these two possibilities:

  • Read the smartmeter with ESP32/Tasmota and provide the data over MQTT to Openhab
  • Use a (TTL-)RS485-Ethernet Adapter and read the data in Openhab over TCP. But this is currently not supported by the smartmeter binding.
1 Like