Serial ports getting blocked after some re-connecting

[fwolter]

When using the Modbus binding with OH3, the serial port with the Modbus RS485 transciever cannot be opened anymore after some time.

When the error appears, the following is printed on stdout: initialise_event_info_struct: initialise failed!

This is a known bug NeuronRobotics/nrjavaserial#111.

After compiling the native libs with DISABLE_LOCKFILES as suggested in above issue, the error is gone.

This has been discussed in https://community.openhab.org/t/modbus-binding-loses-its-serial-connection-every-few-days-without-a-reason-after-updating-to-2-5-0-release-build/89550/14

Maybe locking should be disabled in OH nrjavaserial again?

[wborn]

For me this issue is not that critical wanting to start forking nrjavaserial again. 😉 Forking nrjavaserial implies all other native libraries need to be recompiled as well (linux/armhf/arm64) and you'd have to merge any upstream changes to the fork.

[fwolter]

I understood you == me :) I'd do that if the pain gets too big. Until now there is only one user beside me facing the problem. Maybe @MrDOS manages to re-work the locking mechanism in the next time.

[jumblejj]

Hi, Also seeing this issues with OH3, see https://community.openhab.org/t/modbus-binding-not-working-on-oh3/111619

[ssalonen]

Reconnect issue discussed in more detail in this post https://community.openhab.org/t/modbus-binding-not-working-on-oh3/111619/26?u=ssalonen

It gets stuck at

at gnu.io.RXTXPort.waitForTheNativeCodeSilly(RXTXPort.java:958)

at gnu.io.RXTXPort.(RXTXPort.java:180)

at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java:983)

Looking at latest code from github, it looks like MonitorThreadLock is never "released", leading to the deadlock.

https://github.com/NeuronRobotics/nrjavaserial/blob/40587564401997d31c1f2a73b20a14cde2f04cf7/src/main/java/gnu/io/RXTXPort.java#L955

Is there workaround we could implement in the binding side?

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/modbus-binding-problem-with-serial-connection/117942/7

[ssalonen]

@fwolter could you enlighten whether the following workaround would help in the binding?

Current behaviour

• when I/O error is encountered, serial port is closed and re-opened before next retry

New behaviour

• when I/O error is encountered, serial port is kept open

[ssalonen]

Comment from user in community https://community.openhab.org/t/modbus-binding-problem-with-serial-connection/117942/8?u=ssalonen shows how frustrating the nrjavaserial issue is in practice:

I read all those threads.
I gave up with this binding. It’s not usable.

I have written my own rules to query the modbus unit using the modpoll command line utility.
Works perfectly and absolutely reliable 100%.

[fwolter]

@fwolter could you enlighten whether the following workaround would help in the binding?

Current behaviour

* when I/O error is encountered, serial port is closed and re-opened before next retry

New behaviour

* when I/O error is encountered, serial port is kept open

Could be, but I often observed the error right after the start of the JVM.

I agree that this problem is very annoying. A "quick" solution would be to disable the locks in general.

[ssalonen]

Potentially related observation with other binding (DSMR) https://community.openhab.org/t/serial-communication-stops-working-oh3/117203

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/smartmeter-binding-throws-unable-to-open-port-after-a-while/94349/20

[MikeTheTux]

I'm also affected by this problem when using the SmartMeter binding.

I'm running a total of 4 USB2Serial devices, 3 FTDI, 1 cp210x. The 3 FTDI from OH3.0.1, the single cp210x via zigbee2mqtt.

• 2 Amber USB Sticks via WMBus Binding:
  • FTDI driver
  • runs stable, no deadlocks noticed
• 1 SmartMeter Reader via SmartMeter Binding
  • FTDI driver, but other device type then the ones above
  • blocked after some days of operation

mike@nas:~$ usb-devices
T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#=  9 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6001 Rev=06.00
S:  Manufacturer=FTDI
S:  Product=AMB8465 AMBER USB Stick
S:  SerialNumber=Www
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=90mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

T:  Bus=01 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#= 12 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6015 Rev=10.00
S:  Manufacturer=FTDI
S:  Product=FT230X Basic UART
S:  SerialNumber=Xxx
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=90mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

