"Serial port /dev/ttyUSB0 not found or port is busy", but only periodically

Hi all. I have a USB IR Reader attached to a Raspberry PI, which works correctly with the Smartmeter binding. That is, it works correctly for a period of time before it suddenly stop working, spitting out the error “Serial port /dev/ttyUSB0 not found or port is busy”. Disabling and re-enabling the Thing doesn’t help. Restarting openhab (“sudo systemctl restart openhab”) does the trick though. This leads me to believe that it’s the java process itself that locks the port.

Any ideas on the cause of this or a possible work around (that could preferably be implemented as a rule)?

Cheers,
Jamie

Is this OH3?
There are a number of bindings showing similar symptoms, with the suspect as the underlying serial library. Example -

Have the same problem. What I do:

  1. on all serial configs in things I write down the port and change it to /dev/tty
  2. Reboot raspberry pi
  3. once OH is back up and running, change serial port config back to original settings
  4. reboot once again
    All ports are back ok

It always is java to lock the serial port on start (or whenever a binding is configured to use the port, actually).
Try to (manually in the first place) restart (in Karaf openhab console) a) the binding b) the serial transport bundle c) nrjavaserial to see if that helps.

@rossko57, Yes, OH3.

@mstormi, thanks, I’ll try these steps next time.

I think Serial ports getting blocked after some re-connecting · Issue #1842 · openhab/openhab-core · GitHub points to a probable cause and we might just have to wait for an update of NRJavaSerial

Further research shows that NeuronRobotics/nrjavaserial#111 is the most likely cause. For a proper fix, this bug needs to be solved and the smartmeter binding updated to use the new version, which can then be included in the next openhab release.

In the meantime, I’ve decided to just periodically restart the openhab service by adding the following to /usr/lib/systemd/system/openhab.service:

[Service]
RuntimeMaxSec=86400

and then running

systemctl daemon-reload
systemctl restart openhab

It’s a bit of a sledgehammer approach, but I can live without openhab during the restart period

did you try my proposal to restart the nrjavaserial bundle?

@mstormi in short, no, not completely. When the problem originally occurred, I disabled the Thing and re-enabled it, but that didn’t solve the problem. (That would be equivalent to suggestion “a”, right?)

I could wait a number of days for the problem to re-occur and try the other suggestions, but even one of those worked, I couldn’t see a way to easily detect the problem and restart a particularly component from within openhab. Hence the approach I chose (which is arguably a bad workaround, but it solves my problem for now).

Are you expecting regular meter readings or something like?
Add expire to your metering Item for period NN minutes and state UNDEF
Write a rule triggered from change to UNDEF that rings bells or sends you an email etc.

There is a scipt checking for offline Things through the api.
If yes it will restart the openhab service.
See here: