The thing has been deleted and discovered several times, but the device hasn’t been reincluded, so lifeline configuration has not been touched since then. I added this device to OH1.x first time, then migrated to OH2 etc, but from the controller perspective nothing has changed, maybe some config params, but not associations.
OK. Just wanted to be sure you didn’t miss that step in the upgrade. Have you tried deleting and rediscovering since you last updated the binding? This works for me with my dimmers and switches.
4 days later: all is good
Things stay Online in PaperUI and report data as scheduled.
I removed the battery from one Z-Wave node on purpose and it got reported as Offline after a while (same behavior as the master branch).
1 Like
I don’t think this is relevant, just this one device I reincluded stopped sending reports, also in .xml file association map is empty and after analyzing log it shows that there is a problem with command class version.
Additionaly after reincluding the device got discovered as a new one with new node ID, so it is a new thing anyway.
Quick question on the last update for the development version of the zwave binding 04th June:
Is there still a difference between the “test” version of the binding mentioned here or are they the same now?
They are different - the version at the top of this thread uses the same concept for dead nodes as it always has…
Just to add - I decided to keep them separate to avoid everyone changing concepts while I/we were still testing 
.
1 Like
Makes sense 
BTW, test version is running now for a few days without any issues. 
1 Like
Hello,
Is the zwave 2.3.0 stable binding buggy ?
I was using 2.3.0 SNAPSHOT dev version of the zwave binding that was fully fonctional before the stable release of 2.3.0 and all was going right.
I then updated to 2.3.0 stable for both openhab and the zwave binding. Everything runs fine excepting the zwave binding. I find in particular in the logs “… nonce that is unknown to us”.
Everything is allright again if I use the last zwave snapshot (june 2018, on top of this topic).
Wouldn’t it be nice to provide a fully functional stable binding in the 2.3.0 stable release ?
Regards,
Romain
No - there has been very little change to the binding for a long time. I don’t think it is buggy. If you have a problem, then please provide information on what is wrong - just saying it’s buggy doesn’t really help.
If you are swapping back and forward between the two versions, then it will likely not work. The two bindings are not compatible. If you swap versions, you will need to delete your things and add them back.
If you have included secure devices, they will NOT work with the stable version as the stable version doesn’t support security. Hence the development version.
Of course - I believe that it is stable. As above, if you have a bug to report, then please provide details of the problem.
Hi Chris,
Thank you. I was thinking that the fresh openHAB 2.3.0 stable release (28 mat 2018) embedded the last zwave snapshot binding available before this date. I did not understand that you maintain a stable version without security. I think the version with security has been stable for weeks in my context and it was obvious for me that such a good stuff would be promoted to stable !
So, no bug to report. And many thanks for your work.
Regards,
Romain
Well, for me it does not make sense. First the device lists ASSOCIATION in supported command classes, after that it requests to remove this command class returning version “0”. For sure this is a bug in device’s firmware, but I’d like to solve somehow it.
Here is some code to override command class version but I am not sure how to use it. I assume some properties must be added to the database, but any hint would helpful.
I agree - it’s not meant to do this.
Yes, I’m well aware of this feature. We can add the command class, and we can force the version (this is what I was referring to earlier). However I think that the feature to remove the command class will effectively override this. I need to spend some time to look at this, maybe adding the command class, and forcing the version might work - the class would be removed by the version 0 issue, and then might be added again later.
I was going to play with this as well, but my development machine is not usable and I need to reinstall it unfortunately. 
I have 2 Z-wave dongles in my system (migrating from one system to another). I added the snapshot binding jar and I can see the first Z-wave dongle in my inbox (wrong tty), but it’s not the one I need to use. I attempted to add the correct one manually in PaperUI, but there’s no obvious way to add it (nothing on the screen to configure?). Should I add the one that is showing and then change the tty setting? I don’t want it to try to talk to the wrong tty.
Adding the controller manually should be exactly the same as it has been since the first version of the binding. Simply go to the things menu, click the + button, select ZWave, select the controller, and fill in the information.
In PaperUI, Configuration -> Things -> Z-wave -> Add Manually -> works - I can add and configure the Z-wave controller.
I had tried Inbox -> Add Manually -> Z-wave -> blank screen. I had tried this latter sequence since the Inbox has the Z-wave controller with the other tty, so it seemed logical that I could add the proper Thing manually through the Inbox. Apparently that is not the case.
Anyway, I have the controller working now. Thanks.
I thought it could also be done through the inbox, but I could be wrong… This logic is nothing to do with the binding and is solely part of the UI…
Anyway, glad you’re up and running 
.
Hi @chris,
your binding is very chatty at debug log level, particularly at inclusion time to log it’s comparing against all those potential thing type matches, and at poll time. At the same time it’s somewhat stiff-lipped at info level.
Since I run on Pi and log to NFS (somewhat slower writes), this is actually causing a huge delay in Habmin to display the ‘inclusion’ popup, sometimes it’s even too late. Note I believe this is a pretty common setup, so I’m not just speaking for myself but I believe there’s quite a number of users to be affected by this.
Reducing log level to INFO fixes that but on the other hand does not provide enough information for daily debugging works.
May I ask you to change logging levels a bit to some less output lines on those thing type compares on inclusion (not sure if you’re possibly willing to move them to trace level?)
Could you add some kind of summary line to contain essential data such as node/msg type/value only on each ZWave message on INFO level ? Would help to spot the essential data. Running on debug still requires to ‘parse’ several lines which can be somewhat fatigueing while you’re in need to focus on debugging the problem you’re after.
I think that could be a valuable change. Users could then permanently operate the binding at info level, no more (or just rare) need to change logging levels every time there’s a need for debug.
I always planned on reducing the logging before this version is merged, so yes, things like the thing type comparison, and a lot of the transaction logging will likely just be deleted.
I’m not sure about adding more INFO logging. I’m not sure I completely understand what you mean to be honest? I’m happy to consider something, but there are also guidelines for what should be logged at these levels and it shouldn’t be regular data -:
Only few important things should be logged in info level, e.g. a newly started component or a user file that has been loaded.
A single line output per Z-Wave message (or successful transaction, rather - I don’t mean to show ACKs, retransmits, timeouts etc).
I guess we could argue forever if that fits into the guidelines but clearly it would be valuable to users.
And I think the guideline examples weren’t written with a huge subsystem like your zwave binding in mind so we should be somewhat flexible when it comes to applying them here.
Running on debug all the time obviously is nasty (lots of data produced, painful to parse to find the info you’re looking for due to the sheer amount of data).
Running on info is what most users do, and as of today you always need to switch into debug first if you need to debug a zwave related problem and then reproduce the problem (which sometimes isn’t easy at all 'cause you need to drive OH rules into proper state, too).
Means we don’t have historical data one needs to reconstruct OH state at the time a problem occured.
I believe that with respect to the zwave info needed to resolve the problem on application (rules) level, most of the time that info from my proposed line is sufficient. If we permanently run on info with that message added, we could avoid the need to start a debugging session every time.