(Changed) Polling period for Qubino 2 Flush (Z-wave) Relais sensors set to 30 min?

[Elsing (Markus)]

Hi @Chris, thanks for the fast reply ! Next time I will try to capture the ZWave messages, in fact I have the logfiles still and I will try to dig them out later for you (I am still learning and wasn’t identifying it in the logs).

Do you understand why the device polling produces an update with the right MC association ?

I will try a new version of the binding this evening and let you know in case.

[chris (Chris Jackson)]

Do you understand why the device polling produces an update with the right MC association ?

Yes. Polling polls the different endpoints using multi-channel encapsulation, and the device MUST respond using multi-channel encapsulation. However when the device sends unsolicited data, it doesn’t - it will send without the encapsulaton unless the multi-channel association is configured and this isn’t working properly at the moment.

See -:

I've made a change, but I'm not sure it will work for you yet. Since this only affects group 1, and there are other problems preventing you changing group 1, this change may not actually do anything. If you exclude the device and add it back it might work. Make sure you keep a log so we can see what happened during the initialisation if it didn't work.

and

How to access different endpoints?

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 d…

and

Qubino ZMNHBD1 Flush 2 not reporting separate switches

Hi there, I've just installed a second Qubino Flush 2 Relay and added it to my Zwave network. I'm now having trouble receiving status updated for the two separate switches it contains when using the hardware switch. When toggling the switch, the Qubino correctly toggles the connected light. The Zwave binding receives a status update for switch_binary. However, this channel reports changes for either of the hardware switches. There are separate channels switch_binary1 and switch_binary2, but th…

[Elsing (Markus)]

Hi @Chris, I updated the binding, no change in the behaviour (as you expected).

Below a piece of the logfile with the message this time included, I hope. I don’t understand what it means, hope you find this useful:

21:42:35.572 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 39 0A 32 02 21 34 00 00 01 25 00 00 D9
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
21:42:35.573 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 39 0A 32 02 21 34 00 00 01 25 00 00 D9
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 39 0A 32 02 21 34 00 00 01 25 00 00 D9
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 39 0A 32 02 21 34 00 00 01 25 00 00
21:42:35.573 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Application Command Request (ALIVE:DONE)
21:42:35.573 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 57: Starting initialisation from DONE
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1fd05ca4 already registered
21:42:35.573 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Incoming command class METER
21:42:35.573 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Received METER command V3
21:42:35.573 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Meter: Type=Electric(1), Scale=W(2), Value=29.3
21:42:35.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
21:42:35.573 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Got an event from Z-Wave network: ZWaveMeterValueEvent
21:42:35.573 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Got a value event from Z-Wave network, endpoint = 0, command class = METER, value = 29.3
21:42:35.574 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Updating channel state zwave:device:c1977c1d:node57:meter_watts to 29.3 [DecimalType]
21:42:35.574 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_KWh <> E_W

[automatic (Allen)]

I am experiencing a similar issue with Qubino 2 Relays (I have 2 modules installed):

• Unit 1 reports state from 1 of 2 switches (i.e second switch does not report when manually triggered). Power reporting works.

• Unit 2 does not report anything (neither power nor switch states)

Both units process input from the controller without any problems (i.e. on/off works fine).

I have a few Qubino 1 Relay modules, they all report status/power without any problems. Network looks good according to Habmin Network Viewer.

Any thoughts on what may be going on here?

[vossivossi]

Any thoughts on what may be going on here?

Yes, sounds like the old problem with the multi instance associations. The solution for me was to exclude the device and reinclude it with Habmin with a network wide inclusion. The inclusion should be done with the OH Release 2.0.0 or a newer snpashot version (do not use the dev branch Z-Wave binding as it still has this problem).

[automatic (Allen)]

The solution for me was to exclude the device and reinclude it with Habmin with a network wide inclusion. The inclusion should be done with the OH Release 2.0.0 or a newer snpashot version

That is exactly what I did. Reincluded via Habmin (via magnifying glass with plus sign inside) and am using current snapshot version. Despite apparently having done the same thing as you, I am getting different results…