T:  Bus=01 Lev=02 Prnt=03 Port=02 Cnt=03 Dev#= 13 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=10c4 ProdID=ea60 Rev=01.00
S:  Manufacturer=Silicon Labs
S:  Product=slae.sh cc2652rb stick - slaesh's iot stuff
S:  SerialNumber=Yyy
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=cp210x

T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#= 11 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0403 ProdID=6001 Rev=06.00
S:  Manufacturer=FTDI
S:  Product=AMB8465-M AMBER USB Stick
S:  SerialNumber=Zzz
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=90mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

Can I provide some debugging info in order to nail down the root cause?

If blocked, the only solution that I found to unblock the serial is via a restart of Openhab. Sometimes I even need to do some magic on the interface inbetween the restart. Is there a better way, without a restart of OH?

If the issue is not found, I need to go back to my previous, stable solution: read SmartMeter out via an external script and pump the data into OH3 via MQTT.

[digitaldan]

So I am seeing this as well now in the Z-wave binding on our nightlies, its suddenly stops working, hanging on this line:

2021-04-16 11:52:46.858 [DEBUG] [g.openhab.binding.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'

but i can't figure out why, other then the serial thread looks to be waiting here:

    at [email protected]/java.lang.Thread.sleep(Native Method)
    at gnu.io.RXTXPort.waitForTheNativeCodeSilly(RXTXPort.java:958)
    at gnu.io.RXTXPort.<init>(RXTXPort.java:180)
    at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java:983)
    at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:467)
    at org.openhab.core.io.transport.serial.internal.SerialPortIdentifierImpl.open(SerialPortIdentifierImpl.java:53)
    at org.openhab.binding.zwave.handler.ZWaveSerialHandler.watchSerialPort(ZWaveSerialHandler.java:108)
    at org.openhab.binding.zwave.handler.ZWaveSerialHandler$$Lambda$1283/0x00000001011f7440.run(Unknown Source)
    at [email protected]/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at [email protected]/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at [email protected]/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
    at [email protected]/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at [email protected]/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at [email protected]/java.lang.Thread.run(Thread.java:834)

Whats odd, is that if i install a fresh system, so no configuration, and add the zwave controller it seems ok, but at some point after the system runs for a while, the binding stops being able to connect after a restart. The problem i'm having is that it will no longer connect again after any amount of restarts.

I don't see other bindings competing for the port in the thread stack, so i don't have any explanation why it suddenly stop being able to reconnect, even among restarts. It's as if there is a lock file somewhere, but i don't really think thats the case.

[fwolter]

The probability this error occurs rises with the number of times the serial port is re-opened. I don't know whether the Z-Wave binding re-opens the port on communication errors, but a re-open can also be forced by EMI or bad connection between USB port and stick. You could take a look in the kernel log if there are any re-connect messages.

[digitaldan]

You could take a look in the kernel log if there are any re-connect messages.

No, there's no messages in my system logs (trust me, i have been scouring my system for clues as this has been very frustrating ), and at some point after adding enough bindings back into the mix on a clean install, this happens when OH starts so there no chance for it to reconnect, it never completes a connect in the first place.

I'm also seeing the same message initialise_event_info_struct: initialise failed! in the startup log at the same time the zwave log is printing Connecting to serial port '/dev/ttyACM0' .

I'm still messing around with adding and removing bindings to figure out the tipping point, but i'm guessing this is a race condition that gets triggered by load or binding start order as i don't have any other bindings that use the serial libraries, and it only happens as i add the 15-20 bindings i use back into my configuration.

I have also occasionally seen this message RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyACM0 right before the message initialise_event_info_struct: initialise failed! which leades me to believe nrjavaserial may not be cleaning up properly or possibly crashing at some point ?

Whats very strange is there is nothing else new here on my system, other then using the latest nightly builds.

[ssalonen]

@digitaldan the thinking is actually that the issue is with nrjavaserial alone. All you need is one binding using serial.

The way nrjavaserial is compiled for OH3 is different compared to OH2, something that might trigger this.

#1842 (comment)

I suspect that all bindings that use serial suffer from this. Since the root cause is quite intractable, I personally introduced a workaround for modbus binding that seems to help, ssalonen@1dc4094. Basically the workaround is that we avoid close/reconnect cycle with the serial port. Instead, we just keep the port open no matter what.

