I’ve created a new TEST binding here. This has some changes that might cause problems as I’ve made some mods to change the way dead nodes are handled and messing with the low level transaction code is always a little dangerous.
If you’re feeling adventurous, then please feel free to give it a go and report back 
. This is one of the last major changes I want to make before I can merge the dev binding into master so it would be good to iron out any issues…
testing now
quick question: Is the Bridge name editable?
I see zwave:serial_zstick:512 but I can’t change the 512 part.
If I remember well, I was able to specify the bridge name (I have all my items linked to channel names)
Maybe I am doing something wrong 
OH 2.4 S1292
You can set it on startup, but I’m not sure you can go around changing it (I think it’s meant to be immutable). This isn’t anything to do with the binding though - it’s up to the core…
Correct. Maybe something changed in OH 2.4 core… If I remember well, I was able to modify that part. Anyway… no worries…
Continuing the tests now
I did a quick test and half of my devices, even mains powered, were reported as dead. Had to roll back due to house guests, but will test more (and get some logs) over the weekend.
Quick question: does the latest 2.3 version (from the top of this thread) work with 2.4 snapshot?
In other words is it safe to upgrade to OH 2.4?
I mean are there any breaking changes in 2.4 core? I did upgrade to 2.4, but zwave did not resolve due to missing guava dependencies. I know there was a plan to remove guava from OH, so maybe this happened in 2.4?
Yes.
Remember - all that is changed is the number… Last week it was numbered 2.3, now it’s numbered 2.4. It’s still basically the same thing…
Really - I’ve not seen that issue. ZWave doesn’t use guava so I don’t know why this would have been the case 
. There were some other missing dependencies relating to UoM and USB, but that was due to new features and these are in 2.4 anyway.
That’s what I thought.
It has been mentioned in this thread too. But it wasn’t an issue with the binding itself, it was enough to just reinstall it. I will do that today, yesterday it was really late, so I just gave up. Now that you confirmed it should work, I will try to reinstall the binding, hopefully all the issues will gone. 
I think that was a change of ESH - they changed a definition of a protected field from static (from memory) and that made it binary incompatible, so needed to be reinstalled. At least that wasn’t guava related, but maybe there was something else that I didn’t know about… If I search this thread for guava, there is basically nothing other than our mails this morning (and one message from 12 months ago which is I think unrelated).
I think it’s ok in any case 
.
Search for com.google.common.collect, this is what I meant. I assume this package is part of guava library…
Again, this is all from a LONG time ago - well before 2.2 was released, let alone 2.3…
That’s true, but this is what got yesterday. Strange, but true… 
Tested today with openHAB build #1292 (2.4 snapshot).
All devices are online and seem to work properly.
Debug log provided through website ticket.
It still is possible to modify it. It am running OH 2.4 1292 and named it.
Where? When it appears on the Inbox I can only set the label.
I have also tested the new version and so far it works well. The only thing is additional controller in the inbox. I have one defined in .things file, but the binding discovers it anyway and put it in the inbox. I think it didn’t happen in previous versions, but I may be wrong.
Thanks for the feedback. The discovery issue is due to the new USB controller discovery feature in Linux which was not in the previous versions (as you suspected ).
That’s right! Before the controller has to be added manually, I completely forgot about it.
I have tested and this seems to be working better than the version at the top of the thread. All my zwave devices (except for the locks that I have not tried to add back in) are connected and working. I am running OH 2.3 stable. The zwave snapshot version would get stuck on REQUESTING_NIF and various other states and I would not be able to control any zwave devices.
I will try adding the locks back in today and see how that works out.
Thanks for the feedback. The changes made are only to the way transactions are processed, and DEAD node states decides, so hopefully the security features shouldn’t be affected…
I’ll await the confirmation though