Thank you!
The association groups always show as blank for me too, but they are set - I think a bug in Habmin?
But weirdly the device still refuses to work for me… anyone else having any luck with COMMAND_CLASS_BASIC?
Dan
For me, it also shows as blank in Paper UI. Can you confirm what you see in Paper UI?
For me it is also blank in PaperUI and Habmin for most of my nodes.
However some nodes are showing the correct association information in Habmin. I noticed that in the JSON there is a difference. The blank entries in Habmin look as follows:
the corresponding JSON shows:
Another node shows the correct information in Habmin:
The corresponding JSON for this node shows:
In PaperUI the association information is NOT shown for BOTH nodes.
I have OH2.2.0 (rel.version) and Zwave dev binding 201712301543
Hmm, maybe somehow related to endpoint 0, since the issue seems to occur on the following values:
"node_1_0"
and
"node_1"
Yes, I think in the latest code, there shouldn’t be any reference to the “_0” on the end of the endpoint and this is why the association groups are blank. For devices that were configured previously, there will likely still be these references, but because the binding now defined _1 as the controller, we end up with the blank in the UI.
There may also be a case where there is no endpoint defined - I’ll check this.
The whole endpoint association issue is unfortunately quite complex 
. There are many different implementations of endpoints with this (relatively) new concept in ZWave and I think the command class definition has 3 versions all with different definitions of how to use the endpoint and then there’s multi-channel and single-channel association classes which are meant to map to each other, but depending on which one is used will change the way a device works.
@chris Some added info…
On this REST API call
http://host:8080/rest/config-descriptions/thing:zwave:device:zstick:node8
I see this in the section for the Group 1 association. If I’m reading this correctly, I don’t see where the current value is being returned.
Edit: It appears that the limitToOptions shows node_1_1. Not sure if that is right in this case.
}, {
"label": "1: Reports",
"name": "group_1",
"required": false,
"type": "TEXT",
"readOnly": false,
"multiple": false,
"groupName": "association",
"advanced": false,
"verify": false,
"limitToOptions": true,
"options": [{
"label": "openHAB Controller",
"value": "node_1_1"
}, {
"label": "Node 6",
"value": "node_6"
}, {
"label": "Node 22",
"value": "node_22"
}, {
"label": "Node 9",
"value": "node_9"
}, {
"label": "Node 10",
"value": "node_10"
}
],
"filterCriteria": []
Edit: This was using PaperUI, but I expect the same would be true with HABmin as I assume it makes the same REST API call to get the config.
yes, blank in Paper UI as well.
The current value is not returned here - this is the config description - not the configuration itself.
Sorry - what do you mean by this? node_1_1 is correct - as I said in my earlier message - _1 is now used for the controller. _0 causes problems on some devices that are using V1 or V2 of the command class when the definition didn’t allow the use of endpoint 0.
Ah, sorry, my misunderstanding. So the current value is returned in the /rest/things API call. Which contains this:
"configuration": {
"action_heal": false,
"action_reinit": false,
"config_132_1": 0,
"action_failed": false,
"group_1": ["node_1"],
"action_remove": false,
"binding_pollperiod": 1800,
"node_id": 8
},
So, I’m still confused. node_1 is not one of the limitToOptions in the config description. Isn’t that why it doesn’t display?
Yes - also as I said earlier 
Maybe this wasn’t well explained (ok, maybe not “maybe” ) but this is the case I meant. The definition is currently static and it needs to either be node_controllerNode or node_controllerNode_1.
Yes, you did. Reading skills are so important… 
1 Like
I’ve just posted a new version that I hope will solve the issues seen with secure inclusion - especially with larger networks. Thanks to @5iver for testing 
.
Let me know what you find (good or bad 
) - if there’s any issues, please provide a log so I can take a look.
1 Like
I have a couple of the Fibaro Relays (FGS221 and FGS222) for both of them I have observed the “problem” described below:
The relay has two channels, which I have mapped to this in my config:
Switch switchLightLivingroom1 "Light1 [%s]" { channel="zwave:device:kaervej23:node51:switch_binary1" }
Switch switchLightLivingroom2 "Light1 [%s]" { channel="zwave:device:kaervej23:node51:switch_binary2"}
The switches can be controlled from openHAB, but if I turn ON/OFF swicth 1 from the physical switch, state isn’t chenged in openHAB. I then tried to change channel mapping in openHAB for switch 1:
Switch switchLightLivingroom1 "Light1 [%s]" { channel="zwave:device:kaervej23:node51:switch_binary" }
Switch switchLightLivingroom2 "Light1 [%s]" { channel="zwave:device:kaervej23:node51:switch_binary2"}
Now everything works as expected. I would expect the switch_binary to be a channel for controlling both channels? I havn’t tried this on the old binding (eg. “before” implementing the security stuff), but I am not sure this is a new problem.
It seems to me like the input channel in the relay is mapped incorrectly, since switch_binary1 controls the channel just as I would expect?
BTW. thanks for a great binding!
The definition of the root endpoint is not mandated by the standard, so it’s up the the manufacturer. Typically the root endpoint will mirror endpoint 1, and may also add some features from other endpoints.
My preference is actually to remove these from the database to avoid confusion, but if it is there, then the binding can’t really influence what it does - it’s down to the device itself.
Sorry - what do you mean by this? You think it’s mapped incorrectly, but it is as you expect?
OK. But I would still expect switch_binary1 to act as switch_binary2 on the input (which it doesn’t). Could it be a bad mapping in the database?
I’m not really sure what the issue is that you’re reporting? You said “Now everything works as expected” so I thought you were saying everything works?
Sorry, I obviously isn’t clear enough
Initially my zwave.items look like this
Switch switchLightLivingroom1 "Light1 [%s]" { channel="zwave:device:kaervej23:node51:switch_binary1" }
Switch switchLightLivingroom2 "Light1 [%s]" { channel="zwave:device:kaervej23:node51:switch_binary2"}
With that channel configuration the item switchLightLivingroom1 doesn’t reflect the actual state of the switch, when the physical switch changes the state. I can still turn the light ON/OFF using the SwitchItem from a sitemap in openHAB.
I can change the channel config in my zwave.items:
Switch switchLightLivingroom1 "Light1 [%s]" { channel="zwave:device:kaervej23:node51:switch_binary" }
Switch switchLightLivingroom2 "Light1 [%s]" { channel="zwave:device:kaervej23:node51:switch_binary2"}
Then everything works as I would expect. Both switch items now adapt the physical state of the relay both if changed from openHAB, but also when changed at the physical switches connected to the relay.
The above behaviour can be reproduced for both my FGS-221 (Firmware 2.1) and FGS-222 (Firmware 2.2) switches.
I haveonly verified this behaviour in the security binding from the marketplace. But I suspect that the same behaviour could be found in the released version of the binding.
If you provide a log showing the configuration of the device, and the device XML, and I will take a look. I guess this is linked to association configuration - have you manually configured any associations?
I’ve just posted a new version that I hope will solve the issues seen with secure inclusion - especially with larger networks.
Stupid question – is the dev build still theorg.openhab.binding.zwave-2.2.0-SNAPSHOT.jar not 2.3 or something? (Ie, http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar)
I’m still unable to set associations on any of my devices. I’ll pull this version and see if it helps my inability to get a secure inclusion to work, but I’m starting to wonder if I’m pulling the wrong one, and that’s why the association fix is also not working.
Yes. The link in the first post is still valid.
Definitely try the latest… I am able to set associations with it. How do you know they aren’t working for you? A quick check you could do is to make sure you only have the one binding installed (bundle:list |grep -i zwave).