[fwolter]

it only happens as i add the 15-20 bindings i use back into my configuration.

My observation is, that it doesn't seem to depend on the number of bindings. I suffered from the issue with only two bindings installed (modbus and a custom) after every reboot on some days. So, the system was unsable. On other days, it worked after a reboot reproducibly for hours, days or sometimes even weeks, without changing anything.

My setup works flawlessly for months now, after disabling the locks in nrjavaserial.

[digitaldan]

@digitaldan the thinking is actually that the issue is with nrjavaserial alone. All you need is one binding using serial.
The way nrjavaserial is compiled for OH3 is different compared to OH2, something that might trigger this.
#1842 (comment)

Yeah, thats what i was trying to say, that i don't have any other serial bindings, and yes, of course I read the first comment in this issue, thanks.

My observation is, that it doesn't seem to depend on the number of bindings.

The only way this repeats for me is when my load profile changes, then its nearly 100% constant. This is at least my observation after trying this many, many times. I'm sure its probably different for others. I have no idea why that is, but I can reproduce it reliability.

My setup works flawlessly for months now, after disabling the locks in nrjavaserial.

I'm going to give that a shot as well. I'm a little concerned that this ends up becoming a bigger issue for us now that it looks to affect z-wave and other serial binding users. Was there a bump in the nrjavaserial version we think caused this? It seems to me to be a recent development.

[ssalonen]

Yeah, thats what i was trying to say, that i don't have any other serial bindings, and yes, of course I read the first comment in this issue, thanks.

@digitaldan yeah, did not mean to be snarky -- I was on mobile and missed the fact that it was indeed the first post, hah

Was there a bump in the nrjavaserial version we think caused this? It seems to me to be a recent development.

What do you mean by recent development? The "working hypothesis" is that the issue was introduced in OH3. In OH2, openHAB used a "forked" version of nrjavaserial which had the library locking feature disabled (it's a compilation flag of nrjavaserial). openHAB 3 uses upstream nrjavaserial which has the library locking feature enabled. I presume also the version has been bumped with potential changes, most likely including fixes but potentially also regressions.

I think this is the PR introducing the OH3 "locking behaviour" #1426

With the upgraded version the library will no longer crash the Java 11 VM on Windows.

The native libraries now use the built in RXTX lockfiles instead of the previously used (OS dependent) liblockdev whereas the OH build didn't use any lockfiles at all.

It seems that serial port disconnect/re-connect has been troublesome also before, see e.g.
#1503 motivated by openhab/org.openhab.binding.zwave#1338

With this version it will no longer completely exit exclamation the JVM in certain scenarios when ports are closed/reopened.

[berlic]

Hi, I'm in the same boat after upgrading to OH3. Modbus polls hangs after half a day or so. Had no problems with OH2 and the very same hardware.

Not sure if this of any help, but here are some observations.

I noticed a lot of deleted lock files for an openhab process (example):

java    9716 openhab  255u      REG       0,22         0   7911 /run/lock/tmpQtqAl9 (deleted)
java    9716 openhab  256u      REG       0,22         0   7913 /run/lock/tmp8nA4TH (deleted)
java    9716 openhab  257u      REG       0,22         0   7915 /run/lock/tmpBPaDnw (deleted)

When modbus binding hangs the total number of files shown by lsof is slightly more than 1024, so I initially thought that there might be some ulimit issue or smth; but it seems that systemd increases nofile limits for openhab process.

I tried the jar-file from #2272, and it seems that the number of lock-files is not growing. Thanks @ssalonen, I'll try it for a longer run.

After reverting org.openhab.core.io.transport.modbus back to original 3.0.1 version and watching for lsof I see additional set of lock files after every modbus transmission error like this:

2021-04-22 11:01:07.390 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint@f2a815[slaveId=109,functionCode=READ_MULTIPLE_REGISTERS,start=121,length=1,maxTries=3]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID e3a53c0e-b2fb-44b0-87a0-0d31a10bd068]

Doing inotifywait on /run/lock gives this after each error:

10:54:34 LCK..ttyUSB0 OPEN
10:54:34 LCK..ttyUSB0 ACCESS
10:54:34 LCK..ttyUSB0 CLOSE_NOWRITE,CLOSE
10:54:34 LCK..ttyUSB0 DELETE
10:54:34 tmpvviHME CREATE
10:54:34 tmpvviHME OPEN
10:54:34 tmpvviHME MODIFY
10:54:34 tmpvviHME OPEN
10:54:34 tmpvviHME CLOSE_WRITE,CLOSE
10:54:34 tmpvviHME DELETE
10:54:34 LCK..ttyUSB0 CREATE
10:54:34 LCK..ttyUSB0 OPEN
10:54:34 LCK..ttyUSB0 MODIFY
10:54:34 LCK..ttyUSB0 CLOSE_WRITE,CLOSE
10:54:34 LCK..ttyUSB0 OPEN
10:54:34 LCK..ttyUSB0 ACCESS
10:54:34 LCK..ttyUSB0 CLOSE_NOWRITE,CLOSE
10:54:34 LCK..ttyUSB0 DELETE
10:54:34 tmpmrxXDm CREATE
10:54:34 tmpmrxXDm OPEN
10:54:34 tmpmrxXDm MODIFY
10:54:34 tmpmrxXDm OPEN
10:54:34 tmpmrxXDm CLOSE_WRITE,CLOSE
10:54:34 tmpmrxXDm DELETE
10:54:34 LCK..ttyAMA0 CREATE
10:54:34 LCK..ttyAMA0 OPEN
10:54:34 LCK..ttyAMA0 MODIFY
10:54:34 LCK..ttyAMA0 CLOSE_WRITE,CLOSE
10:54:34 LCK..ttyAMA0 OPEN
10:54:34 LCK..ttyAMA0 ACCESS
10:54:34 LCK..ttyAMA0 CLOSE_NOWRITE,CLOSE
10:54:34 LCK..ttyAMA0 DELETE
10:54:34 tmpXU7dB3 CREATE
10:54:34 tmpXU7dB3 OPEN
10:54:34 tmpXU7dB3 MODIFY
10:54:34 tmpXU7dB3 OPEN
10:54:34 tmpXU7dB3 CLOSE_WRITE,CLOSE
10:54:34 tmpXU7dB3 DELETE
10:54:34 LCK..ttyUSB0 CREATE
10:54:34 LCK..ttyUSB0 OPEN
10:54:34 LCK..ttyUSB0 MODIFY
10:54:34 LCK..ttyUSB0 CLOSE_WRITE,CLOSE
10:54:34 LCK..ttyUSB0 OPEN
10:54:34 LCK..ttyUSB0 ACCESS
10:54:34 LCK..ttyUSB0 CLOSE_NOWRITE,CLOSE
10:54:34 LCK..ttyUSB0 DELETE
10:54:34 tmpaYqBMK CREATE
10:54:34 tmpaYqBMK OPEN
10:54:34 tmpaYqBMK MODIFY
10:54:34 tmpaYqBMK OPEN
10:54:34 tmpaYqBMK CLOSE_WRITE,CLOSE
10:54:34 tmpaYqBMK DELETE
10:54:34 LCK..ttyAMA0 CREATE
10:54:34 LCK..ttyAMA0 OPEN
10:54:34 LCK..ttyAMA0 MODIFY
10:54:34 LCK..ttyAMA0 CLOSE_WRITE,CLOSE
10:54:34 LCK..ttyAMA0 OPEN
10:54:34 LCK..ttyAMA0 ACCESS
10:54:34 LCK..ttyAMA0 CLOSE_NOWRITE,CLOSE
10:54:34 LCK..ttyAMA0 DELETE
10:54:34 tmpdg0Vcr CREATE
10:54:34 tmpdg0Vcr OPEN
10:54:34 tmpdg0Vcr MODIFY
10:54:34 tmpdg0Vcr OPEN
10:54:34 tmpdg0Vcr CLOSE_WRITE,CLOSE
10:54:34 tmpdg0Vcr DELETE
10:54:34 LCK..ttyUSB0 CREATE
10:54:34 LCK..ttyUSB0 OPEN
10:54:34 LCK..ttyUSB0 MODIFY
10:54:34 LCK..ttyUSB0 CLOSE_WRITE,CLOSE
10:54:34 LCK..ttyUSB0 OPEN
10:54:34 LCK..ttyUSB0 ACCESS
10:54:34 LCK..ttyUSB0 CLOSE_NOWRITE,CLOSE
10:54:34 LCK..ttyUSB0 DELETE
10:54:34 tmpKBd8W7 CREATE
10:54:34 tmpKBd8W7 OPEN
10:54:34 tmpKBd8W7 MODIFY
10:54:34 tmpKBd8W7 OPEN
10:54:34 tmpKBd8W7 CLOSE_WRITE,CLOSE
10:54:34 tmpKBd8W7 DELETE
10:54:34 LCK..ttyAMA0 CREATE
10:54:34 LCK..ttyAMA0 OPEN
10:54:34 LCK..ttyAMA0 MODIFY
10:54:34 LCK..ttyAMA0 CLOSE_WRITE,CLOSE
10:54:34 LCK..ttyAMA0 OPEN
10:54:34 LCK..ttyAMA0 ACCESS
10:54:34 LCK..ttyAMA0 CLOSE_NOWRITE,CLOSE
10:54:34 LCK..ttyAMA0 DELETE
10:54:34 tmpZ5hVCS CREATE
10:54:34 tmpZ5hVCS OPEN
10:54:34 tmpZ5hVCS MODIFY
10:54:34 tmpZ5hVCS OPEN
10:54:34 tmpZ5hVCS CLOSE_WRITE,CLOSE
10:54:34 tmpZ5hVCS DELETE
10:54:34 LCK..ttyUSB0 CREATE
10:54:34 LCK..ttyUSB0 OPEN
10:54:34 LCK..ttyUSB0 MODIFY
10:54:34 LCK..ttyUSB0 CLOSE_WRITE,CLOSE

