Welcome back @chris
I am still trying to Identify the cause of Those hick ups with Rejects and CANs in my Network and esp. With Qubino Dimmers.
Anything in my log in above post that would Look Strange to you?
Thanks and Cheers
I’m not really sure what is happening…
In the above code, there should be an ACK almost immediately after a frame is sent. This doesn’t get received, so the binding aborts the transaction. This abort does get an ACK!
This happens a few times, so I’m it’s not just a one off. 
Have you reset the controller (ie removed the stick and put it back, and restarted the binding)? It’s about the only thing I can really think of to do as I’m not sure what would cause the controller to not respond with the ACK.
did soft reset and restart of the bundle.
now I additionally swapped usb ports.
looks better currently. fingers crossed
1 Like
I’m using 2 USB Gen5 Sticks. And my OH server is running virtual (by HV Proxmox).
A lot of bindings (knx, zoneminder, bosch, zwave…). I’m using a recent version, namely 2.5.0.M1
Zwave has about 55 nodes over the 2 sticks (2 different buildings).
And everything is running smooth. For a while…
Suddenly, a zwave stick (or network?) suddenly stops working.
Nothing in the logs that could explain it. It just stops sending traffic it seems. In PaperUI, everything stays online. And that’s a bit annoying, since I can’t trigger a rule on this to restart it automaticly. 
Something it runs for 1 days, sometimes for 3, sometimes for… Sometimes it’s stick 1, sometimes it’s stick 2. Not really an logic in it…
Any idea what I could try next?
Just had another crash. I thought I had the logs on debug, but seems it’s not.
In the console, I’m haveing: log:set DEBUG org.openhab.binding.zwave
@chris, any idea what I’m doing wrong?
I’ve got 4 installations running today in a simular way (HV: proxmox, VM: openhab 2.4, Zwave stick). And 2 (zwave) are crashing almost once a week. Only a reboot helps to have zwave online again. A restart of the binding itself doesn’t work.
Not really, but there’s not a lot to really go on. If only a reboot is resolving this, then I would suggest that it’s not the binding, but possibly the serial driver or something in the virtualisation, but that’s just a guess with pretty limited inputs…
Is there by the way any chance to improve the serial driver? This is the most unreliable part in my Z-Wave network(s). As I am using multiple controllers and some of them via USB over IP I get them sometimes to stop working just because the connection is lost for a couple of seconds. They do not recover by themselves in OH without restarting the binding (vie Karaf console), athough they are again connected with the same COM Port on the OH server.
Well, first you would have to know what is wrong, but this is not part of the binding, so you’d need to look at the driver itself I think.
Probably then the issue is related not to serial port, but to the serial IP emulation?
This is not what is stated above - above it states that a REBOOT was needed to get it working again.
What is the component that the binding is using here?
The same problem also occurs if you pull out the stick from the real physical serial port for 1 second and plug it back in. Then the connection is permanently lost unless the binding is restarted. So it is not a question of serial IP but of the handling of short contact losses in general (by either the binding or the driver).
So if it is not the binding where would be the piece of code to look at?
The serial driver (NrJavaSerial from memory).
Yes, if you remove the stick, it will stop working 
. I’d suggest not to do that - there is no need to do it, and it causes problems, as you are finding.
I think you are now talking about a different issue than was discussed above. The comment above said a reboot was needed, and this is likely an issue with the serial driver. You are talking about removing the stick and putting it back - this is simply something the binding doesn’t support, and it’s not trivial to add this.
hmmm, Seeing the remarks of vossivossi, maybe I should also check if a ‘complete OH’ restart give other results. Today, I’m restarting the binding, or the server. Not openhab. I will try this with the next ‘crash’.
Else I’ll try to figure out the serial path… Not sure how to start this, but step by step. A bit weird that 2 other installations (same proxmox version (=hypervisor), same ubuntu version (=virtual machine), same USB stick) don’t have the issue.
Do you’ve an idea what’s wrong with my ‘log’ settings? Seem I can’t activate the debug log…
I’ve tried with:
log:set debug "org.openhab.binding.zwave"
log:set debug "ZWave Binding"
log:set debug "245" (=zwave id)Use -:
log:set debug org.openhab.binding.zwave
ie - no quotes.
Strange, but this isn’t working. Just normal logs, no debugs…
Am I maybe missing someting in my logger?
openhab> log:list
Logger │ Level
──────────────────────────┼──────
ROOT │ WARN
org.apache.sshd │ WARN
org.openhab.binding.zwave │ DEBUG
How are you viewing your logs? By default, logs are written to two files, OPENHAB_USERDATA/etc/logs/event.log and openhab.log. Also by default, the zwave binding will log to the openhab.log. If you’ve modified org.ops4j.pax.logging.cfg to add additional appenders, then there may be other files in other locations.
But it looks like your logging has been heavily modified from the default, since there should be a lot more in there. You may need to restore the file to the one from the distrobution.
1 Like
Indeed, after recopying the original file, debug logs are properly now!
Thanks!!!
1 Like
How do you restore the entire z wave network readings when one downs OH (eg backup of the VM )?
It seems like everytime I restart OH, I get all these request_nif which is quite frustrating, even though OH was down for just a few minutes
You don’t have to restore anything - the system will sort this out. The devices will be available for almost immediate use once the binding starts up.
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.