Status updates for Qubino Relays/Dimmers generally do not work

[sihui]

@houz

I only understand half of that.

You need to read the whole thread. It is all in there …

[vossivossi]

I agreee that it is more than hard to follow this thread if you did not follow it in details or contributed to the testing. So I will try to explain:

@houz

What are activated additional endpoints?

You can activate additional reporting functions for the dimmer by changing its configuration parameters and afterwards excluding and reincluding the device to the network. The parameters 100 and 101 allow to enable/disable the endpoints I2/I3 (which would allow you for example to connect another switch or binary sensor to the dimmer device on the physical inputs I2 or I3 and report their status changes to the controller). Another option is to connect a temperature sensor which also then represents an additional endpoint.

@houz

Isn’t that the temperature sensors you can attach?

Yes, one of the 3 options to acitivate additional endpoints as stated above. (I2, I3, temperature sensor)

@houz

And isn’t he talking about how well the dimmer works?

Correct, the dimmer performs its main original task (=dimming light) excellent, even with very low LED loads

@houz

I was asking about how well openHAB works.

This depends indeed from several criteria: The Z-Wave-Bind version you are using (or have used) to include the device and the activated (or not activated) endpoints on the device. From my experience:

Z-Wave Snapshot binding (non dev version): works fine for endpoint 0 (switch_dimmer) in any case (with or without activated additional endpoints) , but never for the additional endpoints.

Z-Wave Dev Binding before 20180102 (my latest before was 20171230): works fine for endpoint 0 (switch_dimmer) in any case (with or without activated additional endpoints) , but never for the additional endpoints.

Z-Wave Dev Binding from 20180102 (the most recent dev version): Does NOT work for switch_dimmer if NO additional endpoints are activated. BUT: Works for switch_dimmer1 and additional endpoints as soon as at least one additional endpoint is activated.

These are at least my findings.

For a solution the last suitable solution discussed here is to reactivate the channel ‘Switch_Dimmer’ (which was deleted in the 20180102 dev version). This would allow people without additional endpoints to have everything work with channel switch_dimmer. Users with additional endpoints could use switch_dimmer1 (for the light) AND the additional endpoints.

However @chris has not yet published a new dev version with this workaround solution. But he wants to do this until tommorow.

[mrRobit]

@Daniel_Linder

I have never managed to get my flush 2 relays firmware 1.1 to report on anything but endpoint 0. Not with Openhab nor with Vera.

Replaced one device with a new one (firmware 5.0). It immidiately worked, reporting on the individual switches. I reported this back to where I bought the qubinos 18 months ago. Was immidiately offered replacements FOC. I believe the firmware 1.1 devices are bad, and a waste of time.

I did the same thing yesterday. I replaced my Qubino ZMNHBD Flush 2 relay v1.2 for new Qubino Flush 2 Relay Plus (ZMNHBD1 H1S5P2) v5.0 with no cost (I only had one). It immediately started to work with the latest stable openHAB release 2.2.0-1 and z-wave binding.
I suppose replacing Qubino relays is the best solution both for endusers and for @chris if your reseller is willing to replace.

[vossivossi]

@chris

Actually it looks like I already updated the database… I’ll do a binding update tomorrow if I get time, otherwise Friday.

Hi Chris, could you already find the time for the binding update?

Thanks,
Martin

[Guido_van_Haasteren]

I am not sure whether this is related, if not, tell me and I will start enother thread.
I use Openahbian on Raspi 2B, OH2.2.0-1 Releas-built, Aeon Z-stick Gen5.
I have several Qubino Flush 1 Relais, Flush 2 Relais, and a Flush shutter. Satusupdates are sometimes working sometimes not. For now I am testing a Flush 2 Relais ZMNHBD1, firmware v5.0, and for the test I deleted everything in my items-file, rules-file and sitemap, except the following parts. I did not delete any things.
I have a physical switch connectend to only to l1, which switches the light. My simple rule then switches on the ventilation with the second relais. In the end there will be more logic to this. But I have the problem that once every 3-4 times I turn on the light, the light will stay on for several seconds, then it will go out for a few seconds, end the both the light and the ventilation are turned on. Sometimes I can here switching goining on several times, without either the ventilation or the light coming on.
Underneath you find my logging. As far as I can tell, only the intended swiching is logged. (I did not yet turn on zwave debug logging, will do that after this post and report back if interesting).

items:

Group Badkamer
//Badkamer
Switch Lamp_BK "Licht badkamer" <switch> (Badkamer) { channel="zwave:device:f4f7d5ef:node13:switch_binary1"}
Switch Ven_BK "Ventilator badkamer" <switch> (Badkamer) { channel="zwave:device:f4f7d5ef:node13:switch_binary2"}

sitemaps:

sitemap default label="Sonsbeek"{
        Switch item=Lamp_BK
        Switch item=Ven_BK
}

rules:

rule "Ven_bad_aan"
when
	Item Lamp_BK changed from OFF to ON
then
	Ven_BK.sendCommand(ON)
end

rule "Ven_bad_uit"
when
	Item Lamp_BK changed from ON to OFF
then
	Ven_BK.sendCommand(OFF)
end

log:

2018-01-21 12:09:36.488 [vent.ItemStateChangedEvent] - Lamp_BK changed from OFF to ON

2018-01-21 12:09:36.496 [ome.event.ItemCommandEvent] - Item 'Ven_BK' received command ON

2018-01-21 12:09:36.529 [vent.ItemStateChangedEvent] - Ven_BK changed from OFF to ON

2018-01-21 12:09:36.545 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f4f7d5ef_serial_ack changed from 5321 to 5322

2018-01-21 12:09:36.551 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f4f7d5ef_serial_sof changed from 15582 to 15583

2018-01-21 12:09:36.751 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f4f7d5ef_serial_sof changed from 15583 to 15584

2018-01-21 12:09:39.987 [vent.ItemStateChangedEvent] - network_device_192_168_0_21_time changed from 601.0 to 618.0

2018-01-21 12:09:45.708 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f4f7d5ef_serial_sof changed from 15584 to 15585

2018-01-21 12:09:46.245 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_memory_available changed from 581 to 580

2018-01-21 12:09:46.254 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_cpu_load changed from 31.4 to 31.8

2018-01-21 12:09:46.274 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_memory_availablePercent changed from 59.9 to 59.8

2018-01-21 12:09:46.314 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_memory_usedPercent changed from 40.1 to 40.2

2018-01-21 12:09:46.348 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_memory_used changed from 389 to 390

Is this problem related to the problems of reporting state in this thread? Or should I ask for help in a new thread?
Maybe also related: my zwave mesh does not look much like a mesh…

[Guido_van_Haasteren]

I’m afraid I have to confirm that with OH2.2.0-1, the Qubino Flush-2 relais do not report back their state.
My rules work when I change inputs to the rule from the sitemap, but not from the fysical switches connected to the Relais.

[vossivossi]

@Guido_van_Haasteren

with OH2.2.0-1

This has nothing to do with the OH2 release as such, the important point is which version of the Z-Wave binding do you use? You can get the version in Karaf Console with the list command.

[Guido_van_Haasteren]

Oww, I though newer OH would install corresponding number Zweave-binding.
I did:
ssh into Raspberry Pi (Openhabian)
ssh -p 8101 openhab@localhost
bundle:list

And found: 222 Active 80 2.2.0 Zwave binding

I guess this means I am on Zwvae binding 2.2.0?
Should I upgrade to newest version? I believe this would be 2.3.0?

I hastitate to do this since I see so many problems in this forum about upgrading. But If I am right the instructions would be to:

1. Deinstall Zwave binding from PaperUI
2. Upgrade OH from stable to snapshot from openhabian-config
3. Download latest binding-jar from link in main zwave refractoring-thread
4. And then reboot
5. If no zwave-binding, type command from Karaf Console (??) feature:install openhab-transport-serial
6. Reboot again

Is this alright?

[vossivossi]

@Guido_van_Haasteren

And found: 222 Active 80 2.2.0 Zwave binding

I guess this means I am on Zwvae binding 2.2.0?

This means you are using the release version, not the dev branch.
You can find the dev version and an instruction how to install at the beginning of this thread:

https://community.openhab.org/t/oh2-z-wave-refactoring-and-testing-and-security/21653

Try to exclude the device and then reinclude it with the most recent dev version by using Habmin and the network wide inclusion.

[Daniel_Linder]

Dear all,
I just want to check - is anyone getting the “state report” from hardware switch to controller to function correctly for the dimmers. If so - with which binding?
I have been following this thread and the development binding thread for a very long time.
Chris has been checking my logs, changes have been made - it has been working from time to time.
Now (using the Jan 21 development snapshot) it doesn’t.

