How to access different endpoints?

Setup, Configuration and Use Items & Sitemaps
1

Hi,

I have a Qubino flush 2 switch (ZMNHBD) which is supported by the Zwave binding (1.8.0).
This Zwave device has just two switches with each its own endpoint (I think).

My question, how can you select the right switch/endpoint? My item file now looks like this:
Switch Z_Kitchen_Switch1 “switch1” { zwave=“17:command=switch_binary” }
Switch Z_Kitchen_Switch2 “switch2” { zwave=“17:command=basic” }

This way I can differentiate between the message I receive when a switch is pressed.
When I configure both switches as “switch_binary” I can not separate them anymore. I would thought that providing the endpoint would help, like this:

Switch Z_Kitchen_Switch1 “switch1” { zwave=“17:1:command=switch_binary” }
Switch Z_Kitchen_Switch2 “switch2” { zwave=“17:2:command=switch_binary” }

But that doesn’t work. Any idea how I should do this using the endpoints?

Thanks.

2

What you have should work fine I think - I have the same working fine with a Qubino ZMNHBA.

What does the XML file show?

3

Hi Chris,

Here is my XML:
node17.xml (11.4 KB)

Thanks!

Ps. I use version 1.8.0.201512110201

4

Thanks - this looks like it should be fine. The XML shows that the endpoints are supported and recognised, and the switch_binary command class is supported by these endpoints. I would have expected that the item configs you presented would work…

Is there an error/warning in the log?

Chris

5

Hi Chris,

I configured the items as 17:1 and 17:2 but it both switch buttons are reported as endpoint 0:

…/…/logs/zwave.log:2015-12-17 19:07:32.191 [DEBUG] [ApplicationCommandMessageClass:38 ]- NODE 17: Application Command Request (ALIVE:DONE)
…/…/logs/zwave.log:2015-12-17 19:07:32.192 [DEBUG] [ApplicationCommandMessageClass:56 ]- NODE 17: Incoming command class SWITCH_BINARY
…/…/logs/zwave.log:2015-12-17 19:07:32.194 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 17: Switch Binary report, value = 0x00
…/…/logs/zwave.log:2015-12-17 19:07:32.196 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 17: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 0
…/…/logs/zwave.log:2015-12-17 19:07:32.196 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 17: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 0, ignoring.
…/…/logs/zwave.log:2015-12-17 19:07:36.194 [DEBUG] [ApplicationCommandMessageClass:38 ]- NODE 17: Application Command Request (ALIVE:DONE)
…/…/logs/zwave.log:2015-12-17 19:07:36.195 [DEBUG] [ApplicationCommandMessageClass:56 ]- NODE 17: Incoming command class SWITCH_BINARY
…/…/logs/zwave.log:2015-12-17 19:07:36.197 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 17: Switch Binary report, value = 0xFF
…/…/logs/zwave.log:2015-12-17 19:07:36.199 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 17: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255
…/…/logs/zwave.log:2015-12-17 19:07:36.200 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 17: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 255, ignoring.
…/…/logs/zwave.log:2015-12-17 19:07:39.190 [DEBUG] [ApplicationCommandMessageClass:38 ]- NODE 17: Application Command Request (ALIVE:DONE)
…/…/logs/zwave.log:2015-12-17 19:07:39.191 [DEBUG] [ApplicationCommandMessageClass:56 ]- NODE 17: Incoming command class SWITCH_BINARY
…/…/logs/zwave.log:2015-12-17 19:07:39.192 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 17: Switch Binary report, value = 0x00
…/…/logs/zwave.log:2015-12-17 19:07:39.194 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 17: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 0
…/…/logs/zwave.log:2015-12-17 19:07:39.195 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 17: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 0, ignoring.

The associations groups are for both switches (input) switch_binary to USB host controller.

Thanks.

6

This is a different issue…

Firstly, does the command work? If you set up a switch and click it in the gui, does it work?

The fact that the device is sending its association status with endpoint 0 is a different issue. We’ve seen this before and it might not be something that we can work around.

7

I do not have lamps attached to the output as I use the switch only to detect if someone hit the switches.

It seems to work though:

