Sorry - I missed your previous message. I’ll try and have a read tomorrow…
As I’ve said elsewhere, this is quite a complex topic - there are MANY different ways to configure associations now, and different devices tend to want the configuration done differently (I think this is a mess in ZWave, but hey…).
Can you provide a debug log from the binding and I’ll have a look. Best thing to do is to click on the “reinitialise” button for the device in HABmin and send the log for the next 30 seconds or so.
Thanks for the log. In this log, there are no commands from the binding to set the associations. There is an association already set in group 1 to report to node 1:0. This is an endpoint association and this looks fine to me and is inline with the latest ZWave spec for version 3 of the MULTI_CHANNEL_ASSOCIATION command class (which is what the device is reporting).
Below is the relevant section of the standards -:
What this tells me is that if I set a node:endpoint of 1:0 (as we see in the log above), then I believe the last line in the table is applicable (since we have an endpoint association type). In this case, the device should send non-encapsulated for anything coming from the root (ie endpoint 0), and it should be sent encapsulated if the data is coming from an endpoint other than 0.
If you read the above table different to me, then I’m happy to hear a different interpretation 
. This is all part of the mess that I refer to above - there are many options for setting the associations, and depending on how they are set, there are different options for how the data is then sent… 
So, the next question is - what is the device sending? Does it send anything (there’s nothing in the log you sent)? I guess it is sending something as you showed some logs in the OZW log - it would be good to see what these are in the OH log (just because there was an error in the OZW log, doesn’t necessarily make it wrong for OH).
So, the next question is - what is the device sending? Does it send anything (there’s nothing in the log you sent)?
I just sent you another set of debug logs containing device inclusion, association setting and wall switch triggering. The binding only detects the presses, if I put the controller into association groups 2 or 3. But the associated items aren’t triggered.
I’ve just realised that you’re not using the latest version of the binding that has had the work to try and solve this. I think it will likely solve the issue here. The problem is that the device doesn’t report that it supports multiple channels in the NIF, so the binding doesn’t know about the other channels, and yet the device sends multi-channel data. The device then doesn’t decode this.
The new version should fix this issue as it adds a check to ensure that there are multiple channels before using the multi-channel-association class.
The manually installing the version here -:
You might need to exclude the device again to ensure it’s cleanly reset. If the problems still persist, then please provide a new log…
Oh, sorry. I thought I made it clear that I am/was using the OH 2.3 stable including the stable Z-Wave binding. I’ll install the test binding and report back (around the end of the week).
You may well have and I could well have just missed it (it’s quite likely), so I was just meaning that I’d only just realised.
Let me know if it helps (or not 
).
Let me know if it helps (or not
I finally came around to testing this: You were right, after exluding/including the device with the/a test binding, button presses are finally detected as well. Thank you very much! 
I’m also having some troubles with ZMNHDD firmware 3.5 (status doesn’t work).
After the initiation the lifeline association is blank. If I set it to “OpenHAB controller” and then restart the service, the field is empty.
I’m using 2.4 0626 snapshot.
As @Nyarly states it works with the development version of the zwave binding I suggest changing to that one:
1 Like
Ok, they’re dated to the same date. Will check and report back. Is it enough to install the binding or do I need to reinit?
Edit: @nyarly excluded and included again.
As @sihui stated, I’ve used (or am currently using) the development binding dated June 19th 2018 with openHAB 2.3 stable.
I only had to delete and re-add the things for my fibaro roller shutters, motion sensors und rgbw controllers. My Qubino DIN dimmers and everspring plugs, however, had to be exluded, reset and re-included to work properly.
There is a somewhat recent discussion in that thread about the steps needed.
Yeah, cloned development and compiled with maven. Will check tonight.
Or just download the jar from the first post.
Can’t use the linked version. Controller says: Serial Error Port {0} does not exist.
Did you configure the port (in the controller Thing)? You’ll also need to delete and rediscover your zwave Things to use the dev binding. This does not mean exclude/reinclude.
Yes, I have a pine64 so /dev/ttyS2 works in stable / snapshot but not in that dev jar.
Presumably recompiling the same code will result in the same error …