I have not gotten any further with this for a year - sometimes it works - most of the time it does not.
I am really considering scrapping all my Qubino equipment, since I cannot live with anything that requires continuous tinkering - for very unstable performance.
It is so frustrating that something works, and then (for some reason I do not know) just suddenly stops.

So, please - I value any feedback from someone that has gotten this to work…

[h4l1s (Halis)]

I agree with you that this is frustrating. I also experience a lot of trouble with this devices. I hope there will be soon a solution for this problem as otherwise all my qubino devices will replaced by fibaro devices.

[ypoosn]

Wrong status updates !!!

Hi,

it seems that I get wrong status updates from Qubino ZMNHDD Firmware 3.5

Szenario:

1. Dimmer is switched “OFF”. Lights are off
2. After a while status of the item is updated to “'ON”, but nobody touched the wall switch or openhab’s UI

In the logs you find the following mysterious entries:

events.log:

2018-02-03 21:57:47.836 [ome.event.ItemCommandEvent] - Item 'EG_KU_SP_Helligkeit' received command OFF
2018-02-03 21:57:47.906 [vent.ItemStateChangedEvent] - EG_KU_SP_Helligkeit changed from 100 to 0
... mysterious things happen now
2018-02-03 22:14:45.645 [vent.ItemStateChangedEvent] - EG_KU_SP_Helligkeit changed from 0 to 100

openhab.log:

2018-02-03 21:57:47.878 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Command received zwave:device:15ff39b3682:node20:switch_dimmer1 --> OFF
2018-02-03 21:57:47.962 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 20: Creating new message for application command SWITCH_BINARY_SET
2018-02-03 21:57:48.030 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build null
2018-02-03 21:57:48.054 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Encapsulating message, endpoint 1
2018-02-03 21:57:48.085 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Encapsulating message, instance / endpoint 1
2018-02-03 21:57:48.119 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 20: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 1
2018-02-03 21:57:48.158 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: SECURITY not supported
2018-02-03 21:57:48.186 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Command Class COMMAND_CLASS_MULTI_CHANNEL is NOT required to be secured
2018-02-03 21:57:48.226 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 20: Creating new message for application command SWITCH_BINARY_GET
2018-02-03 21:57:48.264 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build COMMAND_CLASS_SWITCH_BINARY
2018-02-03 21:57:48.294 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Encapsulating message, endpoint 1
2018-02-03 21:57:48.326 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Encapsulating message, instance / endpoint 1
2018-02-03 21:57:48.360 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 20: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 1
2018-02-03 21:57:48.399 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: SECURITY not supported
2018-02-03 21:57:48.427 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Command Class COMMAND_CLASS_MULTI_CHANNEL is NOT required to be secured
2018-02-03 21:57:48.468 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: Adding to device queue
2018-02-03 21:57:48.497 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: Added to queue - size 1
2018-02-03 21:57:48.527 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2018-02-03 21:57:48.560 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: listening == true, frequentlyListening == false, awake == false
2018-02-03 21:57:48.605 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from sendQueue  
2018-02-03 21:57:48.634 [DEBUG] [nal.protocol.ZWaveTransactionManager] - getTransactionToSend 6
2018-02-03 21:57:48.664 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0E 00 13 14 07 60 0D 01 01 25 01 00 25 56 CB 
2018-02-03 21:57:48.710 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 20: Sending REQUEST Message = 01 0E 00 13 14 07 60 0D 01 01 25 01 00 25 56 CB 
2018-02-03 21:57:48.754 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2018-02-03 21:57:48.758 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2018-02-03 21:57:48.781 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 185: Transaction Start type SendData 
2018-02-03 21:57:48.819 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2018-02-03 21:57:48.850 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 185: [WAIT_RESPONSE] requiresResponse=false callback: 86
2018-02-03 21:57:48.889 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2018-02-03 21:57:48.930 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd class: null
2018-02-03 21:57:48.965 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
2018-02-03 21:57:48.964 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
2018-02-03 21:57:49.021 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2018-02-03 21:57:49.000 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd: 0
2018-02-03 21:57:49.067 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
2018-02-03 21:57:49.050 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-02-03 21:57:49.138 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
2018-02-03 21:57:49.101 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage Transactions outstanding: 1
2018-02-03 21:57:49.193 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 56 00 00 02 BF 
2018-02-03 21:57:49.155 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2018-02-03 21:57:49.251 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2018-02-03 21:57:49.226 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Sat Feb 03 21:57:51 CET 2018 - 2000ms
2018-02-03 21:57:49.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[0x13], type=Request[0x00], dest=0, callback=86, payload=56 00 00 02 
2018-02-03 21:57:49.267 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
2018-02-03 21:57:49.362 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=SendData[0x13], type=Request[0x00], dest=0, callback=86, payload=56 00 00 02 
2018-02-03 21:57:49.322 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage lastTransaction: TID 185: [WAIT_RESPONSE] requiresResponse=false callback: 86
...
2018-02-03 21:57:52.646 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: Application Command Request (ALIVE:DONE)
2018-02-03 21:57:52.670 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: resetResendCount initComplete=true isDead=false
2018-02-03 21:57:52.696 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2018-02-03 21:57:52.720 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Incoming command class COMMAND_CLASS_SWITCH_BINARY, endpoint 1
2018-02-03 21:57:52.748 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: SECURITY not supported
2018-02-03 21:57:52.770 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 20: Received COMMAND_CLASS_SWITCH_BINARY V1 SWITCH_BINARY_REPORT
2018-02-03 21:57:52.798 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 20: Switch Binary report, value = 0
2018-02-03 21:57:52.823 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2018-02-03 21:57:52.852 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-02-03 21:57:52.884 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Got a value event from Z-Wave network, endpoint = 1, command class = COMMAND_CLASS_SWITCH_BINARY, value = 0
...
2018-02-03 22:14:45.115 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: Response processed after 2106ms
2018-02-03 22:14:45.136 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: TID 231: Transaction completed
2018-02-03 22:14:45.158 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: notifyTransactionResponse TID:231 DONE
2018-02-03 22:14:45.182 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2018-02-03 22:14:45.207 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-02-03 22:14:45.237 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 07 60 0D 01 01 26 03 63 
2018-02-03 22:14:45.276 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-02-03 22:14:45.295 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: Application Command Request (ALIVE:DONE)
2018-02-03 22:14:45.318 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: resetResendCount initComplete=true isDead=false
2018-02-03 22:14:45.343 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2018-02-03 22:14:45.367 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 1
2018-02-03 22:14:45.395 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 20: SECURITY not supported
2018-02-03 22:14:45.416 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 20: Received COMMAND_CLASS_SWITCH_MULTILEVEL V3 SWITCH_MULTILEVEL_REPORT
2018-02-03 22:14:45.445 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 20: Switch Multi Level report, value = 99
2018-02-03 22:14:45.471 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2018-02-03 22:14:45.498 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-02-03 22:14:45.529 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Got a value event from Z-Wave network, endpoint = 1, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 99
2018-02-03 22:14:45.591 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Updating channel state zwave:device:15ff39b3682:node20:switch_dimmer1 to 100 [PercentType]
2018-02-03 22:14:45.631 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: Commands processed 1.
2018-02-03 22:14:45.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 20: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@c59fa5.

