Testing Z-Wave binding on openHAB-2

Yes.

It shouldn’t change anything - it just stops the binding - the same thing that happens when OH2 stops, and then restarts - nothing is touched with the config.

Hi @chris,

thank you for your reply. After testing the device (Düwi Wireless plug adaptor switch
ZW ZS 3500) with Homee (english Website coming soon) and Open-Z-Wave it seems that the hardware is defect :confused: Won’t spend any more of your and my rare spare time on testing it an i throw it to the trashcan :-1:

The original german supplier of my device called DÜWI is “insolvent” since 2009, it isn’t of worth to spent time on it :wink:

Regards,
Heiko

I mean that I saw the nodeX.xml with the last version. Then I think that nodes are correctly discovered with the current version of Binding.

Also, I can send you some logs of the discovering process, what do you think about that ?

When I talk about an older version, I mention the first version you published by provide source link in this ZWave status under OH2 topic. I compiled this version in december. I will try to get the version number.

Regards,

Pascal

I’m seeing exceptions with one of my nodes - a Qubino flush shutter.
Not sure if this is known issue or not.
I have updated to the snapshot from today, but it is still there;

21:58:14.311 [WARN ] [ocol.ZWaveController$ZWaveSendThread] - NODE 10: Too many retries. Discarding message: Message: class = SendData (0x13), type = Request (0x00), payload = 0A 02 26 02 
21:58:14.312 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
21:58:14.312 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 0A 02 26 02 25 C2 2E 
21:58:14.312 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 10: Sending REQUEST Message = 01 09 00 13 0A 02 26 02 25 C2 2E 
21:58:14.316 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
21:58:14.317 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
21:58:14.317 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8 
21:58:14.317 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8 
21:58:14.317 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = SendData (0x13), type = Response (0x01), payload = 01 
21:58:14.317 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 10: Sent Data successfully placed on stack.
21:58:14.331 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 C2 00 00 02 2B 
21:58:14.332 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
21:58:14.332 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 C2 00 00 02 00 00 25 
21:58:14.332 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 C2 00 00 02 00 00 25 
21:58:14.332 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = SendData (0x13), type = Request (0x00), payload = C2 00 00 02 
21:58:14.332 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 10: SendData Request. CallBack ID = 194, Status = Transmission complete and ACK received(0)
21:58:14.332 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 0A 02 26 02 
21:58:14.332 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Recv message Message: class = SendData (0x13), type = Request (0x00), payload = C2 00 00 02 
21:58:14.332 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, expected=ApplicationCommandHandler, cancelled=false
21:58:14.363 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 0A 03 26 03 FE 20 
21:58:14.363 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
21:58:14.363 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 0A 03 26 03 FE 20 
21:58:14.363 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 0A 03 26 03 FE 20 
21:58:14.363 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0A 03 26 03 FE 
21:58:14.364 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Application Command Request (ALIVE:DYNAMIC_VALUES)
21:58:14.364 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Incoming command class SWITCH_MULTILEVEL
21:58:14.364 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 10: Received Switch Multi Level Request
21:58:14.364 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 10: Switch Multi Level report, value = 254
21:58:14.364 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
21:58:14.364 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
21:58:14.364 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_MULTILEVEL, value = 254
21:58:14.364 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Checking channel zwave:qubino_zmnhcd_00_000:controller:node10:switch_dimmer
21:58:14.364 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Processing event as channel zwave:qubino_zmnhcd_00_000:controller:node10:switch_dimmer PercentType
21:58:14.364 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2.
java.lang.IllegalArgumentException: Value must be between 0 and 100                                                                                                                                            

21:58:14.375 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 18: Stage PING. Initialisation retry timer triggered. Increased to 320000

From what I read in the Z-Wave documents, this value (0xFE) is forbidden, but maybe it’s something new… It would be interesting if you can see if it’s linked to anything ‘special’ - eg when the shutter is in a certain position or something…

The value can be either 0x00 (off/disable) or 0xFF (on/enable). Furthermore it can return values from 1 to 99 (0x01 – 0x63). Devices must not respond with a Multilevel Switch Report with any other value.

I’ll also add a check in the to stop this and assume it is 100%.

