ZWave binding updates

No worry… I just didnt want to activate this option, if it´s still an issue…

If the process in the first post don’t work, what is the next thing I should try? Should I go ahead and also remove the controller? Exclude everything? Remove items?

Setting on/off from OpenHAB isn’t working with my zwave switches. They’re all Zooz brand, and I mostly just use them for monitoring power usage. They still report on/off when I manually press it, they still report power, and my other Zooz sensors are working. So OpenHAB is receiving updates from them, but they’re not obeying changes made in OpenHAB. I don’t use them very often, but they were definitely working when I was on 2.5 milestone 3. I’ve updated to each milestone and then the final since then. My version of the binding doesn’t seem to be stuck or anything (according to the console). Thanks!

Please advise what the devices are and provide a debug log showing what happens when you send the command.

Here’s some of the log for this device:
Z-Wave Node 009: ZEN15 Power Switch
Debug logging gets really loud with my other sensors, so I tried to boil it down. Let me know if you need more. Thanks you!
Node9-On-Off-Log.txt (9.0 KB)

Filtered logs are of no use for troubleshooting.

I have 2 of ZEN 15 I received in the past few months.

I see we have 2 entries in the database. What firmware version do you have?

1 Like

Thanks. The log shows that the controller is not accepting the commands. Normally this happens when the controller is overloaded.

What controller do you have? Does it work for other devices?

1 Like

I think you solved it. It’s an Aeotec Z-Stick Gen5. I don’t have any other zwave devices that receive commands from OpenHAB (they only send), so I couldn’t tell you if other devices worked. I’d guess they wouldn’t have. But suspecting my controller, I unplugged it and plugged it back in, then rebooted. Seems fine now, and responding faster than before. I’ve rebooted before, but it is on a powered hub, so I don’t think that was enough. I’ll move things around and get it off of the USB hub.

The firmware is 1.4 according to OpenHAB. Although, that doesn’t seem to exactly match with the versions listed on Zooz’s website.

Sorry to waste your time with this, but I really appreciate the help!

Before I factory reset these locks, are there any known issues with the 2.5.0 binding and 914TRLv3 locks? I have one that is working, and 2 that are not and are giving me a

2020-01-05 23:08:11.828 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 53: Command class COMMAND_CLASS_DOOR_LOCK not found

after excluding and re-including them when I try to control them. All 3 show that they are using zwave secure and were added feet from the controller. The only difference I can see is that the non-functional ones aren’t showing the user codes while the functional one is as well as the SKU.

What would be the download site for the latest z wave snapshots now that 2.5 is released?

This should do it…

bundle:update org.openhab.binding.zwave

This one is a little more direct…

bundle:update org.openhab.binding.zwave

Actually,the second doesn’t seem to have the latest device db updates, so use the first one.

Chris has been pointing people to a 2.5 Jenkins link. I am traveling and cannot look that up currently. I think he posted it yesterday though.

EDIT: Here it is. @5iver you may want to bookmark this too.

I’m aware of what is on the CI server, but it should be used for viewing the status of the automated builds, not for distributing them. Since builds are continuously running, you can’t count on the CI server links being valid and odds are good that you won’t be able to download the file or it will be corrupt. It’s possible that we could put unneeded load on the server too, which would slow down or break the builds. So, it’s best not to use that server for downloads. We use Bintray for distribution.

Except they have not been posting timely addon snapshots for distribution between 2.5.0 and 2.5.1. That may not change.

I have 2 : NAS-WR01ZE| (dbReference|:1117, manufacturerId|: 0258, manufacturerRef|: 0200:1027, vendor: Shenzhen Neo Electronics Co., Ltd)
With 2.5.0 the appeared correctly in the PaperUI and HABmin.
After the upgrade to 2.5.1 (I also reinstalled the zwave binding).
They do not show correctly anymore :

But they seem to work correctly

As it says in your screenshot: delete the Thing and readd it (dont’t exclude)

Is that really true? There are static links that always provide the latest successful build -:

I wouldn’t think they should be corrupted, and they should always be available.

However, the CI server is sometimes offline which is annoying.

It’s one of the reasons I moved the manual install script over to bintray. It would frequently pull down 0KB files or corrupt files. When this would happen, it was repeatable when manually trying the link. Never had any issues with bintray. I would be nice if it was easier to find things in bintray, but if you know the file names, the search works well.

IIRC, every now and then I recall @kai requesting people use bintray for downloads too. I couldn’t locate a post, but I could very possibly be getting things mixed up with the Cloudbees move.

I recall a discussion too but that was before the reorganization for 3.0. I am not aware of any official direction after the changes. Users still need timely binding updates.

@chris I seem to have an issue where the commandPollPeriod value isn’t either being set or respected for some things. It seems to always just poll at 175ms, regardless of what I set it to.

Here’s some logs:

2020-01-14 20:25:48.977 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 12: Application update request. Node information received. Transaction null
2020-01-14 20:25:48.978 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: resetResendCount initComplete=true isDead=false
2020-01-14 20:25:48.979 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 12: Application update request. Requesting node state.
2020-01-14 20:25:48.980 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Got an event from Z-Wave network: ZWaveDelayedPollEvent
2020-01-14 20:25:48.981 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Polling initialised at 86400 seconds - start in 175 milliseconds.
2020-01-14 20:25:48.982 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 12: Application update - no transaction.
2020-01-14 20:25:49.156 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Polling...
2020-01-14 20:25:49.157 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Polling zwave:device:16f2b7d12f8:node12:switch_dimmer
2020-01-14 20:25:49.158 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 12: Generating poll message for COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2020-01-14 20:25:49.159 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 12: Creating new message for command SWITCH_MULTILEVEL_GET
2020-01-14 20:25:49.160 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: SECURITY not supported
2020-01-14 20:25:49.161 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
2020-01-14 20:25:49.162 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Polling skipped for zwave:device:16f2b7d12f8:node12:switch_dimmer on COMMAND_CLASS_BASIC
2020-01-14 20:25:49.163 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 12: Adding to device queue
2020-01-14 20:25:49.165 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 12: Added 321 to queue - size 3
2020-01-14 20:25:49.168 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 12: Sending REQUEST Message = 01 09 00 13 0C 02 26 02 25 20 CA 
2020-01-14 20:25:49.185 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 12: sentData successfully placed on stack.
2020-01-14 20:25:49.187 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 12: TID 321: Transaction not completed
2020-01-14 20:25:49.210 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 12: SendData Request. CallBack ID = 32, Status = Transmission complete and ACK received(0)
2020-01-14 20:25:49.211 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: resetResendCount initComplete=true isDead=false
2020-01-14 20:25:49.213 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 12: TID 321: Transaction not completed
2020-01-14 20:25:49.223 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 12: Application Command Request (ALIVE:DONE)
2020-01-14 20:25:49.224 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: resetResendCount initComplete=true isDead=false
2020-01-14 20:25:49.225 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2020-01-14 20:25:49.226 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: SECURITY not supported
2020-01-14 20:25:49.227 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 12: Received COMMAND_CLASS_SWITCH_MULTILEVEL V1 SWITCH_MULTILEVEL_REPORT
2020-01-14 20:25:49.228 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 12: Switch Multi Level report, value = 73
2020-01-14 20:25:49.229 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2020-01-14 20:25:49.229 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_MULTILEVEL, value=73
2020-01-14 20:25:49.231 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Updating channel state zwave:device:16f2b7d12f8:node12:switch_dimmer to 73 [PercentType]```

You can see in there that I had set it to `3000`, and there were no errors or anything.