Status updates for Qubino Relays/Dimmers generally do not work

Add-ons Bindings
235

Hi!

I have read this thread throgoughly and think that I have the same problem. I have an ZMNHAD1 H1S5P2, which I think means firmware version 5. I downloaded the latest snapshot yesterday from https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastStableBuild/org.openhab.binding%24org.openhab.binding.zwave/, however I think it was before the 2018-jan-04 22:45:20 snapshot came out. Is snapshot the same as dev branch? If not, how do I get builds from the dev branch?

After excluding the device (but not resetting all settings) and including it again with the (back then) latest snapshot, it seems to work with updates to the controller. However it doesn’t seem to work with association to another device I have (Aeon Labs Nano Switch). Could it be a related problem? The other way works. When I manually press the Nano Switch the Qubino lights up. Also it seems that when updating configuration settings the updates from the Qubino can stop working again, but another exclude/include fixes it. I have not tested it thoroughly enough to know if it is 100% repeatable.

I bought one Nano Switch and one Qubino to evaluate which one I think is best and I would very much like to use the Qubino due ti it’s faster response time when pressing the switch and the fact that there’s a 2 relay version of it.

Please let me know if I can be of any help.

236

No - they are different.

237

Thank you!

I have tried it out now. Excluded the Qubino with 5 clicks within 60 sec of power up, and then removed all Things. After that I replaced the snapshot jar (named 2.3.0) with the dev jar (named 2.2.0). Then I added the controller again and included the Qubino. Now it is working exactly as before trying the snapshot, no updates at all. It’s as if I am running the release version again. How can I verify that it actually is the new jar that is executing?

Edit: Sorry, I forgot to mention that I shut down OH before swapping the jar

238

in the karaf console type bundle:list. it will show all the bindings with versions.

239

It said:

229 | Active | 80 | 2.3.0.201801032157 | ZWave Binding
230 | Installed | 80 | 2.2.0.201801021718 | ZWave Binding

I uninstalled the 2.3.0 and restarted, excluded the Qubino again with 5 clicks, removed all Things and added them back again, included the Qubino again and now it works! It doesn’t work every time however. Sometimes it misses state changes. When that happens I get nothing in the log, even though debug output is activated. It doesn’t seem to happen when I hold the laptop in front of the switch, but it happens when the laptop is sitting on a (grounded) steel bench about 1 meter away. Maybe that is disturbing the RF signal.

The association to the Nano Switch still doesn’t work however. Only the Nano Switch can trigger the Qubino, not the other way around. Has anybody else had any luck with association and the Qubino 1 Relay?

240

The dev version is your bundle 230 (dated 201801021718). As both bindings are still installed the snapshot version is currently still active. So you need to unstall the old version with

bundle:uninstall 230

241

don’t know what is the difference between Active and Installed but for me it seems like the active is the one currently running - so You do not use the developement branch.

242

Maybe my post was a little confusing. That was how it looked first, before I did everything that I wrote underneath :slight_smile: Now the 201801021718 is active and it works, except for the problems I mentioned.

243

association groups have nothing to do with the binding itself - the binding is only needed when you are configuring the association groups. You can also use different software for that. If the associations are setup correctly the gateway may be even shutdown and associated devices should still work together. So aparently the problem is in association settings.

244

Yes, I thought if maybe the settings are made incorrectly as they were for the lifeline.

245

GOD DAMN IT !!! THOSE QUBINOS ARE PIECE OF SH*** !!!

  1. when switching off locally.
    i get in the log following reports:
2018-01-05 21:42:02.587 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got a value event from Z-Wave network, endpoint = 1, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 0
2018-01-05 21:42:03.604 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got a value event from Z-Wave network, endpoint = 1, command class = COMMAND_CLASS_METER, value = 0E+1

so, dimmer sends that its dimmer value went to 0 (which means OFF) and the power consumption also is 0.

  1. when polling the device from OH after local off.
    i get in the log following polling requests:
2018-01-05 21:54:53.304 [DEBUG] [erter.ZWaveMultiLevelSensorConverter] - NODE 43: Generating poll message for COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 0
2018-01-05 21:54:53.314 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 43: Generating poll message for COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 1
2018-01-05 21:54:53.326 [DEBUG] [ternal.converter.ZWaveBasicConverter] - NODE 43: Generating poll message for COMMAND_CLASS_BASIC endpoint 1

and then in response:

2018-01-05 21:54:53.523 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SENSOR_MULTILEVEL, value = 33.7
2018-01-05 21:54:53.622 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got a value event from Z-Wave network, endpoint = 1, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 71
2018-01-05 21:54:53.848 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 43: Got a value event from Z-Wave network, endpoint = 1, command class = COMMAND_CLASS_BASIC, value = 71

This is ridiculous … first the dimmer says that it has just switched OFF but when asked again it says that it is TURNED ON !!! …

@chris if I remember correctly, in previous binding versions when there was separate channel for switch_binary and switch_dimmer, the switch_binary was always showing the correct value, even when the dimmer channel was showing wrong value. But now I don’t see any reports for binary_switch when switching dimmer locally - so now if there was switch channel it would not be updated after local turn on/off. But in the latest qubino dimmer manual (V1.9) there is additional configuration parameter:

Parameter No. 249 – Enable/Disable Reporting on Set
command
Available configuration parameter (data type is 1 Byte Dec):
* default Value 1
* 0 – Disable reporting
* 1 – Enable reporting

So maybe bringing back the switch channel and adding parameter 249 to the database would solve the problem ?

246

@chris

I now tested several hours this evening with my Qubino devices in the test environment. I used OH Rel. 2.2.0 and the most recent dev binding (201801021718). Here are my findings:

ZMNHBD (Qubino Flush 2 relay, Firmware 1.2): EXCELLENT! Everything works as expected when I include the device with the new binding version (after doing a “hard” reset with setting back all parameters to default). Manual switching reports back to Switch1/Switch2 and also power (watts) is reported to the corresponding 1/2 channels. PERFECT!

ZMNHDD (Flush Dimmer Plus, Firmware 1.1): COMPLETE DESASTER and worse as before. The device is not showing the normal switch_dimmer channel anymore (only switch_dimmer1). The switch_dimmer1-channel unfortunately DOES NOT WORK AT ALL. Neither manual switching is reported nor is it possible to switch or dim the light anymore via the UI. Manual switching will switch and dim the light but there is absolutely no communication between the device and OH anymore, so the switch_dimmer1 channel is dead and useless. Power consumption (watts) is reported after manual switching, but only to the meter_watts channel, not to meter_watts1.
The curious thing about this: I am using 29 of these devices in my productive environment (also dev binding 201801021718) and they work fine on channel switch_dimmer (but these devices were included with older versions of the binding and already had their JSON-entries and XML-Files with the switch_dimmer channel).

Conclusion: Flush 2 Relay perfect, but Flush Dimmer Plus (ZMNHDD) need some rework.

If you need any logs from certain moments (inclusion, switching, whatever) just let me know.

Cheers,
Martin

247

weird, I don’t have such problems with this dimmer with same binding version. The only two problems are the one described in the post above yours and the second is that the restore last dimm value does not work when switching remotely.

248

Have any of you got association to another device working?

249

yes, I could associate the i2 input with another dimmer

250

Good :wink:

Yes - I’m aware of the issue here. For some reason the database change I made to force add the multi-channel class didn’t work. The removal of the switch_dimmer channel is discussed above - I want to try and avoid the confusion that we now have where people are using different channels and there’s no standard approach. Depending on how the device is configured will depend on what channel gets used and it makes it very confusing.

Clearly I need to resolve the issue with the multi-channel class, and I’ll look at this tomorrow.

251

so this my debug log when switching off the light manually:

