Well, you link an item to an endpoint, so you can always tell what endpoint an item came from - assuming the device reports endpoints in its association updates, and not all do.
I was actually referring to devices like the Qubino Flush 2 Relay which (in my installation) does not seem to be reporting the endpoints in its association updates. With my items defined as:
Switch Light_GF_Playroom_Ceiling_1 "Ceiling Light 1" { zwave="15:1:command=SWITCH_BINARY" }
Switch Light_GF_Playroom_Ceiling_2 "Ceiling Light 2" { zwave="15:2:command=SWITCH_BINARY" }
openHAB seems to be only receiving an update for endpoint 0, regardless of which physical switch is triggered, e.g.:
2016-01-28 08:59:38.601 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
2016-01-28 08:59:38.601 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 15: No item bound for event, endpoint = 0, command class = BASIC, value = 0, ignoring.
2016-01-28 08:59:38.602 [DEBUG] [ApplicationCommandMessageClass:85 ]- Transaction not completed: node address inconsistent.
2016-01-28 08:59:39.148 [DEBUG] [eController$ZWaveReceiveThread:1481]- Receive Message = 01 09 00 04 00 0F 03 25 03 00 D8
2016-01-28 08:59:39.148 [DEBUG] [eController$ZWaveReceiveThread:1405]- Receive queue ADD: Length=1
2016-01-28 08:59:39.149 [DEBUG] [b.z.i.protocol.ZWaveController:1163]- Receive queue TAKE: Length=0
2016-01-28 08:59:39.149 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 09 00 04 00 0F 03 25 03 00 D8
2016-01-28 08:59:39.149 [DEBUG] [b.z.i.protocol.ZWaveController:1164]- Process Message = 01 09 00 04 00 0F 03 25 03 00 D8
2016-01-28 08:59:39.150 [DEBUG] [b.z.i.protocol.ZWaveController:192 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0F 03 25 03 00
2016-01-28 08:59:39.150 [DEBUG] [ApplicationCommandMessageClass:38 ]- NODE 15: Application Command Request (ALIVE:DONE)
2016-01-28 08:59:39.150 [DEBUG] [ApplicationCommandMessageClass:56 ]- NODE 15: Incoming command class SWITCH_BINARY
2016-01-28 08:59:39.150 [DEBUG] [.ZWaveBinarySwitchCommandClass:79 ]- Received Switch Binary Request for Node ID = 15
2016-01-28 08:59:39.151 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 15: Switch Binary report, value = 0x00
2016-01-28 08:59:39.151 [DEBUG] [b.z.i.protocol.ZWaveController:635 ]- Notifying event listeners: ZWaveCommandClassValueEvent
2016-01-28 08:59:39.151 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ]- ZwaveIncomingEvent
2016-01-28 08:59:39.151 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 0
2016-01-28 08:59:39.152 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 15: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 0, ignoring.
2016-01-28 08:59:39.152 [DEBUG] [ApplicationCommandMessageClass:85 ]- Transaction not completed: node address inconsistent.
2016-01-28 08:59:39.703 [DEBUG] [eController$ZWaveReceiveThread:1481]- Receive Message = 01 10 00 04 00 0F 0A 32 02 21 34 00 00 00 00 00 00 CB
2016-01-28 08:59:39.703 [DEBUG] [eController$ZWaveReceiveThread:1405]- Receive queue ADD: Length=1
2016-01-28 08:59:39.704 [DEBUG] [b.z.i.protocol.ZWaveController:1163]- Receive queue TAKE: Length=0
2016-01-28 08:59:39.704 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 10 00 04 00 0F 0A 32 02 21 34 00 00 00 00 00 00 CB
2016-01-28 08:59:39.705 [DEBUG] [b.z.i.protocol.ZWaveController:1164]- Process Message = 01 10 00 04 00 0F 0A 32 02 21 34 00 00 00 00 00 00 CB
2016-01-28 08:59:39.705 [DEBUG] [b.z.i.protocol.ZWaveController:192 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0F 0A 32 02 21 34 00 00 00 00 00 00
I have tried configuring the association for the individual switches:
(And similarly for the Q1 Switch Binary, Q2 basic/binary etc).
The reporting from the individual endpoints does not seem be working for me from this Qubino.
Thus in my earlier post, what I meant was that if there was a way to force a refresh of the physical device status from within an openHAB rule, I could then work out which switch was triggered.
You mentioned in a previous post that you are using the same Qubino relays. Are you getting the indivudual endpoint status updates?
I believe that Qubino doesn’t support associations with multi instances - we’ve seen this before, and I’ve seen other reports about this on the OZW list…
Can you supply me the XML file that OH generates?
Hi!
I have exacly the same problem, did anyone success to workout some solution for this status reporting problem?
Hi,
I also have this problem. I contacted Qubino for help. I got the reply below which does not make a lot of sense to me. Can anybody help?
here is the reply to similar question:
> The Qubino device appears to send global reports unencapsulated (As instance 1? Or is OZW ASSUMING instance 1?). And sends relay reports encapsulated as instance 1 & 2.
The device will send unencapsulated reports (which in a multi channel context would correspond to endpoint 0 – the root device) in case no Multichannel Association is set on the device. This was done in order to ensure max interoperability of legacy controllers as instructed by Sigma designs support, since the module cannot know whether that class is supported by the controller.
When a Multi Channel Association is set to either one of the lifeline groups or a specific group on an endpoint then the data would arrive encapsulated. If endpoint 1 (that is controlled via I1) would report data it would report it to node 1 (the controller) in an encapsulated message with the source endpoint being 1 and destination ednpoint 0. If I2 would be triggerred then reports would arrive encapsulated with source endpoint 2. Endpoint 3 would send encapsulated data to the controller in case a temperature sensor is connected.
> In the OpenZWave XML file for the ZMNHBDx devices there is an entry about mapping endpoints. When included this causes the device global reports to be treated as instance 1 and the reports for relay 1 & 2 that come in the mutichannelencap reports to be treated as instance 1 & 2. This results in 2 different readings being reported for instance 1.
Removing the endpoint mapping results in OZW leaving the global device as instance 1 and incrementing the instance counts for relay 1 & 2 to be instance 2 & 3. This results in 3 separate devices that work when the information is passed up the stack to the calling application (e.g. Domoticz).
OZW should interpret the global (root) device as instance 0 in this case. Endpoint 1 would then be instance 1 and so on. We are not aware why they decided on such an implementation, it could be tied to the fact that it is not an official Z-Wave product, and as such not subject to specification from Sigma Designs.
> The real question is, WHY is there an endpoint mapping in the config. What’s it supposed to do? And who put it there (I think this is a qubino supplied file?)
The endpoints were defined according to the way other modules were defined in OZW, though they are in fact not needed since Z-Wave already contains endpoint discovery mechanisms via the Multi Channel Command Class. This entry wasn’t described at all in the device adding guide (Adding Devices · OpenZWave/open-zwave Wiki · GitHub) so the endpoint list was defined according to the way we saw other devices have them defined.
I have tried various things such as removing the default association to node 1 and instead enabling “Q1 switch binary” and similar association groups to node 1. I have also tried various combinations of command type in the item file (BINARY, BASIC, MULTI_INSTANCE).
I usually see SWITCH_BINARY and BASIC reports to endpoint 0, but I have occasionally observed BINARY reports to endpoint 1 and 2. The latter seems to happen only when my Pi and/or openHAB is restarted.
METER reports seem to sent to both endpoint 0 and 1/2.
I’m using the latest Zwave binding 1.9.0 and the controller is ZME UZB1 USB stick plugged into RPI2.
uname -a
Linux rpi 4.1.15-v7+ #830 SMP Tue Dec 15 17:02:45 GMT 2015 armv7l GNU/Linux
Sorry for warming up this old post, but: Could you find any solution or workaround to this?
I am facing the same trouble in my new house where I installed more then 10 ZMNHBD devices. Unfortunately it seems that I can only use them as single relays instead of the intended use as double relays. There is no distinction in reporting between the 2 endpoints (which is not understandable as this is THE KEY FEATURE of a DOUBLE relay…).
This will not be resolved on OH1 - sorry - it’s just too much work.
Thank you for claryfiying this. Does it already work in OH2?
Yes.
Cool, but is it already a good idea to move to beta4 with a produktive Environment with more than 100 nodes?
I guess that’s up to you ;). You can always try OH2 and if it doesn’t work well for you you can change back to OH1 (so long as you don’t delete your OH1 configuration of course.)
Ok, this seems to be the first killer feature forcing me to go ahead.
Just one question: Which functions exactly are ot supported in OH1 (it seems to have to do with ZWAVE Plus features?) ?
It’s not so easy to answer that question. In general, newer features over the past year have been made into OH2. Where possible, we’ve also added them to OH1, but in this case, it’s a major change as the way that associations are managed to incorporate the multi_instance_association class is a (relatively) large restructuring of the binding.
Thank you chris, so the feature in question for my qubino devices was the multi_instance_association class that is missing in OH1.
Is it possible that also other newer devices (i.e. Fibaro FGS-223 double Zwave+ relay) have this class implemented for different endpoints. I encounter similar problems with them.
There is no problem with implementation of endpoints, even in OH1. The issue is that Qubino don’t send the unsolicited responses encapsulated within the multi channelencap unless this is configured with the multi-channel-association class. So, this only is a problem when you change the state of the device by pressing the button on the device - not when controlled through the software.
I have not seen this in any Fibaro devices - they have always sent their data using multi channel encapsulation so this should not impact them and I’ve used them fine on OH1 for many years. Maybe they have changed the way this works on very recent devices, but I don’t think so.
One point to note on Fibaro is that some devices don’t encapsulate switch 1 with multi-channel, so you need to use endpoint 0 rather than endpoint 1 for the dual switches. This is something they changed quite a while ago now (maybe 1 year or more) but it is different than the older devices which encapsulated everything with multi-channel.
After having spent half the night with the configuration of OH2 (Build 694) I am close to frustration. The problem with the endpoint reporting of the Qubino ZMNHBD is exactly the same with OH2. Sorry, but I cannot see any difference/improvement.
I have defined threee switch items for the ZMNHBD, for endpoint 0,1 and 2). When I switch the device via UI, the correct light is switched on (1 or 2) or both (when hitting 0). However, endpoints 1 and 2 are NEVER updated in OH when switching is done on the physically switch. The only update in this case is for endpoint 0 (which does not make any sense and is of no use and contradictory).
Here the content of my ItemChanelLink.json:
"zwave_device_15970bead83_node55_switch_binary -\u003e zwave:device:15970bead83:node55:switch_binary": {
"class": "org.eclipse.smarthome.core.thing.link.ItemChannelLink",
"value": {
"channelUID": {
"segments": [
"zwave",
"device",
"15970bead83",
"node55",
"switch_binary"
]
},
"itemName": "zwave_device_15970bead83_node55_switch_binary"
}
},
"zwave_device_15970bead83_node55_switch_binary1 -\u003e zwave:device:15970bead83:node55:switch_binary1": {
"class": "org.eclipse.smarthome.core.thing.link.ItemChannelLink",
"value": {
"channelUID": {
"segments": [
"zwave",
"device",
"15970bead83",
"node55",
"switch_binary1"
]
},
"itemName": "zwave_device_15970bead83_node55_switch_binary1"
}
},
"zwave_device_15970bead83_node55_switch_binary2 -\u003e zwave:device:15970bead83:node55:switch_binary2": {
"class": "org.eclipse.smarthome.core.thing.link.ItemChannelLink",
"value": {
"channelUID": {
"segments": [
"zwave",
"device",
"15970bead83",
"node55",
"switch_binary2"
]
},
"itemName": "zwave_device_15970bead83_node55_switch_binary2"
}
}
Is there any other thing I could (or have to) configure?
Thanks for any help or hints!
Is there any other thing I could (or have to) configure?
Have you configured the devices associations? This is how the reporting is configured.
Yes, but have you configured them in OH2 or is this still configured from OH1?