I have configured my first association with my swiid cord switch. I have added in the group a switch and the association works perfectly, the long press switch on and off the other switch but the status for this other switch is not updated.
I have the following traces in the openhab.log
2015-09-06 21:01:41.563 [WARN ] [.z.internal.ZWaveActiveBinding] - NODE 5: No item bound for event, endpoint = 0, command class = BASIC, value = 255, ignoring.
2015-09-06 21:01:41.606 [WARN ] [.z.internal.ZWaveActiveBinding] - NODE 5: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 255, ignoring.
Please, can you help or provide any idea to update the status?
The endpoint ID is only required/allowed when using the multi_instance command class. In case a node consists of multiple instances or endpoints, the instance number can be specified using this value. The default value is not to use the multi_instance command class - the number must be positive and must not be 0.
I will defer to Chris on this, perhaps what you need is “5:” Running on a Pi 2 with many zwave spec’ed as “NN:0” (and all working fine), I just changed all those to “NN:” and things at least generally working.
However, after doing the above, in my zwave log, I do see DEBUG messages saying “…got a message from the zwave network, endpoint=0,command class = switch binary, value=0”
I would assume you also see these messages before you make the change? The binding just logs the endpoint as 0 when a non multi_instance command is received - I could have used -1, or null as you suggest - I chose 0. It’s just the way it prints the DEBUG messages - that’s all
You’ve done great work with zwave. I’ll double-check truth value on “do you see the messages before…”.
I actually added all the “:0” in my Items because of an web reference (which I cannot lay hands on at this exact moment) that talked about the message with the “endpoint=NN” message indicating that the binding needs to reflect the NN port number.
So “endpoint=NN” in DEBUG is actually overloaded , means one thing if NN==0 an another if NN !=0. Correct ?
Yes - what you want to do isn’t possible. Unfortunately when you use an association to control another device, the device being controlled won’t send status updates, or association messages itself as a result of this command.
I was thinking how this could be worked around but at the moment it isn’t immediately obvious
The associations are used to send commands from a switch to a device, or from one device to another device - exactly as you are using them. You have an association configured that turns on node 4 when you click the switch on node 5, and I understand that this works? This is using associations, and this is what they were designed for…
I think that a node that is configured from the association on a different node (ie in your case, node 4 is configured from node 5) doesn’t send an association of it’s own to prevent the possibility of getting into loops - I might be wrong, but that’s the only thing I can think of…
Currently I don’t have a work around - I will have a think about what could be added - I have an idea, but I need to think it through more yet…
No - it’s not something I’ve had the time to look at - I’ve been a bit busy over the past couple of weeks
It will be the same as OH1 since this is simply the way that ZWave works and we can’t change that. All we might be able to do is to find some way to poll based on something that is detected within the binding, but it is always likely to be a bit of a hack since the bottom line is that zwave isn’t supporting ‘linked’ associations…
If you remember, I have defined the association at node5 to turn on node4 with the long press.
Let’s remove the association from node 5, but create a rule which is fire with the long press to node 5 switch. In that rule, i can switch on/off node5 and node4. This would update the item status for node4 and node 5, wouldn’t it?
You don’t need to remove the association - I would leave it there. That way, if OH stops working, the light will still work (and you don’t upset your partner ).
So, you leave the association between node 5 and 4 - this turns on the lights.
You also leave the association from node 4 to node 1 - this means that if node 4 changes state for some reason, then OH will know about it (well - any reason other than node 5 sending it an association!).
You also leave the association from node 5 to node 1 - this tells OH that node 5 changed state, and from this you can assume that node 4 has also changed state. You then set up a rule that changes the state of the item associated with node 4, each time node 5 changes…
Does that make sense? I think it should do what you want (if I understand correctly).