No, I’m talking about starting the binding over the karaf console.
After you connect with SSH to your system, enter:
ssh -p 8101 openhab@localhost
The password is: habopen
bundle:list
and find the z-wave binding.
bundle:restart <number of binding>
and it will restart.
In this console, you also can set the debug level for the z-wave binding:
log:set debug org.openhab.binding.zwave
don’t forget to set it back to info, after you’re done debugging:
log:set info org.openhab.binding.zwave
I would not recommend restarting the binding - it will generate a lot of network traffic and is totally unnecessary.
Tried this, did not help as far as i can see. Also, debug creates a wall of text, impossible to follow, or look at afterwards, unless one knows what to look for.
It is node 6, is it some keywords i could look for to get going, inside the logfile?
Please run the Karaf console as described here.
First let’s find out which version of the binding is running. Please report what version you’re on.
list -s | grep zwave
Now let’s put the zwave binding in debug mode.
log:set DEBUG org.openhab.binding.zwave
Now, let’s look at the log while you wake up the device.
Assuming you’re on a Linux variant… At the shell prompt in the logs directory type the following
tail -f openhab.log | grep "NODE 6:"
Now wake up the device and report back what you see.
Thanks.
I first did an exclusion of the device, and then i did a hard reset of the zstick (aotec).
Did a new inclusion, and i put the remote very close to the stick. For the first time the remote gave an ack by blinking green. I can now press a button and there is some reaction. Looks like the system is queueing up some requests, and as far as i can interpret it is talking to the device.
I just kept pressing the button when the log indicated device was sleeping. Then, after a while, there was possible to set an wakeup time/interval in habmin. It was “0”, i set 10 seconds, hoping this would mean it would stay awake long enough to exchange some information.
Kept pressing a button from time to time, and suddenly something “came loose” and the system looked like it was creating the device, i think it had enough info to detect it, and create it.
The main thing i did was reset the zstick, so it forgot what it had seen of the remote, and also forgot the fibaro dimmer2. Then i did a new scan, initiating the inclusion mode on the remote a couple of times, close to the stick, until it acked with a green blink.
I dont know what and if something was wrong, log was too fast for me to recognize something obvius.
This probably was not necessary.
This is a very short wakeup interval. It likely will drain your battery rapidly. 
Generally, a “good” wakeup interval is 3600 to 14400 seconds, depending on how much you want to conserve battery life.
if you post your openhab.log, we can take a look at what actually happened. The log likely is too big to post on the forum, so you would need to post to a sharing service like Dropbox, Google Drive, etc.
Edit: If you’d rather not post the log, you can use @chris log viewer to better see what was happening.
https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer
Hey @chris. Can you take a look at this log from @kimhaak?
https://1drv.ms/u/s!Ag4TtT27NXy2g_0H4yqBUdqm4kgCfA
Node 3 is showing tons of these retires/timeouts, which appears to what’s interfering with the initialization process.
By waking the device many times, it looks like initialization completed. But, the above-mentioned errors made initialization take much longer than normal.
BTW, @kimhaak can’t post anything for a while due to some new user post throttling.
Now i am blocked from making new messages as well, need to wait 12 hours for new topics…
This was my last reply. I need to go to bed now as well, thanks for all.
Response to last pm:
Its a full stack trace. It also happens if trying to edit properties in habmin.
I can copy the trace to:
https://1drv.ms/f/s!Ag4TtT27NXy2g_0Ge3H6vDkJQZwOOA
I am using a snapshot, så this might be related. I can try to downgrade, if possible, maybe even reinstall to stable version.
No worries. Just give the account some time so that the new user throttling expires.
No need to downgrade. I don’t think that will help. In fact, it might hurt. 
It looks like the binding is still sending requests when the device is asleep and they are failing - I don’t know why this is, and really can’t look for this in the old binding.
My suggestion is to change to using the development branch - then if there is any such error we can actually look for it.
The development branch can be found here -:
Alternatively, this will be merged in a week or so if you prefer to wait.
Yeah, good point. That seems to make the most sense.
I’ll try to do that. Maybe it will take care of the 500 server error as well 
Hi,
I am on the latest snapshot build, and the jar installer you provided in your link, looks to be the same as i am running, and which the logs come from.
http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar
No - it’s not the same version - at least the logs that are provided above are definitely not from the new version of the binding. If these are not the logs, then maybe I’m looking at the wrong ones?
The logs i provided is from my box. The box is running snapshot/nightly build.
How can i verify between versions? Because the installed binding, according to the gui, is 2.4.0, and it was yesterday also.
This is from bundle:list:
191 │ Active │ 80 │ 2.4.0.201808271627 │ ZWave Binding
Attached is gui info.
If you can see it in PaperUI, then you do not have the development binding installed. If you’d like to give it a try, this script should do it all for you…
Then this is not the version that is referenced in the above post.
Please just use the version in the post I referenced above.
The file names are not so relevant. All snapshots have the same name, but they can be different (it’s the nature of the build process).
Thanx
Will this work on openhabian? In regards to paths where files are stored etc.
Ok, now we are getting there! Used 5iver’s script, wich worked just fine. Deleted my things, and rediscovered them. Now i dont get the 500 internal server error while editing the remote 
I can even control my first lamp
Ok, so then i guess i will have to go on to the next step, integrate more stuff, and figure out the logics
Thank you all!
