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.
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).
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
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.
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
If You would read the whole topic You would know that 
I haven’t tried I2, only the standard Q output association group. Maybe I shall try to connect I2 and enable that endpoint to see if it works, but that shouldn’t be necessary.
Ok, I tested now with activated endpoint 2 (I set Parameter 100 ‘Enable/Disable Endpoints I2’ to ‘9 - Sensor binary’). After a ‘soft’ exclusion (pressing 3 times) and reinclusion the result is as follows:
The device is reporting to endpoint 1 for switch_dimmer1 and meter_watts1.
The device is also reporting to endpoint 2 for sensor_binary2 and alarm_general2. Great, I see this for the first time! 
However, I would prefer that the binding also works with devices with only endpoint 0. Otherwise I would have to reconfigure and reinclude 29 devices allover the house even if I do not intend to user multiple endpoints for many of them. And the shitty Qubino procedure with “clicking 5 times or 3 times the button within the first 60 seconds after connecting the device to power” is a pain in the ass if you do it with devices which are already mounted eyerywhere in the house and you need to run from the general power switch to the room with the I1-Switch 
As said previously - the plan is to do this. The problem is that the device does not report that it supports multi-channel. Without this, the binding thinks it can’t use multi-channel - I should be able to force this using a database change, but this didn’t work. Once this is working, then it should work with only endpoint 0.
Please give me some time to work this through - as said earlier, I will look at it tomorrow.
But how is this implemented in other software? As far as I read there seem to be other HA software solutions that work. Or are they also only supporting devices with or without multi-channel support? 