Association doesn't update the associated item status

Hi,

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?

Thanks,

I think this indicates that your Item file has wrong port on Node 5. The trace indicates that nothing is bound to zwave node:port 5:0

My guess is you have just “5” in your Items file, or possibly you were read the doc page and assumed you has to use a port > 0.

In any case, I’d suggest specifying “5:0” in your binding.

No - this is not valid and shouldn’t be used. While it MAY work, it also may cause problems, and you shouldn’t use ‘0’ (as per the wiki - see below).

However, you may be right in that the endpoint might be wrong. Can you provide the item definition, and also the XML (from /etc/zwave/node5.xml).


From the wiki -:

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”

The item bound to that node is currently:

switch…{zwave=“38:command class=switch_binary,refresh_interval=120”}

So at the very least, there’s something in the DEBUG code that is defaulting to port 0 in it’s messaging in instead of some other value like NULL or -1 (to mean “no specific port”).

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 :smile:

I haven´t added the switch to my items file. That’s the reason for that message. Item which is not updated is 4.

Here is the link to download the file.

here the debug log:

2015-09-06 23:08:37.180 [DEBUG] [eController$ZWaveReceiveThread:1441]- Receive Message = 01 09 00 04 00 05 03 20 01 FF 2A 
2015-09-06 23:08:37.186 [DEBUG] [b.z.i.protocol.ZWaveController:1123]- Receive queue TAKE: Length=0
2015-09-06 23:08:37.186 [DEBUG] [eController$ZWaveReceiveThread:1365]- Receive queue ADD: Length=1
2015-09-06 23:08:37.188 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 09 00 04 00 05 03 20 01 FF 2A 
2015-09-06 23:08:37.190 [DEBUG] [b.z.i.protocol.ZWaveController:1124]- Process Message = 01 09 00 04 00 05 03 20 01 FF 2A 
2015-09-06 23:08:37.192 [DEBUG] [b.z.i.protocol.ZWaveController:190 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 05 03 20 01 FF 
2015-09-06 23:08:37.193 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 5: Application Command Request (ALIVE:DONE)
2015-09-06 23:08:37.195 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 5: Incoming command class BASIC
2015-09-06 23:08:37.196 [DEBUG] [z.i.p.c.ZWaveBasicCommandClass:74  ]- NODE 5: Received Basic Request
2015-09-06 23:08:37.197 [DEBUG] [z.i.p.c.ZWaveBasicCommandClass:78  ]- NODE 5: Basic Set sent to the controller will be processed as Basic Report
2015-09-06 23:08:37.198 [DEBUG] [z.i.p.c.ZWaveBasicCommandClass:107 ]- NODE 5: Basic report, value = 0xFF
2015-09-06 23:08:37.199 [DEBUG] [b.z.i.protocol.ZWaveController:595 ]- Notifying event listeners: ZWaveCommandClassValueEvent
2015-09-06 23:08:37.200 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ]- ZwaveIncomingEvent
2015-09-06 23:08:37.201 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2015-09-06 23:08:37.203 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63  ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 05 01 00 
2015-09-06 23:08:37.204 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64  ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 05 03 20 01 FF 
2015-09-06 23:08:37.205 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65  ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false
2015-09-06 23:08:37.221 [DEBUG] [eController$ZWaveReceiveThread:1441]- Receive Message = 01 09 00 04 04 05 03 25 03 FF 29 
2015-09-06 23:08:37.224 [DEBUG] [eController$ZWaveReceiveThread:1365]- Receive queue ADD: Length=1
2015-09-06 23:08:37.224 [DEBUG] [b.z.i.protocol.ZWaveController:1123]- Receive queue TAKE: Length=0
2015-09-06 23:08:37.226 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 09 00 04 04 05 03 25 03 FF 29 
2015-09-06 23:08:37.228 [DEBUG] [b.z.i.protocol.ZWaveController:1124]- Process Message = 01 09 00 04 04 05 03 25 03 FF 29 
2015-09-06 23:08:37.229 [DEBUG] [b.z.i.protocol.ZWaveController:190 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 04 05 03 25 03 FF 
2015-09-06 23:08:37.230 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 5: Application Command Request (ALIVE:DONE)
2015-09-06 23:08:37.231 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 5: Incoming command class SWITCH_BINARY
2015-09-06 23:08:37.233 [DEBUG] [.ZWaveBinarySwitchCommandClass:79  ]- Received Switch Binary Request for Node ID = 5
2015-09-06 23:08:37.234 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 5: Switch Binary report, value = 0xFF
2015-09-06 23:08:37.235 [DEBUG] [b.z.i.protocol.ZWaveController:595 ]- Notifying event listeners: ZWaveCommandClassValueEvent
2015-09-06 23:08:37.236 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ]- ZwaveIncomingEvent
2015-09-06 23:08:37.237 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255
2015-09-06 23:08:37.239 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63  ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 05 01 00 
2015-09-06 23:08:37.245 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64  ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 04 05 03 25 03 FF 
2015-09-06 23:08:37.253 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65  ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false

Just to confirm what you’re trying to do (sorry - I’m a bit confused :confused:).

You’ve set up an association from node 5, and you want it to turn on node 4? Correct?

If so, it looks like this should be configured ok - what is node 4? Is it quite close to node 5? (I assume so, but just checking).

Totally “been there, done that, made the same choice” (see https://www.linkedin.com/in/bobdickenson)

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 ?

No worries Chris. My explanation was confused.

Correct, and I’m able to do it manually from the switcher with a long press (3 seconds).

I agree. The configuration is OK, because it works. Node 4 and 5 are 2 meters away. My problem is related to not updating the status for Node 4. Only status for node 5 is updated.

If I’m switching on, Node 4 and Node 5 are turned on (the device) but the status only for node 5 gets on and status for Node 4 is off although the device is on.

any other ideas?

Sorry - I forgot to reply :frowning:

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

Chris

No worries, thank for your reply Chris.

It is a surprise taht the status updated is not sent as the openhab won’t have the current status for those devices. Any idea for the workaround?

Also, what is the purpose of association then? what are the normal use cases?

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…

Hi Chris,

Not to put pressure, but any progress?

How will association work in OH2? As it is currently doing, or as I expected

Thanks,

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 :frowning:

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…

would it be possible to define the association at rule level?

Suppose I’m able to identify the long press in my switch, then I would define what to do in the rule, switch on/off this and that.

If this is possilbe, how can I identify a long press?

Thanks,

I don’t know what you mean by this? Associations are something that are configured into a device, so they are part of zwave, and nothing to do with openHAB.

If this switch is only ever used to turn on the other node (node 4 was it?) then you could use a rule to turn node 4 on and off depending on the state of the node 5 switch…

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 :smile:).

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).