I’m also experiencing such a lag with my qubino dimmer, but i thing this is how these devices work … If i switch on and then off locally within 1-2 seconds I do not get any updates in the OH and in the debug log I get reports only for last action. If it was the delay in OH then I would get all the updates eventually.
@chris unfortunately i still have problems with other two qubino dimmers i have. I re-included them and they do not report the dimmer status but report the power meter value. Additionally one dimmer does not react to commands.
first dimmer:
firmware v3.5, enabled endpoint i2 - this is the first i tested with new binding and it is working ok.
second dimmer:
firmware v1.1, with temperature sensor, can be controller from OH but does not report status when switched locally. In debug log i see that report message arrives but is not send to the channel like meter_watts is:
2018-01-04 20:13:52.361 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Application Command Request (ALIVE:DONE)
2018-01-04 20:13:52.364 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: resetResendCount initComplete=true isDead=false
2018-01-04 20:13:52.367 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2018-01-04 20:13:52.371 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: SECURITY not supported
2018-01-04 20:13:52.374 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 41: Received COMMAND_CLASS_SWITCH_MULTILEVEL V3 SWITCH_MULTILEVEL_REPORT
2018-01-04 20:13:52.377 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 41: Switch Multi Level report, value = 99
2018-01-04 20:13:52.383 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-04 20:13:52.387 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 99
2018-01-04 20:13:52.391 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Commands processed 1.
2018-01-04 20:13:52.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@189c735.
2018-01-04 20:13:53.385 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Application Command Request (ALIVE:DONE)
2018-01-04 20:13:53.388 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: resetResendCount initComplete=true isDead=false
2018-01-04 20:13:53.391 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: Incoming command class COMMAND_CLASS_METER, endpoint 0
2018-01-04 20:13:53.395 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: SECURITY not supported
2018-01-04 20:13:53.398 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 41: Received COMMAND_CLASS_METER V3 METER_REPORT
2018-01-04 20:13:53.402 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 41: Meter: Type=Electric(1), Scale=W(2), Value=20.2
2018-01-04 20:13:53.409 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got an event from Z-Wave network: ZWaveMeterValueEvent
2018-01-04 20:13:53.412 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = 20.2
2018-01-04 20:13:53.416 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Updating channel state zwave:device:zstick:node41:meter_watts to 20.2 [DecimalType]
2018-01-04 20:13:53.420 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Commands processed 1.
2018-01-04 20:13:53.424 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@3cf624.
third dimmer:
firmware v3.5, no additional endpoints enabled, can’t be controller from OH, debug logs give me:
2018-01-04 20:13:32.581 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Command received zwave:device:zstick:node40:switch_dimmer1 --> ON
2018-01-04 20:13:33.635 [DEBUG] [converter.ZWaveBinarySwitchConverter] - NODE 40: Command class class COMMAND_CLASS_SWITCH_BINARY for endpoint 1 not found
2018-01-04 20:13:33.637 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: No messages returned from converter
and
2018-01-04 20:19:22.373 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Command received zwave:device:zstick:node40:switch_dimmer1 --> 5
2018-01-04 20:19:22.376 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 40: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 1
2018-01-04 20:19:22.379 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: No messages returned from converter
and does not report status exactly as second dimmer:
2018-01-04 20:14:55.057 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Application Command Request (ALIVE:DONE)
2018-01-04 20:14:55.058 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: resetResendCount initComplete=true isDead=false
2018-01-04 20:14:55.060 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2018-01-04 20:14:55.061 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: SECURITY not supported
2018-01-04 20:14:55.062 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 40: Received COMMAND_CLASS_SWITCH_MULTILEVEL V3 SWITCH_MULTILEVEL_REPORT
2018-01-04 20:14:55.064 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 40: Switch Multi Level report, value = 0
2018-01-04 20:14:55.067 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-04 20:14:55.068 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 0
2018-01-04 20:14:55.070 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Commands processed 1.
2018-01-04 20:14:55.072 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1ee75e1.
2018-01-04 20:14:56.081 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Application Command Request (ALIVE:DONE)
2018-01-04 20:14:56.082 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: resetResendCount initComplete=true isDead=false
2018-01-04 20:14:56.083 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: Incoming command class COMMAND_CLASS_METER, endpoint 0
2018-01-04 20:14:56.084 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: SECURITY not supported
2018-01-04 20:14:56.086 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 40: Received COMMAND_CLASS_METER V3 METER_REPORT
2018-01-04 20:14:56.087 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 40: Meter: Type=Electric(1), Scale=W(2), Value=0E+1
2018-01-04 20:14:56.090 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Got an event from Z-Wave network: ZWaveMeterValueEvent
2018-01-04 20:14:56.091 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = 0E+1
2018-01-04 20:14:56.094 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Updating channel state zwave:device:zstick:node40:meter_watts to 0 [DecimalType]
2018-01-04 20:14:56.098 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Commands processed 1.
2018-01-04 20:14:56.099 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@e5792f.
I think i fixed it, the one thing that was different between working dimmer and not working dimmers is that working one sends reports from endpoint 1 and not working dimmers from endpoint 0. I excluded with reset of the settings (5 times on i1), and after the inclusion the dimmer sends updates on endpoint 1. So it seems that to update to this dev binding the qubino device must be totally wiped from the z-wave network 
Those qubinos ere giving me a hard time … the last one had no additional endpoints defined and even resetting didn’t helped. So I enabled i2 endpoint and then reincluded and only then it reports correctly … I hope that this was the last time I had to reinclude qubino device …
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.
No - they are different.
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
in the karaf console type bundle:list. it will show all the bindings with versions.
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?
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
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.
Maybe my post was a little confusing. That was how it looked first, before I did everything that I wrote underneath Now the 201801021718 is active and it works, except for the problems I mentioned.
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.
Yes, I thought if maybe the settings are made incorrectly as they were for the lifeline.
GOD DAMN IT !!! THOSE QUBINOS ARE PIECE OF SH*** !!!
- 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.
- 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 ?
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
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.
Have any of you got association to another device working?
yes, I could associate the i2 input with another dimmer
Good 
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.