2018-01-05 23:59:57.373 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 0F 03 26 03 00 DB 
2018-01-05 23:59:57.373 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2018-01-05 23:59:57.373 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=15, callback=0, payload=00 0F 03 26 03 00 
2018-01-05 23:59:57.373 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=15, callback=0, payload=00 0F 03 26 03 00 
2018-01-05 23:59:57.374 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=15, callback=0, payload=00 0F 03 26 03 00 
2018-01-05 23:59:57.374 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-01-05 23:59:57.374 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Application Command Request (ALIVE:DONE)
2018-01-05 23:59:57.374 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: resetResendCount initComplete=true isDead=false
2018-01-05 23:59:57.374 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2018-01-05 23:59:57.374 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: SECURITY not supported
2018-01-05 23:59:57.374 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Received COMMAND_CLASS_SWITCH_MULTILEVEL V3 SWITCH_MULTILEVEL_REPORT
2018-01-05 23:59:57.374 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 15: Switch Multi Level report, value = 0
2018-01-05 23:59:57.374 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2018-01-05 23:59:57.375 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-05 23:59:57.375 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 0
2018-01-05 23:59:57.375 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Commands processed 1.
2018-01-05 23:59:57.375 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@543a691d.
2018-01-05 23:59:57.375 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-01-05 23:59:57.375 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-01-05 23:59:57.375 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-01-05 23:59:57.375 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2018-01-05 23:59:57.376 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2018-01-05 23:59:57.376 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
2018-01-05 23:59:58.392 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 14 00 04 00 0F 0E 32 02 21 34 00 00 00 00 00 00 00 00 00 00 CB 
2018-01-05 23:59:58.392 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2018-01-05 23:59:58.392 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=15, callback=0, payload=00 0F 0E 32 02 21 34 00 00 00 00 00 00 00 00 00 00 
2018-01-05 23:59:58.393 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=15, callback=0, payload=00 0F 0E 32 02 21 34 00 00 00 00 00 00 00 00 00 00 
2018-01-05 23:59:58.393 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=15, callback=0, payload=00 0F 0E 32 02 21 34 00 00 00 00 00 00 00 00 00 00 
2018-01-05 23:59:58.393 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-01-05 23:59:58.393 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Application Command Request (ALIVE:DONE)
2018-01-05 23:59:58.393 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: resetResendCount initComplete=true isDead=false
2018-01-05 23:59:58.393 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Incoming command class COMMAND_CLASS_METER, endpoint 0
2018-01-05 23:59:58.393 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: SECURITY not supported
2018-01-05 23:59:58.393 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Received COMMAND_CLASS_METER V3 METER_REPORT
2018-01-05 23:59:58.393 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 15: Meter: Type=Electric(1), Scale=W(2), Value=0E+1
2018-01-05 23:59:58.394 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
2018-01-05 23:59:58.394 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveMeterValueEvent
2018-01-05 23:59:58.394 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = 0E+1
2018-01-05 23:59:58.394 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Updating channel state zwave:device:ZWTE:node15:meter_watts to 0 [DecimalType]
2018-01-05 23:59:58.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Commands processed 1.
2018-01-05 23:59:58.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6dacf414.
2018-01-05 23:59:58.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-01-05 23:59:58.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-01-05 23:59:58.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-01-05 23:59:58.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2018-01-05 23:59:58.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2018-01-05 23:59:58.395 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing

for me it looks as if the device is reporting back only to endpoint 0:

2018-01-05 23:59:57.375 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 0

However, the endpoint 0 is no longer available as a channel (used to be switch_dimmer). The endpoint 1 (switch_dimmer1) does not get an update, so it is useless.

The power is also reported only to endpoint 0:

2018-01-05 23:59:58.394 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = 0E+1

So this is why I can see an update to meter_watts but again no report to endpoint 1 (meter_watts1).

252

Thank you for the update! Our next postings crossed each other so maybe you might be interested in the debug log that I posted above in reply to @rozpruwacz

253

this is because You didn’t do all the steps required for endpoint 1 appear to OH. It seems that the dimmer has to be configured with at least two endpoints enabled. So at least one of following must be true: temperature sensor connected, endpoint i2 enabled, endpoint i3 enabled. Event if You don’t want them to use. I also needed to reset the dimmer, but I’m not sure if this is necessary. And remember that after enabling the i2 or i3 endpoint you cannot reset the dimmer, so first reset the dimmer, then include, then enable i2 and then re-include.

254

This is correct, but the binding should also be able to work with the standard configuration (only endpoint 0). This is not possible anymore.
I will however try to activate an additional endpoint and see what i get, I am curious now :wink: