In my testing I found things usually worked when starting OH but failed when a binding was restarted. It could not find the serial port.
Bundle Management
a vendor and technology agnostic open source automation software for your home
In my testing I found things usually worked when starting OH but failed when a binding was restarted. It could not find the serial port.
Are you running the latest version of the binding?
Is nrjavaserial (bundle) running in openHAB?
Yes it is the latest version and yes it is runing:
openhab> bundle:list -s | grep serial
259 β Active β 80 β 3.14.0 β com.neuronrobotics.nrjavaserial
260 β Active β 80 β 3.15.0.OH2 β com.neuronrobotics.nrjavaserial
261 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.discovery.usbserial
262 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.discovery.usbserial.linuxsysfs
263 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.serial
264 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial
265 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial.rxtx
266 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial.rxtx.rfc2217
Why are there 2 versions running?
Iβm out of ideas and time this morning. Maybe try searching the forum for βserial port not foundβ or similar, not involving MySensors.
@CrazyIvan359 as mentioned by @Bruce_Osborne
Try using the console stop/remove one of them, could be a conflict not seen in logs, see if that helps.
They may need to restart OH too? I duobt just stopping a bundle would be sufficient. Is there a way to stop a bundle from auto-starting with OH?
Not that I know of.
Just pick the one you want to use, then from the console use
bundle:uninstall to remove the other.
With the extra complexity I would try a few things to troubleshoot. First - if you donβt have it already Iβd grab the Portainer docker app and run it. This is a web admin GUI for docker and it will allow you to not only edit / redeploy current containers but also enter a command shell within the container itself. This way you can confirm the serial port is there and accessible within the container. If all is well there then you can go on to troubleshooting openHAB. When jumping into the container you can go in as root so all permissions should be fine - as long as docker is running as a user with access to the ports. From what I see In your config Iβd just confirm that you have the group IDs matching and openhab is running as a user with access to the tty ports
When I do this both bundles will disappearβ¦
openhab> bundle:list -s | grep serial
261 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.discovery.usbserial
262 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.discovery.usbserial.linuxsysfs
263 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.serial
264 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial
265 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial.rxtx
266 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial.rxtx.rfc2217
278 β Active β 80 β 3.14.0 β com.neuronrobotics.nrjavaserial
279 β Active β 80 β 3.15.0.OH2 β com.neuronrobotics.nrjavaserial
openhab> bundle:uninstall com.neuronrobotics.nrjavaserial
openhab> bundle:list -s | grep serial
261 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.discovery.usbserial
262 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.discovery.usbserial.linuxsysfs
263 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.config.serial
264 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial
265 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial.rxtx
266 β Active β 80 β 0.10.0.oh240 β org.eclipse.smarthome.io.transport.serial.rxtx.rfc2217
Use the bundle number 278 or 279 to identify the one to remove. a vendor and technology agnostic open source automation software for your home
Bundle Management
With the extra complexity I would try a few things to troubleshoot. First - if you donβt have it already Iβd grab the Portainer docker app and run it. This is a web admin GUI for docker and it will allow you to not only edit / redeploy current containers but also enter a command shell within the container itself. This way you can confirm the serial port is there and accessible within the container. If all is well there then you can go on to troubleshooting openHAB. When jumping into the container you can go in as root so all permissions should be fine - as long as docker is running as a user with access to the ports. From what I see In your config Iβd just confirm that you have the group IDs matching and openhab is running as a user with access to the tty ports
I already use Portainer and yes I can connect to the docker container and can manualy read from ther serial port by using cat /dev/ttyUSB0
Use the bundle number 278 or 279 to identify the one to remove.
Bundle Management | openHAB
Ok that worked one of the bundles is now removed however still no luck
15:36:03.098 [ERROR] [ocol.serial.MySensorsSerialConnection] - No such port: /dev/ttyUSB0
gnu.io.NoSuchPortException: null
at gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:273) ~[283:com.neuronrobotics.nrjavaserial:3.15.0.OH2]
at org.openhab.binding.mysensors.internal.protocol.serial.MySensorsSerialConnection.establishConnection(MySensorsSerialConnection.java:51) [275:org.openhab.binding.mysensors:2.4.0.201812040738]
at org.openhab.binding.mysensors.internal.protocol.MySensorsAbstractConnection.connect(MySensorsAbstractConnection.java:148) [275:org.openhab.binding.mysensors:2.4.0.201812040738]
at org.openhab.binding.mysensors.internal.protocol.MySensorsAbstractConnection.run(MySensorsAbstractConnection.java:127) [275:org.openhab.binding.mysensors:2.4.0.201812040738]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Did you restart OH after removing the bundle?
yes of course