../../logs/zwave.log:2015-12-17 19:58:04.309 [DEBUG] [.ZWaveBinarySwitchCommandClass:146 ]- NODE 17: Creating new message for application command SWITCH_BINARY_SET
../../logs/zwave.log:2015-12-17 19:58:04.311 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ]- NODE 17: Creating empty message of class = SendData (0x13), type = Request (0x00)
../../logs/zwave.log:2015-12-17 19:58:04.312 [DEBUG] [.z.internal.protocol.ZWaveNode:660 ]- NODE 17: Encapsulating message, instance / endpoint 1
../../logs/zwave.log:2015-12-17 19:58:04.314 [DEBUG] [ZWaveMultiInstanceCommandClass:560 ]- NODE 17: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 1
../../logs/zwave.log:2015-12-17 19:58:04.326 [DEBUG] [WaveController$ZWaveSendThread:1268]- NODE 17: Sending REQUEST Message = 01 0E 00 13 11 07 60 0D 01 01 25 01 00 25 06 9E
../../logs/zwave.log:2015-12-17 19:58:04.356 [DEBUG] [b.z.i.p.s.SendDataMessageClass:38  ]- NODE 17: Sent Data successfully placed on stack.
../../logs/zwave.log:2015-12-17 19:58:04.366 [DEBUG] [b.z.i.p.s.SendDataMessageClass:74  ]- NODE 17: SendData Request. CallBack ID = 6, Status = Transmission complete and ACK received(0)
../../logs/zwave.log:2015-12-17 19:58:04.373 [DEBUG] [WaveController$ZWaveSendThread:1327]- NODE 17: Response processed after 47ms/4942ms.
../../logs/zwave.log:2015-12-17 19:58:05.954 [DEBUG] [.ZWaveBinarySwitchCommandClass:146 ]- NODE 17: Creating new message for application command SWITCH_BINARY_SET
../../logs/zwave.log:2015-12-17 19:58:05.956 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ]- NODE 17: Creating empty message of class = SendData (0x13), type = Request (0x00)
../../logs/zwave.log:2015-12-17 19:58:05.958 [DEBUG] [.z.internal.protocol.ZWaveNode:660 ]- NODE 17: Encapsulating message, instance / endpoint 2
../../logs/zwave.log:2015-12-17 19:58:05.959 [DEBUG] [ZWaveMultiInstanceCommandClass:560 ]- NODE 17: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 2
../../logs/zwave.log:2015-12-17 19:58:05.968 [DEBUG] [WaveController$ZWaveSendThread:1268]- NODE 17: Sending REQUEST Message = 01 0E 00 13 11 07 60 0D 01 02 25 01 00 25 08 93
../../logs/zwave.log:2015-12-17 19:58:05.985 [DEBUG] [b.z.i.p.s.SendDataMessageClass:38  ]- NODE 17: Sent Data successfully placed on stack.
../../logs/zwave.log:2015-12-17 19:58:06.008 [DEBUG] [b.z.i.p.s.SendDataMessageClass:74  ]- NODE 17: SendData Request. CallBack ID = 8, Status = Transmission complete and ACK received(0)
../../logs/zwave.log:2015-12-17 19:58:06.015 [DEBUG] [WaveController$ZWaveSendThread:1327]- NODE 17: Response processed after 47ms/4942ms.
../../logs/zwave.log:2015-12-17 19:58:06.954 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 17: Application Command Request (ALIVE:DONE)
../../logs/zwave.log:2015-12-17 19:58:06.954 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 17: Incoming command class SWITCH_BINARY
../../logs/zwave.log:2015-12-17 19:58:06.956 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 17: Switch Binary report, value = 0x00
../../logs/zwave.log:2015-12-17 19:58:06.957 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 17: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 0
../../logs/zwave.log:2015-12-17 19:58:06.958 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 17: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 0, ignoring.
../../logs/zwave.log:2015-12-17 19:58:08.013 [DEBUG] [.ZWaveBinarySwitchCommandClass:146 ]- NODE 17: Creating new message for application command SWITCH_BINARY_SET
../../logs/zwave.log:2015-12-17 19:58:08.015 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ]- NODE 17: Creating empty message of class = SendData (0x13), type = Request (0x00)
../../logs/zwave.log:2015-12-17 19:58:08.016 [DEBUG] [.z.internal.protocol.ZWaveNode:660 ]- NODE 17: Encapsulating message, instance / endpoint 2
../../logs/zwave.log:2015-12-17 19:58:08.018 [DEBUG] [ZWaveMultiInstanceCommandClass:560 ]- NODE 17: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 2
../../logs/zwave.log:2015-12-17 19:58:08.024 [DEBUG] [WaveController$ZWaveSendThread:1268]- NODE 17: Sending REQUEST Message = 01 0E 00 13 11 07 60 0D 01 02 25 01 FF 25 09 6D
../../logs/zwave.log:2015-12-17 19:58:08.039 [DEBUG] [b.z.i.p.s.SendDataMessageClass:38  ]- NODE 17: Sent Data successfully placed on stack.
../../logs/zwave.log:2015-12-17 19:58:08.056 [DEBUG] [b.z.i.p.s.SendDataMessageClass:74  ]- NODE 17: SendData Request. CallBack ID = 9, Status = Transmission complete and ACK received(0)
../../logs/zwave.log:2015-12-17 19:58:08.060 [DEBUG] [WaveController$ZWaveSendThread:1327]- NODE 17: Response processed after 35ms/4942ms.
../../logs/zwave.log:2015-12-17 19:58:09.816 [DEBUG] [.ZWaveBinarySwitchCommandClass:146 ]- NODE 17: Creating new message for application command SWITCH_BINARY_SET
../../logs/zwave.log:2015-12-17 19:58:09.817 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ]- NODE 17: Creating empty message of class = SendData (0x13), type = Request (0x00)
../../logs/zwave.log:2015-12-17 19:58:09.819 [DEBUG] [.z.internal.protocol.ZWaveNode:660 ]- NODE 17: Encapsulating message, instance / endpoint 1
../../logs/zwave.log:2015-12-17 19:58:09.826 [DEBUG] [ZWaveMultiInstanceCommandClass:560 ]- NODE 17: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 1
../../logs/zwave.log:2015-12-17 19:58:09.833 [DEBUG] [WaveController$ZWaveSendThread:1268]- NODE 17: Sending REQUEST Message = 01 0E 00 13 11 07 60 0D 01 01 25 01 FF 25 0A 6D
../../logs/zwave.log:2015-12-17 19:58:09.849 [DEBUG] [b.z.i.p.s.SendDataMessageClass:38  ]- NODE 17: Sent Data successfully placed on stack.
../../logs/zwave.log:2015-12-17 19:58:09.865 [DEBUG] [b.z.i.p.s.SendDataMessageClass:74  ]- NODE 17: SendData Request. CallBack ID = 10, Status = Transmission complete and ACK received(0)
../../logs/zwave.log:2015-12-17 19:58:09.870 [DEBUG] [WaveController$ZWaveSendThread:1327]- NODE 17: Response processed after 36ms/4942ms.
../../logs/zwave.log:2015-12-17 19:58:11.960 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 17: Application Command Request (ALIVE:DONE)
../../logs/zwave.log:2015-12-17 19:58:11.961 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 17: Incoming command class SWITCH_BINARY
../../logs/zwave.log:2015-12-17 19:58:11.963 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 17: Switch Binary report, value = 0xFF
../../logs/zwave.log:2015-12-17 19:58:11.965 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 17: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255
../../logs/zwave.log:2015-12-17 19:58:11.966 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 17: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 255, ignoring.
../../logs/zwave.log:2015-12-17 19:58:13.958 [DEBUG] [ApplicationCommandMessageClass:38  ]- NODE 17: Application Command Request (ALIVE:DONE)
../../logs/zwave.log:2015-12-17 19:58:13.959 [DEBUG] [ApplicationCommandMessageClass:56  ]- NODE 17: Incoming command class SWITCH_BINARY
../../logs/zwave.log:2015-12-17 19:58:13.969 [DEBUG] [.ZWaveBinarySwitchCommandClass:115 ]- NODE 17: Switch Binary report, value = 0xFF
../../logs/zwave.log:2015-12-17 19:58:13.974 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 17: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255
../../logs/zwave.log:2015-12-17 19:58:13.976 [WARN ] [.z.internal.ZWaveActiveBinding:467 ]- NODE 17: No item bound for event, endpoint = 0, command class = SWITCH_BINARY, value = 255, ignoring.
8

@chris Is there a way of directly querying the status of each of the device endpoints from within a rule to then determine which endpoint has triggered the association status update?

9

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.

10

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?

11

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?

12

Qubino ZMNHBD xml file attached: node15.xml (15.9 KB)

13

Hi!
I have exacly the same problem, did anyone success to workout some solution for this status reporting problem?

14

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

15

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

16

This will not be resolved on OH1 - sorry - it’s just too much work.

17

Thank you for claryfiying this. Does it already work in OH2?

18

Yes.

19

Cool, but is it already a good idea to move to beta4 with a produktive Environment with more than 100 nodes?

20

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