ZWave binding updates

Even with all the numerous “request_nif” for the zwave things, they will automatically sort themselves out?
What is the expected time frame? I have just under 20 z wave battery and power plugs things.

When the binding restarts, it goes through a process of checking if the devices are there, and then requesting their state so that it knows if anything changed. This is reasonably minimal - most of the static information that is gathered during the device initialisation is stored on disk and not requested again.

If, during this time there is a notification, then it will still be processed.

Battery devices will not complete this process for quite some time as they only wake up every hour, or every day, or… Mains devices should be quick.

Just had another ‘crash’. And a restart of OH2 works.
So not a restart of the binding, or the server, but ‘service openhab stop’, wait 1 minute and ‘service openhab start’.

@chris
Can you have a look at my 2 logs if you see anything that could explain the sudden stop? I filtered the files a bit to keep them small.
I focus on the zwave:device:30038385:node14, this is a powered outlet, that gives his status a lot. I see that the last entry was at 20:55. And after that, nothing more…

eventsCrash20180303.log (22.1 KB)

openhabCrash20180303.log (553.9 KB)

Thanks already!!!

How can I do this? Manually thing by thing via PaperUI? Is there a karaf command? Which one? Any other suggestions?

Sorry if this has been asked before. I searched for „remove“ but was not able to find an answer within more than 600 comments. Thanks for helping me out!

Frank, open PaperUi or Habmin, select the ZWave thing ie: Light Switch or Dimmer and then hit delete.

Alternatively, if you defined these using item files, delete the lines from your item files

If you have a lot of zwave Things, you may want to try this…

@dastrix80 and @5iver many thanks for your hints!

@5iver: I appreciate your rule very much but I‘m not sure if I can use it for the above descripted procedure as your rule does everything in one step while Chris wrote that I‘d have to

  1. Remove things
  2. Uninstall zwave binding
  3. Install zwave binding
  4. Discover new things
    It seems that your rule does steps 1. and 4. toegether without the chance to uninstall and reinstall the binding.

You’ll be OK doing 2, 3, 1, 4. But if you’re worried about it, comment out the discovery section in the rule to do the removal, then put it back in after the binding is upgraded to do the discovery.

If you had manually installed the binding by dropping a jar into the addond directory, don’t forget to delete the jar.

Thanks @5iver, I‘ll check that out.

@5iver
Thank you ! Will definately try out that rule, although I thankfully have significantly less than 120 zwave things.

Would you have/know a rule that will check if the zwave things give a null response, and automatically 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.