Hello @chris
I’m just getting started with OH2 on an rpi2 and have gotten everything installed as it should be I believe. I’m using the Aeon z-stick series 2. The v2 binding seems to communicate with it, and I was able to get it to discover my Leviton DZPD3-1LW. However, it discovered it as an unknown device (it seems to detect that it’s a dimmer though). I’m assuming this is because its not in the database. I would like to get some of these things working in addition to my Aeon minimote, which is not in the db either. How can I contribute? I see where the xml files are being generated. Do I just upload the xml file to the database at http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list? Is there any way for me to assign channel definitions myself and whatnot? I’m not completely familiar with zwave and OH as I never had OH1 and never used the old school method of adding devices. There is somewhat of a lack of documentation on OH2. Much of the content online pertains to OH1, and OH2 seems to have changed many things, making most documentation useless (so it seems). I guess I’m just wondering how I can dig in and actually map out my own zwave devices, and potentially submit a working definition to your database. I’m also interested in getting zigbee working. I posted up a question about that on github I believe and mentioned you, because you are working on that binding as well right? I bought 2x of the TI sticks, and have the programmer on order.
Thanks for any info you can provide! Perhaps it would help everyone if these things were documented somewhere besides this thread? I can try to help in whatever way I can. I’ve been coding in PHP and Python professionally and have done some C++ and Java way back in the day. Been coding for 18 years off and on so I know a thing or two. I would love to assist in some way!

Hi Chris,

The older version which works with Fibaro Plug FPGWE is org.openhab.binding.zwave_2.0.0.201512291053.

The logs with the new binding (update from openhab2 today) shows that the devices are correctly discovered (I think…).
However, they stay OFFLINE.

When I try to switch on/off the NODE 3 the binding try to send command to NODE 0.

I found the issue by desactivated the autoapprove=true in the runtime.cfg.
When I desactivate the autoapprove, the device appears ONLINE.

But in this case I have no items created automatically when I add the things from Inbox to a group.
Also, when I try to activate channels, no corresponding items are shows to be selected.
I need to notice that I use PaperUI.

How can I have the Items created without autoapprove actived ?

Regards,

Pascal

Pascal
The generation of items is not linked to auto approve. I also have auto approve disabled.

I think items should be generated when you approve the thing. If not you can easily create them in Habmin and probably PaperUI.

Chris

Thanks for your answer Chris,

Do you means that when you approve manually the thing, the items has been created automatically ?

If that, it will be convenient, but on my side the items are not generated when I approve the thing.
That’s why I add the autoapprove feature.
In some previous topics (from Kai in 2014) I saw that a bundle has been developped to create items automatically but I can’t find it now in the repository.

Have you got some idea around that ?

Regards,

Pascal

My understanding, which might be wrong, is that autoapprove just approves the thing - I didn’t think that it did anything different than manually approving. I don’t however use auto-approve, so I don’t know what it does.

Items are currently automatically created when the thing is added from the inbox, but this might be removed in the near future, but adding a new thing (in HABmin at least) should be as simple as pressing 2 buttons, so I’m still not really sure what the problem is - sorry.

Chris

not sure if this also affetcs habmin but…

if you activated “AdvancedMode” checkbox in paper ui no channles are auto populated … worth a look / check

It doesn’t affect HABmin in that the ‘Advanced Mode’ feature only hides some options. Up until now, HABmin should create the items, but it’s likely to stop to let people create their own, but as I said, you can do this with 2 clicks per channel in HABmin - it’s not too hard I think :wink:.

Newly added HA-01C In-Wall Dual Receptacle discovered, linked, and switching as expected in Build #168.

Chris,

Here are two nodes that shows up as unknown;

Node 5 is the Z-Wave.Me Wall Controller 06443, that had issues before your fix;
xml: https://drive.google.com/open?id=0B1-V_L_iOMcSSWd4blhHYVBENms

Node 19 is a Düwi (Ritter) EDAN 300 Art-nr 0505433555 Flush mount Dimmer
xml: https://drive.google.com/open?id=0B1-V_L_iOMcScGh1OGtGNTNPR0E

I’ve added the node 19 - node 5 needs some more work as it’s a scene controller and I need to sort this out over the next week…

Great!

I must say that the binding is working quite well - already much better than my Vera. :slight_smile:
In combination also with the Aeon gen 5 usb stick Including and Excluding are easier than ever before.

Chris, I have this sometimes. How should the “false unknowns” be treated? Shall I “delete” them, or “ignore” them or mentally ignore them (this is hard!).
Once I get a false, they seam to stick around.

Hi Chris,

You’re right, but when I use auto-approve, it creates also the items.
Yes, I know it’s very simple to add new thing, but I want to have the items created automatically (with UUID).

Thanks for your answer

Thanks a lot.

Yes!!! The issue comes with the “Advanced Mode”. It resolves the problem.

Regards,

Pascal

New unknown: Düwi/Reitz ZW ES 1000 "Flush Mount Switch"
xml: https://drive.google.com/open?id=0B1-V_L_iOMcSV3VQd1RfZlhaUzA