I have no idea what could be wrong. Why does the “SWITCH_MULTILEVEL_REPORT” at “2018-02-03 22:14:45.416” report value 99 although the “SWITCH_BINARY_REPORT” at “2018-02-03 21:57:52.720” reports 0.

Is this a firmware bug in 3.5 ? Or is the value wrong interpreted?

I am using

227 │ Active   │  80 │ 2.2.0.201801021718     │ ZWave Binding

Any help is appreciated.

best,

ypoosn

[rozpruwacz (Marek)]

Yes, I had the same problem. Talked to qubino and they advised to send them the dimmer to update the firmware. I did that, and today I got a dimmer with 3.7 firmware version, and it seems that now is ok. But i just tested it for an hour now.

[Daniel_Linder]

Hi,
Thought I should do some more inclusion test this evening (note I am not a programmer - just a simple Mechanical Engineer, so software/code review is not one of my skills. ).
I have a number of Qubino v2 dimmers with firmware 1.1. One of the has been included a long time - and works perfect. Inclusion of the rest goes well, but I do not get any feedback to openhab from the switches (it bugs me that one out of four works for some reason). So - i started to include a switch using Zensys tools, and directly from the Aeon stick. It took a couple of tries, but It seemed to go through the full handshake procedure. Also the list of command classes seems equal to the “working dimmer”.
When i toggle the hardware switch, zensys tools shows a message “COMMAND_CLASS_SWITCH_MULTILEVEL.SWITCH_MULTILEVEL_REPORT, hex data 26 03 38” when I toggle the light on, and “COMMAND_CLASS_SWITCH_MULTILEVEL.SWITCH_MULTILEVEL_REPORT, hex data 26 03 00” when I toggle it off. This is the identical to the “working dimmer”.
However, when adding the dimmer in Habmin/Openhab (Jan 21 test bindning) after that, it does not report state. Also - when checking in Zensys tools - it does no longer report state changes from the physical switch. I do not understand what is going on here. It seems to report back - using zensys tools (similar to an identical switch that is fully functional in openhab). But adding it to openhab seems to break that