Not sure why it does something with ttyAMA0, as I only use ttyUSB0 for RS485 communication.

[MrDOS]

Hey, as an NRJavaSerial contributor, I feel like I owe you folks my $0.02 on the underlying library issue at play here, and what I intend to do about it. My 👀 response to @fwolter's comment back in November was supposed to indicate that I was aware of the issue, but as time wears on, I think that response comes off as a bit too glib.

I noticed a lot of deleted lock files for an openhab process (example):

NRJavaSerial leaks the file descriptors for its lockfiles. I haven't hunted down where, exactly, but it seems to unlink(2) (or equivalent) the lockfile paths without close(2)'ing the open descriptors. (In your inotifywait output above, you can see that some of the files are opened twice, but only closed once.) As you're finding, this eventually gums up the works for itself and other file access done within the same process. It's been a while since I was last able to look at this, but IIRC, this manifests as an initialization error (initialise_event_info_struct: initialise failed!) and not a file open error due to limitations surrounding select(2) and FD_SETSIZE. The file can open: with an increased ulimit, you can open more than 1,024 (FD_SETSIZE) files. But the files are opened with large file descriptor numbers (>1,024), and so when the library tries to use the serial port, it calls FD_SET() with that larger-than-FD_SETSIZE descriptor, and encounters an error. The library solution is for us to use the newer poll(2) instead of select(2) – and to not leak file descriptors like a sieve in the first place.

This is why building NRJavaSerial with locking disabled circumvents the problem: no leaked lockfiles means no high file descriptor numbers, means select(2) is happy, and means no random initialization crashes.

New behaviour

• when I/O error is encountered, serial port is kept open

Retaining/reusing old file descriptors (by reusing port objects) will avoid this problem, yes. Unfortunately, it can be really hard to distinguish when this is safe to do so: was the I/O error directly relating to the port hardware, e.g., a USB-to-serial dongle being disconnected, or was it a protocol error/unresponsive device on the far end? If you can rearchitect openHAB to continue to use old ports, you'll still eventually be unable to open new ports, but you can keep using the ones you already have open. It would be a pretty clumsy workaround for a problem you shouldn't have to deal with, but it should help.

Not sure why it does something with ttyAMA0, as I only use ttyUSB0 for RS485 communication.

