Hi Chris, could you already find the time for the binding update?
Thanks,
Martin
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…
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.
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.
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:
- Deinstall Zwave binding from PaperUI
- Upgrade OH from stable to snapshot from openhabian-config
- Download latest binding-jar from link in main zwave refractoring-thread
- And then reboot
- If no zwave-binding, type command from Karaf Console (??) feature:install openhab-transport-serial
- Reboot again
Is this alright?
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.
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…
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.
Wrong status updates !!!
Hi,
it seems that I get wrong status updates from Qubino ZMNHDD Firmware 3.5
Szenario:
- Dimmer is switched “OFF”. Lights are off
- 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
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.
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?
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:
Hello,
i have the same Problem with the fibaro dimmer, no stats from the physical Switch.
Carsten
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
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
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.
I documented how I did update to 2.3.0 as openhabian-config did not work for me:
see here:
and here
ok, working with association groups meakes the thing better, here the latest results.
i’m working with the latest cloudbees 2.3.0 zwave binding.
note: using habmin i can see the applied setup (in example correct values in association groups), while using paper ui, when i choose a value from the dropdown fields, the value is empty after saving. so it’s better with habmin.
Phlio PAN04-1B: the same results with any combination of association groups: any switch i change i can only see “switch_binary” channel changes so i don’t know which channel is up and which is down. the same i can see consumption but i down’t know which channel is using that power.
Qubino ZMNHBD1: setting only “default reporting group” to “openhab controller” make it works perfectly on both channels: output state and consumption
Qubino ZMNHAD1 Flush 1 relay: setting only “default reporting group” to “openhab controller” (other combinations have the same effects) no way to know if relay is on or off. triggering i3 i can see “switch_binary” tigger, triggering i2 i can see both “switch_binary” and " sensor_binary" triggering so it’s confusing. triggering i1 i can’t see anything.
for all devices i’ve configured any given channel and if i trgger switch from ui any relay triggers correctly, so it’s only in receiving datas.
hope this helps.
I am having problems with the Qubino Fluss Dimmer with firmware V3.7, which I posted here:
Does someone experience the same behaviour?
@chris So, I finally found some time (and nerves) to get back to my beloved Qubino ZMNHSD1 DIN dimmers: I recently set up a new openHAB 2.2 installation and realised that status updates and wall switch presses are still missing for my dimmers. So, I manually updated the Z-Wave binding to 2.3, but still no luck. Even after excluding the dimmers, resetting them and including them again - no updates. No matter what I did with the association groups, no updates.
Yesterday I found this guide that describes how to setup (compile) the Open Z-Wave Control Panel on my Raspberry Pi / openHABian installation. So I did that out of interest, to diagnose my setup. After stopping openHAB and starting OZCP, I pressed the wall switches and got the following log events:
2018-05-13 14:07:51.534 Detail, Node017, Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x11, 0x07, 0x60, 0x0d, 0x01, 0x00, 0x20, 0x01, 0xff, 0x52
2018-05-13 14:07:51.534 Error, Node017, Received a MultiChannelEncap for endpoint 1 for Command Class 32, which we can't find
2018-05-13 14:07:52.233 Detail, Node017, Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x11, 0x07, 0x60, 0x0d, 0x01, 0x00, 0x20, 0x01, 0x00, 0xad
2018-05-13 14:07:52.278 Error, Node017, Received a MultiChannelEncap for endpoint 1 for Command Class 32, which we can't find
Something was indeed happening, but not in the right kind of way. I decided to exclude/reset/include my dimmers using OZCP. Finally, status updates arrived in a way that didn’t register as errors in the OZCP log (no on/off switch events, but at least power output dropped to 0):
2018-05-13 19:24:08.933 Detail, Node019, Received: 0x01, 0x10, 0x00, 0x04, 0x00, 0x13, 0x0a, 0x32, 0x02, 0x21, 0x34, 0x00, 0x00, 0x00, 0x32, 0x00, 0x00, 0xe5
2018-05-13 19:24:08.934 Detail,
2018-05-13 19:24:08.934 Detail, Node019, Refreshed Value: old value=false, new value=false, type=bool
2018-05-13 19:24:08.935 Detail, Node019, Changes to this value are not verified
2018-05-13 19:24:08.935 Info, Node019, Received Meter report from node 19: Power=5.0W
2018-05-13 19:24:08.936 Detail, Node019, Refreshed Value: old value=5.5, new value=5.0, type=decimal
2018-05-13 19:24:08.936 Detail, Node019, Changes to this value are not verified
2018-05-13 19:24:08.937 Detail, Node019, Notification: ValueChanged
2018-05-13 19:24:08.937 Info, Notification: Value Changed Home 0xf248b5ca Node 19 Genre user Class METER Instance 1 Index 32 Type bool
2018-05-13 19:24:08.937 Detail, Node019, Notification: ValueChanged
2018-05-13 19:24:08.938 Info, Notification: Value Changed Home 0xf248b5ca Node 19 Genre user Class METER Instance 1 Index 8 Type decimal
I stopped OZCP, started openHAB, which immediately detected the new things. Even before adding them, I could see status updates in the log. Already enjoying my victory, I added the things using Paper UI and merely edited the location. After saving, the party was over. No more updates, no matter what I do in Paper UI or HABmin.
When the status updates were working, I could see that the lifeline was set in the OZCP log:
2018-05-13 19:22:48.542 Info, Node019, Adding the controller to group 1 (Lifeline) of node 19
2018-05-13 19:22:48.542 Info, Node019, MultiChannelAssociation::Set - Adding instance 0 on node 1 to group 1 of node 19
2018-05-13 19:22:48.543 Detail, Node019, Queuing (Send) MultiChannelAssociationCmd_Set (Node=19): 0x01, 0x0b, 0x00, 0x13, 0x13, 0x04, 0x8e, 0x01, 0x01, 0x01, 0x25, 0xbd, 0xe7
2018-05-13 19:22:48.543 Info, Node019, Get MultiChannelAssociation for group 1 of node 19
2018-05-13 19:22:48.544 Detail, Node019, Queuing (Send) MultiChannelAssociationCmd_Get (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x8e, 0x02, 0x01, 0x25, 0xbe, 0xe0
2018-05-13 19:22:48.544 Detail, Node019, Expected reply and command class was received
2018-05-13 19:22:48.544 Detail, Node019, Message transaction complete
If I now view the logs in OZCP, I get the errors shown in the first code block again (MultiChannelEncap for endpoint 1 for Command Class 32). No lifeline message. So, what’s the Z-Wave binding doing differently?