ZWave binding updates

I don’t have one, and my devices don’t go offline, except for a couple Enerwave motion sensors, but they stay functional even when reported as offline. I need to troubleshoot that at some point. I do recall some posts about doing something like this, using the old rule engine.

Sorry - I missed this.

However, I’m not rally sure what I’m looking for. There is nothing obviously wrong, but I don’t know what the log is showing? Is this log from before the crash (ie it finishes at the crash) or does it include the restart (ie the crash was in the middle of the log somewhere)?

If this requires a restart of OH2, I’m wondering why you think this issue is a ZWave problem rather than an OH2 problem?

Anyway, as I said, I don’t see anything really wrong in the log - all activity for just seems to stop and there are no indications of any problems or exceptions at all.

@chris, No prob. :wink:

This debug log is from the moment it just ‘died’.
I filtered some minutes from before, and a short time from after it. Else logs are about 15M big. If you want, I can search at for the moment I restarted the service. This is several hours later, so a lot of extra logs. :wink:
Sch_OnOff1 is a powered outlet. And this sends his data a lot (each 30 seconds). You can see that it just ‘stops’?

Not sure where to look for the problem/solution. I hoped that you could help me to explain the issue.

Personally I think that the problem is linked with the Virtualisation (proxmox). But till now, I just see that the zwave communication stops (knx-bindings, roomba, bosh home connect… stays working). A restart of the OH2 service solves the problem. I can’t find anything in the (system) logs that could explain it.
It just dies, and a restart of OH2 solves it.
A annoying part is that OH2 says that all things (Stick, nodes…) are online, but no data is being sent.

I’m aware of 3 other simular setups (with proxmox), and only 2 of the 4 have a simular case. That the zwave suddenly dies… On the other installation that dies, I’ve installed a new ZWave Gen5 stick, but the result was the same. So I don’t think it’s a hardware (=stick) issue.

@brononius, I have had the same problem you’re having, zwave stopping to communicate and nothing in any logs.

I’m running my openhab on a linux ubuntu 18 virtual machine using VirtualBox. The machine has got usb3 ports, so when i configured virtualbox I used the settings for usb3 from the host to the virtual machine.

I talked to a friend about my problems the recently, and he told me that he had experience of the virtualbox usb3 software had bugs in it. So I reconfigured virtual box to only use usb2 to the virtual machine. That was about a week ago and it has been 100% stable since then.

A side note: Before finding this solution I managed to make a rule in openhab that checked received packages from the zwave controller(aeotec gen5) and if there had been no packages in 5 minutes I triggered a restart of the zwave binding and if that didn’t help, a restart of openhab was triggered automatically.
I have solved the problem with my zwave usb controller changing serial port when restarting the binding that has stopped working by using a symlink (I found that help on this forum).

I don’t have USB3, only USB2. My server is a bit old. :wink:
But I’ve played around with the option USB3 ON/OFF on virtual level. But nothing changed.

What I have noticed now, is that the (virtual) server that don’t have an issue, is running on Ubuntu 16.04.1. And the (virtual) servers that have an issue are on Ubuntu 18.04.2 LTS.

I’ve got a simular script that checks incoming zwave traffic. And if no data is seen during 10 minutes, he restart his binding. Do you mind sharing your script? Sounds better with the restart of OH…

@brononius @cerebralcortex,
Can I suggest that this should be discussed in a separate thread? I don’t think this is a ZWave issue directly since the serial port is not part of the binding it’s a separate bundle, and also this issue presumably also exists for other serial based bindings running under virtual environments.

I think it would be good to have this discussion a bit more in the open than it being hidden in the middle of this large thread - then everyone can find it again in future as it seems likely others will benefit from your experience.

1 Like

Note that the next update of the ZWave binding will change the serial port system to use the ESH serial abstraction layer. This, I hope!, will continue to work normally with normal serial ports, but will allow serial-over-ip support.

I will give this a day or two before merging, but please take note. I’ll post here again before I merge and welcome any comments.

6 Likes

Awesome chris! So for those who have a Zstick on a remote IP connected machine may you provide a quick run down on what we would be required to do?

I have a need at times to connect to my ZWave controller via serial from some external tool while OH keeps running. This is to e.g. use a controller’s vendor tool to create a backup of my ZWave stick config.
For the time being I need to shutdown OH for that to work as Java owns the port.
Do you think this abstraction layer will also allow for a way to keep OH running while doing that backup ?

No - you can’t do this. Even if the abstraction was to allow this, the binding would not work. It needs to be restarted somehow if you disconnect the serial port.

See the link in the github issue I posted - it states the following -:

A client application now only needs to set the correct port name.
e.g.
* /dev/ttyUSB -> RxTxPort
* rfc2217://x.x.x.x:3001 -> TelnetSerialPort

As I said, I’ve not tested this so I can’t confirm it works, but as it’s not part of the binding there isn’t too much I can do to change it.

Does it mean you could connect through localhost:3001 with the new Z-Wave binding?

Hmmm… OK. so I think that removes 50% of the socat/ser2net solution in that nothing is needed on the OH2 side now. Does this allow the binding to recover without a restart if the binding looses access to the rfc port?

No - as stated above - if you disconnect the port, then the binding needs to be restarted. It’s not an insignificant change to the binding to change this.

OK. So what does converting to the RFC actually do? :slight_smile:

My hope and wish, was an ability to have the binding not be restarted when loss of the TCP/USB port. Sounds like this DOES allow a native connection via TCP to the Stick on another machine, so thats a big step forward.

1 Like

It allows the system to use an IP connection rather than a serial port.

That’s exactly what is implemented here - yes.

1 Like

Ill test it out when its available in the snapshot, or is it already?

No - it’s not available. Please refer to the PR I posted above. At the moment, I’ve tested it on my machine, but I’m not 100% sure if this feature has been ported over from ESH so I’m trying to clarify that (as you should see in the PR).

I was about to ask if the Z/IP ZIPR IP to Z-Wave RF bridge might work with a RFC2217 redirected port without further development, but after a quick bit of searching it looks unlikely as RFC2217 adds encapsulation for all serial signals (e.g. RTS, RI…), not just TX/RX as raw TCP would.

Personally, I’m happy using a RPi2b with a RaZberry directly connected, but there could be use cases that a remote server and local radio could be useful.

What’s RFC2217

It’s a standard to control Ethernet to Serial ports, such as to allow control of a serial device remotely via Ethernet rather than a very long serial cable.
https://tools.ietf.org/html/rfc2217

What’s a Z/IP ZIPR?

A couple of years ago, Sigma Designs released a Z/IP ZIPR Ethernet to Z-Wave radio bridge which apparently was deployed in large hotels to manage Z-Wave devices in each room.

Basically, instead of one server per room, there is one IP to Z-Wave bridge.

No - it is a completely different beast and it operates in a completely different way to the current serial API.