OH2.1 - zwave I/O error after plugging back in

Not a major issue, just an annoyance…

If I remove USB ZWave stick (aeotec z-wave gen 5) in order to go include a new zwave device, then plug it back in, then go and do a search for things under the zwave binding under PaperUI, I get the following generated in the openhab.log. It’s fine if I go and reboot (or restart) openhab, but should it not be able to recover from this?

2017-07-12 16:59:16.903 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-07-12 16:59:21.920 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-07-12 16:59:26.933 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-07-12 16:59:31.946 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-07-12 16:59:37.003 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-07-12 16:59:42.022 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-07-12 16:59:47.035 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-07-12 16:59:52.048 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-07-12 16:59:57.064 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.

1 Like

In my view, this is an operating system issue. The USB port needs a small kick sometimes when you put back the Z-Stick in your system. I think that the problem is that unplugging the Z-Stick without notifying the system of the removal in advance gets the port stuck (? or something similar :slight_smile:)

Try the following linux command after you re-introduce the Z-Stick in the USB port of your system:

udevadm trigger

I haven’t tried it with OH2 running… maybe it will work.

Thanks. As above, I’ll reword in that it only comes right after a reboot. Restarting OH doesn’t resolve.

You might be right though, in HABMin it shows below the Z-Wave Serial Controller “zwave.thingstate.serial_notfound”

I started doing network inclusion so I don’t have to remove the stick anymore…works like a charm and prevents that exact issue from occurring.

I accomplish Network Inclusion by shutting down OH and then starting the Zensys Z Wave controller software (it’s free) with one click I can put the system into Network inclusion and join the device wherever it is, leaving the USB stick plugged into my OH server. From the Zensys application you can also have the device update their neighbors.

1 Like

do you get any info in dmesg?
it should say something like:

[94521.140936] usb 5-1: USB disconnect, device number 2
[94540.446004] ehci_irq: port change detect
[94540.575920] ehci_irq: port change detect
[94540.925375] usb 5-1: new full-speed USB device number 3 using sw-ohci
[94541.121095] cdc_acm 5-1:1.0: This device cannot do calls on its own. It is not a modem.
[94541.130311] cdc_acm 5-1:1.0: ttyACM1: USB ACM device

sometimes, the /dev/ttyACM0 may change to /dev/ttyACM1 when replugging

udevadm trigger should deal with that (I hope)… I will try this now in my system and report back :slight_smile:

I suspect you’re right again :slight_smile:

I’m assuming dmesg is sequential output of system events… shows ttyACM1, so I unplugged and plugged back in, changes back to ttyACM0 (which is correct) I then run udevadm trigger and wait a little bit and voila, it comes back to life in HABMin!

[ 6587.945000] usb 1-1.5: USB disconnect, device number 3
[ 6639.490000] usb 1-1.5: new full-speed USB device number 4 using ehci-platform
[ 6639.600000] cdc_acm 1-1.5:1.0: ttyACM1: USB ACM device
[ 8349.395000] usb 1-1.5: USB disconnect, device number 4
[ 8352.760000] usb 1-1.5: new full-speed USB device number 5 using ehci-platform
[ 8352.865000] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device

Thanks!

1 Like

upon Z-Stick disconnect while OH 2.2.0 snapshot build #983 running:

dmesg:

[1087987.116514] usb 1-1: USB disconnect, device number 2

ZWave.log:

08:26:42.033 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.

upon Z-Stick reconnect:
No dmesg entry, LED on Z-Stick stays off…

Issue: udevadm trigger, stick comes alive (LED ON)… but…

dmesg:

[1088309.283278] usb 1-1: new full-speed USB device number 5 using xhci_hcd
[1088309.468330] usb 1-1: New USB device found, idVendor=0658, idProduct=0200
[1088309.468343] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1088309.469080] cdc_acm 1-1:1.0: This device cannot do calls on its own. It is not a modem.
[1088309.469975] cdc_acm 1-1:1.0: ttyACM1: USB ACM device

So: Port changed… ZWave.log is configured with ACM0 and as a result, it is still spitting errors when trying to search for things… next step :slight_smile:

Unplug again Z-Stick, replug, rerun udevadm trigger: again ACM1 :frowning:

Stop OH2, rinse and repeat: back to ACM0

So… it seems that with OH2 running, the /dev/ttyACM0 is kept and doesn’t come back with udevadm trigger
You will need to stop OH2, run udevadm trigger and then start it.

1 Like

How did you get it to change back to ttyACM0 with OH2 running?
I couldn’t… :frowning:
I had to stop the OH2 process to “release” the port

Yeah I didn’t need to restart OH which was convenient. I assume OH (or the zwave binding) didn’t manage to hold the port open (based on the initial error that showed “zwave.thingstate.serial_notfound”) Or perhaps it was just a timing issue?

I’m running OH2.1 snapshot release. Didn’t know 2.2 was out. I can do an apt-get and upgrade it, see if I get the same results :wink:

(I run OH on an NTC CHIP, running Debian Jesse)

2.2 is the latest “unstable” snapshot (it was renumbered after 2.1 Release Build was published)
btw, I don’t consider it unstable… it runs fine without any problems.
I am always on Snapshots since I want to try the new features immediately as they come out :blush:
My system is a HP Laptop (Intel CPU i5-6200U, 8GB RAM, 1TB HDD, Linux Debian Jessie)

If I understand correctly, you are removing the USB stick while the binding is running? You then plug it back in and expect the system to recover? If so, then no, it won’t recover from this - you need to restart the binding.

good point! no need to restart the entire openHAB process… just the Z-Wave binding (maybe with bundle:restart in the openHAB console)

I got this error back tonight “out of the blue” - but under different circumstances, this time the only change an apt-get update/upgrade about 8 hours earlier. When this error occurs, all zwave devices stop responding in the OH2 GUI. A reboot is only thing that resolved it.

[ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.

This error is likely coming from the hardware or low level drivers - there’s not a lot the binding can do about this I’m afraid…

Thanks for the super fast response Chris. I’ve suspected for quite a while that the device I’m running OH on is well under spec’d. Time to move to Rpi I think.

the binding could restart itself if it got an error related to the serial port - ofcourse it should not try it to often

but people do expect usb to be hot plugable