As part of enumerating available ports (CommPortIdentifier.getPortIdentifiers()), NRJavaSerial tries to open each device in turn to confirm that the port is accessible to the current user. As far as I can tell, there's no valid reason for it to open the port to do the access check instead of just... performing an access check (i.e., via access(2)). But on top of that, it doesn't just open(2) the port – no, it goes through the entire usual rigmarole of locking/unlocking the port, too. So because port locking/unlocking leaks file descriptors, every port enumeration operation leaks file descriptors proportional to the number of serial ports attached to the system.

This is pretty high on the list of things I'd like to fix in NRJavaSerial. Unfortunately, the road to hell being paved with good intentions and all that, I haven't gotten to it yet. Hopefully I can soon.

What does the release cycle for look like, by the way? Do you issue updates on an as-available basis, or is there a release window you try to hit? Obviously you'd like this fixed in NRJavaSerial ASAP, but is there a time (other than “yesterday!”) when it would be optimal to receive a fix by?

[fwolter]

Thanks for your explanations!

port locking/unlocking leaks file descriptors, every port enumeration operation leaks file descriptors proportional to the number of serial ports attached to the system.

IIRC, openHAB also enumerates the serial ports each time you open a configuration UI containing a serial port.

The openHAB minor release cycle is twice a year, I think. In any case, the next release will already be in May.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/serial-port-dev-ttyusb0-not-found-or-port-is-busy-but-only-periodically/121464/5

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/z-wave-controller-offline-after-power-failure/125964/2

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh3-1-out-of-memory-error/126929/45

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh3-x-alternative-java-serial-provicer/128462/1

[JensHoRi]

A question from my site:

Would there be a work-around, restarting some bundles or features directly within karaf console?

Does anybody know?

[wborn]

As workaround you can for instance update the nrjavaserial bundle to a snapshot build.

To update the bundle on the Karaf Console to a snapshot build with the fix (in my fork) use:

bundle:update nrjavaserial https://github.com/wborn/nrjavaserial/releases/download/5.2.1-20220113/nrjavaserial-5.2.1.202201130000.jar

[JensHoRi]

Thanks for all your work. Just did and will report how it goes ;)

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/problem-with-setting-up-zooz-usb-z-wave-plus-s2-stick-zst10/134603/73

[JensHoRi]

Snapshot seems to work. No problems until yet, USB-devices all still on and running :-) Great work

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh3-x-alternative-java-serial-provider/128462/5

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/aeotec-z-wave-gen5-stick-stays-offline-after-container-restart-raspi-reboot/136990/5

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/aeotec-z-wave-gen5-stick-stays-offline-after-container-restart-raspi-reboot/136990/23

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/aeotec-z-wave-gen5-stick-stays-offline-after-container-restart-raspi-reboot/136990/25

[Mr-jreeves]

I am experiencing this same issue on OpenHab 3.4.0 Build #3029. The Zwave process stops at:

2022-08-03 07:02:21.029 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyUSB0'

and the syslog at the same time shows:

Aug 3 07:02:21 openhabian karaf[955]: initialise_event_info_struct: eis->fd >= FD_SETSIZE!

I have found that this problem is intermittent. I have only seen this when rebooting. Sometimes it happens, sometimes it does not. I doubt this is related, but the times, so far, that I have made it work is when I disconnect the Pi4 from power, and remove the Ethernet cable and let the system sit for 5 minutes ... (sounds like black magic so likely just coincidental)

This never happened when running OpenHab 3.2.0.M4.

I have confirmed I am running:

308 │ Active │ 80 │ 5.2.1.OH1 │ nrjavaserial

This is very repeatable (and annoying since it can take some tries to get the system up) ... I can help with some logs if more information is needed.

This problem has been discussed in this case:

https://community.openhab.org/t/zwave-bridge-wont-go-online/137521

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/zwave-bridge-wont-go-online/137521/24

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh3-x-alternative-java-serial-provider/128462/13

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/aeotec-z-wave-gen5-stick-stays-offline-after-container-restart-raspi-reboot/136990/29

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/aeotec-z-wave-gen5-stick-stays-offline-after-container-restart-raspi-reboot/136990/30

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhabian-rpi4-zwave-gen5-falls-offline-on-restart/146694/46

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/is-smartmeter-reading-over-serial-interface-recommended/150912/1