@chris: Do you have any guidance what I should do/try?

[Kjamsek]

This sounds like a clear SC/MC Lifeline related issue. If this association isn’t set then the device is not allowed to send reports without polling.

I’ve seen on OpenHAB that whenever you go and change any configuration settings for the device on the paper UI, that the controller goes and removes association groups and doesn’t always set them back. So it would explain why previously working devices suddenly stop reporting if you start to change any configurations. See here, a log from the zniffer:

[Carsten_OW (Carsten)]

Hello,

i have the same Problem with the fibaro dimmer, no stats from the physical Switch.

Carsten

[domoticaundici (Stefano Pecoraro)]

hello,
i’m doing tests over tests with my RPI3 + AeonLabs Z-Stick gen5. i’m trying with openhab version 2.2.0 release build and 2.3 snapshot. it seems 2.3 zwave binding going better, updates regulary device parameters while 2.2.0 gives an error.
Qubino ZMNHBD1: channels switch_binary and switch_binary3 switches both relays. when an input is pressed the relative channel (switch_binary1 or switch_binary2) is not updated, the only one updates is switch_binary. for the power metering is the same.
Phlio PAN04-1B: behaviour is exactry the same as for Qubino ZMNHBD1
Qubino Smart meter: the only way to make it works is been polling the device instead of wait for datas. received datas are correct but it’s not possible to imagine to poll for any device.
Finbaro Dimmer2 FGD-212: currently i have no push button on input, i only change dimming value from interface. here, as before, the only way to get updated power consumption is to poll the device.

how to fix this behaviour?
thanks

[domoticaundici (Stefano Pecoraro)]

also:
Qubino ZMNHAD1 Flush 1 relay: no way to get input states for i2, i3

checking communication by openzwavecontrolpanel the results are the same.

in habmin, association groups seems to be ok:
qubino devices: lifeline -> openhab controller

phlio devices: relay1+2 -> openhab controller as well as relay1 and relay2

[Kjamsek]

For most of the issues mentioned by @domoticaundici the cause of the issue is in setting the singlechannel or multichannel lifeline associations that are used by Z-Wave devices to report unsolicited state changes.

In case a device support the MultiChannel CC, and as such implements endpoints, then a multichannel lifeline should be set via the use of Multichannel Association Set multichannel Node ID and endpoint fieldcombinations.

In case a device doesn’t support Multichannel CC, and as such does not implement endpoints, then a singlechannel lifeline association should be set via the use of Association Set and Node ID fields.

Without these two association settings in place (depending on which one applies to your device) you WILL NOT see state changes being reported to the controller on any Z-Wave Plus device.

[stefan.hoehn (Stefan Höhn)]

I documented how I did update to 2.3.0 as openhabian-config did not work for me:

see here:

First major update in 2.3.0-SNAPSHOT

Even though I couldn’t get it to run through the openhabian-config, @omr was so kind to explain to me how it could be done manually cat /etc/apt/sources.list.d/openhab2.list shows the old content. Change the file (e.g. with nano) to have the following content deb http://openhab.jfrog.io/openhab/openhab-linuxpkg unstable main After changing file, do: sudo apt-get update sudo apt-get upgrade What could have worked though in openhabian config is to go into 40 openhab-related and then switc…

and here

How to use the Fibaro Keyfob and to manage challenges around it

Certainly: (I only know ‘how to’ with ubuntu-server 16.04 LTS, but is probably the same) OH2: omr@shs2:~$ cat /etc/apt/sources.list.d/openhab2.list deb http://openhab.jfrog.io/openhab/openhab-linuxpkg unstable main omr@shs2:~$ After changing file, do: sudo apt-get update sudo apt-get upgrade Z-wave binding: First uninstall from PaperUI. Download from here Goes into: /usr/share/openhab2/addons/ Do not re-install from PaperUI You might need to install this from karaf: (if no nodes are…